Mailman 3 June 2013 - Python-ideas

Re: [Python-ideas] "Iteration stopping" syntax [Was: Is this PEP-able? for X in ListY while conditionZ:]
by Shane Green 30 Jun '13

30 Jun '13

Yes, but it only works for generator expressions and not comprehensions. My opinion of that workaround is that it’s also a step backward in terms of readability. I suspect if i < 50 else stop() would probably also work, since it throws an exception. That’s better, IMHO. On Jun 28, 2013, at 6:38 PM, Andrew Carter <acarter(a)g.hmc.edu> wrote: > Digging through the archives (with a quick google search) http://mail.python.org/pipermail/python-ideas/2013-January/019051.html, if you really want an expression it seems you can just do > > def stop(): > raise StopIteration > list(i for i in range(100) if i < 50 or stop()) > > it seems to me that this would provide syntax that doesn't require lambdas. > > > > > > > On Fri, Jun 28, 2013 at 4:50 PM, Alexander Belopolsky <alexander.belopolsky(a)gmail.com> wrote: > > > > On Fri, Jun 28, 2013 at 7:38 PM, Shane Green <shane(a)umbrellacode.com> wrote: > .. > [x until condition for x in l ...] or > [x for x in l until condition] > > Just to throw in one more variation: > > [expr for item in iterable break if condition] > > (inversion of "if" and "break"reinforces the idea that we are dealing with an expression rather than a statement - compare with "a if cond else b") > > _______________________________________________ > Python-ideas mailing list > Python-ideas(a)python.org > http://mail.python.org/mailman/listinfo/python-ideas

8 21

Short form for keyword arguments and dicts
by Anders Hovmöller 29 Jun '13

29 Jun '13

Keyword arguments are great for increasing readability and making code more robust but in my opinion they are underused compared to the gains they can provide. You often end up with code like: foo(bar=bar, baz=baz, foobaz=foobaz) which is less readable than the ordered argument version when the names of the variables and the keywords match. ( Here's another guy pointing out the same thing: http://stackoverflow.com/questions/7041752/any-reason-not-to-always-use-key… ) I have a suggestion that I believe can enable more usage of keyword arguments while still retaining almost all the brevity of ordered arguments: if the variable name to the right of the equal sign equals the keyword argument ("foo=foo") make it optional to just specify the name once ("=foo"). For completeness I suggest also make the same change for dictionaries: {'foo': foo} -> {:foo}. This change would turn the following code: a = 1 b = 2 c = 3 d = {'a':a, 'b':b, 'c':c} foo(a=a, b=b, c=c) into: a = 1 b = 2 c = 3 d = {:a, :b, :c} foo(=a, =b, =c) This should be compatible with existing code bases since the new forms are syntax errors in current python. What do you think? / Anders Hovmöller

19 96

PEP 315: do-while
by Łukasz Langa 29 Jun '13

29 Jun '13

The PEP is deferred because it seems that while True: <code> if condition: break is good enough. I agree. We should reject the PEP and summarise the status. Alternatively, the only way I think we can improve on the syntax above is something like this: do: <code> if condition: break or without a new keyword: while: <code> if condition: break The empty-predicate variant would let Python check whether there's actually a break in the body of the loop. -- Best regards, Łukasz Langa WWW: http://lukasz.langa.pl/ Twitter: @llanga IRC: ambv on #python-dev

12 27

Re: [Python-ideas] Is this PEP-able? for X in ListY while conditionZ:
by jimjhb＠aol.com 28 Jun '13

28 Jun '13

You shouldn't have to invoke takewhile and a lambda just to break out of for loop. >http://docs.python.org/2/library/itertools.html#itertools.takewhile > >for item in takewhile(lambda x: x < 5, range(10)): > pass >> >> [People who avoid the 'break' by functionalizing an inner portion of the >> loop are just kidding themselves and making their own code worse, IMO. >> Takewhile from itertools also works, but that's clumsy and wordy as well.] >>

18 42

Re: [Python-ideas] Is this PEP-able? for X in ListY while conditionZ:
by jimjhb＠aol.com 25 Jun '13

25 Jun '13

