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

[Mike Krell]

On Thu, Nov 5, 2009 at 1:08 PM, "Martin v. Löwis" wrote:

> > Mike Krell wrote:
> >> Well, 3to2 would then be an option for you: use Python 3 as the
> source
> >> language.
> >
> > Making life easier for 3to2 is an *excellent* rationale for backports.
>

Clarifying a bit of potentially misleading editing:  I wrote neither of the
statements quoted above.  M v L wrote the first and Nick C. wrote the
second.


> I'm skeptical. If new features get added to 2.7: why would that simplify
> 3to2? It couldn't *use* these features, since it surely would have to
> support 2.6 and earlier as well.
>
> Not sure what 3to2 would do about difficult-to-convert 3.x feature (as,
> perhaps, the nonlocal keyword). If it currently gives up, it then may
> offer you to restrict your target versions to 2.7+. Not sure whether
> users would use that option, though - perhaps they rather stop using
> nonlocal in 3.x if 3to2 cannot support it for all 2.x versions they are
> interested in.
>

> Perhaps 3to2 has a work-around that still provides a good backport in
> most cases. Then, the backport would not make the tool any simpler: if
> 3to2 would start using the backport, it would actually get more
> complicated (not easier), as it now needs to support two cases.
>

I basically agree with you here, except perhaps for the likely definition of
"versions they are interested in".  You have suggested on several occasions
that a 2.7 (or 2.8) containing new syntax such as nonlocal would be of
limited value because the vast majority of developers interested in
supporting 2.x would have to support 2.6 as well.  I respectfully suggest
that may not necessarily be the case.  I suspect that there are lots of
small fish out there like me who have the luxury of being able to hop onto
whatever version of the language suits them the best.  Not to mention all of
the new users who will be drawn to Python over the next several years while
the 3.x standard library and third party library situation becomes more
stable and comprehensive.  Why not make the 2.x feature set the best it can
be given the likelihood that 2.x will be the most compelling alternative to
many users until the 3.x libraries mature?

Of course, it's easy for me to ask other people to the hard work.  It might
be fun to take a crack at implementing nonlocal myself, but I know next to
nothing about the implementation of CPython.  By the time I pestered y'all
with enough questions to get up to speed, you'd probably wish you'd just
implemented it yourself -- less work :-)

   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]

Michael Foord  voidspace.org.uk> writes:
> 
> I would love to see nonlocal backported to 2.7 as it cleans up a simple 
> pattern that I use relatively often for testing.

Well you know I'm sure that if someone proposes a proper patch it will
eventually get accepted ;)

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?

[Brett Cannon]

On Thu, Nov 5, 2009 at 09:34, Yuvgoog Greenle  wrote:
> On Thu, Nov 5, 2009 at 2:31 PM, Nick Coghlan  wrote:
>>
>> While it may be hard to tell without knowing who is and isn't a core
>> developer
>
> Maybe there should be badges or something, hmmm, sounds like making an
> svn-commits-hall-of-fame for python could be a nice project.
>

You might be interested in http://www.ohloh.net/p/python/contributors .

-Brett


> --yuv
>
> ___
> 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/brett%40python.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?

[Lennart Regebro]

2009/11/4 sstein...@gmail.com :
> Maybe the 3.x line should just be put out of our misery, merged back to 2.7,
> 2.8, 2.9, and proceed as Glyph suggested in passing with increasing levels
> of deprecation until it just turns into 3.x on its own by running out of
> numbers.

Yeah, maybe. If people haven't moved over to Python 3 in 2015 I think
we should start considering it. Let's discuss this again then.

-- 
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64
___
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?

[Eric Smith]

Martin v. Löwis wrote:

Mike Krell wrote:

Well, 3to2 would then be an option for you: use Python 3 as the source
language.

Making life easier for 3to2 is an *excellent* rationale for backports.



I'm skeptical. If new features get added to 2.7: why would that simplify
3to2? It couldn't *use* these features, since it surely would have to
support 2.6 and earlier as well.

Not sure what 3to2 would do about difficult-to-convert 3.x feature (as,
perhaps, the nonlocal keyword). If it currently gives up, it then may
offer you to restrict your target versions to 2.7+. Not sure whether
users would use that option, though - perhaps they rather stop using
nonlocal in 3.x if 3to2 cannot support it for all 2.x versions they are
interested in.


But surely someday 2.7 will be the oldest targetted 2.x version of 
Python for 3to2 and other tools (regardless of whether there's a 2.8). 
When that day comes, 3to2 can be made simpler, or can increase the 
amount of Python 3.x it can convert (or both) if we add 3.x features to 2.7.


Of course, planning for a time so far in the future is difficult, and 
possibly pointless.

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

[Michael Foord]

Martin v. Löwis wrote:

Mike Krell wrote:


Well, 3to2 would then be an option for you: use Python 3 as the source
language.
  

Making life easier for 3to2 is an *excellent* rationale for backports.




I'm skeptical. If new features get added to 2.7: why would that simplify
3to2? It couldn't *use* these features, since it surely would have to
support 2.6 and earlier as well.

Not sure what 3to2 would do about difficult-to-convert 3.x feature (as,
perhaps, the nonlocal keyword). If it currently gives up, it then may
offer you to restrict your target versions to 2.7+. Not sure whether
users would use that option, though - perhaps they rather stop using
nonlocal in 3.x if 3to2 cannot support it for all 2.x versions they are
interested in.
  


I would have thought you could translate nonlocal with the following:

Python 3:

def scope():
   name = value
   do_something_with(name)
   def inner():
   nonlocal name
   name = new_value
   do_something_else(name)

Python 2

def scope():
   name = [value]
   do_something_with(name[0])
   def inner():
   name[0] = new_value
   do_something_else(name[0])

I would love to see nonlocal backported to 2.7 as it cleans up a simple 
pattern that I use relatively often for testing.



Suppose you have an class and you want to test that method a calls 
method b, in Python 2 you might write something like this:


def test_method_a_calls_method_b():
  instance = SomeClass()
  was_called = []
  def method_b():
 was_called.append(True)

  instance.method_b = method_b
  instance.method_a()

  assert was_called == [True]

in Python 3 you can replace this with the slightly nicer:


def test_method_a_calls_method_b():
  instance = SomeClass()
  was_called = False
  def method_b():
 nonlocal was_called
 was_called = True

  instance.method_b = method_b
  instance.method_a()

  assert was_called

As to the argument that releasing 2.7 is pointless as few people would 
use it for several years, the success of Python 2.6 shows that although 
*many* people don't / can't use new versions of Python for several years 
many other people are able to and do use new versions of Python.


All the best,

Michael Foord


Perhaps 3to2 has a work-around that still provides a good backport in
most cases. Then, the backport would not make the tool any simpler: if
3to2 would start using the backport, it would actually get more
complicated (not easier), as it now needs to support two cases.

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

[Lennart Regebro]

2009/11/4 "Martin v. Löwis" :
>> Keep in mind also that the 2.x translation process is extremely slow and
>> results in a clunky development process.  There's no '2to3
>> --interactive' commandline that lets me type python 2 at a >>> prompt
>> and get python 3 results out so that I can try experiments on the 3.x
>> interpreter; I have to actually put my experiments into my unit tests
>> and wait 10 minutes to see if it works.  It's like writing C++.
>
> That's not my experience. I see a change in source (say, on Django)
> available for 3.x within 5 seconds.

True, but you need to set up a process that will convert only the
changed files, and before Distribute came with 3.0 support, that was
tedious. Now it's easy, if you want to use distribute. (Except that
there is some bug I promised to look at this week, but haven't)

-- 
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64
___
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]

