Re: [Python-Dev] Cut/Copy/Paste items in IDLE right click context menu

2013-02-17 Thread Nick Coghlan
On Sun, Feb 17, 2013 at 4:56 PM, R. David Murray  wrote:
> On Sun, 17 Feb 2013 14:00:24 +1100, Neil Hodgson  wrote:
>> Nick Coghlan:
>>
>> > - no need for extensive cross-OS testing prior to commit, that's a key
>> > part of the role of the buildbots
>>
>>Are the buildbots able to test UI features like menu selections?
>
> Not to mention that the test suite is a bit sparse for Idle, despite
> recent efforts to improve this, even for the stuff that can be tested.

Perhaps something for the PEP to elaborate on before we declare open
season on Idle improvements in bug fix releases.

Cheers,
Nick.

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


Re: [Python-Dev] BDFL delegation for PEP 426 (PyPI metadata 1.3)

2013-02-17 Thread Nick Coghlan
On Sun, Feb 3, 2013 at 4:37 PM, Guido van Rossum  wrote:
> I don't know or care much about PyPI metadata, so do what you feel is
> right. If you are uncomfortable being PEP-uncle *and* -author, find
> another author or another uncle. But since it doesn't affect the
> language or library, it's fine with me if you are both. :-)

Based on this, and due to the fact that I think most everyone else
involved in reviewing PEP 426 would have already accepted it by now,
I've reclaimed the BDFL-Delegate role for PEP 426.

I'll be posting the latest draft to distutils-sig for a final sanity
check shortly. (Do people see any point in posting it here as well?
Everyone that will need to support it near-term is over on
distutils-sig, but may not be on python-dev)

Cheers,
Nick.

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


Re: [Python-Dev] cpython: Issue #15022: Add pickle and comparison support to types.SimpleNamespace.

2013-02-17 Thread Antoine Pitrou
On Sat, 16 Feb 2013 18:20:14 -0700
Eric Snow  wrote:
> On Sat, Feb 16, 2013 at 5:02 PM, Eric Snow  
> wrote:
> > On Sat, Feb 16, 2013 at 4:45 PM, Antoine Pitrou  wrote:
> >> I think you should test with all pickle protocols.
> >
> > I'll do that.
> 
> Out of curiousity, how critical is it to support protocols 0 and 1?
> I've made sure SimpleNamespace does, but it made me wonder what the
> use case is for the older protocols.

Not critical at all. It's just nice to have for consistency, but it
shouldn't stop you if it's too difficult to implement.

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: Issue #15022: Add pickle and comparison support to types.SimpleNamespace.

2013-02-17 Thread Nick Coghlan
On Sun, Feb 17, 2013 at 9:49 PM, Antoine Pitrou  wrote:
> On Sat, 16 Feb 2013 18:20:14 -0700
> Eric Snow  wrote:
>> On Sat, Feb 16, 2013 at 5:02 PM, Eric Snow  
>> wrote:
>> > On Sat, Feb 16, 2013 at 4:45 PM, Antoine Pitrou  
>> > wrote:
>> >> I think you should test with all pickle protocols.
>> >
>> > I'll do that.
>>
>> Out of curiousity, how critical is it to support protocols 0 and 1?
>> I've made sure SimpleNamespace does, but it made me wonder what the
>> use case is for the older protocols.
>
> Not critical at all. It's just nice to have for consistency, but it
> shouldn't stop you if it's too difficult to implement.

Although in such cases, we probably want to test we generate a
reasonable error message for the unsupported protocols, rather than
silently writing junk to the pickle.

Cheers,
Nick.

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


Re: [Python-Dev] PEP 426 is now the draft spec for distribution metadata 2.0

2013-02-17 Thread Antoine Pitrou
On Sun, 17 Feb 2013 20:11:23 +1000
Nick Coghlan  wrote:
> 
> Major changes since the last draft:
> 
> 1. Metadata-Version is 2.0 rather than 1.3, and the field now has the
> same major.minor semantics as are defined for wheel versions in PEP
> 427 (i.e. if a tool sees a major version number it doesn't recognise,
> it should give up rather than trying to guess what to do with it,
> while it's OK to process a higher minor version)

So is it possible to bundle several versioned metadata files in order
to maximize compatibility? Or does a distribution with 2.0 metadata
have to abandon all hope of being compatible with all tools?

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] PEP 426 is now the draft spec for distribution metadata 2.0

2013-02-17 Thread Daniel Holth
On Sun, 17 Feb 2013 20:11:23 +1000
Nick Coghlan  wrote:
>
> Major changes since the last draft:
>
> 1. Metadata-Version is 2.0 rather than 1.3, and the field now has the
> same major.minor semantics as are defined for wheel versions in PEP
> 427 (i.e. if a tool sees a major version number it doesn't recognise,
> it should give up rather than trying to guess what to do with it,
> while it's OK to process a higher minor version)

So is it possible to bundle several versioned metadata files in order
to maximize compatibility? Or does a distribution with 2.0 metadata
have to abandon all hope of being compatible with all tools?

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/dholth%40gmail.com

Not likely to matter for a while as the current md v1 tools don't
understand this new obsolescence rule :-)
___
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] PEP 426 is now the draft spec for distribution metadata 2.0

2013-02-17 Thread Fred Drake
On Sun, Feb 17, 2013 at 1:45 PM, Daniel Holth  wrote:
> Not likely to matter for a while as the current md v1 tools don't understand
> this new obsolescence rule :-)

Using a separate file for post-obsolescence-rule metadata versions would
allow coexistance, which would likely improve adoption.


  -Fred

-- 
Fred L. Drake, Jr.
"A storm broke loose in my mind."  --Albert Einstein
___
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] PEP 426 is now the draft spec for distribution metadata 2.0

2013-02-17 Thread Nick Coghlan
On 18 Feb 2013 04:54, "Fred Drake"  wrote:
>
> On Sun, Feb 17, 2013 at 1:45 PM, Daniel Holth  wrote:
> > Not likely to matter for a while as the current md v1 tools don't
understand
> > this new obsolescence rule :-)
>
> Using a separate file for post-obsolescence-rule metadata versions would
> allow coexistance, which would likely improve adoption.

Perhaps, but not something we actually need to worry about until we're
contemplating metadata 3.0, especially since whether or not it helps will
depend on why we're breaking backwards compatibility. At the very least,
updated wheel, sdist and installation database specs would be needed to
allow multiple versions of the metadata.

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.

Cheers,
Nick.

>
>
>   -Fred
>
> --
> Fred L. Drake, Jr.
> "A storm broke loose in my mind."  --Albert Einstein
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
http://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
___
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] PEP 426 is now the draft spec for distribution metadata 2.0

2013-02-17 Thread Fred Drake
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).


  -Fred

-- 
Fred L. Drake, Jr.
"A storm broke loose in my mind."  --Albert Einstein
___
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] PEP 426 is now the draft spec for distribution metadata 2.0

2013-02-17 Thread Nick Coghlan
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.

Cheers,
Nick.

>
>
>   -Fred
>
> --
> Fred L. Drake, Jr.
> "A storm broke loose in my mind."  --Albert Einstein
___
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