Mailman 3 May 2016 - Python-ideas

Sleep and timedelta Was: Boolean parameters guidelines
by Alexander Belopolsky 13 May '16

13 May '16

On Wed, May 11, 2016 at 4:36 PM, Ian Kelly <ian.g.kelly(a)gmail.com> wrote: > Still best to be explicit: > > >>> sleep(timedelta(100)) > > It would be awesome if that actually worked. > FWIW, I would not mind seeing sleep() as a timedelta instance method: >>> timedelta(seconds=42).sleep()

3 2

Adding Type[C] to PEP 484
by Guido van Rossum 13 May '16

13 May '16

I've got another proposed update to PEP 484 ready. There was previously some discussion on python-ideas (Bcc'ed for closure) and quite a bit on the typing issue tracker: https://github.com/python/typing/issues/107 I've worked all that into a patch for PEP 484: https://github.com/python/typing/pull/218 Once we're okay with that I will work on getting the implementation ready in time for Python 3.5.2. Here's the added text: Meta-types ---------- A meta-type can be used to indicate a value that is itself a class object that is a subclass of a given class. It is spelled as ``Type[C]`` where ``C`` is a class. To clarify: while ``C`` (when used as an annotation) refers to instances of class ``C``, ``Type[C]`` refers to *subclasses* of ``C``. (This is a similar distinction as between ``object`` and ``type``.) For example, suppose we have the following classes:: class User: ... # Abstract base for User classes class BasicUser(User): ... class ProUser(User): ... class TeamUser(User): ... And suppose we have a function that creates an instance of one of these classes if you pass it a class object:: def new_user(user_class): user = user_class() # (Here we could write the user object to a database) return user Without ``Type[]`` the best we could do to annotate ``new_user()`` would be:: def new_user(user_class: type) -> User: ... However using ``Type[]`` and a type variable with an upper bound we can do much better:: U = TypeVar('U', bound=User) def new_user(user_class: Type[U]) -> U: ... Now when we call ``new_user()`` with a specific subclass of ``User`` a type checker will infer the correct type of the result:: joe = new_user(BasicUser) # Inferred type is BasicUser At runtime the value corresponding to ``Type[C]`` must be an actual class object that's a subtype of ``C``, not a special form. IOW, in the above example calling e.g. ``new_user(Union[BasicUser, ProUser])`` is not allowed. There are some concerns with this feature: for example when ``new_user()`` calls ``user_class()`` this implies that all subclasses of ``User`` must support this in their constructor signature. However this is not unique to ``Type[]``: class methods have similar concerns. A type checker ought to flag violations of such assumptions, but by default constructor calls that match the constructor signature in the indicated base class (``User`` in the example above) should be allowed. A program containing a complex or extensible class hierarchy might also handle this by using a factory class method. Plain ``Type`` without brackets is equivalent to using ``type`` (the root of Python's metaclass hierarchy). This equivalence also motivates the name, ``Type``, as opposed to alternatives like ``Class`` or ``SubType``, which were proposed while this feature was under discussion; this is similar to the relationship between e.g. ``List`` and ``list``. -- --Guido van Rossum (python.org/~guido)

1 0

Adding Type[C] support to PEP 484 and typing.py
by Guido van Rossum 13 May '16

13 May '16

There's one new feature I'd like to add to PEP 484 and the typing.py module that will go out with Python 3.5.2. There's a long discssion in https://github.com/python/typing/issues/107, but I think I can explain the proposal very quickly. There's currently no good way to talk about class objects. If you have a function argument that's a class (as opposed to an instance) the only annotation you can give it is `type`. But I've encountered this pattern quite frequently, and what people invariably want to say is "it's a subclass of this here class C." Example: class User: ... class TeamUser(User): ... class ProUser(User): ... def new_user(user_class: Type[User]) -> User: ... The proposal is to let you spell that explicitly by setting the type or such an argument to `Type[C]`. The type checker will then understand that if you call it, the result is an instance of C. It will also know about all the class methods defined on C. There are some subtleties, e.g. in the above example we would actually like to know that the return type varies with the argument type: joe = new_user(ProUser) # Really, joe is a ProUser, not just a User This can be done using a type variable, e.g. U = TypeVar('U', bound=User) def new_user(user_class: Type[U]) -> U: ... joe = new_user(ProUser) The key part I want to settle quickly is the notation: I need to add a special generic `class Type` to typing.py so that we can start implementing this in mypy. Any objections? Or should I just go ahead and add the text to PEP 484 and post the diff to python-dev? -- --Guido van Rossum (python.org/~guido)

