Re: [Python-Dev] PEP 467: Minor API improvements to bytes, bytearray, and memoryview

On 07.06.16 23:28, Ethan Furman wrote: Minor changes: updated version numbers, add punctuation. The current text seems to take into account Guido's last comments. Thoughts before asking for acceptance? PEP: 467 Title: Minor API improvements for binary sequences Version: $Revision$

Re: [Python-Dev] PEP: Ordered Class Definition Namespace

On 07.06.16 20:51, Eric Snow wrote: Hi all, Following discussion a few years back (and rough approval from Guido [1]), I started work on using OrderedDict for the class definition namespace by default. The bulk of the effort lay in implementing OrderedDict in C, which I got landed just in time

Re: [Python-Dev] PEP: Ordered Class Definition Namespace

> On Jun 7, 2016, at 4:12 PM, Nick Coghlan wrote: > > By the time decorators run, the original execution namespace is no > longer available - the contents have been copied into the class dict, > which will still be a plain dict (and there's a lot of code that calls >

Re: [Python-Dev] PEP 467: Minor API improvements to bytes, bytearray, and memoryview

On 7 June 2016 at 21:56, Nick Coghlan wrote: > On 7 June 2016 at 14:33, Paul Sokolovsky wrote: >> Ethan Furman wrote: >>> Deprecation of current "zero-initialised sequence" behaviour >>>

Re: [Python-Dev] PEP 520: Ordered Class Definition Namespace

On Tue, Jun 7, 2016 at 6:20 PM, Ethan Furman wrote: > On 06/07/2016 05:50 PM, Eric Snow wrote: >> __definition_order__ = tuple(k for k in locals() >> if (!k.startswith('__') or >>

Re: [Python-Dev] PEP 467: Minor API improvements to bytes, bytearray, and memoryview

On Wed, Jun 08, 2016 at 02:17:12AM +0300, Paul Sokolovsky wrote: > Hello, > > On Tue, 07 Jun 2016 15:46:00 -0700 > Ethan Furman wrote: > > > On 06/07/2016 02:33 PM, Paul Sokolovsky wrote: > > > > >> This PEP proposes to deprecate that behaviour in Python 3.6, and > > >>

Re: [Python-Dev] PEP 520: Ordered Class Definition Namespace

On 06/07/2016 05:50 PM, Eric Snow wrote: Overall +1. Some nits below. Specification = 3. types for which `__prepare__()`` returned something other than ``OrderedDict`` (or a subclass) have their ``__definition_order__`` set to ``None`` (unless

Re: [Python-Dev] PEP: Ordered Class Definition Namespace

On Tue, Jun 07, 2016 at 11:39:06AM -0700, Eric Snow wrote: > On Tue, Jun 7, 2016 at 11:32 AM, Terry Reedy wrote: > > On 6/7/2016 1:51 PM, Eric Snow wrote: > > > >> Note: just to be clear, this PEP is *not* about changing > > > >> ``type.__dict__`` to ``OrderedDict``. > > > > By

[Python-Dev] PEP 520: Ordered Class Definition Namespace

I've grabbed a PEP # (520) and updated the PEP to clarify points that were brought up earlier today. Given positive feedback I got at PyCon and the reaction today, I'm hopeful the PEP isn't far off from pronouncement. :) -eric == PEP: 520 Title: Ordered

Re: [Python-Dev] PEP 467: Minor API improvements to bytes, bytearray, and memoryview

Hello, On Tue, 07 Jun 2016 15:46:00 -0700 Ethan Furman wrote: > On 06/07/2016 02:33 PM, Paul Sokolovsky wrote: > > >> This PEP proposes to deprecate that behaviour in Python 3.6, and > >> remove it entirely in Python 3.7. > > > > Why the desire to break applications of

Re: [Python-Dev] PEP: Ordered Class Definition Namespace

On 7 June 2016 at 16:03, Raymond Hettinger wrote: > >> On Jun 7, 2016, at 10:51 AM, Eric Snow wrote: >> >> This PEP changes the default class definition namespace to ``OrderedDict``. > > I think this would be a nice improvement. > >>

Re: [Python-Dev] PEP: Ordered Class Definition Namespace

> On Jun 7, 2016, at 10:51 AM, Eric Snow wrote: > > This PEP changes the default class definition namespace to ``OrderedDict``. I think this would be a nice improvement. > Furthermore, the order in which the attributes are defined in each class > body will now be

Re: [Python-Dev] PEP 467: Minor API improvements to bytes, bytearray, and memoryview

On 7 June 2016 at 15:22, Koos Zevenhoven wrote: > On Wed, Jun 8, 2016 at 12:57 AM, Barry Warsaw wrote: >> On Jun 07, 2016, at 09:40 PM, Brett Cannon wrote: >> >>>On Tue, 7 Jun 2016 at 14:38 Paul Sokolovsky wrote: What's wrong with

Re: [Python-Dev] PEP 467: Minor API improvements to bytes, bytearray, and memoryview

On 06/07/2016 02:33 PM, Paul Sokolovsky wrote: This PEP proposes to deprecate that behaviour in Python 3.6, and remove it entirely in Python 3.7. Why the desire to break applications of thousands and thousands of people? Besides, bytes(3) behavior is very logical. Everyone who knows what

Re: [Python-Dev] PEP: Ordered Class Definition Namespace

On 06/07/2016 03:27 PM, Eric Snow wrote: Not all attrs are writable and it's a case-by-case situation: some of the ones that are writable started out read-only and changed once there was a valid reason. If anything, it's arguably safer in general to take an immutable-by-default approach. I'm

Re: [Python-Dev] PEP: Ordered Class Definition Namespace

On Tue, Jun 7, 2016 at 2:34 PM, Ethan Furman wrote: > On 06/07/2016 02:20 PM, Eric Snow wrote: >> I think both of those make __definition_order__ more complicated and >> less useful. As the PEP stands, folks can be confident in what >> __definition_order__ represents. What

Re: [Python-Dev] PEP 467: Minor API improvements to bytes, bytearray, and memoryview

On Wed, Jun 8, 2016 at 12:57 AM, Barry Warsaw wrote: > On Jun 07, 2016, at 09:40 PM, Brett Cannon wrote: > >>On Tue, 7 Jun 2016 at 14:38 Paul Sokolovsky wrote: >>> What's wrong with b[i:i+1] ? >>It always succeeds while indexing can trigger an IndexError. > >

Re: [Python-Dev] PEP 467: Minor API improvements to bytes, bytearray, and memoryview

On Jun 07, 2016, at 09:40 PM, Brett Cannon wrote: >On Tue, 7 Jun 2016 at 14:38 Paul Sokolovsky wrote: >> What's wrong with b[i:i+1] ? >It always succeeds while indexing can trigger an IndexError. Right. You want a method with the semantics of __getitem__() but that returns

Re: [Python-Dev] PEP 467: Minor API improvements to bytes, bytearray, and memoryview

Ignore that message. I hit send before brain and hands were fully in sync. > -Original Message- > From: tritium-l...@sdamon.com [mailto:tritium-l...@sdamon.com] > Sent: Tuesday, June 7, 2016 5:51 PM > To: 'Nick Coghlan' ; 'Barry Warsaw' > > Cc:

Re: [Python-Dev] PEP 467: Minor API improvements to bytes, bytearray, and memoryview

On 7 June 2016 at 14:33, Paul Sokolovsky wrote: > Hello, > > On Tue, 07 Jun 2016 13:28:13 -0700 > Ethan Furman wrote: > >> Minor changes: updated version numbers, add punctuation. >> >> The current text seems to take into account Guido's last comments. >>

Re: [Python-Dev] PEP: Ordered Class Definition Namespace

On Tue, Jun 7, 2016 at 2:34 PM, Nick Coghlan wrote: > On 7 June 2016 at 14:20, Eric Snow wrote: >> What would you consider to be the >> benefit of a mutable (or replaceable) __definition_order__ that >> outweighs the benefit of a simpler

Re: [Python-Dev] PEP 467: Minor API improvements to bytes, bytearray, and memoryview

> -Original Message- > From: Python-Dev [mailto:python-dev-bounces+tritium- > list=sdamon@python.org] On Behalf Of Nick Coghlan > Sent: Tuesday, June 7, 2016 5:40 PM > To: Barry Warsaw > Cc: python-dev@python.org > Subject: Re: [Python-Dev] PEP 467: Minor API

Re: [Python-Dev] PEP 467: Minor API improvements to bytes, bytearray, and memoryview

On Tue, 7 Jun 2016 at 14:38 Paul Sokolovsky wrote: > Hello, > > On Tue, 7 Jun 2016 17:31:19 -0400 > Barry Warsaw wrote: > > > On Jun 07, 2016, at 01:28 PM, Ethan Furman wrote: > > > > >* Add ``bytes.iterbytes``, ``bytearray.iterbytes`` and > > >

Re: [Python-Dev] PEP 467: Minor API improvements to bytes, bytearray, and memoryview

On 7 June 2016 at 14:31, Barry Warsaw wrote: > On Jun 07, 2016, at 01:28 PM, Ethan Furman wrote: > >>* Add ``bytes.iterbytes``, ``bytearray.iterbytes`` and >> ``memoryview.iterbytes`` alternative iterators > > +1 but I want to go just a little farther. > > We can't change

Re: [Python-Dev] PEP: Ordered Class Definition Namespace

On 7 June 2016 at 14:20, Eric Snow wrote: > On Tue, Jun 7, 2016 at 12:30 PM, Nick Coghlan wrote: >> The main alternative would be to make __definition_order__ writable, >> so the default behaviour would be for it to reflect the original class >>

Re: [Python-Dev] PEP 467: Minor API improvements to bytes, bytearray, and memoryview

Hello, On Tue, 7 Jun 2016 17:31:19 -0400 Barry Warsaw wrote: > On Jun 07, 2016, at 01:28 PM, Ethan Furman wrote: > > >* Add ``bytes.iterbytes``, ``bytearray.iterbytes`` and > > ``memoryview.iterbytes`` alternative iterators > > +1 but I want to go just a little farther. >

Re: [Python-Dev] PEP: Ordered Class Definition Namespace

On 06/07/2016 02:20 PM, Eric Snow wrote: On Tue, Jun 7, 2016 at 12:30 PM, Nick Coghlan wrote: On 7 June 2016 at 10:51, Eric Snow wrote: * ``__definition_order__`` is a tuple * ``__definition_order__`` is a read-only attribute Thinking about the class decorator use case, I think this may

Re: [Python-Dev] PEP 467: Minor API improvements to bytes, bytearray, and memoryview

On Tue, Jun 7, 2016 at 11:28 PM, Ethan Furman wrote: > > Minor changes: updated version numbers, add punctuation. > > The current text seems to take into account Guido's last comments. > > Thoughts before asking for acceptance? > > PEP: 467 > Title: Minor API improvements for

Re: [Python-Dev] PEP 467: Minor API improvements to bytes, bytearray, and memoryview

On Jun 07, 2016, at 01:28 PM, Ethan Furman wrote: >* Add ``bytes.iterbytes``, ``bytearray.iterbytes`` and > ``memoryview.iterbytes`` alternative iterators +1 but I want to go just a little farther. We can't change bytes.__getitem__ but we can add another method that returns single byte

Re: [Python-Dev] PEP: Ordered Class Definition Namespace

On Tue, Jun 7, 2016 at 12:30 PM, Nick Coghlan wrote: > On 7 June 2016 at 10:51, Eric Snow wrote: >> * ``__definition_order__`` is a tuple >> * ``__definition_order__`` is a read-only attribute > > Thinking about the class decorator use case, I

Re: [Python-Dev] C99

Nathaniel Smith wrote: > No-one's proposing to use C99 indiscriminately; > There's no chance that CPython is going to drop MSVC support in 3.6. Stinner was proposing that by saying "Is it worth to support a compiler that in 2016 doesn't support the C standard released in 1999,

Re: [Python-Dev] C99

On Tue, Jun 7, 2016 at 12:37 PM, Sturla Molden wrote: > Victor Stinner wrote: > >> Is it worth to support a compiler that in 2016 doesn't support the C >> standard released in 1999, 17 years ago? > > MSVC only supports C99 when its needed for

Re: [Python-Dev] C99

We should definitely keep supporting MSVC. --Guido (mobile) On Jun 7, 2016 12:39 PM, "Sturla Molden" wrote: > Victor Stinner wrote: > > > Is it worth to support a compiler that in 2016 doesn't support the C > > standard released in 1999, 17

[Python-Dev] PEP 467: Minor API improvements to bytes, bytearray, and memoryview

Minor changes: updated version numbers, add punctuation. The current text seems to take into account Guido's last comments. Thoughts before asking for acceptance? PEP: 467 Title: Minor API improvements for binary sequences Version: $Revision$ Last-Modified: $Date$ Author: Nick Coghlan

Re: [Python-Dev] C99

Doesn't Cygwin build against the posix abstraction layer? Wouldn't a python built as such operate as though it was on a unix of some sort? It has been quite a while since I messed with Cygwin - if it hasn't changed, it's not really an option, especially when we have native windows builds now.

Re: [Python-Dev] C99

Victor Stinner wrote: > Is it worth to support a compiler that in 2016 doesn't support the C > standard released in 1999, 17 years ago? MSVC only supports C99 when its needed for C++11 or some MS extension to C. Is it worth supporting MSVC? If not, we have Intel C,

Re: [Python-Dev] PEP: Ordered Class Definition Namespace

On 7 June 2016 at 10:51, Eric Snow wrote: > Specification > = > > * the default class *definition* namespace is now ``OrderdDict`` > * the order in which class attributes are defined is preserved in the > new ``__definition_order__`` attribute on each

Re: [Python-Dev] PEP: Ordered Class Definition Namespace

> From: Eric Snow > Sent: Tuesday, June 07, 2016 2:52 PM > To: Émanuel Barry > Cc: Python-Dev > Subject: Re: [Python-Dev] PEP: Ordered Class Definition Namespace > > "dunder" names (not just methods) will not be present in > __definition_order__. I'll add an explanation to the PEP. The gist >

Re: [Python-Dev] PEP: Ordered Class Definition Namespace

On Tue, Jun 7, 2016 at 11:45 AM, Ethan Furman wrote: > On 06/07/2016 11:13 AM, Eric Snow wrote: >> A __definition_order__ in the class body always takes precedence. So >> a supplied value will be honored (and not replaced with None). > > Will the supplied __definition_order__

Re: [Python-Dev] PEP: Ordered Class Definition Namespace

On Tue, Jun 7, 2016 at 11:36 AM, Émanuel Barry wrote: >> From: Eric Snow >> * "dunder" attributes (e.g. ``__init__``, ``__module__``) are ignored > > What does this imply? If I define some __dunder__ methods, will they simply > not be present in __definition_order__? What if I

Re: [Python-Dev] Proper way to specify that a method is not defined for a type

For those interested in this topic, if you are not already aware of it, see also http://bugs.python.org/issue25958, which among other things has a relevant proposed patch for datamode.rst. On Tue, 07 Jun 2016 10:56:37 -0700, Guido van Rossum wrote: > Setting it to None in the

Re: [Python-Dev] PEP: Ordered Class Definition Namespace

On 06/07/2016 11:13 AM, Eric Snow wrote: On Tue, Jun 7, 2016 at 11:01 AM, Ethan Furman wrote: On 06/07/2016 10:51 AM, Eric Snow wrote: Specification = * types for which `__prepare__()`` returned something other than ``OrderedDict`` (or a subclass)

Re: [Python-Dev] PEP: Ordered Class Definition Namespace

On Tue, Jun 7, 2016 at 11:32 AM, Terry Reedy wrote: > On 6/7/2016 1:51 PM, Eric Snow wrote: > >> Note: just to be clear, this PEP is *not* about changing > >> ``type.__dict__`` to ``OrderedDict``. > > By 'type', do you mean the one and one objected named 'type or the class >

Re: [Python-Dev] PEP: Ordered Class Definition Namespace

> From: Eric Snow > Sent: Tuesday, June 07, 2016 1:52 PM > To: Python-Dev > Subject: [Python-Dev] PEP: Ordered Class Definition Namespace > > > Currently the namespace used during execution of a class body defaults > to dict. If the metaclass defines ``__prepare__()`` then the result of >

Re: [Python-Dev] PEP: Ordered Class Definition Namespace

On 6/7/2016 1:51 PM, Eric Snow wrote: Note: just to be clear, this PEP is *not* about changing > ``type.__dict__`` to ``OrderedDict``. By 'type', do you mean the one and one objected named 'type or the class being defined? To be really clear, will the following change? >>> class C: pass

Re: [Python-Dev] PEP: Ordered Class Definition Namespace

On Tue, Jun 7, 2016 at 11:01 AM, Ethan Furman wrote: > On 06/07/2016 10:51 AM, Eric Snow wrote: >> Specification >> = > > >>* types for which `__prepare__()`` returned something other than >> ``OrderedDict`` (or a subclass) have their

Re: [Python-Dev] PEP: Ordered Class Definition Namespace

On 06/07/2016 10:51 AM, Eric Snow wrote: My intention was to land the patch soon, having gone through code review during PyCon. However, Nick pointed out to me the benefit of having a concrete point of reference for the change, as well as making sure it isn't a problem for other

Re: [Python-Dev] Proper way to specify that a method is not defined for a type

Setting it to None in the subclass is the intended pattern. But CPython must explicitly handle that somewhere so I don't know how general it is supported. Try defining a list subclass with __len__ set to None and see what happens. Then try the same with MutableSequence. On Tue, Jun 7, 2016 at

Re: [Python-Dev] Proper way to specify that a method is not defined for a type

> From: Ethan Furman > Sent: Tuesday, June 07, 2016 1:38 PM > To: Python Dev > Subject: [Python-Dev] Proper way to specify that a method is not defined for > a type (Just so everyone follows, this is a followup of http://bugs.python.org/issue27242 ) > For binary methods, such as __add__, either

[Python-Dev] PEP: Ordered Class Definition Namespace

Hi all, Following discussion a few years back (and rough approval from Guido [1]), I started work on using OrderedDict for the class definition namespace by default. The bulk of the effort lay in implementing OrderedDict in C, which I got landed just in time for 3.5. The remaining work was

[Python-Dev] Proper way to specify that a method is not defined for a type

For binary methods, such as __add__, either do not implement or return NotImplemented if the other operand/class is not supported. For non-binary methods, simply do not define. Except for subclasses when the super-class defines __hash__ and the subclass is not hashable -- then set __hash__ to

Re: [Python-Dev] C99

So here's the diffs that seem to indicate we were working with a compiler that wasn't full C99 (or maybe previously we were working with a compiler that had extensions?) https://github.com/dropbox/typed_ast/commit/f7497e25abc3bcceced3ca6c3be3786d8805df41 On Tue, Jun 7, 2016 at 8:18 AM, Guido van

Re: [Python-Dev] C99

I'll ask my colleague what his compiler setup was. On Tue, Jun 7, 2016 at 3:24 AM, Victor Stinner wrote: > Hi, > > 2016-06-04 19:47 GMT+02:00 Guido van Rossum : > > Funny. Just two weeks ago I was helping someone who discovered a > > compiler that

Re: [Python-Dev] C99

Hi, 2016-06-04 19:47 GMT+02:00 Guido van Rossum : > Funny. Just two weeks ago I was helping someone who discovered a > compiler that doesn't support the new relaxed variable declaration > rules. I think it was on Windows. Maybe this move is a little too > aggressively