date:20091103

Antoine Pitrou wrote:
> Guido van Rossum  python.org> writes:
>>
>> Is it even wort doing a 2.7 release? Isn't the effort better spent on
>> 3.2 alone? (Note, these aren't rhetorical questions. It's well
>> possible that there are good reasons for pushing along with 2.7. Maybe
>> considering those reasons will also help answering questions about
>> whether to backport things like nonlocal.)
> 
> 2.7 has an up-to-date backport of the C IO lib (as well as the memoryview
> object), which means it is better for people wanting to ease transition to 
> 3.x.
> 
> But of course, as Martin said, few people will want to support 2.7 only and 
> not 
> 2.6.

Since 2.7 will be closer to 3.2 than 2.6, the result will more likely
be: many people will want to support 2.7 and 3.x - which is really
what we should be after.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Nov 03 2009)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/

::: Try our new mxODBC.Connect Python Database Interface for free ! 

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   http://www.egenix.com/company/contact/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2009-11-03 Thread Michael Foord


Sturla Molden wrote:
I'd just like to mention that the scientific community is highly 
dependent on NumPy. As long as NumPy is not ported to Py3k, migration 
is out of the question. Porting NumPy is not a trivial issue. It might 
take a complete rewrite of the whole C base using Cython. NumPy's ABI 
is not even PEP 3118 compliant. Changing the ABI for Py3k might break 
extension code written for NumPy using C. And scientists tend to write 
CPU-bound routines in languages like C and Fortran, not Python, so 
that is a major issue as well. If we port NumPy to Py3k, everyone 
using NumPy will have to port their C code to the new ABI. There are 
lot of people stuck with Python 2.x for this reason. It does not just 
affect individual scientists, but also large projects like IBM and 
CERN's blue brain and NASA's space telecope. So please, do not cancel 
2.x support before we have ported NumPy, Matplotlib and most of their 
dependant extensions to Py3k.


What will it take to *start* the port? (Or is it already underway?) For 
many projects I fear that it is only the impending obsolescence (real 
rather than theoretical) of Python 2 that will convince projects to port.


Python 2.X is not about to 'stop working', but there will come a point 
where it will 'stop being worked on'.


All the best,

Michael
The community of scientists and engineers using Python is growing, but 
shutting down 2.x support might bring an end to that.


Sturla Molden


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk 




--
http://www.ironpythoninaction.com/

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] language summit topic: issue tracker

2009-11-03 Thread Nick Coghlan

Martin v. Löwis wrote:
>> +lots on adding a module field (independent of automatically adding
>> maintainers to the nosy list, it would assist in "I just did a major
>> cleanup of module X, are there any old bugs I can kill off").
> 
> Link (1:1) or Multilink (1:n)? What is the impact on the Component field?

I was thinking multilink, and leaving component alone - the module field
would largely come into play when the component was just the "Lib"
catch-all.

> Would you be willing to manage the field (in the sense of managing the
> set of values)? If so, please send me a list of values.

I would suggest just using the module index from the documentation to
seed any such list of modules in the tracker:
http://docs.python.org/modindex.html

Packages could generally be left as a single entry in the list. The only
exception I think is that there should be an "xml.etree" entry separate
from the main "xml" entry, and perhaps a separate entry for "os.path".

Deprecated modules could either be left out of the list, or else moved
to appear at the end.

Regards,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
---
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

On Tue, Nov 3, 2009 at 6:13 PM, Michael Foord  wrote:
> Sturla Molden wrote:
>>
>> I'd just like to mention that the scientific community is highly dependent
>> on NumPy. As long as NumPy is not ported to Py3k, migration is out of the
>> question. Porting NumPy is not a trivial issue. It might take a complete
>> rewrite of the whole C base using Cython. NumPy's ABI is not even PEP 3118
>> compliant. Changing the ABI for Py3k might break extension code written for
>> NumPy using C. And scientists tend to write CPU-bound routines in languages
>> like C and Fortran, not Python, so that is a major issue as well. If we port
>> NumPy to Py3k, everyone using NumPy will have to port their C code to the
>> new ABI. There are lot of people stuck with Python 2.x for this reason. It
>> does not just affect individual scientists, but also large projects like IBM
>> and CERN's blue brain and NASA's space telecope. So please, do not cancel
>> 2.x support before we have ported NumPy, Matplotlib and most of their
>> dependant extensions to Py3k.
>
> What will it take to *start* the port? (Or is it already underway?) For many
> projects I fear that it is only the impending obsolescence (real rather than
> theoretical) of Python 2 that will convince projects to port.

I feel the same way. Given how much resources it will take to port to
py3k, I doubt the port will happen soon. I don't know what other numpy
developers think, but I consider py3k to simply not worth the hassle -
I know we will have to port eventually, though.

To answer your question, the main issues are:
 - are two branches are necessary or not ? If two branches are
necessary, I think we simply do not have the resources at the moment.
 - how to maintain a compatible C API across 2.x and 3.x
 - is it practically possible to support and maintain numpy from 2.4
to 3.x ? For example, I don't think the python 2.6 py3k warnings are
very useful when you need to maintain compatibility with 2.4 and 2.5.

There is also little documentation on how to port a significant C
codebase to py3k.

David
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2009-11-03 Thread Raymond Hettinger

[Michael Foord]
What will it take to *start* the port? (Or is it already underway?) For many projects I fear that it is only the impending
obsolescence (real rather than theoretical) of Python 2 that will convince projects to port.

FWIW, I do not buy into the several premises that have arisen in this thread:

* For 3.x to succeed, something bad has to happen to 2.x. (which in my book translates to intentionally harming 2.x users, either
through neglect or force, in order to bait them into switching to 3.x).

* Core developers will are losing time supporting 2.x. (backports take some
time but it
is small in comparison to getting a patch to work in the first place -- if anyone can comment on this assertion, it is the people
who have been doing it already (such as AP, MD, BP, GB, and myself)).

* That 3.x has proven its readiness to supplant 2.x. (It hasn't been exercised that heavily and there are a lot of things that may
or may not prove to be successful in the end -- bytes/text issues, tuple comparison challenges, new io, mapping views with set
operations, etc).

In all these matters, I think the users should get a vote. And that vote should be cast with their decision to stay with 2.x, or
switch to 3.x, or try to support both. We should not muck with their rational decision making by putting "carrots" in one pile and
abandoning the other.

Raymond

P.S. I found it curious that one of the strongest proponents of killing 2.x also mentioned that he has never written a line of 3.x
code. Since this discussion is a matter of great consequence, I would hope that advocates will only take informed positions --
this isn't really time for shooting from the hip and killing 2.x.

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2009-11-03 Thread Paul Moore

2009/11/3 Raymond Hettinger :
> In all these matters, I think the users should get a vote.  And that vote
> should be cast with their decision to stay with 2.x, or switch to 3.x, or
> try to support both.  We should not muck with their rational decision making
> by putting "carrots" in one pile and abandoning the other.

Agreed (up to a point).

The biggest issue to my mind is that adoption by the ultimate end
users is significantly hampered by the fact that big projects like
Twisted, numpy and the like, have no current plans to move to Python
3. Even end users with a reasonable level of coding expertise don't
have the time or resources to offer much in the way of help with a
port, when the project as a whole isn't interested in starting the
process.

At the moment, it seems to me that this is the biggest blocker to
Python 3 adoption. And it's a chicken and egg situation - I don't use
Python 3, so I don't test the new features, so the projects I need see
little take-up, so I can't use them in Python 3, so I don't use Python
3...

And while I know I can run Python 2.x and Python 3.x side by side, at
the end of the day, I want to just be able to type "python" to get my
interpreter.

I don't know how to solve this (assuming that "just wait" isn't going
to do it). Maybe the core devs will have to offer resource to some of
the key projects to get things moving (but as this is a volunteer
effort, that isn't something that "just happens" either...)

Paul.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

Sturla Molden  molden.no> writes:
> 
> Porting NumPy is not a trivial issue. It might take 
> a complete rewrite of the whole C base using Cython.

I don't see why they would need a rewrite. Little of the C API has changed
between 2.x and 3.x. Cython itself is supposed to support both 2.x and 3.x,
isn't it?

> NumPy's ABI is not even PEP 3118 compliant.

That's interesting, because PEP 3118 was pushed mainly by a prominent member of
the NumPy community and some of its features are almost dedicated to NumPy.

Regards

Antoine.

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

David Cournapeau  gmail.com> writes:
> 
> To answer your question, the main issues are:
>  - are two branches are necessary or not ? If two branches are
> necessary, I think we simply do not have the resources at the moment.
>  - how to maintain a compatible C API across 2.x and 3.x
>  - is it practically possible to support and maintain numpy from 2.4
> to 3.x ? For example, I don't think the python 2.6 py3k warnings are
> very useful when you need to maintain compatibility with 2.4 and 2.5.

You should ask all those questions on the dedicated mailing-list:
http://mail.python.org/mailman/listinfo/python-porting

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2009-11-03 Thread R. David Murray


On Mon, 2 Nov 2009 at 22:06, Guido van Rossum wrote:

On Mon, Nov 2, 2009 at 9:51 PM, sstein...@gmail.com  wrote:

BeautifulSoup, which I use every day, is one such product. ?Since the crappy
old SMGL parser's gone, BeautifulSoup uses the one that's left in Python 3
and it makes BeautifulSoup completely useless for my daily work.


This sounds an area where some help might be useful. Perhaps the
quickest solution would simply be to copy the old crappy "sgml" based
html parser into a new version of BeautifulSoup. Though I imagine what
it really needs is a "quirks mode" parser that is compatible with the
HTML dialect accepted by, say, IE6. Maybe a summer of code project?


It's not a matter of quirks.  It's a matter of being able to parse
truly broken html/xml, which browsers unfortunately do too well
for everyone else's sanity.

So, call it a "sloppy mode" parser, and then yes, that would solve the
problem.

--David (RDM)___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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


On Nov 3, 2009, at 1:07 AM, Martin v. Löwis wrote:


Barry Warsaw wrote:

On Nov 2, 2009, at 10:48 PM, sstein...@gmail.com wrote:

A better language, i.e. Python 3.x, will become better faster  
without

dragging the 2.x series out any longer.


If Python 2.7 becomes the last of the 2.x series, then I personally
favor back porting as many features from Python 3 as possible.


And if *2.6* becomes the last of the 2.x series?


Then clearly we can't back port features.

I'd like to read some case studies of people who have migrated  
applications from 2.6 to 3.0.  Having just gone through a 2 week  
sprint to migrate Launchpad from 2.4 to 2.6, and only making it to  
2.5, I can say that I was unpleasantly surprised at the amount of work  
it took.  A lot of that was working out the dependency upgrades, with  
some amount of fixing our code (mostly tests) for things that have  
changed (e.g. exception print/str format).  We didn't make it to  
Python 2.6 because dealing with deprecation warnings for sha, md5, and  
sets (a little in our code but tons in our dependencies) consumed most  
of our remaining time.


Given another week or so I think we would have made it to Python 2.6,  
but I'm not at all confident that that would have been a good enough  
platform to attempt an upgrade to Python 3, even if all of our very  
numerous large dependencies were available for Python 3.  Maybe it  
wouldn't be so bad, but my recent experience informs me that I'm  
probably being too optimistic rather than too pessimistic.


-Barry



PGP.sig
Description: This is a digitally signed message part
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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


On Nov 2, 2009, at 11:51 PM, sstein...@gmail.com wrote:


I agree as long as:
	A> 2.7 comes out as soon as possible, even if it's missing helpful  
porting features.
	B> 2.7 will get ONLY new features that make it easier to port to  
3.x, not every feature added to 3.x or all you've done is make  
"Python 2.7, the Python 3 Version." and core developer time will  
continue to be wasted on Python 2.7 instead of moving forward.


I'm not sure I agree with that core developer time will be "wasted on  
Python 2.7 instead of moving forward".  However, I completely  
understand core developers seeing Python 2.x as a dead end and not  
wanting to work on it.  If that's a real issue, we should acknowledge  
that as a factor in the decision.  This is a volunteer organization  
and if the majority of developers are sick and tired of Python 2, then  
it absolutely makes no sense to slog through a Python 2.7 release.   
I'd much rather take all the enthusiastic energy that decision will  
reclaim and focus it on, oh, Python 3's email package instead .


I also think Guido's call for feature freeze makes a lot more sense  
when 2.7 is the EOL.  Let's give people migrating to Python 3 a  
nice big stable target to hit.  Improving the stdlib also gives  
people a big carrot to move.


Agreed. And specifically NOT porting every shiny new toy from Python  
3 back to 2.7 makes sure the carrots are only in the 3.x series.


Python 3's got enough carrots and sticks already.  One huge carrot  
that will never make it back into Python 2 is bytes/strings of  
course.  The huge stick is that Python 2 is end-of-lifed, if not now,  
eventually.  It isn't going to get a reprieve.  Everyone knows that  
everyone will have to get to Python 3.  The question is, what can we  
as a community  do to make that inevitability as easy to swallow as  
possible?


I think it's also necessary to give third party library and  
application authors as much help as possible to provide Python 3  
compatible software.  Putting together Python tools involves so  
many dependencies in a fairly deep stack that even one unconverted  
library can cause everything above it to stall on Python 2.


And that's one of the reasons my explorations into Python 3 have  
been limited to pretty much nothing.


I don't have time to do a bunch of work only to find out that the  
tool I absolutely have to have to finish a project doesn't have a  
Python 3 version or has been crippled to make a Python 3 version.


Unfortunately, I think we have to do those explorations, fail, hit  
roadblocks, complain, etc. but most importantly identify the packages  
that need to be ported.  Then work with those package authors to make  
the upgrades happen.  And improve Python and Pythonic tools so that  
migrations can go smoothly.


Speaking as a package author, I know how much work it is just to get a  
bug fix release out.  The three lines of code fix means 50 lines of  
test writing, a half a day of documenting, packaging, uploading, and  
announcing.  Porting even one of my packages to Python 3 is a  
significant undertaking which frankly I don't have the cycles for.   
Anything large and complicated is hopeless.  Witness how long and  
difficult it's been just to get a standard library module updated  
(email) and you get a sense of how much work it will be to get an  
entire stack of code onto Python 3.


BeautifulSoup, which I use every day, is one such product.  Since  
the crappy old SMGL parser's gone, BeautifulSoup uses the one that's  
left in Python 3 and it makes BeautifulSoup completely useless for  
my daily work.


That's not to say I can't fix that one particular project, but  
customers get cranky when their project is taking longer than  
expected and "Oh, I'm having to convert a lot of things to use  
Python 3" doesn't seem to improve their mood much.


I completely agree.  What happens when your application depends on a  
half dozen Zope packages, Twisted, and 15 or 20 other established,  
mature packages?  It's a daunting prospect.


-Barry



PGP.sig
Description: This is a digitally signed message part
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

Raymond Hettinger wrote:
> In all these matters, I think the users should get a vote.  And that
> vote should be cast with their decision to stay with 2.x, or switch to
> 3.x, or try to support both.  We should not muck with their rational
> decision making by putting "carrots" in one pile and abandoning the other.

I don't think users will really go for carrots. Python 2.x is mature
enough already and at least the users I know are really happy with it
(including myself).

IMHO, the main benefit of backporting features from 3.x to 2.x is
to make the transition from 2.x to 3.x a gradual one based on evolution
rather than revolution.

The other aspect is maintenance. Users do care about bug fixes and
security patches. They also care about fixes needed to make Python
work on new platforms (such as Windows 7) - mainly to keep their
existing code running on these new platforms.

The question is: Who is going to continue working on such 2.x
releases, review patches, etc. ?

If there are no core developers willing to do this, it's likely
not going to happen.

OTOH, I'm sure that companies who have invested in Python 2.x
applications will gladly pay a yearly fee to the PSF to have
this done for them.

It's simply a whole lot cheaper than to port a few 100K lines of
Python/C code, not to mention having to wait for all the used
3rd party libs to get ported as well.

The PSF could then pay a core developer to take care of the
extra Python 2.x releases.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Nov 03 2009)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/

