[issue18844] allow weights in random.choice

2013-09-11 Thread Neil Girdhar
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

[issue16540] Make itertools count, cycle, and repeat objects subscriptable like range.

2012-11-23 Thread Neil Girdhar
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

[issue16540] Make itertools count, cycle, and repeat objects subscriptable like range.

2012-11-23 Thread Neil Girdhar
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

[issue16540] Make itertools count, cycle, and repeat objects subscriptable like range.

2012-11-23 Thread Neil Girdhar
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

[issue16540] Make itertools count, cycle, and repeat objects subscriptable like range.

2012-11-23 Thread Neil Girdhar
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

[issue16540] Make itertools count, cycle, and repeat objects subscriptable like range.

2012-11-23 Thread Neil Girdhar
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

[issue2292] Missing *-unpacking generalizations

2015-01-22 Thread Neil Girdhar
Changes by Neil Girdhar mistersh...@gmail.com: Added file: http://bugs.python.org/file37821/starunpack14.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2292

[issue2292] Missing *-unpacking generalizations

2015-01-22 Thread Neil Girdhar
Changes by Neil Girdhar mistersh...@gmail.com: Removed file: http://bugs.python.org/file37817/starunpack14.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2292

[issue2292] Missing *-unpacking generalizations

2015-01-22 Thread Neil Girdhar
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

[issue2292] Missing *-unpacking generalizations

2015-01-26 Thread Neil Girdhar
Neil Girdhar added the comment: def f(a, *b): print(list(a), list(b)) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2292 ___ ___ Python-bugs

[issue2292] Missing *-unpacking generalizations

2015-01-26 Thread Neil Girdhar
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 stdin, line 1 f(**i for i in ['abc', 'def']) ^ SyntaxError: invalid syntax Should neither work? Both

[issue23316] Incorrect evaluation order of function arguments with *args

2015-01-26 Thread Neil Girdhar
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

[issue23316] Incorrect evaluation order of function arguments with *args

2015-01-26 Thread Neil Girdhar
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

[issue2292] Missing *-unpacking generalizations

2015-01-26 Thread Neil Girdhar
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

[issue2292] Missing *-unpacking generalizations

2015-01-30 Thread Neil Girdhar
Neil Girdhar added the comment: Another bug, another test. -- Added file: http://bugs.python.org/file37926/starunpack29.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2292

[issue2292] Missing *-unpacking generalizations

2015-01-30 Thread Neil Girdhar
Neil Girdhar added the comment: Fixed a bug in ceval.c; added a test to test_unpack_ex. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2292

[issue2292] Missing *-unpacking generalizations

2015-01-30 Thread Neil Girdhar
Changes by Neil Girdhar mistersh...@gmail.com: Added file: http://bugs.python.org/file37924/starunpack28.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2292

[issue2292] Missing *-unpacking generalizations

2015-01-30 Thread Neil Girdhar
Changes by Neil Girdhar mistersh...@gmail.com: Added file: http://bugs.python.org/file37925/starunpack28.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2292

[issue2292] Missing *-unpacking generalizations

2015-01-30 Thread Neil Girdhar
Changes by Neil Girdhar mistersh...@gmail.com: Removed file: http://bugs.python.org/file37924/starunpack28.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2292

[issue2292] Missing *-unpacking generalizations

2015-01-19 Thread Neil Girdhar
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

[issue2292] Missing *-unpacking generalizations

2015-01-20 Thread Neil Girdhar
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

[issue2292] Missing *-unpacking generalizations

2015-01-20 Thread Neil Girdhar
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

[issue2292] Missing *-unpacking generalizations

2015-01-20 Thread Neil Girdhar
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

[issue2292] Missing *-unpacking generalizations

2015-01-20 Thread Neil Girdhar
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

[issue2292] Missing *-unpacking generalizations

2015-01-20 Thread Neil Girdhar
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

[issue2292] Missing *-unpacking generalizations

2015-01-20 Thread Neil Girdhar
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

[issue2292] Missing *-unpacking generalizations

2015-01-20 Thread Neil Girdhar
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

[issue2292] Missing *-unpacking generalizations

2015-01-20 Thread Neil Girdhar
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

[issue2292] Missing *-unpacking generalizations

2015-01-20 Thread Neil Girdhar
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

[issue2292] Missing *-unpacking generalizations

2015-01-20 Thread Neil Girdhar
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

[issue2292] Missing *-unpacking generalizations

2015-01-20 Thread Neil Girdhar
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

[issue2292] Missing *-unpacking generalizations

2015-01-20 Thread Neil Girdhar
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

[issue2292] Missing *-unpacking generalizations

2015-01-20 Thread Neil Girdhar
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

[issue2292] Missing *-unpacking generalizations

2015-01-20 Thread Neil Girdhar
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

[issue2292] Missing *-unpacking generalizations

2015-01-20 Thread Neil Girdhar
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

[issue2292] Missing *-unpacking generalizations

2015-01-20 Thread Neil Girdhar
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

