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
 
 
 [1061] #thread_hate
2014-02-21 09:58:38 <triad> what do you think about algorithms ?
2014-02-21 09:58:50 <dash> triad: I'm against them.
2014-02-21 10:00:13 <cwillu_at_work> triad, the thing to keep in mind about dash is that he's seen things that would drive a lesser mind to despair at everything.  In his case, it's merely driven him to scoff at everything.
2014-02-21 10:00:57 <ttkp> dash's anger towards threads goes beyond scoffing.  he seems to want to eradicate them from the face of the planet.
2014-02-21 10:01:05 <ssbr_> ttkp: is that so wrong
2014-02-21 10:01:24 <dash> ttkp: we'd be better off without 'em, it is true
2014-02-21 10:01:48 <dash> ttkp: i am not particularly angry about technical mistakes of the past though
2014-02-21 10:02:01 <dash> ttkp: if i was going to take that route, i'd stay permanently angry all the time
     #python
 
 
 [1058] #thread_hate
2014-02-18 20:27:45 <dash> GIL is completely irrelevant to concurrency
2014-02-18 20:28:32 <ttkp> cool!  so it's possible to concurrently run python bytecode in the same process, now?
2014-02-18 20:28:48 <dash> ttkp: sure, has been since 1.x
2014-02-18 20:28:55 <dash> ttkp: in the obvious way
2014-02-18 20:29:11 <ttkp> "the obvious way" == threads, yes?
2014-02-18 20:29:17 <dash> ttkp: or an event loop
2014-02-18 20:29:40 <ttkp> the event loops with which I'm familiar don't provide concurrent execution
2014-02-18 20:30:18 <dash> ttkp: sure they do
2014-02-18 20:30:43 <ttkp> in the same process, using threads?
2014-02-18 20:30:54 <dash> ttkp: in the same process, not using threads
2014-02-18 20:31:17 <dash> ttkp: if you don't block then it's easy to process concurrent events
2014-02-18 20:31:47 <ttkp> oh, so you're *not* talking about concurrently running python bytecode
2014-02-18 20:31:55 <dash> ttkp: sure I am
2014-02-18 20:32:03 <dash> ttkp: i'm not talking about _parallel execution_, though.
2014-02-18 20:32:08 <ttkp> no, you're talking about concurrent events
2014-02-18 20:32:16 <ttkp> not bytecode processing concurrently
2014-02-18 20:32:19 <dash> ttkp: yes that is what concurrency is about.
2014-02-18 20:32:37 <ttkp> you had me all excited for a moment there 
2014-02-18 20:35:10 <ireallylikedogs> can anyone recommend a simple guide (perhaps with examples) to multithreading / thread pools? currently, i'm using imaplib/regex to do some searches on the contents of a bunch of emails, and it's taking a really long time.
2014-02-18 20:36:37 <dash> ireallylikedogs: enjoy this simple pictorial guide: http://goo.gl/movdCX
     #python
 
 
 [1056] #thread_hate
2014-02-07 13:10:53 <offby1> dash: I dunno.  Can't one thread kill another?
2014-02-07 13:10:58 <dash> offby1: no, of course not
2014-02-07 13:11:01 <offby1> no?
2014-02-07 13:11:07 <dash> offby1: How would that work?
2014-02-07 13:11:18 <offby1> I dunno :-)
2014-02-07 13:12:06 <dash> on linux, threads are not processes.
2014-02-07 13:12:35 <dash> offby1: a good rule of thumb is that using threads adds more problems, it doesn't remove them ;)
2014-02-07 13:13:48 <ttkp> POSIX.1-2001 allows for the signalling of individual threads .. qv the pthread_kill(3) man page
2014-02-07 13:13:53 <dash> ttkp: ha ha
2014-02-07 13:14:00 <dash> ttkp: you're hilarious.
2014-02-07 13:14:37 <ttkp> oh sorry, I forgot, threads are taboo here
2014-02-07 13:14:58 <therealfakemoot> ttkp: They're not taboo. They're just not the right tool for as many tasks as people think.
2014-02-07 13:15:01 <dash> ttkp: delusional statements unconnected to reality are taboo
2014-02-07 13:15:20 <dash> (for example, POSIX standards documents)
 
[Note: dash is wrong.]
 
     #python
 
 
 [1043] #thread_hate
2014-01-10 11:21:32 <dash> locsmif: python isn't the worst thing. It could just be better.
2014-01-10 11:24:37 <locsmif> dash: I've read about threading and the GIL.
2014-01-10 11:25:23 <dash> locsmif: python supports "actual threading" everywhere
2014-01-10 11:25:40 <dash> locsmif: but the presence of threads is one of the drawbacks of python i want to fix
2014-01-10 11:25:56 <locsmif> I read that in practice, the execution order is close to serial
2014-01-10 11:26:24 <locsmif> dash: what about the Windows kernel model where threading is supposedly more efficient than forking?
2014-01-10 11:26:29 <dash> locsmif: not really interesting in practice
2014-01-10 11:26:43 <locsmif> Okay
2014-01-10 11:27:11 <dash> locsmif: here's no real need to start processes or threads very often
2014-01-10 11:27:14 <ttkp> it's not like process shrinks are mostly fictional these days, and not contributing significantly to single-threaded performance, and future performance gains will be had primarily from effective utilization of concurrency.
2014-01-10 11:27:55 <dash> locsmif: if you want to spread cpu-bound work across multiple cores, then it's enough to start N processes at the startup of your app and distribute tasks between them
2014-01-10 11:28:10 <dash> locsmif: python doesn't make this easy or pleasant though
2014-01-10 11:28:54 <dash> the 'multiprocessing' module demonstrates how hacky python's data model really is
2014-01-10 11:31:32 <locsmif> I didn't know any of this, but I suppose that (you seem like one of the regulars here) you've tried things, seen things, and know very well what you're talking about. I had really hoped python could handle these things.
2014-01-10 11:31:53 <locsmif> But then again, you warned me about it now, let's see what I run into
2014-01-10 11:32:09 <cdunklau> locsmif: if you're doing io-bound stuff, twisted can help
2014-01-10 11:32:11 <dash> locsmif: defaults matter, and python's defaults were invented in the early 90s :)
2014-01-10 11:32:17 <cdunklau> especially if it's mostly networking
2014-01-10 11:32:25 <cdunklau> or talking to processes
2014-01-10 11:33:01 <dash> yeah. twisted is the nice thing in terms of model, but the API is more difficult than it has to be
     #python
 
 
 [1020] #thread_hate
2013-10-24 14:39:15 <ssbr`> dw: my attitude with locks in projects has been to remove them if they're for some abstract untested "thread safety" feature
     #python
 
 
 
 
    Ciar Main Page >> TTK's Home Page