::: Try our new mxODBC.Connect Python Database Interface for free ! 

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   http://www.egenix.com/company/contact/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

On Tue, Nov 3, 2009 at 8:40 PM, Antoine Pitrou  wrote:
> Sturla Molden  molden.no> writes:
>>
>> Porting NumPy is not a trivial issue. It might take
>> a complete rewrite of the whole C base using Cython.
>
> I don't see why they would need a rewrite.

(let me know if those numpy-specific discussions are considered OT0

There is certainly no need for a full rewrite, no. I am still unclear
on the range of things to change for 3.x, but the C changes are not
small, especially since numpy uses "dark" areas of python C extension.
The long vs int, strings vs bytes will take some time.

AFAIK, the only thing which has been attempted so far is porting our
own distutils extension to python 3.x, but I have not integrated those
changes yet.

> between 2.x and 3.x. Cython itself is supposed to support both 2.x and 3.x,
> isn't it?

Yes - but no numpy code use cython ATM, except for the random
generators, which would almost certainly be trivial to convert.

The idea which has been discussed so far is that for *some* code which
need significant changes or rewrite, using cython instead of C may be
beneficial, as it would give the 3.x code "for free". Having more
cython and less C could also bring more contributors - that would
actually be the biggest incentive, as the number of people who know
the core C code of numpy is too small.

> That's interesting, because PEP 3118 was pushed mainly by a prominent member 
> of
> the NumPy community and some of its features are almost dedicated to NumPy.

I have not been involved with PEP 3118 discussion, so cannot comment
on the reason why it is not fully supported yet by numpy.

But I think that's a different issue altogether - PEP 3118 goal is for
interoperation with other packages. We can port to PEP 3118 without
porting to 3.x, and we can port to 3.x without taking care of PEP
3118.

David
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

On Tue, Nov 3, 2009 at 9:55 PM, Barry Warsaw  wrote:

>
> Then clearly we can't back port features.
>
> I'd like to read some case studies of people who have migrated applications
> from 2.6 to 3.0.

+1, especially for packages which have a lot of C code: the current
documentation is sparse :) The only helpful reference I have found so
far is an email by MvL concerning psycopg2 port.

David
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

On Nov 3, 2009, at 12:06 AM, Guido van Rossum wrote:

On Mon, Nov 2, 2009 at 9:51 PM, sstein...@gmail.com > wrote:
BeautifulSoup, which I use every day, is one such product. Since
the crappy
old SMGL parser's gone, BeautifulSoup uses the one that's left in
Python 3

and it makes BeautifulSoup completely useless for my daily work.

This sounds an area where some help might be useful. Perhaps the
quickest solution would simply be to copy the old crappy "sgml" based
html parser into a new version of BeautifulSoup.

That is what we're discussing doing on the old-soup branch at http://github.com/adevore/old-beautiful-soup
. I'm not exactly sure why the old SGML parser was dropped but it
seems that porting it to Python 3 would be enough of an effort that it
caused the Python library to drop it, and the current developer of the
mainline of Beautiful Soup to decide to just use what was available in
Python 3 natively.

Though I imagine what it really needs is a "quirks mode" parser that
is compatible with the

HTML dialect accepted by, say, IE6. Maybe a summer of code project?

I think it just relies on the old SGML parser's not blowing up on
completely bogus HTML (like most of the web) and does the best it can
with the 'chunks' that come back; nothing to do with quirks mode per se.

As for a Summer of Code project, I have no idea what would be
involved. I know there are lots of users for Beautiful soup; as far
as I know it is the best scraper of HTML code, valid or not, that's
out there and it's been around a long time and I see it in projects in
the "html scraping" realm all the time.

At any rate, it's just one example of where the developer has taken
the easy route out with a 3.0 port and has produced a product that's
"Python 3" but, instead of getting better with Python's new features,
has actually become useless for the majority of use-cases where
formerly it shined.

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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



On Nov 3, 2009, at 1:07 AM, Martin v. Löwis wrote:


Barry Warsaw wrote:

On Nov 2, 2009, at 10:48 PM, sstein...@gmail.com wrote:

A better language, i.e. Python 3.x, will become better faster  
without

dragging the 2.x series out any longer.


If Python 2.7 becomes the last of the 2.x series, then I personally
favor back porting as many features from Python 3 as possible.


And if *2.6* becomes the last of the 2.x series?


Then I'd guess that that would annoy the crap out of everyone who's  
put so much effort into 2.7 and all of us who have been waiting for  
what I hope will finally be the "now ports way more easily to 3.0"  
version.


S

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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



On Nov 3, 2009, at 4:55 AM, David Cournapeau wrote:

On Tue, Nov 3, 2009 at 6:13 PM, Michael Foord > wrote:


There is also little documentation on how to port a significant C
codebase to py3k.


Now there's a good Summer of Code project:  to produce a pre-processor  
that will flag all C constructs that need to be modified in some way,  
with direct pointers to the relevant documentation, and "code  
suggestions" wherever practicable.


S

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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



On Nov 3, 2009, at 4:58 AM, Raymond Hettinger wrote:


P.S.  I found it curious that one of the strongest proponents of  
killing 2.x also mentioned that he has never written a line of 3.x  
code.   Since this discussion is a matter of great consequence, I  
would hope that advocates will only take informed positions --  this  
isn't really time for shooting from the hip and killing 2.x.


Uh, that would be me.

I'm only a proponent of making a decision.

I *want* to have a better development language, library, and add-on  
tools.


If 3.x is where future core development time is going to be focused,  
then I have faith that they will be able to make it the compelling  
path that it will become with Guido having put as much effort into it  
as he has.  Or, maybe he's completely lost his mind as sometimes  
happens with "dictators for life" benevolent or other-wise. ;-)


In any case, splitting time between 2.x and 3.x, with limited  
developer resources is going to lead to slower progress on both fronts.


And, as you point out, if 3.x doesn't start getting the crap beat out  
of it in the real world sooner rather than later, we may find  
ourselves, collectively with a stale 2.x, an under battle-tested 3.x,  
and nowhere to go.


S

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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



On Nov 3, 2009, at 2:20 AM, Sturla Molden wrote:

I'd just like to mention that the scientific community is highly  
dependent on NumPy. As long as NumPy is not ported to Py3k,  
migration is out of the question. Porting NumPy is not a trivial  
issue. It might take a complete rewrite of the whole C base using  
Cython. NumPy's ABI is not even PEP 3118 compliant. Changing the ABI  
for Py3k might break extension code written for NumPy using C. And  
scientists tend to write CPU-bound routines in languages like C and  
Fortran, not Python, so that is a major issue as well. If we port  
NumPy to Py3k, everyone using NumPy will have to port their C code  
to the new ABI. There are lot of people stuck with Python 2.x for  
this reason.


It does not just affect individual scientists, but also large  
projects like IBM and CERN's blue brain and NASA's space telecope.


Then, perhaps, if 2.7 is known to be the last release of the 2.x line,  
some of those deep pockets can cough up some $$$ or developers to  
actually _do_ the port.


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.


S

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

David Cournapeau  gmail.com> writes:
> 
> We can port to PEP 3118 without
> porting to 3.x, and we can port to 3.x without taking care of PEP
> 3118.

I'm not sure you can do the latter. The old buffer API (the one PEP 3118
replaces) doesn't exist in py3k.


Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2009-11-03 Thread Daniel Stutzbach

On Tue, Nov 3, 2009 at 3:55 AM, David Cournapeau  wrote:

>  - are two branches are necessary or not ? If two branches are
> necessary, I think we simply do not have the resources at the moment.
>  - how to maintain a compatible C API across 2.x and 3.x
>  - is it practically possible to support and maintain numpy from 2.4
> to 3.x ? For example, I don't think the python 2.6 py3k warnings are
> very useful when you need to maintain compatibility with 2.4 and 2.5.
>

I've already ported some of my Python extension modules to Python 3.  Here's
how I would answer your questions based on my experience.

Writing C code that compiles with Python 2.4 through 3.1 is pretty easy.
Python's C API hasn't changed much and you can use #ifdef and #define for
any bits that must be version-specific.

It's pretty easy to make Python source that works under 2.6 and 3.x.  It's
basically impossible to make Python source that works under 2.4/2.5 and
3.x.  You may be able to write code that works under 2.4/2.5 and works
cleanly with 2to3 to produce 3.x code.  I haven't tried that route, though
in theory it should work.  All you really need is syntax compatibility.  For
the rest, you can check sys.version_info.

In a nutshell, I don't think you need two branches to support an extension
module on Python 2 and Python 3.

YMMV.

--
Daniel Stutzbach, Ph.D.
President, Stutzbach Enterprises, LLC 
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2009-11-03 Thread skip


Martin> And if *2.6* becomes the last of the 2.x series?

With all due respect, I don't think you can make that decision now.  The
time to have stated 2.6 would be the end of the 2.x line was when 2.6 was
released.  At that point instead of opening up the trunk for changes you
would have closed it off or merged the py3k branch to trunk.  2.6.0 was
released over a year ago and there has been no effort to suppress bug fix or
feature additions to trunk since then.  If you call 2.6 "the end of 2.x"
you'll have wasted a year of work on 2.7 with about a month to go before the
first 2.7 alpha release.

If you want to accelerate release of 2.7 (fewer alphas, compressed schedule,
etc) that's fine, but I don't think you can turn back the clock at this
point and decree that 2.7 is dead.

Skip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2009-11-03 Thread skip


mal> I don't think users will really go for carrots. Python 2.x is
mal> mature enough already and at least the users I know are really
mal> happy with it (including myself).

Taking that thought further back one step (or three), from

http://effbot.org/tkinterbook/listbox.htm

I pull this quote:

In versions before Python 1.5, use string.atoi instead of int.

:-)

Skip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

On Tue, Nov 3, 2009 at 4:55 AM, Barry Warsaw  wrote:
> I'd like to read some case studies of people who have migrated applications
> from 2.6 to 3.0.  Having just gone through a 2 week sprint to migrate
> Launchpad from 2.4 to 2.6, and only making it to 2.5, I can say that I was
> unpleasantly surprised at the amount of work it took.  A lot of that was
> working out the dependency upgrades, with some amount of fixing our code
> (mostly tests) for things that have changed (e.g. exception print/str
> format).  We didn't make it to Python 2.6 because dealing with deprecation
> warnings for sha, md5, and sets (a little in our code but tons in our
> dependencies) consumed most of our remaining time.

Ouch. sets. I'm guessing you are referring to code that was still
using the pre-2.4 sets.py module? Yes, that must have been painful.

> Given another week or so I think we would have made it to Python 2.6, but
> I'm not at all confident that that would have been a good enough platform to
> attempt an upgrade to Python 3, even if all of our very numerous large
> dependencies were available for Python 3.  Maybe it wouldn't be so bad, but
> my recent experience informs me that I'm probably being too optimistic
> rather than too pessimistic.

There are two stages of porting to 2.6 you have to go through. The
first one, which you would probably have reached in that week, is
running on 2.6 period. You can then release your code for the benefit
of others wanting to use it on 2.6.

But the second stage, which can take much more time (depending on the
state of your code base) is to run on 2.6 *free of warnings with the
-3 flag on*. You pretty much have to consider this a separate port,
and it is here where you do much of the prep work for 3.x (at least
for Python code -- for C extensions it's not so clear). The good news
is that you can claim 2.6 support before you've even started this
stage; the other good news is that doing this right will really help
you prepare for 3.x. And in most cases you can even (with some effort)
maintain compatibility with 2.5 or even 2.4 -- though you may have to
work around some things like the md5 and sha warnings.

The bad news is that this stage may well take more time than porting
from 2.4 to 2.6.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2009-11-03 Thread Eric Smith


s...@pobox.com wrote:

mal> I don't think users will really go for carrots. Python 2.x is
mal> mature enough already and at least the users I know are really
mal> happy with it (including myself).

Taking that thought further back one step (or three), from

http://effbot.org/tkinterbook/listbox.htm

I pull this quote:

In versions before Python 1.5, use string.atoi instead of int.


Which reminds me: I've been meaning to add -3 warnings for these string 
module functions!


Eric.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2009-11-03 Thread James Y Knight


On Nov 3, 2009, at 8:55 AM, sstein...@gmail.com wrote:
And, as you point out, if 3.x doesn't start getting the crap beat  
out of it in the real world sooner rather than later, we may find  
ourselves, collectively with a stale 2.x, an under battle-tested  
3.x, and nowhere to go.


If that happens, it's not true that there's *nowhere* to go. A  
solution would be to discard 3.x as a failed experiment, take  
everything that is useful from it and port it to 2.x, and simply  
continue development from the last 2.x release. And from there,  
features can be deprecated and then removed a few releases later, as  
is the usual policy.


Been there, done that, on a couple other projects. It's unfortunate  
when you have to throw out work you've done because it failed to gain  
traction over the thing you tried to replace, but sometimes that's life.


James
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2009-11-03 Thread geremy condra

On Tue, Nov 3, 2009 at 8:47 AM, sstein...@gmail.com  wrote:
>
> On Nov 3, 2009, at 4:55 AM, David Cournapeau wrote:
>
>> On Tue, Nov 3, 2009 at 6:13 PM, Michael Foord 
>> wrote:
>>
>> There is also little documentation on how to port a significant C
>> codebase to py3k.
>
> Now there's a good Summer of Code project:  to produce a pre-processor that
> will flag all C constructs that need to be modified in some way, with direct
> pointers to the relevant documentation, and "code suggestions" wherever
> practicable.
>
> S

How much interest is there in this?

Geremy Condra
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

On Tue, Nov 3, 2009 at 9:04 AM, James Y Knight  wrote:
> If that happens, it's not true that there's *nowhere* to go. A solution
> would be to discard 3.x as a failed experiment, take everything that is
> useful from it and port it to 2.x, and simply continue development from the
> last 2.x release. And from there, features can be deprecated and then
> removed a few releases later, as is the usual policy.
>
> Been there, done that, on a couple other projects. It's unfortunate when you
> have to throw out work you've done because it failed to gain traction over
> the thing you tried to replace, but sometimes that's life.

I'm not ready for that yet. I think there's plenty of time before we
have to agree to such a bleak view. In the mean time let's do
something practical like help NumPy port to Py3k.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] PEP 3003 - Python Language Moratorium

I've checked draft (!) PEP 3003, "Python Language Moratorium", into
SVN. As authors I've listed Jesse, Brett and myself.

