Mailman 3 December 2020 - Python-ideas

dataclass allow_missing option
by Eelke van den Bos 19 Dec '20

19 Dec '20

Hi all, Dataclasses provide a unique way of creating parameter bags with decent typing and validation options. However, they currently lack a meaningful way of detecting a missing value as a dataclass interface consumer. Current behavior allows us to specify defaults per property, but defining a default value has consequences for the reusability of the dataclass, especially when it comes to inheritance patterns. Aside from this effect, littering the code with `str_field: str = MISSING_STR` does not really provide a clean and readable interface. Therefore, I would like to propose an extra option on both the dataclasses.dataclass decorator as well as a dataclasses.field boolean argument called `allow_missing`. Example: @dataclass(allow_missing=True) class UserBag: user_id: UUID bag = UserBag() # no exception with regards to missing args bag.user_id # type: Missing[UUID] ? if not bag.user_id: # sentinel value evaluates to false ... if dataclasses.ismissing(bag.user_id): # or more explicit ... Alternatively, as api on a per-field-basis: @dataclass class UserBag: user_id: UUID = field(allow_missing=True) As a bonus, one would imagine the `asdict` method has an argument to convert a dataclass instance to a dictionary without the missing properties (example: `asdict(d, exclude_missing=True)`). Generation of code could stay largely the same as it currently is, with only minor differences: - type hinting of constructor args should provide a sentinel default value that adheres to the typing of the original field, something along the lines of `__init__(self, arg = Missing[str])` - exception currently raised if a Missing[T] value is detected after construction should be silenced if the field is marked as missable. - current sentinel MISSING value evaluates to True when cast as boolean I would love to have your feedback on this. Best, Eelke van den Bos

3 2

Using explicit parenthesization to convey aspects of semantic meaning?
by Paul Sokolovsky 18 Dec '20

18 Dec '20

Hello, How would you feel if explicit parens were used to convey additional semantic meaning? That seems like a pretty dumb question, because, well, parens *are* used to convey additional semantic meaning. E.g.: 1 + 2 + 3 vs 1 + (2 + 3) The result is the same, but somehow I wanted to emphasize that 2 and 3 should be added together, and somehow else. a + b + c vs a + (b + c) Here, there's even no guarantee of the same result, if we have user objects with weirdly overloaded __add__(). Thanks for hanging with me so far, we're getting to the crux of the question: Do you think there can be difference between the following two expressions: obj.meth() (obj.meth)() ? The question is definitely with a trick (why else there would be the intro), and first answer which comes to mind might not be the right one. As a hint, to try to get a grounded answer to that question, it would be useful to look at the difference in disassembly of the above code in CPython3.6 vs CPython3.7 (or later): python3.6 -m dis meth_call.py python3.7 -m dis meth_call.py Then, to try to explain the difference at the suitable level of abstraction. If that doesn't provide enough differentiation, it might be helpful to add the 3rd line: t = obj.meth; t() And run all 3 lines thru CPython3.7, and see if the pattern is now visible, and a distortion in the pattern too. What would be the explanation for all that? For reference, the disassembly of the 3 lines with CPython3.7 is provided: 1 0 LOAD_NAME 0 (obj) 2 LOAD_METHOD 1 (meth) 4 CALL_METHOD 0 6 POP_TOP 2 8 LOAD_NAME 0 (obj) 10 LOAD_METHOD 1 (meth) 12 CALL_METHOD 0 14 POP_TOP 3 16 LOAD_NAME 0 (obj) 18 LOAD_ATTR 1 (meth) 20 STORE_NAME 2 (t) 22 LOAD_NAME 2 (t) 24 CALL_FUNCTION 0 26 POP_TOP ... -- Best regards, Paul mailto:pmiscml@gmail.com

12 58

[Feature Request] Member variable as member function default argument values
by Local-State 17 Dec '20

17 Dec '20

