For me, it looks normal because I am used to seeing pattern matching for
function parameters in functional programming languages. However, if we write
“case” before “def” similar to “async” before “def” in async function it should
be clear we are doing pattern matching. The function will be name
> On 7 Aug 2021, at 19:22, Serhiy Storchaka wrote:
>
> Python integers have arbitrary precision. For serialization and
> interpolation with other programs and libraries we need to represent
> them as fixed-width integers (little- and big-endian, signed and
> unsigned). In Python, we can use st
Abdulla Al Kathiri writes:
> case def fib(0):
> return 0
This syntax (1) is a new, slightly shorter version of something we can
already do as you point out yourself, and (2) plausibly is something
of a bug magnet if someone does
case def fib(1):
case def fib(2):
def fib(n):
Plausible !=
On 2021-08-08 at 09:41:34 +0100,
Barry Scott wrote:
> What is mixed endian? I would guess that its use would be application
> specific - so I assume you would not need to support it.
Not AFAIK application specific, but hardware specific:
https://en.wikipedia.org/wiki/Endianness#Mixed
__
On 2021-08-08 at 11:30:20 +0400,
Abdulla Al Kathiri wrote:
> ... if we write “case” before “def” similar to “async” before “def” in
> async function it should be clear we are doing pattern matching. The
> function will be named case function.
>
> case def fib(0):
> return 0
>
> case def f
If you are going to add a new case function somewhere in the middle of a REPL
session because order matters, maybe break it with anything like write a number
or something.. and then repeat the case functions with the order you wish. Now
the new case functions will overwrite whatever you wrote be
08.08.21 07:08, Stephen J. Turnbull пише:
> Serhiy Storchaka writes:
>
> > Python integers have arbitrary precision. For serialization and
> > interpolation with other programs and libraries we need to
> > represent them [...]. [In the case of non-standard precisions,]
> > [t]here are private
08.08.21 11:41, Barry Scott пише:
>> On 7 Aug 2021, at 19:22, Serhiy Storchaka wrote:
>> 1. How to encode the byte order?
>>
>> a) 1 -- little endian, 0 -- big endian
>> b) 0 -- little endian, 1 -- big endian
>> c) -1 -- little endian, +1 -- big endian, 0 -- native endian.
>
> Use an enum and do
Hi. I would like to suggest to add functionality to argparse
For example we can have one ArgumentParser instance, for (windows, linux),
(community edition, pro edition) apps. It could give ability to show and be
able to run only allowed commands based on version of os, app or some other
logic.
On 2021-08-08 at 21:37:28 -,
Hasan Aliyev wrote:
> For example we can have one ArgumentParser instance, for (windows, linux),
> (community edition, pro edition) apps. It could give ability to show and be
> able to run only allowed commands based on version of os, app or some other
> logic.
I lack the relevant experience to have an opinion on most of this, but FWIW
"PyLong_FromBytes/PyLong_ToBytes' seems clearest to me out of the options
proposed.
On Sat, Aug 7, 2021 at 2:23 PM Serhiy Storchaka wrote:
> Python integers have arbitrary precision. For serialization and
> interpolation
This is a proposal to change the behaviour of the startswith() and
endswith() methods for str, bytes and bytearray objects, making them
return the matched value instead of the True boolean.
Here a str example with the endswith() method:
domain = "python.org"
if domain.endswith(".fr"):
print(
On Mon, Aug 9, 2021 at 1:42 PM wrote:
>
> This is a proposal to change the behaviour of the startswith() and
> endswith() methods for str, bytes and bytearray objects, making them
> return the matched value instead of the True boolean.
Unfortunately this would break backward compatibility, since
09.08.21 05:05, [email protected] пише:
> This is a proposal to change the behaviour of the startswith() and
> endswith() methods for str, bytes and bytearray objects, making them
> return the matched value instead of the True boolean.
And what should it return for empty matched value?
On Sun, Aug 8, 2021 at 9:54 AM Serhiy Storchaka wrote:
> 1. Support conversion to/from all C integer types (char, short, int,
> long, long long, intN_t, intptr_t, intmax_t, wchar_t, wint_t and
> corresponding unsigned types),
I suggest support for the "new" C sized types available in
Why anyo
15 matches
Mail list logo
