Mailman 3 February 2014 - Python-ideas

with expression
by Yann Kaiser Feb. 23, 2014

Feb. 23, 2014

As an alternative to the recently-proposed "except expression", I suggested this in its thread. I was recommended to post this separately, as, while it is related, it is different enough from the original idea. The general idea is to extend the context manager protocol so that it can produce a return value in alternative to simply letting or denying an exception from propagating, and introduce an inline form of "with". The motivation behind is, in all honesty, that I find the suggested except-expressions from PEP 463 to be too verbose to inline, and that context managers have a much broader reach. The motivation from the aforementioned PEP(inline evaluation to a "default" expression upon catching an exception) also applies here. It could look a bit like this: contexted_expr with context_manager as c Once more, the rationale from PEP 463 also applies here, in that we can shift "easy defaulting" from being a potential concern for the callee to being always available to the caller through new syntax. Likewise, currently in-lining the use of a context manager can be done, but only through manually encapsulating what would be the context-ed code through lambdas or eval. A full example could be as such: class Default(object): """Context manager that returns a given default value when an exception is caught.""" def __init__(self, value, *exception_types): self.value = value self.exception_types = exception_types or BaseException def __enter__(self): pass def __exit__(self, typ, val, tb): if typ and issubclass(typ, self.exception_types): return True, self.value lst = [1, 2] # found is assigned 2 found = lst[1] with Default(0, IndexError) # not found is assigned 0 not_found = lst[2] with Default(0, IndexError) The different interpretation of __exit__'s return value is probably something that needs to be discussed. In this form, it is potentially backwards-incompatible, so a preferable alternative would be a different special method, perhaps: def __return__(self, typ, val, tb, ret): if typ is None: return False, ret * 3 elif isinstance(typ, IndexError): return True, 10 The alternatively-named special method would take priority over __exit__ and take over its augmented function: If no exception has occurred, typ, val, and tb are given None, as with the regular __exit__ incarnation, but ret, or whatever is the fourth positional parameter, is supplied with what "expr" evaluated to in "expr with cmgr". When an exception has occurred or propagated, typ, val and tb are set to the appropriate values(Since exceptions now keep their traceback as an attribute, maybe only supply the exception object?), and ret is given None. If the return value of this special method is None, the exception or return value is propagated as is. If it is a sequence, the first element is used like the return value of __exit__ would be, and the second element is used to (re-)place the return value of the whole with expression. When multiple context managers are being chained, the return value/exception is forwarded much like it is with twisted's Deferreds. In the use case of providing a default value, if the default value is the product of an expensive operation, an alternative context manager can be designed to compute the value only when needed, for instance: fa = factorials[n] with SetDefault(factorials, n, lambda: math.factorial(n)) Other examples using existing context managers: contents = f.read() with open('file') as f with open('file') as f: contents = f.read() d = Decimal(1) / Decimal(7) with Context(prec=5) with Context(prec=5): d = Decimal(1) / Decimal(7) I think that's all I can think of so far. Sorry as this might be a little too detailed to start with, so I will remind you there is no offense in rethinking any of what I posted here. -yk

7 14

is that expensive?
by Liam Marsh Feb. 23, 2014

Feb. 23, 2014

Hello everyone, is it possible to create(or tell me its name) a command to evaluate compute length of a command/procedure? (in number of: -processor operations(for 32 and 64 bit processors) -RAM read and write operations -hard disk write and read operations -eventual graphic operations ) this may be difficult, but it ables users to optimise their programs.

4 3

Function to return first(or last) true value from list
by Ryan Gonzalez Feb. 22, 2014

Feb. 22, 2014

It isn't uncommon to try and get either the first or the last True value from a list. In Python 2, you'd do this: next((x for x in mylist if x)) And, in Python 3, thanks to filter returning an iterator, you'd do this: next(filter(bool,mylist)) It still is pretty common. Common enough to make it aggravating to write a function to do that nearly every time. My idea is to add first and lastfunctions that do just that. Stuff that's open to lots of debate: - Names. They're not very creative; I know. - Builtin or itertools. I'm personally leaning towards the latter at the moment. Implementing it in itertools would be simple: def first(it): return next(filter(bool,it)) def last(it): return next(reversed(filter(bool,it))) -- Ryan If anybody ever asks me why I prefer C++ to C, my answer will be simple: "It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was nul-terminated."