Hello guys, First time for me to submit a feature request for python. A lot of time we try to use a member variable as the default value of a member function argument. So we write the code like this: ```python class A: def __init__(self, a: int = 3): self.a = a def func(self, a: int = None): if a is None: a = self.a a += 1 return a ``` This seems okay, but when there are more than 10 arguments need to set their default values as correlated member variables (with the same name at most times), it'll be very painful and the codes turn out to be quite ugly. I wish a clean coding style, so I write something like this ```python def func(self, a: int = 'self'): for k, v in process(a=a, b=b): eval(f'{k} = v') a += 1 return a def process(self, **kwargs): return {k: getattr(self, k) if (v == 'self' and k in self.__dict__.keys()) else v for k, v in kwargs.items()} ``` That seems absolutely much worse for sure! I dream I can just write ```python def func(self, a: int = 'self'): a += 1 return a ``` where I know the default value cannot be 'self', but a special flag which won't get conflict with any other valid argument values. I don't know what it should be though. Some related questions: python: https://stackoverflow.com/questions/39928345/python-member-variable-as-para… C++: https://stackoverflow.com/questions/32399730/default-arguments-as-non-stati… Let me know your ideas! Ren Pang

5 8

Python package funding command-line argument
by Yash Jha 17 Dec '20

17 Dec '20

Many open-source developers are committing to several projects, developing package (for Python). A fraction of developers might need funds for the continuing development of several projects and to pursue contributing. Sadly, there is no direct short way for donors to fund python package developers. There is no particular function in the python package installer(pip) and the site. A command-line argument for listing the funding pages of package developer for packages installed by them (global or pyenv), will help donors to reach such developers easily. The funding page can be the GitHub sponsor page, or PayPal redirect (control of the developer) Similar implementations include the "npm fund" command. This command retrieves information on how to fund the dependencies of a given project, released 4-5 months ago which has gained momentum.

2 1

@classproperty, @abc.abstractclasspropery, etc.
by K. Richard Pixley 16 Dec '20

16 Dec '20