> Mike Krell wrote:
>> Well, 3to2 would then be an option for you: use Python 3 as the source
>> language.
> 
> Making life easier for 3to2 is an *excellent* rationale for backports.
> 

I'm skeptical. If new features get added to 2.7: why would that simplify
3to2? It couldn't *use* these features, since it surely would have to
support 2.6 and earlier as well.

Not sure what 3to2 would do about difficult-to-convert 3.x feature (as,
perhaps, the nonlocal keyword). If it currently gives up, it then may
offer you to restrict your target versions to 2.7+. Not sure whether
users would use that option, though - perhaps they rather stop using
nonlocal in 3.x if 3to2 cannot support it for all 2.x versions they are
interested in.

Perhaps 3to2 has a work-around that still provides a good backport in
most cases. Then, the backport would not make the tool any simpler: if
3to2 would start using the backport, it would actually get more
complicated (not easier), as it now needs to support two cases.

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?

[P.J. Eby]

At 11:27 PM 11/4/2009 +, Floris Bruynooghe wrote:



You have time to read this thread but no time to read "What's New In
Python 3"?




Given that the average developer using tons of existing libraries on 
2.x is unlikely to see any killer benefits in moving to 3.x, it's a 
natural attitude to have.


I fought this same battle with setuptools for a long time before it 
sank in that people who don't perceive a need aren't going to RTFM, 
no matter how much time said RTFMing would save them in the long run, 
vs. sitting around complaining.


IOW, once someone has become annoyed by the mere appearance of a 
necessity to deal with something that appears to be being foisted on 
them (whether it's setuptools or Python 3), the natural tendency is 
to minimize any actual work that would move in the direction of the 
thing they feel forced to deal with.


For me, the closest thing to a killer feature in 3.x is argument type 
declarations, and it'd be a mild convenience at best.  From a 
distance, many of the other changes appear like anti-features, if 
only because they're changing what I've been used to for twelve-plus 
years.  (A few, like the removal of __metaclass__-in-locals support, 
are an active hindrance to porting.)


So no, I haven't actually tried to port anything, nor have I done 
more than lightly skim the porting docs...  looking for some reason 
why I'd *want* to move to Python 3.  Heck, I have yet to use 2.6 to 
run any production code, and find some of *its* changes a bit 
annoying from a porting perspective.  (E.g. dropping the "sets" module.)


To make Py3 migration worthwhile to developers with heavy investment 
in the 2.x lines (and especially those supporting all the way back to 
2.3 and 2.4), it'd have to have some *really* killer features.  That 
is, be more like a Python 3000, and less like a Python 2.6 with a few 
bells and whistles, hampered by having to relearn some of the basic 
types and a soon-to-be-rebuilt standard library.


Even if, in truth, the cost-benefit ratio right now *is* good for 
migrating to 3.x, nobody's doing a good job at promoting what those 
benefits are.


(And it being easy to port to is NOT a benefit: nobody cares how easy 
it is to do something they don't see a reason to do in the first place.)


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

Zooko O'Whielacronx wrote:

Folks:



So, if you guys slip in your favorite new Python 3 feature into 2.7
and add a deprecation warning for your least favorite Python 2
misfeature, 


Just run with the -3 flag for warnings.

Also see my response to Glyph.

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] 2.7 Release? 2.7 == last of the 2.x line?

[Terry Reedy]

Glyph Lefkowitz wrote:

For what it's worth, the official position of the Twisted project is not 
that we have "no plan" to move to Python 3.  It's that our plan is to do 
exactly as Raymond suggests, and give the users a vote - in this case, 
you vote with your patches :).


You probably will not hear from potential users who skip Twisted because 
it is not available for 3.x. I suspect you do not hear much either from 
new users who only installed 2.x to use Twisted, but would prefer 3.x. 
There are regular questions on python-list about 'web programming with 
3.0' or some such.


For one thing, we have a very long row to hoe here.  The migration to 
3.0 is a long, tedious process with little tangible benefit.


One group that benefits is new Python programmers. Python 3 is easier to 
learn, and is being used to teach Python in at least some schools and 
universities, and will be used more as more libraries are available. 
Hardly a week goes by on Python list without someone posting a problem 
using 2.x that has been solved in 3.x.


Another group is existing programmers who were/are sufficiently annoyed 
by some of the things that got cleaned up.


A third group is people who want to use non-ascii in identifiers, and 
who are delighted now that they can.


Since you do not fall in these groups, I understand your impatience and 
reluctance with the change. I can also imagine that Twisted may be more 
affected by some of the changes than most other projects.


[snip more] ...

There have been some other comments in this thread indicating that this 
was not the case because some users indicated that they'd rather deal 
with lots of changes "all at once".


