Mailing List Archive: Python: Dev

3.1 focus (was Re: for future import planning)

Index | Next | Previous | View Threaded

g.brandl at gmx

Oct 4, 2008, 12:45 AM

Post #1 of 24 (627 views)
Permalink

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
who pay them.

We need to make 2to3 and related tools reliable and do more showcases
of porting, like Martin did with Django, so that people have real-world
examples at their disposal, by which they can estimate their own
porting needs. (Waiting for the extended community to deliver such
examples may be a mistake.)

We also need to commit to help people with porting. I propose a new
mailing list (e.g. python3-porting), parallel to python-list,
specifically for people going that way. I think it will help to
focus the community effort of getting Python 3 off the ground.

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.

cheers,
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
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

amk at amk

Oct 4, 2008, 3:16 AM

Post #2 of 24 (611 views)
Permalink

Re: 3.1 focus (was Re: for __future__ import planning) [In reply to]

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/list-python-dev%40lists.gossamer-threads.com

martin at v

Oct 4, 2008, 3:24 AM

Post #3 of 24 (611 views)
Permalink

Re: 3.1 focus (was Re: for __future__ import planning) [In reply to]

> 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/list-python-dev%40lists.gossamer-threads.com

solipsis at pitrou

Oct 4, 2008, 3:36 AM

Post #4 of 24 (611 views)
Permalink

Re: 3.1 focus (was Re: for future import planning) [In reply to]

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/list-python-dev%40lists.gossamer-threads.com

martin at v

Oct 4, 2008, 5:22 AM

Post #5 of 24 (610 views)
Permalink

Re: 3.1 focus (was Re: for __future__ import planning) [In reply to]

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
_______________________________________________
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/list-python-dev%40lists.gossamer-threads.com

brett at python

Oct 4, 2008, 11:03 AM

Post #6 of 24 (597 views)
Permalink

Re: 3.1 focus (was Re: for __future__ import planning) [In reply to]

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
> to mention that it typically isn't viewed as productive work by those
> who pay them.
>
> We need to make 2to3 and related tools reliable and do more showcases
> of porting, like Martin did with Django, so that people have real-world
> examples at their disposal, by which they can estimate their own
> porting needs. (Waiting for the extended community to deliver such
> examples may be a mistake.)
>
> We also need to commit to help people with porting. I propose a new
> mailing list (e.g. python3-porting), parallel to python-list,
> specifically for people going that way. I think it will help to
> focus the community effort of getting Python 3 off the ground.
>

This is a good idea; python-help for porting.

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

-Brett
_______________________________________________
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/list-python-dev%40lists.gossamer-threads.com

g.brandl at gmx

Oct 4, 2008, 11:11 AM

Post #7 of 24 (597 views)
Permalink

Re: 3.1 focus (was Re: for __future__ import planning) [In reply to]

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
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

martin at v

Oct 4, 2008, 12:17 PM

Post #8 of 24 (597 views)
Permalink

Re: 3.1 focus (was Re: for __future__ import planning) [In reply to]

> 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/list-python-dev%40lists.gossamer-threads.com

brett at python

Oct 4, 2008, 12:36 PM

Post #9 of 24 (594 views)
Permalink

Re: 3.1 focus (was Re: for __future__ import planning) [In reply to]

[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
port, tips for pure Python code (and how to write 2.6/3.0 compatible
code), extension modules, and make it clear what our overall plan is
(e.g. 3.2 probably being the truly stable release semantically).

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

Yes, people should be warned that if they are not ready to make
changes after each Python release that are probably more than they are
used to between minor releases, they might to hold off for 3.1 or 3.2.
But I don't want to be too discouraging as that might stifle any
forward momentum we might have and potentially leave 3 flat before it
even gets going.

-Brett
_______________________________________________
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/list-python-dev%40lists.gossamer-threads.com

facundobatista at gmail

Oct 4, 2008, 4:19 PM

Post #10 of 24 (594 views)
Permalink

Re: 3.1 focus (was Re: for __future__ import planning) [In reply to]

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/
_______________________________________________
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/list-python-dev%40lists.gossamer-threads.com

ziade.tarek at gmail

Oct 4, 2008, 4:53 PM

Post #11 of 24 (593 views)
Permalink

Re: 3.1 focus (was Re: for __future__ import planning) [In reply to]

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,
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, the metadata
of a package should provide this information imho.

>From there PyPI should be able to provide the Python version directly.

For a full list of dependencies this is another tough problem due to the dynamic
nature of the metadata: you have to run setup.py to get the list of dependencies
because they are determined by code. This is by design, and plans for
a refactoring are
being discussed in distutils-SIG since a few days.

In any case, extending metadata with supported Python version could
be a first simple, useful step to do in distutils and PyPI today. So
the Python version
comes as the same level than the Platform or the License.

Tarek
_______________________________________________
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/list-python-dev%40lists.gossamer-threads.com

martin at v

Oct 4, 2008, 9:59 PM

Post #12 of 24 (585 views)
Permalink

Re: 3.1 focus (was Re: for __future__ import planning) [In reply to]

> 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/list-python-dev%40lists.gossamer-threads.com

ziade.tarek at gmail

Oct 5, 2008, 1:25 AM

Post #13 of 24 (577 views)
Permalink

Re: 3.1 focus (was Re: for __future__ import planning) [In reply to]

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
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

kevin at bud

Oct 5, 2008, 1:46 AM

Post #14 of 24 (577 views)
Permalink

Re: 3.1 focus (was Re: for __future__ import planning) [In reply to]

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.

There is a "Py Version" field for file uploads (which I'd really like
to tweak the UI to read "Python Version"), 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).

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?

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

