Mailman 3 April 2022 - Python-ideas

PEP 671 (late-bound arg defaults), next round of discussion!
by Chris Angelico 23 Jul '23

23 Jul '23

I've just updated PEP 671 https://www.python.org/dev/peps/pep-0671/ with some additional information about the reference implementation, and some clarifications elsewhere. *PEP 671: Syntax for late-bound function argument defaults* Questions, for you all: 1) If this feature existed in Python 3.11 exactly as described, would you use it? 2) Independently: Is the syntactic distinction between "=" and "=>" a cognitive burden? (It's absolutely valid to say "yes" and "yes", and feel free to say which of those pulls is the stronger one.) 3) If "yes" to question 1, would you use it for any/all of (a) mutable defaults, (b) referencing things that might have changed, (c) referencing other arguments, (d) something else? 4) If "no" to question 1, is there some other spelling or other small change that WOULD mean you would use it? (Some examples in the PEP.) 5) Do you know how to compile CPython from source, and would you be willing to try this out? Please? :) I'd love to hear, also, from anyone's friends/family who know a bit of Python but haven't been involved in this discussion. If late-bound defaults "just make sense" to people, that would be highly informative. Any and all comments welcomed. I mean, this is python-ideas after all... bikeshedding is what we do best! The reference implementation currently has some test failures, which I'm looking into. I'm probably going to make this my personal default Python interpreter for a while, to see how things go. ChrisA

43 364

zip(x, y, z, strict=True)
by Ram Rachum 01 Dec '22

01 Dec '22

Here's something that would have saved me some debugging yesterday: >>> zipped = zip(x, y, z, strict=True) I suggest that `strict=True` would ensure that all the iterables have been exhausted, raising an exception otherwise. This is useful in cases where you're assuming that the iterables all have the same lengths. When your assumption is wrong, you currently just get a shorter result, and it could take you a while to figure out why it's happening. What do you think?

27 179

disallow assignment to unknown ssl.SSLContext attributes
by Thomas Grainger 10 Jun '22

10 Jun '22

I was debugging some code that was using TLSv1.2 when I expected it to only support TLSv1.3, I tracked it down to a call to: context.miunimum_version = ssl.TLSVersion.TLSv1_3 it should have been: context.minimum_version = ssl.TLSVersion.TLSv1_3 I'd like invalid attribute assignment to be prevented at runtime

13 32

Auto assignment of attributes
by Pablo Alcain 08 May '22

08 May '22