[issue2292] Missing *-unpacking generalizations

2015-01-21 Thread Neil Girdhar
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

[issue2292] Missing *-unpacking generalizations

2015-01-21 Thread Neil Girdhar
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

[issue2292] Missing *-unpacking generalizations

2015-01-21 Thread Neil Girdhar
Neil Girdhar added the comment: You're right. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2292 ___ ___ Python-bugs-list mailing list

[issue2292] Missing *-unpacking generalizations

2015-01-21 Thread Neil Girdhar
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

[issue2292] Missing *-unpacking generalizations

2015-01-21 Thread Neil Girdhar
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

[issue2292] Missing *-unpacking generalizations

2015-01-21 Thread Neil Girdhar
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

[issue2292] Missing *-unpacking generalizations

2015-01-21 Thread Neil Girdhar
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

[issue2292] Missing *-unpacking generalizations

2015-01-22 Thread Neil Girdhar
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

[issue2292] Missing *-unpacking generalizations

2015-01-22 Thread Neil Girdhar
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

[issue2292] Missing *-unpacking generalizations

2015-01-22 Thread Neil Girdhar
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

[issue2292] Missing *-unpacking generalizations

2015-01-22 Thread Neil Girdhar
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

[issue2292] Missing *-unpacking generalizations

2015-01-22 Thread Neil Girdhar
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

[issue2292] Missing *-unpacking generalizations

2015-01-22 Thread Neil Girdhar
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

[issue2292] Missing *-unpacking generalizations

2015-01-22 Thread Neil Girdhar
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

[issue2292] Missing *-unpacking generalizations

2015-01-22 Thread Neil Girdhar
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

[issue2292] Missing *-unpacking generalizations

2015-01-22 Thread Neil Girdhar
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

[issue2292] Missing *-unpacking generalizations

2015-01-22 Thread Neil Girdhar
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

[issue2292] Missing *-unpacking generalizations

2015-01-20 Thread Neil Girdhar
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

[issue2292] Missing *-unpacking generalizations

2015-01-21 Thread Neil Girdhar
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

[issue2292] Missing *-unpacking generalizations

2015-01-26 Thread Neil Girdhar
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

[issue2292] Missing *-unpacking generalizations

2015-01-28 Thread Neil Girdhar
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 rep...@bugs.python.org http://bugs.python.org/issue2292

[issue2292] Missing *-unpacking generalizations

2015-01-28 Thread Neil Girdhar
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 stdin, line 1, in module parser.ParserError: Expected node type 12, got 302

[issue2292] Missing *-unpacking generalizations

2015-01-25 Thread Neil Girdhar
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 rep...@bugs.python.org http

[issue2292] Missing *-unpacking generalizations

2015-01-25 Thread Neil Girdhar
Neil Girdhar added the comment: Dict comprehensions work. -- Added file: http://bugs.python.org/file37852/starunpack16.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2292

[issue23316] Incorrect evaluation order of function arguments with *args

2015-01-25 Thread Neil Girdhar
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 rep...@bugs.python.org http://bugs.python.org

[issue23316] Incorrect evaluation order of function arguments with *args

2015-01-25 Thread Neil Girdhar
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

[issue23316] Incorrect evaluation order of function arguments with *args

2015-01-25 Thread Neil Girdhar
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

[issue2292] Missing *-unpacking generalizations

2015-01-25 Thread Neil Girdhar
Neil Girdhar added the comment: Dict displays work. -- Added file: http://bugs.python.org/file37851/starunpack15.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2292

[issue2292] Missing *-unpacking generalizations

2015-01-25 Thread Neil Girdhar
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

[issue2292] Missing *-unpacking generalizations

2015-01-26 Thread Neil Girdhar
Changes by Neil Girdhar mistersh...@gmail.com: Added file: http://bugs.python.org/file37876/starunpack22.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2292

[issue2292] Missing *-unpacking generalizations

2015-01-26 Thread Neil Girdhar
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 rep...@bugs.python.org http://bugs.python.org

[issue2292] Missing *-unpacking generalizations

2015-02-09 Thread Neil Girdhar
Changes by Neil Girdhar mistersh...@gmail.com: Added file: http://bugs.python.org/file38062/starunpack31.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2292

[issue2292] Missing *-unpacking generalizations

2015-02-09 Thread Neil Girdhar
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, we can't

[issue2292] Missing *-unpacking generalizations

2015-02-09 Thread Neil Girdhar
Neil Girdhar added the comment: Removed incidental PEP 7 changes and reran tests. -- Added file: http://bugs.python.org/file38070/starunpack32.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2292

[issue2292] Missing *-unpacking generalizations

2015-03-20 Thread Neil Girdhar
Changes by Neil Girdhar mistersh...@gmail.com: Added file: http://bugs.python.org/file38611/starunpack38.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2292

[issue2292] Missing *-unpacking generalizations

2015-03-20 Thread Neil Girdhar
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 rep...@bugs.python.org http://bugs.python.org/issue2292

