jnoller

69 ms·

721.
by jnoller 17y ago
The GIL is an implementation detail; not a bug.
722.
by jnoller 17y ago
As soon as the SDK agreement doesn't ban interpreters, I could see such a thing coming, but not from -core
723.
by jnoller 17y ago
Then you're not paying attention. No one (except a broken minority) said that they would not want to get rid of the GIL so long as single threaded performance was note degraded. Guido himself has stated this time and time again. The one t
724.
PyCon 2010: Invited Speakers announced(us.pycon.org)
1 points by jnoller 17y ago|0 comments
725.
by jnoller 17y ago
Public disclosure without giving a vendor or project a chance to fix the issue before you release the information publicly screws everyone running it who may or may not have the skills needed to fix the issue. In this case, it was a mista
726.
by jnoller 17y ago
How about this one: 2.x is dead. While bug fixes and minor changes are occuring, it's going to slip into maintenance mode once 2.7 comes out. All the cool things, such as importlib and other items are py3k only.
727.
by jnoller 17y ago
I love you
728.
by jnoller 17y ago
FWIW: argparse is not google's
729.
by jnoller 17y ago
There will still be batteries included. Brett (the article) was talking about how to clean it up, my point in this thread ( http://mail.python.org/pipermail/stdlib-sig/2009-September/0... ) is a break-up which still offers the batteries (as
730.
by jnoller 17y ago
Yup, that's the point.
731.
by jnoller 17y ago
Here's the thread: http://mail.python.org/pipermail/stdlib-sig/2009-September/0...
732.
by jnoller 17y ago
What's being proposed is trimming it of less useful libraries (and ones without maintainers, low test coverage, etc). No one wants it to "just go away".
733.
by jnoller 17y ago
Yes, yes, yes. I'll be sending out an email to the stdlib-sig later today proposing a logical "breaking out" of the stdlib from "the core". We can offer a "mega pack" download, but there's various (and all good) reasons to offer a split cor
734.
Python Thread Synchronization Primitives : Not Entirely What You Think(dabeaz.com)
20 points by jnoller 17y ago|0 comments
735.
by jnoller 17y ago
Running this (for me) has a lot, a lot of advantages over using apache. Not the least of which is it's microscopic compared to Apache. I'll be very interested in this; and might take the django bit for a spin this week. Thank you.
736.
by jnoller 17y ago
No, a CTO didn't waste money; he got exactly what he needed, cleaner, simpler. No - it doesn't handle every single edge case, nuance, platform - but it does exactly what they needed. They didn't need to spend time patching and grokking twis
737.
by jnoller 17y ago
I know that, except most web application servers spend most of their time in I/O - socket, database, etc. Threads are not hard: wanton abuse of shared state and concurrent modification of the shared state is hard to get right; tread a threa
738.
by jnoller 17y ago
No, it doesn't. I/O bound tasks can heavily use multiple cores just fine using threads.
739.
by jnoller 17y ago
Minor correction. The removal of the GIL is not disallowed by fiat. The removal of the GIL was attempted (via granular locking) and destroyed single threaded performance. That's unacceptable for a variety of reasons. In the same thread, Gui
740.
by jnoller 17y ago
This should be interesting. Imagine the cross over possibilities - Mickey Mouse Clubhouse + X-Men for example: "It's the Mickey Mouse X-Men lair, come inside there's Mutants inside!" and "I think we need a Mousektool! Everyone say "OH XAVIE
741.
by jnoller 17y ago
I'd really encourage people (obviously) to try this out. I'd personally like to use Python 3 in the next few years for my day job, and a tool like this obviously helps adoption.
742.
by jnoller 17y ago
This is why I want a translation party implementation :)
743.
by jnoller 17y ago
And I've got the same thing, but I write and test code on OS/X and "deploy" to the VM
744.
by jnoller 17y ago
I'm surprised having the hardcoded paths didn't bite you - of course, how frequently are you moving the interpreter, or installing multiple versions of the interpreter (with the same dependencies) with a shared bin dir?
745.
by jnoller 17y ago
Yeah, well, it's (mostly) a rant, though I like the kickstart thing I put together. I wouldn't have posted this to hacker news though, fwiw
746.
by jnoller 17y ago
Not exactly - for example, I depend on fabric, PIP, easy_install, nose, pylint and others. In this case, it's not a matter of fixing upstream on a per-project basis, it's fixing distutils as this is "magical" behavior I (and others) have se
747.
by jnoller 17y ago
Also, you have to run the sed command over the tree every time you install a new package which installs a binary
748.
by jnoller 17y ago
And I can/could, and will probably still end up doing that as much as I might not like it - and any time you install something else which includes a script in a binpath, you need to rerun the sed command.
749.
by jnoller 17y ago
easy_install, when installed with setuptools, hardcodes the shebang fwiw
750.
by jnoller 17y ago
I'm not proposing mangling anything here; in fact I dropped the mangled environment (as it was a hack, and added too much space) and swapped to a simpler (and cleaner) virtualenv built in /opt. I still haven't fixed the build something and

More ›