8 14

Fwd: Block-Scoped Exception Handlers
by INADA Naoki 07 May '16

07 May '16

> ____def process_todo(todo):________pre_process()________for t in todo:____________except Exception, e:________________break____________process(t)________post_process() > > > As an alternative to > ____def process_todo(todo):________pre_process()________for t in todo:____________try________________process(t)____________except Exception, e:________________break________post_process() > > I don't feel former is quite readable than later. Of course, a couple `try` nested statements make the indentation worse. > For example, we wish to ignore problems in dealing with todo items, like > above, but the todo items are complicated; each is a dict() of details. > Failure to deal with one of the details is ignored, but the rest of the > details are still attempted: > > def process_todo(todo): > ____pre_process() > ____for t in todo: > ________except Exception, e: > ____________break > ________for u, v in t.items(): > ____________except Exception, e: > ________________continue > ____________process() > ____post_process() > > Which is better than what I do now: > > def process_todo(todo): > ____pre_process() > ____for t in todo: > ________try: > ____________for u, v in t.items(): > ________________try: > ____________________process() > ________________except Exception, e: > ____________________continue > ________except Exception, e: > ____________break > ____post_process() > > > While later is more nested, it seems straightforward. Additionally, try-catch pair should have minimum try block unlike try-finally pair. I am afraid of proposed syntax sugar misleads people to expand try block. At a high level: The `try/except/finally` is powerful structure. > Realizing that the `try/finally` pair is very common leads to the creation > of `with`. I am proposing the same logic for `try/catch` pair: They are > commonly paired together and should have an optimized syntax. > > try-catch pair shouldn't used so many like try-finally pairs. When function call is very nested, only function near top level should catch Exceptions. Most of middle~bottom level functions use only finally (or with statement, off course). If many functions have catch clause, it's a very bad code smell. C# and Java have syntax sugar only for try-finally pair too. (using statement in C# and try with resource in Java). -- INADA Naoki <songofacandy(a)gmail.com>

3 3

Re: [Python-ideas] Object grabbing
by Joshua Morton 07 May '16

07 May '16

The latter, the former isn't currently syntax (as in `with [a, b, c]"` will throw an error). This was, however, mainly if we were using a variant of the with syntax, since having But take the following example: def func(ctx): with ns: # namespace with ctx: # only known at runtime .attr You can't have that be a compile time error. Which actually makes the specific syntax of a bare `with` a strong -1 now, since mixing it with normal context managers is incredibly ambiguous. This would either need to be `in` or `given` as mentioned elsewhere, or something like with `Magic_Namespace_Object(ns):` --Josh On Mon, May 2, 2016 at 7:26 PM Erik <python(a)lucidity.plus.com> wrote: > On 02/05/16 23:28, Joshua Morton wrote: > > > It is not reasonable to expect an error to be generated at runtime: > > > because each and every object would have to be queried as to whether > > > they have the attribute to know if there is ambiguity on each and > every > > > reference to an attribute. > > > > It absolutely is: > > It almost certainly is not ;) > > > if you're using an "inferred" syntax like > > > > in object: > > .value > > > > but there are multiple such objects to look at, Python immediately > > throws an error, > > It is not clear what you mean by "multiple such objects". Do you mean > that 'object' can be some sort of sequence, or do you mean that the > syntax used for multiple objects is "in object0, object1:" or similar? > > If the latter, then given the choice between the two, I would agree with > some sort of compile time error over a runtime exception. Why wait until > runtime? > > If the former (which might mean a runtime error is appropriate), then > you need to explain what you are suggesting in a lot more detail. > > Regards, E. >

12 25

dictionary constructor should not allow duplicate keys
by Luigi Semenzato 06 May '16

06 May '16

