headers
Benjamin Peterson | 3 Oct 23:22
Gravatar

for __future__ import planning

So now that we've released 2.6 and are working hard on shepherding 3.0
out the door, it's time to worry about the next set of releases. :)

I propose that we dramatically shorten our release cycle for 2.7/3.1
to roughly a year and put a strong focus stabilizing all the new
goodies we included in the last release(s). In the 3.x branch, we
should continue to solidify the new code and features that were
introduced. One 2.7's main objectives should be binding 3.x and 2.x
ever closer.

--

-- 
Cheers,
Benjamin Peterson
"There's nothing quite as beautiful as an oboe... except a chicken
stuck in a vacuum cleaner."
_______________________________________________
Python-Dev mailing list
Python-Dev <at> python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org
Permalink | Reply |
headers
Christian Heimes | 4 Oct 00:00
Favicon

Re: for __future__ import planning

Benjamin Peterson wrote:
> I propose that we dramatically shorten our release cycle for 2.7/3.1
> to roughly a year and put a strong focus stabilizing all the new
> goodies we included in the last release(s). In the 3.x branch, we
> should continue to solidify the new code and features that were
> introduced. One 2.7's main objectives should be binding 3.x and 2.x
> ever closer.

Hey! That was my idea! I told you the very same idea on IRC a week ago. 
Shame on you!

:)

I'm +1 on the proposal. Let's focus on stability and performance for the 
next release. But before we start planning the next release we need to 
find a way to sync the development.
Soon we have to apply fixes to up to four (again FOUR) branches: 2.6, 
2.7, 3.0 and 3.1. We don't have to merge as many code as we did during 
the py3k phase. But it's still lots of work and we need all the 
(technical) help we can get.

Christian
_______________________________________________
Python-Dev mailing list
Python-Dev <at> python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org
Permalink | Reply |
headers
Barry Warsaw | 4 Oct 00:56
Favicon

Re: for __future__ import planning


On Oct 3, 2008, at 5:26 PM, Benjamin Peterson wrote:

> So now that we've released 2.6 and are working hard on shepherding 3.0
> out the door, it's time to worry about the next set of releases. :)
>
> I propose that we dramatically shorten our release cycle for 2.7/3.1
> to roughly a year and put a strong focus stabilizing all the new
> goodies we included in the last release(s). In the 3.x branch, we
> should continue to solidify the new code and features that were
> introduced. One 2.7's main objectives should be binding 3.x and 2.x
> ever closer.

There are several things that I would like to see us concentrate on  
after the 3.0 release.  I agree that 3.1 should be primarily a  
stabilizing release.  I suspect that we will find a lot of things that  
need tweaking only after 3.0 final has been out there for a while.

I think 2.7 should continue along the path of convergence toward 3.x.   
The vision some of us talked about at Pycon was that at some point  
down the line, maybe there's no difference between "python2.9 -3" and  
"python3.3 -2".

I would really like to see us adopt a distributed version control  
system.

I want our maintenance branches to always be in a releasable state.  I  
want to be confident enough about the tree to be able to cut a point  
release at any time.  I want to release a new point release from the  
maint branches once a month.
(Continue reading)

Permalink | Reply |
headers
Brett Cannon | 4 Oct 01:34
Favicon

Re: for __future__ import planning

On Fri, Oct 3, 2008 at 3:56 PM, Barry Warsaw <barry <at> python.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Oct 3, 2008, at 5:26 PM, Benjamin Peterson wrote:
>
>> So now that we've released 2.6 and are working hard on shepherding 3.0
>> out the door, it's time to worry about the next set of releases. :)
>>
>> I propose that we dramatically shorten our release cycle for 2.7/3.1
>> to roughly a year and put a strong focus stabilizing all the new
>> goodies we included in the last release(s). In the 3.x branch, we
>> should continue to solidify the new code and features that were
>> introduced. One 2.7's main objectives should be binding 3.x and 2.x
>> ever closer.
>
> There are several things that I would like to see us concentrate on after
> the 3.0 release.  I agree that 3.1 should be primarily a stabilizing
> release.  I suspect that we will find a lot of things that need tweaking
> only after 3.0 final has been out there for a while.
>
> I think 2.7 should continue along the path of convergence toward 3.x.  The
> vision some of us talked about at Pycon was that at some point down the
> line, maybe there's no difference between "python2.9 -3" and "python3.3 -2".
>

