Shit said in #python


 
Ciar Main Page >> TTK's Home Page
 
More quotes: Alaric   Fuz   Sonic   Pie   Izzy   Danny   TTK   Shit Said in Python   Shit Said in Go   mst
 
 
Display quotes in order:     
 [1071] #continuous-integration
2017-12-12 15:57:33 <Remram> there are packages out there whose setup.py is insane, and errors out on PY3, or does something different, or
          doesn't handle egg_info
2017-12-12 15:57:55 <Remram> as long as we have those, package management on Python is going to be broken
2017-12-12 16:04:00 <ttkpy> CPAN solves this by shoving all newly contributed modules through CI in various environments (windows, linux,
          freebsd, various versions of the language, etc) .. when a module fails to build, that is noted on its MetaCPAN page
2017-12-12 16:04:32 <ttkpy> and users avoid using it until module authors fix their code (which might be in the code itself or in the
          installation blargh)
2017-12-12 16:04:58 <ttkpy> might python apply a similar solution to root out these naughty setup.py?
2017-12-12 16:06:38 <ttkpy> example of a naughty module's CPANtesters CI results grid:  http://matrix.cpantesters.org/?dist=Curses+1.36
2017-12-12 16:06:58 <dw> ttkpy: i posted this very thing to python-ideas many moons ago and it was shot down by the packaging guys as "too much work"
2017-12-12 16:07:18 <nedbat> dw, ttkpy: build it
2017-12-12 16:07:26 <runciter> who pays for the CI?
2017-12-12 16:07:54 <ttkpy> runciter - the CPANtesters are volunteers who provide their own hardware
2017-12-12 16:08:06 <dw> nedbat: i feel strongly disincentivized by every packaging-related interaction i've ever had
2017-12-12 16:08:19 <runciter> as a contributor to open source projects that use existing CI service's free tier, it can be a bummer because the
          CI services response times vary from good to terrible
2017-12-12 16:08:20 <nedbat> dw: it doesn't have to be part of pypi, does it?
2017-12-12 16:08:32 <runciter> ttkpy: how do you trust the CPANtesters?
2017-12-12 16:08:33 <dw> nedbat: a good solution does, yes
2017-12-12 16:08:49 <nedbat> dw: not at first?  And why does it need to be part of pypi?
2017-12-12 16:08:52 <ttkpy> runciter - through time and familiarity, so you won't get trust immediately upon launch
2017-12-12 16:09:22 <runciter> ttkpy: a lot of open source communities in python seem to be moving away from self-hosted solutions
2017-12-12 16:10:50 * ttkpy contemplates how he'd prioritize a CPANtesters-for-pypi project
2017-12-12 16:11:11 * ttkpy glances at the 70+ other projects he's neglecting
2017-12-12 16:14:58 <dw> nedbat: because the alternatiev is scraping pypi for already-released packages to discover failures.
2017-12-12 16:15:05 <dw> nedbat: it needs to happen as part of release
2017-12-12 16:15:28 <nedbat> dw: at first, you'd need to do it asynchronously. too much stuff would become unavailable if you gate releases on it.
2017-12-12 16:19:51 <dw> ttkpy, nedbat: https://mail.python.org/pipermail/python-ideas/2014-April/027705.html was the thread in question, it
          never got nearly as far as discussing pypi integration before devolving into arguing about how much work it'd be
2017-12-12 16:21:53 <ttkpy> thanks, dw
2017-12-12 16:22:29 <ttkpy> the success of CPANtesters implies it's not insurmountably difficult
2017-12-12 16:22:53 <ttkpy> the python community is far more vibrant and energized, so it should be easier to pull off
2017-12-12 16:24:24 <dw> code and technology are rarely the difficult parts of any project
     #python
 
 
 [1027] #wrong
2013-11-26 11:00:43 <ttkp> At [REDACTED] we had python libraries with parts implemented in C, and the C code was all in separate files, with filenames prefixed by underscores.
2013-11-26 11:01:16 <ttkp> Does python have anything similar to perl's Inline::C module, for C-code and python code co-existing in the same source file?
2013-11-26 11:01:27 <dash> ttkp: there's stuff
2013-11-26 11:02:02 <ttkp> dash - what do you recommend?
2013-11-26 11:02:08 <dash> ttkp: depends on what you want to do
2013-11-26 11:03:43 <ttkp> dash - I'd like to hand out a python library, which I have partially written in C, with the expectation of people just using it without worrying about compiling it themselves (if they have a C compiler on their system).
2013-11-26 11:04:29 <dash> ttkp: what do the C parts do?
2013-11-26 11:05:20 <ttkp> dash - usually something math-intensive, like calculating the area of an irregular polygon.
2013-11-26 11:05:48 <dash> ttkp: sure. for that just use python
2013-11-26 11:06:28 <ttkp> dash - Well, I'd like it to perform nicely, and C usually performs between 100x and 1000x as well for math-intensive operations.
2013-11-26 11:06:47 <dash> ttkp: eh, maybe 2x-10x
2013-11-26 11:07:10 <ttkp> dash - I guess we've had differing experiences in that regard.
 
[Note: see a few actual microbenchmarks at: http://ciar.org/ttk/public/vs/ ]
 
     #python
 
 
 [1024] #wrong
2013-11-13 11:57:41 <kevlarman> dash: processes have difficulty efficiently communicating
2013-11-13 11:57:52 <dash> kevlarman: unix processes yes
2013-11-13 11:57:56 <dash> kevlarman: erlang processes less so
     #python
 
 
 [1015] #wrong
2013-10-18 11:17:46 <therealfakemoot> CrtxReavr: If open() throws an error, you'll know that it doesn't exist
2013-10-18 11:17:29 <therealfakemoot> CrtxReavr: If it's there, you'll be able to open it
     #python
 
 
 [1008] #wrong
2013-10-14 10:18:16 <Ivo> Eagle5: python's loops should iterate over collections of things most of the time, not usually a range of numbers like older languages (C, java) might.
 
[Note: Python was released in 1991; Java was released in 1995.  Aside from that, though, afaict the reasons people avoid C-style for loops are (1) an aversion to "math", and (2) they're a lot slower in python than iterating over a collection.)
 
     #python
 
 
 
 
    Ciar Main Page >> TTK's Home Page