Mailman 3 May 2016 - Python-ideas

Sleep and timedelta Was: Boolean parameters guidelines
by Alexander Belopolsky May 13, 2016

May 13, 2016

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 May 13, 2016

May 13, 2016

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 … [View More]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) [View Less]

1 0

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

May 13, 2016

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 … [View More]

8 14

Fwd: Block-Scoped Exception Handlers
by INADA Naoki May 7, 2016

May 7, 2016

> ____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 … [View More]

3 3

Re: [Python-ideas] Object grabbing
by Joshua Morton May 7, 2016

May 7, 2016

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 … [View More]

12 25

dictionary constructor should not allow duplicate keys
by Luigi Semenzato May 6, 2016

May 6, 2016

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+ … [View More]

21 81

Re: [Python-ideas] Block-Scoped Exception Handlers
by Robert van Geel May 4, 2016

May 4, 2016

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 … [View More]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 > ********************************************* [View Less]

2 2

Re: [Python-ideas] dictionary constructor should not allow duplicate keys
by Franklin? Lee May 4, 2016

May 4, 2016

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 … [View More]

1 0

Specify an alternative exception for "assert"
by Giampaolo Rodola' May 3, 2016

May 3, 2016

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, … [View More]

7 15

Re: [Python-ideas] Object grabbing
by Robert van Geel May 3, 2016

May 3, 2016

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 … [View More]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. > [View Less]

3 2