+1 from me. I think 2.7/3.1 should be used as a chance to get our
testing framework straightened out and have those releases be
extremely rock-solid (especially 2.7 as it might be the last in the
2.x series).
(Continue reading)

Permalink | Reply |
headers
Eric Smith | 4 Oct 01:43
Favicon

Re: for __future__ import planning

Brett Cannon wrote:
>> Christian rightly points out that with four active trees, we're going to a
>> pretty big challenge on our hands.  How do other large open source projects
>> handle similar situations?
>>
> 
> Beats me. Are that many projects crazy enough to have that many active branches?

Is it really that bad? Once 3.0 is released, it's not like we're going 
to be patching 2.6 and 3.0 all that much. All the "real development" (by 
which I mean most of the checkins) will be on 2.7 and 3.1. The biggest 
challenge I see is the buildbots.

Eric.

_______________________________________________
Python-Dev mailing list
Python-Dev <at> python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org
Permalink | Reply |
headers
"Martin v. =?iso-8859-1?q?L=F6wis=22?= | 4 Oct 09:22

Re: for __future__ import planning

> Is it really that bad? Once 3.0 is released, it's not like we're going
> to be patching 2.6 and 3.0 all that much.

And unfortunately so. The 2.5 branch doesn't get the attention that it
should, let alone the 2.4 branch. We will continue to "have" them (even
if only for security patches).

Regards,
Martin
_______________________________________________
Python-Dev mailing list
Python-Dev <at> python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org
Permalink | Reply |
headers
Antoine Pitrou | 4 Oct 02:18

Re: for __future__ import planning

Brett Cannon <brett <at> python.org> writes:
> 
> Beats me. Are that many projects crazy enough to have that many active
> branches?

Any project using branch-driven development has many active branches. Our
specificity is that we must maintain in sync two branches (trunk, py3k) which
have widely diverged from each other. Thus, merges are often non-trivial.

Regards

Antoine.

_______________________________________________
Python-Dev mailing list
Python-Dev <at> python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org
Permalink | Reply |
headers
Barry Warsaw | 4 Oct 19:08
Favicon

Re: for __future__ import planning


On Oct 3, 2008, at 7:34 PM, Brett Cannon wrote:

> Wow! I guess release.py is going to get really automated then. =) That
> or you are going to manage to con more of us to help out (and even cut
> the release ourselves).

release.py is really coming along well.  I'm planning to spend some  
time next time around on updating large parts of the web site  
automatically.  Or maybe Benjamin will when he's RM :)

-Barry
Permalink | Reply |
headers
Georg Brandl | 4 Oct 09:45
Gravatar

3.1 focus (was Re: for __future__ import planning)

Barry Warsaw schrieb:
> On Oct 3, 2008, at 5:26 PM, Benjamin Peterson wrote:
> 
>> So now that we've released 2.6 and are working hard on shepherding 3.0
>> out the door, it's time to worry about the next set of releases. :)
> 
>> I propose that we dramatically shorten our release cycle for 2.7/3.1
>> to roughly a year and put a strong focus stabilizing all the new
>> goodies we included in the last release(s). In the 3.x branch, we
>> should continue to solidify the new code and features that were
>> introduced. One 2.7's main objectives should be binding 3.x and 2.x
>> ever closer.
> 
> There are several things that I would like to see us concentrate on  
> after the 3.0 release.  I agree that 3.1 should be primarily a  
> stabilizing release.  I suspect that we will find a lot of things that  
> need tweaking only after 3.0 final has been out there for a while.
> 
> I think 2.7 should continue along the path of convergence toward 3.x.   
> The vision some of us talked about at Pycon was that at some point  
> down the line, maybe there's no difference between "python2.9 -3" and  
> "python3.3 -2".