Hello and sorry if this is an old and over-discussed topic. I could not find such discussions here. This was discussed and rejected at https://bugs.python.org/issue16385, but I am not convinced that the discussion presented all arguments properly. I tried reopening the bug at http://bugs.python.org/issue26910, but was told I should discuss it here instead. The original problem description: lives_in = { 'lion': ['Africa', 'America'], 'parrot': ['Europe'], #... 100+ more rows here 'lion': ['Europe'], #... 100+ more rows here } The above constructor overwrites the first 'lion' entry silently, often causing unexpected behavior. These are the arguments presented in favor of the rejection, followed by my rebuttals. 1. "An error is out of the question for compatibility reasons". No real rebuttal here, except I wonder if exceptions are ever made and under what circumstances. I should point out that a warning may also create incompatibilities. 2. "There are ways to rewrite this as a loop on a list". Yes of course, but the entire point of the dictionary literal is to offer a concise and convenient notation for entering a dictionary as program text. 3. "Being able to re-write keys is fundamental to Python dicts and why they can be used for Python's mutable namespaces". This is fine but it applies to the data structure, not the literal constructor. 4. "A code generator could depend on being able to write duplicate keys without having to go back and erase previous output". Yes, but it seems wrong to facilitate automated code generation at the expense of human code writing. For hand-written code, I claim that in most (all?) cases it would be preferable to have the compiler detect key duplications. It is easier for an automated code generator to check for duplications than it is for a human. 5. "There is already pylint". True, but it forces an additional step. For context, someone ran into this problem in my team at Google (we fixed it using pylint). I haven't seen any valid reason (in the bug or elsewhere) in favor of these constructor semantics. From the discussions I have seen, it seems just an oversight in the implementation/specification of dictionary literals. I'd be happy to hear stronger reasoning in favor of the status quo. (additional search keywords: dict constructor, dict literal)

21 81

Re: [Python-ideas] Block-Scoped Exception Handlers
by Robert van Geel 04 May '16

04 May '16

