[Python-Dev] Please reject or postpone PEP 526 (original) (raw)
Nick Coghlan ncoghlan at gmail.com
Tue Sep 6 12:13:29 EDT 2016
- Previous message (by thread): [Python-Dev] Please reject or postpone PEP 526
- Next message (by thread): [Python-Dev] Please reject or postpone PEP 526
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 6 September 2016 at 02:51, Ian Foote <ian at feete.org> wrote:
On 05/09/16 14:46, Nick Coghlan wrote:
That's not what the PEP proposes for uninitialised variables though: it proposes processing them before a series of assignment statements, which only makes sense if you plan to use them to constrain those assignments in some way.
If you wanted to write something like that under a type assertion spelling, then you could enlist the aid of the "all" builtin: assert all(x) : List[T] # All local assignments to "x" must abide by this constraint if case1: x = ... elif case2: x = ... else: x = ... Would the
assert all(x)
be executed at runtime as well or would this be syntax only for type checkers? I think this particular spelling at least is potentially confusing.
Only for typecheckers, same as the plans for function level bare annotations. Otherwise it wouldn't work, since you'd be calling "all()" on a non-iterable :)
Guido doesn't like the syntax though, so the only place it would ever appear is explanatory notes describing the purpose of the new syntax, and hence can be replaced by something like:
# After all future assignments to x, check that x conforms to T
Cheers, Nick.
P.S. Or, if you're particularly fond of mathematical notation, and we take type categories as sets:
# ∀x: x ∈ T
That would be a singularly unhelpful explanatory comment for the vast majority of folks, though :)
-- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
- Previous message (by thread): [Python-Dev] Please reject or postpone PEP 526
- Next message (by thread): [Python-Dev] Please reject or postpone PEP 526
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]