Especially 3.1 should also be a release where we focus as much on the
community as on the code. There are many people out there for whom
Python 3, as an incompatible language, is not an easy step to make,
especially those with huge 2.x codebases on their hands. They have
two problems: The libraries they depend on aren't ported, and the
KLOC of code they care about are hard and tedious work to port, not
to mention that it typically isn't viewed as productive work by those
(Continue reading)

Permalink | Reply |
headers
A.M. Kuchling | 4 Oct 12:16
Favicon
Gravatar

Re: 3.1 focus (was Re: for __future__ import planning)

On Sat, Oct 04, 2008 at 09:45:27AM +0200, Georg Brandl wrote:
> Barry Warsaw schrieb:
> two problems: The libraries they depend on aren't ported, and the
> KLOC of code they care about are hard and tedious work to port, not
> to mention that it typically isn't viewed as productive work by those
> who pay them.

PyPI should also be enhanced to indicate which libraries are
3.x-compatible, to make it easier for 3.x users to find packages they
can use.

This may be more complicated than it sounds, because you'd probably
add a very general requirement-indicating feature to PyPI, not merely
a 'supports 3.0' Boolean on each record, and requirements are actually
pretty complicated: alternative packages, specific version numbers...

--amk

_______________________________________________
Python-Dev mailing list
Python-Dev <at> python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org
Permalink | Reply |
headers
"Martin v. =?iso-8859-1?q?L=F6wis=22?= | 4 Oct 12:24

Re: 3.1 focus (was Re: for __future__ import planning)

> This may be more complicated than it sounds, because you'd probably
> add a very general requirement-indicating feature to PyPI, not merely
> a 'supports 3.0' Boolean on each record, and requirements are actually
> pretty complicated: alternative packages, specific version numbers...

Can you propose a spec?

Regards,
Martin
_______________________________________________
Python-Dev mailing list
Python-Dev <at> python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org
Permalink | Reply |
headers
Antoine Pitrou | 4 Oct 12:36

Re: 3.1 focus (was Re: for __future__ import planning)

Martin v. Löwis <martin <at> v.loewis.de> writes:
> 
> > This may be more complicated than it sounds, because you'd probably
> > add a very general requirement-indicating feature to PyPI, not merely
> > a 'supports 3.0' Boolean on each record, and requirements are actually
> > pretty complicated: alternative packages, specific version numbers...
> 
> Can you propose a spec?

Setuptools already has a syntax for declaring requirements.
http://peak.telecommunity.com/DevCenter/setuptools#declaring-dependencies

_______________________________________________
Python-Dev mailing list
Python-Dev <at> python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org
Permalink | Reply |
headers
"Martin v. =?iso-8859-1?q?L=F6wis=22?= | 4 Oct 14:22

Re: 3.1 focus (was Re: for __future__ import planning)

Antoine Pitrou wrote:
> Martin v. Löwis <martin <at> v.loewis.de> writes:
>>> This may be more complicated than it sounds, because you'd probably
>>> add a very general requirement-indicating feature to PyPI, not merely
>>> a 'supports 3.0' Boolean on each record, and requirements are actually
>>> pretty complicated: alternative packages, specific version numbers...
>> Can you propose a spec?
> 
> Setuptools already has a syntax for declaring requirements.
> http://peak.telecommunity.com/DevCenter/setuptools#declaring-dependencies

That is underspecified for the issue at hand: What *specifically* should
PyPI look for to determine 3.0 support in a package, and how
*specifically* should it display that?

An alternative to specifying dependencies would be to specify a
classifier, e.g.

  Programming Language :: Python :: 3

or

  Programming Langauge :: Python3

Then, no changes to PyPI are needed (except for adding the classifier to
the database), and searching for Python-3-supporting packages could
go through http://pypi.python.org/pypi?%3Aaction=browse