I wrote that based on both my reading of clp/pylist posts during the 
discussion of the int/int semantic change and Guido's report of private 
conversations he had had.


> My understanding is that it was
done this way so that the *developers* of Python could make a clean 
break, and design and implement a new version of Python without being 
constrained by compatibility concerns.


I do not believe that was ever intended. It certainly is not what 
happened; many changes were not made *because* of compatibility concerns 
and all went through the filter of 'is the benefit of this change worth 
the pain of breakage'. There is a big difference between not being 
straightjacketed and being unconstrained.


> If you can show me an actual
application or library developer in Python who wanted this one-big-jump 
migration, I will show you a crazy person.


Be careful of labels.

Once the prolonged and intense int/int debate shifted from the ontology 
of ints to the pragmatics of the proposed change, most people agreed 
that int/int 'should' have meant float(int)/float(int) from the 
beginning. But some were still strongly opposed to making the change 
because they (understandably) did not want to have to scan (by eye) 
possibly 1s or even 10s of lines for every a/b to determine 
whether any fix was needed. Some said that that would be such a major 
change that it should not be done until there was a new major release, a 
Python 3 off in the then distant future.  Well, that future is now.


I half-jokingly suggested that the change be made on Guido's original
timetable, but that the '2.5' that completed the change simply be 
relabeled '3.0'. I personally would have preferred that it had been 
completed in 2.5. But that did not happen and more changes were made 
once they were made, and here we are.


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] 2.7 Release? 2.7 == last of the 2.x line?

[Floris Bruynooghe]

On Wed, Nov 04, 2009 at 03:54:44PM -0700, Zooko O'Whielacronx wrote:
> It occurred to me to wonder why I haven't investigated how hard it
> would be to make my Python packages Python-3-compatible.  That's right
> -- I haven't even looked closely.  I couldn't even tell you off the
> top of my head what is in Python 3 that I would have to think about
> except for the new unicode regime.  I think the answer is that the
> payoff is just *so* low to me at this point that it doesn't even
> justify me taking 15 minutes to read "What's New In Python 3" or to
> execute 2to3 on my smallest package and see what it does.



You have time to read this thread but no time to read "What's New In
Python 3"?



Personally I found porting to Python 3 a rather pleasant experience
(include C extension module).  I can't wait until I can drop support
for Python 2.2-2.X.

Regards
Floris

