A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2009-November/093640.html below:

[Python-Dev] 2.7 Release? 2.7 == last of the 2.x line?

[Python-Dev] 2.7 Release? 2.7 == last of the 2.x line? [Python-Dev] 2.7 Release? 2.7 == last of the 2.x line?Eric Smith eric at trueblade.com
Tue Nov 3 19:13:18 CET 2009
Martin v. Löwis wrote:
>> A Python 3 version of NumPy might be enough of an improvement to bring
>> *more* scientists and engineers onboard if the Python 3.x version shows
>> what great productivity gains are to be had with Python 3.x over 2.x.
> 
> I would be really surprised if 2.7 would simplify porting to 3.x. How
> could that possibly work?

The only things I can think of that would go into this category are 
features like:
- PEP 3118, revised buffer protocol. If the buffer API that numpy
   uses is not present in py3k (I'm no expert on the subject, but
   it seems this way from a recent thread on python-dev), then if
   they could move to PEP 3118 in 2.7 their migration to 3.x would
   be easier
- short float repr. This would remove a class of hard-to-find
   problems from a migration from 2.7 to 3.x.
- Maybe io, but I don't know enough about it to say.

But I definitely agree that backporting language features new to 3.x 
don't make it easier. Examples are nonlocal and required keyword args.

Eric.
More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4