Regards,
Martin
(Continue reading)

Permalink | Reply |
headers
"Tarek =?iso-8859-1?q?Ziad=E9=22?= | 5 Oct 01:53
Gravatar

Re: 3.1 focus (was Re: for __future__ import planning)

On Sat, Oct 4, 2008 at 2:22 PM, "Martin v. Löwis" <martin <at> v.loewis.de> wrote:
> Antoine Pitrou wrote:
>> Martin v. Löwis <martin <at> v.loewis.de> writes:
>>>> This may be more complicated than it sounds, because you'd probably
>>>> add a very general requirement-indicating feature to PyPI, not merely
>>>> a 'supports 3.0' Boolean on each record, and requirements are actually
>>>> pretty complicated: alternative packages, specific version numbers...
>>> Can you propose a spec?
>>
>> Setuptools already has a syntax for declaring requirements.
>> http://peak.telecommunity.com/DevCenter/setuptools#declaring-dependencies
>
> That is underspecified for the issue at hand: What *specifically* should
> PyPI look for to determine 3.0 support in a package, and how
> *specifically* should it display that?
>
> An alternative to specifying dependencies would be to specify a
> classifier, e.g.
>
>  Programming Language :: Python :: 3
>
> or
>
>  Programming Langauge :: Python3
>
> Then, no changes to PyPI are needed (except for adding the classifier to
> the database), and searching for Python-3-supporting packages could
> go through http://pypi.python.org/pypi?%3Aaction=browse

Setuptools declares dependencies, but does not add a Python version requirement,
(Continue reading)

Permalink | Reply |
headers
"Martin v. =?iso-8859-1?q?L=F6wis=22?= | 5 Oct 06:59

Re: 3.1 focus (was Re: for __future__ import planning)