PS: I have to admit that the commerial code base I work on is still at
Python 2.5, but that doesn't make me worry in any way.  It'll get to
Python 3 in time (it's running on 2.6 already in development).

-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.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?

[Paul Moore]

2009/11/4 Zooko O'Whielacronx :
> On the other hand, I'm totally committed to supporting Python 2.7,
> because my customers will demand it and because I expect that it will
> be easy.

Why do you think your customers will demand 2.7 support but not 3.1
support? If I were one of your customers, I'd want 3.1 support...

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?

[Zooko O'Whielacronx]

Folks:

It occurred to me to wonder why I haven't investigated how hard it
would be to make my Python packages Python-3-compatible.  That's right
-- I haven't even looked closely.  I couldn't even tell you off the
top of my head what is in Python 3 that I would have to think about
except for the new unicode regime.  I think the answer is that the
payoff is just *so* low to me at this point that it doesn't even
justify me taking 15 minutes to read "What's New In Python 3" or to
execute 2to3 on my smallest package and see what it does.

On the other hand, I'm totally committed to supporting Python 2.7,
because my customers will demand it and because I expect that it will
be easy.

So, if you guys slip in your favorite new Python 3 feature into 2.7
and add a deprecation warning for your least favorite Python 2
misfeature, then probably within about 24 months I'll have fixed all
code that uses the deprecated feature, and probably within about five
years I'll consider dropping backwards-compatibility with Python 2.6
and starting to use that new feature that you added to Python 2.7.

(I'm currently considering dropping Python 2.4 compatibility for the
next releases of most of my code.)

Regards,

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

[Brett Cannon]

On Wed, Nov 4, 2009 at 10:20, sstein...@gmail.com  wrote:
>
> On Nov 4, 2009, at 1:06 AM, Lennart Regebro wrote:
>
>> 2009/11/3 sstein...@gmail.com :
>>>
>>> On Nov 2, 2009, at 7:26 PM, James Y Knight wrote:

 It really sounds like you're saying that switching to 3.x isn't worth
 the
 cost to you, but you want to force people (including yourself) to do so
 anyways, because ...?
>>>
>>> Because that's the future of Python
>>
>> Or not. Maybe it's a dead branch of Python?
>
> Maybe the 3.x line should just be put out of our misery, merged back to 2.7,
> 2.8, 2.9, and proceed as Glyph suggested in passing with increasing levels
> of deprecation until it just turns into 3.x on its own by running out of
> numbers.
>

I am going to say this once: we are not killing off Python 3.

First off, Python 3 is not even a year old! Considering people have
not fully migrated to 2.6, should we kill it off as well? There is a
certain lack of perspective on time scale. This is especially true
when Guido himself has said on multiple occasions that moving the
community to 3.x would be a mult-year process, as in 3-5 years
process, not 11 months.

Second, the people calling for us to potentially kill 3.x and just
keep 2.x floating along have yet to say that they have tried porting
their code and that it was difficult. Every person who has stepped
forward stating they have done a port has said it was actually
relatively straight-forward. Not only that, we have anecdotal evidence
from multiple people that you can support code way back to whatever
old version of Python RHEL is running.

Third, the same people calling for the death of 3.x have not suggested
they have used it extensively (if at all). I have yet to hear anyone
say that 3.x is not at least a nice improvement, if not a huge one. I
for one find 3.x more enjoyable to work in than 2.x, and that's saying
a lot since I obviously loved Python 2.x enough to get involved in its
development. I have also never heard anyone ever say, "I gave 3.x a
fair shake and honestly, I wish I had not wasted the time." Wait until
3to2 gets to a good state (which will happen; it's my next project --
after I either get us moved to Hg or I simply give up on it -- and I
know I am not the only core developer planning on making it happen).

I realize that there is some fear that it will be time wasted if
people port their code to 3.x if it somehow burns out. But do you
honestly think that python-dev would leave you hanging like that?
Let's take a worst-case scenario here and say that direct pick-up of
3.x after a couple years never happens. Fine, we then begin to
backport features. But if you already ported your code then chances
are you already support the new features. And you know what one of the
first things we would back port would be? Unicode strings and bytes.
And since that is the hardest thing to port to, you will have not
wasted any time.

In other words the calling for the death of 3.x is rather premature
and honestly unfair until people have actually tried to port their
code in earnest and it has been a couple of years for the community to
catch up to what python-dev is pushing out the door (which always
takes a while no matter what minor version has been released).

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

[Martin v. Löwis]

>> That's not my experience. I see a change in source (say, on Django)
>> available for 3.x within 5 seconds.
> 
> This is for which version of 2to3 ? I got similar experience (several
> minutes), but maybe I am using 2to3 the wrong way. On my machine, with
> 2to3 from 3.1.1, it takes ~ 1s to convert one single file of 200
> lines, and converting a tiny subset of numpy takes > one minute.

The version released with 3.1. The trick is not to recompile all 2to3
code every time you make a source change. Instead, cache the 2to3 output
in the build area, and have setup.py only invoke 2to3 for the files
that got modified.

So whenever I make a change, I do "python3 setup.py install". This
checks all timestamps, finds the modified files (which will only be
one), runs 2to3 on it, and then copies it into my 3.1 installation,
where I can test the change. Recompiling a single file typically takes a
few seconds, or less. It would be possible to also run out of the build
area; you still would need to run "setup.py build" after every change.

There is already support for this in both distutils (as released in
3.1), and distribute.

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?

[Mike Krell]

On Wed, Nov 4, 2009 at 12:02 PM, "Martin v. Löwis" wrote:


> > The main reason I want a long 2.x series is that I believe it would more
> > easily allow us infrastructure folks to drop support for *older*
> > versions.  With this big 2.x->3.x chasm, I can't really see an end in
> > sight for Twisted using Python 2.x as its _source_ language, translating
> > with 2to3.
>
> Well, 3to2 would then be an option for you: use Python 3 as the source
> language.
>

A migration path which would be made all the more compelling with the
addition of the nonlocal keyword to 2.7 ;-)

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?

[David Cournapeau]

On Thu, Nov 5, 2009 at 4:02 AM, "Martin v. Löwis"  wrote:

>
> That's not my experience. I see a change in source (say, on Django)
> available for 3.x within 5 seconds.

This is for which version of 2to3 ? I got similar experience (several
minutes), but maybe I am using 2to3 the wrong way. On my machine, with
2to3 from 3.1.1, it takes ~ 1s to convert one single file of 200
lines, and converting a tiny subset of numpy takes > one minute.

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?

[sstein...@gmail.com]

On Nov 4, 2009, at 1:39 PM, Carl Trachte wrote:


On 11/4/09, sstein...@gmail.com  wrote:


Maybe the 3.x line should just be put out of our misery, merged back
to 2.7, 2.8, 2.9, and proceed as Glyph suggested in passing with
increasing levels of deprecation until it just turns into 3.x on its
own by running out of numbers.



As a user, I'm horrified.  Granted, I'm not the most high powered
user, but . . .
my employer is already providing me with a 3.0 Python version on one
of my work computers with the expectation that I'll be using it more
and more.

Sorry to butt in, but is this a joke?  I thought all this was hashed
out prior to inventing python 3.0.


Yes, of course it was a joke.

2.7 won't "turn into" Python 3.x any more that Perl will turn into Ruby.

Oh, wait, maybe that was a bad example.

The point was, that Python 3.x does not seem to be something that can  
be "evolved" into and, all along, I have been suggesting that, if  
Python 3.x is the future, let's let 2.7 be the last of the 2.x series,  
backport whatever will make it easiest to make 2to3 do as much of the  
work as possible, and just decide that 2.7 is the end of the line.


I shudder to think how much time has been spent hacking things around  
to make them compatible with the 2.x series while trying to move to 3.x.


If 2.x is over, let it be over and let's all focus on moving into  
Python 3.x with no more time doing other than bug-fixes on 2.x  
versions of things.


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?

[Martin v. Löwis]

> For one thing, we have a very long row to hoe here.  The migration to
> 3.0 is a long, tedious process with little tangible benefit.  I hope
> that sometime in the next decade Twisted can accelerate the process of
> dropping old 2.x versions, but I seriously doubt we could do a
> feature-complete 3.1/2.6 version.  I get the general impression that a
> 3.2/2.7 port would be more feasible; hopefully a 3.3/2.8 would be even
> moreso.

Please understand that you will not need to drop 2.x versions in order
to support 3.x. Just add 3.x support now and make sure it won't break
2.x support.

> Also, the benefits of migrating to python 3.x are still negligible, as
> far as I can tell.

For Twisted, most definitely - you will need to support 2.x and 3.x
simultaneously, so you can't really benefit from 3.x-only changes
for a long time to come - perhaps until a 3to2 tool has a good quality,
and probably not even then (since it will restrict you what you can
do in 3.x code).

> On the other hand, you've got NumPy, PyGTK, Unladen Swallow,
> PyPy, Jython, IronPython, and so on and so forth.  Since I started using
> it, the strength of Python has been in its ecosystem, and the 3.x
> ecosystem is not yet viable.

Right - the advantages wouldn't be for Twisted itself, but for users
of Twisted, which would see a larger ecosystem if Twisted was available.

> The main reason I want a long 2.x series is that I believe it would more
> easily allow us infrastructure folks to drop support for *older*
> versions.  With this big 2.x->3.x chasm, I can't really see an end in
> sight for Twisted using Python 2.x as its _source_ language, translating
> with 2to3.

Well, 3to2 would then be an option for you: use Python 3 as the source
language.

> Some projects which depend on Twisted and want new versions
> (and security fixes, etc) are going to want Python 2.x for a really long
> time.  Maybe they're just really conservative, maybe they don't have a
> lot of maintenance energy, or maybe they have other dependencies which
> haven't got a port; it doesn't really matter, empirically speaking
> people want older versions of Python.

But wouldn't these applications also break as Twisted drops support
for old 2.x versions, and the applications fail to work on the newer
2.x version (say, 2.34)?

> Keep in mind also that the 2.x translation process is extremely slow and
> results in a clunky development process.  There's no '2to3
> --interactive' commandline that lets me type python 2 at a >>> prompt
> and get python 3 results out so that I can try experiments on the 3.x
> interpreter; I have to actually put my experiments into my unit tests
> and wait 10 minutes to see if it works.  It's like writing C++.

That's not my experience. I see a change in source (say, on Django)
available for 3.x within 5 seconds.

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?

[Martin v. Löwis]

Antoine Pitrou wrote:
> 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.

That's not strictly true, see

http://svn.zope.org/zope.interface/branches/regebro-python3/

While this isn't released yet, Lennart and myself have been working
to make it work on 2.x and 3.x. So porting activities *could* start
now (requiring 3.x user to use that branch).

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?

[Guido van Rossum]

On Wed, Nov 4, 2009 at 10:39 AM, Carl Trachte  wrote:
> On 11/4/09, sstein...@gmail.com  wrote:
>
>> Maybe the 3.x line should just be put out of our misery, merged back
>> to 2.7, 2.8, 2.9, and proceed as Glyph suggested in passing with
>> increasing levels of deprecation until it just turns into 3.x on its
>> own by running out of numbers.
>
> 
> As a user, I'm horrified.  Granted, I'm not the most high powered
> user, but . . .
> my employer is already providing me with a 3.0 Python version on one
> of my work computers with the expectation that I'll be using it more
> and more.
>
> Sorry to butt in, but is this a joke?  I thought all this was hashed
> out prior to inventing python 3.0.
> 

I have no idea who "ssteinerX" is. He certainly doesn't speak for the
core developers.

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

[Arc Riley]

That's not going to happen.  Stop trolling the python-dev list.

On Wed, Nov 4, 2009 at 1:20 PM, sstein...@gmail.com wrote:

> Maybe the 3.x line should just be put out of our misery, merged back to
> 2.7, 2.8, 2.9, and proceed as Glyph suggested in passing with increasing
> levels of deprecation until it just turns into 3.x on its own by running out
> of numbers.
>
>
___
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?

[Carl Trachte]

On 11/4/09, sstein...@gmail.com  wrote:

> Maybe the 3.x line should just be put out of our misery, merged back
> to 2.7, 2.8, 2.9, and proceed as Glyph suggested in passing with
> increasing levels of deprecation until it just turns into 3.x on its
> own by running out of numbers.


As a user, I'm horrified.  Granted, I'm not the most high powered
user, but . . .
my employer is already providing me with a 3.0 Python version on one
of my work computers with the expectation that I'll be using it more
and more.

Sorry to butt in, but is this a joke?  I thought all this was hashed
out prior to inventing python 3.0.

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

On Nov 4, 2009, at 1:06 AM, Lennart Regebro wrote:


2009/11/3 sstein...@gmail.com :


On Nov 2, 2009, at 7:26 PM, James Y Knight wrote:


It really sounds like you're saying that switching to 3.x isn't  
worth the
cost to you, but you want to force people (including yourself) to  
do so

anyways, because ...?


Because that's the future of Python


Or not. Maybe it's a dead branch of Python?


Maybe the 3.x line should just be put out of our misery, merged back  
to 2.7, 2.8, 2.9, and proceed as Glyph suggested in passing with  
increasing levels of deprecation until it just turns into 3.x on its  
own by running out of numbers.


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?

[P.J. Eby]

At 12:51 AM 11/4/2009 -0500, Glyph Lefkowitz wrote:

With the 2.x series, users and operating systems seem to move on
fairly rapidly, because dependencies generally continue to work if you
upgrade just one version.  This isn't quite as formal a requirement as
I would like (warnings get generated, unit tests fail, things do
break) but in practice, users can rely on it for most functionality.
If 3.x could be broken into a series of transitions like that, where
you can upgrade one version, fix some stuff, then upgrade another
version, even if you couldn't actually support more than 2 versions at
once, I think that we could pick up the migration pace to the point
where we might actually be using 3.x syntax in a few years.  Having a
2.x series which goes to 2.9 and then stops isn't *quite* the same
thing as having one that moves over continuously to some 3.x version,
but it does seem to me that by that point the chasm between versions
will have narrowed to a crack, and the migration will be a little hop
over it rather than the currently-required great flying leap.


+1 (I actually thought this was the original plan.)

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

[Guido van Rossum]

On Tue, Nov 3, 2009 at 9:51 PM, Glyph Lefkowitz
 wrote (amongst way too many words):
> [...] For example, 2.8 could emit a deprecation
> warning for every old-style class that was defined, 2.9 could emit a
> deprecation warning for every string constant declared without a 'b' or 'u'
> prefix unless the module in question were in "3.x mode" (i.e. no-prefix ==
> 'u').

This proposal is hopelessly naive. It has been considered seriously
from all possible sides before, and there just isn't a way to make
this work. Not even with several releases as stepping points.

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

[Mark Summerfield]

Hi,

I wanted to make some brief comments on this thread:

- 2to3 encourages people to see Python 3 as exotic and other---and not
  to actually write in it.

- 3to2 encourages people to use Python 3 and also provides a route to
  Python 2 compatibility.

I hope that a point will be reached where people are encouraged to do a
one off 2to3, hand fix, and once it passes their tests to keep a single
Python 3 source and use 3to2 to support their users of older Pythons.

- Unicode strings is the solution, not the problem, and is one of Python
  3's most important advances.

- Have any big ports been done? Yes, PyQt4.
  PyQt4 supports both Python 2 and Python 3---and the port was done by
  one person in his "spare" time over a period of months. PyQt4 wraps at
  least 700,000 lines of C++ code---and it isn't just GUI stuff, it has
  networking, threading, etc., and works on Linux, Mac, Windows, etc.

- I do hope NumPy gets ported, since both on and off the lists it seems
  like a show-stopper for many people.

- I hope the "ditch 3" calls are ignored. Python 3 is significantly
  better than (an already excellent) Python 2: eventually people will
  port---or those who start out with Python 3 will build their own
  libraries for what's missing, just as people did when Python 2 came
  out.

- I think the developers have done a fantastic job with Python 3.
  I just wish more people realised how good it is!

Regarding the Moratorium:

+inf

since I'd really love to see more time devoted to improving the standard
library.

My 2c:-)

