> 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
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
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
>
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
> 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
"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
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
On Sat, Nov 21, 2009 at 11:05 AM, "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 int
> 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 it's better than it sounds. The m
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 discussion of this at http://bugs.
The wiki page for porting to 3.x says:
http://wiki.python.org/moin/PortingExtensionModulesToPy3k
"""
long/int Unification
In Python 3.0, there is only one integer type. It is called int on the Python
level, but actually
corresponds to 2.x's long type. In the C-API, PyInt_* functions are replaced
11 matches
Mail list logo