> Setuptools declares dependencies, but does not add a Python version requirement,
> like what was proposed in PEP 345 (http://www.python.org/dev/peps/pep-0345/)
> with a new metadata called 'Requires Python'
> 
> Even if the problem is fixed in short term with a Trove classifier, 

Why would that be a short-term fix? It would work for the entire life
time of Python 3, and can be easily extended for Python 4, so it sounds
like a permanent solution to me.

As a permanent solution, you need to keep the problem statement in mind,
though: to allow people to determine whether a package works with Python 3.

> the metadata of a package should provide this information imho.

Well, the classifiers *are* part of the metadata of the package.

Regards,
Martin
_______________________________________________
Python-Dev mailing list
Python-Dev <at> python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org
Permalink | Reply |
headers
"Tarek =?iso-8859-1?q?Ziad=E9=22?= | 5 Oct 10:25
Gravatar

Re: 3.1 focus (was Re: for __future__ import planning)

On Sun, Oct 5, 2008 at 6:59 AM, "Martin v. Löwis" <martin <at> v.loewis.de> wrote:
>> Setuptools declares dependencies, but does not add a Python version requirement,
>> like what was proposed in PEP 345 (http://www.python.org/dev/peps/pep-0345/)
>> with a new metadata called 'Requires Python'
>>
>> Even if the problem is fixed in short term with a Trove classifier,
>
> Why would that be a short-term fix? It would work for the entire life
> time of Python 3, and can be easily extended for Python 4, so it sounds
> like a permanent solution to me.
>
> As a permanent solution, you need to keep the problem statement in mind,
> though: to allow people to determine whether a package works with Python 3.
>
>> the metadata of a package should provide this information imho.
>
> Well, the classifiers *are* part of the metadata of the package.

Yes and they are redundant to other metadata, like the licence for instance..

So maybe the problem is the other way: some specific metadata should be removed
since they are expressed in the classifier medatata. (e.g. only in one place)

There should be one-- and preferably only one --obvious way to do it.

Regards
Tarek
_______________________________________________
Python-Dev mailing list
Python-Dev <at> python.org
(Continue reading)

Permalink | Reply |
headers
Kevin Teague | 5 Oct 10:46
Favicon
Gravatar

Re: 3.1 focus (was Re: for __future__ import planning)


On Oct 4, 2008, at 9:59 PM, Martin v. Löwis wrote:

>> Setuptools declares dependencies, but does not add a Python version  
>> requirement,
>> like what was proposed in PEP 345 (http://www.python.org/dev/peps/pep-0345/ 
>> )
>> with a new metadata called 'Requires Python'
>>
>> Even if the problem is fixed in short term with a Trove classifier,
>
> Why would that be a short-term fix? It would work for the entire life
> time of Python 3, and can be easily extended for Python 4, so it  
> sounds
> like a permanent solution to me.
>
> As a permanent solution, you need to keep the problem statement in  
> mind,
> though: to allow people to determine whether a package works with  
> Python 3.
>

The Setuptools dependencies fields are only for declaring  library  
dependencies, not dependencies such as the Python interpreter.

A problem with overloading the Categories field with Python version  
compatability information is that it makes for a poor user-interface.  
On the release page for a package, I'd rather see a Python Version  
field than having to look through a potentially large list of  
Categories.
(Continue reading)

Permalink | Reply |
headers
"Martin v. =?iso-8859-1?q?L=F6wis=22?= | 5 Oct 11:05

Re: 3.1 focus (was Re: for __future__ import planning)

> A problem with overloading the Categories field with Python version
> compatability information is that it makes for a poor user-interface. On
> the release page for a package, I'd rather see a Python Version field
> than having to look through a potentially large list of Categories.

That's an issue of how the page is rendered. Hence I asked for a full
specification.

> There is a "Py Version" field for file uploads (which I'd really like to
> tweak the UI to read "Python Version")

Feel free to submit a patch (or perhaps just a bug report).

> maybe if you could specify for
> uploads of the "source" type the Python compatability of the source
> file? Even without  Python 3 it would be nice to upload a source file
> and indicate that you've used a Python 2.5 or 2.6ism in your code (or
> made use of newer standard library modules).

I think that deviates from the subject, which is "3.1 focus", and
AMK's request to let people find out whether a package runs on Python 3.

> Although this raises the question, what is the recommended practice for
> version numbering for distributions attempting to support both Python 2
> and 3? Say I have a distribution that I've made work with Python 2.6 and
> can run on Python 3 after running it through 2to3. The source code is
> different so that to me suggests different version numbers - but the API
> will be the same, so maybe the same version number should be used? That
> is should there be?
(Continue reading)

Permalink | Reply |
headers
Steve Holden | 5 Oct 13:54
Favicon
Gravatar

Re: 3.1 focus (was Re: for __future__ import planning)

Martin v. Löwis wrote:
>> A problem with overloading the Categories field with Python version
>> compatability information is that it makes for a poor user-interface. On
>> the release page for a package, I'd rather see a Python Version field
>> than having to look through a potentially large list of Categories.
> 
> That's an issue of how the page is rendered. Hence I asked for a full
> specification.
> 
>> There is a "Py Version" field for file uploads (which I'd really like to
>> tweak the UI to read "Python Version")
> 
> Feel free to submit a patch (or perhaps just a bug report).
> 
>> maybe if you could specify for
>> uploads of the "source" type the Python compatability of the source
>> file? Even without  Python 3 it would be nice to upload a source file
>> and indicate that you've used a Python 2.5 or 2.6ism in your code (or
>> made use of newer standard library modules).
> 
> I think that deviates from the subject, which is "3.1 focus", and
> AMK's request to let people find out whether a package runs on Python 3.
> 
>> Although this raises the question, what is the recommended practice for
>> version numbering for distributions attempting to support both Python 2
>> and 3? Say I have a distribution that I've made work with Python 2.6 and
>> can run on Python 3 after running it through 2to3. The source code is
>> different so that to me suggests different version numbers - but the API
>> will be the same, so maybe the same version number should be used? That
>> is should there be?
(Continue reading)