-- 
Mark Summerfield, Qtrac Ltd, www.qtrac.eu
C++, Python, Qt, PyQt - training and consultancy
"Advanced Qt Programming" - ISBN 0321635906
___
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?

[Nick Coghlan]

Terry Reedy wrote:
> 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.

The pure Python io module was already backported for the 2.6 release
[1], as was the C API aspect of PEP 3118 [2].

Short float repr has since been backported for 2.7, as has the C
accelerated io module implementation and the Python API (memoryview)
aspect of PEP 3118.

I believe those 3 features alone are more than enough justification to
proceed with at least a 2.7 release (that is probably the point Eric was
making in posting that list of features in the first place).

As to how those backports can help with forward ports to Py3k, someone
made the point elsewhere in the thread that testing/experimenting via
2to3 is a very C++ like development cycle - there is a long build time
before you get to see the results of running a test. With features
backported to 2.x, you can instead use more traditional version checks
(or the interactive prompt) and get the usual quick feedback cycle via
the 2.7 version, before submitting your code to the tender mercies of
the 2to3 converter (or possibly avoid 2to3 altogether if the version
checks turn out to suffice for a given use case).

Cheers,
Nick.

[1] http://docs.python.org/whatsnew/2.6.html#pep-3116-new-i-o-library
[2]
http://docs.python.org/whatsnew/2.6.html#pep-3118-revised-buffer-protocol

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