It looks frankly a bit like an "on error goto errorhandler" statement but with a few drawbacks to that. How can you indicate the 'exception handled block' should end, when there's no indentation level involved? It would force the exception block to service all code until the end of that indentation level but what happens on within the indentation level is defined by other more functional criteria. The proposed construct could not replace the normal try/catch syntax because of that, but it can also not mix with the normal syntax well because it's too similar to it and hence confusing. The gain of the proposed construct seems to be to save 1 indentation level. Even when this would be worth the cost it would be more logical to still put the except block at the end of the functional block. So instead of the proposed: def process_todo(todo): except Exception, e: raise OverallTodoError("Not expected") from e with Timer("todo processing"): # pre-processing for t in todo: except Exception, e: raise TodoError("oh dear!") from e # do error p the below is more logical, since the main code remains the focus and the exception the afterthought: def process_todo(todo): with Timer("todo processing"): # pre-processing for t in todo: except Exception, e: raise TodoError("oh dear!") from e # do error p except Exception, e: raise OverallTodoError("Not expected") from e But this all leaves something implicit rather then implicit: the start (or in the proposal: the end) of the exception block. Robert > Message: 3 > Date: Wed, 4 May 2016 15:58:58 -0400 > From: Kyle Lahnakoski <klahnakoski(a)mozilla.com> > To: python-ideas(a)python.org > Subject: [Python-ideas] Block-Scoped Exception Handlers > Message-ID: <00d21501-60fd-d756-c8a6-906a8b235221(a)mozilla.com> > Content-Type: text/plain; charset=windows-1252 > > > Please excuse my nomenclature. I hope the community can correct the > synonyms that clarify my proposal. > > Problem > ------- > > I program defensively, and surround many of my code blocks with try > blocks to catch expected and unexpected errors. Those unexpected > errors seem to dominate in my code; I never really know how many ways my > SQL library can fail, nor am I really sure that a particular key is in a > `dict()`. Most of the time I can do nothing about those unexpected > errors; I simply chain them, with some extra description about what the > code block was attempting to do. > > I am using 2.7, so I have made my own convention for chaining > exceptions. 3.x chains more elegantly: > > for t in todo: > try: > # do error prone stuff > except Exception, e: > raise ToDoError("oh dear!") from e > > The ?error prone stuff? can itself have more try blocks to catch known > failure modes, maybe deal with them. Add some `with` blocks and a > conditional, and the nesting gets ugly: > > def process_todo(todo): > try: > with Timer("todo processing"): > # pre-processing > for t in todo: > try: > # do error prone stuff > except Exception, e: > raise TodoError("oh dear!") from e > # post-processing > except Exception, e: > raise OverallTodoError("Not expected") from e > > Not only is my code dominated by exception handling, the meaningful code > is deeply nested. > > > Solution > -------- > > I would like Python to have a bare `except` statement, which applies > from that line, to the end of enclosing block (or next `except` > statement). Here is the same example using the new syntax: > > def process_todo(todo): > except Exception, e: > raise OverallTodoError("Not expected") from e > > with Timer("todo processing"): > # pre-processing > for t in todo: > except Exception, e: > raise TodoError("oh dear!") from e > > # do error prone stuff > # post-processing > > Larger code blocks do a better job of portraying he visual impact of the > reduced indentation. I would admit that some readability is lost > because the error handling code precedes the happy path, but I believe > the eye will overlook this with little practice. > > Multiple `except` statements are allowed. They apply as if they were > used in a `try` statement; matched in the order declared: > > def process_todo(todo): > pre_processing() # has no exception handling > > except SQLException, e: # effective until end of method > raise Exception("Not expected") from e > except Exception, e: > raise OverallTodoError("Oh dear!") from e > > processing() > > A code block can have more than one `except` statement: > > def process_todo(todo): > pre_processing() # no exception handling > > except SQLException, e: # covers lines from here to beginning > of next except statement > raise Exception("Not expected") from e > except Exception, e: # catches other exception types > raise Exception("Oh dear!") from e > > processing() # Exceptions caught > > except SQLException, e: # covers a lines to end of method > raise Exception("Happens, sometimes") from e > > post_processing() # SQLException caught, but not Exception > > In these cases, a whole new block is effectively defined. Here is the > same in legit Python: > > def process_todo(todo): > pre_processing() # no exception handling > > try: > processing() # Exceptions caught > except SQLException, e: # covers all lines from here to > beginning of next except statement > raise Exception("Not expected") from e > except Exception, e: # catches other exception types > raise Exception("Oh dear!") from e > > try: > post_processing() # SQLException caught, but not Exception > except SQLException, e: # covers a lines to end of method > raise Exception("Happens, sometimes") from e > > Other Thoughts > -------------- > > I only propose this for replacing `try` blocks that have no `else` or > `finally` clause. I am not limiting my proposal to exception chaining; > Anything allowed in `except` clause would be allowed. > > I could propose adding `except` clauses to each of the major statement > types (def, for, if, with, etc?). which would make the first example > look like: > > def process_todo(todo): > with Timer("todo processing"): > # pre-processing > for t in todo: > # do error prone stuff > except Exception, e: > raise TodoError("oh dear!") from e > > # post-processing > except Exception, e: > raise OverallTodoError("Not expected") from e > > But, I am suspicious this is more complicated than it looks to > implement, and the `except` statement does seem visually detached from > the block it applies to. > > > Thank you for your consideration! > > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > Python-ideas mailing list > Python-ideas(a)python.org > https://mail.python.org/mailman/listinfo/python-ideas > > > ------------------------------ > > End of Python-ideas Digest, Vol 114, Issue 35 > *********************************************

2 2

Re: [Python-ideas] dictionary constructor should not allow duplicate keys
by Franklin? Lee 04 May '16

04 May '16

On May 4, 2016 2:47 AM, "Pavol Lisy" <pavol.lisy(a)gmail.com> wrote: > > 2016-05-04 6:03 GMT+02:00, Nick Coghlan <ncoghlan(a)gmail.com>: > > > I was curious as to whether or not it was technically feasible to > > implement this "duplicate keys" check solely for dict displays in > > CPython without impacting other dict use cases, and it turns out it > > should be. > > [...] > > > 1. Report a DeprecationWarning in 3.6 > > 2. Report a [RuntimeError? ValueError?] in 3.7+ > > But what about SyntaxError instead of RuntimeError? Could it be easily > done too? Is it really a SyntaxError? The compiler knows what the source code means, but it assumes that the meaning is not what you intended.