Permalink | Reply |
headers
Raymond Hettinger | 5 Oct 17:08
Favicon

Re: 3.1 focus (was Re: for __future__ import planning)

[Steve Holden"]
>
> Of course there is also the option of treating Python 3 as a different
> language, and having a Py3Pi website as well. This might not be as
> wasteful as it at first seems.

It would be nice if we had a way of marking Py2.6 recipes that still
work when run through 2-to-3 and then automatically porting updates
to the Py3Pi website.

Raymond

_______________________________________________
Python-Dev mailing list
Python-Dev <at> python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org
Permalink | Reply |
headers
"Martin v. =?iso-8859-1?q?L=F6wis=22?= | 5 Oct 18:32

Re: 3.1 focus (was Re: for __future__ import planning)

> Of course there is also the option of treating Python 3 as a different
> language, and having a Py3Pi website as well. This might not be as
> wasteful as it at first seems.

Although it would be possible, I think it's not appropriate.

It would be fairly easy to implement, though: just create
pypi.python.org/python3 (say), along with /simple3 and /packages3.
I find it inappropriate for two reasons: over time, Python 2 will
disappear, and then we are left with the python3 URLs (similar
how Microsoft now needs to put 64-bit binaries into the system32
folder). In addition, packages that do support both versions need
to register twice, upload twice, etc.

In any case, if that route is chosen, we have to adjust distutils
before the 3.0 release is made.

Regards,
Martin
_______________________________________________
Python-Dev mailing list
Python-Dev <at> python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org
Permalink | Reply |
headers
Antoine Pitrou | 6 Oct 14:50

Re: 3.1 focus (was Re: for __future__ import planning)

Martin v. Löwis <martin <at> v.loewis.de> writes:
> 
> Although it would be possible, I think it's not appropriate.

I also think it's inappropriate. We want people to know about the existence of
Python 3, and the best for that is to have Python 3-related information in the
standard PyPI site where people look for Python 2.x packages.

Regards

Antoine.

_______________________________________________
Python-Dev mailing list
Python-Dev <at> python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org
Permalink | Reply |
headers
Paul Moore | 6 Oct 17:28

Re: 3.1 focus (was Re: for __future__ import planning)

2008/10/6 Antoine Pitrou <solipsis <at> pitrou.net>:
> Martin v. Löwis <martin <at> v.loewis.de> writes:
>>
>> Although it would be possible, I think it's not appropriate.
>
> I also think it's inappropriate. We want people to know about the existence of
> Python 3, and the best for that is to have Python 3-related information in the
> standard PyPI site where people look for Python 2.x packages.

Agreed. Although there are significant differences to consider, I
think the last thing we want to do is to encourage the impression that
Python 3 is a different language from Python 2.

Paul.
_______________________________________________
Python-Dev mailing list
Python-Dev <at> python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org
Permalink | Reply |
headers
Facundo Batista | 5 Oct 15:32

Re: 3.1 focus (was Re: for __future__ import planning)

2008/10/5 Kevin Teague <kevin <at> bud.ca>:

> on Python 3 after running it through 2to3. The source code is different so
> that to me suggests different version numbers - but the API will be the
> same, so maybe the same version number should be used? That is should there
> be?
>
> foobar-1.0-py2.6.tar.gz
> foobar-1.0-py3.0.tar.gz

More likely, in this way:

foobar-1.0-py2.tar.gz
foobar-1.0-py3.tar.gz

> Or should it be something like?
>
> foobar-1.0.tar.gz # Python 2
> foobar-1.1.tar.gz # Python 3

The problem here is that I can foresee libs or apps that have a mixed
path, starting to support Py 3 at some point, and deprecating the Py 2
support after a while:

foobar-1.0.tar.gz   # Py 2
foobar-1.1.tar.gz   # Py 2 & 3
foobar-1.2.tar.gz   # Py 2 & 3
foobar-1.3.tar.gz   # Py 2 & 3
foobar-1.4.tar.gz   # Py 2 & 3
foobar-1.5.tar.gz   # Py 3
(Continue reading)

Permalink | Reply |
headers
"Martin v. =?iso-8859-1?q?L=F6wis=22?= | 5 Oct 18:38

Re: 3.1 focus (was Re: for __future__ import planning)

>> foobar-1.0-py2.6.tar.gz
>> foobar-1.0-py3.0.tar.gz
> 
> More likely, in this way:
> 
> foobar-1.0-py2.tar.gz
> foobar-1.0-py3.tar.gz

How do you implement this in distutils? People probably won't rename
the files from how sdist names them. So it's more likely that they
come up with things like

foobar_py3-1.0.tar.gz

and register a second project foobar_py3 in PyPI.

Regards,
Martin

_______________________________________________
Python-Dev mailing list
Python-Dev <at> python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org
Permalink | Reply |
headers
Facundo Batista | 6 Oct 14:08

Re: 3.1 focus (was Re: for __future__ import planning)

2008/10/5 "Martin v. Löwis" <martin <at> v.loewis.de>:

>>> foobar-1.0-py2.6.tar.gz
>>> foobar-1.0-py3.0.tar.gz
>>
>> More likely, in this way:
>>
>> foobar-1.0-py2.tar.gz
>> foobar-1.0-py3.tar.gz
>
> How do you implement this in distutils? People probably won't rename
> the files from how sdist names them. So it's more likely that they
> come up with things like

Sorry, I was not advising that structure, just mentioning that if
you'll follow it, don't include the minor version, just the major one.

Regards,

--

-- 
.    Facundo

Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/
_______________________________________________
Python-Dev mailing list
Python-Dev <at> python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org
(Continue reading)

Permalink | Reply |
headers
Brett Cannon | 4 Oct 20:03
Favicon

Re: 3.1 focus (was Re: for __future__ import planning)

On Sat, Oct 4, 2008 at 12:45 AM, Georg Brandl <g.brandl <at> gmx.net> wrote:
> Barry Warsaw schrieb:
>> On Oct 3, 2008, at 5:26 PM, Benjamin Peterson wrote:
>>
>>> So now that we've released 2.6 and are working hard on shepherding 3.0
>>> out the door, it's time to worry about the next set of releases. :)
>>
>>> I propose that we dramatically shorten our release cycle for 2.7/3.1
>>> to roughly a year and put a strong focus stabilizing all the new
>>> goodies we included in the last release(s). In the 3.x branch, we
>>> should continue to solidify the new code and features that were
>>> introduced. One 2.7's main objectives should be binding 3.x and 2.x
>>> ever closer.
>>
>> There are several things that I would like to see us concentrate on
>> after the 3.0 release.  I agree that 3.1 should be primarily a
>> stabilizing release.  I suspect that we will find a lot of things that
>> need tweaking only after 3.0 final has been out there for a while.
>>
>> I think 2.7 should continue along the path of convergence toward 3.x.
>> The vision some of us talked about at Pycon was that at some point
>> down the line, maybe there's no difference between "python2.9 -3" and
>> "python3.3 -2".
>
> Especially 3.1 should also be a release where we focus as much on the
> community as on the code. There are many people out there for whom
> Python 3, as an incompatible language, is not an easy step to make,
> especially those with huge 2.x codebases on their hands. They have
> two problems: The libraries they depend on aren't ported, and the
> KLOC of code they care about are hard and tedious work to port, not
(Continue reading)

Permalink | Reply |
headers
Georg Brandl | 4 Oct 20:11
Gravatar

Re: 3.1 focus (was Re: for __future__ import planning)

Brett Cannon schrieb:

>> Last not least, there should be a *central* location on python.org where
>> specifically all resources on 2->3 transition are collected. Talks,
>> documents, links, and some crucial information many people seem to miss,
>> such as how long the 2.x series will at least be maintained. They depend
>> on this.
> 
> That seems reasonable if someone gets around to doing it. =)