[Paul Moore]

2009/11/4 Glyph Lefkowitz :
> On Nov 3, 2009, at 5:16 PM, Paul Moore wrote:
>>
>> 2009/11/3 Brett Cannon :
>>>
>>> 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.
>
>> 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
>
>
> Speaking of FUD, we've had a plan for Python 3 support for some time:
[...]

Thanks, and my sincere apologies for spreading FUD - I did try to find
details, and in fact I did spot a couple of the specific python 3
compatibility tickets you mentioned, but missed the link back to the
master plan.

Having said that,

>  http://stackoverflow.com/questions/172306/how-are-you-planning-on-handling-the-migration-to-python-3/214601#214601

seems pretty negative in terms of when Twisted will support Python 3.
Based on my reading, the focus is more on when 2.x support will be
dropped than on when there will be a version of Twisted which works
with Python 3 (which I'd expect to be much sooner!)

> If you're interested in helping, our core team has all not had much time for
> Twisted lately and we need volunteers who are interested in doing code
> reviews and becoming a committer to help shepherd these tickets through the
> process.

Personally, I don't *use* twisted. I occasionally play with it, and I
sometimes end up using applications which rely on it, but I don't use
it myself. So I couldn't be much direct help. (And yes, I know that
means I'm not one of your users, so me asking for Python 3 support
isn't an issue. No problem there).

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?

[Arc Riley]

I'm not aware of any currently active project that isn't in the process of
adding Py3 support (or who has already done so).  By "most maintainers" I'm
referring to the long tail; the hundreds of 3rd party modules used in niche
cases and can be easily replaced by those who need the functionality they
provide.

Free software is an evolutionary process.  Evolution dictates that those who
cannot adapt will die when faced with a changing environment.  It's better
for us all that they do.

Thus, I am not attempting to persuade anyone to upgrade their package,
rather, I'm explaining why it's best we ignore them and get on with doing
productive work.

On Tue, Nov 3, 2009 at 4:05 PM, Mike Klaas  wrote:

>
> 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/arcriley%40gmail.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?

[Lennart Regebro]

2009/11/3 Charles Cazabon :
> "Martin v. Löwis"  wrote:
>  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.

Without using 2to3, yes.

See http://code.google.com/p/python-incompatibility/ where I've
attempted to document most 2.5/3.0 incompatibilities and explain how
to get around them to run the same unmodified code under 2.6 and 3.0.

(It's not complete, help appreciated, especially with the C-API part)

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

Then it's going to be dead easy to support both 2.x and 3.x by using 2to3.

If you don't want to have separate packages youcan use distribute:
http://packages.python.org/distribute/python3.html

Also see my talk at PyCon: http://pycon.blip.tv/file/1949281/

-- 
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64
___
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?

[Lennart Regebro]

2009/11/3 Paul Moore :
> Has that port been integrated back into the zodb project?

That is on the way. Setuptools has been ported via the distribute
project, I'm hoping to make a test release of the zope.interface
branch (to test Python 2 compatibility mainly) soon, and then
hopefully merge it, etc.

It's slow, but moving.

-- 
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64
___
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]

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

However, you don't have to make that choice. You can support 2.4 and 3.x
simultaneously; IMO, any simplification resulting from possible
backports is really minor compared to the rest of the work that you
would have to do, anyway.

For example, porting to the new buffer interface is may be difficult
and/or a lot of work, and you'll have to do it, anyway. Making it then
conditional (with preprocessor statements), and maintaining both APIs
in parallel for some time, is really not that hard, 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] 2.7 Release? 2.7 == last of the 2.x line?

[Lennart Regebro]

2009/11/3 sstein...@gmail.com :
>
> On Nov 2, 2009, at 7:26 PM, James Y Knight wrote:
>>
>> It really sounds like you're saying that switching to 3.x isn't worth the
>> cost to you, but you want to force people (including yourself) to do so
>> anyways, because ...?
>
> Because that's the future of Python

Or not. Maybe it's a dead branch of Python?

-- 
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64
___
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?

[Lennart Regebro]

2009/11/3 sstein...@gmail.com :
> Not that anyone has asked yet, but here's my opinion on two issues that have
> been raised on the python-dev mailing list lately:
>
>        +1 on 2.7 release with as much 3.0 "easy-port goo" as is practicable
> without delaying the product beyond the tentative schedule.  Sooner would,
> of course, be better but I'm sure PEP 373 was produced after due
> consideration of all pertinent factors.

+1

>        +1 on 2.7 being the last of the 2.x series.  Enough already!

