Hello,
I built something very similar for my company last year, and it’s been running
flawlessly in production at a few customer sites since, with avg. CPU usage ~50%
around the clock. I even posted about it on the Python mailing list [1] where
there was almost no resonance at that time. I never p
Stefan Ring wrote:
> [2] http://www.bestinclass.dk/index.php/2009/10/python-vs-clojure-evolving/
> [3] www.dabeaz.com/python/GIL.pdf
>
> PS On a slightly different note, I came across some Python bashing [2]
> yesterday
> and somehow from there to David Beazley’s presentation about the GIL [3].
Eric Smith wrote:
> M.-A. Lemburg wrote:
>> Since package developers are just starting to port things to 3.x and
>> many appear to be considering supporting both 2.7 and 3.1 (including
>> myself), I find it a bit strange that such an import aliasing header
>> was removed in 3.1.
>
> There's some d
"Martin v. Löwis" wrote:
>> IMHO, that's not really a good way to encourage people to try to provide
>> a smooth upgrade to the 3.x branch. Much to the contrary. 3.x should make
>> it easier for developers by providing more standard helpers like
>> the removed intobject.h header file.
>
> I think
> I built something very similar for my company last year, and it’s been running
> flawlessly in production at a few customer sites since, with avg. CPU usage
> ~50%
> around the clock. I even posted about it on the Python mailing list [1] where
> there was almost no resonance at that time. I neve
> In an ideal world, developers would add that code to their
> extensions right away. In the real world, where developers only
> have limited resources available, you'll get more 3.x ports
> by making such ports as painless as possible while at the
> same time not forcing them to alienate their 2.x
On Mon, Nov 23, 2009 at 10:44 AM, M.-A. Lemburg wrote:
> Thanks for pointing me to the that ticket.
>
> Looks like Guido already commented on this, so intobject.h could
> be revived in some form.
I'm wondering how a resurrected intobject.h should be used: would
Linux distributors (for example) p
Mark Dickinson wrote:
> On Mon, Nov 23, 2009 at 10:44 AM, M.-A. Lemburg wrote:
>> Thanks for pointing me to the that ticket.
>>
>> Looks like Guido already commented on this, so intobject.h could
>> be revived in some form.
>
> I'm wondering how a resurrected intobject.h should be used: would
>
M.-A. Lemburg egenix.com> writes:
>
> We could then also have a py2compat.c to hold corresponding
> C code, e.g. to provide compatibility wrappers of new APIs that
> implement different semantics in 3.x.
If the semantic differences are embodied in the builtin object types I wonder
how you can ma
> I'm not sure concealing the differences between 2.x and 3.x behind such a
> wrapper is a good idea. It would be better if people became aware of / learnt
> about the new semantics.
+1. When porting a larger code base, I always came up with a custom set
of macros, specific to the way the modules
10 matches
Mail list logo