Well, since for >95% of the (potential) Py3k users it is more important than
e.g. the import rewrite in Python (no stab at you intended, Brett), it is
something someone will have to get around to doing.

I'm not excusing myself; in fact, I'd be happy to work on this, but overall
the team "Python 3 advocacy and support" should consist of more than one
person.

Georg

--

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.

_______________________________________________
Python-Dev mailing list
Python-Dev <at> python.org
http://mail.python.org/mailman/listinfo/python-dev
(Continue reading)

Permalink | Reply |
headers
"Martin v. =?iso-8859-1?q?L=F6wis=22?= | 4 Oct 21:17

Re: 3.1 focus (was Re: for __future__ import planning)

> Well, since for >95% of the (potential) Py3k users it is more important than
> e.g. the import rewrite in Python (no stab at you intended, Brett), it is
> something someone will have to get around to doing.
> 
> I'm not excusing myself; in fact, I'd be happy to work on this, but overall
> the team "Python 3 advocacy and support" should consist of more than one
> person.

I think this has time. I'm (now) confident that people will port to
Python 3 sooner rather than later, just because it's there. In fact,
we have to be careful not to talk too many people into porting, since
there will be some glitches which need to be resolved, and may not get
resolved before 3.2 or so. So people with a natural wariness are advised
to trust this wariness, or else all their concerns become
self-fulfilling prophecies.

