Thank You, Guido
blog.dropbox.com
blog.dropbox.com
And lets be honest, he's earned it.
Thank you Guido, after learning Python, I never looked back, and it has been the source of great joy for me over the last decade.
I’m sure he’s going to take a break from the chaos of being at a unicorn in SF and the departure from BDFL, spend some time in the woods reading books and getting ready for the next thing. He’s got plenty of cash (presumably) so hopefully finances are not a source of concern. Then the itch will come and hopefully he will be poised to scratch it.
I’m sure we’ll see more from him!
That matches my experience. All the pros and cons that in principle apply to any language, whether newer than Python or older, mean nothing to me in practice. Python is the one that feels right, the others feel like a chore. Since I started with Python 10 years ago, nothing has changed that.
There's ways I'll insist that Python is the best at [x], and ways I'll concede some other language is better at [y]. But it never amounts to anything close to a debate about what language I should use.
Beyond times when Python is clearly wrong, there are other issues, mainly around tooling and documentation. Languages have come a long way in the past 20 years.
So if your task was to deliver let's say commercial grade FFT library ( substitute with any other long computationally extensive process ) for consumption by others you would write it in Python?
On my team, we've been successful with this rough approach:
1. write a prototype in Python to explore the idea/ensure correctness
2. extract the core library and re-implement it in Rust
3. consume the core from Javascript via WASM and Python via pyo3 (Python/Rust bindings)
Kinda seems like you are, mate.
To the extent I have a choice, I'll go out of my way to use Python and I'll be a little creative to fit it into certain uses cases where it's not a perfect fit, consciously accepting a reasonable penalty. But yeah, sometimes it won't fit at all.
The point is more that I'd go so far as to avoid taking a job or gravitating towards a project where the development would not be enjoyable based on the tools I'd have to use.
I can definitely understand this point of view. Well sorta. I was/am always goal oriented. I find satisfaction in creating a product used by other people. The actual process of implementation is 90% boring work and language for me is just a tool. I do not get too excited by languages.
A carefully controlled message.
PSF now has an elected steering council to replace him.
https://mail.python.org/pipermail/python-committers/2018-Jul...
Then, at work, I was introduced to Python. It was so...obvious, for lack of a better world. It was like a language I always knew that never spoke before.
I'm now a software engineer, write Python almost all day, and looking back to the 18-year old version of myself, I would only say "if only you knew".
That, and more, is what people like Guido and those who followed his path enable people like me to do: enjoy the art of programming.
Thanks Guido, and enjoy your well-deserved retirement.
Now that you have bigger systems and more complex requirements and cheap high performance computing, the balance is tipped.
And because python is (almost) on the opposite side of the spectrum for your thinking process, you might have a harder time wrapping your head around why it does something in a particular way.
I think this is also true for Haskell evangelists over here also, I think they started acquiring the programming mindset through advanced math(in my experience most have PhDs) etc., so haskell fits the way they solve a problem in their head the best.
For me personally it is Python, the delay between solving a problem and having it translated to python in my head is slim. You probably feel the same way about your own favourite programming language, because it is the tool that makes you most productive with the least effort.
I feel that with Ruby, which I do a lot nowadays and love
WIth regards to Python, it is the things like having to write 'self' on each class method, having spaces as part of the language syntax, inconsistent Object orientation (len(string)?? instead of string.len ) and the neverending Python 2 vs 3 pain.
I tried to learn ruby and was put off by all the magic, last value calculated is magically returned, the useful but cryptic method calls.
It is shorter and more implicit, I like the explicit approach more.
to give you my perspective on the points you made:
- self: more explicit, I would prefer to write it, because there is classmethod(with cls) and staticmethod(without any) params.
- spaces vs. braces: I don't hate braces, but spaces makes it more readable, less things I see(whitespace vs. {}) the less distracted my eyes are from the the characters that do the actual work, you get used to it, I like it more to be honest.
- len(string) vs. string.length: again, no preference, I am used to both.
- py 2 vs py 3: it is not never ending, I helped move a 170K Django project from Django 1.6 to Django 2.1 and python 2.7.4 to 3.6 in a span of a year, we were mainly 3 people working on it on the side, our work was not even in the sprints, 2 senior engineers + 1 really good QA & deployment engineer, it took 1 year because the platform was business critical and we incrementally fixed stuff. At this moment whoever still runs py2 either has been lazy, does not care about technical debt or their business does not value solving technical debt, so they can not allocate time to do it. This is my opinion, might be wrong, maybe there are other reasons also. But the change had to be done for the health and longterm viability of the language.
Really?? This is my least favorite thing about Python. D: It can't possibly be more readable when you're talking about large code blocks. It just happens that we're never supposed to be talking about large code blocks in Python. "If you want to write a lot of code, you use another language," they say -- probably one with braces, which syntax highlighters can match-highlight on. In Python, you just hope the indentation is far enough to make it obvious where something ends and another thing begins.
The syntax, dynamic nature (lack of privates, etc) are so similar yet one is a lot more flexible (Ruby) and another is a lot more explicit (Python).
Ruby is incredibly expressive, the language puts the full power into the authors hands and let them go wild.
There always good arguments on both side of the camp, both have mature web frameworks backed by massive communities. I don't think one is inherently better than the other, it's more a matter of style/mindsets.
I personally love coding in both, in fact today I wrote some ruby code that would run some python code and do stuff with it!
Um, "end"?
:)
From the old fart: conflating performance conscious code with the lack of readability is plain wrong.
Edit: I cannot blame too much though, its generating comfortable revenue for me as a consultant. Still, having to deploy nginx/haproxy to load balance python servers for only 200 requests per second each makes me pray for our planet, but it grants me the money the customer saved on developers ;-)
I think it might be that back when I worked with it I was young and did not know better. Nowadays I assume that if someone put me to do something in VB6 it will be super painful.
God that's well put
I don't use it because Python's more popular and I'm a slave to fashion and critical mass, but it's so much more easy and expressive than even Python's syntax.
for i in 0..5
Also, I hate how discussions like this seem to always turn towards small syntactic differences rather than actual differences in functionality.
Yes, coming from Perl that was a huge hit.
I too have to say Thank you Guido. Python 1.5 helped me a lot with several projects way back when. Then I got into Django later, and marvelled at how easy it was to use. Now I use Python (and other things) for AI.
I am sad because of the motivation for Guido leaving the BFDL position, but empathize and understand. I hope he has fair winds and following seas for whatever journey he sails on next.
May be this is one of the reasons of success of Python and its community which is open, humble, friendly and inclusive.
In my startup we have been using Python as one of the primary development language, and thanks to its community and Guido, we will continue to do so in time to come.
I recently watched a talk by creator of Elm language [1] [2] who is trying to create similar community like Python, I will try it besides lisp, since I like the ethos of Python like community and obviously PEP-20 [3].
From my whole team thanks to Guido, and Python community.
It is much, much better of late (I was thrust into a role a year ago where I am doing 95% of my coding in python now). I'm not sure what's changed; I had assumed it was the "core" culturalists were diluted by the influx of ML people, but it is only an assumption.
The part about Guido personally mentoring women engineers is, despite his (obvious) technical contributions, the most impressive part about his Dropbox tenure to me. The article mentions him leading by example and it's inspiring to see someone of that stature and level of accomplishment willing to spend time with individuals. It's one thing to talk about fostering a welcoming community, it's quite another to offer up his time so generously when he could be doing "higher leverage" things with regards to diversity.
I hope you enjoy whatever you set yourself to next.
I chuckled and forwarded the email to the then head of HR and CEO. I am good friends with both, and I knew they will take it with humor.
It is difficult to find good recruiters.
This is very sage advice.
> Code is read many more times than it is written. Writing code costs something, but over time the cost of reading is often higher. Anyone who ever looks at a piece of code has to invest brain-power into figuring out what it does.[1]
This is also noted in PEP8:
> One of Guido's key insights is that code is read much more often than it is written. The guidelines provided here are intended to improve the readability of code and make it consistent across the wide spectrum of Python code. As PEP 20 says, "Readability counts".[2]
[1]: https://www.sandimetz.com/blog/2017/6/1/the-half-life-of-cod... [2]: https://www.python.org/dev/peps/pep-0008/#a-foolish-consiste...
Code smells draw the eye when debugging. Your brain wants the problem to be in the code that’s clearly “wrong”. So smelly code anywhere near common code paths has a huge cost compared to smelly code in some leaf function in an obscure feature.
One of the wisdoms of XP, I think. The code you touch the most should be the sanest.
I'm really curious how true this is. Partly because, if it really was read more than it is written, people would optimize to /write less/ of it - if you have to pick up everything you put on the floor ten times over, it will incentivize you to put fewer things on the floor in future. And people would say things about code which people say about writing, such as "you have to write for your audience", instead of the more common "it's either boolean readable or unreadable".
And partly because I suspect code is /skimmed over/ more than it is read; that is, people assume what it does, glance at its shape, then if there's no surprise triggered, move on.
I would be interested to know if anyone has studied what it means for code to be read, but my suspicions are that most code which works is almost never read, and most code which is read, is read because it doesn't work and therefore it will be self-selected to be poor code in some regard.
But then, I'm not a programmer working on a large codebase. Those of you who are, how much of it have you read in enough detail that you verified how it works - and no assuming that a method does what its name implies, or assuming that if it passes tests it must work, but actually verifying by studying it that it does what it should and that you understand it?
I mean in real life (when you don't have Guido to do it for you), if people are writing code you can't understand then you need to tell them to fix it. And many people don't like being told they need to rewrite their code because you can't understand it, so it leads to conflict and eventually you often need to fire people.
So yes, it's good advice, but by cleaning up engineering debt you're often going to take on a lot of team debt.
There are people who simply refuse to understand generics and/or stream APIs. Which are to (most) programmers more readable then the same logic being drawn out in a loop.
Meanwhile some other programmer would just write code golf and brag about it.
At the end of the day, it should be about enforcing a coding style that defines what you can or can't do. Adding final to all variable that can be final for instance is a great start.
How come so many people try to use code to show how smart they are?
My first CL at my first job out of college was writing a state machine at Google. I remember collapsing it into this dense, elegant representation by hinging on a couple of bits of state. It took me an extra half day, but I was really proud of the end result, and I remember being mildly put off by the request that I unroll it and make it explicit. Upon thinking about it for a bit, I decided it was entirely reasonable, and after a few more years at Google, I transformed into the kind of engineer insisting that every bit of code prioritize readability over everything else, in the absence of constraints like performance. Across the tech orgs and teams that I've run since, this has paid huge dividends. I'm writing a lot of tensorflow and C++ at a very fast-moving company working on a complex problem, and I don't know how anyone on my team would be productive at all without strictly prioritizing readability.
Being good at coding and having good engineering habits aren't the same skill, and the latter is about discipline and patience (and occasionally thinking like a dumber person), which are inherently less fun than unfettered technical challenges.
I’ve been thinking again lately about little bits I picked up via osmosis and my own early creative writing experiences. In fact I was just noting a couple weeks ago how refactoring resembles an exploratory writing exercise.
I think we need to embrace the creative writing similarities. Would we ever celebrate an author who published efficient, dense and cryptic text? Rarely.
One of the things we do want is someone who paints a clear picture in a few well chosen words. Another is to be inspired. Tricked or bored are not on that list.
We have ideas of a "grade 6 reading level", do we have such a scale for code? If not, why not?
Writing clever code doesn't mean it's being done for that reason. As the article notes, Guido himself agreed that in the early stages of developing a piece of software, such as in an early stage startup, it probably makes sense to write clever code, because you can get it done faster and therefore iterate faster on improving the code to meet user needs. At this stage very few people are working on the code (often just one), so communicating with other developers is not a big issue.
The need for making it maintainable comes later, when the product is mature and many more people are working on the code, so the need for clear communication becomes much stronger.
>We don’t see people writing books in acronyms or omitting words.
Math books written for mathematicians do this all the time.
I think it would be more accurate to say that we assume that other developers have the same amount of context about the problem as we do.
Going back and reading my own code from even a few months ago makes this very evident, as I frequently realize that I'd made various assumptions that required a much deeper level of understanding than I anticipated. The difficulty in providing a sufficient amount of context is readily apparent to me as I go back and fill in the gaps I unknowingly left.
And telling them their cleverness is hurting other people can be traumatic, for one or both parties.
I like being clever too. I’ve just sublimated that into more beneficial things like human factors.
I think that excuse falls over when you look at some old code you yourself wrote, and you find that you can't understand it.
That's presuming your smartness doesn't change much over time.
When I’m trying to add functionality of fix a bug, I’m going to read dozens and dozens of functions to winnow down to a handful of candidates.
Simple code can be filtered quickly and cheaply. Clever code requires contemplation. Which clears working memory.
Yes, I can understand your code. But I shouldn’t have to work for it.
If a critical service is experiencing growth and built on cryptic stuff, then the world may notice if no one can maintain it and it falls over.
when I write code for a concept i don't understand completely, it tends to be complex and cryptic. I'll go back to it after trying to understand the problem and the problem space more and be able to write simpler code.
When are you having fun reading someone else’s code? You’re usually there trying to solve a problem. Your plans for the day have gotten away from you. You may even be having a Bad Day. And this is at least doubly true for failing tests.
Take pity on the person.
An example that frequently occurrs is decomposing a large method into smaller methods. Okay, there are now more lines of code (due to adding method declarations), but what was really gained? The gain that can be had is identifying common use cases and factoring some of those methods out to utility classes that can be referenced from the same source file and others. This can be difficult to identify unless one learns to really look for these oppurtunities.
The approach I've been taking recently is presenting the idea as there's always a minimal level of abstraction, and code should try to achieve it. I'm interested to hear what others think about this.
Python not caring about the type of a parameter makes it easy to share code too.
It's tricky, isn't it? The original quote was about "clever code" versus "maintainable code", but they are not orthogonal: it's possible to write code that's more maintainable (because it's harder to use incorrectly) at the cost of being more clever (because you need to learn more of the language or standard library to understand it). One person's "more maintainable" is going to be another person's "too clever" — you're going to get a bunch of different opinions on where the line lies. Not everybody is trying to show off their brains.
I agree that code should be as straightforward as possible, but I don't think books follow that rule.
Yes, you can have your pie and eat it :)
I’ve seen clever code that was 300% faster, half the lines, completely unreadable, and called once per session, for a total the time of 10ms in a workflow that was minutes long.
No amount of commenting could justify it.
There's nothing to say code can't be performant and legible. In fact I'm a bit confused what "clever" means here. Writing performant but illegible code does not take more cleverness than performant while legible.
Edit. Yes I get the difference and the reasons they do this. The wordplay crossover (cryptic, clever, etc) was notable to me, and reminded me of the link I posted above.
Makes me wonder what kind of secret club they have going on..
Enjoy the retirement, Guido!
It's no secret; they lived through the time where the computing power was outstripping people's ability to express ideas harnessing that power, and the world was ripe for more expressive languages that leaned harder on the CPU to convert them into action.
And, that's still true. ;) New languages are being invented, some haven't caught on yet.
We don't just need ad blocking, we need crap blocking and text caching.
When I leave hints in the code it’s enlightened self interest. It’s often as much for my own benefit as for others.
( ~ might be putting the cart before the horse. ~ take it easy )
It would be great to see some examples of this rewriting. I feel that we see a lot of examples of converting repetitive code to terse code, but fewer examples of "de-clevering" code.
The more I code the more I appreciate statically typed languages.
When I learned/started coding, I liked dynamically typed languages. It was easier to get past compiler. My code seemed to do something. And if there was anything wrong in the way, it would just continue to execute making me feel that my code is at least doing something.
Now more into programming, I don't want to go back to duck-typed languages. I like when compiler gives me guarantees along with exceptions being thrown at runtime when something goes wrong, crashing the program and noticing it immediately that something is wrong.
I think language people also recognizes benefits.
- PHP7 allows using strict types.
- Python has static type support
- Javasript -> Typescript
Disclaimer: Have used php, tried ruby. Using C# and javascript. Looking forward to typescript.
Do dynamic language people: 1. Write more tests? 2. Have more defective code? 3. Are better at writing code? 4. Maybe there is just no correlation between code correctness and static/dynamic lang. I just wrote down MY feelings.
He was gracious and polite enough not to call me a dumbass for not realizing that tabs were a requirement, not an option.
That was also when I became a tab-convert.
Thank you Guido for this incredible tool that has helped so many others actualize their solution aspirations.
It is the ideal programming language for an increasing set of tasks.
But you don't have to do that to yourself to use the language.
Given the impact Python has had on my career I'm nothing but grateful for it.
Thank You
Also highly encourage people to read the PEPs, as well as mailing list archives and interesting bugs on bugs.python.org. The PSF highly encourages backwards compatibility so that history is all there and live :)
Yet, most application engineers are still writing Python on the backend and TypeScript for the frontend.
[I work at Dropbox]
Thank You, Guido!
Thanks Guido!
And since Java 8 the language is pretty nice and offers good functional idioms.
Of course, major versions of libraries still change. But there's no match with the JS approach.
It's not "exceedingly good" at it, it's just alright. Go has done much better for us in this area.
Maybe Jigsaw didn't impact you particularly hard, but you can't argue the JVM has a policy of minimal backwards incompatible changes given that debacle.
Personally I would second Go as a good answer for this. It has its limitations, but it’s simplicity and it’s standard library more than make up for that from a pragmatic standpoint imo
I would argue that the .NET Framework is way better. The way you can have multiple versions installed side by side and have the framework pick the correct one to run is awesome. Granted, you can do something similar with the JVM by mucking around with env vars, but it's not the same thing.
Standing still in the Java ecosystem is fine. Keeping on with the advances is painful and exhausting. The Java tech stack is awesome when it works, but to solve issues you have to go so deep into the tech stack that I'm starting to think it just can't be done unless you're at least a mid-sized company with JVM specialists on the payroll. Not developers, but systems people.
The dance over that as we've gone from 8 to 9 to 10 to 11 is mind boggling.
This is probably why I’ve come to appreciate Rich Hickey’s talks more and more as years go by.
I think Clojure is a good fit when it comes to stability as per their own development guidelines [1]:
The Clojure development team values a measured and thoughtful approach to language evolution with a strong emphasis on maintaining backward compatibility.
FTFY
Go is good at being Pythonic in some senses too. Some would say to a fault.
Standardized since the 80s, it has had only minor, backwards compatible revisions in 99 and 11.
According to the TIOBE index, it's the second most popular language in the world. It works on almost any platform imaginable and it has decades of tooling available for it.
Of course it doesn't have any of the good new things developed recently, but if it's stability what you look for, then I don't see a better option.
The rule has generally been that you can take a 20 year old Perl script and it will still just run. This has its own complications though, as it makes it harder to advance the language, and then people feel it's being left behind (the Perl 6 stuff came after that feeling developed).
It's a longstanding problem in language design and communities, stability vs advancement.
If you depend on some functions in the standard library, it's super-easy to replace them. They're leaf dependencies.
Anyway, C has about the smallest standard library you can have. And if we're talking about it's benefits in terms of compatibility, we're probably talking about the fact that it doesn't introduce new syntax / language features each other week.
https://elixir-lang.org/blog/2019/06/24/elixir-v1-9-0-releas...
That being said I like writing code that can feel “done”. No “I wish I could refactor this object hierarchy to make it easier to use, etc” notions in the back of my mind. Not every piece of code is like that, but enough.
About the only change that had a significant impact on projects I worked on was removal of the 'mysql' DB extension (replaced by 'mysqli' and 'PDO'). For an older project I created a few shim functions and it still works just fine.
While frameworks come and go, the core of the language is highly backward compatible. The choices made early on were in the UNIX style, so they were right.
To quote an earlier post[1],
--
There is something to be said about PHP's staying power. The early versions of the language weren't considered "right". Except maybe they were right for the problem at hand.
The way I see it was PHP captured the vector of change, and left ample room for future developments. Both internal changes (hello, bytecode; hello, JIT), language level features (hi there, namespaces), and runtime level features (oh hai, countless built in classes and functions).
Moreover, unlike many framework that shone brightly and burned out quickly (Rails?), PHP captured the essence of the environment: HTTP is stateless, and URLs aren't uniformly routable from either end, and well-formed HTML/XML/JSON is just a subset of tag soup.
Worse is better.
--
The language is arguably complete and any syntactic changes you could wish upon yourself are doable in form of a library because it’s a lisp.
And all that piggybacks on top of already quite stable java ecosystem.
Can’t get much better than that.
Maybe C? Cobol? Ada? Fortran? Though even those languages have modern flavors & updates...
We make progress because we learn, not just new technology, bu new approaches to old problems. When I see an "old" programmer who keeps writing C89 code because "it still works", it is painful to see them rejecting decades of learnings about how to write better software.
I looked up "engraving marble" to find an example of the above, but no luck there: They use lasers for that now.
I do enjoy some of the "new" features of python 3.
I generally run with LANG=C, and run into Python3 issues regularly as a result.
Also, if you have to support 'async' code that someone wrote, that could be a heavy load as well.
Come on over to Javaland, it's nice, warm, and the sun is always shining!
With the exception of the Java 8 -> Java 11 transition (skipping the non-LTS versions), things are pretty stable. You don't have to use any new-fangled features if you don't want... and your Java 3 code compiled nearly 20 years ago will still run just fine on modern JVM's.
My oracle predicts much worse weather.
Funny joke, but Oracle is all but out of the equation at this point.
They've stepped back and become yet another JVM vendor that takes OpenJDK source and compiles it into a binary for users, sprinkled with some special sauce here and there, and just happens to charge for support.
That puts them in line with Azul, IBM, Amazon, AdoptOpenJDK Project, SAP, Red Hat, and a ton more.
You get your pick of JVM vendors now... That's a fantastic thing for Java.
Running code is the easy part. Writing it is the hard part.
And if running on a VM is your standard, my old DOS programs still run on DOSBox :-)
Java and the JVM themselves value backward compatibility, and I'd say Clojure takes it a notch above that.
Overall it was for the best, since prior to that it was just weird code that had a bit of a undefined behavior since it wasn't using the macro in the proper way. But it still meant we had to go and fix a few of them so they compiled again. Though in the process we realized that we were misusing the macros to begin with.
Also, new tech trends are not just hot air, there's also a lot of innovation happening. You just have to see through the hype and wait until the dust settles.
I assume that I hear about new stuff fairly early in their adoption, since I try to keep up with these things, so if it's still a thing two years later, it might have enough staying power to be worth learning. After that it still takes a while for me to get around actually learning the things.
Go and Rust are languages that have been on my todo list for a while now, for example, but I still haven't touched a JS framework because I haven't seen one with staying power yet.
Just get away from javascript and once in 20 year platform language changes like swift and most platforms don't have that much churn.
It's part of the value proposition: the language and libraries are planned for forward compatibility and stability for use ten years in the future, as well as now.
It's ideal if it has a stable community, but it should be a small group of core devs, so they don't have time to change things that aren't broken. It helps if the community has a culture of stability.
In my experience, FreeBSD and Erlang fit this bill. You may need to manage some small changes now and again when upgrading between releases, but generally the most apparent changes are things you were doing before work better. And you can run a fleet with rather divergent versions, as long as you're careful not to use new features (it helps to make sure your dev environment matches your most out of date hosts)
I hear every day: don't change a thing in D, just add these two features.
C also shows excellent stability and backwards compatibility.
Cobol is also quite stable, but IDK about the quality of open-source tools for it.
The problem of stability is that you are pinned to the moment when the interfaces were defined and committed to, and this moment goes further and further into the past. Quite often this means that you can't use the new things which give advantage to your competitors.
Rails is so-so.
Python 3 is 11 years old.
11 years is a long time to married to the bugs of the past.
20 years is a long time to be married to a fixed language.
Currently there is no all encompassing theory for the design of languages or anything. So there's no prove-able way to design a language that can always be improved and always be backward compatible.
I imagine that such a language would be incredibly simple. Minimal syntax and all sugar and conveniences would be built with libraries.
We get it, some people are unhappy that py2 is deprecated. But whatever sympathy I might hold for that viewpoint is drowned out by the incessant and unproductive whining I keep seeing here.
Can we please move on now?
There's nothing "simple" about "list of characters" in Unicode. Discussed at length at: https://news.ycombinator.com/item?id=18154667
Here's how a Unicode export with 20 years of experience in Unicode explained it: https://blog.golang.org/strings
> Some people think Go strings are always UTF-8, but they are not: only string literals are UTF-8. As we showed in the previous section, string values can contain arbitrary bytes; as we showed in this one, string literals always contain UTF-8 text as long as they have no byte-level escapes.
> In fact, the definition of "character" is ambiguous and it would be a mistake to try to resolve the ambiguity by defining that strings are made of characters.
> [Exercise: Put an invalid UTF-8 byte sequence into the string. (How?) What happens to the iterations of the loop?]
If you aren't in Unicode, then "character" is the same as "byte" so splitting the types gets you nothing of vlaue.
Assuming you are not implementing a low-level Unicode library, what's your use case for "list of Unicode characters" ?
This would help a lot in preparing code incrementally to work on python3.
In the mean time, mypy in python 2 mode doesn't warn about str <-> bytes either :/
Businesses think once it's written it will always just work...and that's true if the underlying OS and hardware never change, and the business never changes, and requirements never change. But even if it's a completely niche application whose requirements never change, after a while the hardware breaks, and we can't buy the same, and we can't license the old OS or it has documented problems that won't be fixed, so we have to use a new one, and we can't get the old software dependencies to work on the new one, etc etc.
Being a CADD person, I had a lot of contact with A/E/C, facilities management, space planning, etc.
Seems like everyone suffers legacy, neglects maintenance, prefers do overs.
Cultural? Misaligned incentives? Bad accounting? Complexity catastrophe (when cost of any change outweighs benefits)?
If someone knows, please tell.
Sustained operations are hard unless you have growth, because flat budgets are cuts given inflation, etc. Given the choice between stocking the toilet paper or doing a preventative maintenance on the elevator that may impact your successor a few years from now, what do you choose?
The only times that facilities are run well is when there is a retired senior military nco in charge. Usually someone who was a chief of the boat in the Navy.
I would call it more something like upgrade debt or time debt, as it's a problem that appeared because an external situation changed over time. Similar problem in that regard are operating systems which change and let old software behind, or in case of linux old packages not working anymore, repos disappearing, etc.
What I'm talking about can't be improved or fixed, or higher-ups refuse to improve or fix it. Instead, it has to be completely replaced. It's like a Replicant with a four-year lifespan. You literally know it's going to die in four years, and nobody orders a new one until the old one is practically dead, and everyone has to rush to replace it.
It's not too late though. We could add better backward compatibility into Python 3.
No really, what was the relevance of that comment? A task from a decade ago, with maintenance reaching end of life in two months, and they're off-topic boasting about "already starting" it. What, they think it's early and applause-worthy? They're trying to show that even Guido had to deal with it? Or that even with Guido they couldn't complete it quickly? "Here are some words about Python to make the PR representative look hip and with it"?
Nothing about that interjection reflects particularly well on Dropbox - it's far off the tone of the rest of the post, they would have been better off not mentioning it at all.
Not all companies have the big tech or mid/early stage VC money to throw around. Who knows what kind of other tech debt Dropbox has accumulated.
It says "He has already put into motion the conversion of the Dropbox server code from Python 2 to Python 3. "
"already" refers to "sometime in the past 6 years".
Perhaps it’s already done, in which case this word choice is poor.
He also spent large amount of time working on mypy (type checker) which my understanding is also is used for the migration to address unicode issues.
Fundamentally the issue is that the Python language is too dynamic for static analyzers to fully understand the code and perform conversions. I'm not just talking about type systems, but also monkey patching, reflections, etc.
What we really need is a tool that runs your Python 2 code, records types and other dynamic manipulations, and then produce Python 3 code. But I'm not aware of such a tool.
[1] https://github.com/dropbox/pyannotate [2] https://github.com/instagram/MonkeyType [3] https://github.com/google/pytype
That's a great idea, but it sounds pretty intense to implement. I ended up becoming addicted to ML-family languages pretty early (Scala, F#, OCaml, Rust) for a variety of reasons, but I never fully grasped how much strong/static types help for refactoring until I tried refactoring some Ruby code. I can't imagine trying to write an automated tool for the task.
For example in python 3 they actually made import statements more predictable they are now absolute by default, it was a bit ambiguous in python 2. Ignoring the ambiguity (which is a problem by itself) some people were creative and instead doing standard imports like god intended decided to do it dynamically using importlib, that can't be easily fixed if the file you're importing is a variable.
Another problem: unicode, actually most python 2 code is broken and it can crap out whenever you use characters outside of ascii. That's because it conflates bytes with text, python 3 makes the distinction strict, so you have to properly address it. Though for 99% of application user meant text, so perhaps this assumption could be made?
- division, in python 2 division worked similar to C, if both the parameters were integers you get integer as a result, python 3 changed it to be more what most people would expect, although python 3 also introduced // which had the prior behavior so I guess this could be automated
There are probably others too.
Dropbox's server code base is literally millions of lines of Python 2. The "stop all development" approach simply won't work there. The only thing that works is to port the whole code base to "straddling code" that works on both interpreters, then switch interpreters. Automated tooling to prevent regressions is essential.
People migrate when the allure of Python 3 outweighs the hassle of juggling 2 versions. Naturally, people who grew up on Python 2 are more hesitant than people who started later on Python 3.
I wonder what "retirement" means for Guido. The Python/software community could never hear from him again and he'd completely deserve the rest (and we the community would be immensely grateful for the work already poured in), but I get the sense that won't be the case. :D
No it's not. Significant whitespace, underscores that mean things, lack of type system (but people treat variables as typed anyway), et all, make it quite a difficult language to understand. And we won't get into performance problems that it's cult following turns a blind eye to.
I will say Python has inspired a generation of languages that got away from the C-inspired syntax. We're moved to critically thinking about _why_ we write code the way we do, rather than simply accepting things because "that's the way it's done" and for that we owe Python a great debt.
I won't defend beauty, as that's extremely subjective. I happen to find the whitespace significantly more intelligible than nested braces and parens, but that's me. I know plenty of people who strongly prefer to have braces and parens, so no argument from me.
Everyone loves to bring up performance as a huge drawback to Python, but it never holds up as a fundamental problem. Yes, that means for specific problems, it's not suitable. But the same can be said about many languages. Fortran is a horrible language to try and build a web framework on top of. Lisp is a bad language to write an OS in. Programming languages are tools, choose the right one for the job.
If you need blazing fast processing of numerical data, choose the proper tool. If you want fast iterative development with a broad set of packages and an active community, Python is a suitable tool.
I do agree that the growth in new languages is amazing, and greatly welcome them to the the toolbox that is programing and software development.
Beg to differ. Lisp machines were huge, back in the day, and there are still hobbyist projects like https://github.com/froggey/Mezzano
There's a reason why most OSes are not written in Lisp, and it's not because the OS writers aren't smart enough to learn Lisp. It's not because they don't know it exists. It's because there are better languages to write an OS in.
This is different from someone working on an OS in, say, C. They just pick some C compiler and use it, without becoming a C researcher and implementor.
(They might bemoan some things happening in the development of the compiler they are using that affect their work, but not actually take that on.)
OSes aren't written in lisp because lisp isn't terribly popular, and subset of lisp programmers who are interested in OSes is pretty small--this is a much more interesting factor to look at than subset of OS programmers who are interested in lisp.
Given that it's been decades, I think it may be safe to say "If Lisp were a good language to write an OS in, we'd see more than hobbyist projects and the Lisp machine companies would still be offering them."
(The need for garbage collection caused a bit of a stumble for the Lisp machines on the market, if I recall correctly).
' 'Of course there is issues, as there is with ANY language.
Stop these silly language wars...
Since then I've watched people use it as an application or systems programming language and I don't really get it.
To me it's a great Swiss army knife scripting language.
But yes, I think you're right. There are far more "elegant" programming languages. I never got the sense that that was Python's niche, though.
"Intuitive" is a word for "stuff I already know". Symplectic geometry is unintuitive until you learn it. Learn stuff.
Python has a type system. The types are on the objects, not the variablenames. If people threat variables as types then it's their misunderstanding.
That being said, simple static analysis definitely has its advantages, but it's not so useful that it needs to eat the world.
Unlike say, for example...?
Python 3 has introduced syntax to optionally declare types in the source (type annotations). This does not affect the runtime. Mypy is a program that does static analysis to tell you where your code is inconsistent with your type annotations, so:
a: int = "foo"
I don't hate python just lazy windows ports.