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.
I thought so at first too, but enforcing indentation by making it the block defining element increases readability a lot.
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.
Any word on how Trump is going make Python great, finally? Maybe by adding curly braces?
Programming was great when we had GOTO so that's how Trump will save Python from being a LOSER and make it win, win, win until we're tired of it winning
Pain is merely failure leaving the body
Derp!
Der took er berces!!
Derp!!!
Can we please retain "special snowflake" to refer to gender specials and liberal arts majors who think $100k of debt entitles them to a well paid job, and not debase the phrase by wheeling it out every time someone complains.
I use python about once every two years when I have to patch something written in it. Same problem, especially because the function/method names make no sense whatsoever.
Someone had to do it.
Complain some more you special snowflake.
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.
I have programmed in Perl for over 20 years... recently been learning Python and rather like the whitespace and newlines as part of the syntax... economy of expression. Also the OO syntax is less bolt on as it is in Perl and a breeze to implement and remember.
What I don't like about Python is the v2 and v3 scism....
I'm still trying to figure out how the antiamerican 4chan trolls from 15 years ago have become the mainstream opinion of the "patriotic" American right of today.
Fucksakes, I thought the NSA invented reddit to stem that from ever happening.
If you just assume that the US Government, from the highest levels on down, is absolutely determined to fragment and destroy American culture while running its economy into the ground, then the behavior of its agencies suddenly makes a lot of sense. In fact it becomes predictable.
Also, anyone referencing "patriotism" should be aware that a massive PR effort has been made against it. The old definition was "support what is best for one's country". The new definition is "support whatever its government wants". They are rarely compatible.
Why the hell is that? As a Python newbie I never know what to install and configure a new project in. I start with say v3 only to find that some module or framework I need down the road isn't available in 3 or visa versa. Really annoying.
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!
After learning a third or fourth programming language, I think most people don't care much about such cosmetic things. There are much more important pros and cons to languages, and arguing over the syntax is like arguing over the color of a server: outside of very convoluted or extreme situations it doesn't make any difference in the real world.
Nobody cares about HO's. Best keep your personal hangups to yourself. It's like emacs vs vi. Just be happy with what you like.
What the christ does Python's "one clear way to do any given thing" philosophy have to do with using indentation to denote blocks?
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.
In pretty much any other language, you already indent your code to represent blocks. If you don't, it because very hard to read whether there are curly braces or not.
When I first started learning python I also had a knee jerk reaction to the indentation thing, especially because I had used fortran before and I hated it. But after writing a few lines of code, you quickly realize that the indentation is not an issue at all. I was already going through the trouble of properly indenting all my code in C++, java, perl, etc..., so removing the curly braces did not make any difference. They are in fact redundant.
That said, there are a couple annoyances related to the indentation (pretty minor in my opinion):
If you try to embed python inside a template tool, like how you do in php or embedding java inside jsp, then it really gets in the way.
If you sometimes use tabs and sometimes use spaces, it can get in the way. It is best to use an IDE that will enforce tabs or spaces but never mix them.
> What the christ does Python's "one clear way to do any given thing" philosophy have to do with using indentation to denote blocks?
He said "a single form", which does relate to indentation. A single form of indentation that is read the same way by the reader and by the compiler.
But it is also "one clear way", unlike other languages where the 'begin' and 'end' can be done in several different styles, or not at all:
if condition {
action
}
if condition {
action
}
if condition
{
action
}
if condition {
action }
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.
I think you both miss the point; use a real editor and you can press tab and have it automatically use whatever number of spaces you want. Python sets people up with screwy notions because IDLE has all kinds of tab-manipulation functions where you can end up mixing both until you get into a better editor.
Sure, but you seem to have ignored the point I was actually driving at that a modern programming language should not constrain what editing environment(s) a programmer can or should choose from. "Better" is inherently a subjective term that has no discernable meaning in this context beyond whatever editor one is most accustomed to.
File under 'M' for 'Manic ranting'
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?
And before anyone says it, yes I'm aware this poses interesting challenges for certain code-as-data metaprogramming stuff, hence my penultimate question.
>Sure, but you seem to have ignored the point I was actually driving at that a modern programming language should not constrain what editing environment(s) a programmer can or should choose from.
Actually, some of the biggest gains to be had is from *exactly* providing a special live editing environment.
If you don't want to use Python then don't use it. Simple.
But *please* stop trying to get Python to add braces. Just use another language and stop trying to break ours, thanks.
I agree, not an issue. Refactoring and getting the wrong indent level for last statement in "for" loop. Ouch. Many times I 've scooched the last line the wrong indent level on refactor. ha
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.
For a 2 line script, it might be okay, but I work with the beast and it ain't pretty.
I'm more annoyed in that, even if you break things into ridiculously small functions,
the fact that you have to do things on a single line burns me to no end.
Scope by white-space indentation is high-school mentality feature. Yeah, the language
has some good points, but readability and maintenance isn't high on its list of pluses.
CAP === 'grazing'
And if you're sensible enough to use tabs
"tabs vs spaces" is one of the oldest arguments in programming since we moved off punch cards.
And now one programmer immediately alienated half the programming world by enshrining his opinion into the programming language. Nicely done.
"First they came for the slanderers and i said nothing."
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.
Enforced indentation in Python is great, but I have to agree: allowing the use of tabs or spaces was a horrible idea. I assume supporting spaces was a bad habit held over from C.
Another one of the enlightened. People in my lab get a look when I tell them that they will use tabs as indentation. Then they come back and thank me.
Using tabs for indentation is a mental disease.
Um, why? Tab exists solely to provide indentation.
cf.
* https://en.wikipedia.org/wiki/Tab_stop
PEP 8 says that Guido prefers spaces. It doesn't say tabs are bad, and it certainly doesn't say they're wrong. It DOES say mixing tabs and spaces is bad, Python 3 doesn't allow it, and you're recommended to run Python 2 in such a way that it doesn't allow it either.
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.
I seem to have hit a nerve :) Been using Python off and on (more off than on) for 15 years or so and am well aware of the curly braces, um, discussion.
My biggest issue is sometimes when tracking down a problem you want to comment out blocks of code. Easiest is an "if(0){....}", that isn't really practical with Python.
That just breaks things even if you're trying to get it right.
Consider, I see well so I set tabstops at 2 chars on my editor. Except when my eyes are tired and I set it to 4. The next guy to read my code has limited vision and so he sets it to 8 chars (there are many vision problems that make it hard to tell if one letter is directly above another or not).
You realize paragraphs introduce white space, don't you?
Actually, he didn't. Python accepts either one as long as you don't mix them.
Because large-scale infrastructure resists change by sheer inertia. It's the same reason the US hasn't gone metric. Even if the "new" is arguably better, no one likes to fix problems caused by deliberately designed incompatibility.
One of the great strengths of C++ is that nearly any ancient code from decades ago can still compile today on a C++14-compliant compiler. The language committee went to great lengths to avoid making incompatible changes over the years. When there are billions of lines of C++ code out there, that's a responsibility that you need to take seriously. This dedication to backwards-compatibility means that developers have little fear about investing in significant C++ development, without worrying about a language designer that suddenly decides to go in a new direction and break ties to the past, leaving them in a nasty position (especially if your language requires a run-time interpreter).
As you can tell, I'm not a fan of breaking backwards compatibility in languages. If you *must* do it, be prepared to deprecate those features over *decades*, because that's how long things like that will linger around. The Python developers *vastly* underestimated the pain that decision would cause, and the time it would take to get resolved. Apple *still* ships 2.7 on their machines.
Irony: Agile development has too much intertia to be abandoned now.
That's true, I should have pointed my comment at the GP, but tbh I think tabs to the point of indent and spaces thereafter is the proper way to indent things :)
"First they came for the slanderers and i said nothing."
Agreed, that is the proper way to use tab.
I think three single quotes above and below is easier than that.
Excellent, I'm glad to encounter a person with such refined taste as yourself.
"First they came for the slanderers and i said nothing."
Time to dump Python 3.x resume development on the 2.x branch. The ridiculous lack of backwards compatibility hurts far more than it helps.
Fast Federal Court and I.T.C. updates
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.
Before the apologists say you can use Babel, admittedly, you can, but, using such a tool is an admission of defeat. To compile something that is not true JS to something that is JS I would argue is not the original language. It's like using macros in assembly. It may seem pedantic, but pragmatically, Python runs _everywhere_ that C runs*. (Meaning your platform has a C compiler). Comparatively, using JSLint as an example, in order for JSLint to support a particular feature, it must be in two runtimes and at least stage 3 in proposal.
* I'm not talking about browsers, because that's where JS was designed to work. I'm talking about outside the browser, where people are taking JS. And Mozilla did have an experiment about running Python in the browser. And if you want to split hairs: https://repl.it/languages/pyth...
Slashdot's rate-of-post filter: Preventing you from posting too many great ideas at once.
I completely agree. The K&R braces argument has always come down to the fact that people who disagree can just use an editor which shows them what they want to see. Code is a sequence of tokens so why not store it as a sequence of tokens, rather than a sequence of characters.
http://michaelsmith.id.au
Not if there is triple quotes inside the block you want to remove.
http://michaelsmith.id.au
lol it does do that.
http://michaelsmith.id.au
I use python3 as well but there is a lot of important stuff out there which doesn't, like google oauth libraries.
http://michaelsmith.id.au
They exist solely to provide invisible errors in the editor and text processing system of your choice. Tabs are nothing but a really primitive text compression system that should've died 50 years ago.
No, tabs are tabs and nothing else. "Invisible errors" come from handling indentation with spacing, in fact.
Grow up and use tabs, then set the display spacing to whatever floats your boat.
Wrong. That's not what the PEP 8 I'm reading says. As noted.
BTW, I'm nowhere near as diplomatic as Guido. IMO, anyone who uses tab characters for indentation is a moron. I also much prefer 2 spaces to 4.
IIUC, there is a rule against mixing tabs and spaces at the beginning of lines. I think that's a syntax error. This was a problem with Python 2.?.
That said, as I always use tabs at the beginning of lines I've never encountered the error, at least not within the last couple of years. I prefer tabs over spaces because if I start getting deeply indented lines it's easy to reduce the amount of horizontal indentation without editing the lines. (Just change how the editor displays tabs.)
OTOH, I follow this rule whatever language I using. It's not something specific to Python. I feel that a consistent pattern of indentation is valuable in making code intelligible whether or not braces are used...or for that matter begin...end pairs. (Ada does/did insist on the function name appended to the end token, but that doesn't really change things, and I often do that even in Python. e.g.:
... some code here ...
/. doesn't seem to preserve it.)
def fun (args):
#def fun (args)
Sorry about the spacing, but
I think we've pushed this "anyone can grow up to be president" thing too far.
Be that as it may, it is still not possible to distinguish between them when simply looking at source code. Counting characters and telling the difference between characters that are not visibly distinguishable in how they are rendered on screen is something that a computer is good at, but humans aren't. Ironically, because most people don't ordinarily actually even *read* whitespace, the indentation that Python advocates claim improves readability amounts to differences that are ordinarily invisible to people anyways, and only a computer can actually tell the difference unless a person is paying especially close attention.
It is, I'm afraid, somewhat reminiscent of the bygone days when COBOL was king. and programmers had to have certain things in certain columns in their code or else it would not compile.
File under 'M' for 'Manic ranting'
Bingo. With C, C++, Java you can easily disable a block of code. With Python you're just as likely to introduce a new bug into the code you're debugging than to isolate code you don't care about.
:)
Don't get me wrong, I love Python. But IMHO using whitespace to define blocks was a stupid move. And yeah, I'm well aware of the arguments for and against for the last 15 years.
Almost 24 hours after I made my snarky first post, the discussion rages on. Sez I hit a nerve
"It doesn't say'tabs are OK'."
While I admire your attempt to try to steer the argument to yourlimited comprehension of PEP 8 and yourinsular viewthat tab using people are "idiots", your strawman attempt was quite awful.All one has to do is read the parent post to which you are replying to see that youmade up a fake quote and tried topass it off as something I wrote.
Go read PEP 8 again, please. It is quite clearly denoted as the style guide that should be adhered toif you are contributing to the Python Standard Library.It is not promoted or positioned as the only style guide to ever be used on any Python project. In fact the final sentence of the Introduction to PEP 8 says all that needs to be said about projects using their own conventions, "Many projects have their own coding style guidelines. In the event of any conflicts, such project-specific guides take precedence for that project." But, honestly, if you are sosmall minded as to view people who use tabs as "idiots" I doubt we can hold it against you that you were unable to read and comprehend five (5) sentences. If you had somehow maintained the mental stamina necessaryto readthe title of the second section of the PEP, "A Foolish Consistency is the Hobgoblin of Little Minds" you might have managedthe insight that the following sentences would further clarify the situation. Starting at sentence four (4) in that section are these four (4) sentences, "A style guide is about consistency. Consistency with this style guide is important. Consistency within a project is more important. Consistency within one module or function is the most important."
To summarize, projects can have their own coding styles, project specific coding styles take precedence for that project, and consistency within a project is more important than consistency with PEP 8.
That you would say 'Wake up' as a reply to my post, as if I'mnot comprehending something when it is absolutely clearthat you can't comprehend nine (9) sentences at the very start of a PEP is pretty self-righteous of you. Why don't you take your ego down a peg or two (or nine) andgo read PEP8, for it is not what you are portraying it to be.In other words, words that you can probably understand, "wake up". There is no mandate whatsoever in PEP 8 that all Python ever written must adhere tospaces and an indentation level of 4, let alone anything else specified in that PEP.
Which PEP 8 are you reading, as you areclearly not reading the correct one. In the entirety of PEP 8 the word 'tabs' only appearsseven times. Hereis all the PEPhas to say on that subject,
Tabs or Spaces?
Spaces are the preferred indentation method.
Tabs should be used solely to remain consistent with code that is already indented with tabs.
Python 3 disallows mixing the use of tabs and spaces for indentation.
Python 2 code indented with a mixture of tabs and spaces should be converted to using spaces exclusively.
When invoking the Python 2 command line interpreter with the -t option, it issues warnings about code that illegally mixes tabs and spaces. When using -tt these warnings become errors. These options are highly recommended!
And since PEP 8 only deals with code being written for the Python Standard Library those statements are only applicable to that codebase.
So far you've referred to people who use tabs as 'idiots','brain dead', and'morons' in various, all demonstrably incorrect, replies in this discussion, yet all you have done is continually demonstrate your lack of actual knowledge regarding PEP 8. If anyonein this discussion deserves to have disparaging names regarding their lack of mental acuity assigned to them it would be you.
Replacing tabs with spaces is a good practice in any language because as soon as you open a program in a different editor it becomes unreadable. In fact, Python is the first language where I DIDN'T have to replace tabs with spaces because indentation rules are enforced and taken care of by editor.
To start it would be helpful if functions were consistently verbs when that is a natural choice: in python you have "filter", which is a verb, but then you have "sorted" and "reversed", and then to add to the crazy you have sort(..., [reverse]) which, if you were heart set on using an adjective form, that parameter would be the place to actually use "reversed".
array.extend to me would imply more a memory management tweak allocating more slots. If you're appending elements "push" or "append" makes more sense, or maybe "concatenate" if you like to be mathy. So you do have "append" but only for single elements... and... you have "pop" s why in the heck would you not have "push"?
It's little stuff like this that kinda turns me off above and beyond the whitespace handling, which I find just intolerable.
(PHP is way worse, though)
Someone had to do it.
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?
The big deal about indentation is actually in C. :)
Or more precisely: the question where to place the { and } and how to indent them!
I think the five or six most common (which means the lesser common ones of those share perhaps 10% of all C code base) even have names!! Like K&R, Awho, etc.
The lack of {/} in Python at least relieves us from that war
My next project involves me maintaining and developing a build system in Python (github, see BoB), I'm looking forward to get my hands on it.
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
Larry Wall critiquing someone else's programming language? ROFL.
Given that he blessed us with:
Pre-
Encyphered
Rune
Language
Where are we going and why are we in a handbasket?
Then learn how to use your source code control tool. ... easily!
Delete the offending code instead of commenting it out.
If you are forced to use a certain one and are not allowed to do single commits, install a local one of a different kind, e.g. if you use SVN you can locally use Git or even RCS just fine.
Commit your code locally. Delete the stuff you usually would uncomment, commit if you want, continue your work.
Everything can later be retrieved from the central or local repository
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
Tabs work great if everyone uses them consistently. Which *never* happens.
No shit. Too bad the same is true about spaces.
Syntactic whitespace makes me twitch, too; but it neatly resolves many of the codestyle hubbub issues you see in other language environments.
Well, it could have, by being more strict, but no.
It also applies to people that think what they learned 30 years ago makes them completely competitive in a modern workforce.
You'll often find them complaining about H1Bs and ageism.
I cannot count the number of times I have accidentally
And I can't count the number of times I've flipped back to C from Matlab/Python and it doesn't do anything because I forgot a semi-colon.
Python's strength is in its brevity.
Sorry, but there's more to readability than consistent indentation. I'm pretty sure I'm not the only one who has seen truly horrible python code. Running in production, of course.
CLI paste? paste.pr0.tips!
The ASCII tab _character_ is a form of text compression which was useful when disks were 20Megabytes or less.
What a moron. How many spaces a tab is supposed to "uncompress"?
You're mixing up tabulation with spacing. These are two different enough concepts that, lo and behod, we have dedicated keys for each.
Unfortunately, getting that right requires a functioning brain. fnj doesn't seem to have one.
CLI paste? paste.pr0.tips!
A thousand times this.
CLI paste? paste.pr0.tips!
Well played, TeknoHog, well played.
Knowledge is power. Knowledge shared is power lost.
Well, at the time COBOL was common, the only editor was a *I* had was a keypunch machine. But I never knew that COBOL was sensitive to indentation. Fortran was, as the first 5 columns were reserved for numeric labels, and the 6th column was reserved for a continuation marker, and columns 73-80 were reserved for non-code uses (often sequence numbers), but I never heard any rule like that for COBOL.
So back then I couldn't, and didn't, use tabs. (I *did* use special formatting cards in the keypunch...but I no longer remember the details, just as I no longer remember how to punch carriage control tapes for the printer.)
That said, the tabs vs. spaces argument is silly. I prefer tabs, but I can automate conversion of them to spaces when I ship the code to someone who prefers spaces. The only problem comes when you mix them...which can happen when converting spaces to tabs, but not in the tabs-to-spaces direction. (Yeah, I *could* tell my editor to always replace tabs by spaces, but I won't. I see no advantage and a few disadvantages. [The disadvantages are only annoyances, but they *are* annoyances.])
I think we've pushed this "anyone can grow up to be president" thing too far.
You don't have to distinguish between them while reading the code. Any Python 3 program that mixes the two is not a valid program, and won't even parse. So you can safely assume that whitespace "behaves" exactly how it looks, and disregard tab size issues etc.
If you just assume that the US Government, from the highest levels on down, is absolutely determined to fragment and destroy American culture while running its economy into the ground, then the behavior of its agencies suddenly makes a lot of sense. In fact it becomes predictable.
This has been demonstrably true for the last 8 years. Come back in a few more to see if it continues.
You are in a maze of twisty little passages, all alike.
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.
I kind of thought so too, until I tried it. Now I like it. It forces you do to do something you should be doing to make the code readable, and it's something I always do anyway. It's not brain-dead, it's just different. You might not prefer it, and if not, I think that's understandable, but it's definitely not a bad idea.
You are in a maze of twisty little passages, all alike.
Because human readability of code is much more important than machine readability of code... The art is in creating a language in which the program is obvious to many humans, not just the person who wrote it.
That's an argument for my stance, not yours. Create an intermediate layer consisting of symbols and scopes that are mostly free of ambiguity and an IDE that convert to or from that format. Presto, you get your whitespace scope delimiters and the brace people get theirs. (For maximum transparency, there's no reason why this intermediate layer couldn't be human readable as well. It would necessarily be a very explicit and even Lisp-y syntax with lots of parentheses and brackets. And whitespace would be ignored, of course.)
There's a corner case for metaprogramming, but that can be dealt with in a few ways... and does Python even support/encourage code as data?
If you dislike using an IDE, tools can exist to translate it to plaintext (and then either you or someone else can translate back into the generalized format.)
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.
It's only reliably readable and maintainable to the extent that your language remains popular, and "artistic impression" is a fancy way of saying that in some ways Python lacks the power of other languages, but you want people to code inferiorly with large training wheels so that you can hire someone cheap to maintain it, because it's still a fairly popular language. For now.
with a take-it-or-leave-it attitude
Insisting that humans should be manually doing something (learning the One True Way) that computers can easily, silently and transparently do is pretty much the worst conceivable solution for any problem.
How did that old meme go?
"Your mediocre language has been replaced by a simple shell script."
Yes, but you've got to remember that while Python has no end delimiter for code blocks, it does have a start delimiter -- :. People try to spin it that a colon is a syntactic feature of the preceding statement, but that is merely playing semantics. It occurs everywhere an open brace would in C, Java etc.
Got them moderator blues I blieve I walk out the do', With these mod-points I been gettin', I 'most never post no mo'
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.
...and there's my big problem with semantic whitespace: if it all comes down to needing the right editor, why bother with semantic whitespace in the first place?
Any decent code editor can match parentheses no problem at all, so why not have the editor parse the structure and handle the indentation automatically? That way everybody in the team can have the code set in the way that is most readable to them taking into account their screen size, coding style, visual impairments etc.
Got them moderator blues I blieve I walk out the do', With these mod-points I been gettin', I 'most never post no mo'
Yes, but the point here is that it's a semantic token that can be rendered as per personal preference, which would be a good thing. However, Python conventions favour spaces because people like to line up their continuation lines exactly (eg the continuation of a parenthetical expression should be indented at least one character beyond the parenthesis or bracket it is ruled by), which means either all spaces or a mixture of tabs and space... or at least it does until we abandon our collective love of dumb plaintext editors and start writing languages that demand that the editor parses code structure and renders the code itself.
Got them moderator blues I blieve I walk out the do', With these mod-points I been gettin', I 'most never post no mo'
That's not true. Most editors have a notion of tab stops, and a tab does not "uncompress" to a specific number of spaces. In gedit, a tab character is a true tab -- by default it will leave up to 8 blank columns, moving to the next column that's directly after a multiple of eight. It's very different from just a number of spaces.
Got them moderator blues I blieve I walk out the do', With these mod-points I been gettin', I 'most never post no mo'
if expression: action()
- that's perfect valid python.
Yes, but in order to use that to "comment out" multiple lines of code, you've got to indent each and every line of code that you're commenting out, which defeats the purpose of the exercise.
Got them moderator blues I blieve I walk out the do', With these mod-points I been gettin', I 'most never post no mo'
You're right, my acquaintance with COBOL was always at a distance. I did see some code, but it was in printout, and I think I once wrote a 5 line routine, but someone else keypunched it. But I would have expected to know if it was picky about line columns. Perhaps it was a matter of which implementation was being used, or compiler options or some such. (Certainly modern Fortrans aren't picky about columns used, unless you pick certain compiler options.)
I think we've pushed this "anyone can grow up to be president" thing too far.
Indentation is visible, but the actual characters are not... ironically, the very thing that python advocates claim improves readability is, without using a custom font, invisible.
Also, the actual amount of whitespace will mean dick-all to a programmer that is visually handicapped, rather than improving any legibility, it will only amount to a whole lot of extra noise to its syntax, possibly literally as well as figuratively.
The legibility of any program written in a language that uses explicit block start and block end indicators but is not nicely indented can be improved by passing the program through a pretty-printer algorithm anyways, so python forces programmers using it to do something that computers are generally far more adept at and can perform much more reliably.
File under 'M' for 'Manic ranting'
Jesus, does anybody have to work with this guy? I've met some self righteous ass-clowns, but sheesh.
You are the very definition of a logic failure. As you yourself just quoted, PEP 8 says "Tabs or Spaces? Spaces are the preferred indentation method." And yet you think that it means tabs are just fine.