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
(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
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
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
> >
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
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
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)``
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
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
*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?
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
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
12 matches
Mail list logo