On python-ideas the moratorium idea got fairly positive responses
(more positive than I'd expected, in fact) but I'm bracing myself for
fierce discussion here on python-dev. It's important to me that if if
this is accepted it is a "rough consensus" decision (working code we
already have plenty of :-), not something enforced by a vocal minority
or an influential individual such as myself. If there's too much
opposition I'll withdraw the PEP so as not to waste everybody's time
with a fruitless discussion.

The PEP tries to spell out some gray areas but I'm sure there will be
others; that's life. Do note that the PEP proposes to be *retroactive*
back to the 3.1 release, i.e. the "frozen" version of the language is
the state in which it was released as 3.1.

-- 
--Guido van Rossum (python.org/~guido)
PEP: 3003
Title: Python Language Moratorium
Version: $Revision$
Last-Modified: $Date$
Author: Brett Cannon, Jesse Noller, Guido van Rossum
Status: Draft
Type: Process
Content-Type: text/x-rst
Created: 21-Oct-2009
Post-History:


Abstract


This PEP proposes a temporary moratorium (suspension) of all changes
to the Python language syntax, semantics, and built-ins for a period
of at least two years from the release of Python 3.1.

This suspension of features is designed to allow non-CPython implementations
to "catch up" to the core implementation of the language, help ease adoption
of Python 3.x, and provide a more stable base for the community.


Rationale
=

This idea was proposed by Guido van Rossum on the python-ideas [1]_ mailing
list. The premise of his email was to slow the alteration of the  Python core
syntax, builtins and semantics to allow non-CPython implementations to catch
up to the current state of Python, both 2.x and 3.x.

Python, as a language is more than the core implementation --
CPython -- with a rich, mature and vibrant community of implementations, such
as Jython [2]_, IronPython [3]_ and PyPy [4]_ that are a benefit not only to
the community, but to the language itself.

Still others, such as Unladen Swallow [5]_ (a branch of CPython) seek not to
create an alternative implementation, but rather they seek to enhance the
performance and implementation of CPython itself.

Python 3.x was a large part of the last several years of Python's
development. Its release, as well as a bevy of changes to the language
introduce by it and the previous 2.6.x releases, puts alternative
implementations at a severe disadvantage in "keeping pace" with core python
development.

Additionally, many of the changes put into the recent releases of the language
as implemented by CPython have not yet seen widespread usage amongst the
general user population. For example, most users are beholden to the version
of the interpreter (typically CPython) which comes pre-installed with their
operating system. Most OS vendors are just barely beginning to ship Python 2.6
-- even fewer are shipping Python 3.x.

As it is expected that Python 2.7 be the effective "end of life" of the Python
2.x code line, with Python 3.x being the future, it is in the best interest of
Python core development to temporarily suspend the alteration of the language
itself to allow all of these external entities to catch up and to assist in
the adoption of, and migration to, Python 3.x

Finally, the moratorium is intended to free up cycles within core development
to focus on other issues, such as the CPython interpreter and improvements
therein, the standard library, etc.

This moratorium does not allow for exceptions -- once accepted, any pending
changes to the syntax or semantics of the language will be postponed until the
moratorium is lifted.

This moratorium does not attempt to apply to any other Python implementation
meaning that if desired other implementations may add features which deviate
from the standard implementation.


Details
===

Cannot Change
-

* New built-ins
* Language syntax
The grammar file essentially becomes immutable apart from ambiguity
fixes.
* General language semantics
The language operates as-is with only specific exemptions (see
below).


Case-by-Case Exemptions
---

* New methods on built-ins
The case for adding a method to a built-in object can be made.
* Incorrect language semantics 
If the language semantics turn out to be ambiguous or improperly
implemented based on the intention of the original design then the
semantics may change.
* Language semantics that are difficult to implement
Because other VMs have not begun implementing Python 3.x semantics
there is a possibility that certain semantics are too difficult to
replicate. In those cases they can be changed to ease adoption of
Python 3.x by the other VMs.


Allowed to Change
-

* C API
It is entirely acceptable to change the u

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

Paul Moore  gmail.com> writes:
> 
> FWIW, I did a quick survey of some packages (a sampling of packages
> I've used or considered using in the past):
> 
> Twisted - no plans yet for Python 3

Well Twisted depends on zope.interface which is not ported yet.
Twisted apparently has plans to reduce or remove the warnings generated with the
"-3" option, we'll see if the patches get committed:
http://twistedmatrix.com/trac/ticket/2484
http://twistedmatrix.com/trac/ticket/4053
http://twistedmatrix.com/trac/ticket/4065

> TurboGears - Python 3 "currently unsupported", no timescale given

TurboGears is Pylons-based, so I suppose the actual question is when Pylons gets
ported.

Regards

Antoine.

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 3003 - Python Language Moratorium

Guido van Rossum  python.org> writes:
> 
> The PEP tries to spell out some gray areas but I'm sure there will be
> others; that's life. Do note that the PEP proposes to be *retroactive*
> back to the 3.1 release, i.e. the "frozen" version of the language is
> the state in which it was released as 3.1.

I've done a quick check through the NEWS file and it seems no post-3.1 change
would be affected by this PEP.

I'm for the PEP myself.

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

Arc Riley  gmail.com> writes:
> 
> +1 on ending with 2.6.I'm the maintainer of 3rd party Python 3-only packages
> and have ported a few modules that we needed with some help from the 2to3 
> tool.  It's really not a big deal - and Py3 really is a massive improvement.
> The main thing holding back the community are lazy and/or obstinate package 
> maintainers.  If they spent half the time they've put into complaining about 
> Py3 into actually working to upgrade their code they'd be done now.

One thing you could do is explain (do you have a blog?) how Py3 is a massive
improvement for you as a developer and package maintainer.
We core developers obviously agree that py3k is better than 2.x, but the same
opinion coming from a third-party developer would carry a different weight.

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2009-11-03 Thread Charles Cazabon

Arc Riley  wrote:
> +1 on ending with 2.6.

That seems precipitous.

> I'm the maintainer of 3rd party Python 3-only packages and have ported a few
> modules that we needed with some help from the 2to3 tool.  It's really not a
> big deal - and Py3 really is a massive improvement.
> 
> The main thing holding back the community are lazy and/or obstinate package
> maintainers.

I wouldn't say that.  For instance, I'm just starting a refactoring that will
result in getmail v.5, but I need to target Python 2.5 and up, so there's
essentially no way the code will run in Python 3.x (as another list member
posted).

Why do I need to target Python 2.5?  Because that's the most current default
version of Python shipped in Debian stable and various other distributions
that don't stay on the bleeding edge.  getmail v.4 targeted Python 2.3 and up,
getmail v.3 targeted Python 1.5.2 and up.  I may be able to target Python 2.6
in a year or two, at which point Python 3 compatibility becomes a reasonable
goal.

Saying "2.6 is the last Python 2.x" seems to me to be a death sentence for
Python 3.  People will stay with 2.x much longer than you seem to want them
to, and making it harder for them to upgrade will only hurt Python 3.

Charles
-- 
---
Charles Cazabon
GPL'ed software available at:   http://pyropus.ca/software/
---
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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



On Nov 3, 2009, at 12:38 PM, Guido van Rossum wrote:

On Tue, Nov 3, 2009 at 9:35 AM, sstein...@gmail.com > wrote:


On Nov 3, 2009, at 12:23 PM, Guido van Rossum wrote:

On Tue, Nov 3, 2009 at 9:04 AM, James Y Knight   
wrote:


If that happens, it's not true that there's *nowhere* to go. A  
solution
would be to discard 3.x as a failed experiment, take everything  
that is
useful from it and port it to 2.x, and simply continue  
development from

the
last 2.x release. And from there, features can be deprecated and  
then

removed a few releases later, as is the usual policy.

Been there, done that, on a couple other projects. It's  
unfortunate when

you
have to throw out work you've done because it failed to gain  
traction

over
the thing you tried to replace, but sometimes that's life.


I'm not ready for that yet. I think there's plenty of time before we
have to agree to such a bleak view. In the mean time let's do
something practical like help NumPy port to Py3k.


Or, for example, Django...


Wasn't Django ported to Py3k by MvL as a demo? The problem seems to be
more to port the Django *community* to Py3k...


I do remember seeing something about that somewhere but it sure isn't  
jumping into my workflow at the moment.


If I can get a Python 3 version of Django, that's keeping up with  
trunk, I hereby declare that I will start using it on my current  
project as soon as the client takes the blowtorch off my toes for the  
current deliverable.


And...I'll help keep it up to date with trunk as best I can and also  
help pull along all the modules I need (incidentally, including  
Beautiful Soup).


I really _want_ Python 3 to be better, I hope actual use convinces me  
that it is...


There, now I'm committed (or, maybe I should _be_ committed).

Thanks,

S

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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



On Nov 3, 2009, at 12:43 PM, Martin v. Löwis wrote:


I'm not ready for that yet. I think there's plenty of time before we
have to agree to such a bleak view. In the mean time let's do
something practical like help NumPy port to Py3k.


Or, for example, Django...


See

http://wiki.python.org/moin/PortingDjangoTo3k


Well, that's certainly a  start.

I guess the logical question is: Now what?

S

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

> 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?

(and no, adding things like nonlocal to 2.7 doesn't making porting of
a real application or library any easier, since the existing application
or library simply doesn't use that keyword. In fact, no change to 2.x
can reasonably simplify porting - only changes to 3.x might - except
for changes to 2to3, which can simplify porting a lot. But 2to3 should
be run under 3.x, IMO.)

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] nonlocal keyword in 2.x?

>> 2.7 has an up-to-date backport of the C IO lib (as well as the memoryview
>> object), which means it is better for people wanting to ease transition to 
>> 3.x.
>>
>> But of course, as Martin said, few people will want to support 2.7 only and 
>> not 
>> 2.6.
> 
> Since 2.7 will be closer to 3.2 than 2.6, the result will more likely
> be: many people will want to support 2.7 and 3.x - which is really
> what we should be after.

Supporting 2.7 doesn't mean that you have to use the nonlocal keyword
(nor does support for 3.2 require that keyword). So I'm not sure how
the backport of a feature to 2.x could encourage people to forward-port
to 3.x.

Regards,
Martin

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2009-11-03 Thread Zooko O'Whielacronx

Folks:

I really don't want to make anyone feel bad or to criticize, but I
should mention that I have no plans to use Python 3 or to support
Python 3.  My best guess at this time is that the current projects
that I'm involved in will still require Python 2 for the forseeable
future (let's say 5 years.  I can see 5 years into the future.), and
that as I start new projects I will probably try out interesting
alternative programming languages like Haskell, Newspeak [1],
Jacaranda [2], and other new things that appear in the coming years.

Of course, I reserve the right to change my mind and start using and
supporting Python 3.  That might happen if there is some combination
of: 1. my users start asking for it (no-one has yet), 2. my
dependencies start providing it (I use Python because it has Twisted.
Twisted requires Python 2.), 3. it becomes more possible for me to
write code which is still Python-2-compatible and also is more and
more close to being Python-3-compatible.

By the way, one significant detail which makes Python 3 less
interesting to me is [3].  Those two languages that I mentioned --
Newspeak and Jacaranda -- both have object-capability nature.  If that
issue in [3] were fixed then Python 3 would join Python 2 as a
language that can (with the CapPython extension) have
object-capability nature.

Regards,

Zooko

[1] http://bracha.org/Site/Newspeak.html
[2] http://jacaranda.org
[3] 
http://lackingrhoticity.blogspot.com/2008/09/cappython-unbound-methods-and-python-30.html
---
Your cloud storage provider does not need access to your data.
Tahoe-LAFS -- http://allmydata.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2009-11-03 Thread Farshid Lashkari

On Tue, Nov 3, 2009 at 9:37 AM, "Martin v. Löwis" wrote:
>
> (and no, adding things like nonlocal to 2.7 doesn't making porting of
> a real application or library any easier, since the existing application
> or library simply doesn't use that keyword. In fact, no change to 2.x
> can reasonably simplify porting - only changes to 3.x might - except
> for changes to 2to3, which can simplify porting a lot. But 2to3 should
> be run under 3.x, IMO.)
>

I agree that adding these features doesn't really help much for people that
are porting from 2.x to 3.x. However, I can see it being useful for package
developers who want to support both 3.x and 2.x. The more these two versions
have in common the easier it will be to support them both. Obviously, this
means the package might not work with 2.6 and earlier. But some users out
there might be in some situation where they cannot upgrade to 3.x but can
jump from 2.4/5/6 to 2.7.

-Farshid
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Retrieve an arbitrary element from a set withoutremoving it

2009-11-03 Thread Greg Ewing


Antoine Pitrou wrote:

Guido van Rossum  python.org> writes:


Picking a random element can be done in O(1) only if the data
structure supports access by index, which Python's hash tables don't.


Well, at the implementation level, they can. You'd just have to pick a new
random index until it points to a non-empty slot.


But that's hardly O(1).

--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

Martin v. Löwis schrieb:
>> It's pretty easy to make Python source that works under 2.6 and 3.x. 
>> It's basically impossible to make Python source that works under 2.4/2.5
>> and 3.x.  You may be able to write code that works under 2.4/2.5 and
>> works cleanly with 2to3 to produce 3.x code.  I haven't tried that
>> route, though in theory it should work.  All you really need is syntax
>> compatibility.
> 
> I have tried that route for a number of projects, and I think it works
> really well. It is also supported by distribute.

I've ported both Docutils and Pygments using that strategy, and I'll gladly
agree to that.

Georg

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

Georg Brandl  gmx.net> writes:
> 
> skip  pobox.com schrieb:
> > Martin> And if *2.6* becomes the last of the 2.x series?
> > 
> > With all due respect, I don't think you can make that decision now.  The
> > time to have stated 2.6 would be the end of the 2.x line was when 2.6 was
> > released.  At that point instead of opening up the trunk for changes you
> > would have closed it off or merged the py3k branch to trunk.  2.6.0 was
> > released over a year ago and there has been no effort to suppress bug fix or
> > feature additions to trunk since then.  If you call 2.6 "the end of 2.x"
> > you'll have wasted a year of work on 2.7 with about a month to go before the
> > first 2.7 alpha release.
> 
> +1.

+1 as well. Besides, it is much better communication to release 2.7 and say up
front that it will be the last major release in the 2.x line. Announcing that
there won't be a 2.7, however, would give the impression of poor planning.

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

>> I'd like to read some case studies of people who have migrated applications
>> from 2.6 to 3.0.
> 
> +1, especially for packages which have a lot of C code: the current
> documentation is sparse :) The only helpful reference I have found so
> far is an email by MvL concerning psycopg2 port.

You may also want to take a look at my ZODB port:

https://www.dcl.hpi.uni-potsdam.de/home/loewis/zodb/

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

>> I'm not ready for that yet. I think there's plenty of time before we
>> have to agree to such a bleak view. In the mean time let's do
>> something practical like help NumPy port to Py3k.
> 
> Or, for example, Django...

See

http://wiki.python.org/moin/PortingDjangoTo3k

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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



On Nov 3, 2009, at 12:23 PM, Guido van Rossum wrote:


On Tue, Nov 3, 2009 at 9:04 AM, James Y Knight  wrote:
If that happens, it's not true that there's *nowhere* to go. A  
solution
would be to discard 3.x as a failed experiment, take everything  
that is
useful from it and port it to 2.x, and simply continue development  
from the

last 2.x release. And from there, features can be deprecated and then
removed a few releases later, as is the usual policy.

Been there, done that, on a couple other projects. It's unfortunate  
when you
have to throw out work you've done because it failed to gain  
traction over

the thing you tried to replace, but sometimes that's life.


I'm not ready for that yet. I think there's plenty of time before we
have to agree to such a bleak view. In the mean time let's do
something practical like help NumPy port to Py3k.


Or, for example, Django...

S

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

> It's pretty easy to make Python source that works under 2.6 and 3.x. 
> It's basically impossible to make Python source that works under 2.4/2.5
> and 3.x.  You may be able to write code that works under 2.4/2.5 and
> works cleanly with 2to3 to produce 3.x code.  I haven't tried that
> route, though in theory it should work.  All you really need is syntax
> compatibility.

I have tried that route for a number of projects, and I think it works
really well. It is also supported by distribute.

> In a nutshell, I don't think you need two branches to support an
> extension module on Python 2 and Python 3.
> 
> YMMV.

Exactly my experience as well.

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

Raymond Hettinger schrieb:
> [Michael Foord]
>> What will it take to *start* the port? (Or is it already underway?) For
>> many projects I fear that it is only the impending obsolescence (real
>> rather than theoretical) of Python 2 that will convince projects to port.
> 
> FWIW, I do not buy into the several premises that have arisen in this thread:
> 
> 
> * For 3.x to succeed, something bad has to happen to 2.x.  (which in my book
> translates to intentionally harming 2.x users, either through neglect or
> force, in order to bait them into switching to 3.x).
> 
> * Core developers will are losing time supporting 2.x. (backports take some
> time but it is small in comparison to getting a patch to work in the first
> place -- if anyone can comment on this assertion,  it is the people who have
> been doing it already (such as AP, MD, BP, GB, and myself)).

I agree.  However I wouldn't want to lose the amount of work I've put into 2.7.

While reviewing the 2.6 "svnmerge avail" output, I also got the impression that
a *significant* number of fixes were not backported to 2.6.  I don't have the
time to go through a 300+ kb change log and find out what to backport, just
based on commit messages that are not always clear on whether a fix or feature
was added.

So if we kill 2.7, we at least need to make sure no real improvements that
should have been in 2.x are lost.

Georg

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2009-11-03 Thread Eric Smith


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.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

> To answer your question, the main issues are:
>  - are two branches are necessary or not ? If two branches are
> necessary, I think we simply do not have the resources at the moment.

No, it should be well possible to have the same source being used in
both 2.x and 3.x. I've ported ZODB to Python 3 (which includes both
C and Python code), and it works quite well.

