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
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
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
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
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
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
*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
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
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
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
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
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
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
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
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
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.
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
(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
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
>
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
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
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
22 matches
Mail list logo
