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
Neil Girdhar added the comment:
Ready for a code review:
Blocked f(*x for x…) as requested.
Polished up parsermodule.c.
--
Added file: http://bugs.python.org/file37920/starunpack26.diff
___
Python tracker
<http://bugs.python.org/issue2
Neil Girdhar added the comment:
Fixed a bug and added a test.
--
Added file: http://bugs.python.org/file37921/starunpack27.diff
___
Python tracker
<http://bugs.python.org/issue2
Neil Girdhar added the comment:
Is it possible to edit the PEP to reflect the current design decisions?
Specifically:
* Remove: "Because of the new levity for * and ** unpackings, it may be
advisable to lift some or all of these restrictions." (in both abstract and
specification
Changes by Neil Girdhar :
Added file: http://bugs.python.org/file37925/starunpack28.diff
___
Python tracker
<http://bugs.python.org/issue2292>
___
___
Python-bugs-list m
Neil Girdhar added the comment:
Fixed a bug in ceval.c; added a test to test_unpack_ex.
--
___
Python tracker
<http://bugs.python.org/issue2292>
___
___
Python-bug
Changes by Neil Girdhar :
Added file: http://bugs.python.org/file37924/starunpack28.diff
___
Python tracker
<http://bugs.python.org/issue2292>
___
___
Python-bugs-list m
Changes by Neil Girdhar :
Removed file: http://bugs.python.org/file37924/starunpack28.diff
___
Python tracker
<http://bugs.python.org/issue2292>
___
___
Python-bugs-list m
Neil Girdhar added the comment:
Another bug, another test.
--
Added file: http://bugs.python.org/file37926/starunpack29.diff
___
Python tracker
<http://bugs.python.org/issue2
Changes by Neil Girdhar :
Added file: http://bugs.python.org/file38062/starunpack31.diff
___
Python tracker
<http://bugs.python.org/issue2292>
___
___
Python-bugs-list m
Neil Girdhar added the comment:
Thank you, Benjamin.
It's my nature to keep code consistent/clean, but I realize that I can get
carried away. Should I revert all incidental PEP 7 style changes?
Regarding the args/keywords, where do you mean? If you're talking about
compile.c
Neil Girdhar added the comment:
Removed incidental PEP 7 changes and reran tests.
--
Added file: http://bugs.python.org/file38070/starunpack32.diff
___
Python tracker
<http://bugs.python.org/issue2
New submission from Neil Gierman:
Using a scoped IPv6 address with urllib2 creates an invalid Host header that
Apache will not accept.
IP = "fe80:::::0001%eth0"
req = urllib2.Request("http://["; + IP + "]/")
req.add_header(&#x
Neil Girdhar added the comment:
Simplified functools.partial documentation.
--
Added file: http://bugs.python.org/file39561/wn2.diff
___
Python tracker
<http://bugs.python.org/issue24
Changes by Neil Girdhar :
Added file: http://bugs.python.org/file39562/wn2.diff
___
Python tracker
<http://bugs.python.org/issue24136>
___
___
Python-bugs-list mailin
Neil Girdhar added the comment:
I don't receive emails from the tracker anymore either and I have no idea why
that is.
--
___
Python tracker
<http://bugs.python.org/is
Neil Girdhar added the comment:
Copied from closed issue 24240:
Since Grammar/Grammar relies on semantic postprocessing in ast.c,
it would be nice to have an update of the (human readable) Grammar
in the language reference docs.
--
___
Python
New submission from Neil Girdhar:
In the description of the consume recipe:
def consume(iterator, n):
"Advance the iterator n-steps ahead. If n is none, consume entirely."
# Use functions that consume iterators at C speed.
if n is None:
# feed the entire iterator i
Neil Girdhar added the comment:
Ah, good point.
--
___
Python tracker
<http://bugs.python.org/issue24624>
___
___
Python-bugs-list mailing list
Unsubscribe:
Neil Schemenauer added the comment:
I don't see how that patch can be correct. The logic is now if the directory
has two links inside it then skip it. The filesystems that don't count '.' and
'..' will have zero links when empty and will have two links when two
Neil Schemenauer added the comment:
So what happens for the filesystems that doesn't count '.' and '..'? It looks
to me like if there are exactly two messages in a folder then the revised code
will return [] (i.e. it will think the folder is empty). Probably we sho
Neil Schemenauer added the comment:
Okay, feel free to close this bug. I had heard that HFS+ counts files but I
don't have a way to verify that.
--
___
Python tracker
<http://bugs.python.org/i
Neil Girdhar added the comment:
I'm also looking for bisect with a key argument (numpy array of records, want
to search on one element). However, I don't see bisect in the what's new:
https://docs.python.org/3.6/whatsnew/3.6.html ? Any luck with the
implementation?
-
Neil Girdhar added the comment:
Also, please add the following test: "{*{True, 1}}"
Should be True.
--
___
Python tracker
<http://bugs.python.o
Neil Girdhar added the comment:
Please don't forget to fix BUILD_SET_UNPACK to match.
--
___
Python tracker
<http://bugs.python.org/issue26020>
___
___
Pytho
Neil Girdhar added the comment:
Ah, sorry, I somehow went cross-eyed. Not sure offhand which test would test
the BUILD_TUPLE_UNPACK, but I think you're right Serhiy. Could just add both?
--
___
Python tracker
<http://bugs.python.org/is
Neil Girdhar added the comment:
New changelist for updated patch (before merging changes).
--
Added file: http://bugs.python.org/file38252/starunpack33.diff
___
Python tracker
<http://bugs.python.org/issue2
Neil Girdhar added the comment:
Finished merge.
--
Added file: http://bugs.python.org/file38253/starunpack34.diff
___
Python tracker
<http://bugs.python.org/issue2
Neil Girdhar added the comment:
FWIW I looked at the changes. Does it make sense to run tests before there are
actual tests in lib/Test? I'll happily run all tests when some new ones are
added.
--
nosy: +neil.g
___
Python tracker
Neil Girdhar added the comment:
Removed dead code. Awaiting code review! :)
--
Added file: http://bugs.python.org/file38341/starunpack35.diff
___
Python tracker
<http://bugs.python.org/issue2
Neil Girdhar added the comment:
Nice work Alexander. I believe what's left is for it to work with complex
numbers.
--
nosy: +neil.g
___
Python tracker
<http://bugs.python.org/is
Changes by Neil Girdhar :
Added file: http://bugs.python.org/file38395/starunpack36.diff
___
Python tracker
<http://bugs.python.org/issue2292>
___
___
Python-bugs-list m
Changes by Neil Girdhar :
Added file: http://bugs.python.org/file38429/starunpack37.diff
___
Python tracker
<http://bugs.python.org/issue2292>
___
___
Python-bugs-list m
Changes by Neil Girdhar :
Added file: http://bugs.python.org/file38611/starunpack38.diff
___
Python tracker
<http://bugs.python.org/issue2292>
___
___
Python-bugs-list m
Neil Girdhar added the comment:
Removed a confusing and outdated comment in Lib/importlib/_bootstrap.py
--
Added file: http://bugs.python.org/file38613/starunpack39.diff
___
Python tracker
<http://bugs.python.org/issue2
Changes by Neil Girdhar :
Added file: http://bugs.python.org/file38856/starunpack40.diff
___
Python tracker
<http://bugs.python.org/issue2292>
___
___
Python-bugs-list m
Changes by Neil Girdhar :
Added file: http://bugs.python.org/file39059/starunpack41.diff
___
Python tracker
<http://bugs.python.org/issue2292>
___
___
Python-bugs-list m
Neil Girdhar added the comment:
Hi Steve:
I have limited expertise in most of these areas, but I looked at
starunpack40.diff and have these comments:
* tests look to have good coverage of the feature (can't speak to coverage of
the parser/compiler code)
* parsermodule.c changes comprehe
Neil Girdhar added the comment:
All tests pass. All reviewer comments addressed. Please let me know if
anything else needs to be done from my end.
--
Added file: http://bugs.python.org/file39230/starunpack42.diff
___
Python tracker
<h
Neil Girdhar added the comment:
Just updated the "what's new". Also, thank you for adding my name to
Misc/Acks. Should we also add Joshua Landau's name? He helped me quite a bit
with the implementation, and he wrote the PEP.
--
keywords: +patch
nosy: +nei
New submission from Neil Girdhar:
Minimum working example:
class MyMetaclass(type):
pass
class OtherMetaclass(type):
pass
def metaclass_callable(name, bases, namespace):
return OtherMetaclass(name, bases, namespace)
class MyClass(metaclass=MyMetaclass):
pass
try:
class
Neil Girdhar added the comment:
Oops, I meant:
MyDerived = new_class("MyDerived", (MyClass,),
dict(metaclass=metaclass_callable))
Nevertheless, the exception line number is totally off because it's tripping in
the C code rather than in the Python code of th
Neil Girdhar added the comment:
The documentation suggests that you can have a metaclass that does is not the
"most derived metaclass" provided you specify one that is not an instance of
type. This doesn't work in CPython, so I would suggest fixing the
documentation using the
Neil Girdhar added the comment:
>From your comment:
>>> MyDerivedDynamic = new_class("MyDerivedDynamic", (MyClass,),
>>> dict(metaclass=metaclass_callable))
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib64/python3.5/ty
Neil Girdhar added the comment:
"As a result of this, *both* implementations include a conditional check for a
more derived metaclass in their namespace preparation logic, as well as an
unconditional call to that metaclass derivation logic from type_new if the
calculated metaclass is e
Neil Girdhar added the comment:
Thanks for taking the time to explain, but it's still not working for me:
from types import new_class
class MyMetaclass(type):
pass
class OtherMetaclass(type):
pass
def metaclass_callable(name, bases, namespace):
return new_class(name, bases,
Neil Girdhar added the comment:
Okay, I understand what you're saying, but I it says in the documentation that
"if an explicit metaclass is given and it is not an instance of type(), then it
is used directly as the metaclass". My recent updated "metaclass_callable" is
New submission from Neil Schemenauer:
I notice that after running "make" then running "make install", the build will
go through the whole compile/profile/compile process again. This is really
infuriating behaviour, given the extremely long make time for the profiled
o
Neil Schemenauer added the comment:
Okay, my initial idea was wrong (I blame years of not having to look at
Makefiles). I think the attached patch works. It uses a "stamp" file to
record the fact that the profiled build is complete.
The fix is sub-optimal because changing some s
Neil Blakey-Milner <[EMAIL PROTECTED]> added the comment:
This affects OS X too.
I'm attaching two patches - one uses malloc to build a bigger string if
the existing implementation returns ERANGE, and the other one uses
malloc from the start. This was done on the theory that stack
Changes by Neil Blakey-Milner <[EMAIL PROTECTED]>:
Added file: http://bugs.python.org/file10241/python-getcwd-malloconly.patch
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Neil Blakey-Milner <[EMAIL PROTECTED]> added the comment:
Here's a patch to add a test that fails with Python 2.5 on OS X, but
passes with either of these patches.
Added file:
http://bugs.python.org/file10250/python-getcwd-test_longpathnames.patch
___
601 - 674 of 674 matches
Mail list logo
