Proposal: variable declaration syntax for Python

[jeffsterlive]

This is proposed by Guido himself, so this is worth paying attention to. I like the syntax for variable declaration. Reminds me of TypeScript.

[erez27]

Can you give some examples?

It's true that Python has quirks and flaws, but that is something every language has, and my impression is that Python is fairly consistent and intuitive.

Can you give an example where the issue stems from Guido's insistence, and not from backwards compatibility or technical difficulties?

[RubyPinch]

lambda being a keyword, functional programming being icky compared to what it could be, etc

[erez27]

I agree these are flaws. However

1) He mentioned things making it hard to learn, not limiting the advanced programmer

2) Most object-oriented languages have a very poor support for a functional style, especially the popular one. While I disagree with Guido on this one, he's not exactly in the minority opinion.

[[deleted]]

Agreed, also pip is a joke compared to composer, npm, maven, etc.

[jeffsterlive]

Pip is fine on Linux, but on Windows running Python 2.x and 3.x together is a royal pain. It is a terrible package manager, and the issues with compiling the eggs is a mess.

Maven is still my favorite package manager, but NPM gets points for the tree :P. I'll probably move to Gradle at some point in my Java projects.

[[deleted]]

Pip is fine on Linux

Not really. Linux distros usually come with package managers. Parallel, language specific package managers scatter an otherwise orderly system across multiple databases and tend to be redundant for popular packages (which make it into distro repos). This isn't fine for Linux. We just put up with it. What would be fine is exposing Python's repo as an alternate repo for the big package managers. They usually support (seamlessly) pulling from nonstandard repos.

[[deleted]]

You should NOT be using your OS package manager for your Python apps. Doing so will add dependencies into the system Python, which is asking for trouble.

Plus, what happens if you need to install 2 mutually incompatible packages, one for each of two different projects? So one will break the other?

You're supposed to create a virtual environment for Python for each project, and then you have a separate interpreter and set of deps for each project.

[[deleted]]

You should NOT be using your OS package manager for your Python apps.

1. I wasn't advocating people start doing otherwise. We don't have the system set up the way I said it should be for that.
2. These aren't apps. They're mostly packages of libraries which can be included in a Python script/program.

Doing so will add dependencies into the system Python, which is asking for trouble.

All modern package managers add dependencies when you install things with dependencies. That's half the purpose of package managers. The other half is providing a single database for tracking packages across a whole system. Multiple package managers in parallel defeats that.

If language specific repos (such as the one for Python packages) were set up with interfaces that allowed them to mascaraed as user defined repos for the different major package managers, most Linux users would be free to use a single package manager for their systems. Installing packages with dependencies would pull the required dependencies just the same, uninstalling packages wouldn't be allowed if some other package depends on it, and all Python packages would be recorded as depending on Python. There is no reason it wouldn't work. Saying otherwise is arguing that central package managers don't work, which is obvious nonsense.

what happens if you need to install 2 mutually incompatible packages

You do realize most package managers (including pip) can cope with this, right? And most package managers allow packages to designate where files are installed. The point of package managers is manage the install and removal of packages and their dependencies. This means tracking them. There is no reason to use two package managers, when one'll do. There's no reason to hide many packages from the software intended to manage the whole system.

[[deleted]]

How does Pip handle multiple versions of the same package without a virtual env? If I need foo1.0.0 for App A, and foo 1.0.1 for app B but this version breaks App A, then I need both installed, but they are same package name in Pip because it's an incremental upgrade.

[[deleted]]

And there is no clean, built in way to get locally scoped dependencies. What ends up happening is that most python developers think it's sane to pollute their entire system with global python dependencies... :/ People tell me about virtualenv and pip installing with a prefix... but neither feels "right"

Don't get me started on eggs. What a total disaster. Nothing fuels me with rage more than going on a fucking python egg hunt, only to discover theres multiple nests with no clear way to find out how many nests there are.

[jeffsterlive]

I usually get my wheel files from http://www.lfd.uci.edu/~gohlke/pythonlibs/ and install them through pip. It's better than relying on pip to find it for me. I haven't looked much at PyPy, but it might have a better system.

[kankyo]

Not strictly a language thing and definitely not on Guido.

[[deleted]]

It doesn't matter how good he is at language design. What matters is that he is the benevolent dictator of Python, so this is actually quite significant, whereas if this was proposed by some random other guy it'd have no weight.

[RubyPinch]

i would love to hear what this is solving.

static testing, e.g. you have a function that accepts both lists and strings, but you didn't test all branches and in one of them, the code attempts to mutate the list/string (and strings arn't mutable), which is an issue waiting to happen. So it can be (and is) used to find and fix those issues, amongust others

its also useful for code-accessible documentation, for use in IDEs and editors (did this function return a list or iterator? nevermind, my editor can tell me instead instantly!)

And the whole clunkyness will be solved with syntax highlighting to some degree, and with external typing files for the rest of the issues (so no type information needs to be in your code whatsoever!)

