Re: [Python-Dev] PEP487: Simpler customization of class creation

2016-07-18 Thread Neil Girdhar
Yes, I see what you're saying. However, I don't understand why __init_subclass__ (defined on some class C) cannot be used to implement the checks required by @abstractmethod instead of doing it in ABCMeta. This would prevent metaclass conflicts since you could use @abstractmethod with any metacl

Re: [Python-Dev] Fun with ExitStack

2016-07-18 Thread Nick Coghlan
On 19 July 2016 at 09:40, Barry Warsaw wrote: > Ah, the try-finally changes the behavior! There's probably some documentation > somewhere that defines how a generator gets finalized, and that triggers the > finally clause, whereas in the previous example, nothing after the yield gets > run. I ju

Re: [Python-Dev] PEP487: Simpler customization of class creation

2016-07-18 Thread Nick Coghlan
On 19 July 2016 at 09:26, Neil Girdhar wrote: > Yes, I'm very excited about this! > > Will this mean no more metaclass conflicts if using @abstractmethod? ABCMeta and EnumMeta both create persistent behavioural differences rather than only influencing subtype definition, so they'll need to remain

Re: [Python-Dev] PEP 467: next round

2016-07-18 Thread Nick Coghlan
On 19 July 2016 at 08:00, Ethan Furman wrote: > On 07/18/2016 02:45 PM, Brett Cannon wrote: >> >> On Mon, 18 Jul 2016 at 14:35 Alexander Belopolsky wrote: >>> >>> On Mon, Jul 18, 2016 at 5:01 PM, Jonathan Goble wrote: > > full(), despite its use in numpy, is also unintuitive to me (my first >

Re: [Python-Dev] PEP 467: next round

2016-07-18 Thread Nick Coghlan
(Thanks for moving this forward, Ethan!) On 19 July 2016 at 06:17, Ethan Furman wrote: > * Add ``bytes.getbyte`` and ``bytearray.getbyte`` byte retrieval methods > * Add ``bytes.iterbytes``, ``bytearray.iterbytes`` and > ``memoryview.iterbytes`` alternative iterators As a possible alternative

Re: [Python-Dev] Fun with ExitStack

2016-07-18 Thread Martin Panter
On 18 July 2016 at 23:40, Barry Warsaw wrote: > I was trying to debug a problem in some work code and I ran into some > interesting oddities with contextlib.ExitStack and other context managers in > Python 3.5. > > This program creates a temporary directory, and I wanted to give it a --keep > flag

[Python-Dev] Fun with ExitStack

2016-07-18 Thread Barry Warsaw
I was trying to debug a problem in some work code and I ran into some interesting oddities with contextlib.ExitStack and other context managers in Python 3.5. This program creates a temporary directory, and I wanted to give it a --keep flag to not automatically delete the tempdir at program exit.

Re: [Python-Dev] PEP487: Simpler customization of class creation

2016-07-18 Thread Neil Girdhar
Yes, I'm very excited about this! Will this mean no more metaclass conflicts if using @abstractmethod? On Sun, Jul 17, 2016 at 12:59 PM Guido van Rossum wrote: > This PEP is now accepted for inclusion in Python 3.6. Martin, > congratulations! Someone (not me) needs to review and commit your > c

Re: [Python-Dev] PEP 467: next round

2016-07-18 Thread Brett Cannon
On Mon, 18 Jul 2016 at 15:49 Random832 wrote: > On Mon, Jul 18, 2016, at 17:34, Alexander Belopolsky wrote: > > On Mon, Jul 18, 2016 at 5:01 PM, Jonathan Goble > > wrote: > > > > > full(), despite its use in numpy, is also unintuitive to me (my first > > > thought is that it would indicate wheth

Re: [Python-Dev] PEP 467: next round

2016-07-18 Thread Random832
On Mon, Jul 18, 2016, at 17:34, Alexander Belopolsky wrote: > On Mon, Jul 18, 2016 at 5:01 PM, Jonathan Goble > wrote: > > > full(), despite its use in numpy, is also unintuitive to me (my first > > thought is that it would indicate whether an object has room for more > > entries). > > > > Perhap

Re: [Python-Dev] PEP 467: next round

2016-07-18 Thread Alexander Belopolsky
On Mon, Jul 18, 2016 at 6:00 PM, Ethan Furman wrote: > bytes.fromsize() sounds good to me, thanks for brainstorming that one for > me. > +1 ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscrib

Re: [Python-Dev] PEP 467: next round

2016-07-18 Thread Ethan Furman
On 07/18/2016 02:45 PM, Brett Cannon wrote: On Mon, 18 Jul 2016 at 14:35 Alexander Belopolsky wrote: On Mon, Jul 18, 2016 at 5:01 PM, Jonathan Goble wrote: full(), despite its use in numpy, is also unintuitive to me (my first thought is that it would indicate whether an object has room for mo

Re: [Python-Dev] PEP 467: next round

2016-07-18 Thread Ethan Furman
On 07/18/2016 02:01 PM, Jonathan Goble wrote: This PEP isn't revisiting that original design decision, just changing the spelling as users sometimes find the current behaviour of the binary sequence constructors surprising. In particular, there's a reasonable case to be made that ``bytes(x)`` (w

Re: [Python-Dev] PEP 467: next round

2016-07-18 Thread Brett Cannon
On Mon, 18 Jul 2016 at 14:35 Alexander Belopolsky < alexander.belopol...@gmail.com> wrote: > > On Mon, Jul 18, 2016 at 5:01 PM, Jonathan Goble > wrote: > >> full(), despite its use in numpy, is also unintuitive to me (my first >> thought is that it would indicate whether an object has room for mo

Re: [Python-Dev] PEP 467: next round

2016-07-18 Thread Alexander Belopolsky
On Mon, Jul 18, 2016 at 5:01 PM, Jonathan Goble wrote: > full(), despite its use in numpy, is also unintuitive to me (my first > thought is that it would indicate whether an object has room for more > entries). > > Perhaps bytes.fillsize? > I wouldn't want to see bytes.full() either. Maybe byte

Re: [Python-Dev] PEP 467: next round

2016-07-18 Thread Jonathan Goble
*de-lurks* On Mon, Jul 18, 2016 at 4:45 PM, Alexander Belopolsky wrote: > On Mon, Jul 18, 2016 at 4:17 PM, Ethan Furman wrote: >> >> - 'bytes.zeros' renamed to 'bytes.size', with option byte filler >> (defaults to b'\x00') > > > Seriously? You went from a numpy-friendly feature to something r

Re: [Python-Dev] PEP 467: next round

2016-07-18 Thread Alexander Belopolsky
On Mon, Jul 18, 2016 at 4:17 PM, Ethan Furman wrote: > - 'bytes.zeros' renamed to 'bytes.size', with option byte filler > (defaults to b'\x00') > Seriously? You went from a numpy-friendly feature to something rather numpy-hostile. In numpy, ndarray.size is an attribute that returns the number

[Python-Dev] PEP 467: next round

2016-07-18 Thread Ethan Furman
Taking into consideration the comments from the last round: - 'bytes.zeros' renamed to 'bytes.size', with option byte filler (defaults to b'\x00') - 'bytes.byte' renamed to 'fromint', add 'bchr' function - deprecation and removal softened to deprecation/discouragement --- PEP: 467 Tit

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

2016-07-18 Thread Ethan Furman
On 06/07/2016 02:34 PM, Koos Zevenhoven wrote: Why not bytes.viewbytes (or whatever name) so that one could also subscript it? And if it were a property, one could perhaps conveniently get the n'th byte: b'abcde'.viewbytes[n] # compared to b'abcde'[n:n+1] AFAICT, 'viewbytes' doesn't add muc

Re: [Python-Dev] PEP487: Simpler customization of class creation

2016-07-18 Thread Eric Snow
Great job, Martin! Thanks for seeing this through. :) -eric On Sun, Jul 17, 2016 at 10:57 AM, Guido van Rossum wrote: > This PEP is now accepted for inclusion in Python 3.6. Martin, > congratulations! Someone (not me) needs to review and commit your > changes, before September 12, when the 3.6

Re: [Python-Dev] PEP 514: Python registration in the Windows registry

2016-07-18 Thread Paul Moore
On 18 July 2016 at 17:33, Steve Dower wrote: >> Some comments below. > > Awesome, thanks! Posted a pull request at > https://github.com/python/peps/pull/59 for ease of diff reading, and some > commentary below (with aggressive snipping). Thanks - I'll do a proper review of that, but just wanted t

Re: [Python-Dev] PEP 514: Python registration in the Windows registry

2016-07-18 Thread Steve Dower
On 16Jul2016 1254, Paul Moore wrote: On 15 July 2016 at 23:20, Steve Dower wrote: Hi all I'd like to get this PEP approved (status changed to Active, IIUC). Some comments below. Awesome, thanks! Posted a pull request at https://github.com/python/peps/pull/59 for ease of diff reading, and