[issue46730] Please consider mentioning property without setter when an attribute can't be set
New submission from Neil Girdhar : class C: @property def f(self) -> int: return 2 class D(C): pass D().f = 2 Gives: Traceback (most recent call last): File "/home/neil/src/cmm/a.py", line 10, in D().f = 2 AttributeError: can't set attribute 'f' This can be a pain to debug when the property is buried in a base class. Would it make sense to mention the reason why the attribute can't be set, namely that it's on a property without a setter? -- components: Interpreter Core messages: 413122 nosy: NeilGirdhar priority: normal severity: normal status: open title: Please consider mentioning property without setter when an attribute can't be set versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue46730> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46730] Please consider mentioning property without setter when an attribute can't be set
Neil Girdhar added the comment: Thank you, this would have saved me a lot of time! On Sat, Feb 12, 2022 at 8:37 PM Alexander wrote: > > Alexander added the comment: > > Indeed, the error message does not help to identify the problem. Moreover, > it collides with similar errors in namedtuple and DynamicClassAttribute > which may lead to even more confusion. > > I made a draft patch that could help with it ( > https://github.com/Alex-Blade/cpython/commit/06df3a72dfe462c8fe4eac60dce0ef059b1738f8), > but I have a concern related to backwards compatibility (that's why no PR). > I don't really understand if according to PEP 387 a change in an exception > message should be considered compatibility breaking? > > -- > nosy: +Alex-Blade > > ___ > Python tracker > <https://bugs.python.org/issue46730> > ___ > -- ___ Python tracker <https://bugs.python.org/issue46730> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46757] dataclasses should define an empty __post_init__
New submission from Neil Girdhar : When defining a dataclass, it's possible to define a post-init (__post_init__) method to, for example, verify contracts. Sometimes, when you inherit from another dataclass, that dataclass has its own post-init method. If you want that method to also do its checks, you need to explicitly call it with super. However, if that method doesn't exist calling it with super will crash. Since you don't know whether your superclasses implement post-init or not, you're forced to check if the superclass has one or not, and call it if it does. Essentially, post-init implements an "augmenting pattern" like __init__, ___enter__, __exit__, __array_finalize__, etc. All such methods define an empty method at the top level so that child classes can safely call super. Please consider adding such an empty method to dataclasses so that children who implement __post_init__ can safely call super. -- components: Library (Lib) messages: 413283 nosy: NeilGirdhar priority: normal severity: normal status: open title: dataclasses should define an empty __post_init__ ___ Python tracker <https://bugs.python.org/issue46757> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46757] dataclasses should define an empty __post_init__
Neil Girdhar added the comment: On Sat, Feb 19, 2022 at 2:51 AM Vedran Čačić wrote: > > Vedran Čačić added the comment: > > That "except AttributeError" approach is a powerful bug magnet, since it > can very easily mask real attribute errors stemming from misspelled > attribute names in the __post_init__ call itself. What you should _really_ > do is > > def __post_init__(self): > with contextlib.suppress(AttributeError): > post_init = super().__post_init__ > post_init() > > But of course, nobody will ever write that. > > Great point! Raymond in his "super considered super" video ( > https://youtu.be/xKgELVmrqfs?t=2068) says the right thing to do is to > make your own root which knows exactly what classes it manages, and drops > the supercalls from them (after possibly verifying that all kwargs have > actually been used and so on). > > But in case of dataclasses, usually any class can serve as such a root, > and the main reason people use dataclasses is to avoid boilerplate code. So > I think it would be a nice compromise. > I'm not sure I understand what you're saying here. Anyone can inherit from a class C with the special root and some other class D, and then your introduced root won't catch D's super calls. > > -- > nosy: +veky > > ___ > Python tracker > <https://bugs.python.org/issue46757> > ___ > -- ___ Python tracker <https://bugs.python.org/issue46757> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46757] dataclasses should define an empty __post_init__
Neil Girdhar added the comment: > I'm not crazy about adding a method to every dataclass just for the 0.1% of > the times it's needed. I'm not sure I totally understand the cost here. You can have a single shared global function that you set on each dataclass. So the only cost would be an entry in each dataclass type's dict. Even if a user creates a thousand dataclasses, that should only be tens of killobytes in pointers. > I think using hasattr or catching the exception is a better way to go. If you choose this, then I think this should be documented under the __post_init__ saying that any time you define __post_init__, you should either be a final class, or else call super. If you call super, you musteither use hasattr(super().__post_init__) or catch the exception. I have to admit, I find this quite ugly from a user perspective. -- ___ Python tracker <https://bugs.python.org/issue46757> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46757] dataclasses should define an empty __post_init__
Neil Girdhar added the comment: > How would an arbitrary derived class know how to call this? It can't. There > has to be knowledge of the base class's requirements already. Surely knowing > "__post_init__ must be called with some_arg" isn't too different from "I know > __post_init__ doesn't exist". This is exactly the same problem you have with all other "augmenting methods" that have arbitrary parameters (e.g., __init__). When calling super on a non-final class you could simply forward keyword arguments. @dataclass class X: def __post_init__(self, **kwargs): super().__post_init__(**kwargs) ... @dataclass class Y(X): def __post_init__(self, **kwargs): super().__post_init__(**kwargs) ... > I'm still unconvinced, but I'll hold off on making a decision to see if > there's more support. Maybe taking it to python-ideas would be worthwhile. Sounds good, done: https://groups.google.com/g/python-ideas/c/-gctNaSqgew -- ___ Python tracker <https://bugs.python.org/issue46757> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46757] dataclasses should define an empty __post_init__
Neil Girdhar added the comment: @Raymond yeah I've been thinking about this some more, and there's no way to have a "top level" method with the dataclass decorator. I think I will make a case to have a class version of dataclasses that works with inheritance. Class versions of dataclasses are used in some places like here: https://github.com/google/flax/blob/main/flax/struct.py#L184 They just call dataclass on the class in __init_subclass__. If we had something like this in the standard library, then you could put your empty __post_init__ in that class. You could also make __init__ call super so that mixins would be initialized (right now the collider pattern you showed also breaks if B is not a dataclass, and has a non-trivial __init__). -- ___ Python tracker <https://bugs.python.org/issue46757> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46757] dataclasses should define an empty __post_init__
Neil Girdhar added the comment: @eric Good thinking. Would it make sense to add to the documentation as well that the __post_init__ methods aren't collected, and you should call super's __post_init__ if there is one using something like if hasattr(super(), "__post_init__"): super().__post_init__() Noting this will make it easier to point to the docs if someone wonders when they see code like this. -- ___ Python tracker <https://bugs.python.org/issue46757> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23316] Incorrect evaluation order of function arguments with *args
Neil Girdhar added the comment: FYI: https://github.com/PyCQA/pylint/issues/4586 -- ___ Python tracker <https://bugs.python.org/issue23316> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4356] Add "key" argument to "bisect" module functions
Neil Girdhar added the comment: The problem with `key=lambda item: -item` is that item cannot always be easily negated. For example, tuples are often used as keys. -- ___ Python tracker <https://bugs.python.org/issue4356> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32626] Subscript unpacking raises SyntaxError
Neil Girdhar added the comment: This came up already on python-ideas: https://groups.google.com/forum/#!topic/python-ideas/YOpT9fDQyFk I think this was an oversight, and I'm with Ben that it's unexpected. That said, this is usually the kind of thing that Guido likes to comment on. My suggestion is to first check to see if you can change the grammar, and then ask Guido what he thinks. -- ___ Python tracker <https://bugs.python.org/issue32626> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33419] Add functools.partialclass
New submission from Neil Girdhar : functools.partial is almost good enough for specifying some of the parameters of an object's initializer, but the partial object doesn't respond properly to issubclass. Adding functools.partialclass is similar to the addition of partialmethod in 3.4. -- files: partialclass.diff keywords: patch messages: 316126 nosy: neil.g priority: normal severity: normal status: open title: Add functools.partialclass versions: Python 3.7 Added file: https://bugs.python.org/file47567/partialclass.diff ___ Python tracker <https://bugs.python.org/issue33419> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33419] Add functools.partialclass
Change by Neil Girdhar : -- components: +Library (Lib) type: -> enhancement ___ Python tracker <https://bugs.python.org/issue33419> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33419] Add functools.partialclass
Change by Neil Girdhar : Added file: https://bugs.python.org/file47568/partialclass2.diff ___ Python tracker <https://bugs.python.org/issue33419> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33419] Add functools.partialclass
Neil Girdhar added the comment: I edited some of the documentation as well to use the technical terms "partial function application", "partial method application", and "partial class application". This emphasizes the parallel structure and reduces confusion with "partial functions" that mean something else in other languages. I also removed a phrase that used the term "freezes" since in Python "frozen" is also used in frozenset to mean frozen for good whereas the keyword arguments in a partial function application are overridable. -- ___ Python tracker <https://bugs.python.org/issue33419> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33419] Add functools.partialclass
Neil Girdhar added the comment: Added functools experts. Links to relevant stackoverflow questions: https://stackoverflow.com/questions/38911146/python-equivalent-of-functools-partial-for-a-class-constructor https://stackoverflow.com/questions/50143864/is-there-a-nice-way-to-partially-bind-class-parameters-in-python/50143893 -- nosy: +ncoghlan, rhettinger ___ Python tracker <https://bugs.python.org/issue33419> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33419] Add functools.partialclass
Change by Neil Girdhar : Added file: https://bugs.python.org/file47569/partialclass3.diff ___ Python tracker <https://bugs.python.org/issue33419> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33419] Add functools.partialclass
Neil Girdhar added the comment: I figured it would have to be 3.8, but it looks like Doc/whatsnew/3.8.rst has not been created? Do I create that? -- ___ Python tracker <https://bugs.python.org/issue33419> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33419] Add functools.partialclass
Neil Girdhar added the comment: Done: https://github.com/python/cpython/pull/6699 -- ___ Python tracker <https://bugs.python.org/issue33419> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33419] Add functools.partialclass
Neil Girdhar added the comment: I'm not sure that this should be in the stdlib. The three-line function can be enough for your simple case, and it is too simple for including it in the stdlib. But for general stdlib quality solution it lacks many details. 1. It doesn't work with classes that implement the constructor as __new__, but not __init__. It may need of using metaclasses with overridden __call__. But how then handle classes with custom metaclasses? Can you illustrate how you would do it for these kinds of classes? Anyway, I think using __new__ on user classes is extremely rare. 2. inspect.signature() doesn't give the correct signature as for partial(). This requires changing the inspect module. Good point. I can look into this. 3. pickling and copying of instances are broken in many cases. Pickling a class is always broken. I afraid that this can't be solved without significant reworking of the pickle and the copy modules. Okay, interesting, but this doesn't seem relevant to partialclass. 4. It adds instance attributes __dict__ and __weakref__ even if they were disabled by using __slots__. This increases the size of instances and breaks some properties. Can we just copy the parent class' __slots__ to the partialclass return value? 5. repr() of the class doesn't show that it is a partialclass (unlike to the result of partial()). I will fix this. 6. Many alternate constructors and copying methods are broken. For example the copy() method of partialclass(defaultdict, list) in your example. There is no general solution of this, it should be solved individually for every class. Ultimately, if pickling works, then copying should work too. The usual way I do it is implementing __getnewargs__, etc. This should work fine? > If there is a need of this feature in the stdlib, it needs changing many > parts of the stdlib. And the result will still need an additional work for > every concrete class. Fair enough. > Also note that the term "partial class" has different well known meaning in > some other programming languages: > https://en.wikipedia.org/wiki/Class_(computer_programming)#Partial . Interesting. Similarly "partial function" means something else. That's why I changed the documentation to use the terms: "partial class application", "partial function application", and "partial method application". All of these are "partial applications": https://en.wikipedia.org/wiki/Partial_application . Should we discuss this on github? -- ___ Python tracker <https://bugs.python.org/issue33419> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33419] Add functools.partialclass
Neil Girdhar added the comment: It seems like Python doesn't do very well with dynamically-generated classes. For that reason, I'm losing interest on this feature. Is there any interest in merging the documentation changes here: https://bugs.python.org/review/33419/diff/20050/Doc/library/functools.rst ? I think we should use the terminology "partial function application" (see https://en.wikipedia.org/wiki/Partial_application) rather than "partial function". Also, the existing paragraphs change subject from talking about the library function (e.g., partial) to the function returned by the library function, which is confusing. I thought we should break them up. Finally, the term "freezing" an interface is a bit weird since Python uses freezing in other another context to mean immutable (frozenset), and the interface returned by partial is overridable. Also, I realize I didn't wait very long, but I think it would be best in the future to register one's "–1" on pyhton-ideas before someone embarks on implementing something everyone else approved. This also happened with PEP 448 too after I'd worked on it for weeks, and it was very frustrating. Anyway, feel free to close. If this keeps coming up over the next few years, someone else can work from this patch. -- ___ Python tracker <https://bugs.python.org/issue33419> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34363] dataclasses.asdict() mishandles dataclass instance attributes that are instances of subclassed typing.NamedTuple
Neil Girdhar added the comment: Sorry if I'm intruding here, but I really dislike that we are doing isinstance versus list, tuple, and dict. And I dislike even more type(x) in (list, tuple). I think the ideal thing to do would have been to check versus abstract base classes like isinstance(x, Sequence) and isinstance(x, Mapping). The advantage to this is flexibility with user-defined types. The problem seems to be that the abstract base classes don't promise anything about the constructor. It seems like some Sequence types accept an Iterable (e.g. tuple), but others like NamedTuple want positional arguments. I think this promise should be encoded in some way. Maybe a third solution is to have NamedTuple special-cased out: isinstance(x, Sequence) and not isinstance(x, NamedTuple) If there are other Sequence types that do this (are there?) then an abstract base class could be created. This solution has the benefit of playing the most nicely with user-defined classes. -- nosy: +NeilGirdhar ___ Python tracker <https://bugs.python.org/issue34363> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34363] dataclasses.asdict() mishandles dataclass instance attributes that are instances of subclassed typing.NamedTuple
Neil Girdhar added the comment: Why can't we add an ABC into a NamedTuple instance's MRO? Because while I like Eric's solution, it seems to be backwards: tuple and list are not the special cases—NamedTuple is. All sequences accept an iterable in their constructor, and NamedTuple doesn't. So it should be NamedTuple that is marked as being "weird". Right now, NamedTuple instances claim to be tuples, but don't accept iterables to initialize themselves. That seems wrong. This problem that we have with dataclass can easily pop up somewhere else, and it will require the same restriction to list and tuple types to fix it (breaking user-defined types). Is it imposible to add to the MRO of NamedTuple instances? -- ___ Python tracker <https://bugs.python.org/issue34363> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34363] dataclasses.asdict() mishandles dataclass instance attributes that are instances of subclassed typing.NamedTuple
Neil Girdhar added the comment: > The code generated by oollections.namedtuple was based on patterns already in > widespread use at the time. That's fair enough. However, it seems like there is one important difference: unlike any other Sequence, namedtuples cannot be initialized with an iterable. For that reason, I like Eric's option of checking for the _fields member rather than special-casing list and tuple since it seems like namedtuple is the special case. -- ___ Python tracker <https://bugs.python.org/issue34363> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18844] allow weights in random.choice
Neil Girdhar added the comment: Should this really be implemented using the cumulative distribution and binary search algorithm? Vose's Alias Method has the same initialization and memory usage cost (O(n)), but is constant time to generate each sample. An excellent tutorial is here: http://www.keithschwarz.com/darts-dice-coins/ -- nosy: +neil.g ___ Python tracker <http://bugs.python.org/issue18844> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16540] Make itertools count, cycle, and repeat objects subscriptable like range.
New submission from Neil Girdhar: When using sequence types polymorphically, range, list, and tuple are both iterable and subscriptable. Unfortunately, itertools.count, cycle, and repeat objects are not subscriptable, although this is not a hard change. Please consider making these objects subscriptable for polymorphic usage. -- components: Library (Lib) messages: 176183 nosy: Neil.Girdhar priority: normal severity: normal status: open title: Make itertools count, cycle, and repeat objects subscriptable like range. type: enhancement versions: Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 ___ Python tracker <http://bugs.python.org/issue16540> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16540] Make itertools count, cycle, and repeat objects subscriptable like range.
Neil Girdhar added the comment: Apologies if this is a bad question, but why do count, cycle, and repeat return iterators rather than iterables? -- ___ Python tracker <http://bugs.python.org/issue16540> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16540] Make itertools count, cycle, and repeat objects subscriptable like range.
Neil Girdhar added the comment: My suggestion is then to update collection.abc to have an InfiniteSequence, which inherits from Iterable, and adds abstract methods __getitem__ and mixin methods __iter__. Then, itertools count, cycle, and repeat could implement collection.abc.InfiniteSequence, and collections.abc.Iterator (for backwards-compatibility). -- ___ Python tracker <http://bugs.python.org/issue16540> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16540] Make itertools count, cycle, and repeat objects subscriptable like range.
Neil Girdhar added the comment: My code looks like this: presignal_abd = [[], [0.1, 0.6], []] tarsignal_abd = [[], [0.4, 0.9], []] diagsignal_abd = [[], [0.1, 0.6, 0.7, 0.8], []] # etc. for (filename, observations, presignals, tarsignals, diagsignals, diagram_type) in zip(['events-deduction', 'events-abduction', 'events-accomodation', 'events-learning', 'events-learning-2'], [observations_ded, observations_abd, observations_tra, observations_tra1, observations_tra], [repeat_([]), presignal_abd, presignal_tra, repeat_([]), presignal_tra], [repeat_([]), tarsignal_abd, tarsignal_tra, repeat_([]), tarsignal_tra], [repeat_([]), diagsignal_abd, diagsignal_tra, repeat_([]), diagsignal_tra], [0, 1, 2, 3, 3]): second_set_of_events = presignals[1] I am using repeat_ objects (itertools.repeat objects) to fill as dummies. -- ___ Python tracker <http://bugs.python.org/issue16540> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16540] Make itertools count, cycle, and repeat objects subscriptable like range.
Neil Girdhar added the comment: Thanks, that works. One of the things I like about Python is that you can write what you mean. I figured that since I meant "repeat [] as many times as necessary", that I should write it that way. So, from an intuitive standpoint, I still feel that these itertools types intuitively implement InfiniteSequence. Although I recognize that some people might see them only in the narrower sense of Iterators. -- ___ Python tracker <http://bugs.python.org/issue16540> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27598] Add SizedIterable to collections.abc and typing
Neil Girdhar added the comment:
@gvanrossum is there any reason that subclasshook is implemented by overriding
instead of cooperation? E.g.,:
class Sized(metaclass=ABCMeta):
@classmethod
def __subclasshook__(cls, C):
return (super().__subclasshook__(C) and
any("__len__" in B.__dict__ for B in C.__mro__))
etc. And then Collection does not need to implement subclasshook since its
base classes cooperate?
--
nosy: +neil.g
___
Python tracker
<http://bugs.python.org/issue27598>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27598] Add SizedIterable to collections.abc and typing
Neil Girdhar added the comment: Great patch. Shouldn't Sequence be a "Reversible, Collection"? -- ___ Python tracker <http://bugs.python.org/issue27598> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27598] Add SizedIterable to collections.abc and typing
Neil Girdhar added the comment: (added the documentation changes) -- Added file: http://bugs.python.org/file44146/doc_changes.diff ___ Python tracker <http://bugs.python.org/issue27598> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27802] Add __eq__ and __ne__ to collections.abc.Sequence.
New submission from Neil Girdhar: Both Mapping and Set provide __eq__ and __ne__. Why not have Sequence do the same? -- messages: 273114 nosy: neil.g priority: normal severity: normal status: open title: Add __eq__ and __ne__ to collections.abc.Sequence. ___ Python tracker <http://bugs.python.org/issue27802> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27802] Add __eq__ and __ne__ to collections.abc.Sequence.
Changes by Neil Girdhar : -- components: +Library (Lib) versions: +Python 3.6 ___ Python tracker <http://bugs.python.org/issue27802> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27802] Add __eq__ and __ne__ to collections.abc.Sequence.
Changes by Neil Girdhar : -- keywords: +patch Added file: http://bugs.python.org/file44151/abc_eq.diff ___ Python tracker <http://bugs.python.org/issue27802> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27598] Add SizedIterable to collections.abc and typing
Neil Girdhar added the comment: Given issue http://bugs.python.org/issue27802, it might be worth considering that all Collections implement __eq__ and __ne__, so maybe these should be abstract methods on Collection? -- ___ Python tracker <http://bugs.python.org/issue27598> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27598] Add Collection to collections.abc and typing
Changes by Neil Girdhar : -- title: Add SizedIterable to collections.abc and typing -> Add Collection to collections.abc and typing ___ Python tracker <http://bugs.python.org/issue27598> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27802] Add __eq__ and __ne__ to collections.abc.Sequence.
Neil Girdhar added the comment: That's a really good point. Perhaps bring it up on ideas so that it can be discussed by more people? I don't know what the answer is. -- ___ Python tracker <http://bugs.python.org/issue27802> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27802] Add __eq__ and __ne__ to collections.abc.Sequence.
Neil Girdhar added the comment: (there's already an open thread.) -- ___ Python tracker <http://bugs.python.org/issue27802> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27598] Add Collection to collections.abc and typing
Neil Girdhar added the comment: (never mind about the comparison operators :) Turns out that would break backwards compatibility.) -- ___ Python tracker <http://bugs.python.org/issue27598> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2292] Missing *-unpacking generalizations
Neil Girdhar added the comment: Updated the patch for 3.5. Currently, building fails with TypeError: init_builtin() takes exactly 1 argument (0 given) This is probably due to an argument counting bug, but I am not sure how to debug it. -- nosy: +neil.g Added file: http://bugs.python.org/file37779/starunpack3.diff ___ Python tracker <http://bugs.python.org/issue2292> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2292] Missing *-unpacking generalizations
Neil Girdhar added the comment: Hi Chris. It might be hard to notice, but you're seeing the same build failure. Looking at the patch-to-patch differences, I didn't see anything out of the ordinary. My patch file includes more surrounding lines, dates, and is against a different repository, so it sees a lot of the new matrix multiplication operator stuff, etc. Is there a best practice for creating diff files? I just did hg diff > starunpack3.diff. Anyway, here's a new patch with the "yield *args" code that has been supplanted by "yield from" removed. -- Added file: http://bugs.python.org/file37787/starunpack4.diff ___ Python tracker <http://bugs.python.org/issue2292> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2292] Missing *-unpacking generalizations
Changes by Neil Girdhar : Added file: http://bugs.python.org/file37788/starunpack4.diff ___ Python tracker <http://bugs.python.org/issue2292> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2292] Missing *-unpacking generalizations
Changes by Neil Girdhar : Removed file: http://bugs.python.org/file37787/starunpack4.diff ___ Python tracker <http://bugs.python.org/issue2292> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2292] Missing *-unpacking generalizations
Neil Girdhar added the comment: Yup, that's it. So two problems down: It has yet to be updated to the most recent Python version It features a now redundant replacement for "yield from" which should be removed I'm working on: It also loses support for calling function with keyword arguments before positional arguments, which is an unnecessary backwards-incompatible change. I'm waiting on some feedback from python-ideas to make sure I know what should be allowed post PEP448. -- ___ Python tracker <http://bugs.python.org/issue2292> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2292] Missing *-unpacking generalizations
Neil Girdhar added the comment: Yes, thank you! That explained it. I am almost done fixing this patch. Here's my progress so far if you want to try it out. Just one test left to fix. -- Added file: http://bugs.python.org/file37790/starunpack5.diff ___ Python tracker <http://bugs.python.org/issue2292> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2292] Missing *-unpacking generalizations
Neil Girdhar added the comment: All tests pass for me! Would anyone be kind enough to do a code review? -- Added file: http://bugs.python.org/file37791/starunpack6.diff ___ Python tracker <http://bugs.python.org/issue2292> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2292] Missing *-unpacking generalizations
Changes by Neil Girdhar : Added file: http://bugs.python.org/file37792/starunpack6.diff ___ Python tracker <http://bugs.python.org/issue2292> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2292] Missing *-unpacking generalizations
Neil Girdhar added the comment: Thanks. It's probably compile.c under "/* Same dance again for keyword arguments */". nseen remains zero and probably shouldn't. I need to learn more about the opcodes. -- ___ Python tracker <http://bugs.python.org/issue2292> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2292] Missing *-unpacking generalizations
Neil Girdhar added the comment: Post it? It's just "hg diff > a.diff" -- ___ Python tracker <http://bugs.python.org/issue2292> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2292] Missing *-unpacking generalizations
Neil Girdhar added the comment: I think there will still be a problem ceval with the way the dicts are combined unfortunately, but that should be easy to fix. -- ___ Python tracker <http://bugs.python.org/issue2292> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2292] Missing *-unpacking generalizations
Neil Girdhar added the comment:
Thanks!
I've incorporated your changes to deal with the [*[0] for i in [0]] problem,
although I don't understand them yet.
The problem with using STORE_MAP is you create a new dict for each keyword
argument in that situation. I optimized that away. Good catch on the
BUILD_MAP opcode problem. I could not figure out why that wasn't working!
I added some tests. Did you say you had some tests?
One of the tests that both of our code is failing on still is:
>>> def f(x, y):
... print(x, y)
...
>>> f(x=5, **{'x': 1}, **{'x': 3}, y=2)
It's just a problem in ceval that I'll work on now.
--
Added file: http://bugs.python.org/file37799/starunpack9.diff
___
Python tracker
<http://bugs.python.org/issue2292>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2292] Missing *-unpacking generalizations
Neil Girdhar added the comment: Why is that correct? The PEP mentions overriding. Right now each dict overrides values from the last silently, which I think makes sense. The keyword arguments you pass in override keys from previous dicts (also good I think). The problem is that you can pass multiple duplicate keyword arguments, and the one below, which I think should succeed. -- ___ Python tracker <http://bugs.python.org/issue2292> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2292] Missing *-unpacking generalizations
Neil Girdhar added the comment:
That makes sense.
If you wanted to override, you could always write:
f(**{**a, **b, 'x': 5})
rather than
f(**a, **b, x=5)
Should I go ahead and fix it so that overriding is always wrong? E.g.,
f(**{'x': 3}, **{'x': 4})
which currently works?
--
___
Python tracker
<http://bugs.python.org/issue2292>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2292] Missing *-unpacking generalizations
Neil Girdhar added the comment:
Could you try this and tell me how many BUILD_MAPs you're doing?
dis.dis("def f(w, x, y, z, r): pass\nf(w=1, **{'x': 2}, y=3, z=4, r=5)")
Mine does 2.
--
___
Python tracker
<http://bugs.python.org/issue2292>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2292] Missing *-unpacking generalizations
Neil Girdhar added the comment: If there is a speed issue, the real answer I think is to add an opcode as suggested in the source code that coalesces keyword arguments into dicts rather than "the weird dance" as the previous authors described it, or turning each argument into an individual dict and merging them at the end as you're doing… -- ___ Python tracker <http://bugs.python.org/issue2292> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2292] Missing *-unpacking generalizations
Neil Girdhar added the comment: Ah, nice! I didn't realize what STORE_MAP did. I thought it created a map each time. We'll just do it your way. -- ___ Python tracker <http://bugs.python.org/issue2292> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2292] Missing *-unpacking generalizations
Neil Girdhar added the comment:
Detecting overrides and raising TypeError. E.g.,
>>> def f(x, y):
... print(x, y)
...
>>> f(x=5, **{'x': 3}, y=2)
Traceback (most recent call last):
...
TypeError: f() got multiple values for keyword argument 'x'
--
Added file: http://bugs.python.org/file37801/starunpack10.diff
___
Python tracker
<http://bugs.python.org/issue2292>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2292] Missing *-unpacking generalizations
Neil Girdhar added the comment: Added many tests, six of which fail. Started work on grammar to fix new tests. -- Added file: http://bugs.python.org/file37805/starunpack11.diff ___ Python tracker <http://bugs.python.org/issue2292> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2292] Missing *-unpacking generalizations
Neil Girdhar added the comment: Very nice! So what's left besides errors? * Fixing the grammar, ast, and compilation for the list, dict, and set comprehension element unpackings > Now the primary problem is giving good errors; I don't know how to make them > look like they came from the function call. I'm not sure I want to, either, > since these opcodes are used elsewhere. The _UNPACK opcodes are new in this changelist. You can do "hg vdiff" to give a side-by-side diff or just check in the patch review. -- ___ Python tracker <http://bugs.python.org/issue2292> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2292] Missing *-unpacking generalizations
Neil Girdhar added the comment: Oh, I see. For BUILD_MAP_UNPACK we don't want to raise on duplicate dict comprehension element unpackings, right? Maybe we should add a different opcode, or else a flag to the opcodes, or else use the top bit of the length parameter? What do you think? -- ___ Python tracker <http://bugs.python.org/issue2292> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2292] Missing *-unpacking generalizations
Neil Girdhar added the comment: I am a huge fan of giving good errors. Looks good to me. Will we need to make sure that the call helper function we worked on produces additional BUILD_MAP_UNPACK opcodes every 256 dictionaries just in case? -- ___ Python tracker <http://bugs.python.org/issue2292> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2292] Missing *-unpacking generalizations
Neil Girdhar added the comment: Another option to consider is to just use a bit on the BUILD_MAP_UNPACK and then have a stack marking opcode at the function call (not sure what to call it, but say FUNCTION_CALL_MARK) The advantage would be you don't store or calculate relative stack positions. When the interpreter sees the mark, it stores the function call address for use in BUILD_MAP_UNPACK errors. Although I guess you have 24 bits to store the relative stack position? -- ___ Python tracker <http://bugs.python.org/issue2292> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2292] Missing *-unpacking generalizations
Neil Girdhar added the comment: I see your point: if there are 255 dictionaries, there's no room for neither preceding keyword arguments nor positional arguments. Okay, then I like your solution. -- ___ Python tracker <http://bugs.python.org/issue2292> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2292] Missing *-unpacking generalizations
Neil Girdhar added the comment: Also maybe not in this changelist, but we should consider replacing STORE_MAP and BUILD_MAP with a single opcode BUILD_MAP(n) that produces a dict out of the top n items on the stack just like BUILD_LIST(n) does. What do you think? -- ___ Python tracker <http://bugs.python.org/issue2292> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2292] Missing *-unpacking generalizations
Neil Girdhar added the comment: You're right. -- ___ Python tracker <http://bugs.python.org/issue2292> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2292] Missing *-unpacking generalizations
Neil Girdhar added the comment: BUILD_MAP(n) -- Added file: http://bugs.python.org/file37817/starunpack14.diff ___ Python tracker <http://bugs.python.org/issue2292> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2292] Missing *-unpacking generalizations
Changes by Neil Girdhar : Added file: http://bugs.python.org/file37821/starunpack14.diff ___ Python tracker <http://bugs.python.org/issue2292> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2292] Missing *-unpacking generalizations
Changes by Neil Girdhar : Removed file: http://bugs.python.org/file37817/starunpack14.diff ___ Python tracker <http://bugs.python.org/issue2292> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2292] Missing *-unpacking generalizations
Neil Girdhar added the comment: By the way, Joshua if you wanted to edit the text of the PEP, it might be nice to point out that this replaces itertools.chain.from_iterable. I know you mention one use of itertools.chain, but I think this nicely replaces all uses of both: itertools.chain(a, b, c) is (*x for x in [a, b, c]) itertools.chain.from_iterable(it) is (*x for x in it) -- ___ Python tracker <http://bugs.python.org/issue2292> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2292] Missing *-unpacking generalizations
Neil Girdhar added the comment: In that case, another option would be to use that to send the "number of maps" to CALL_FUNCTION and let it do the BUILD_MAP_UNPACK stuff itself. Would that simplify your ideas regarding error handling? -- ___ Python tracker <http://bugs.python.org/issue2292> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2292] Missing *-unpacking generalizations
Neil Girdhar added the comment: Sorry, I don't know enough about how you were planning on using the stack pointer difference to produce good errors. I thought that if you waited for the CALL_FUNCTION to be happening before reporting errors about duplicate parameters it might simplify that code. -- ___ Python tracker <http://bugs.python.org/issue2292> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2292] Missing *-unpacking generalizations
Neil Girdhar added the comment: Okay, I didn't realize it was so simple to raise the error from somewhere else. Regarding "duplicate the (large) dictionary merging function" — of course we would just factor it out into a function. -- ___ Python tracker <http://bugs.python.org/issue2292> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2292] Missing *-unpacking generalizations
Neil Girdhar added the comment: That's true. But wouldn't the offset always be one (or three or whatever) since if we do BUILD_MAP_UNPACK in a function call it's always right before CALL_FUNCTION? -- ___ Python tracker <http://bugs.python.org/issue2292> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2292] Missing *-unpacking generalizations
Neil Girdhar added the comment: What do you mean by the stack will "have the function"? At the point that you're doing BUILD_MAP_UNPACK, CALL_FUNCTION hasn't been executed… -- ___ Python tracker <http://bugs.python.org/issue2292> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2292] Missing *-unpacking generalizations
Neil Girdhar added the comment: when does that get pushed on the stack? -- ___ Python tracker <http://bugs.python.org/issue2292> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2292] Missing *-unpacking generalizations
Neil Girdhar added the comment:
Oh, thanks I see, by the LOAD_BUILD_CLASS or VISIT(c, expr, e->v.Call.func)
?
Ok, I see. Why do the errors work now for f(x=1, **{'x': 2}) — these are
happening at BUILD_MAP_UNPACK without a stack pointer adjustment. For me, the
error message mentions 'f' by name. Is that not the error message you're
trying to fix?
--
___
Python tracker
<http://bugs.python.org/issue2292>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2292] Missing *-unpacking generalizations
Neil Girdhar added the comment:
Ah, sorry, yes, this is what I meant (and I see what your'e trying to fix now!):
>>> import dis
>>> def f(x,y): pass
...
>>> dis.dis("f(y=1, **{'x': 1}, x=2)")
1 0 LOAD_NAME0 (f)
3 LOAD_CONST 0 ('y')
6 LOAD_CONST 1 (1)
9 LOAD_CONST 1 (1)
12 LOAD_CONST 2 ('x')
15 BUILD_MAP1
18 LOAD_CONST 3 (2)
21 LOAD_CONST 2 ('x')
24 BUILD_MAP1
27 BUILD_MAP_UNPACK 2
30 CALL_FUNCTION_KW 256 (0 positional, 1 keyword pair)
33 RETURN_VALUE
>>> f(y=1, **{'x': 1}, x=2)
Traceback (most recent call last):
File "", line 1, in
TypeError: () got multiple values for keyword argument 'x'
>>>
--
___
Python tracker
<http://bugs.python.org/issue2292>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2292] Missing *-unpacking generalizations
Neil Girdhar added the comment: I was also thinking of unifying it all, but I couldn't find a way to ensure that the most common case (which I assume is f(x, y, z=0, w=0, *args, **kwargs)) produces no additional opcodes. If you have a nice unification, I look forward to it. -- ___ Python tracker <http://bugs.python.org/issue2292> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2292] Missing *-unpacking generalizations
Neil Girdhar added the comment: Dict displays work. -- Added file: http://bugs.python.org/file37851/starunpack15.diff ___ Python tracker <http://bugs.python.org/issue2292> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2292] Missing *-unpacking generalizations
Neil Girdhar added the comment: Dict comprehensions work. -- Added file: http://bugs.python.org/file37852/starunpack16.diff ___ Python tracker <http://bugs.python.org/issue2292> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2292] Missing *-unpacking generalizations
Neil Girdhar added the comment: All tests pass, polishing. Joshua, I'm still not sure how to do show the right error for the function call with duplicate arguments… -- Added file: http://bugs.python.org/file37853/starunpack17.diff ___ Python tracker <http://bugs.python.org/issue2292> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2292] Missing *-unpacking generalizations
Neil Girdhar added the comment: Fixed all tests except test_parser. New node numbers are not reflected here for some reason. -- Added file: http://bugs.python.org/file37854/starunpack18.diff ___ Python tracker <http://bugs.python.org/issue2292> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23316] Incorrect evaluation order of function arguments with *args
Neil Girdhar added the comment:
I assume this is the problem:
>>> dis.dis('f(*a(), b=b())')
1 0 LOAD_NAME0 (f)
3 LOAD_NAME1 (a)
6 CALL_FUNCTION0 (0 positional, 0 keyword pair)
9 LOAD_CONST 0 ('b')
12 LOAD_NAME2 (b)
15 CALL_FUNCTION0 (0 positional, 0 keyword pair)
18 CALL_FUNCTION_VAR 256 (0 positional, 1 keyword pair)
21 RETURN_VALUE
— looks fine.
>>> dis.dis('f(b=b(), *a())')
1 0 LOAD_NAME0 (f)
3 LOAD_NAME1 (a)
6 CALL_FUNCTION0 (0 positional, 0 keyword pair)
9 LOAD_CONST 0 ('b')
12 LOAD_NAME2 (b)
15 CALL_FUNCTION0 (0 positional, 0 keyword pair)
18 CALL_FUNCTION_VAR 256 (0 positional, 1 keyword pair)
21 RETURN_VALUE
Joshua, we could make function calls take:
x lists
y dictionaries
one optional list
z dictionaries
but we as well do all the merging in advance:
one optional list
one optional dictionary
one optional list
one optional dictionary
which is representable in three bits, but four is easier to decode I think.
--
nosy: +neil.g
___
Python tracker
<http://bugs.python.org/issue23316>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23316] Incorrect evaluation order of function arguments with *args
Neil Girdhar added the comment: actually, we accept alternation, so maybe a bit to say whether we start with a list or a dict followed by a length of the alternating sequence? -- ___ Python tracker <http://bugs.python.org/issue23316> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23316] Incorrect evaluation order of function arguments with *args
Neil Girdhar added the comment: Yes, sorry David. I got linked here from the other issue. In any case, in the current code, the longest alternating sequence possible is 4. So one way to solve this is to change the CALL_FUNCTION parameters to be lists and dicts only and then process the final merging in CALL_FUNCTION. -- ___ Python tracker <http://bugs.python.org/issue23316> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23316] Incorrect evaluation order of function arguments with *args
Neil Girdhar added the comment: another option is to add a LIST_EXTEND(stack_difference) opcode that would allow us to take the late iterable and extend a list at some arbitrary stack position. I had to add something like that for dicts for the other issue, so it would follow that pattern. -- ___ Python tracker <http://bugs.python.org/issue23316> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2292] Missing *-unpacking generalizations
Neil Girdhar added the comment: Sounds good. I'll stop working until I see your patch. I tried to make it easy for you to implement your error idea wrt BUILD_MAP_UNPACK :) -- ___ Python tracker <http://bugs.python.org/issue2292> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23316] Incorrect evaluation order of function arguments with *args
Neil Girdhar added the comment: After thinking about this a bit more, my suggestion is not to fix it. Instead, I suggest that PEP 8 be modified to suggest that all positional arguments and iterable argument unpackings precede keyword arguments and keyword argument unpackings. Then, a tool like autopep8 is free to reorganize argument lists. Such reorganization will not be possible if f(*a(), b=b()) is different than f(b=b(), *a()). -- ___ Python tracker <http://bugs.python.org/issue23316> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2292] Missing *-unpacking generalizations
Neil Girdhar added the comment: >>> def f(a, *b): print(list(a), list(b)) -- ___ Python tracker <http://bugs.python.org/issue2292> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2292] Missing *-unpacking generalizations
Neil Girdhar added the comment: Is this correct? >>> f(*i for i in ['abc', 'def']) ['a', 'b', 'c', 'd', 'e', 'f'] [] >>> f(**i for i in ['abc', 'def']) File "", line 1 f(**i for i in ['abc', 'def']) ^ SyntaxError: invalid syntax Should neither work? Both? -- ___ Python tracker <http://bugs.python.org/issue2292> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2292] Missing *-unpacking generalizations
Neil Girdhar added the comment:
Could you help me understand this a bit better?
I always thought of f(x for x in l) as equivalent to f( (x for x in l) ).
So, I can see that f(*x for x in l) should be equivalent to f( (*x for x in l)
).
How should we interpret f(**x for x in l)? Is it then f( {**x for x in l} )?
--
___
Python tracker
<http://bugs.python.org/issue2292>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23316] Incorrect evaluation order of function arguments with *args
Neil Girdhar added the comment: (I also suggest that the evaluation order within a function argument list to be defined to be positional and iterable before keyword, otherwise left-to-right — rather than strictly left-to-right). -- ___ Python tracker <http://bugs.python.org/issue23316> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2292] Missing *-unpacking generalizations
Neil Girdhar added the comment: fixed a minor bug with the function address, and made a number of polishing changes. -- Added file: http://bugs.python.org/file37871/starunpack21.diff ___ Python tracker <http://bugs.python.org/issue2292> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2292] Missing *-unpacking generalizations
Changes by Neil Girdhar : Added file: http://bugs.python.org/file37876/starunpack22.diff ___ Python tracker <http://bugs.python.org/issue2292> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2292] Missing *-unpacking generalizations
Neil Girdhar added the comment: Everything seems to work except two tests are still failing: parser and venv. Any ideas Joshua? Also, we have to decide what to do with f(*x for x in l) and f(**x for x in l). -- Added file: http://bugs.python.org/file37877/starunpack23.diff ___ Python tracker <http://bugs.python.org/issue2292> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2292] Missing *-unpacking generalizations
Neil Girdhar added the comment: Fixed a couple bugs and added a test. Incremented the magic number. -- Added file: http://bugs.python.org/file37896/starunpack24.diff ___ Python tracker <http://bugs.python.org/issue2292> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2292] Missing *-unpacking generalizations
Neil Girdhar added the comment:
Just need to fix the parser now. Minimal example:
>>> parser.sequence2st(parser.expr("{1}").totuple())
Traceback (most recent call last):
File "", line 1, in
parser.ParserError: Expected node type 12, got 302.
--
___
Python tracker
<http://bugs.python.org/issue2292>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2292] Missing *-unpacking generalizations
Neil Girdhar added the comment: All tests pass. @Guido: can we get some clarification on f(*… and f(**…? One option is to make them illegal for now and then open them up in a future PEP when it's more clear what's wanted? -- Added file: http://bugs.python.org/file37911/starunpack25.diff ___ Python tracker <http://bugs.python.org/issue2292> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
