bytes.ord is a bad name, given the behavior would be the opposite of ord
(ord converts length one str to int, not int to length one str).
PEP467 (currently deferred to 3.9 or later) does have proposals for this
case, either bytes.byte (old proposal:
Hi Luca,
I'm the original author of the statistics module, and I'm very
interested in your idea for calculating running statistics. However
feature-freeze for 3.8 is not far away (about three weeks) so I think it
would have to be deferred until 3.9.
But I encourage you to give some thought
On Tue, May 07, 2019 at 09:54:03AM +1000, Cameron Simpson wrote:
> On 06May2019 18:47, Antoine Pitrou wrote:
[...]
> >The main constructors for built-in types are used so pervasively that
> >there is no hope of actually removing such deprecated behavior.
>
> I don't find that compelling. I for
On 06May2019 18:47, Antoine Pitrou wrote:
On Mon, 6 May 2019 19:39:39 +0300
Serge Matveenko wrote:
On Mon, May 6, 2019 at 7:29 PM Guido van Rossum wrote:
> On Mon, May 6, 2019 at 11:14 AM Serhiy Storchaka wrote:
>> I do not propose to change the current behavior. I propose to add new
>>
On Sun, May 05, 2019 at 04:23:58AM +0300, Serge Matveenko wrote:
> So, I would like to propose adding a third main object called
> `interface` in addition to `object` and `type` and to use it to define
> interface objects.
Having read this thread, I think the proposal is complex enough that
On Fri, Apr 26, 2019 at 11:14:32AM +1200, Greg Ewing wrote:
> Steven D'Aprano wrote:
> >But having the opening bracket auto-added is a small satisfaction, and
> >if you're using the REPL for actual calculations and not just help(),
> >the benefit probably outweighs the annoyance
>
> The
On Thu, Apr 25, 2019 at 02:42:09PM +0100, Stefano Borini wrote:
> PyCharm adds the parenthesis, but also adds the end parenthesis, so
> the whole use of parentheses is consistent: the user has not to worry
> about them.
> Bash refuses to guess when it's ambiguous, and stops until you fill
> the
On Mon, May 06, 2019 at 07:39:39PM +0300, Serge Matveenko wrote:
> With all respect, I disagree. There are ways to evolve Python such as
> deprecation policies which proven to be effective. There are ways to
> monitor current features adoption on PyPI to see whether it is safe to
> remove
I've often wanted a windowing function in itertools. One exists as a recipe
in the docs. If I remember correctly, one reason this was never implemented
is that the most efficient implementation changes depending on the size of
the window.
Use a deque(maxsize=n) for large windows and tuple
пн, 6 мая 2019 г. в 19:48, Antoine Pitrou :
> On Mon, 6 May 2019 19:39:39 +0300
> Serge Matveenko wrote:
> > On Mon, May 6, 2019 at 7:29 PM Guido van Rossum
> wrote:
> > >
> > > On Mon, May 6, 2019 at 11:14 AM Serhiy Storchaka
> wrote:
> > >> I do not propose to change the current behavior. I
On Sun, May 5, 2019 at 1:08 PM Luca Baldini wrote:
>
> Hi here,
> I wonder if the idea of adding to the statistics module a class to
> calculate the running statistics (average and standard deviation) of a
> generic input data stream has ever come up in the past.
>
> The basic idea is to do the
On Mon, May 6, 2019 at 7:48 PM Antoine Pitrou wrote:
>
> On Mon, 6 May 2019 19:39:39 +0300
> Serge Matveenko wrote:
> > With all respect, I disagree. There are ways to evolve Python such as
> > deprecation policies which proven to be effective. There are ways to
> > monitor current features
On Mon, May 6, 2019 at 7:29 PM Guido van Rossum wrote:
>
> On Mon, May 6, 2019 at 11:14 AM Serhiy Storchaka wrote:
>> I do not propose to change the current behavior. I propose to add new
>> named constructors. In most cases default constructors can be used, but
>> in cases when we use type
On Mon, 6 May 2019 19:39:39 +0300
Serge Matveenko wrote:
> On Mon, May 6, 2019 at 7:29 PM Guido van Rossum wrote:
> >
> > On Mon, May 6, 2019 at 11:14 AM Serhiy Storchaka
> > wrote:
> >> I do not propose to change the current behavior. I propose to add new
> >> named constructors. In most
On Mon, May 6, 2019 at 11:14 AM Serhiy Storchaka
wrote:
> 06.05.19 17:49, Guido van Rossum пише:
> > 20-25 years ago this might have been a good idea. Unfortunately there's
> > so much code (including well-publicized example code) that I'm not sure
> > it's a good use of anyone's time to try and
06.05.19 17:49, Guido van Rossum пише:
20-25 years ago this might have been a good idea. Unfortunately there's
so much code (including well-publicized example code) that I'm not sure
it's a good use of anyone's time to try and fix this.
I do not propose to change the current behavior. I
On Mon, May 6, 2019 at 5:33 PM Ivan Levkivskyi wrote:
>
> On Mon, 6 May 2019 at 03:23, Serge Matveenko wrote:
>>
>> On Sun, May 5, 2019 at 8:23 PM Stephen J. Turnbull
>> wrote:
>> >
>> > Serge Matveenko writes:
>> >
>> > > So, I would like to propose adding a third main object called
>> > >
The other bytes object constructor I often find myself in need of without
being able to remember how to do it is creating a a length 1 bytes object
from a known ordinal. The "obvious":
someordinal = ...
bytes(someordinal)
creates a zeroed bytes of that length, which is clearly wrong. I
20-25 years ago this might have been a good idea. Unfortunately there's so
much code (including well-publicized example code) that I'm not sure it's a
good use of anyone's time to try and fix this.
Exception: I am often in need of a constructor for a bytes object from an
integer using the decimal
On Mon, 6 May 2019 at 03:23, Serge Matveenko wrote:
> On Sun, May 5, 2019 at 8:23 PM Stephen J. Turnbull
> wrote:
> >
> > Serge Matveenko writes:
> >
> > > So, I would like to propose adding a third main object called
> > > `interface` in addition to `object` and `type` and to use it to
Constructors for builtin types is too overloaded.
For example, int constructor:
* Converts a number (with truncation) to an integer.
* Parses human readable representation of integer from string or
bytes-like object. Optional base can be specified. Note that there is an
alternate constructor
21 matches
Mail list logo
