Re: [Python-Dev] PEP 426 is now the draft spec for distribution metadata 2.0
On Mon, Feb 18, 2013 at 9:54 AM, Nick Coghlan wrote: > > On 18 Feb 2013 08:36, "Fred Drake" wrote: >> >> On Sun, Feb 17, 2013 at 4:21 PM, Nick Coghlan wrote: >> > As Daniel pointed out, easy_install and pip also don't follow this rule >> > yet, >> > so it won't really have any impact if we never get to metadata 3.0. >> >> Actually, my point was that using a separate filename for version 2.0 >> would >> allow provision of both 1.x and 2.0, so version 2.0 metadata can be >> deployed >> as tool support becomes available, instead of having to wait until 1.x >> tools >> are replaced. >> >> Once tools are following the new rule about version compatibility, there's >> less worry about this (at least on my part). > > None of sdist, wheel or the installation database currently support parallel > metadata versions. Interpreting 2.0 metadata as 1.1 also won't be > catastrophically wrong in general, especially if the production tools still > also ship the legacy dependency and entry points data as separate files. The > worst thing that is likely to happen is an old tool may fail to show a 2.0 > style description. > > However, I *will* update the PEP to state explicitly that tools should emit > the lowest required metadata version for the fields being published. I clarified the metadata version handling here: http://hg.python.org/peps/rev/630c5dd5a123 Rather than "should", I softened the "use the lowest metadata format" suggestion to a "may". I also pointed out that these new rules will only apply to a future major version transition, and for this one, people can just emit the extra files they do today and even older versions of tools will probably get things fairly right. Cheers, Nick. diff --git a/pep-0426.txt b/pep-0426.txt --- a/pep-0426.txt +++ b/pep-0426.txt @@ -89,9 +89,15 @@ Version of the file format; "2.0" is the only legal value. -Automated tools should warn if ``Metadata-Version`` is greater than the -highest version they support, and must fail if ``Metadata-Version`` has -a greater major version than the highest version they support. +Automated tools consuming metadata should warn if ``Metadata-Version`` is +greater than the highest version they support, and must fail if +``Metadata-Version`` has a greater major version than the highest +version they support. + +For broader compatibility, automated tools may choose to produce +distribution metadata using the lowest metadata version that includes +all of the needed fields. + Example:: @@ -1283,9 +1289,19 @@ metadata specifications is unlikely to give the expected behaviour. Whenever the major version number of the specification is incremented, it -is expected that deployment will take some time, as metadata consuming tools -much be updated before other tools can safely start producing the new -format. +is expected that deployment will take some time, as either metadata +consuming tools must be updated before other tools can safely start +producing the new format, or else the sdist and wheel formats, along with +the installation database definition, will need to be updated to support +provision of multiple versions of the metadata in parallel. + +Existing tools won't abide by this guideline until they're updated to +support the new metadata standard, so the new semantics will first take +effect for a hypothetical 2.x -> 3.0 transition. For the 1.x -> 2.0 +transition, it is recommended that tools continue to produce the +existing supplementary files (such as ``entry_points.txt``) in addition +to any equivalents specified using the new features of the standard +metadata format (including the formal extension mechanism). -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Rationale for different signatures of tuple.__new__ and namedtuple.__new__
Hi,
I can do
tuple([1,2,3])
but not:
from collections import namedtuple
namedtuple('B', 'x y z')([1,2,3])
I get a TypeError: __new__() takes exactly 4 arguments (2 given)
However I can do:
namedtuple('B', 'x y z')._make([1,2,3])
So namedtuple's _make classmethod looks a lot like tuple's __new__().
What's the rationale for this? Wouldn't it be better to share the same
signature for __new__?
IPython's serialization code depends on a tuple's __new__() having the
signature that tuple has and therefore does not work with namedtuples.
See discussion here:
http://article.gmane.org/gmane.comp.python.general/726849
Thanks,
John.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Rationale for different signatures of tuple.__new__ and namedtuple.__new__
On 02/18/2013 03:32 PM, John Reid wrote:
I can do
tuple([1,2,3])
but not:
from collections import namedtuple
namedtuple('B', 'x y z')([1,2,3])
I get a TypeError: __new__() takes exactly 4 arguments (2 given)
However I can do:
namedtuple('B', 'x y z')._make([1,2,3])
So namedtuple's _make classmethod looks a lot like tuple's __new__().
What's the rationale for this? Wouldn't it be better to share the same
signature for __new__?
Sharing the constructor signature with tuple would break the common case of:
namedtuple('B', 'x y z')(1, 2, 3)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython (2.7): Fix posixpath.realpath() for multiple pardirs (fixes issue #6975).
On Mon, 18 Feb 2013 11:24:40 +0100 (CET)
serhiy.storchaka wrote:
>
> +def test_realpath_curdir(self):
> +self.assertEqual(realpath('.'), os.getcwd())
> +self.assertEqual(realpath('./.'), os.getcwd())
> +self.assertEqual(realpath('/'.join(['.'] * 100)), os.getcwd())
> +
> +def test_realpath_pardir(self):
> +self.assertEqual(realpath('..'), dirname(os.getcwd()))
> +self.assertEqual(realpath('../..'), dirname(dirname(os.getcwd(
> +self.assertEqual(realpath('/'.join(['..'] * 100)), '/')
What if there's a symlink along os.getcwd()?
Regards
Antoine.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython (2.7): Fix posixpath.realpath() for multiple pardirs (fixes issue #6975).
On 18.02.13 19:26, Antoine Pitrou wrote:
On Mon, 18 Feb 2013 11:24:40 +0100 (CET)
serhiy.storchaka wrote:
+def test_realpath_curdir(self):
+self.assertEqual(realpath('.'), os.getcwd())
+self.assertEqual(realpath('./.'), os.getcwd())
+self.assertEqual(realpath('/'.join(['.'] * 100)), os.getcwd())
+
+def test_realpath_pardir(self):
+self.assertEqual(realpath('..'), dirname(os.getcwd()))
+self.assertEqual(realpath('../..'), dirname(dirname(os.getcwd(
+self.assertEqual(realpath('/'.join(['..'] * 100)), '/')
What if there's a symlink along os.getcwd()?
1. AFAIK, os.getcwd() returns the path with resolved symlinks.
2. realpath() first resolve relative path and then prepends cwd to the
result.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython (2.7): Fix posixpath.realpath() for multiple pardirs (fixes issue #6975).
On Mon, 18 Feb 2013 19:56:07 +0200
Serhiy Storchaka wrote:
> On 18.02.13 19:26, Antoine Pitrou wrote:
> > On Mon, 18 Feb 2013 11:24:40 +0100 (CET)
> > serhiy.storchaka wrote:
> >>
> >> +def test_realpath_curdir(self):
> >> +self.assertEqual(realpath('.'), os.getcwd())
> >> +self.assertEqual(realpath('./.'), os.getcwd())
> >> +self.assertEqual(realpath('/'.join(['.'] * 100)), os.getcwd())
> >> +
> >> +def test_realpath_pardir(self):
> >> +self.assertEqual(realpath('..'), dirname(os.getcwd()))
> >> +self.assertEqual(realpath('../..'), dirname(dirname(os.getcwd(
> >> +self.assertEqual(realpath('/'.join(['..'] * 100)), '/')
> >
> > What if there's a symlink along os.getcwd()?
>
> 1. AFAIK, os.getcwd() returns the path with resolved symlinks.
Indeed, it seems you are right (under POSIX at least):
“The getcwd() function shall place an absolute pathname of the current
working directory in the array pointed to by buf, and return buf. The
pathname shall contain no components that are dot or dot-dot, or are
symbolic links.”
http://pubs.opengroup.org/onlinepubs/9699919799/functions/getcwd.html
Regards
Antoine.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Rationale for different signatures of tuple.__new__ and namedtuple.__new__
Later today you posted "Differences creating tuples and collections.namedtuples" on python-list. http://thread.gmane.org/gmane.comp.python.general/726849 That *is* the proper place to make observations about current Python and ask questions about why it is the way it is and how to work around features that get in your way. So I will answer there, if I think more needs to be said, after reading the multiple current responses. Anyone else should do the same. -- Terry Jan Reedy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