Syntax: for X in ListY while conditionZ: The 'for' loop would proceed as long as conditionZ remains true. The motivation is to be able to make use of all the great aspects of the python 'for' (no indexing or explicit end condition check, etc.) and at the same time avoiding a 'break' from the 'for'. (NOTE: Many people are being taught to avoid 'break' and 'continue' at all costs, so they instead convert the clean 'for' into a less-clean 'while'. Or they just let the 'for' run out. You can argue against this teaching practice (at least for Python) but that doesn't mean it's not prevalent and prevailing.) [People who avoid the 'break' by functionalizing an inner portion of the loop are just kidding themselves and making their own code worse, IMO. Takewhile from itertools also works, but that's clumsy and wordy as well.] I'm not super familiar with CPython, but I'm pretty sure I could get this up and working without too much effort. Please note that I don't feel the answer to this is 'just use break'. Programmers are now being taught to avoid 'break' and 'continue' as if they were 'goto's. The result (now) is that people are avoiding the 'for' (with its GREAT properties) because they can't break out of it. Comments and Questions welcome. Thanks.

9 19

interactive sqlite3 module
by ZeD 25 Jun '13

25 Jun '13

Hi. some python modules contains a "console" usage (for example the module timeit). It would be useful (for the times when you have python installed but not a sqlite executable... think windows...) to add a minimal interactive sqlite interpreter... a (really) basic implementation is something like the source below... teoretically the idea is to to $ python -msqlite3 'my_data.db' or $ python -msqlite3 ':memory:' and have a simple sqlite interpreter do you think it whould be useful? ------------------------- #!/usr/bin/env python # ATM I'm on python2... from __future__ import print_function try: input = raw_input except: pass # ideally this file is part of sqlite from sqlite3 import * def main(): from sys import argv if len(argv) < 2: raise SystemExit("usage: %s DATABASE" % (argv[0], )) with connect(argv[1]) as conn: while True: command = input("> ") if command == '.exit': break try: c = conn.cursor() for row in c.execute(command): print(row) conn.commit() except Exception as e: print(e) if __name__ == '__main__': main() -- Vito 'ZeD' De Tullio

3 2

Catching of multiple exceptions without halting execution
by Samuel Littley 24 Jun '13

24 Jun '13

I find I often have to run several tests on data input, making a list of which tests succeed, which fail, and somehow determine where to go after running all the tests. Obviously, the standard way of showing that a test as failed is to raise an exception, caught by try/except/finally, however this would only allow one test to be flagged as failing, requiring multiple runs to correct every fault that may exist. I propose an alternative to try/except, as follows: validate: // Code to run tests, raising exceptions if tests fail accept: // Code to run if all tests pass (i.e. no exceptions) reject es: // Code to handle each failed test except: // Code to handle non-test related exceptions finally: // Code to be always executed The difference to a normal try/except is a different type of exception, which, rather than halting execution, is added to the list `es`, which the reject block could then loop through to display error messages, require re-entry, etc. Standard exceptions could be raised and caught by the except block. Alternatively, the except block could not be a part of this, and instead all exceptions are caught in the reject block, which could then raise exceptions itself to be caught by a try/except/finally around the validate/accept/reject/finally The use case I thought of is validating data entry (from web forms for example), where each exception creates an error message displayed on the form, however I'm pretty sure there would be other uses for this. Samuel Littley

6 6

Fwd: Iterable unpacking within containers
by SpaghettiToastBook . 24 Jun '13

24 Jun '13

I think it would be very convenient if the * syntax was extended to allow unpacking iterables inside containers. For example: >>> x = range(1, 4) >>> y = [-2, *(-1, 0), *x, 4, 5] >>> print(y) [-2, -1, 0, 1, 2, 3, 4, 5] This would be especially convenient if two lists needed to be combined, but one list's contents needed to be the the middle of the other one. I don't think any code would break because the suggested syntax currently raises a SyntaxError.

5 4

Get the class that *defines* a method
by anatoly techtonik 24 Jun '13

24 Jun '13

Currently, the only way to get the name of the class that *defines* a method is to get chain of parent classes from inspect.getmro() and look into every class's dict until a given name is found. Knowing that dict contains not only methods, and knowing that it can be modified at run-time, this doesn't seem too reliable for me (unless Python itself does the same). At first I wanted to propose an enhancement to runtime skeleton of Python, which is 2D lookup tree for objects and containers that define them. But then I realized that it will may not reflect the model I need. For example, classes need to provide their parent classes, but in my model classes need to provide module name (or function name, or method name) in which they are defined. And while writing this I realized that *definition* scope may be different from *run-time* scope, and Python doesn't make it clear: >>> def lll(): ... class A(object): ... pass ... a=A() ... return a ... >>> lll() <__main__.A object at 0x948252c> >>> __main__.A Traceback (most recent call last): File "<stdin>", line 1, in <module> NameError: name '__main__' is not defined The A object is said to be in __main__ namespace, but it seems to be a run-time namespace local to function and it seems like Python loses this information. There is no information about the function that defined the class (owner, parent or .?.), and hence no info about container of the function, which makes it hard to assume the scope of variables for this class at run-time. So, the above is a generalization of a simple idea - store the "structure reference" of the class that *defines* a method inside this method. "structure reference" here is the address in the nested scopes formed by Python definitions. The specific action items for you here are: 1. is that stuff will be useful (for me it brings some much needed consistency into the chaos of run-time Python object space) 2. what is the best way to define/cache the reference to the class defining the method? 3. what is the best way to define/cache the reference to the scope defining the method? 4. what is the best way to organize storing of this static scope structure information at run-time? See method.im_class note at http://docs.python.org/2/library/inspect.html#types-and-members "Namespaces are one honking great idea -- let's do more of those!" (c) import this -- anatoly t.

4 3

Python execution progress counter
by anatoly techtonik 23 Jun '13

23 Jun '13

In x86 assembly there is a concept of instruction pointer (IP) that indicates where a computer is in its program sequence (c) http://en.wikipedia.org/wiki/Program_counter I wonder if it is possible to implement a similar thing in Python? Not the instruction pointer, which points to the linear memory address space (and therefore is a 1D structure), but a 2D Execution Progress Counter, which counts position in program sequence for every stack level? -- anatoly t.

3 2