-1

The last of the series should be the last one needed, and we don't
know that until after it's been made. No official decision should be
taken on this.

> I, personally, haven't even written my first line of 3.x code, nor have I
> had any good reason to.
>
> If I saw the actual end of the line at 2.7, I would actually start looking
> for 3.x versions of my favorite tools and would be much more inclined to
> help push them along ASAP.

That's a terrible reason. It's a stick, and sticks suck. If Python 3
is not enough of a carrot, then people should not migrate at all.

> Right now, so much that I use on a daily basis doesn't even have a 3.x
> roadmap, much less any sort of working implementation, that I don't see
> switching to 3.x ever unless the 2.x line ends, and soon!

Wrong. Most things do not have a 3.x roadmap or a working
implementation, because most things depend on another thing, that also
doesn't have an implementation, and therefore can't be ported or
planned. The major hangup for this has been setuptools. As you know,
distribute came with a Python 3 release fairly recently, which means
that most projects out there could not be ported or even planned (as
setuptools had no Python 3 plans) until something like a month ago.

-- 
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64
___
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?

[Glyph Lefkowitz]

On Nov 3, 2009, at 6:23 AM, Paul Moore wrote:


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.



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.


For what it's worth, the official position of the Twisted project is  
not that we have "no plan" to move to Python 3.  It's that our plan is  
to do exactly as Raymond suggests, and give the users a vote - in this  
case, you vote with your patches :).


We are actively and frequently encouraging our users to contribute  
patches that clean up warnings, which is the biggest impediment to a  
py3 port of Twisted.  Some of you would probably expecting to whinge  
about how people never contribute anything, but actually, users *have*  
shown up and started doing this.  Our biggest problem at the moment is  
that we don't have enough people doing code reviews so the  
contributions are starting to pile up.  As I said in my other message,  
if someone would like to help, signing up to do code reviews would be  
a good way.


Despite this progress, my hope is that there will be a robust 2.x  
series up through 2.9.


For one thing, we have a very long row to hoe here.  The migration to  
3.0 is a long, tedious process with little tangible benefit.  I hope  
that sometime in the next decade Twisted can accelerate the process of  
dropping old 2.x versions, but I seriously doubt we could do a feature- 
complete 3.1/2.6 version.  I get the general impression that a 3.2/2.7  
port would be more feasible; hopefully a 3.3/2.8 would be even moreso.


Also, the benefits of migrating to python 3.x are still negligible, as  
far as I can tell.  On the one hand, you've got a Python with no old- 
style classes and a clear unicode/bytes situation, and that's great.   
On the other hand, you've got NumPy, PyGTK, Unladen Swallow, PyPy,  
Jython, IronPython, and so on and so forth.  Since I started using it,  
the strength of Python has been in its ecosystem, and the 3.x  
ecosystem is not yet viable.


As long as we're tossing out modest proposals here, I still think that  
(as I believe James Knight already proposed) abandoning the current  
3.x branch, backporting everything to 2.7, and continuing forward with  
a migration strategy that introduces individual deprecations every  
major version until 2.x == 3.x is the way to go.  For example, 2.8  
could emit a deprecation warning for every old-style class that was  
defined, 2.9 could emit a deprecation warning for every string  
constant declared without a 'b' or 'u' prefix unless the module in  
question were in "3.x mode" (i.e. no-prefix == 'u').  (I leave the  
determination of whether the parser should be in 3.x mode for a  
particular module as an exercise for the reader, but a 'from  
__future__' import would suffice.)


I realize that there are other issues here, like the C ABI changes  
some NumPy folks have raised.  Also, I'm not planning to actually do  
any *work* on this suggestion, so you can take it for what it is,  
which is to say, armchair quarterbacking.


There have been some other comments in this thread indicating that  
this was not the case because some users indicated that they'd rather  
deal with lots of changes "all at once".  My understanding is that it  
was done this way so that the *developers* of Python could make a  
clean break, and design and implement a new version of Python without  
being constrained by compatibility concerns.  If you can show me an  
actual application or library developer in Python who wanted this one- 
big-jump migration, I will show you a crazy person.


The main reason I want a long 2.x series is that I believe it would  
more easily allow us infrastructure folks to drop support for *older*  
versions.  With this big 2.x->3.x chasm, I can't really see an end in  
sight for Twisted using Python 2.x as its _source_ language,  
translating with 2to3.  Some projects which depend on Twisted and want  
new versions (and security fixes, etc) are going to want Python 2.x  
for a really long time.  Maybe they're just really conservative, maybe  
they don't have a lot of maintenance energy, or maybe they have other  
dependencies which haven't got a port; it doesn't really matter,  
empirically speaking people want older versions of Python.


Keep in mind also that the 2.x translation process is extremely slow  
and results in a clunky development pro

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

[Glyph Lefkowitz]

On Nov 3, 2009, at 5:16 PM, Paul Moore wrote:

2009/11/3 Brett Cannon :

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.



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



Speaking of FUD, we've had a plan for Python 3 support for some time:

http://twistedmatrix.com/trac/ticket/2484

http://stackoverflow.com/questions/172306/how-are-you-planning-on-handling-the-migration-to-python-3/214601#214601

Not only that, but progress is actually being made on that plan, as it  
is being slowly executed by contributors from the community, a  
sampling of which you can see on these tickets, linked from the bottom  
of the "master plan" ticket I mentioned above (#2484):


http://twistedmatrix.com/trac/ticket/4053
http://twistedmatrix.com/trac/ticket/4065
http://twistedmatrix.com/trac/ticket/4066

If you're interested in helping, our core team has all not had much  
time for Twisted lately and we need volunteers who are interested in  
doing code reviews and becoming a committer to help shepherd these  
tickets through the process.

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

[Steven Bethard]

On Tue, Nov 3, 2009 at 6:14 AM, Daniel Stutzbach
 wrote:
> 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.

This keeps getting quoted later in the thread so I just wanted to say
again that this is not true. The argparse module supports Python
2.3-3.1 all from the same codebase, and it really wasn't all that
hard:

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

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?

[geremy condra]

On Tue, Nov 3, 2009 at 6: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.
>

Interesting- I've been doing crypto in python 3 for quite some time and
haven't had any issues except with getting things to play nicely with
C. Any specific examples?

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?

[Guido van Rossum]

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?

[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] 2.7 Release? 2.7 == last of the 2.x line?

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

[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] 2.7 Release? 2.7 == last of the 2.x line?

[sstein...@gmail.com]

On Nov 3, 2009, at 1:42 PM, 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.


Yah, me neither, but the other two are still cool in my book ;-)

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]

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] 2.7 Release? 2.7 == last of the 2.x line?

