Re: [Python-Dev] Fun with ExitStack

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

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

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,

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

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

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

(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

Re: [Python-Dev] Fun with ExitStack

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

[Python-Dev] Fun with ExitStack

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[Python-Dev] PEP 467: next round

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

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

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

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

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

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

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