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
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 si
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 d
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
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
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 diffe
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 ver
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(), &quo
Neil Girdhar added the comment:
FYI: https://github.com/PyCQA/pylint/issues/4586
--
___
Python tracker
<https://bugs.python.org/issue23316>
___
___
Python-bug
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/issue4
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 comme
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
partialmet
Change by Neil Girdhar :
--
components: +Library (Lib)
type: -> enhancement
___
Python tracker
<https://bugs.python.org/issue33419>
___
___
Python-bugs-lis
Change by Neil Girdhar :
Added file: https://bugs.python.org/file47568/partialclass2.diff
___
Python tracker
<https://bugs.python.org/issue33419>
___
___
Python-bug
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
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
Change by Neil Girdhar :
Added file: https://bugs.python.org/file47569/partialclass3.diff
___
Python tracker
<https://bugs.python.org/issue33419>
___
___
Python-bug
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/issue33
Neil Girdhar added the comment:
Done: https://github.com/python/cpython/pull/6699
--
___
Python tracker
<https://bugs.python.org/issue33419>
___
___
Python-bug
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 cl
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/D
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
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 Nam
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 initiali
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:
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
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/issue16
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
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
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 t
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
Neil Girdhar added the comment:
Great patch. Shouldn't Sequence be a "Reversible, Collection"?
--
___
Python tracker
<http://bugs.python.org/issue27598>
___
_
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/issue27
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
Changes by Neil Girdhar :
--
components: +Library (Lib)
versions: +Python 3.6
___
Python tracker
<http://bugs.python.org/issue27802>
___
___
Python-bugs-list m
Changes by Neil Girdhar :
--
keywords: +patch
Added file: http://bugs.python.org/file44151/abc_eq.diff
___
Python tracker
<http://bugs.python.org/issue27
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
<h
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/issu
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.o
Neil Girdhar added the comment:
(there's already an open thread.)
--
___
Python tracker
<http://bugs.python.org/issue27802>
___
___
Python-bugs-list m
Neil Girdhar added the comment:
(never mind about the comparison operators :) Turns out that would break
backwards compatibility.)
--
___
Python tracker
<http://bugs.python.org/issue27
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
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
Changes by Neil Girdhar :
Added file: http://bugs.python.org/file37788/starunpack4.diff
___
Python tracker
<http://bugs.python.org/issue2292>
___
___
Python-bugs-list m
Changes by Neil Girdhar :
Removed file: http://bugs.python.org/file37787/starunpack4.diff
___
Python tracker
<http://bugs.python.org/issue2292>
___
___
Python-bugs-list m
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 wi
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
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/issue2
Changes by Neil Girdhar :
Added file: http://bugs.python.org/file37792/starunpack6.diff
___
Python tracker
<http://bugs.python.org/issue2292>
___
___
Python-bugs-list m
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.
--
___
P
Neil Girdhar added the comment:
Post it? It's just "hg diff > a.diff"
--
___
Python tracker
<http://bugs.python.org/issue2292>
___
___
Pytho
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/issue2
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 a
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
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
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
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
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.
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 va
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/issue2
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 th
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
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
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 posi
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.py
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
Neil Girdhar added the comment:
You're right.
--
___
Python tracker
<http://bugs.python.org/issue2292>
___
___
Python-bugs-list mailing list
Unsubscr
Neil Girdhar added the comment:
BUILD_MAP(n)
--
Added file: http://bugs.python.org/file37817/starunpack14.diff
___
Python tracker
<http://bugs.python.org/issue2
Changes by Neil Girdhar :
Added file: http://bugs.python.org/file37821/starunpack14.diff
___
Python tracker
<http://bugs.python.org/issue2292>
___
___
Python-bugs-list m
Changes by Neil Girdhar :
Removed file: http://bugs.python.org/file37817/starunpack14.diff
___
Python tracker
<http://bugs.python.org/issue2292>
___
___
Python-bugs-list m
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
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?
--
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
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.
--
___
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
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://bu
Neil Girdhar added the comment:
when does that get pushed on the stack?
--
___
Python tracker
<http://bugs.python.org/issue2292>
___
___
Python-bugs-list mailin
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 messag
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_NAME
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
Neil Girdhar added the comment:
Dict displays work.
--
Added file: http://bugs.python.org/file37851/starunpack15.diff
___
Python tracker
<http://bugs.python.org/issue2
Neil Girdhar added the comment:
Dict comprehensions work.
--
Added file: http://bugs.python.org/file37852/starunpack16.diff
___
Python tracker
<http://bugs.python.org/issue2
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
___
P
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/issue2
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)
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/issue23
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
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
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/i
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
Neil Girdhar added the comment:
>>> def f(a, *b): print(list(a), list(b))
--
___
Python tracker
<http://bugs.python.org/issue2292>
___
___
Python-bugs-li
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'])
Fi
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
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
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/issue2
Changes by Neil Girdhar :
Added file: http://bugs.python.org/file37876/starunpack22.diff
___
Python tracker
<http://bugs.python.org/issue2292>
___
___
Python-bugs-list m
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
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/issue2
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: E
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/st
1 - 100 of 142 matches
Mail list logo
