Happy birthday, Python, you're 30 years old this week: Easy to learn, and the right tool at the right time The 30th anniversary of Python this week finds the programming language at the top of its game, but not without challenges. "I do believe that Python just doesn’t have the right priorities these days," said Armin Ronacher, director of engineering at software monitoring biz Sentry and creator of Flask, the popular Python web …
30 years is a great achievement - we should push for a special anniversary edition of Python to be released in celebration.
Following the naming convention used for wedding anniversaries, this could be called 'Python Pearl Edition'.
I already can't wait for the 40th anniversary and 'Python Ruby Edition'.
This post has been deleted by its author
Reposted to correct a slew of grammar errors I made...
Python is indeed a great language, but I do agree with Armin Ronacher in that some off devisions have been taken or are being taken are quite strange, and the community sometimes reacts very oddly (e.g. the vast amount of navel-gazing over the := operator).
Here's some the decisions I don't get:
1. The whole unicode thing; just store strings as uff-8. Literal indexing is slower for sure, but what's the proportion of code that does this vs iterating (and startswith/endswith can be iterator based) vs not doing any of this at all?
2. await and async are lovely and welcome, but the implementation of asyncio and its api is horrible - copying Twisted was not a good choice; copying Twisted is never a good choice. And the mess involved whenever sync code needs to call async code (i.e. an implied, or otherwise, await) is awful, essentially splitting a codebase in two and requiring async and sync versions of everything.
Every time I look at Curio and Trio I see what a missed opportunity all of this was. Ever tried to step through the event loop or follow any asyncio stack trace? You know what I mean then. The wrong people implemented asyncio in Python.
3. The proposed match statement is nice, except it seems a mishmash of re matching, literals and instanceof checks which will clash horribly with function calls in case statements. And why case _: instead of else:?
4. Why all the time and effort spent on the typing module and annotations without supplying the obvious use case - type coercion? (I ended up writing this for my own projects and it wasn't pleasant, although has been very useful from time to time).
5. The GIL. Just fix multithreading. Everyone else has; enough with the excuses about incompatibility. Py2 to Py3 shows such a compatibility-breaking can be made if done for good reasons and done with care. So much great work has been done in Linux and Windows to address scalability via threads and the Python folks appear to have just said... no... not for us.
(Full disclosure: I have had no involvement in Curio or Trio - I just wish I'd written something like this because they are both very, very elegant.)
Interesting that the article mentions ease of extensibility (at least in earlier versions). That reminded me of Tcl, which I had almost forgotten about. Needed to do a cross platform utility back in the late 1990s, complete with GUI. At the time I knew Perl, but the Tk module was Unix only.
I was aware of Python, but was put off by the forced humour in the documentation and books as well as the significant whitespace thing. (Perl suffered from Larry Wall's bizarre humour as well).
So I took a look at Tcl, which was where Tk had originated from and had a beta for Windows. The C source code to Tcl itself was beautiful, and where the language lacked performance it was so easy to extend with C code.
Whilst I have found Tcl more useful than Python and Perl, it does majorly suffer from the fact that only primitives can be returned back from functions. This means no arrays and worse, no structures can be returned. You instead need to pass the structure to be populated in as a parameter. Which has a knockon effect for structures inside structures. Awk suffers from this issue too.
That said, I do really like the layout system for Tk. I use it mostly from Tcl but it is also fairly well bound to Perl and Python.
Weirdly all we have for C++ is this which has never hit off (even though C++ gui libraries on the whole are terrible): http://cpptk.sourceforge.net/
I have never created or even seen a bug caused by python using the quantity of white space to indicate the start and end of a block of code. Seriously never in decades.
At best missing a { or } in C/C++ causes a compilation error reported at a line utterly unrelated to where the problem is. If the mistake is in a header file the compiler can report multiple different problems in different source files - none of which are the right file to correct. The actual error message hardly ever mentions { or } and it takes years of experience to relate the many possible cryptic messages to the actual cause of the problem. Even when the correct cause of the problem has been conjectured finding where the problem is takes time. Ironically, one tool to partially automate the process is GNU indent: mechanically arranging to the amount of white space to match actual use of braces bounds the flaw to the right function (if you got the right file) by making the block levels as clear as python.
Finding a missing { or } is such a time sink that I minimise the possibility with self discipline: always type the two together then insert the code block between them. Likewise only ever put a statement where a block is permitted if it is astoundingly obvious that even after a thousand years no-one would ever consider the possibility of adding another statement. That limits the chances of the far more nasty problem: a code sequence that is completely valid to the compiler but the indentation implies different flow control to the programmer compared to the actual one that the compiler will see.
I massively appreciate the herculean effort compiler writers have put into improving C/C++ error messages. Imagine what they could have been doing instead if this were a complete non-issue like python.
What is it about making the flow control of a program appear identical to programmers and interpreters that makes some people turn up their noses and walk away?
Is there a difference in Python between an indent caused by a tab, an indent caused by a space, and an indent caused by multiple spaces (or indeed a combination of the above)?
Or to put that another way: if the statements are aligned on my screen, irrespective of how they're actually generated, are they aligned in the interpreter?
I was exposed to a Python course many years ago, and quite enjoyed it, but I do recall I was careful to use only tabs and never spaces for formatting.
The style guide recommends code blocks are indented with a multiple of 4 spaces and that tabs should only be used for existing code that consistently uses tabs.
Python2 accepts a mixture of tabs and spaces. If your text editor is set to tabs every 8 columns then appearance and behaviour will be the same. The style guide recommends using -t or -tt to detect inconsistent uses of tabs and spaces and to fix them by converting tabs to spaces.
Python3 will raise a TabError exception when a source file contains a mixture of tabs and spaces for indented code blocks.
Some text editors and IDE's are set by default to ignore a programmers's clear and explicit key presses and interpret the [tab] key as what it thinks is the right number of spaces. Some people think that kind of blatant disobedience is tolerable.
Thank you.
Not the place to rehearse the old tabs-vs-spaces argument... hmm, I wonder if the Eclipse editor has a mode to always save as spaces, but to handle tabs as tabs for moving around on the displayed text? It's pretty good at working out where to keep the indents, but I don't know what it's actually saving (in C of course it doesn't matter.)
Some text editors and IDE's are set by default to ignore a programmers's clear and explicit key presses and interpret the [tab] key as what it thinks is the right number of spaces. Some people think that kind of blatant disobedience is tolerable.
What rubbish. If I instruct my editor to insert spaces when I press the tab key, or to insert tabs when I press it, or to insert "XPzxY7" when I press it, then that's exactly what it should do.
Who's to be the master, you or the label on the key?
> Some text editors and IDE's are set by default to ignore a programmers's clear and explicit key presses and interpret the [tab] key as what it thinks is the right number of spaces. Some people think that kind of blatant disobedience is tolerable.
'Tab' is short for Tabulate or 'make into a tabular form (a table)'. Program source code is not generally in the form of a table (OK some are, like Assembly or RPG). On typewriters the Tab key causes the platen to move along several _spaces_ until the next 'tab stop'. Having the Tab key move several spaces to the next 'stop' is the correct thing to do.
If you like to have tab characters in your source code and space characters, then don't use Python. Nobody wants to force you to use it.
Mixing tabs and spaces in an ambiguous way in the same block of code in Python results in a compile error.
Here's an example of part of a Python compiler error message from doing this (the rest of the error message would also give you the line number and print out the line itself).
IndentationError: unindent does not match any outer indentation level
For example, if you have an 'if' statement where you indent one line with tab and the next line with 4 spaces, this will result in a compile error even if the two lines line up visually.
Consistency is enforced at the block level, so different blocks can have different indentation without any problems so far as the compiler is concerned.
Mixing tabs and spaces for indenting in Python will work, provided you are consistent within the same block of code.
However, mixing tabs and spaces for indenting in any language is not good practice and strongly discouraged by most people. Regardless of whatever method the compiler uses to identify code blocks, people use indentation as their primary means of identifying what lines of code go together with one another and inconsistent indentation can lead to someone misinterpreting what they have read.
I've waded through the tab and white space thing with minimal comprehension.
What I do remember is working on source code where braces "{ }" enclosed blocks of code, and this seemed a reasonable approach.
I also recall text editors (gvim?) which could highlight code blocks in different colours by matching open and close braces.
Then again, that was a while back.
Irrational hatred? No.
I hate the indent thing for a very specific reason.
I often like to test little fragments of python in the interpreter, to make sure they are doing what I think they are doing before I run the whole script. Being able to do this is one of the nice things about interpreted languages. You can set up test data, run bits of code to see whether it works properly, tweaks stuff, try again with different data, etc etc.
If such a multiple-line fragment is nested (and hence necessarily indented) in the script, when I select out and then paste them into the interpreter - to test them - it complains because there is unexpected indentation and refuses to run. And, naturally, almost everything in a script is indented at least one level.
Of course YMMV. But to me (even if not anyone else) it is essentially a language feature designed specifically to be obstructive to the way I work. I've got no reason to like that.
Oh, thank goodness for the downvote. The scales have fallen from my eyes, and I now see that what seemed like an frustrating obstruction was in fact for my own good, and the irritation induced by it is in fact a good thing.
Of course, a better thing might have been pointing me towards a clever clipboard macro that strips out extra indents, or a more tolerant interpreter variant, or something or other along those lines. But I understand that you have no assistance to offer beyond a simple, single, click.
In vim, this is trivial to resolve:
1. Go to the first line of the snippet.
2. Hit w to go to the first non-space character on the line.
3. Hit ^v, $ to start a block-select to the end of the line.
4. Use j or cursor-down to select the remaining lines. The left side of the selection remains at the column where it started; the right side is at the end of each line.
5. Use "*y to yank the block to the clipboard.
(That may seem complicated, but it's the sort of thing that vim users generally do without even thinking about it. And it's really just 5-plus-number-of-lines keypresses, and there are shortcuts for selecting those lines in many cases.)
Of course, I wouldn't recommend changing what editor you're accustomed to, and I wouldn't recommend any non-vi user switch to vim anyway. It's my editor of choice because I've been using it since the '80s. Unless you're reading this from the '80s, you're unlikely to share my justifications.
And if the interpreter were running in a vim-compatible editor, it would be trivial to shift text back and forth. (You could do that in vim, with block-shift, pipe to external, and a bunch of undo, but that's rather a kluge. Though, of course, you could write a macro for it.)
None of this is likely to be helpful in your case. I'm just noting that it's possible for an editor to make this easier.
Which, really, is just the rather trivial observation that sometimes unrelated tools work well together, and sometimes they don't.
I was of course questioning that statement (having myself come across bugs caused by indenting mix ups, but surely no poster would ever be dishonest), and doing so by attempting to illustrate my point with a series of statements at arbitrary indentation to highlight the ambiguity it creates. The forum software decided to improve on my post by stripping the unnecessary white space, thereby making an even better point about the role of presentation in flow control.
Asserting that a mild objection, and maybe poking a little fun, is irrational hatred and prejudice doesn't make it so. It does make you look a touch irrational though.
Oh hey, just spent a bit of time helping someone out with a scrap of code I sent them last night which they couldn't get working. Turns out that copy and paste of my solution from email somehow screwed up the correct indentation while looking correct, they tried correcting it and couldn't get it right. They're not a python expert, so I'm sure it's one of our faults that this happened somehow rather than an issue with any language decisions.
I'd agree whitespace doesn't cause bugs. But it makes the editor experience more clunky, because the editor has to infer when a block ends.
Imagine you are copying a piece of text into a function, behind a for loop. Your editor doesn't know whether you are pasting at the level of the function or the for loop. If it gets it wrong, you have to manually re-indent the code. That's fine is the pasted cost is all at one level, but if it includes indented blocks itself, that can break as well but not indenting correct. Still at least it is not all bad. You used to be able to mix tabs and spaces; I used to do this in an exercise with my students -- the code only ran if it looked badly indented. Python3 has killed this off, I believe.
With other languages there is an explicit start and and explicit end. Of course, there are famous bugs where white space indentation and blocks were mismatched. Python's approach sought to avoid all of those which it does. But that was 30 years ago. No one indents their code nowadays.The IDE does it. And, in languages with good tools, you run the code auto-formatting tool and lint check in your git hooks/CI.
It's not a biggie, it's a not a disaster for python and it's now not worth fixing. But, while it was an interesting design feature of the original language, 30 years on, it is clear that it was a mistake.
Wasn't sure where to put the reply as several people get frustrated by their editor of choice being unhelpful when it is time to change the indentation level of some code.
I am very old. Back when computers were made flint chips the first text editor I used had some very handy features that I did not find elsewhere when I was selecting an editor for Linux. My personal "learning to do something non-trivial in C" project was a text editor and I put the features I liked into it. Specifically:
^u: Start making a new record of key presses
^v: Stop extending that record of key presses
^p: (Includes an implicit ^v) Play back that record of key presses
So when in python the sequence [home]^u[space][space][space][space][home][down] followed by holding down ^p adds a level of indentation to a code block. Likewise the above with [space] changed to [delete] removes a level of indentation.
I can see that without basic features of tools from the '80s mixing python indentation with modern IDEs can quickly lead to frustration.
Thanks to everyone who actually explained what the problem is.
It's really nothing to do with the IDE. It's a fundamental problem that the ending of a block is implicit. No editor can ever no with certainly while moving text, where the end of the block is, nor where you as the user intend the end of the block to be.
Curiously you see the same problem in Word. If you have a piece of text in Italics and you cut and paste this, or paste any text to it, you cannot tell Word whether you have intend to be inside the end of the italic block or past the end of the italic block. Now in the case of Word, there really is an end of Italic thing in the data model, but it makes no difference at all, because you, the user, cannot see it. You cannot tell Word whether to include it or not and Word cannot tell you whether it has included it or not.
Practical upshot, sometimes when you cut and paste, suddenly a pile of text will appear in Italics when it shouldn't or vice versa. It's an inconsistent user experience and that inconsistency is irritating.
I don't use a modern IDE. I write code in Emacs or Vim, both of which are forty years old.
Some pre-historic (before mice became ubiquitous) word processors had a switch to display start and end markers for things like bold, italic and paragraphs. I do not know if any of them handled cut an paste of such marks well but they would have been useful for selecting the intended insertion point. IIRC early versions of Word had such a switch. I have no idea if the switch was removed or just buried deep in the an obscure part of the UI.
I was involved with desktop publishing from the early days of desktops so I saw WYSIWYG for the mixed blessing that it was. After one attempt to do a large document in Word I retreated in terror back to LaTeX and later switched to ReportLab (Python library for generating postscript).
Such tools have a high entry cost but have proved worth the effort in the long run. A consequence has been that I have become so thoroughly accustomed to modifying plain text efficiently that I have not noticed the problems others are now identifying with python's use of white space.
I have never created or even seen a bug caused by python using the quantity of white space to indicate the start and end of a block of code. Seriously never in decades.
I have - once. The circumstances was: a developer was adding some new feature to a section of code, whilst at the same time another developer finished adding a safety check to the same section of code. The safety check added an if clause, and was merged to master first of all, and when the second developer merged those changes in to their changes, they didn't examine the conflict carefully enough and left their additions at the same indentation level as when they wrote it, when they should have been inside the new if statement.
It was caught in review, although the "safety check" developer was asked why they hadn't added a test that exercised the "safety check failed" branch of the code, which would have failed when the "new feature" developer had finished their merge (and I enabled branch coverage to make it clear that just hitting every line once is not full coverage).
The reason I like it is I have to write code professionally with Indian co-"workers"
Thus the Java and SQL code I see is literally randomly indented, making it very very hard to follow. Any attempt to clean up gets "oh that'll break our source control 'tools'" from management.
I spent a day properly indenting an important Java class, only to get it rejected in code review "because it's too different!" when it was actually the same code, only indented.
Fuck that shit.
I would agree that it is a once or twice per decade event. The cost of failure is sufficiently high that programmers quickly adopt a discipline to make it really unlikely. When it does happen the compiler's error messages will have changed beyond recognition so the cost does not come down far with experience. Just think of the effort compiler writers have put into helping you with a rare but problematic event that could have been applied elsewhere.
"The cost of failure is sufficiently high that programmers quickly adopt a discipline to make it really unlikely"
Whereas Python programmers adopt draconian editor settings to shackle them to someone else's idea of "clear code".
Programming languages have cultures. Guido started off making a stupid mistake about whitespace and then defending it against all rational argument. Naturally enough Python today is dominated by people who stand by their mistakes against all rational argument and the language is a pig as a result. Backward compatibility is not a consideration so even the version numbering is broken. But any discussion just meets the same old Python response: "You don't like it because it's different; you are stupid and we are geniuses".
Python is pollution.
What would happen if I did CTRL-A and SHIFT-TAB a few times to remove all indentations?
How would Python reactive that?
How would you fix the code if it wasn't backed up in a repository?
I would genuinely like to know. I see this as a design flaw in the language if you don't have some sort of end block marker/statement to mitigate these kind of mistakes.
"I have never created or even seen a bug caused by python using the quantity of white space to indicate the start and end of a block of code. Seriously never in decades."
That doesn't change the fact that it's a mind-numbingly stupid idea. Also, I don't believe you.
It took me years to warm up to this language. It was difficult to accept indentation-as-syntax. Once I did, it became one of my two go-to languages (C++ being the other). Prior to accepting Python if I needed to prototype an idea or write a moderately complex script I would use PHP CLI, which remains a good scripting language IMO.
Armin Ronacher's complaints are all centred around his point of view as the developer of a web framework, rather than taking a broader view of how Python is used across many fields.
His complaint about async IO will be related to how it has essentially made most existing web frameworks (including Flask) obsolete in the eyes of many users who now want async versions. There are async frameworks, but established synchronous frameworks with a lot of legacy code are struggling with how to integrate the concepts into their existing code bases that weren't meant to accommodate it.
Python has had async since the 1990s as a library, but various web frameworks created their own version for one reason or another and then monkey patched Python to support it. As an aside, Python Twisted was the inspiration for NodeJS.
Van Rossum decided that the proliferation of third party async libraries was a problem because it limited the degree to which one could mix and match third party libraries. He therefore created a set of new official Python async mechanisms which the third parties were encouraged to use instead of their own custom ones. This has proven so popular that anyone who isn't "async" these days is perceived as being uncool, and so the complaints are coming out from the established non-async frameworks about async.
As for packaging, most Linux distros ship Python by default and most people that I am familiar with use their Linux distro packaging system by preference when installing packages. There's no problem with Pip from their perspective because they don't use it, and their sys admins don't want Pip used either.
The main people who complain about Pip tend to be web framework developers who want their users to Pip install all the bleeding edge versions of all possible dependencies instead of the supported ones in their distro. If you really insist on doing that though then you should be using containers.
The actual main reason however that Pip isn't part of the default Python package is because the Pip developers want you to always use the latest version of Pip.
If I had to actually pick a number one thing that more Python developers would like to see fixed with Python than any other it would be to ship a more modern default cross platform GUI package for it than Tkinter. That's not the sort of thing that concerns web developers such as Ronacher though, so it won't make his list of issues. I see that as a bigger problem than improving packaging (which I have no problems with) or anything else he listed.
I've no problems with Armin Ronacher by the way. I'm just pointing out that he has a particular viewpoint which is shaped by his personal experiences but which may not take into account the many other points of view which have to be taken together to get a reasonable compromise.
As for packaging, most Linux distros ship Python by default and most people that I am familiar with use their Linux distro packaging system by preference when installing packages. There's no problem with Pip from their perspective because they don't use it, and their sys admins don't want Pip used either.
This is okay, provided you only want to use libraries and programs that have been packaged by your distro. However, once you need to use other software, particularly more than one piece of other software, with different ideas about what versions it wants, things get a bit more complicated. Additionally you've got people who need to develop the things you are actually using, a handful of people who need to both use and develop things, and people who, for reasons best known to themselves, insist on using Macs.
As a Python application developer, the only thing I want from the system is python itself. Every other package, I want complete control over the version used - and that's why we have virtualenv. System python packages, IMO, are just for python system applications.
As a Python library developer, I don't even want the system python. pyenv supplies the array of python versions that I'll test with.
As a Python app operator, I don't want any of that, the app should be bundled in a docker container based on python{ver}-slim-{latest-debian-release}.
I normally apt install the packages that I use, including libraries. The distro maintainer takes care of ensuring that dependencies are consistent.
This way I don't have to manually keep track of which version of which third party library had an unpatched security bug which the author couldn't be bothered to fix because he fixed it in another release three versions later. Once you start doing your own mix-and-match of different library versions you take a huge security testing and maintenance burden upon yourself which few developers have the resources to do properly.
I do use projects that I pipped from Pypi and I have projects on Pypi, but when I use libraries from there I am very selective about which ones I use, and only use them when I have assured myself that they aren't in the distro repository.
We've recently (finally!?) got to the point where we have built some in-house Python to be deployed to a standalone dir, to be targeted by the application guys who can then use virtualenv etc and pip to their hearts content.
This then frees us from the un-endying nightmare of the same application lot complaining about what the OS-provided Python was or was not providing.
Unfortunately it still hasn't quite got rid of the same asking for the very latest version of Python for the reason that it's the latest not that they actually need any of those features. Yes, we could indulge them, but then we'd end up with a never ending amount of Python versions to keep under control to make InfoSec happy.
The thing we're still working on (and it's for an academic environment where people justifiably need to run a whole lot of different things, some of which they are building themselves, so locking everything down is not an option), is a core console profile which sets up the preferred environment (including Python and the 'production' libraries). Then for python use conda environments (could do virtualenv instead, we happen to be using anaconda), some pre-defined and installed for tasks. The missing piece is a conda-activate-like command that will switch between base installs, not done yet but should be relatively trivial, it's just not provided by core anaconda.
For anything that needs to be run in a stable configuration it gets stuck behind wrappers that set up the environment first. Docker or other containers would work here too, we just haven't needed to do it yet.
<rant>
I’ll start looking at it when execution is no longer dependant on whitespace
Most other languages from smart people strip whitespace and rely on things that the programmer put in that other people can read. You use whitespace to make it readable in the editor only, not to effect how the code actually executes.
Imagine if the next generation of CPU designers considered adding a bunch of whitespace dependant jumps for example, I don’t know, perhaps a relative jump that it dependant on the amount of whitespace or how bold the characters are in my source code. They might get into compatibility problems though when they consider how bold whitespace should be handled. There are no such issues when the operators are visible.
</rant>
Your CPU design straw man is utter drivel on every possible level. CPU designers get as far as selecting the bit patterns for the op-codes that make up machine code. You are thinking about assembly language that an assembler program converts into machine code. Some CPUs have had multiple different assembly languages that convert to the same machine code. The standard for just about every language is plain text created by a text editor. Text editors do not have the concept of encoding bold into a source file. Some use bold for syntax highlighting but that is not something a compiler, assembler or interpreter can see.
The first law of databases is that when the same information is stored in two different places at least one copy is out of date. C/C++ mark blocks of statements to the compiler by enclosing them in braces. By custom, white space is used to make blocks of statements clearly visible to humans. Ideally the same information is encoded by braces and white space. In the real world, at least one copy becomes out of date leading to a mismatch between how the compiler and a programmer consider the program should behave. This is followed by surprise, bad language, the gnashing of teeth and missed deadlines.
Python uses the same white space decisions programmers use to make source code human readable to mark blocks of statements to the interpreter. As the information is only encoded by one mechanism it cannot become out of sync with another mechanism. Human readability is preserved with the benefit of preventing a large selection of bugs and syntax errors that are a pain to deal with in C/C++.
If you have an actual reason why python's use of white space is a problem please present it without false analogies or straw men. I am genuinely interested but so far no-one has been able to provide me with any good reason for their irrational hatred.
I like python, but the white space is frustrating. It's fragile to moving code blocks or copy and paste. Making changes to code flow involves changing block indents directly and often results in re-editing lines.
White space is presentation. A decent editor can re-indent according to syntax for you, and lines can't easily slip past braces when editing, but indentation can easily change.
This means in other languages white space is not a duplication of the information braces provide, it's a visual parity check.
@ibmalone:
it's a visual parity check.
But that's exactly what it isn't in Python, and for a very good reason.
In pretty much every structured-programming language, starting with Algol 60, there's no enforcement of indentation to correspond to nesting levels. The good old Burroughs Algol compiler, for example, would merrily say "semi-colon expected" right under a semi-colon, and 99 times out of a hundred, the correct action was to insert a semi-colon somewhere else in the program. Whether or not it was correctly indented didn't help at all, and incorrect indentation (which was common) made it even harder to find the nesting error.
By making indentation part of the language syntax, Python completely abolished that whole confusion and made it much easier to find nesting errors, without any need for { } noise characters.
It took me about 2 weeks of Python programming to understand that. Every time I have to manually fix an XML document I wish it used indentation like Python does.
To me it's a solution to something which isn't really a problem. The language syntax determines levels, whether by whitespace or braces, but it can't tell you what the original programmer intended. Python whitespace is more easily messed up than a brace. I write a lot of python, I don't generally have to give it much thought, but it's always there nudging your elbow a little. Sure, the errors will tell you what line has gone wrong, this is rarely a problem, the thing you want to know is what part of the flow does a line really belong to? You don't know because it's absolutely lost. Missing brace or semicolon? Learn to read the compiler errors, get compilers that produce better errors, it's not the 60's any more.
Also, it's likely you don't wish XML had Python indentation because you'd need a second monitor for most of the levels.
When I need to work out what is going on deep inside some XML I subclass a python XML parser and have it throw away most of the document and output only the relevant branch with nesting represented by indentation starting at 0 for that branch.
It would be nice if XML had some mechanism like C's static inline functions that allows structure to be made visible by indentation without needing an infinitely wide monitor. Unfortunately some XML would instead take inspiration from the IOCCC.
@Flocke Kroes.
I think you missed the point about my posting.
But feel free to have another rant. :-)
Whitespace is not part of the code, its for formatting to make it easy to read, nothing more..
Its too fragile if you don't tell the compiler / interpreter where things start and end.
You can agree or disagree, I don't care, but I will not use it until there is some way to express what I want in a portable manner that doesn't depend on formatting.
Now go and read again the point about whitespace, bold and cpu design and you might understand what I'm saying.
I did re-read your post. I think I did not miss the point because there is no valid point in there to miss.
White space is a required part of many languages although only a few draw a distinction between one and several spaces / new lines.
Not being able to indicate the precise division of code blocks is not fragile. It is completely and immediately broken. Python uses a different system to most languages to indicate the start and end of a block of code. It is just as clear to the compiler and more clear to humans.
Python uses the same block markers for humans and interpreters that most languages use to mark blocks only to humans. Those characters (space and new-line) are present in all code pages and required by many languages including C/C++. C/C++ use braces to mark blocks. Braces are not present in all code pages and C gets around that by allowing ??< and ??> or <% and %> instead (much to the confusion of people who think it is safe to put ?? in a string literal or comment). Python uses braces for dictionary and set literals. (Their absence would be inconvenient but not a serious barrier in python).
So it turns out using formatting to indicate blocks is more portable than using braces! (Barely more as porting code to computers that belong in a museum is not an obvious way to earn a living).
The stuff you were saying about CPU designs was an attempt at argument by analogy. Argument by analogy fails when the things compared are not actually analogous. (Not something you are guilty of but argument by analogy is often selected to 'prove' rubbish by deliberately equating things that are not analogous). What you were calling CPU design was in fact assembly language design - very different from and entirely separate from selecting how instructions are encoded in binary or transistors. It was wrong in so many ways that it was not in any way useful as an analogy for anything and was a complete distraction from your point. For example your straw man involved looking for a way to use white space to obfuscate the meaning of a program (a valid criticism of a very different programming language). Python is doing the exact opposite: parsing the precise data that programmers were already using to clearly, portably and unambiguously indicate nesting level (to each other) that previous compilers were throwing away.
You have repeatedly said 'not formatting' but have never given a valid reason for 'not formatting'.
ibmalone indicated that html in general and the Register in particular do not preserve white space making it difficult to publish python code. (For html use the pre tag which fixes white space but does not handle <, >, and & which are popular in many computer languages. The register recognises pre, switches to a mono-spaced font but does not preserve white space.)
A popular problem others have identified is their text editors/IDEs that let them down by not providing easy mechanisms for moving blocks of python code to different nesting depths.
If this is your problem with python fine. It is a perfectly valid criticism. If not, please try to express yourself more clearly and without distracting false analogies.
> As the information is only encoded by one mechanism
And there is the problem - it isn't. There are two mechanisms available: spaces and tabs.
If one of these is eliminated entirely then there is no problem but, unfortunately, some programmers have editors which carelessly allow these to be mixed in arbitrary ways. Having a suitable editor configured appropriately*, and there are many available, that deals with this issue makes the language far more usable.
It seems that all these complaints are from programmers with unsuitable editors or configurations and then complain about the language.
* eliminate tab characters entirely, tab key generates spaces, tab characters made visible, block indent and outdent feature, ...
I recall the time when I had to install lots of modules and base python to get pip or easy_install, but those days are long gone. pip is packaged with the base language since 3.5:
"Whereas a Rust programmer can just download the language and use the integrated rustup+cargo tools for everything, Python programmers need to juggle many different tools to accomplish something similar but those tools are not developed in unison," Ronacher explained. "Unlike all other modern languages, Python also can only load one version of a dependency. This means that your entire software project needs to agree on a compatible version, which becomes harder the larger the ecosystem grows and the faster it moves."
And the requirements.txt withg the modulename==version is just as good as anything I've used anywhere, you can juggle installs with pip uninstall module; pip install module==version.
pip is nowhere near as good as tools used elsewhere.
Take for example, cargo and rust. I download a project, type "cargo build", "test" or "run", and it will do precisely that.
With python no. First, the project may or may not be using requirements.txt because there are several different options. pip, of course, will try to do a system wide install, unless you tell it do a user install. Although that will break if there are already dependencies with a different version number. Unless you use a venv. Which you can set up, of course. Although, if you type "python file.py" in that directory, it won't use the venv. Unless you have activated it if you shell. Or in your IDE, if you are launching from the IDE. But, that's okay. You can use pipenv which does all of this for you. Except for using requirements.txt. And it was a bit broken, although then poetry came along which is nicer, although for some reason still ignored the python version requirements, and now pipenv is better and maintained again, but perhaps poetry is still the way to go.
It works in python. But only just. You need to pick a workflow and then you need to set up your environment and then you need to follow the rules quickly and be able to debug when it goes wrong. I can get it working. But I also teach this stuff to 300 students who never done dependency management before. It's really, really not easy.
No, that's not true. If you run "venv/bin/python file.py" it will run in the virtual env, if the virtual env has been created. And if you have used venv as the file name, which you don't have to. And, of course, when anyone else runs python as god intends using "python file.py", they will get a different experience. Unless you have set up "#!/usr/bin/env python3" in your magic cookie. Although, if are on a shared computer and in the meantime someone has come along and updated your python, you might get a different version of python from the last time.
And so on, and so on.
Almost all of the functionality is there, but it's not bundled and packaged (pun!) nicely. And TMTOWTDI, which is not right. This is python not perl. There should be one way. That one way should be simply and easy. It might help
I have hope. There is pyproject.toml and associated PEPs. But python is way behind the curve here.
C# is everywhere, albeit nowhere near the supposed "current" version as Mono and IL2CPP remain somewhat behind the leading edge.
It's mostly because Unity (and others) chose C# for the scripting language, so that's every major platform, desktop and mobile.
Swift is only on iOS - though it's slowly gaining traction on macOS, it's still way behind Objective C and C++ as it's still missing most of what you need for desktop.
Python is of course massively hampered by the fact Apple have still refused to update to Python 3...
Java decided a character was a 16-bit unsigned integer because Unicode characters at the time were *mostly* in that 0-65535 range. Oops.
And C++ didn't do it any better. It's never really mandated any encoding at all, but decided to sort-of support Unicode by tossing in a a wchar_t type except some compilers decided a wide character should be 16-bits wide and some others thought it should be 32-bits. Oops.
And Windows decided their Win32 API should come in an ASCII and 16-bit *wide* form. Oops. And because Windows used 16-bit wide chars QT decided they should use the wide format internally in their QString. Double Oops.
And of course Python did the same using a 16-bit internal representation.
But they all screwed up because China had a small problem with languages and operating systems *mostly* being able to render their symbols and put their foot down. That 0-65535 is the basic multilingual plane (BMP) but there are others including those holding many Chinese symbols.
So UCS-2 (this 16-bit representation) was kludged into the basis of UTF-16 encoding so that a string could include codepoints from other planes. And there was UTF-8 (8-bit) and UTF-32 (32-bit) representations too which can be losslessly converted between.
So that's why Python, Java, QT and Windows are using UTF-16 internal representation and it sucks. Performance takes a hit every time strings need to be converted. Memory takes a hit from extra footprint. And software suffers from weird legacy edge cases with code slicing through codepoints. C++ did it's usual and just defined even more character types with correct sizes this time and left it to code to use them properly.
As it happens there is a strong case for UTF-8 everywhere (http://utf8everywhere.org/) since it's generally more efficient than UTF-16 even for Asian languages. It seems like languages like Golang, Swift and Rust all use it for this reason and have defined their string / character types accordingly. Aside from having proper UTF-8 / Unicode support these languages treat their source code as UTF-8 too so you can have Unicode characters in strings or comments rather than escaping stuff.
Python+unicode is a much deeper rabbit hole.
Windows joined the unicode party early. They deserve some brownie points for getting much of their OS and applications to use unicode. Their selection of UTF-16 might actually have looked sensible at the time but has not aged well. Unix had something unpleasant before unicode: code pages. They were 8-bit encodings with the lower half being ASCII and the upper half being appropriate to one language. Worked brilliantly until a file or file name went abroad. As Unix something almost tolerable (and there is no autocrat able to demand everyone re-write all Unix software to understand unicode) Linux did not transition to unicode until after the problems with UTF-16 became apparent. When Linux programmers individually put unicode support in their projects they mostly mostly went for UTF-8 strings and UTF-32 characters.
C dealt with this culture split by making wchar system dependant because that was the reality at the time.
The python interpreter is written in C so at first the internal encoding of unicode strings was OS dependant: UTF-16 on windows and UTF-32 on Linux. As you say, changing back and forth between the encodings was a performance hit, but this was thoroughly fixed by secretly changing python's internal representation of strings. Instead of simply creating a new bytes object every time a string gets encoded python instead checks the string to see what encodings it already has and if the right one is not already there the new encoding is added to the string and future calls to encode the string will used the cached version. Likewise calls to re-decode bytes just return a reference to the unicode string the bytes came from.
That was all years ago. I am sure the rabbit hole has got deeper since my last visit to Underland.
This post has been deleted by its author
Python has its uses for quick and dirty jobs and for infrequently run analysis tasks, but too many people try to use it for REAL work on web services and such that won't scale - just flat out WON'T because of the way Python runs. But once someone becomes an afficiando of their hammer, they see EVERY problem as a nail... :(
Python needs lots of work. Since it does not come with Windows OS, there needs to be a compiled version that runs as an executable and does not have to have the interpreter installed. Many places won't allow the Python interpreter to be installed, as a security risk. It also it way too slow interpreted. It needs to be able to make all the normal OS calls, like multi processors, sockets, pipes, etc.
I am the opposite of just about everyone else here, but that's probably because I like assembler.
I have no problem with the indents because they reduce the number of lines of code (cf. Java's doubling of required lines of code and endless scrolling).
I don't like the packaging horrors and versions hell.
I don't like the partial declarative nature and ability to embed function calls in conditionals by way of adding a . to the end. This is not readable, on a level equivalent to perl. Also the order of words in the code just isnt right. Colons are also dire.
Dont forget abstractions in OO languages are a leap of intuition for beginners, requiring a mental age over 12, which counts me out on some mornings.
Constantly inventing languages is part of the endless cycle of IT eating itself. The same has been happening in AI/ML algorithms for the past 40 years.
A friend asked me to help with a pilot for a web app. I quickly modified a server-side Perl on my host to do the job.
User testing of the app worked ok. The friend then said he needed Python to use on the Amazon cloud service. Looked at Python - seemed similar enough to Perl for this use. Then found that Python appeared to have no easy way to do a file lock needed for a semaphore.
AWS expects you to use a serverless piece of python linked to DynamoDB database for that sort of thing. Preferrably with a bit of cache inbetween for more cost. Variables and semaphores are so old-school and way too efficient when you can put 10 billion instructions, a load balancer, filewall and 12 tcp/ip connections inbetween all the parts.
My last programming was about 12 years ago in Perl.
Still probably my go to language for quick hacks of text based data.
I thought I might have a look at Python and downloaded a couple of free introductions onto my Kindle but either I am missing something or they are crap.
So Python 101 please.
Free if possible but I can pay if I have to.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