11 28

Make MappingProxyType picklable
by Antony Lee Feb. 22, 2014

Feb. 22, 2014

Currently, mappingproxies are not picklable, which (among other things) lead to signature objects being non picklable. Could this be easily fixed, or is there a stronger reason for not allowing that pickling? If mappingproxies cannot be made picklable, perhaps signatures can implement __getnewargs__ to allow pickling? Antony

2 2

getitem() (was Re: [Python-Dev] PEP 463: Exception-catching expressions)
by Eric Snow Feb. 22, 2014

Feb. 22, 2014

(in response to https://mail.python.org/pipermail/python-dev/2014-February/132648.html) On Fri, Feb 21, 2014 at 9:25 PM, Yury Selivanov <yselivanov.ml(a)gmail.com> wrote: > On 2/21/2014, 10:42 PM, Chris Angelico wrote: >> That fixes it for the list. Square brackets notation works for any >> sequence. Are you proposing adding magic to the language so that any >> class that defines a __getitem__ automatically has a .get() with these >> semantics? Or, conversely, that defining __getitem__ requires that you >> also explicitly define get()? > > > No, I proposed to consider adding 'list.get()' and > 'collections.abc.Sequence.get()' (or a better name), > if catching IndexError is such a popular pattern. > > We can also fix stdlib. Authors of the python libraries/ > frameworks will likely follow. > > No magic in the language, no requirements on __getitem__, > obviously. We could also add a companion to getattr: getitem(). def getitem(seq, index, default=_NOT_SET): try: return seq[index] except IndexError: if default is _NOT_SET: raise return default Of course, one might expect getitem() to work for mappings too (or we'd have 2 distinct functions for mappings and sequences). Having getitem() work for both would not be too hard. Keep in mind that I still think that the PEP 463 syntax is worth adding more than any getitem() function. However, I think the getitem() route would be better than adding another method to sequences (including list). -eric

2 1

Raise exception if (not) true
by Ryan Gonzalez Feb. 21, 2014

Feb. 21, 2014

In Python, you'll constantly see code like this: ```python if x != y: raise ValueError('x != y!!') ``` or: ```python if not isinstance(x,SomeType): raise TypeError('x is not SomeType!') ``` Assertion help a bit: ```python assert isinstance(x,SomeType), 'x is not SomeType!' ``` Notice I said "a bit". If optimizations are on, they're disabled. In addition, the only type of error thrown is an AssertionError. I propose a `raise_if` function. If the given condition is True, an exception is raised. So, the above examples would be shortened to: ```python raise_if(x!=y, ValueError, 'x != y!!') raise_if(not isinstance(x,SomeType),TypeError, 'x is not SomeType!') ``` There could also be a raise_if_not function that does the opposite: ```python raise_if_not(isinstance(x,SomeType), TypeError, 'x is not SomeType!') ``` Thoughts? -- Ryan If anybody ever asks me why I prefer C++ to C, my answer will be simple: "It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was nul-terminated."

7 15

decorator syntax limitation
by Franck Michea Feb. 21, 2014

Feb. 21, 2014

Hi there, Today I hit a limitation of decorator syntax, and I was wondering if maybe this limitation could be removed, or if they could allow more. The grammar for decorators is[1]: decorator: '@' dotted_name [ '(' [arglist] ')' ] NEWLINE But `dotted_name` doesn't allow to write things like the comment put in the snippet attached, or this smaller snippet: @M(b).decorator() def wrapped_func(): pass Although it looks possible to me to add this syntax, I was wondering if it had been discussed previously, and if I could see that discussion. All discussions I found were a lot older, arround the time decorators were designed and the syntax was being choosen. I also read PEP306 and PEP318. This is not a blocking issue since you can do with a temporary variable, but I was wondering what were your thoughts on this. Thank you very much, [1]: http://docs.python.org/3.3/reference/grammar.html ===== Snippet ========== class foo_decorator: def __init__(self): pass def __call__(self, func): return func class Foo: def test(self): return foo_decorator() class Bar: def __init__(self): self._foo = Foo() def M(val): return val._foo b = Bar() # SyntaxError: @M(b).test() m = M(b) @m.test() def func(): print('Hello World!') func() ======================== -- Franck Michea - EPITA/LSE/GISTRE 2014

6 6

while conditional in list comprehension ??
by Wolfgang Maier Feb. 21, 2014

Feb. 21, 2014

Dear all, I guess this is so obvious that someone must have suggested it before: in list comprehensions you can currently exclude items based on the if conditional, e.g.: [n for n in range(1,1000) if n % 4 == 0] Why not extend this filtering by allowing a while statement in addition to if, as in: [n for n in range(1,1000) while n < 400] Trivial effect, I agree, in this example since you could achieve the same by using range(1,400), but I hope you get the point. This intuitively understandable extension would provide a big speed-up for sorted lists where processing all the input is unnecessary. Consider this: some_names=["Adam", "Andrew", "Arthur", "Bob", "Caroline","Lancelot"] # a sorted list of names [n for n in some_names if n.startswith("A")] # certainly gives a list of all names starting with A, but . [n for n in some_names while n.startswith("A")] # would have saved two comparisons Best, Wolfgang

19 70

Create Python 2.8 as a transition step to Python 3.x
by Neil Schemenauer Feb. 21, 2014

Feb. 21, 2014

The transition to Python 3 is happening but there is still a massive amount of code that needs to be ported. One of the most disruptive changes in Python 3 is the strict separation of bytes from unicode strings. Most of the other incompatible changes can be handled by 2to3. Here is a far out idea to make transition smoother. Release version 2.8 of Python with nearly all Python 3.x incompatible changes except for the bytes/unicode changes. This could include: - print as function - default string literal as unicode - return view objects for dict.keys(), etc - rename modules in standard library - rename long to int - rename .next() to __next__() - accept only new 'raise' syntax - remove backticks for repr - rename unicode to str - removal of 'apply', 'buffer', 'callable', 'execfile' - exec as function - rename os.getcwdu() to os.getcwd() - remove dict.has_key - move intern to sys.intern() - rename xrange to range - remove xreadlines New features of Python 3.x could be backported if easy since they could be useful to entice developers to move from 2.7 to 2.8. Problems with this idea: - it would be a huge amount of work. There are thousands of commits to Python 3.x since it was branched. Most of them are not related to the above features but back porting them would still be a huge effort. I tried backport 'print' as a function just to get an idea of the work. - if people install this new version of Python as the default, old scripts and programs will break. I believe this breakage was the movation for making Python 3 an all-at-once jump. I'm not sure how to handle this, maybe this version could be used only by developers during their Python 3 porting efforts. Alternatively, only install it as 'python2.8', never 'python' or 'python2'. An alternative approach to producing Python 2.8 would be to start with the Python 3.x latest branch. Modify bytesobject and unicodeobject to have as close to Python 2 behavior as practical. A-journey-of-a-thousand-miles-begins-ly y'rs Neil

20 38

except expression
by Ram Rachum Feb. 21, 2014

Feb. 21, 2014

Hi, Here's an idea that would help shortening code. Allow a ternary expression based on except, like so: first_entry = entries[0] except IndexError else None item = my_queue.get() except queue.Empty else None response_text = request('http://whatever.com').text except HttpError else "Can't access data" Aside from the fact that this would be a big grammar addition, a big problem here is the usage of the `else` keyword, that when used with except usually means "what would happen if there wasn't an exception" and here means the opposite. But I couldn't think of a nicer syntax. I realize that this is a big change and that most people would be opposed to this... But I guess I just wanted to share my idea :) Ram.

35 408