[issue2292] Missing *-unpacking generalizations

2015-03-12 Thread Neil Girdhar
Changes by Neil Girdhar mistersh...@gmail.com: Added file: http://bugs.python.org/file38429/starunpack37.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2292

[issue2292] Missing *-unpacking generalizations

2015-03-08 Thread Neil Girdhar
Changes by Neil Girdhar mistersh...@gmail.com: Added file: http://bugs.python.org/file38395/starunpack36.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2292

[issue22906] PEP 479: Change StopIteration handling inside generators

2015-03-05 Thread Neil Girdhar
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 rep

[issue2292] Missing *-unpacking generalizations

2015-03-05 Thread Neil Girdhar
Neil Girdhar added the comment: Removed dead code. Awaiting code review! :) -- Added file: http://bugs.python.org/file38341/starunpack35.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2292

[issue2292] Missing *-unpacking generalizations

2015-02-26 Thread Neil Girdhar
Neil Girdhar added the comment: New changelist for updated patch (before merging changes). -- Added file: http://bugs.python.org/file38252/starunpack33.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2292

[issue2292] Missing *-unpacking generalizations

2015-02-26 Thread Neil Girdhar
Neil Girdhar added the comment: Finished merge. -- Added file: http://bugs.python.org/file38253/starunpack34.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2292

[issue23595] Split the math module into _math (C) + math (py)

2015-03-05 Thread Neil Girdhar
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 rep...@bugs.python.org http://bugs.python.org/issue23595

[issue23316] Incorrect evaluation order of function arguments with *args

2015-01-25 Thread Neil Girdhar
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

[issue2292] Missing *-unpacking generalizations

2015-01-25 Thread Neil Girdhar
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 rep...@bugs.python.org http://bugs.python.org

[issue2292] Missing *-unpacking generalizations

2015-01-29 Thread Neil Girdhar
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

[issue2292] Missing *-unpacking generalizations

2015-01-30 Thread Neil Girdhar
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 rep...@bugs.python.org http

[issue2292] Missing *-unpacking generalizations

2015-01-30 Thread Neil Girdhar
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) * Extend

[issue2292] Missing *-unpacking generalizations

2015-01-30 Thread Neil Girdhar
Neil Girdhar added the comment: Fixed a bug and added a test. -- Added file: http://bugs.python.org/file37921/starunpack27.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2292

[issue2292] Missing *-unpacking generalizations

2015-04-28 Thread Neil Girdhar
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 rep

[issue2292] Missing *-unpacking generalizations

2015-04-28 Thread Neil Girdhar
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 comprehension

[issue24136] document PEP 448

2015-05-14 Thread Neil Girdhar
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: +neil.g Added file: http

[issue2292] Missing *-unpacking generalizations

2015-04-15 Thread Neil Girdhar
Changes by Neil Girdhar mistersh...@gmail.com: Added file: http://bugs.python.org/file39059/starunpack41.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2292

[issue2292] Missing *-unpacking generalizations

2015-04-07 Thread Neil Girdhar
Changes by Neil Girdhar mistersh...@gmail.com: Added file: http://bugs.python.org/file38856/starunpack40.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2292

[issue24136] document PEP 448

2015-05-29 Thread Neil Girdhar
Neil Girdhar added the comment: Simplified functools.partial documentation. -- Added file: http://bugs.python.org/file39561/wn2.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24136

[issue24136] document PEP 448

2015-05-29 Thread Neil Girdhar
Changes by Neil Girdhar mistersh...@gmail.com: Added file: http://bugs.python.org/file39562/wn2.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24136

[issue24624] Itertools documentation says iterator when iterable is intended

2015-07-13 Thread Neil Girdhar
Neil Girdhar added the comment: Ah, good point. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24624 ___ ___ Python-bugs-list mailing list

[issue24136] document PEP 448: unpacking generalization

2015-07-07 Thread Neil Girdhar
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 rep...@bugs.python.org http://bugs.python.org/issue24136

[issue24136] document PEP 448: unpacking generalization

2015-07-09 Thread Neil Girdhar
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

[issue24624] Itertools documentation says iterator when iterable is intended

2015-07-12 Thread Neil Girdhar
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 into a zero

[issue4356] Add "key" argument to "bisect" module functions

2016-02-29 Thread Neil Girdhar
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? -- nosy: +neil.g

[issue26020] set_display evaluation order doesn't match documented behaviour

2016-04-26 Thread Neil Girdhar
Neil Girdhar added the comment: Also, please add the following test: "{*{True, 1}}" Should be True. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.py

[issue26020] set_display evaluation order doesn't match documented behaviour

2016-04-26 Thread Neil Girdhar
Neil Girdhar added the comment: Please don't forget to fix BUILD_SET_UNPACK to match. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/i

[issue26020] set_display evaluation order doesn't match documented behaviour

2016-04-26 Thread Neil Girdhar
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 <rep...@bugs.python.org>

  1   2   >