Earlier quoted context omitted.
Proper unicode handling, list comprehensions, generators, await & async, TSL 1.1 & 1.2 support, better namespace handling, better string interpolation, and better argument parsing are just a few of the things that you get. Is there a feature that could entice these people? Or have they made up their minds?
List (and set,dict and generator) comprehensions and generators are available in python2. Await & async and unicode handling are nice improvements, but you could do both in python2 well enough if it was important to you. TSL support I don't use in python so I cannot comment on it. And I've honestly never found namespace handling or string interpolation a problem. Is there a feature that could entice these people? Or…
Python past, present, and future with Guido van Rossum [audio]
81–90 of 151 posts
Re: Python past, present, and future with Guido van Rossum [audio]
#82Earlier quoted context omitted.
Haskell and OCaml are also 90's languages. The rise of Python at the expense of safer, typed, faster, more principled languages makes me very sad for the state of our industry. I do not even believe it is the best choice for teaching programming to children. It heavily mixes and conflates higher-level ideas like lambdas and list comprehensions with imperative programming and mutation (the assignment syntax "x=x+1" mu…
> "x=x+1" must be especially confusing to high-school kids I like immutability as much as the next programmer, probably more. But the idea that changing the value of a variable in memory is confusing to high-school kids gets repeated way too often with way too little evidence. X isn't the x from algebra, x is your bank account balance. That it changes at payday is not a hard analogy to understand. I have yet to meet…
Re: Python past, present, and future with Guido van Rossum [audio]
#83The Python team does an incredible job at making the language evolve. This is a 20+ years old language, with billions of lines written in the world, and allowing a huge number of paradigms. It still matures, steals ideas, makes hard compromise on growth vs compat, etc. I know very few other techs that can even compare to this level of legacy/flexibility.
E.G: the current debate on the mailling list about the "delayed" keyword: https://mail.python.org/pipermail/python-ideas/2017-February...
(Python-idea is a fantastic mailling list BTW. You learn a lot about programming, community management, Python and humans. It's very approachable, yet you read some very talented people. Sign up ! https://mail.python.org/mailman/listinfo/python-ideas)
Coding in 2.x is now a pain. You can't see that if you are stuck in 2.7. 3.X doesn't seems appealing because what it brings on the table is not shinny. But the hundreds of small fixes hugely add up, and the experience is not the same at all on any project that takes more than a few days.
The good things is, Python 3 won. Nobody starts a new project in 2.x, most important 3rd party libs are have been converted and legacy code is ported every day. Porting a big code base is not really hard (2to3, python-future and python-six do most of the work) and can take only a few hours if you know what you are doing. Which is nothing given Guido have us 15 years to do it.
Honestly I had more time porting from Django 1.5 to 1.9 and DRF 1 to 2.
Python 3.6 is a wonderful release and a bliss to use. pathlib, f-string, better error handling, absolute imports, diminished verbosity, transparent unicode support, stable asyncio, unpacking everywhere, improved windows support, wheels for so many things, subprocess pools, pip+venv included (although debians admin excluded them, grrrr)... Everytime you go back to an earlier version it feels clunky.
The problem is, there are very few tutorials showing you the current best practices. I still read plenty of .format(), os.path.join(), manual subprocess/threads handling, etc.
People are still complaining you can't provide a standalone Python program while nuikta have been compiling very well Python for years now. It's even yum/apt installable.
Whether you are in Python 2 or 3 though, the ecosystem makes it all.
I'm amazed at where I find Python these days. It's the official language for colleges in France, it's installed on Linux and Mac by default, on the raspi (en consequently a recommended language for all students in the UK). It's at Google, Facebook, Instagram, Apple, Disney/Pixar, Sony, the CNES, the NASA, Mozilla, Docker...
But also in very heterogeneous places. Blender uses it to script, but most GIS as well. I got clients from everywhere using it: mathematicians, physicists, geographers, sysadmin, bankers, big data analysts, deep learning researchers... In big and small ways.
Plus there are so many great 3rd party tools: requests, django, sqlalchemy, numpy, pendulum, begins, jupyter, httpie, faker, marshmallow, autobahn, crossbar, pew are fantastic.
But how do you discover those ? The ecosystem is so huge, even curated lists such as https://github.com/vinta/awesome-python are intimidating.
On strengh of Python is that it's good a little script upt to big projects. but there is an enormous list of things to learn if you want to get out of the scripter mind set and start coding a big project.
- virtualenv. Wait virtualenvwrapper ? Wait pew ? wait pip ? wait conda ?
- tox, coverall, pytest, flake8, pylint, bandit...
- Python path, modules, __stuff__...
And the packaging is still a mess. It's hard to make a setup.py file for a newcommer. And the 1000 files next to it. It's hard to make a compiled extension wheel. To provide a msi, a deb or a dmg.
It's hard to do desktop or mobile UI. Kivy and PyQT are nowhere as easy as creating a website, which says it all.
Mypy and type hints are not mature enough. Really a pain to use. I would not recommend it right now. Also VSCode and PyCharm makes everything better. I'm a sublime text guy, but the competition rocked it on this one.
Asyncio is super low level. Most people should probably just not use it, it's designed to dev high level libs, not to code your service yourself. And most high level libs using it are not mature. The revolution hasn't happened yet, and we need it to happen in the next 2 years. MeteorsJS is here and kicking. JS has the Webpack ecosystem (which sucks, but provide features you don't have in pure Python right now). You see more and more stack with Sass + es 6 + jsx + whatever and the Python tools to do it don't cut it. So you are back to JS. I hate JS.
Hosting a Python website is still too complicated. pythonanywhere.com comes close, but beginners want PHP + FTP kind of deployments, and you can't blame them. Not everybody needs the robustness of our pro stacks.
Performances, though, has never been an issue for me. I know some people that have indeed the need for it, but my experience is that they are a rare breed. Most people complaining about it want a pony, they don't have a Python performance problem.
Nevertheless, I look forward for the gilectomy just to stop hearing the FUD. But I'm not holding my breath.
I have more hopes for Pyjion, the Microsoft JIT, though. Their approach is the sanest I've seen. Pypy is nice, but is having a hard time by design. Pyston is dead.
Free perf is like free pizza. You don't need it, but hey, free pizza!
Also I have a feeling that rust and Python will be very good friends in the future...
Re: Python past, present, and future with Guido van Rossum [audio]
#84Earlier quoted context omitted.
Haskell and OCaml are also 90's languages. The rise of Python at the expense of safer, typed, faster, more principled languages makes me very sad for the state of our industry. I do not even believe it is the best choice for teaching programming to children. It heavily mixes and conflates higher-level ideas like lambdas and list comprehensions with imperative programming and mutation (the assignment syntax "x=x+1" mu…
> the assignment syntax "x=x+1" must be especially confusing to high-school kids It wasn't at all confusing to me as an elementary school kid in BASIC, so I doubt it. The variables = named boxes metaphor was a fairly standard part of the pedagogy. Immutability is great, sure, but let's not pretend that imperative sequences of instructions aren't basic and common things humans have to deal with and quite natural.
Re: Python past, present, and future with Guido van Rossum [audio]
#85Earlier quoted context omitted.
> "x=x+1" must be especially confusing to high-school kids I like immutability as much as the next programmer, probably more. But the idea that changing the value of a variable in memory is confusing to high-school kids gets repeated way too often with way too little evidence. X isn't the x from algebra, x is your bank account balance. That it changes at payday is not a hard analogy to understand. I have yet to meet…
I never said mutating a variable is confusing. I said repurposing the equality operator is potentially confusing, especially for children. Pascal used ":=" to mean assignment, long before Python existed.
Re: Python past, present, and future with Guido van Rossum [audio]
#86I've recently had to start writing python professionally and I'm not super impressed. My previous python experience was writing small services and fixing others code. Now that I'm working on larger "apps" it feels like a 90's language with all the rough edges and warts. I'd rather being working in a language with better language services and tooling, but python has numpy and all these data viz libraries so whatcha go…
I'd absolutely love to hear what language you're using that's superior and not a "90s language" then. Pretty sure most of the popular languages date back to then if not a decade or two earlier. I find it especially amusing you cite typescript and the node ecosystem as superior. I've never seen such an unreliable and constantly changing ecosystem with dozens of frameworks and libraries ever in recent history.
(Their intersection of uses isn't total, of course; Python's still got Go handily beat for numpy-ish stuff and interactive use. See Julia for a possibly-superior post-90s competitor in those areas, though I've only played with it.)
Re: Python past, present, and future with Guido van Rossum [audio]
#87Earlier quoted context omitted.
I had to work with Python a few times in the past year and I really have to agree. The lack of proper lambdas, closures, its reliance on mutable data structures and imperative idioms, and the useless distinction between statements and expressions makes it feel like somebody was trying to write a modern language but for some reason stopped halfway. For example: you can't assign the result of an "if" statement. Why? Be…
Yeah, I don't think you know python very well at all given your criticisms. The very first thing you criticize is "its reliance on mutable data structures"--uhh no, most data structures and types in python are immutable. I'll at least agree I've met a lot of python snobs who say don't use the built in map/filter functions and things like that in favour of comprehensions, but that's hardly representative of the langua…
I'm sure there are immutable versions of those same data structures hidden somewhere in the standard library, but I haven't looked.
I did stumble upon pyrsistent (https://github.com/tobgu/pyrsistent) a while ago which does provide proper immutable (and persistent) data structures for python.
Re: Python past, present, and future with Guido van Rossum [audio]
#88Earlier quoted context omitted.
I never said mutating a variable is confusing. I said repurposing the equality operator is potentially confusing, especially for children. Pascal used ":=" to mean assignment, long before Python existed.
BASIC used "=" for both assignment and equality tests long before Pascal existed and was more popular for teaching the youngest students even when Pascal was available, so I find the idea that the use of "=" for assignment is some kind of barrier that high school kids (or younger, even) are going to have a lot of problems with just as implausible as the idea that imperative mutation is such a problem.
Re: Python past, present, and future with Guido van Rossum [audio]
#89I've recently had to start writing python professionally and I'm not super impressed. My previous python experience was writing small services and fixing others code. Now that I'm working on larger "apps" it feels like a 90's language with all the rough edges and warts. I'd rather being working in a language with better language services and tooling, but python has numpy and all these data viz libraries so whatcha go…
Haskell and OCaml are also 90's languages. The rise of Python at the expense of safer, typed, faster, more principled languages makes me very sad for the state of our industry. I do not even believe it is the best choice for teaching programming to children. It heavily mixes and conflates higher-level ideas like lambdas and list comprehensions with imperative programming and mutation (the assignment syntax "x=x+1" mu…
There is no rise. Not any more. At best, it's a plateau, and in my opinion, all dynamically typed languages except Javascript are on a straight decline curve, slowly being replaced by statically typed languages.
I noticed that a lot of people who enjoy Go come from Ruby or Python. Go's type system is clearly antiquated and weak, but it's a straight upgrade from a dynamically typed language, which is why it's finding an audience with the Python/Ruby crowd.
Re: Python past, present, and future with Guido van Rossum [audio]
#90I've recently had to start writing python professionally and I'm not super impressed. My previous python experience was writing small services and fixing others code. Now that I'm working on larger "apps" it feels like a 90's language with all the rough edges and warts. I'd rather being working in a language with better language services and tooling, but python has numpy and all these data viz libraries so whatcha go…
Haskell and OCaml are also 90's languages. The rise of Python at the expense of safer, typed, faster, more principled languages makes me very sad for the state of our industry. I do not even believe it is the best choice for teaching programming to children. It heavily mixes and conflates higher-level ideas like lambdas and list comprehensions with imperative programming and mutation (the assignment syntax "x=x+1" mu…
Many other comments already discussing this, but I have to add this. I don't think that has ever confused more than a handful of high school students because you are almost certainly bringing an understanding of "=" that you acquired at a much higher level of math.
For a lot of students, "=" isn't even what you would consider the "equality" operator... it's the simplify operator. That is:
2 + 2 = ____
has, for them, One and Precisely One answer. (You know this to be true, because your brain has already supplied that answer, and you already know that "3 + 1" is not an acceptable thing to put in that blank, even if a later understanding swoops in to say "Well, yes it is..." You still first knew the One and Precisely One answer.) So it's not the "equality" operator for them.(I will give this kudo to Common Core, it tries much harder to avoid grinding the "simplify" definition into children's heads than older curricula.)
I don't think they get much collision with the "simplify" operator while programming because the contexts are too different.
I'd also submit that the conception of mathematical statements existing timelessly in some abstract math space would be foreign to them, and it is not hard for them to develop the "intuition" that "x = x + 1" is simply a statement that "after" this statement x will be one greater.
The only people who have trouble with "x = x + 1" are mathematicians trained to a very particular formal level, where they understand the idea of equality more deeply than a high school student but still haven't noticed that operators and formalisms change between branches of math all the time and insisting on your precise definition of an operator hasn't yet inhibited you from understanding the branches of math that redefine it themselves. Granted, no branch of math uses a definition that looks like the imperative programming version (even mathematical formalizations of imperative programming tend not to use = for assignment from what I can recall), but it's still just one more definition in a constellation of definitions, not the uniquely odd one out. You're going to have a hard time with homotopy type theory if you insist on your conventional = definition, for instance.