Regards,
Martin
_______________________________________________
Python-Dev mailing list
Python-Dev <at> python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org
Permalink | Reply |
headers
Brett Cannon | 4 Oct 21:36
Favicon

Re: 3.1 focus (was Re: for __future__ import planning)

[replying to both Georg and Martin]

On Sat, Oct 4, 2008 at 12:17 PM, "Martin v. Löwis" <martin <at> v.loewis.de> wrote:
>> Well, since for >95% of the (potential) Py3k users it is more important than
>> e.g. the import rewrite in Python (no stab at you intended, Brett), it is
>> something someone will have to get around to doing.
>>

Don't worry, I realize my import work is approaching vaporware status
at this rate (still plugging away at it, though).

But you are right: helping people port to 3 will be the most important
thing we can help people with.

>> I'm not excusing myself; in fact, I'd be happy to work on this, but overall
>> the team "Python 3 advocacy and support" should consist of more than one
>> person.
>

I would definitely be willing to help.

So the mailing list is a good idea. Perhaps it should just be
python-porting so that it can also be used for people who have
problems with minor releases?

We could then have a /porting/ section to the site where we can
actually document after each release how to port to the newest
version.

And as for 2 -> 3 stuff, should probably provide the expected steps to
(Continue reading)

Permalink | Reply |
headers
Facundo Batista | 5 Oct 01:19

Re: [Python-Dev] 3.1 focus (was Re: for __future__ import planning)

2008/10/4 Brett Cannon <brett <at> python.org>:

> So the mailing list is a good idea. Perhaps it should just be
> python-porting so that it can also be used for people who have
> problems with minor releases?

+1. I'd try to help on that list, also.

--

-- 
.    Facundo

Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/
Permalink | Reply |
headers
Lennart Regebro | 12 Oct 19:23
Gravatar

Re: for __future__ import planning

On Sat, Oct 4, 2008 at 00:56, Barry Warsaw <barry <at> python.org> wrote:
> I think 2.7 should continue along the path of convergence toward 3.x.  The
> vision some of us talked about at Pycon was that at some point down the
> line, maybe there's no difference between "python2.9 -3" and "python3.3 -2".

I like that. Do we know what the next "hurdle" would be? The testing I
have done seems to indicate that one major area is handling of binary
file data that may or may not be binary. Is a real bytes type (and not
just an alternate spelling for str) a possibility? It may be that this
isn't a problem in practice, I don't know yet. :)

--

-- 
Lennart Regebro: Zope and Plone consulting.
http://www.colliberty.com/
+33 661 58 14 64
_______________________________________________
Python-Dev mailing list
Python-Dev <at> python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org
Permalink | Reply |

Gmane