[Andrew McNabb]

On Tue, Nov 03, 2009 at 12:28:47PM -0500, 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.

The main reason the package maintainers are so "lazy and/or obstinate"
is that Python 2 is much more available than Python 3.  For example,
work is being completed on a python3 RPM, but it will first appear in
Fedora 13, not Fedora 12.  RHEL is still using Python 2.4 and won't even
get Python 2.6 until RHEL 6 comes out.  I don't think it's worth
worrying about packages being upgraded to Python 3 when many or most
users still don't have access to Python 3.

In my opinion, the best place for current efforts is on infrastructure:

1) Python 3 packages for all Linux distributions (I've recently been
involved with bringing Python 3 to Fedora)

2) WSGI/mod_python, etc.: according to
http://wsgi.org/wsgi/Amendments_1.0 and various blog posts, the WSGI
standard isn't defined for Python 3 yet, and the modwsgi page at
http://code.google.com/p/modwsgi/ does not yet list a Python 3 release.

3) Numpy/scipy: as others have mentioned, numpy is essential for
scientific work, and apparently the project needs help to add support
for Python 3

Before basic infrastructure is available for Python 3, it's absurd to
expect package maintainers to flock to it.

-- 
Andrew McNabb
http://www.mcnabbs.org/andrew/
PGP Fingerprint: 8A17 B57C 6879 1863 DE55  8012 AB4D 6098 8826 6868
___
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?

[Paul Moore]

2009/11/3 Brett Cannon :
> 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.

Sadly, what I've heard a lot of is people (projects) saying that they
*won't* try a port (yet, for the forseeable future, take your pick)
because they *expect* it to be difficult. The worst thing is that even
Martin's (and probably others') efforts in actually producing ports,
and demonstrating that it's not difficult, don't seem to be changing
minds.

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
wxPython - no mention of Python 3
numpy - no plans yet for Python 3
pyQt - supports Python 3
cx_Oracle - supports Python 3
pywin32 - supports Python 3
pygame - python 3 support "mostly completed"
Django - not yet, FAQ suggests it will be "a year or two"
TurboGears - Python 3 "currently unsupported", no timescale given
PIL - 1.1.7 (due very soon) supports Python 3
lxml - supports Python 3
pyCrypto - doesn't appear to support Python 3 yet
gmpy - 1.10 beta supports Python 3
pyYaml - supports Python 3
mod_wsgi - 3.0 RC 5 supports Python 3 (but see below)

Here, "supports Python 3" either means that explicit support is
mentioned on the website, or Windows binaries exist. I guess there's
also some pure python code that "might work", possibly only requiring
testing to confirm this.

That's a lot better picture than I expected. How come this message
isn't getting across? I suspect the big answer is that there's no web
framework (that I'm aware of) which works with Python 3 - mod_wsgi
supports Python 3, but from what I've seen on web-sig, the WSGI
picture for Python 3 is unclear, to say the least.

It seems to me that Python 3 adoption is pretty healthy, at least in
these terms. If a credible Python 3 web development framework appeared
(ie, one of the "big ones" got a port done) things would start to be
in pretty good shape.

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?

[Guido van Rossum]

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?

[Georg Brandl]

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

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

[Terry Reedy]

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.


tjr

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

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

But that's a completely different statement. "make code that works on
both 2.x and 3.x" is *entirely* different from "make code written for
2.x also run on 3.x". The latter is less constrained: to run it on 3.x,
you can convert it to 3.x first, using 2to3. So it would not be the
*same* code that runs, but you can have single source code for both
2.x and 3.x - only that what you run is not literally the source code.

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

No no no. Daniels comment is correct, in that you can't run the code
*unmodified*. However, it is well possible to have a single code base
for both 2.x and 3.x - you just don't *run* the code on 3.x (but convert
it first, e.g. at installation time).

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

And I wouldn't say that. Instead, I say "support both 2.x and 3.x from a
single code base". That approach can work for supporting everything from
2.3 to 3.2 (perhaps even from 2.0 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?

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

[sstein...@gmail.com]

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?

[Georg Brandl]

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?

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

[Georg Brandl]

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] 2.7 Release? 2.7 == last of the 2.x line?

[Guido van Rossum]

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?

[Martin v. Löwis]

 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?

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

[Martin v. Löwis]

>> 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] 2.7 Release? 2.7 == last of the 2.x line?

[sstein...@gmail.com]

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?

[Martin v. Löwis]

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

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

[sstein...@gmail.com]

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?

[Martin v. Löwis]

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

[Barry Warsaw]

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?

[Guido van Rossum]

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?

[Georg Brandl]

s...@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.

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?

[Martin v. Löwis]

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

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

[Georg Brandl]

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?

[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] 2.7 Release? 2.7 == last of the 2.x line?

[sstein...@gmail.com]

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?

[Martin v. Löwis]

>> 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] 2.7 Release? 2.7 == last of the 2.x line?

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

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?

[Martin v. Löwis]

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

[Martin v. Löwis]

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

[Antoine Pitrou]

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?

[Georg Brandl]

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?

[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] 2.7 Release? 2.7 == last of the 2.x line?

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

[Martin v. Löwis]

> 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] 2.7 Release? 2.7 == last of the 2.x line?

[sstein...@gmail.com]

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?

[sstein...@gmail.com]

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?

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

[Arc Riley]

+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.
___
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?

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

[Antoine Pitrou]

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?

[Antoine Pitrou]

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] 2.7 Release? 2.7 == last of the 2.x line?

[Guido van Rossum]

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

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

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

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

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

[Guido van Rossum]

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?

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

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

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

[Antoine Pitrou]

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?

[sstein...@gmail.com]

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