1 0

Specify an alternative exception for "assert"
by Giampaolo Rodola' 03 May '16

03 May '16

assert statement gives the possibility to display the text which goes along with the AssertionError exception. Most of the times though, what would be more appropriate is to raise a different exception (e.g. ValueError). My proposal is to be able to specify an exception as a replacement for AssertionError as in: >>> assert callable(fun), ValueError("object is not a callable") ValueError: object is not a callable Specifically, this would be useful at the top of a function or method, where argument types or values are usually checked: def retry(times=3, timeout=0.1, callback=None): assert times >= 1, ValueError("times must be >= 1") assert isinstance(timeout, (int, float)), ValueError("invalid timeout") assert callable(callback), ValueError("callback is not a callable") ...as opposed to: def retry(times=3, timeout=0.1, callback=None): if not times >= 1: raise ValueError("times must be >= 1") if not isinstance(timeout, (int, float)): raise ValueError("invalid timeout") if not callable(callback): raise ValueError("callback is not a callable") Other than saving 1 line for each type/value check, this has the advantage that the assertion logic (e.g. "times >= 1") is shown in the traceback message itself, because it's on the same line, enriching the context and giving more information in case of error. Thoughts? -- Giampaolo - http://grodola.blogspot.com

7 15

Re: [Python-ideas] Object grabbing
by Robert van Geel 03 May '16

03 May '16

summarizing: 1- the with statement should not be used for this 2- I overrated the code optimization of this change, optimization is not sufficiently large and nothing that can't be done without this syntax 3- picking a keyword would be non-trivial, 'using' has drawbacks, 'in' might be a candidate (frankly I like it) 4- the benefits of .dotted shorthand syntax are disputed, some think it's pythonic and readable, others don't think it is 5 - Pascal style has been discussed in the past and has its own faq explaining rejection. So anyway a dot would be needed, this would also take away possible ambiguity between locals and object properties About 4, the argument that full variable writing is more explicit, hence Pythonic: I think clinging to 20 same-indentation level references to 'obj.' is explicit to the point of sillyness. We also dont use locals.obj.x because the localness of a variable is also present without explicity so a bit of pragmatism could have a voice. People who think .dotted syntax is less readable could still use the familiar syntax. That would lead to two ways to do the same thing but on the same level as the type of decision as to whether to use a lambda or a full function. In the end implementation of this proposal would offer syntactical sugar without added functionality, especially given point 2 above. That would make the feature as desirable as the number of happy eyebrows when looking at code like this: in disussion: .arguments = [a, b, c] .argue() .summarize() x = .eastheticfactor .decision = .calculate(x) On 5/3/2016 4:50 AM, python-ideas-request(a)python.org wrote: > Send Python-ideas mailing list submissions to > python-ideas(a)python.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mail.python.org/mailman/listinfo/python-ideas > or, via email, send a message with subject or body 'help' to > python-ideas-request(a)python.org > > You can reach the person managing the list at > python-ideas-owner(a)python.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Python-ideas digest..." > > > Today's Topics: > > 1. Re: Object grabbing (Guido van Rossum) > 2. Re: Object grabbing (Steven D'Aprano) > 3. Re: Object grabbing (Jonathan Goble) > 4. Re: Object grabbing (Bruce Leban) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 2 May 2016 18:47:00 -0700 > From: Guido van Rossum <guido(a)python.org> > To: Joshua Morton <joshua.morton13(a)gmail.com> > Cc: "python-ideas(a)python.org" <python-ideas(a)python.org> > Subject: Re: [Python-ideas] Object grabbing > Message-ID: > <CAP7+vJJ+P5N3ZLdRgZ3DEBkAGju9qHLjfMs3WmoXfQfpHkrpgQ(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > On Mon, May 2, 2016 at 6:43 PM, Joshua Morton <joshua.morton13(a)gmail.com> > wrote: > >> Which actually makes the specific syntax of a bare `with` a strong -1 now, >> since mixing it with normal context managers is incredibly ambiguous. >> > I'm glad you eventually reached this conclusion. >

3 2