Slashdot Mirror
Python 3.6 Released (python.org)
On Friday, more than a year after Python 3.5, core developers Elvis Pranskevichus and Yury Selivanov announced the release of version 3.6. An anonymous reader writes:
InfoWorld describes the changes as async in more places, speed and memory usage improvements, and pluggable support for JITs, tracers, and debuggers. "Python 3.6 also provides support for DTrace and SystemTap, brings a secrets module to the standard library [to generate authentication tokens], introduces new string and number formats, and adds type annotations for variables. It also gives us easier methods to customize the creation of subclasses."
You can read Slashdot's interview with Python creator Guido van Rossum from 2013. I also remember an interview this July where Perl creator Larry Wall called Python "a pretty okay first language, with a tendency towards style enforcement, monoculture, and group-think...more interested in giving you one adequate way to do something than it is in giving you a workshop that you, the programmer, get to choose the best tool from." Anyone want to share their thoughts today about the future of Python?
You can read Slashdot's interview with Python creator Guido van Rossum from 2013. I also remember an interview this July where Perl creator Larry Wall called Python "a pretty okay first language, with a tendency towards style enforcement, monoculture, and group-think...more interested in giving you one adequate way to do something than it is in giving you a workshop that you, the programmer, get to choose the best tool from." Anyone want to share their thoughts today about the future of Python?
Perl is great for people who tend to be more "verbal". The total math geeks I know really prefer python, though.
It's wonderful that we have such a joyful abundance of tools to choose from in the FLOSS world, and aren't stuck running VB.net or whatever the craptastic commercial product is these days. Be maximally productive and we can all be happy for that.
Now let's work on getting these things coordinated so I can use a python module in perl6 and the ruby folks can use a perl6 module on rails. That was one of the great dreams of the perl6 project and it doesn't seem to be effective yet.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
Python enforces a single form and this is its strength. It makes everyone write readable code. I know this vexes the special snowflakes but it is for the greater good.
Syntactic whitespace makes me twitch, too; but it neatly resolves many of the codestyle hubbub issues you see in other language environments.
If your editor helps you do the right thing, it's just an aesthetic whine, and shouldn't be worth arguing about.
That summary is pretty inflammatory. "New Python: Also, some people say Python sucks!"
What Larry sees as a virtue of Perl, the fact that it gives you myriad tools to accomplish your tasks, many see as over-complicating the matter. You can certainly do whatever you need to get done in Python (duh), but the Python folks pride themselves on giving you a good way. It's just a different approach to language design.
A (possibly) overwhelming everything-and-the-kitchen sink? Or tools crafted by experts? Personally, I love Perl, but there really doesn't need to be this counter-productive contention between the different approaches.
IMHO, curly braces are braindead (unless used in a math context to denote sets, which is the one true way). Now can I also get a +5 Insightful for my equally valid personal opinion?
Escher was the first MC and Giger invented the HR department.
Most written languages do exactly that, why not Python?
It works just fine as long as you're not silly enough to use a word processor as a text editor.
And if you're sensible enough to use tabs, you can even change the spacing to suit personal preferences and visual acuity.
Indentation improves readability. but the problem with using it to directly delimit logical blocks is that humans don't actually directly read whitespace, there can be something syntactically wrong with a program that is not visible to humans reading it because of a line that had a tab character in it instead of spaces, or vice versa, for example. While you can always convert tabs to spaces or vice versa in certain editors, this constrains what editing environments one should develop in, and ideally, languages should be designed to be agnostic to what features should necessarily exist in the editing environment that the programmer chooses.
And related to this, doing python development, I cannot count the number of times I have accidentally had the wrong number of spaces on a line following an indented block, and at best the python environment complains about indentation levels right away, and at worst the mistake is not realized until I find that the program is not behaving as I intended it to behave.
And while I do maintain that practical programming language should not depend on the features of the editing environment to be practical, at least it is *FEASIBLE* for an editing environment to enforce strict indentation policies when the programmer has explicitly specified where each logical block begins and ends, so the claimed advantage that python has of having whitespace be significant to the syntax of the program somehow actually improving legibility is not that important in the long run, since source code that uses explicit delimiters on blocks can easily be run through a pretty-print filter, so python mandates that programmers do something for themselves that a computer is far more capable of doing reliably and consistently. Even at best this is a waste of a programmer's time.
While the intent behind it was laudable, in practice it's just not a very good idea in a modern language. It kinda reminds me of COBOL, to be perfectly honest.
File under 'M' for 'Manic ranting'
The language changed for virtually no reason/benefit in Python 3 and they broke backward compatibility. Worst of all, no automated means of reliably porting 2.7 code to 3 was provided, and even today, there is no reliable means.
Developers stuck with 2.7 to maintain compatibility and then continued further development in 2.7. Thus creating an even larger body of work that doesn't run under Python 3.
It was a massively stupid decision. But, I expect nothing less from those that build a language whose code can completely change functionality by simply misplacing an invisible character(space). Said character itself often makes up 20% of the frickin code!
Using tabs for indentation is a mental disease. Also, PEP 8. Tabs are not Pythonic and should not be used. You're free to torture your programming language however you please, but if you expect others to respect your work, you are advised to adhere to the rules.
Using tabs for indentation is a mental disease.
Um, why? Tab exists solely to provide indentation.
If you don't like it, it's easy enough to fix. You can use an editor macro to "compile" your Python-with-braces to Python, and de-compile other peoples' Python to your Python-with-braces. that would correct what you see as "wrong" with the language but maintaining full access to and compatibility with the entire Python software ecosystem.
In my view the braces/whitespace thing simply isn't such a big deal. It's just a lexical convention. It's an interesting gimmick; what C programmer hasn't encountered some brain-dead indentation that obscures the actual structure of the code? But that's easy to fix, you just pretty-print the file. I guess the problem is when pretty-print reveals a really overblown control flow, which making code formatting lexically significant discourages. But in practical terms coders who are so bad as to generate that kind of stuff will find some other way to make your life miserable.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
With sufficient motivation, I can write unreadable code in any language no matter how it's indented.
> because of a line that had a tab character in it instead of spaces,
This is exactly why you should configure the editor to visibly show tab characters (in colour for example) and to replace tabs with spaces. If it can't do that then get a better editor.
> Even at best this is a waste of a programmer's time.
Then don't use Python, nobody will care that you use Perl or Ruby instead.
There's a third option here: why is this a thing? Why hasn't this been abstracted out into a middle layer pre-compilation markup layer so your IDE can switch to whatever suits your fancy?
Why are these pointless, subjective arguments over syntactic sugar still happening? Why the hell is human readable plaintext the target medium of exchange here? It's not like a this would be incompatible with plaintext; conversion both ways would be easy enough. The guy who insists on using nothing but notepad could keep doing his thing; you'd just have to convert everything to text (using his preferred style) before sending it to him.
This doesn't just solve the immediate, practical issues of different competing preferences; it also has interesting theoretical effects in that people are forced to think about what counts as syntactic sugar and what counts as actual compilation--what should happen when, and why? What are the differences between languages that truly matter?
Have you actually read PEP 8 or are you just throwing it out there?The intro to that PEP goes to great lengths to explain that it is the preferredstyle guide for the Python Standard Library, thatother coding standards are OK, and that you should always adhere to the coding standards any given project uses. It is not some sort of dictatorial manifesto that ALL PYTHON SHOULD BE 4 SPACES.
Enforced indentation enhances readability. Perhaps you've never run into any godawful code where the programmer decided to follow his own arbitrary indentation system.
You don't have to do everything on a single line in Python. Where'd you get that idea? You can split statements across lines just fine. Most Python programmers do so.
Python 3.5 got async, await key words and has had proper OOP for a decade, things JS is still trying to get into the language. The one downfall of python is JSON object literals aren't as easy as in JS.
If more node devs found out about Python's Tornado, they'd probably pick Tornado.
Slashdot's rate-of-post filter: Preventing you from posting too many great ideas at once.
The point is that most languages don't need motivation, let alone sufficient amounts of it to do what say.
First, I know Javascript is wildly more popular as the language that runs everywhere, but it's not what most people use when they're writing a system / glue script - though some people do, they've got a hammer.
Python's the utility / glue scripting language of choice precisely because it's READABLE - it doesn't have nine different ways to do everything like Perl does which makes it less expressive but more comprehensible and maintainable. You can definitely bang stuff out faster in Perl, but you can come back to the Python four years later and easily figure out what it's doing (just did that recently, fixed a large four year old 2.x script for new requirements and features and upgraded it to Python 3.x in a day, most of that testing), or grab someone else's Python and maintain it with reasonable effort unless they were seriously defective. Terrible programmers can write Perl in Python, and great programmers can write very maintainable code in Perl, but the language heavily skews the odds.
Remember when Ruby briefly seemed like a contender for Python? Well, it was neat, and decent enough (I used it), but it had too many perlisms (punctuation vomit syntax) which made it similarly not so readable, and then all the magpies flew away to the next hotness and I went back to Python as more maintainable - and more capable because of the strong library support. And now Ruby is just 'That language you use for Rails'.
Similarly, people like to bitch about the whitespace, but it forces readability. Perl people considered cramming 5 or more lines worth of Python on a single line a bragging point, and it was when vertical space was limited, but it's hell for readability and maintainability and we've got big monitors now. And if you have any code skills at all the whitespace is not a problem - I do Python, C#, C++, bash, Haskell, ASM, and VHDL - all wildly different, and the biggest problem is remembering how each does '# of items in a collection' (Count? count? Count()? Length? length? sizeof()?) - whitespace is not even on the radar.
A more valid complaint is that Python has relentlessly marched towards cleaning itself up even if that breaks compatibility - it is not afraid to clean up terrible mistakes it has made (usually on new features) rather than leaving them in forever for compatibility reasons like bash has to. I know that's a big sticking point - it can be jarring when old code breaks, but locking old code you don't have the time to maintain to a specific version has worked pretty well for us. Mostly that's just segregating things as 2.x or 3.x. Code we have kept up to latest version has improved as a result as the language improves.
Biggest weakness - the lack of compile time checks due to strong but dynamic typing continues to be an Achilles heel for any large project. Python (and other scripting languages) just aren't suited for that and we don't use it for that. Use something with static compile-time checking like C# or C++ - yes, after all my kvetching about readability we still use C++ for some things because nothing else fills its niche.
Because human readability of code is much more important than machine readability of code. With a suitable parser, the machine will be able to read the code. The art is in creating a language in which the program is obvious to many humans, not just the person who wrote it.
IMHO Python is on the right track for that. The best way to ensure all programs written in a programming language are readable by many people is to have the language enforce a uniform style, with a take-it-or-leave-it attitude. People who don't like the language-author's enforced style conventions can use another language. Programs written in the language will be reliably readable and maintainable, and that's way more important than giving freedom of artistic impression to the program writer.
Where are we going and why are we in a handbasket?
Python will immediately complain about mixing tabs and space. Other languages won't, but your code just became unreadable. I know all about that because my coworkers do it constantly. I realized tabs were a bad idea 25 years, and the company I work at now is the only place I've ever worked that uses tabs, and it's been nothing but trouble, but no one wants to change anything.
You are in a maze of twisty little passages, all alike.