jnoller

55 ms·

571.
by jnoller 16y ago
Wrong. Wrong, and Wrong. Plenty of people - all over the world including myself - can use threads (and python threads) perfectly well understanding their limitations. It does benefit our applications just fine. That said, this GIL drum does
572.
A/B testing is no panacea(theonda.org)
3 points by jnoller 16y ago|0 comments
573.
by jnoller 16y ago
I disagree that anything you list is a niche feature. As for the standard lib - I'm interested to hear what you think has been added recently which are "crap". Given the amount of debate, discussion, and work that goes into every single lan
574.
by jnoller 16y ago
We didn't miss an opportunity; no one came up with a patch, or an acceptable fix.
575.
by jnoller 16y ago
Really? Which niche things have we added?
576.
by jnoller 16y ago
Bad architecture or poor design crosses languages. It's entirely possible and done every single day, to emit a broken system using even the most optimal code. That said; this looks, sounds and smells like database scaling issue more than an
577.
by jnoller 16y ago
The interesting thing is that AWS - and it's competitors - are getting easier to use, which only helps with the further commoditization of it. More and more people are going to want - no - expect - that their infrastructure will be easy t
578.
by jnoller 16y ago
And some of Guido's thoughts coming out of Europython: http://mail.python.org/pipermail/python-dev/2010-July/102306...
579.
Threads, processes and concurrency in Python: some thoughts(artima.com)
4 points by jnoller 16y ago|1 comments
580.
by jnoller 16y ago
boto, libcloud, etc, etc mostly support talking to multiple clouds. The API is far from the hardest part of migration - it's actually pretty simple in most cases, unless that vendor picks something like SOAP.
581.
Google Testing Blog: There, but for the grace of testing, go I(googletesting.blogspot.com)
20 points by jnoller 16y ago|4 comments
582.
Amazon S3’s Enhanced Cloud Storage Security is Nice But Not Good Enough(nasuni.com)
2 points by jnoller 16y ago|0 comments
583.
by jnoller 16y ago
You mean like: http://docs.python.org/library/multiprocessing.html#multipro...
584.
Numpy announces Python 3 support (Scipy news included)(mail-archive.com)
87 points by jnoller 16y ago|13 comments
585.
by jnoller 16y ago
Well, if it was I/O bound - the GIL shouldn't bother it too much ;) Don't mistake me for calm though, it drives me nuts :)
586.
by jnoller 16y ago
Alright, so it's not the optimal language for something with a large amount of mutable shared state being hacked at by threads. No one ever tried to bill it as the "one true language" - maybe it's better for glue in this case, or APIs or cl
587.
by jnoller 16y ago
Are you sure you couldn't write it?
588.
by jnoller 16y ago
What's the use case at work that's making it unworkable - just curious.
589.
by jnoller 16y ago
The trick to writing a good interpreter is not in the writing of it; it's in the part wherein you manage to completely avoid making any decisions you might regret in 10 years.
590.
by jnoller 16y ago
Oh, I agree with you! But I think we both know that while we all end up growing thick skins (or quitting) it can still get under your nails and make you sad sometimes. Especially when you've been at it awhile. Guido must have skin like a bl
591.
by jnoller 16y ago
As the maintainer of multiprocessing, I can say I've never really been bothered by the GIL. I know about it - I know that if I have CPU bound tasks, I'm going to better off using processes, ergo, multiprocessing. I spin up some processes, p
592.
by jnoller 16y ago
I never had this problem; we use python threads heavily at work - they're all I/O bound and they work just fine. We switch to multiprocessing when it's CPU bound. Works pretty well.
593.
by jnoller 16y ago
Except Gustavo is wrong in that he has to convince Brett that free threading is a Good Thing. Part of Brett's post was we already know that - but we're not willing to sacrifice backwards compatibility for it, and we do not have/have not t
594.
by jnoller 16y ago
Actually, the good news is that Python 3 already has an improved GIL - it's much better than the 2.x version modulo one or two issues, and Unladen-Swallow's jit work is already well, well under way in the Python SVN tree. I'm hoping the l
595.
by jnoller 16y ago
Thank you; that's one of the nicest ways I've heard it put.
596.
by jnoller 16y ago
And using 3to2 you can easily "downgrade" your code should you desire that. Green field projects should totally feel comfortable with using it.
597.
by jnoller 16y ago
Excuse me? We have an obsessive regard for backwards compatibility and stability through minor/micro releases. Big changes are reserved for Major (2.6->2.7/3.0) releases. Frankly, I've never worked with people more obsessed about not tr
598.
by jnoller 16y ago
Unladen swallow's JIT is coming to Python 3 a lot more quickly than 5 years.
599.
by jnoller 16y ago
It is a rant; but its to be expected to a certain degree. Python 3 is a big change, and while some may think it's "change for change's sake" (honestly, it really isn't) I expect we're going to hear more rants like this as the days go on. We
600.
by jnoller 16y ago
No, we - we being Python Core - want a calm, orderly transition to Python 3 over a period of several years . Python 2 will be around for some time, and we all know and accept that. Yes, if you have dependencies, using python 3 in productio

More ›