There's a whole matrix of these and I'm wondering why the matrix is currently sparse rather than implementing them all. Or rather, why we can't stack them as: class foo(object): @classmethod @property def bar(cls, ...): ... Essentially the permutation are, I think: {'unadorned'|abc.abstract}{'normal'|static|class}{method|property|non-callable attribute}. concreteness implicit first arg type name comments {unadorned} {unadorned} method def foo(): exists now {unadorned} {unadorned} property @property exists now {unadorned} {unadorned} non-callable attribute x = 2 exists now {unadorned} static method @staticmethod exists now {unadorned} static property @staticproperty proposing {unadorned} static non-callable attribute {degenerate case - variables don't have arguments} unnecessary {unadorned} class method @classmethod exists now {unadorned} class property @classproperty or @classmethod;@property proposing {unadorned} class non-callable attribute {degenerate case - variables don't have arguments} unnecessary abc.abstract {unadorned} method @abc.abstractmethod exists now abc.abstract {unadorned} property @abc.abstractproperty exists now abc.abstract {unadorned} non-callable attribute @abc.abstractattribute or @abc.abstract;@attribute proposing abc.abstract static method @abc.abstractstaticmethod exists now abc.abstract static property @abc.staticproperty proposing abc.abstract static non-callable attribute {degenerate case - variables don't have arguments} unnecessary abc.abstract class method @abc.abstractclassmethod exists now abc.abstract class property @abc.abstractclassproperty proposing abc.abstract class non-callable attribute {degenerate case - variables don't have arguments} unnecessary I think the meanings of the new ones are pretty straightforward, but in case they are not... @staticproperty - like @property only without an implicit first argument. Allows the property to be called directly from the class without requiring a throw-away instance. @classproperty - like @property, only the implicit first argument to the method is the class. Allows the property to be called directly from the class without requiring a throw-away instance. @abc.abstractattribute - a simple, non-callable variable that must be overridden in subclasses @abc.abstractstaticproperty - like @abc.abstractproperty only for @staticproperty @abc.abstractclassproperty - like @abc.abstractproperty only for @classproperty --rich

10 15

Function for fetching what months between two dates
by qaidjoharbarbhaya＠gmail.com 15 Dec '20

15 Dec '20

Hello, Greetings! I have the following idea of adding a function in Lib/datetime.py which when called with the datetime.date object returns the months between the object datetime.date and the object datetime.date passed as the date_to argument in function. Herewith is the attached link to the commit: https://github.com/python/cpython/pull/23713/commits/2941fe88bd9c0c1a5c8ddd… Kind regards,

4 3

Add the brotli & zstandard compression algorithms as modules
by Omer Katz 14 Dec '20

14 Dec '20

Hello everyone, We have many compression algorithms as standard modules, but we lack two important new algorithms: brotli and zstandard. Brotli is an important compression algorithm both for HTTP2 and for compressing/decompressing HTTP responses. ZStandard is another algorithm for compression that can easily beat gzip with a better compression ratio and less compression time. Both are now stable enough and are past the 1.0 mark. Let's include them in the standard library and, of course, make them optional at build time like the rest of our compression modules. What do you think?

12 21

a new data type: NamedValue -- similar to Enum
by Ethan Furman 13 Dec '20

13 Dec '20

Enum is great! Okay, okay, my opinion might be biased. ;) There is one area where Enum is not great -- for a bunch of unrelated values. What would be nice is if we had something similar to Enum for the - repr() - constantness of the name/value relationship While I was looking in the stdlib for an example, I came across sre_constants, which was chock full of constants -- and it even has a minimal version of what I'm proposing: class _NamedIntConstant(int): def __new__(cls, value, name): self = super(_NamedIntConstant, cls).__new__(cls, value) self.name = name return self def __repr__(self): return self.name My proposal, compared/contrasted with Enum: like Enum, NamedValues will be in collections (a class) that will keep those names from being deleted or rebound to other values like Enum, NamedValues will have `value` and `name` attributes, and also a `type` attribute like Enum, NamedValues are attributes of their containing class like Enum, iterating over the containing class will yield the names/values defined like Enum, a class of NamedValues do not have to all be the same data type unless one is mixed in like Enum, a particular name/value combination is a singleton unlike Enum, duplicates are allowed unlike Enum, new values can be added after class definition unlike Enum, a NamedValue can always be used as-is, even if no data type has been mixed in -- in other words, there is no functional difference between MyIntConstants(int, NamedValue) and MyConstants(NamedValue). If sre_constants was using a new data type, it should probably be IntEnum instead. But sre_parse is a good candidate for NamedValues: class K(NamedValues): DIGITS = frozenset("0123456789") OCTDIGITS = frozenset("01234567") HEXDIGITS = frozenset("0123456789abcdefABCDEF") ASCIILETTERS = frozenset("abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ") WHITESPACE = frozenset(" \t\n\r\v\f") _REPEATCODES = frozenset({MIN_REPEAT, MAX_REPEAT}) _UNITCODES = frozenset({ANY, RANGE, IN, LITERAL, NOT_LITERAL, CATEGORY}) and in use: >>> K.DIGITS K.DIGITS >>> K.DIGITS.name 'DIGITS' >>> K.DIGITS.value frozenset("0123456789") Thoughts? -- ~Ethan~

3 7

tkinter Variable implementation
by Ivo Shipkaliev 13 Dec '20

13 Dec '20

Hiya :) I'm recently working with tkinter and I noticed that: >>> import tkinter as tk >>> string_var = tk.StringVar() is throwing an AttributeError: > Traceback (most recent call last): > . . . > File "...\lib\tkinter\__init__.py", line 505, in __init__ > Variable.__init__(self, master, value, name) > File "...\lib\tkinter\__init__.py", line 335, in __init__ > self._root = master._root() > AttributeError: 'NoneType' object has no attribute '_root' ... which is making me question myself: -- "Why am I looking for a '_root' attribute on a NoneType object here?", or -- "How did I end up with a NoneType, to be searched for a '_root' attribute in the first place?" I have done something wrong or I don't know something apparently. Following the traceback, looking at "tkinter\__init__.py", lines 333-335 leads us to the implementation of StringVar's parent: class Variable: 333 > if not master: 334 > master = _default_root 335 > self._root = master._root() Class Variable constructor interface: 317 > def __init__(self, master=None, value=None, name=None): Clearly, on line 335, we are relying on the "master" to have a "_root" callable. If "master" was not declared upon class instantiation (line 317), a value can come from _default_root, which is a global module variable. _default_root is holding a Tk instance, if one was instantiated. So, if neither "master" nor _default_root was defined, line 335 will result in an AttributeError. Now, would it be a good idea if we keep the user better informed by making the aforementioned lines look something like?: 333 > if not master: 334 > master = _default_root 335 > if not master: 336 > raise RuntimeError(f"{self.__class__.__name__!r}: 'master' must be defined or a Tk instance must be present!") 337 > self._root = master._root() ... and not relying on this inexplicable AttributeError. Thank you for your time! Regards Ivo Shipkaliev

