[Python-ideas] Re: startswith() and endswith() methods returning the matched value
09.08.21 05:05, fgalla...@gmail.com пише: > 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? ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/TIJOYJZVGEED3WG4LDPBPUSHMQL6T3AI/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: startswith() and endswith() methods returning the matched value
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 it's
currently guaranteed that they return precisely True or False, and
that can be used (eg) for indexing. To maintain that, you'd have to
create new methods which return the matched value or None (and can
then define startswith/endswith as the boolification of that). For
instance:
domain.findsuffix((".fr", ".com", ".org"))
ChrisA
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/722CDS6W3FKLPWF4TBGUBHOL2RA5LZUV/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] startswith() and endswith() methods returning the matched value
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(".fr")
elif domain.endswith(".com"):
print(".com")
elif domain.endswith("org"):
print(".org")
With the ".org" non-empty str returned by the endswith() method
instead of the True boolean, the above code will work in the same
manner; moreover as startswith() and endswith() methods support a
tuple as argument, and as the PEP 572 walrus operator is supported
since Python 3.8, we can now write this code in a more compact and
pythonic way:
if suffix := domain.endswith((".fr", ".com", ".org"):
print(suffix)
As the PEP 616 new methods removeprefix() and removesuffix() don't
support a tuple as argument, it will provide a nice and pythonic way
to do it:
if suffix := domain.endswith((".fr", ".com", ".org"):
print(domain[:-len(suffix)])
Hope I don't miss something obvious and that this proposal could
interest some people.
Best regards
Florent
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/2HTI6GKQPXGHTJKAI2OOJNZDUMIN2BUT/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: C API for converting Python integers to/from bytes sequences
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 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 struct, array, memoryview and ctypes > use for some standard sizes and int methods int.to_bytes and > int.from_bytes for non-standard sizes. In C, there is the C API for > converting to/from C types long, unsigned long, long long and unsigned > long long. For other C types (signed and unsigned char, short, int) we > need to use the C API for converting to long, and then truncate to the > destination type with checking for overflow. For integers type aliases > like pid_t we need to determine their size and signess and use > corresponding C API or wrapper. For non-standard integers (e.g. 24-bit), > integers wider than long long, and arbitrary precision integers all is > much more complicated. There are private C API functions > _PyLong_AsByteArray and _PyLong_FromByteArray, but they are for internal > use only. > > I am planning to add public analogs of these private functions, but more > powerful and convenient. > > PyObject *PyLong_FromBytes(const void *buf, Py_ssize_t size, >int byteorder, int signed) > > Py_ssize_t PyLong_AsBytes(PyObject *o, void *buf, Py_ssize_t n, > int byteorder, int signed, int *overflow) > > PyLong_FromBytes() returns the int object. It only fails in case of > memory error or incorrect arguments (e.g. buf is NULL). > > PyLong_AsBytes() writes bytes to the specified buffer, it does not > allocate memory. If buf is NULL it returns the minimum size of the > buffer for representing the integer. -1 is returned on error. if > overflow is NULL, then OverfowError is raised, otherwise *overflow is > set to +1 for overflowing the upper limit, -1 for overflowing the lower > limit, and 0 for no overflow. > > Now I have some design questions. > > 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. > > Do we need to reserve some values for mixed endians? > > 2. How to specify the reduction modulo 2**(8*size) (like in > PyLong_AsUnsignedLongMask)? > > Add yet one flag in PyLong_AsBytes()? Use special value for the signed > argument? 0 -- unsigned, 1 -- signed, 2 (or -1) -- modulo. Or use some > combination of signed and overflow? > > 3. How to specify saturation (like in PyNumber_AsSsize_t())? I.e. values > less than the lower limit are replaced with the lower limit, values > greater than the upper limit are replaced with the upper limit. > > Same options as for (2): separate flag, encode in signed (but we need > two values here) or combination of other parameters. > > 4. What exact names to use? > > PyLong_FromByteArray/PyLong_AsByteArray, > PyLong_FromBytes/PyLong_AsBytes, PyLong_FromBytes/PyLong_ToBytes? > > > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/V2EKXMKSQV25BMRPMDH47IM2OYCLY2TF/ > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/VVEKHEHP27I453YRW46T3HPJMTZFXLQT/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Argparse.add_argument() argument for additional functionallity
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.
>
> import argparse
>
> def some_callable():
> if edition() == 'pro_edition':
> return True
> return False
>
> parser = argparse.ArgumentParser(
> prog="CustomProgramm",
> description="CustomProgramms custom description",
> epilog='Epilog of this',
> )
>
> parser.add_argument('--full-function', target=some_callable)
>
> This --full-function argument will be available only if some_callable
> function is True, otherwise it will not be shown in command line arguments.
How/why is that better than
if some_callable():
parser.add_argument('--full-function')
especially if there's more than option in the "pro edition"?
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/BPUCESZHW5TODUO65WPQMV7SKQIUZPJC/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Argparse.add_argument() argument for additional functionallity
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.
import argparse
def some_callable():
if edition() == 'pro_edition':
return True
return False
parser = argparse.ArgumentParser(
prog="CustomProgramm",
description="CustomProgramms custom description",
epilog='Epilog of this',
)
parser.add_argument('--full-function', target=some_callable)
This --full-function argument will be available only if some_callable function
is True, otherwise it will not be shown in command line arguments.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/E2LMZQ2PAIBYMN3M64T4QBVYLWSHHG7K/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: C API for converting Python integers to/from bytes sequences
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 not use 0 as a valid value to make mistakes easier to > detect. > I think you are right to have big endian, little endian and native endian. > I do not think the numeric values of the enum matter (apart from avoiding 0). There is a precedence of using +1/-1/0 for big/little/native in the UTF16 and UTF32 codecs. I think that using the same convention will be more error-proof. > Maybe a single enum that has: > signed (modulo) > signed saturate > unsigned (modulo) > unsigned saturate There is a problem with enum -- the size of the type is not specified. It can be int, it can be 8 bits, it can be less than 8 bits in structure. Adding new members can change the size of the type. Therefore it is not stable for ABI. But combining options for signessness and overflow handling (or providing a set of functions for different overflow handling, because the output overflow parameters is not in all cases) may be the best option. ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/QETPJWGWERSQYY2VE25HDJBIFUEZUF25/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: C API for converting Python integers to/from bytes sequences
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 C API functions _PyLong_AsByteArray and > > _PyLong_FromByteArray, but they are for internal use only. > > > > I am planning to add public analogs of these private functions, but more > > powerful and convenient. > > > > PyObject *PyLong_FromBytes(const void *buf, Py_ssize_t size, > >int byteorder, int signed) > > > > Py_ssize_t PyLong_AsBytes(PyObject *o, void *buf, Py_ssize_t n, > > int byteorder, int signed, int *overflow) > > I don't understand why such a complex API is useful as a public facility. There are several goals: 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), POSIX integer types (pid_t, uid_t, off_t, etc) and other platfrom or library specific integer types (like Tcl_WideInt in libtcl). Currently only supported types are long, unsigned long, long long, unsigned long, ssize_t and size_t. For other types you should choose the most appropriate supertype (long or long long, sometimes providing several varians) and manually handle overflow. There are requests for PyLong_AsShort(), PyLong_AsInt32(), PyLong_AsMaxInt(), etc. It is better to provide a single universal function than extend API by several dozens functions. 2. Support different options for overflow handling. Different options are present in PyLong_AsLong(), PyLong_AsLongAndOverflow(), PyLong_AsUnsignedLongMask() and PyNumber_AsSsize_t(). But not all options are available for all types. There is no *AndOverflow() variant for unsigned types, size_t, ssize_t, and saturation is only available for ssize_t. 3. Support serialization of arbitrary precision integers. It is used in pickle and random, and can be used to support other binary data formats. All these goals can be achieved by few universal functions. > So I might want > PyLong_AsGMPInt and PyLong_AsGMPRatio as well as the corresponding > functions for MP, and maybe even PyLong_AsGMPFloat. The obvious way > to write those is (str(python_integer)), I think. PyLong_AsGMPInt() cannot be added until GMP be included in Python interpreter, and it is very unlikely. Converting via decimal representation is very inefficient way, especially for very long integers (it has cubic complexity from the size of the integer). I think GMP support more efficient conversions. > In the unlikely event that an > application needs to squeeze out that tiny bit of performance, I guess > the library constructors all accept buffers of bytes, too, probably > with a similarly complex API that can handle whatever the Python ABI > throws at them. For using the library constructors accepting buffers of bytes we need buffers of bytes. And the proposed functions provide the only interface for conversion Python integers to/from buffer of bytes. > In which case why not just expose the internal > functions? If you mean _PyLong_FromByteArray/_PyLong_AsByteArray, it is because we should polish them before exposing them. They currently do not provide different options for overflow, and I think that it may be more convenient way for common case of native bytes order. The names of functions, the number and order of parameters can be discussed. For such discussion I opened this thread. If you have alternative propositions, please show them. > Is it at all likely that that representation would ever > change? They do not rely on internal representation. They are for implementation-indepent representation. ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/HZTNOP63WRSHITFPTWJ526UCLNAVE2NS/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Pattern matching in python function headers
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 before.. We can make a rule that the case functions should be below each other. I’ve always seen the different functions done above each other in Haskell. > On 8 Aug 2021, at 5:10 PM, 2qdxy4rzwzuui...@potatochowder.com wrote: > > Because the order of cases is significant, these would be difficult to > work with in the REPL. If, for example, I start with your three > definitions, and then decide to write a special case¹ for 2, how do I > convince Python that > >case def fib(2): > return 1 > > belongs before the general case? > > ¹ Yeah, I know, special cases aren't special enough. In a non-toy case > (pun intended), there could be any number of reasons to add a new case > in the middle, or to redfine/fix a case that already exists rather than > add a new case to the end. ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/REES6S3RED7FYQRE7A4J753V7VZBI7VA/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Pattern matching in python function headers
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 fib(1): > return 1 > > case def fib(int(n)): > return fib(n-1) + fib(n-2) > > If you none of the parameters you pass match your case functions, an > exception will be raised ... Because the order of cases is significant, these would be difficult to work with in the REPL. If, for example, I start with your three definitions, and then decide to write a special case¹ for 2, how do I convince Python that case def fib(2): return 1 belongs before the general case? ¹ Yeah, I know, special cases aren't special enough. In a non-toy case (pun intended), there could be any number of reasons to add a new case in the middle, or to redfine/fix a case that already exists rather than add a new case to the end. ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/4OWHKTPCNJML7Y5GRKI3DP2KBUFKDZKI/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: C API for converting Python integers to/from bytes sequences
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 ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/HTOGYMYROL5UGS5YXZAUA6HMRXE54B7G/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Pattern matching in python function headers
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 != probable, but given Python's general conservatism vs. syntax, I suspect "this bug is improbable" is on you to argue. Notes: These comments are not original to me. I do agree that this is a plausible syntax, and don't agree with Steven d'A's suggestion that it might be offputting to new Pythonistas -- I think it could go either way if implemented. I just don't think it's particularly Pythonic or beneficial to Python, so -1. > If you none of the parameters you pass match your case functions, > an exception will be raised. Maybe it would be easier to make those > functions faster since we already know the types in advance. This claim needs to be supported, and it kinda seems unlikely since we already have def fib(n : int) -> int: (although the optimizer doesn't use such information yet AFAIK). > def fib(n): > case 0, : return 0 > case 1, : return 1 > case int(n), : > return fib(n-1) + fib(n-2) > > As opposed to … > > def fib(*args): > match args: > case 0, : return 0 > case 1, : return 1 > case int(n), : > return fib(n-1) + fib(n-2) Saving one line and one level of indentation doesn't seem worth new syntax. This kind of claim is easy to address (again, given Python's conservatism I think it's on the proponents, not the opponents) by going through the stdlib or some other large codebase (Numpy or Pandas or requests might be good candidates) and showing that in fact such dispatching styles would likely bleed off the right edge in many cases where the project has a tight column limit (such as Python's 79 column convention, which is much tighter than many Python programmers like). By the way, what's with the rather strange syntax? In Python 3.10rc1, def fib(n): match n: case 0: return 0 case 1: return 1 case n if isinstance(n, int) and n > 1: return fib(n-1) + fib(n-2) case _: raise RuntimeError is how I'd write it, although I'm not sure that reusing 'n' that way is good style (and RuntimeError is the wrong exception but I'm too lazy to look up the right spelling for args-out-of-range in Python). Interestingly, I can't find a definition for n that gets fib(1.0) to error, except by prepending a "case float()". Not sure if that is intended, anybody know? Steve ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/3M3IUZFMZBPISDAMOKSW4M7R367R6ZSR/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: C API for converting Python integers to/from bytes sequences
> 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 struct, array, memoryview and ctypes > use for some standard sizes and int methods int.to_bytes and > int.from_bytes for non-standard sizes. In C, there is the C API for > converting to/from C types long, unsigned long, long long and unsigned > long long. For other C types (signed and unsigned char, short, int) we > need to use the C API for converting to long, and then truncate to the > destination type with checking for overflow. For integers type aliases > like pid_t we need to determine their size and signess and use > corresponding C API or wrapper. For non-standard integers (e.g. 24-bit), > integers wider than long long, and arbitrary precision integers all is > much more complicated. There are private C API functions > _PyLong_AsByteArray and _PyLong_FromByteArray, but they are for internal > use only. > > I am planning to add public analogs of these private functions, but more > powerful and convenient. > > PyObject *PyLong_FromBytes(const void *buf, Py_ssize_t size, > int byteorder, int signed) > > Py_ssize_t PyLong_AsBytes(PyObject *o, void *buf, Py_ssize_t n, > int byteorder, int signed, int *overflow) > > PyLong_FromBytes() returns the int object. It only fails in case of > memory error or incorrect arguments (e.g. buf is NULL). > > PyLong_AsBytes() writes bytes to the specified buffer, it does not > allocate memory. If buf is NULL it returns the minimum size of the > buffer for representing the integer. -1 is returned on error. if > overflow is NULL, then OverfowError is raised, otherwise *overflow is > set to +1 for overflowing the upper limit, -1 for overflowing the lower > limit, and 0 for no overflow. > > Now I have some design questions. > > 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 not use 0 as a valid value to make mistakes easier to detect. I think you are right to have big endian, little endian and native endian. I do not think the numeric values of the enum matter (apart from avoiding 0). > Do we need to reserve some values for mixed endians? What is mixed endian? I would guess that its use would be application specific - so I assume you would not need to support it. > > 2. How to specify the reduction modulo 2**(8*size) (like in > PyLong_AsUnsignedLongMask)? > > Add yet one flag in PyLong_AsBytes()? Use special value for the signed > argument? 0 -- unsigned, 1 -- signed, 2 (or -1) -- modulo. Or use some > combination of signed and overflow? > > 3. How to specify saturation (like in PyNumber_AsSsize_t())? I.e. values > less than the lower limit are replaced with the lower limit, values > greater than the upper limit are replaced with the upper limit. > > Same options as for (2): separate flag, encode in signed (but we need > two values here) or combination of other parameters. Maybe a single enum that has: signed (modulo) signed saturate unsigned (modulo) unsigned saturate > > 4. What exact names to use? > > PyLong_FromByteArray/PyLong_AsByteArray, > PyLong_FromBytes/PyLong_AsBytes, PyLong_FromBytes/PyLong_ToBytes? Barry > > > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/V2EKXMKSQV25BMRPMDH47IM2OYCLY2TF/ > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/4TSDAQG3BOACRUEH35MD3ME3WQGCZSUA/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Pattern matching in python function headers
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 named case function. case def fib(0): return 0 case def fib(1): return 1 case def fib(int(n)): return fib(n-1) + fib(n-2) If you none of the parameters you pass match your case functions, an exception will be raised. Maybe it would be easier to make those functions faster since we already know the types in advance. Another solution would be something like this …. def fib(n): case 0, : return 0 case 1, : return 1 case int(n), : return fib(n-1) + fib(n-2) As opposed to … def fib(*args): match args: case 0, : return 0 case 1, : return 1 case int(n), : return fib(n-1) + fib(n-2) > On 6 Aug 2021, at 4:46 PM, 2qdxy4rzwzuui...@potatochowder.com wrote: > > On 2021-08-06 at 21:57:47 +1000, > Steven D'Aprano wrote: > >> On Thu, Aug 05, 2021 at 09:39:44AM +0100, Sam Frances wrote: > >>> def fib(0): >>>return 0 >>> >>> def fib(1): >>>return 1 >>> >>> def fib(n): >>>return fib(n-1) + fib(n-2) >> >> I think that there is something rather disturbing about writing a >> function definition with a constant literal as parameter. It looks >> wrong and I'm sure it's going to confuse beginners. > > You are not a beginner (nor am I); what's disturbing to you may or may > not look wrong or confuse someone else. When I was a beginner, > x = x + 1 was disturbing, wrong, and confusing to me. > > The proposed definition of the Fibonacci sequence mirrors the ones in > Wikipedia¹ and OEIS,² and will certainly be at least familiar to those > with a background in mathematics or coming to Python from functional > languages. > > That said, I agree that it's not a good fit for Python, for reasons > expressed elsewhere in this thread. > > FWIW, Lisp Flavored Erlang³ (a syntactically imperative language built > atop the Erlang VM and run-time) doesn't repeat the "def," only the > argument lists: > >lfe> (defun ackermann > ((0 n) (+ n 1)) > ((m 0) (ackermann (- m 1) 1)) > ((m n) (ackermann (- m 1) > (ackermann m (- n 1) > > Something like that might work in Python, but at that point, it's no > different from a function that matches on its *args argument. > > ¹ https://en.wikipedia.org/wiki/Fibonacci_number > ² https://oeis.org/A45 > ³ https://lfe.io/ > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/TCBZOFYGD7ZKCK3ITPXOEDZFDZDMDBVX/ > Code of Conduct: http://python.org/psf/codeofconduct/ ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/EZKM57QB2AP47AQO5GN6ADTFNPJ5SI2L/ Code of Conduct: http://python.org/psf/codeofconduct/
