Neil Girdhar added the comment:
BUILD_MAP(n)
--
Added file: http://bugs.python.org/file37817/starunpack14.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2292
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:
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
Neil Girdhar added the comment:
when does that get pushed on the stack?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2292
___
___
Python-bugs
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
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 rep...@bugs.python.org
http
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
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 rep...@bugs.python.org
http://bugs.python.org
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
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:
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
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 rep...@bugs.python.org
http://bugs.python.org/issue2292
___
___
Python-bugs-list mailing list
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 positions
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
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 rep...@bugs.python.org
http
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 rep...@bugs.python.org
http://bugs.python.org
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
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
Changes by Neil Girdhar mistersh...@gmail.com:
Added file: http://bugs.python.org/file37788/starunpack4.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2292
Changes by Neil Girdhar mistersh...@gmail.com:
Removed file: http://bugs.python.org/file37787/starunpack4.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2292
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
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 rep...@bugs.python.org
http://bugs.python.org/issue2292
Changes by Neil Girdhar mistersh...@gmail.com:
Added file: http://bugs.python.org/file37792/starunpack6.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2292
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 rep...@bugs.python.org
http://bugs.python.org/issue2292
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 rep...@bugs.python.org
http://bugs.python.org/issue2292
Neil Girdhar added the comment:
Post it? It's just hg diff a.diff
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2292
___
___
Python-bugs-list
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
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
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': 4})
which currently works
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 rep...@bugs.python.org
http://bugs.python.org
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 rep...@bugs.python.org
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
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:
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
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 rep...@bugs.python.org
http://bugs.python.org/issue16540
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
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
101 - 142 of 142 matches
Mail list logo