Or should it be something like?

foobar-1.0.tar.gz # Python 2
foobar-1.1.tar.gz # Python 3

Well, writing out that last example looks wrong to me, since 1.0 ->
1.1 suggests bug fixes and API changes to the package. But someone
could be thinking, "1.0 supports the Python 2 API and 1.1 supports the
Python 3 language API". So at any rate it'd be good to make the way to
handle this explicit in the (yet to be created) "2to3 central"
documentation resource.

_______________________________________________
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/list-python-dev%40lists.gossamer-threads.com

martin at v

Oct 5, 2008, 2:05 AM

Post #15 of 24 (577 views)
Permalink

Re: 3.1 focus (was Re: for __future__ import planning) [In reply to]

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

It all depends on how you do the porting. If all it takes to run the
program through 2to3 to make it port correctly, I recommend to use
the build_py_2to3 build step of distutils in 3.0. Then the same source
can be installed for 2.x and 3.x, with no modifications.

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/list-python-dev%40lists.gossamer-threads.com

steve at holdenweb

Oct 5, 2008, 4:54 AM

Post #16 of 24 (568 views)
Permalink

Re: 3.1 focus (was Re: for __future__ import planning) [In reply to]

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?
>
> It all depends on how you do the porting. If all it takes to run the
> program through 2to3 to make it port correctly, I recommend to use
> the build_py_2to3 build step of distutils in 3.0. Then the same source
> can be installed for 2.x and 3.x, with no modifications.
>
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.

regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
Holden Web LLC http://www.holdenweb.com/

_______________________________________________
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/list-python-dev%40lists.gossamer-threads.com

steve at holdenweb

Oct 5, 2008, 4:54 AM

Post #17 of 24 (568 views)
Permalink

Re: 3.1 focus (was Re: for __future__ import planning) [In reply to]

facundobatista at gmail

Oct 5, 2008, 6:32 AM

Post #18 of 24 (565 views)
Permalink

Re: 3.1 focus (was Re: for __future__ import planning) [In reply to]

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

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/list-python-dev%40lists.gossamer-threads.com

python at rcn

Oct 5, 2008, 8:08 AM

Post #19 of 24 (565 views)
Permalink

Re: 3.1 focus (was Re: for __future__ import planning) [In reply to]

[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/list-python-dev%40lists.gossamer-threads.com

martin at v

Oct 5, 2008, 9:32 AM

Post #20 of 24 (564 views)
Permalink

Re: 3.1 focus (was Re: for __future__ import planning) [In reply to]

> 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/list-python-dev%40lists.gossamer-threads.com

martin at v

Oct 5, 2008, 9:38 AM

Post #21 of 24 (564 views)
Permalink

Re: 3.1 focus (was Re: for __future__ import planning) [In reply to]

>> 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/list-python-dev%40lists.gossamer-threads.com

facundobatista at gmail

Oct 6, 2008, 5:08 AM

Post #22 of 24 (521 views)
Permalink

Re: 3.1 focus (was Re: for __future__ import planning) [In reply to]

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/list-python-dev%40lists.gossamer-threads.com

solipsis at pitrou

Oct 6, 2008, 5:50 AM

Post #23 of 24 (521 views)
Permalink

Re: 3.1 focus (was Re: for future import planning) [In reply to]

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/list-python-dev%40lists.gossamer-threads.com

p.f.moore at gmail

Oct 6, 2008, 8:28 AM

Post #24 of 24 (518 views)
Permalink

Re: 3.1 focus (was Re: for __future__ import planning) [In reply to]

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/list-python-dev%40lists.gossamer-threads.com

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact lists@gossamer-threads.com

3.1 focus (was Re: for __future__ import planning)

3.1 focus (was Re: for future import planning)