>  - how to maintain a compatible C API across 2.x and 3.x

Not sure what the "C API" is: if it is the actual implementation of
the C modules, then I recommend to use preprocessor macros a lot.
If you need specific solutions, you'll have to ask specific questions.

>  - is it practically possible to support and maintain numpy from 2.4
> to 3.x ? 

Absolutely, yes.

> For example, I don't think the python 2.6 py3k warnings are
> very useful when you need to maintain compatibility with 2.4 and 2.5.

These I don't know. I found that I had little use for the 3k warnings
in porting to 3k; I usually rely on tests to find out whether the code
still works correctly.

> There is also little documentation on how to port a significant C
> codebase to py3k.

Please do ask specific questions.

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2009-11-03 Thread Paul Moore

2009/11/3 "Martin v. Löwis" :
>>> I'd like to read some case studies of people who have migrated applications
>>> from 2.6 to 3.0.
>>
>> +1, especially for packages which have a lot of C code: the current
>> documentation is sparse :) The only helpful reference I have found so
>> far is an email by MvL concerning psycopg2 port.
>
> You may also want to take a look at my ZODB port:
>
> https://www.dcl.hpi.uni-potsdam.de/home/loewis/zodb/

Has that port been integrated back into the zodb project? If not, it
would be interesting to know the reasons (zodb project maintainers not
interested, barriers to contribution are too high, port is not 100%
complete and no-one willing to take it over and complete it...?)

Paul.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Retrieve an arbitrary element from a set withoutremoving it

2009-11-03 Thread Greg Ewing


Steven D'Aprano wrote:


I don't know how expensive it is to create a set iterator,


Not expensive enough to justify burdening the set type with
extra functionality that will be extremely rarely used.

--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

On Tue, Nov 3, 2009 at 9:35 AM, sstein...@gmail.com  wrote:
>
> On Nov 3, 2009, at 12:23 PM, Guido van Rossum wrote:
>
>> On Tue, Nov 3, 2009 at 9:04 AM, James Y Knight  wrote:
>>>
>>> If that happens, it's not true that there's *nowhere* to go. A solution
>>> would be to discard 3.x as a failed experiment, take everything that is
>>> useful from it and port it to 2.x, and simply continue development from
>>> the
>>> last 2.x release. And from there, features can be deprecated and then
>>> removed a few releases later, as is the usual policy.
>>>
>>> Been there, done that, on a couple other projects. It's unfortunate when
>>> you
>>> have to throw out work you've done because it failed to gain traction
>>> over
>>> the thing you tried to replace, but sometimes that's life.
>>
>> I'm not ready for that yet. I think there's plenty of time before we
>> have to agree to such a bleak view. In the mean time let's do
>> something practical like help NumPy port to Py3k.
>
> Or, for example, Django...

Wasn't Django ported to Py3k by MvL as a demo? The problem seems to be
more to port the Django *community* to Py3k...

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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


On Nov 3, 2009, at 10:54 AM, Guido van Rossum wrote:


Ouch. sets. I'm guessing you are referring to code that was still
using the pre-2.4 sets.py module? Yes, that must have been painful.


Indeed. :)  What's nice though is that these changes could be made for  
the Python 2.5 branch and didn't have to wait until 2.6 (e.g. sha/md5 - 
> hashlib, sets -> builtin-set).


What was actually most painful about this were all the tests that were  
checking stdout/stderr for clean subprocess runs.  The  
DeprecationWarnings that were produced killed us for a long while  
because so many of those tests failed.


