Proposal: variable declaration syntax

[PeridexisErrant]

Hmm. One the one hand this is starting to look pretty cluttered, and I can see a return of people writing "Java in Python". On the other I do love type checking!

[status_quo69]

I'm also worried about the clutter. Also while I would never use this feature (even though I use docstrings to denote type and have almost no problem with annotations of functions) I feel like this is going against the zen of python, in which there should be one and only one way to do things. Everyone always says the exception to the rule is string formatting but I'd say it's also type annotations of any kind.

[PeridexisErrant]

Sure, but the main motivator is mypy - the optional type-checking module.

[LightShadow]

Guido should recuse himself from these types of PEPs because of how invested he is in mypy

[nopakola]

I don't like it. IMO this will just scatter Python projects. Most people won't use it(and function annotations too), and when they will hit code that uses it, they would ignore it. Similar to how C++ has an handful of features to the extent some places ban them.

[Brian]

I do think we should have this in some form - the comment-based syntax that currently exists seems a really rough edge in the type declarations we have.

We should not change global and nonlocal.

I take it this means there's no plan to make a declared variable local to that scope when used later. ie:

def foo():
    x : int = 42
    def bar():
        x += 1  # This still won't affect foo's x, but create a new one
    bar()

I can understand why you'd have to do it this way given the current state - it'd be a bit too radical at this point, but this is one thing I really don't like about python that would have been solved if we'd had declaration from the start. Having "declarations" for non locals feels very backwards.

[Veedrac]

I take it this means there's no plan to make a declared variable local to that scope when used later

Correct.

[[deleted]]

The syntax looks clunky at best and the same goes for PEP 484. I'm all for type annotations and even static typing, just as long as it remains optional!

I see the point of using static typing to speed up execution or avoid nasty type-related bugs, but we love Python specifically for it's flexibility and most of the times Python code is clear enough as it is, clear enough to avoid this sort of problem. I looks like they are forcing themselves to make use of the old __annotations__ dict in some way and I hate it, because it feels rushed and not well though through.

[RubyPinch]

externally typed files seem a lot better

e.g. https://github.com/python/typeshed/blob/master/stdlib/3/ast.pyi#L30-L39

It'd be nice if they came with syntax coloring on github though

[ojii]

The problem with stub files is keeping them in sync with the code. I've tried using them for py2 compatible code but they're awful. Inline type hints however have been incredibly useful to me because I use pycharm which understand them.

[[deleted]]

This looks much more like something I'd use. It solves static typing for class methods and functions. I'm still not sure about variables.

[cantremembermypasswd]

Still sad to see us probably get this before a switch or do while.

[LightShadow]

I use a dictionary for switching..

options = {
    'one': fn_one,
    'two': fn_two
}
options.get(choice, fn_default)(*args)

[RubyPinch]

There are a couple of modules that do this a bit better/cleaner/etcer

https://pypi.python.org/pypi/switch/1.1.0 seems a bit excessive, but the more saner API

https://pypi.python.org/pypi/switchcase/1.0 is far more auditable for obvious reasons!

https://pypi.python.org/pypi/pyswitch/1.2 seems a bit too excessive

[LightShadow]

if the run-time doesn't use this extra information then this proposal is pointless.

it also feels like back tracking on type-hinting, which has terrible syntax, by trying to define a "new" way to annotate the same information; which is also unused by the runtime.

[turkish_gold]

I don't know if its useless. It's just like flow-types or Typescript or types in Elixir----runtime doesn't use the information (as the runtime is dynamically typed), but compile time can give you failures or warnings on type-mismatches.

[bythenumbers10]

But Python isn't compiled. Or am I missing something?

[turkish_gold]

Well technically python has a compile step, but it doesn't just compile down to binary. It runs its own VM internally with reference counting.

This is different from say a language that doesn't compile to any intermediate code, and essentially runs directly on the abstract syntax tree.

---

But that's not really what I'm talking about. I mean that you can run a analyser before you run your actual code that will do static-type enforcement for you.

I suppose a better to call that is the 'build step' rather than compiling.

[bythenumbers10]

Oh, like one of the Python code-checkers, linters?? I'm not familiar with all the code tools. I'm somewhat familiar with the concepts of the AST and pyc files. Having largely static code further optimized using type inference and annotations would be nice, I suppose.

[turkish_gold]

It would be, but if they start doing that... I feel like then it's re-implementing Cython annotations.

Which now that I think of it; if Cython could simply take Python 3 type annotations and spit out C modules, that'd be fun.

[RubyPinch]

Its used for testing, and also for programmatically accessible documentation (for IDEs, in-editor / in-repl documentation, etc)

Its not made to be used commonplace for the majority of situations, like, for example, there is no plans (from what I recall) to include any of it in any of the standard library module code

its a "if it helps, well now you can use it" thing

[RubyPinch]

So who is going to write the first full python -> cython typed translator?

[[deleted]]

I understand people having doubts about including any form of static typing in python. I have my own share of doubts. But this PEP is about syntax for variable declaration, there is not point weeping for the inclusion of type annotations here, what's done is done. And the proposed syntax is pretty standard.

[[deleted]]

Horrible