The problem of assigning init arguments as attributes has appeared several times in the past ( https://mail.python.org/archives/list/python-ideas@python.org/message/VLI3D… was the most recent we could find) and is already handled in dataclasses. Lately, discussing this topic with a friend, we thought that using a specific token could be a possible approach, so you could do: class MyClass: def __init__(self, @a, @b, c): pass and it would be analogous to doing: class MyClass: def __init__(self, a, b, c): self.a = a self.b = b Then, you would instantiate the class as usual, and the variables tagged with `@` would be bound to the object: >>> objekt = MyClass(2, 3, 4) >>> print(objekt.b) 3 >>> print(objekt.c) AttributeError: 'MyClass' object has no attribute 'c' We have a working implementation here if anyone wants to take a look at: https://github.com/pabloalcain/cpython/tree/feature/auto_attribute. Keep in mind that we have limited knowledge about how to modify cpython itself, and which would the best places be to do the modifications, so it's more than likely that some design decisions aren't very sound ( https://devguide.python.org/grammar/ and https://devguide.python.org/parser/ were incredibly helpful). Besides the implementation, we would like to know what the community thinks on whether this might have any value. While developing this, we realized that Crystal already has this feature (eg https://github.com/askn/crystal-by-example/blob/master/struct/struct.cr) with the same syntax; which is kind of expected, considering it's syntax is based on Ruby. Random collection of thoughts: 1. If auto-assignment made sense in general, one of the reasons we went for this rather than the decorator approach is that we wouldn't like to have a list of strings that can vary decoupled from the actual argument name. 2. The current implementation of `@` works for any function, not only init. We don't know if this would actually be a desirable feature. 3. It also works with any function in the wild. This mostly allows for monkey-patching to work out of the box: >>> class Klass: ... def __init__(self): ... pass ... >>> def add_parameter(k, @p): ... pass ... >>> Klass.add_parameter = add_parameter >>> objekt = Klass() >>> print(objekt.p) Traceback (most recent call last): File "<stdin>", line 1, in <module> AttributeError: 'Klass' object has no attribute 'p' >>> objekt.add_parameter(11) >>> print(objekt.p) 11 Again, we are not sure if this is desirable, but it's what made most sense for us at the moment. 4. Adding the `@` token to the argument doesn’t remove the variable from the function/method scope, so this would be perfectly valid: >>> def my_function(k, @parameter): ... print(parameter) >>> my_function(objekt, 4) 4 >>> k.parameter 4 5. We didn’t implement it for lambda functions. Cheers, Pablo and Quimey

12 50

int.to_base, int.from_base
by Simon de Vlieger 02 May '22

02 May '22

Hey there, The `int()` function allows to specify a base to convert from, for example: >>> int("foo", 26) 10788 Which is documented as: > The base defaults to 10. Valid bases are 0 and 2-36. For other common bases functions exist in the base64 module in stdlib. I often need other bases, or bases with custom alphabets. Doing so involves a bit of code every time that I think could be generalized so I'd like to propose an `int.to_base()`, and `int.from_base`. These would not supercede or replace any current possibilities but extend and simplify current possibilities. The signature(s) I had in mind for now are akin to: > int.from_base(x, alphabet, padding_character) and > int.to_base(alphabet, padding_character) Has any discussion on this been had previously (I searched around a bit), and if not would this make a decent PEP? Regards, Simon

5 8

Delete dictionary entry if key exists using -= operator via __isub__()
by zmvictor＠gmail.com 29 Apr '22

29 Apr '22

*Background* It is frequently desirable to delete a dictionary entry if the key exists. It is necessary to check that the key exists or, alternatively, handle a KeyError: for, where `d` is a `dict`, and `k` is a valid hashable key, `del d[k]` raises KeyError if `k` does not exist. Example: ``` if k in d: del d[k] ``` *Idea* Use the `-=` operator with the key as the right operand to delete a dictionary if the key exists. *Demonstration-of-Concept* ``` class DemoDict(dict): def __init__(self, obj): super().__init__(obj) def __isub__(self, other): if other in self: del self[other] return self if __name__ == '__main__': given = {'a': 1, 'b': 2, 'c': 3, 'd': 4} demo = DemoDict(given) demo -= 'c' assert(demo == {'a': 1, 'b': 2, 'd': 4}) ```

7 13

Enum should use __class_getitem__
by Stefan Nelson-Lindall 28 Apr '22

28 Apr '22

EnumMeta implements its own __getitem__ function which doesn't respect __class_getitem__. Now that __class_getitem__ exists, this behavior feels unintuitive. For instance ``` class Directions(enum.Enum): LEFT = "LEFT" RIGHT = "RIGHT" def __class_getitem__(cls, name): return super().__class_getitem__(name.upper()) # fails with KeyError -- __class_getitem__ never called assert Directions["left"] == Directions["LEFT"] == Directions.LEFT ``` doesn't work, and the only way to implement this behavior is something like ``` class MyEnumMeta(enum.EnumMeta): def __getitem__(cls, name): return cls.__class_getitem__(name) class MyEnum(enum.Enum, metaclass=MyEnumMeta): def __class_getitem__(cls, name): return cls._member_map_[name] class Directions(MyEnum): ... ``` there might be some compatibility issues with code written between 3.4 and 3.11, but not supporting __class_getitem__ feels like it violates the principle of least surprise with the more recent data models.

2 1

mro and super don't feel so pythonic
by malmiteria 26 Apr '22

26 Apr '22

Hi, Before anything, i made a github repository about this topic here : https://github.com/malmiteria/super-alternative-to-super The core of what i wanna discuss here is that i don't think mro and super (mainly because it relies on mro) are very pythonic. Mainly that some behaviors of the mro are too implicit, and are silencing what really should be errors. Let me explain : in case of multiple inheritence, resolving a child method from it's parent isn't an obvious task, and mro comes as a solution to that. However, i don't understand why we don't let the programmer solve it. I think this is similar to a merge conflict, and not letting the programmer resolve the conflict feels like silencing an error. This is especially infuriating when you realise that mro doesn't solve all possible scenarios, and then, simply refuses the opportunity to solve it to the programmer. Then, super relying on mro gives off some weird behaviors, mainly, it's possible for a child definition to affect what a call to super means in it's parent. This feels like a side effect (which is the 'too implicit' thing i refer to). I also don't understand why we can't simply pass the parent targeted as argument to super, instead of having no argument, or having to pass the current class and instances as argument : super(child) is a proxy to parent, when super(parent) would make more sense to be the proxy to parent, in my mind. I dive in more depths about those topics in the readme of the github repository i linked at the top of this comment. what i propose is a solution that would follow those rules: The mro alternative, which i called explicit method resolution aka EMR (which is probably not a good name since i apply it, as mro, to all class attributes), follow those rules : 1) Straightforward case : the class definition has the method / attribute : this is the one EMR should resolve to 2) Not found : the method / attribute can't be resolved in the class itself, or by any of it's parents, then it should raise an AttributeError 3) Only on parent : the method / attribute can't be resolved in the class itself, and can only be resolved by one of it's parents, this is the one EMR should resolve to 4) Multiple parent : the method / attribute can't be resolved in the class itself, and can be resolved by at least 2 of it's parents, then an ExplicitResolutionRequired error should be raised 5) Transimittin errors : the method / attribute can't be resolved in the class itself, and one parent at least raises an ExplicitResolutionRequired error, then it should raise an ExplicitResolutionRequired error 6) (optional?) Single source : when multiple parent can resolve a method from a single source (in case of diamond shape inheritence), the ExplicitResolutionRequired is not needed The super alternative, which i called __as_parent__ should follow those rules : 1) reliability : the target __as_parent__ points to should not depend on anything other than the argument passed to it 2) expliciteness : in case of multiple inheritence, the parent targetted should be passed as an argument to the __as_parent__ method. 3) impliciteness : in case of simple inheritence, it is not needed to specify the parent targeted (since there can only be one, and it make it closer to the actual behavior of super in most cases) 4) ancestors as targets : should be able to target ancestors, either direct or not (which is needed in case two grandparent define a method that a single parent share, there would be no other way to solve the ExplicitResolutionRequired otherwise) this solution has a few advantages in my mind : - the current mro and super are more tightly coupled than the emr and __as_parent__ i propose here - the __as_parent__ is more reliable than super in its behavior, and should lead to an easier learning curve - the emr i propose as a replacement to mro allows for some inheritence tree mro doesn't allow. - the __as_parent__ method being able to target specific parent allows for different methods to visit the parents in different order easily, which today would be harder, since the parent visiting order is tightly coupled to the class definition - with emr, in case of problematic resolution, an error is raised to tell you about the problem, and ask you for explicit resolution, the current solution doesn't, which can lead to surprises closer to production environment. A few possible downsides : - the transition would be a pain to deal with - the current mro allows for dependencies injection in the inheritence tree. I believe this feature should be untied from super and mro, but it would require some work. - the current super and mro are old enough to have been faced with issues and having been updated to solve those issues down the line. Any alternative would have to face those issues again and new ones down the line - any coexistence between those two solution would require some work to make sure they don't break one another (i've explored some of those scenarios in my repository, but i definitely didn't cover it all) I believe that what i talk about here is definitely too much at once. For exemple, adding a kwarg to super to specify the parent it targets would be a very easy change to add into python, and wouldn't require much more of what i talk about here, but it would still have some of the value i talk about here. But overall, it all makes sense to me, and i wanted to share it all with you guys. What do you think? does it makes sense? Am i missing something?

22 206

NotImplementedMethod function, or making NotImplemented return itself when called
by aanonyme.personne＠hotmail.fr 26 Apr '22

26 Apr '22

This is useful in the context of reducing the available methods and operator overloading, when subclassing a type. Typically, when subclassing a NamedTuple type, you often don't want the <, >, <=, >=, + or * operators to work, so in that case you would want for the related methods to return NotImplemented. This can be done with (and I hope triple-backquotes markdown works here) : ```py def NotImplementedMethod(self, other): return NotImplemented class ...: ... __le__ = __lt__ = __ge__ = __gt__ = __mul__ = __rmul__ = __add__ = __radd__ = NotImplementedMethod ``` This is very handy, and I think it should be added to the builtins. A simple way to implement this could be to have `NotImplemented(a, b)` return NotImplemented for any value of a and b, so that NotImplemented can be used instead of NotImplementedMethod in the above example. A caveat for that version, and the reason I would not recommand it, is that it makes NotImplemented a callable when it doesn't need to be, and probably shouldn't be. The other way around, which I'm recommanding, is to add the NotImplementedMethod, working as-is but implement it in C, so that it has no inner dict, is lightweight and less prone to programmer mismanagement (making it a builtin_function_or_method instead of a function).

3 2

heapq max heap
by Eduardo Nery 13 Apr '22

13 Apr '22

Many times when using the heapq lib I had to convert my array to negative values so that it could behave like a max heap. Maybe we should pass in a parameter in the functions to specify if we want a max heap behaviour or a min heap behaviour.

2 1