It's actually quite difficult to suppress DeprecationWarnings across  
the board, especially when you have lots of subprocess that call third  
party code (where most of the deprecated code lived in, and which we  
couldn't change).  We added filterwarnings where we could, and called  
subprocesses with -W every place we thought we needed to but we never  
did kill them all off.  I think a $PYTHONWARNING environment variable  
might have helped here.


Given another week or so I think we would have made it to Python  
2.6, but
I'm not at all confident that that would have been a good enough  
platform to
attempt an upgrade to Python 3, even if all of our very numerous  
large
dependencies were available for Python 3.  Maybe it wouldn't be so  
bad, but
my recent experience informs me that I'm probably being too  
optimistic

rather than too pessimistic.


There are two stages of porting to 2.6 you have to go through. The
first one, which you would probably have reached in that week, is
running on 2.6 period. You can then release your code for the benefit
of others wanting to use it on 2.6.


Yep.


But the second stage, which can take much more time (depending on the
state of your code base) is to run on 2.6 *free of warnings with the
-3 flag on*. You pretty much have to consider this a separate port,
and it is here where you do much of the prep work for 3.x (at least
for Python code -- for C extensions it's not so clear). The good news
is that you can claim 2.6 support before you've even started this
stage; the other good news is that doing this right will really help
you prepare for 3.x. And in most cases you can even (with some effort)
maintain compatibility with 2.5 or even 2.4 -- though you may have to
work around some things like the md5 and sha warnings.

The bad news is that this stage may well take more time than porting
from 2.4 to 2.6.


We have another window for this (since it's all open source I don't  
mind talking about it) when the next version of Ubuntu comes out.   
Running with the -3 is a great idea, and something I will definitely  
try after finishing the straight 2.6 port.


-Barry



PGP.sig
Description: This is a digitally signed message part
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

> Wasn't Django ported to Py3k by MvL as a demo? The problem seems to be
> more to port the Django *community* to Py3k...

Exactly so. At the last Pycon, we then agreed that I would get a branch
in the Django code repository, but then progress stalled due to
inactivity on boths sides.

Regards,
Martin

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2009-11-03 Thread Charles Cazabon

"Martin v. Löwis"  wrote:
> > I wouldn't say that.  For instance, I'm just starting a refactoring that 
> > will
> > result in getmail v.5, but I need to target Python 2.5 and up, so there's
> > essentially no way the code will run in Python 3.x (as another list member
> > posted).
> 
> That's a common myth. It is very well possible, using 2to3. You don't
> have to wait until you can drop 2.5 to start supporting 3.x, out of a
> single code base.

I haven't tried this, but I was relying on Daniel Stutzbach's opinion posted
here earlier:
http://mail.python.org/pipermail/python-dev/2009-November/093608.html

  It's pretty easy to make Python source that works under 2.6 and 3.x.  It's
  basically impossible to make Python source that works under 2.4/2.5 and
  3.x. 

> > Why do I need to target Python 2.5?  Because that's the most current
> > default version of Python shipped in Debian stable and various other
> > distributions that don't stay on the bleeding edge.
> 
> Are you saying that it doesn't *run* on 2.6?

No.  getmail v.4 runs fine on Python 2.3.4 through 2.6.x; getmail's code has
always been pretty forward-compatible.

> Why?  (not sure what you mean by "targetting")

By target, I mean backwards compatibility -- the minimum version of Python
which is required to run getmail.  getmail v.4 came out of beta about five
years ago targetting Python 2.3 and higher, and 2.3 was too bleeding-edge for
many users -- it wasn't shipped by many Linux distributions for a long time
after getmail v.4 was released.  Debian *still* shipps getmail v3 (which
supports back to Python 1.5.2) today, although they also ship v4.

getmail v.5 will be released in a month or three.  And many of its users will
still have Python 2.5, so that's what getmail has to run on.  Perhaps Daniel's
comment is incorrect (I have no evidence either way), but if it is true that
having a single getmail codebase run on Python 2.5 and Python 3.x is
"basically impossible", then I won't be too concerned about 3.x for a while
yet.

I've been an avid Python user and promoter since 1.2, but saying "drop Python
2.x and switch to 3 now" is simply not realistic in any of the environments in
which I use Python daily.  My $0.02.

Charles
-- 
---
Charles Cazabon
GPL'ed software available at:   http://pyropus.ca/software/
---
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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



On Nov 3, 2009, at 12:28 PM, Arc Riley wrote:


The main thing holding back the community are lazy and/or obstinate  
package maintainers.  If they spent half the time they've put into  
complaining about Py3 into actually working to upgrade their code  
they'd be done now.


That's an inflammatory, defamatory, unsubstantiated, hyperbolic,  
sweeping overgeneralization.


S

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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



On Nov 3, 2009, at 12:35 PM, Antoine Pitrou wrote:


Arc Riley  gmail.com> writes:


+1 on ending with 2.6.I'm the maintainer of 3rd party Python 3-only  
packages
and have ported a few modules that we needed with some help from  
the 2to3
tool.  It's really not a big deal - and Py3 really is a massive  
improvement.
The main thing holding back the community are lazy and/or obstinate  
package
maintainers.  If they spent half the time they've put into  
complaining about

Py3 into actually working to upgrade their code they'd be done now.


One thing you could do is explain (do you have a blog?) how Py3 is a  
massive

improvement for you as a developer and package maintainer.
We core developers obviously agree that py3k is better than 2.x, but  
the same
opinion coming from a third-party developer would carry a different  
weight.


Maybe I haven't been looking, but has anyone collected the "Here's why  
3.x is better and here's how it saved my bacon on project XYZ" stories?


S


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

>> 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

But only if NumPy would drop support for 2.x, for x < 7, right?
That would probably be many years in the future.

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 3003 - Python Language Moratorium

> * General language semantics
> The language operates as-is with only specific exemptions (see
> below).

Would PEP 382 (namespace packages) fall under the moratorium?

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 3003 - Python Language Moratorium

2009-11-03 Thread Michael Foord


Barry Warsaw wrote:

On Nov 3, 2009, at 12:35 PM, Guido van Rossum wrote:


I've checked draft (!) PEP 3003, "Python Language Moratorium", into
SVN. As authors I've listed Jesse, Brett and myself.

On python-ideas the moratorium idea got fairly positive responses
(more positive than I'd expected, in fact) but I'm bracing myself for
fierce discussion here on python-dev. It's important to me that if if
this is accepted it is a "rough consensus" decision (working code we
already have plenty of :-), not something enforced by a vocal minority
or an influential individual such as myself. If there's too much
opposition I'll withdraw the PEP so as not to waste everybody's time
with a fruitless discussion.

The PEP tries to spell out some gray areas but I'm sure there will be
others; that's life. Do note that the PEP proposes to be *retroactive*
back to the 3.1 release, i.e. the "frozen" version of the language is
the state in which it was released as 3.1.


I think this is a great idea.  I'd love to see the energy normally put 
into evolving the language into making the stdlib really kick ass.




+lots

Michael


-Barry



___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk
  



--
http://www.ironpythoninaction.com/

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

 I'm not ready for that yet. I think there's plenty of time before we
 have to agree to such a bleak view. In the mean time let's do
 something practical like help NumPy port to Py3k.
>>>
>>> Or, for example, Django...
>>
>> See
>>
>> http://wiki.python.org/moin/PortingDjangoTo3k
> 
> Well, that's certainly a  start.
> 
> I guess the logical question is: Now what?

Use it, and report bugs.

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2009-11-03 Thread Eric Smith


Martin v. Löwis wrote:

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


But only if NumPy would drop support for 2.x, for x < 7, right?
That would probably be many years in the future.


Right. But that might be their best migration strategy: wait for 2.7 to 
be available everywhere, port to 2.7, then port to 3.4 (or whatever the 
current version of 3.x would be, then).

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

sstein...@gmail.com schrieb:
> 
> On Nov 3, 2009, at 12:28 PM, Arc Riley wrote:
>>
>> The main thing holding back the community are lazy and/or obstinate
>> package maintainers.  If they spent half the time they've put into
>> complaining about Py3 into actually working to upgrade their code
>> they'd be done now.
> 
> That's an inflammatory, defamatory, unsubstantiated, hyperbolic,
> sweeping overgeneralization.

I know a few maintainers, and I have no problem seeing how Arc came
to that conclusion.

Georg

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2009-11-03 Thread Mike Klaas

On Tue, Nov 3, 2009 at 10:42 AM, Georg Brandl  wrote:

> sstein...@gmail.com schrieb:
> >
> > On Nov 3, 2009, at 12:28 PM, Arc Riley wrote:
> >>
> >> The main thing holding back the community are lazy and/or obstinate
> >> package maintainers.  If they spent half the time they've put into
> >> complaining about Py3 into actually working to upgrade their code
> >> they'd be done now.
> >
> > That's an inflammatory, defamatory, unsubstantiated, hyperbolic,
> > sweeping overgeneralization.
>
> I know a few maintainers, and I have no problem seeing how Arc came
> to that conclusion.

Be that as it may, the only way python 3 will be widely adopted if people
have motivation to (need to be compatible with other libs, pressure from
users, their own interest in fostering python 3.0, etc.).  Deriding them as
"lazy" accomplishes nothing and obscures the fact that it is the python
maintainers responsibility to bring about this motivation if they want
python 3.0 to be adopted.  No-one is going to convert to python 3.0 because
you called them lazy.

-Mike

>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

Antoine Pitrou schrieb:
> Georg Brandl  gmx.net> writes:
>> 
>> skip  pobox.com schrieb:
>> > Martin> And if *2.6* becomes the last of the 2.x series?
>> > 
>> > With all due respect, I don't think you can make that decision now.  The
>> > time to have stated 2.6 would be the end of the 2.x line was when 2.6 was
>> > released.  At that point instead of opening up the trunk for changes you
>> > would have closed it off or merged the py3k branch to trunk.  2.6.0 was
>> > released over a year ago and there has been no effort to suppress bug fix 
>> > or
>> > feature additions to trunk since then.  If you call 2.6 "the end of 2.x"
>> > you'll have wasted a year of work on 2.7 with about a month to go before 
>> > the
>> > first 2.7 alpha release.
>> 
>> +1.
> 
> +1 as well. Besides, it is much better communication to release 2.7 and say up
> front that it will be the last major release in the 2.x line. Announcing that
> there won't be a 2.7, however, would give the impression of poor planning.

And of a rush to get rid of 2.x.

Georg

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Retrieve an arbitrary element from a set withoutremoving it

2009-11-03 Thread Daniel Stutzbach

On Tue, Nov 3, 2009 at 4:46 PM, Steven D'Aprano  wrote:

> def pick_two_cards(hand):
>assert isinstance(hand, (set, frozenset))
>assert len(hand) == 5
>return (hand.pick(), hand.pick())
>

Even if pick() chose random, you still might end up picking the same card
twice.  Is that really what you intended?

FWIW, I've been working on an extension module that supplies a "sortedset"
type [1].  In most ways, it's similar to a set except it's indexable like a
list.  The items are kept in sorted order, so index 0 is always the lowest
item, index 1 is the next-to-lowest, etc.  Because they're indexable, it's
easy and efficient to retrieve random elements using the standard library's
"random" module.

With the sortedset type, that function would become:

def pick_two_cards(hand):
assert isinstance(hand, (set, frozenset))
assert len(hand) == 5
return random.choice(hand), random.choice(hand)

or if you want to avoid duplicates:

return random.sample(hand, 2)

Would something like that fit your needs?

[1] It's already implemented, along with sortedlist, weaksortedlist, and
weaksortedset types.  I'm just putting them through the paces in my own
products before releasing them.

--
Daniel Stutzbach, Ph.D.
President, Stutzbach Enterprises, LLC 
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

On Wed, Nov 4, 2009 at 3:25 AM, "Martin v. Löwis"  wrote:

> But only if NumPy would drop support for 2.x, for x < 7, right?
> That would probably be many years in the future.

Yes. Today, given the choice of supporting py 3.x and dropping python
< 2.7 and continue support for 2.4, the latter is by far my preferred
choice today (RHEL still require 2.4, for example).

cheers,

David
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 3003 - Python Language Moratorium

2009-11-03 Thread Stephen J. Turnbull

Guido van Rossum writes:
 > On Tue, Nov 3, 2009 at 11:23 AM, M.-A. Lemburg  wrote:

 > > One question:
 > >
 > > There are currently number of patch waiting on the tracker for
 > > additional Unicode feature support and it's also likely that we'll
 > > want to upgrade to a more recent Unicode version within the
 > > next few years.
 > >
 > > How would such indirect changes be seen under the moratorium ?
 > 
 > That would fall under the Case-by-Case Exemptions section. "Within the
 > next few years" sounds like it might well wait until the moratorium is
 > ended though. :-)

(1) Unicode "feature support" (eg, implementing access to various
databases, implementation of new algorithms) strikes me as worth a
hearing but very dubious under case-by-case (the case I have in
mind is when necessary to support (2) or (3)).

(2) Adjusting existing implementations of Unicode features (eg,
universal newline, which currently does not conform to the
relevant TR AFAIK, thus dubious IMO) to conform to (new versions
of) Unicode seems worthy of consideration on a cost/benefit basis.
I would expect that in most cases the costs that lead to a
moratorium would outweigh prospective benefits, though.  I don't
know of an example where I'd support an exception to the
moratorium for this, though.  It's hard to imagine that things
like the algorithm for UTF-16 are going to change, and support for
things like bidi are currently outside of the scope of the
moratorium as I understand it -- they'd be stdlib facilities.

(3) Upgrading the character repertoire and property databases (eg,
case and composition) seems like a shoo-in to me.  That's why the
databases are versioned.  Of course there are costs to upgrading
(backward compatibility in some corner cases, eg) that might
outweigh the benefits at any given time, but I don't think this
should fall under the moratorium if someone finds a benefit to
upgrading the databases within the moratorium period.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 3003 - Python Language Moratorium

2009-11-03 Thread Jesse Noller

On Tue, Nov 3, 2009 at 12:35 PM, Guido van Rossum  wrote:
> I've checked draft (!) PEP 3003, "Python Language Moratorium", into
> SVN. As authors I've listed Jesse, Brett and myself.
>
> On python-ideas the moratorium idea got fairly positive responses
> (more positive than I'd expected, in fact) but I'm bracing myself for
> fierce discussion here on python-dev. It's important to me that if if
> this is accepted it is a "rough consensus" decision (working code we
> already have plenty of :-), not something enforced by a vocal minority
> or an influential individual such as myself. If there's too much
> opposition I'll withdraw the PEP so as not to waste everybody's time
> with a fruitless discussion.
>
> The PEP tries to spell out some gray areas but I'm sure there will be
> others; that's life. Do note that the PEP proposes to be *retroactive*
> back to the 3.1 release, i.e. the "frozen" version of the language is
> the state in which it was released as 3.1.
>
> --
> --Guido van Rossum (python.org/~guido)
>

+1 - I'll work on some grammar kinks in my prose asap
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 3003 - Python Language Moratorium

On Tue, Nov 3, 2009 at 11:23 AM, M.-A. Lemburg  wrote:
>> This suspension of features is designed to allow non-CPython implementations
>> to "catch up" to the core implementation of the language, help ease adoption
>> of Python 3.x, and provide a more stable base for the community.
>
> I'd also add "to allow users to catch up"... ;-)

IMO that's implied by "help ease adoption".

> One question:
>
> There are currently number of patch waiting on the tracker for
> additional Unicode feature support and it's also likely that we'll
> want to upgrade to a more recent Unicode version within the
> next few years.
>
> How would such indirect changes be seen under the moratorium ?

That would fall under the Case-by-Case Exemptions section. "Within the
next few years" sounds like it might well wait until the moratorium is
ended though. :-)

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2009-11-03 Thread Larry Bugbee

This is my problem to solve...  I work with a lot of [non-production]  
crypto where byte strings are a normal way of manipulating and storing  
keys and other artifacts.  Under Python2 I have few/no Unicode  
issues.  With Python3's default string type being Unicode, there are a  
lot of subtle ways where my codes go south.  Like I say, it is my  
problem.


I will convert to Py3, but not likely before summer.  Besides 2to3,  
any other tools/suggestions would be welcome.  (Perhaps there is a  
Master switch to disable Unicode? ;-)


Changing the subject...  I say -1 on backporting more 3.x features to  
2.6/2.7.  As previously mentioned, leave the carrot.  And best  
intentions aside, backports can introduce problems of their own.




___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2009-11-03 Thread Ben Finney

Antoine Pitrou  writes:

> Paul Moore  gmail.com> writes:
> > TurboGears - Python 3 "currently unsupported", no timescale given
>
> TurboGears is Pylons-based, so I suppose the actual question is when
> Pylons gets ported.

And there's the rub. I expect this general problem of “project FOO
depends on library BAR, so there's no point thinking about migration of
FOO until BAR is ready for Python 3” will prove to be quite common in
widespread projects.

-- 
 \   “If you do not trust the source do not use this program.” |
  `\—Microsoft Vista security dialogue |
_o__)  |
Ben Finney

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Retrieve an arbitrary element from a set withoutremoving it

On Tue, Nov 3, 2009 at 2:46 PM, Steven D'Aprano  wrote:
> On Tue, 3 Nov 2009 09:19:38 am Greg Ewing wrote:
>> Cameron Simpson wrote:
>> > Personally, I'm for the iteration spec in a lot of ways.
>> >
>> > Firstly, a .get()/.pick() that always returns the same element
>> > feels horrible. Is there anyone here who _likes_ it?
>>
>> It doesn't sound very useful to me. However, an iterating
>> version of it doesn't sound any more useful. What would it
>> gain you? Why not just iterate over the set? Or make a
>> copy and repeatedly pop() it?
>
> Since I was the person who decided that "arbitrary" meant "give a
> different result each time", I should answer that.
>
> My intention was not that people should use repeated calls to pick() for
> iteration. I described that as an abuse of the method. But I can
> imagine scenarios where the caller calls set.pick() sequentially:
>
> def pick_two_cards(hand):
>    assert isinstance(hand, (set, frozenset))
>    assert len(hand) == 5
>    return (hand.pick(), hand.pick())
>
>
> As I said in a reply to Raymond, optimization was not my primary
> concern, but as a fundamental set operation[1] pick() should be
> efficient. It may be called on a set with millions of items, not just
> small sets. Copying to another set, or to a list, will be O(N) and
> potentially slow -- at the very least, it is wasteful to copy millions
> of elements in order to access one.
>
> I don't know how expensive it is to create a set iterator, but (my
> reasoning went) surely we can do better? The set already has access to
> its own elements, it just needs to return one of them. pop() also knows
> how to retrieve an arbitrary element. pick() is just like pop(), except
> without removal.
>
>
>> I completely fail to see a use case for this.
>
> Nevertheless, people keep requesting it, so obviously they have a use
> for it. None of the standard solutions are obvious or easily
> discoverable, and in my experience the usual solution people come up
> with is to pop() an element, then add() it back in, but of course
> that's not just inelegant but it fails on frozensets.
>
>
>
> [1] Obviously there is disagreement on whether or not pick() is a
> fundamental operation or not. As Raymond points out, it is uncommon in
> other languages. But Wikipedia lists it as fundamental, and it is not
> just Python users who ask for it:
>
> http://stackoverflow.com/questions/124671/picking-a-random-element-from-a-set

You're obviously talking about a *random* element. This is a separate
use case (though I agree many people don't know the difference).

Picking a random element can be done in O(1) only if the data
structure supports access by index, which Python's hash tables don't.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Porting C extensions

Brett Cannon  python.org> writes:
> 
> I'm afraid there is some FUD going around here, which is
> understandable since no one wants to burn a ton of time on something
> that will be difficult or take a lot of time. But I have not heard
> anyone in this email thread (or anywhere for that matter) say that
> they tried a port in earnest and it turned out to be difficult.

One obvious example is the C extensions for the interpreter itself.
The code for those C extensions is actually almost the same from 2.x to 3.x. The
two main changes are the module initialization sequence (see PEP 3121) and the
bytes->unicode change for special methods such as tp_repr.

Regards

Antoine.

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Retrieve an arbitrary element from a set withoutremoving it

Guido van Rossum  python.org> writes:
> 
> You're obviously talking about a *random* element. This is a separate
> use case (though I agree many people don't know the difference).
> 
> Picking a random element can be done in O(1) only if the data
> structure supports access by index, which Python's hash tables don't.

Well, at the implementation level, they can. You'd just have to pick a new
random index until it points to a non-empty slot.

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 3003 - Python Language Moratorium

2009-11-03 Thread Brett Cannon

On Tue, Nov 3, 2009 at 09:35, Guido van Rossum  wrote:
> I've checked draft (!) PEP 3003, "Python Language Moratorium", into
> SVN. As authors I've listed Jesse, Brett and myself.
>
> On python-ideas the moratorium idea got fairly positive responses
> (more positive than I'd expected, in fact) but I'm bracing myself for
> fierce discussion here on python-dev. It's important to me that if if
> this is accepted it is a "rough consensus" decision (working code we
> already have plenty of :-), not something enforced by a vocal minority
> or an influential individual such as myself. If there's too much
> opposition I'll withdraw the PEP so as not to waste everybody's time
> with a fruitless discussion.
>

Are you going to gauge it roughly from python-dev feedback, or should
we take a more formal vote on python-committers once the PEP has
settled?

> The PEP tries to spell out some gray areas but I'm sure there will be
> others; that's life. Do note that the PEP proposes to be *retroactive*
> back to the 3.1 release, i.e. the "frozen" version of the language is
> the state in which it was released as 3.1.

I'm obviously +1 for this.

I think one thing to decide is how long the moratorium is in effect.
As of right now the PEP's abstract says for "at least two years",
which taking into account the release schedule Benjamin is proposing
and assuming acceptance at the end of the year puts us at roughly the
release of Python 3.3. Should we just say this will be in affect until
development is open for Python 3.4?

-Brett
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 3003 - Python Language Moratorium

On Tue, Nov 3, 2009 at 10:20 AM, "Martin v. Löwis"  wrote:
>> * General language semantics
>>     The language operates as-is with only specific exemptions (see
>>     below).
>
> Would PEP 382 (namespace packages) fall under the moratorium?

Import semantics are a bit of a gray area. However I think the
moratorium shouldn't be interpreted to prohibit this. I think there
was a question on python-ideas about import semantics, and my response
was something like "import semantics vary between Python
implementations anyway." I'll add this to the PEP.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 3003 - Python Language Moratorium

2009-11-03 Thread skip


Guido> I've checked draft (!) PEP 3003, "Python Language Moratorium",
Guido> into SVN.

LGTM.

Skip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2009-11-03 Thread Terry Reedy


Guido van Rossum wrote:

On Tue, Nov 3, 2009 at 9:37 AM, "Martin v. Löwis"  wrote:

(and no, adding things like nonlocal to 2.7 doesn't making porting of
a real application or library any easier, since the existing application
or library simply doesn't use that keyword.


Agreed.


In fact, no change to 2.x
can reasonably simplify porting - only changes to 3.x might - except
for changes to 2to3, which can simplify porting a lot. But 2to3 should
be run under 3.x, IMO.)


Disagreed. Better "-3" warnings could make porting easier. (Not just
more warnings -- "better" might mean fewer false positives for
warnings already issued.)


There is also Eric Smith's list to consider: PEP3118 new buffer 
protocol, short float repr, and maybe io.



FWIW, it doesn't sound like killing 2.7 is a productive thing to do.
However making 2.7 the end of the line (though with indefinite bugfix
releases) might be. (Indefinite != infinite.)


I think you should decide and announce something like the following:
'''
Python 2.7 will be the final, stable release in the Python 2 line.
It will be released in mid-2010 with the first alpha scheduled for 
December 2009.
It will not intentionally break valid older 2.x code; this means no 
removals. (Valid == not exploiting a bug.)
Being the last of its line, there will be no deprecation warnings unless 
explicitly requested with the -3 flag to warn about incompatibilities 
with 3.x.

There will be lots of bug fixes since 2.6.
There will be only a few new features, with those aimed at easing 
eventual transition of libraries to 3.x.
The period of 2.7.z bugfix releases should be longer than for previous 
x.y releases (as long as there are volunteers to write and review 
patches and prepare distributions).


The developers urge people with 2.x code, especially library 
maintainers, to test it with preliminary alpha or beta releases so 2.7 
can be as good as possible.


The developers hope OS distributions can move to including 2.7 as soon 
as feasible, even if it means 'skipping' 2.6 as a default version.

'''
[My intention with the last is to promote 2.7 as the definitive version 
of 2.x, though there might be better wording.]


Terry Jan Reedy


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 3003 - Python Language Moratorium

Guido van Rossum wrote:
> I've checked draft (!) PEP 3003, "Python Language Moratorium", into
> SVN. As authors I've listed Jesse, Brett and myself.
> 
> On python-ideas the moratorium idea got fairly positive responses
> (more positive than I'd expected, in fact) but I'm bracing myself for
> fierce discussion here on python-dev. It's important to me that if if
> this is accepted it is a "rough consensus" decision (working code we
> already have plenty of :-), not something enforced by a vocal minority
> or an influential individual such as myself. If there's too much
> opposition I'll withdraw the PEP so as not to waste everybody's time
> with a fruitless discussion.
> 
> The PEP tries to spell out some gray areas but I'm sure there will be
> others; that's life. Do note that the PEP proposes to be *retroactive*
> back to the 3.1 release, i.e. the "frozen" version of the language is
> the state in which it was released as 3.1.

+1.

> This suspension of features is designed to allow non-CPython implementations
> to "catch up" to the core implementation of the language, help ease adoption
> of Python 3.x, and provide a more stable base for the community.

I'd also add "to allow users to catch up"... ;-)

One question:

There are currently number of patch waiting on the tracker for
additional Unicode feature support and it's also likely that we'll
want to upgrade to a more recent Unicode version within the
next few years.

How would such indirect changes be seen under the moratorium ?

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Nov 03 2009)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/

::: Try our new mxODBC.Connect Python Database Interface for free ! 

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   http://www.egenix.com/company/contact/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Retrieve an arbitrary element from a set withoutremoving it

On Tue, Nov 3, 2009 at 5:10 PM, Antoine Pitrou  wrote:
> Greg Ewing  canterbury.ac.nz> writes:
>> >
>> >>Picking a random element can be done in O(1) only if the data
>> >>structure supports access by index, which Python's hash tables don't.
>> >
>> > Well, at the implementation level, they can. You'd just have to pick a new
>> > random index until it points to a non-empty slot.
>>
>> But that's hardly O(1).
>
> It is, assuming that the set has a built-in minimum fill level (e.g. it always
> keeps at least x% of its entries filled), and the random generator is good.
>
> (of course, it is "statistically O(1)", like lookups in a hash table actually)

Clever. But I don't think the set implementation should have a
dependency on random(), so it would have to expose an "indexing"
operation, which smells like it would expose too much of the
implementation for comfort.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] nonlocal keyword in 2.x?

"Martin v. Löwis" wrote:
>>> 2.7 has an up-to-date backport of the C IO lib (as well as the memoryview
>>> object), which means it is better for people wanting to ease transition to 
>>> 3.x.
>>>
>>> But of course, as Martin said, few people will want to support 2.7 only and 
>>> not 
>>> 2.6.
>>
>> Since 2.7 will be closer to 3.2 than 2.6, the result will more likely
>> be: many people will want to support 2.7 and 3.x - which is really
>> what we should be after.
> 
> Supporting 2.7 doesn't mean that you have to use the nonlocal keyword
> (nor does support for 3.2 require that keyword). So I'm not sure how
> the backport of a feature to 2.x could encourage people to forward-port
> to 3.x.

True. This particular backport is not all that useful - it is well
possible to write code that doesn't need the feature, both in 2.7 and
3.2.

However, if a 3.2 feature is required for code to work out of the
box without changes, then I'd regard such a feature as potential
backport candidate.

memoryviews are a good example. In 3.x the buffer object is gone
and memoryviews are the new replacement for it.

Code written to support both 2.7 and 3.2 would need to have
access to these memoryviews in order to avoid having to
write special support for buffer objects (for 2.7) and
memoryviews (for 3.x).

By backporting memoryviews to 2.7, users no longer have to
write support code for buffer objects and that makes things
easier for them.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Nov 03 2009)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/

::: Try our new mxODBC.Connect Python Database Interface for free ! 

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   http://www.egenix.com/company/contact/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2009-11-03 Thread Steven Bethard

On Tue, Nov 3, 2009 at 4:55 AM, Barry Warsaw  wrote:
> I'd like to read some case studies of people who have migrated applications
> from 2.6 to 3.0.

For what it's worth, it was pretty easy to migrate argparse:

  http://code.google.com/p/argparse/source/detail?r=12

It was mostly just adding a few aliases, and doing a little
sys.exc_info() dance in a couple places because argparse supports
Python 2.3 - 3.1 all in the same code base.

Steve
-- 
Where did you get that preposterous hypothesis?
Did Steve tell you that?
--- The Hiphopopotamus
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

> I wouldn't say that.  For instance, I'm just starting a refactoring that will
> result in getmail v.5, but I need to target Python 2.5 and up, so there's
> essentially no way the code will run in Python 3.x (as another list member
> posted).

That's a common myth. It is very well possible, using 2to3. You don't
have to wait until you can drop 2.5 to start supporting 3.x, out of a
single code base.

> Why do I need to target Python 2.5?  Because that's the most current default
> version of Python shipped in Debian stable and various other distributions
> that don't stay on the bleeding edge.  getmail v.4 targeted Python 2.3 and up,
> getmail v.3 targeted Python 1.5.2 and up.  I may be able to target Python 2.6
> in a year or two, at which point Python 3 compatibility becomes a reasonable
> goal.

Are you saying that it doesn't *run* on 2.6? Why?
(not sure what you mean by "targetting")

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

Terry Reedy schrieb:
> James Y Knight wrote:
> 
>> If that happens, it's not true that there's *nowhere* to go. A solution 
>> would be to discard 3.x as a failed experiment, take everything that is 
>> useful from it and port it to 2.x, and simply continue development from 
>> the last 2.x release. And from there, features can be deprecated and 
>> then removed a few releases later, as is the usual policy.
> 
> The once 'usual policy' of removal was changed several years ago to 
> 'defer removals until 3.0' because people wanted a more stable language 
> and claimed that they would prefer to deal with several removals all at 
> once. So old-style classes were kept around long past when they would 
> have been removed under the old 'usual policy'. Ditto for old-style int 
> / int and some others.  Or one can simply recognize that 3.0 was the 
> 'few releases later' release of that policy.
> 
> The other big change was switching to unicode strings from ascii strings 
> with optional unicode string add-on. That was/is/will-be a hassle 
> regardless of when and what name, but necessary for Python to be a 
> modern world language.

>From my experience, string to unicode migration really is the biggest
pain when porting anything that handles real-world data.

An interesting experiment would have been to split the big changes in two
parts, e.g., a 2.95 that only has the string to unicode changes, and
a 3.0 that has all the rest.  Of course, people would have complained
about having to port twice :)

Georg

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] No buildbot to test wide unicode?

2009-11-03 Thread Amaury Forgeot d'Arc

Hello,

It seems that there is no buildbot to test a wide unicode build.

On http://www.python.org/dev/buildbot/3.x/ all outputs of the "configure"
steps show this message::
  checking what type to use for str... unsigned short
which looks like a ucs2 build to me.

Since wide unicode is the standard chosen by some Linux distributions,
it would make sense to have at least one buildbot running with
--with-wide-unicode (3.x) or --enable-unicode=ucs4 (2.x).

-- 
Amaury Forgeot d'Arc
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Retrieve an arbitrary element from a set withoutremoving it

Greg Ewing  canterbury.ac.nz> writes:
> > 
> >>Picking a random element can be done in O(1) only if the data
> >>structure supports access by index, which Python's hash tables don't.
> > 
> > Well, at the implementation level, they can. You'd just have to pick a new
> > random index until it points to a non-empty slot.
> 
> But that's hardly O(1).

It is, assuming that the set has a built-in minimum fill level (e.g. it always
keeps at least x% of its entries filled), and the random generator is good.

(of course, it is "statistically O(1)", like lookups in a hash table actually)

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 3003 - Python Language Moratorium


On Nov 3, 2009, at 12:35 PM, Guido van Rossum wrote:


I've checked draft (!) PEP 3003, "Python Language Moratorium", into
SVN. As authors I've listed Jesse, Brett and myself.

On python-ideas the moratorium idea got fairly positive responses
(more positive than I'd expected, in fact) but I'm bracing myself for
fierce discussion here on python-dev. It's important to me that if if
this is accepted it is a "rough consensus" decision (working code we
already have plenty of :-), not something enforced by a vocal minority
or an influential individual such as myself. If there's too much
opposition I'll withdraw the PEP so as not to waste everybody's time
with a fruitless discussion.

The PEP tries to spell out some gray areas but I'm sure there will be
others; that's life. Do note that the PEP proposes to be *retroactive*
back to the 3.1 release, i.e. the "frozen" version of the language is
the state in which it was released as 3.1.


I think this is a great idea.  I'd love to see the energy normally put  
into evolving the language into making the stdlib really kick ass.


-Barry



PGP.sig
Description: This is a digitally signed message part
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 3003 - Python Language Moratorium

2009-11-03 Thread Facundo Batista

On Tue, Nov 3, 2009 at 2:35 PM, Guido van Rossum  wrote:

> fierce discussion here on python-dev. It's important to me that if if
> this is accepted it is a "rough consensus" decision (working code we

+1 to the PEP.

-- 
.Facundo

Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] language summit topic: issue tracker

> yet another feature request or two to be lost to a mailing list thread
> along those lines:
> 
> Maintainer or not i'd like to be able to setup triggers so that i'm
> automatically cc'ed on any bugs matching a simple search query i
> specify.

Please add that to the meta tracker (if you really want it, rather
than just losing it on the mailing list :-)

Implementing it would be quite involved, I think. It should probably
go into the saved query feature. Evaluating them on every change would
might be expensive, so doing so only regularly (e.g. hourly) would
be ok?

> The email sent out to people cc'ed when a new bug is opened and
> unassigned should have a simple links in it when cc'ed to someone who
> can be assigned bugs:  'Assign to me' that if followed will assign
> that bug to them without requiring a login.

Unfortunately, this is now defeated by the fear of XSS attacks. If
such a link was possible, it would be also possible to embed it
into a XSS attack, right?

It would be possible to protect the link with a token, but then,
efficient token validation might be tricky. So this would also need
to go into the meta tracker.

If you are really interested in these, it would be best to add them
as feature requests to roundup itself (since that really is the place
where they should be provided):

http://issues.roundup-tracker.org/

[but then, roundup could also use more contributors]

Regards,
Martin

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

On Tue, Nov 3, 2009 at 1:00 PM, Georg Brandl  wrote:
> From my experience, string to unicode migration really is the biggest
> pain when porting anything that handles real-world data.

Of course, handling Unicode right is also the biggest pain when
writing code for 2.x in the first place -- writing greenfield code
targeted at 3.x that does Unicode right is a lot easier. Alas, this
does nothing for those folks who already have working Unicode handling
code for 2.x...

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

On Tue, Nov 3, 2009 at 3:27 PM, Larry Bugbee  wrote:
> This is my problem to solve...  I work with a lot of [non-production] crypto
> where byte strings are a normal way of manipulating and storing keys and
> other artifacts.  Under Python2 I have few/no Unicode issues.  With
> Python3's default string type being Unicode, there are a lot of subtle ways
> where my codes go south.  Like I say, it is my problem.

It may be interesting for others if you posted some examples of what
you are used to doing in 2.x. Maybe somebody will suggest a better way
of doing it in 3.x than you have thought of. :-)

> I will convert to Py3, but not likely before summer.  Besides 2to3, any
> other tools/suggestions would be welcome.  (Perhaps there is a Master switch
> to disable Unicode? ;-)

Yes, go back to 1.5.2. :-)

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

>> You may also want to take a look at my ZODB port:
>>
>> https://www.dcl.hpi.uni-potsdam.de/home/loewis/zodb/
> 
> Has that port been integrated back into the zodb project?

Only partially so.

> If not, it
> would be interesting to know the reasons (zodb project maintainers not
> interested, barriers to contribution are too high, port is not 100%
> complete and no-one willing to take it over and complete it...?)

ZODB is a lot of layers, really (zope.interfaces, zope.lockfile,
zope.proxy, ZConfig, etc..., finally ZODB).

I failed to port buildout and zope.testing. With zope.testing not
ported, it is not easy to actually run the test suites for all of
these; this is where the integration stalled.

In any case, I only did the port in September; at the DZUG sprint,
people from gocept then started looking into integrating it.
We didn't get through at the sprint, and I think there has been
little progress since.

One specific issue was about specifying the root of the zope.interfaces
hierarchy. In current zope.interfaces, None could be used (implicitly)
instead of Interface, to indicate the root interface type. In 3.x, this
would break tests, because you can't sort a list of interfaces anymore
if that list also contains None. So people decided that zope.interfaces
needs to be changed to disallow None, and that was a significant change
that has not yet been fully understood.

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Retrieve an arbitrary element from a set withoutremoving it

On Tue, Nov 3, 2009 at 12:20 AM, Yuvgoog Greenle  wrote:
> On Tue, Nov 3, 2009 at 12:19 AM, Greg Ewing 
> wrote:
>>
>> Cameron Simpson wrote:
>>
>>> Personally, I'm for the iteration spec in a lot of ways.
>>>
>>> Firstly, a .get()/.pick() that always returns the same element feels
>>> horrible. Is there anyone here who _likes_ it?
>>
>
> State might cause people to use this to iterate which would be just plain
> wrong. The 2 things I have a bad feeling about is:
> 1. random.choice could be a pythonic alternative to what some have mentioned
> here but it doesn't work on sets. The following code raises TypeError: 'set'
> object does not support indexing:
>     import random
>     random.choice(set([1,2,3,4,5,6]))

There is a huge difference between picking a random element of a set
and picking an arbitrary one. Algorithms that need randomness *must*
use the random generator (and because the hash table implementation
doesn't provide O(1) access they will have to use a list first).
Algorithms that don't need randomness should not be forced to pay for
the (considerable!) cost of calling the random number generator, and
must accept that the element selected may be predictable.

> this is kinda ironic: http://en.wikipedia.org/wiki/Axiom_of_choice

Also irrelevant. That Axiom is only interesting for infinite sets,
which Python does not support (at least not using the set builtin --
you can of course write your own symbolic algebra package in Python
that can be used to represent certain infinite sets, though you still
won't be able to iterate over all of their elements :-).

> 2. If I store objects in a set and modify their attributes I have no O(1)
> way of getting the objects back if I stumble upon an equivalent object. In
> cases like that I'd have to either iterate over the set or use a dict with
> key == value. I have a feeling the "get" or "peek" api could cater to this
> need. A use case for this could be an implementation of a cookie jar with a
> set of cookies where equivalence is defined by the name and domain.

Sets are what they are. If they don't fit your requirements, don't use
them. Don't get fooled by the name -- a dict also isn't a very good
data structure to implement an actual Chinese-English dictionary, for
example. :-)

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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



On Nov 3, 2009, at 7:42 PM, Ben Finney wrote:


Antoine Pitrou  writes:


Paul Moore  gmail.com> writes:

TurboGears - Python 3 "currently unsupported", no timescale given


TurboGears is Pylons-based, so I suppose the actual question is when
Pylons gets ported.


And there's the rub. I expect this general problem of “project FOO
depends on library BAR, so there's no point thinking about migration  
of

FOO until BAR is ready for Python 3” will prove to be quite common in
widespread projects.


There's no "will prove", it is.

S

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2009-11-03 Thread Brett Cannon

On Tue, Nov 3, 2009 at 05:40, David Cournapeau  wrote:
> On Tue, Nov 3, 2009 at 9:55 PM, Barry Warsaw  wrote:
>
>>
>> Then clearly we can't back port features.
>>
>> I'd like to read some case studies of people who have migrated applications
>> from 2.6 to 3.0.
>
> +1, especially for packages which have a lot of C code: the current
> documentation is sparse :) The only helpful reference I have found so
> far is an email by MvL concerning psycopg2 port.

There used to be a page on the wiki of case studies, but I couldn't
find it. But one C-specific case study is the port of Wing's extension
modules to support from Python 2.0 to 3.0:
http://pythonology.blogspot.com/2009/02/making-code-run-on-python-20-through-30.html
. There is also a wiki pages explicitly about porting C code:
http://wiki.python.org/moin/cporting and
http://wiki.python.org/moin/Py3kExtensionModules . Those latter pages
include links to the official porting docs:
http://docs.python.org/3.1/howto/cporting.html .

And as Georg pointed out there is always the python-porting mailing
list: http://mail.python.org/mailman/listinfo/python-porting .

I'm afraid there is some FUD going around here, which is
understandable since no one wants to burn a ton of time on something
that will be difficult or take a lot of time. But I have not heard
anyone in this email thread (or anywhere for that matter) say that
they tried a port in earnest and it turned out to be difficult.

-Brett
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

On Tue, Nov 3, 2009 at 9:37 AM, "Martin v. Löwis"  wrote:
> (and no, adding things like nonlocal to 2.7 doesn't making porting of
> a real application or library any easier, since the existing application
> or library simply doesn't use that keyword.

Agreed.

> In fact, no change to 2.x
> can reasonably simplify porting - only changes to 3.x might - except
> for changes to 2to3, which can simplify porting a lot. But 2to3 should
> be run under 3.x, IMO.)

Disagreed. Better "-3" warnings could make porting easier. (Not just
more warnings -- "better" might mean fewer false positives for
warnings already issued.)

FWIW, it doesn't sound like killing 2.7 is a productive thing to do.
However making 2.7 the end of the line (though with indefinite bugfix
releases) might be. (Indefinite != infinite.)

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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