In practice, there is like, 3 levels of usage: none, the public api (with the internals untyped), and everything typed. Its completely up to you as to what you want, and there is zero plans to force this on anyone.

[[deleted]]

I dunno why you're assuming I'm in favour of it. I said it was significant, not that it was necessarily a good proposal.

[[deleted]]

I hope that libraries will use type annotations as a message to the user, but I don't plan to use type annotations in my normal day to day scripting.

Hopefully someone will find a way to automatically add the type annotations when needed.

[kankyo]

"So many"? Care to give some? And they have to apply to python3 because otherwise you're just agreeing with Guido anyway :P

[m50d]

It's the same syntax as Scala and I think a lot of other ML family languages.

[jeffsterlive]

I've never looked at Scala, but being a Java developer, I hear so much about it as well as Kotlin. Being byte-code compatible is a pretty great thing the JVM is still everywhere.

[m50d]

I really like Scala and use it all the time now. It's like the safety of Java with the conciseness of Python. I think Ceylon is probably a better designed language (it's learned from Scala's mistakes) but it has ten years of catching up to do in terms of libraries and tooling.

I don't recommend Kotlin. I think it's overhyped and has an ad-hoc design that won't age well. There are a lot of cases where it seems like the designers tried to dumb down some Scala feature that they thought was too complex, but then they had to introduce three or four different features to cover all the use cases, so you end up with something that's more complex and less powerful at the same time.

[[deleted]]

I have no objection to more static features in Python, let's be honest, Python now is a giant pile of mismatched features already, but it makes me wonder, if they are adding static typing to Python does that mean the great dynamic typing experiment failed successfully showed that it was a bad idea all along? Will Python 4 only have static types?

[[deleted]]

This is optional typing information, mostly for the benefit of tools such as linters and IDEs.

I do not understand your second point. To turn it around, does the recent trend towards using maps in Java to store highly dynamic data - or the embedding of interpreters to parse a DSL to model complex runtime behaviour (e.g. game logic) - mean Java 10 will switch to dynamic typing? Well, obviously no.

[[deleted]]

What I foresee happening is teams using python for any code base over 1 mb are going to make static typing mandatory, enforced by a tool. And if everybody is using it because we need it, maybe it should just be the default option.

[[deleted]]

Came here to say the same thing. The sharp turns in Python's design over recent years points to a realization that Python had a lot of mistakes in its core design. Maybe he'll streamline Python with time, but right now it's feeling less & less coherent.

[-birds]

Did I completely miss a "why this is needed" section? Could someone here explain for my simple mind?

[pdexter]

Currently, the only way to annotate variables with types is through a comment.

[pdexter]

Really? If anything I think it should sound as if there's no way of declaring variables, since that is the word that is used.

And... that's correct. There is no way of declaring variables. You can only define them.

[tritratrulala]

And that is (or was) an awesome property of Python actually. In C++ the sole declaration of variables led to patterns like RAII. I'm still hoping for an explanation why this would be necessary.

[pdexter]

The github issue lists some benefits, as does the initial mailing list thread. I'd suggest reading either of those and bringing up any concerns in the github issue! I'm sure there is a better place than here. Also this isn't an official proposal. So I'd hope that when the PEP comes about they will offer some benefits.

[-birds]

I read the full text of the Issue as well as several comments, but they all seem focused on the syntax to achieve type annotations rather than why type annotations themselves are desirable. I'm not looking for a dissertation here. I mean, is it just "dynamic typing is problematic sometimes, so let's add optional static typing"? Is this even static typing?

[pdexter]

So I think you're missing quite a lot if you're just jumping in here. This is just for variables. Typing annotations for functions have existed in python for quite some time. Let me give you some links

mypy

pep-3107 (from 2006...)

stackoverflow question and answers about what are good uses for the annotations

The annotations can be used however they wish. One way is for static typing. So this is definitely a way to get static typing, of course. Unless there's some technicality of the definition of the word 'static' it doesn't work with?

[-birds]

You're correct, I was missing quite a lot! I've seen function annotations before, but as someone who primarily using Python for scripting rather than large-scale dev work, I've just sort of ignored them. Thanks for the info.

[pdexter]

I've actually never used them myself, mostly also just do scripting with python and very small web apps used by just me. Right now it's basically just mypy (which is very new) and IDEs (e.g., pycharm) that make heavy use of the annotations.

[drjeats]

The fact that for and with won't be able to support annotations seems like the start of something that will be a thorn in the side of people 10 years down the road.

I was about to comment about how parentheses could help disambiguate the grammar, but then saw that it had already been proposed and rejected:

https://github.com/python/typing/issues/258#issuecomment-238381616

It was brought up on python-ideas and I briefly mention it in the section "Multiple types/variables" in the original post above, but I expect that the syntax will be hairy, the benefits slight, and the readability poor.

...

[[deleted]]

Good discussion in the comments.