[issue24145] Support |= for parameters in converters

Change by Tal Einat : -- nosy: -taleinat ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python

[issue24145] Support |= for parameters in converters

Tal Einat added the comment: Well, the main reasons I'm +1 on the "|=" feature (regardless of specific syntax) are: 1) the intent is much clearer: e.g. also accept None, nothing else special going on 2) much easier maintenance if the default set of accepted types ever changes Also, this is on

[issue24145] Support |= for parameters in converters

Nick Coghlan added the comment: Aye, it occurs to me now that introducing the implicit form trades a "write time" lookup (where you have to override the converter defaults explicitly), for a "read time" lookup (where you need to mentally add the defaults to understand the modified accept clause)

[issue24145] Support |= for parameters in converters

Serhiy Storchaka added the comment: For now str(accept={str, NoneType}) is used only 14 times in 6 files in 5 modules. The "z" format unit is used also in still not converted modules _codecs (a lot of sites), _locale, mmap, _multiprocessing, and _socket. Current syntax doesn't look so ugly fo

[issue24145] Support |= for parameters in converters

Raymond Hettinger added the comment: To my eyes, the current set notation form more clearly expresses its intentions than the |= notation. Readability counts. I agree the |= is a startling syntax that looks weird enough to cause a mental hiccup when reading it. So, put me down for a -1. The

[issue24145] Support |= for parameters in converters

New submission from Larry Hastings: Some "format units" provided by PyArg_ParseTuple() are exactly the same as others, except that they also accept the value None. For example, "s" and "z" are exactly the same, except "z" accepts None and "s" does not. The same goes for "s*" and "z*", or "s#