3 4

[RFC] "Strict execution mode" (TL;DR version)
by Paul Sokolovsky 13 Dec '20

13 Dec '20

Hello, Recently, there was a discussion of language-level (vs just stdlib-level, like currently done by "typing" module) "const" annotation. The discussion mentioned that the initial implementation would have the best-effort semantics, i.e. don't guarantee "full" constant semantics, effectively, in its baseline, being the same annotation as any other. There was immediately raised a question how a full, eventual implementation would look like, and the posted proposal showcases *one* of the options. This initial post provides "TL;DR" version, also know as "abstract". The following post has the full proposal narrative. ----- ## Abstract This proposal seeks to define "constant namespace slot" (variables/functions/methods) for Python, including both implicit and explicit (user-annotated) slots. Further, the proposal seeks to define necessary changes to language semantics to actually uphold the constant property (i.e. inability to redefine). To preserve as much as possible the benefits of Python's dynamic nature and metaprogramming it enables, the proposal introduces 2 distinct execution modes: "Import-time", which preserves full existing Python execution semantics (albeit with some warnings to point at "problem spots"), and "Run-time", where constant property of the designated name slots (including implicitly constant nameslots, like functions/methods) is enforced (attempts to assign to such slots lead to runtime exception). Overall, the new execution variant is named "strict mode". It is believed that these measures would allow to develop more structured and more robust Python code, especially in big codebases. At the same time, the underlying motivation for the strict mode is to ease the development of runtime optimizers for Python, in particular JIT compilers. Support infrastructure for the strict mode is defined: means to enable it, compatibility measures with standard execution mode. The strict mode is intended to be an opt-in feature, not replacing the default Python execution mode. Below is an example of strict mode program with comments explaining various features: ``` import mod # Leads to a warning: replacing (monkey-patching) a constant slot (function) with a variable. mod.func1 = 1 # Leads to a warning: replacing (monkey-patching) a constant slot (function). mod.func2 = lambda: None # Way to define a constant. my_cnst: const = 1 # Leads to a warning: replacing (monkey-patching) a constant slot. my_cnst: const = 2 glb1 = 100 def fun(): # Imports are not allowed at run-time import mod2 # But you can re-import module previously imported at import-time. import mod # RuntimeError my_cnst = 3 # RuntimeError mod.func2 = lambda x: 1 global glb1, new # RuntimeError: Cannot create new global nameslots at runtime. new = 1 # Nor can delete existing del glb1 # Cheats don't work globals()["new"] = 1 # Leads to a warning: replacing (monkey-patching) a constant slot (function). def fun(): pass # fun_var is a variable storing a reference to a function (can store ref # to another func). fun_var = fun # fun2 is an alias of fun fun2: const = fun # Run-time execution starts with this function. This clearly delineates # import-time from run-time: a module top-level code is executed at # import-time (including import statements, which execute top-level code # of other modules recursively). When that is complete, strict mode # interpreter switches to run-time mode (restrictions enabled) and # executes __main__(). def __main__(): fun() # This statement is not executed when program runs in strict mode. # It is executed when it is run in normal mode, and allow to have # the same startup sequence (execution of __main__()) for both cases. if __name__ == "__main__": __main__() ``` -- Best regards, Paul mailto:pmiscml@gmail.com

11 43