Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Python Family Gets a Triplet Of Updates

timothy posted about a year and a half ago | from the responding-to-constrictive-criticism dept.

Python 196

The Python developers have been busy this weekend, releasing three new versions at different points on the Python continuum: 2.7.4 (a 2.7 series bugfix release), 3.2.4 (what's new), and production releases 3.3.1. Here's what's new in 3.3.1.

Sorry! There are no comments related to the filter you selected.

Yay! (-1)

Anonymous Coward | about a year and a half ago | (#43382699)

An update for a shitty language

Re:Yay! (1, Interesting)

martica (20295) | about a year and a half ago | (#43382757)

Are you proposing that there are languages that could be considered not to be shitty?

Re:Yay! (-1)

Anonymous Coward | about a year and a half ago | (#43382867)

It's called C++ and it's the only real coding language for anything that isn't a toy or esoteric

Re:Yay! (0)

Anonymous Coward | about a year and a half ago | (#43382917)

It's called C, foo.

Re:Yay! (-1)

Anonymous Coward | about a year and a half ago | (#43383035)

It's called as foo(), see?

But back on topic, I'll bet all you homos would love to witness the release of my python.

Re:Yay! (-1, Flamebait)

Anonymous Coward | about a year and a half ago | (#43382981)

C++ is about the shittiest language around: hair-raisingly complex, extremely bloated, poor libraries, and, with all that, quite limited functionality.

Re:Yay! (1, Insightful)

Anonymous Coward | about a year and a half ago | (#43383131)

hair-raisingly complex

You're an idiot.

extremely bloated

Nonsense.

poor libraries

Maybe.

quite limited functionality

Ridiculous.

Re:Yay! (0)

K. S. Kyosuke (729550) | about a year and a half ago | (#43383297)

I get it, don't allow facts to get in the way of a good quarrel. ;-)

Re:Yay! (0)

Anonymous Coward | about a year and a half ago | (#43383983)

I get it, don't allow facts to get in the way of a good quarrel. ;-)

You're responding to an AC, arguing with an AC... And you're even arguing against the wrong one!

Re:Yay! (1)

dkf (304284) | about a year and a half ago | (#43384259)

You're responding to an AC, arguing with an AC... And you're even arguing against the wrong one!

One had a bit of a point (C++'s template metaprogramming is indeed complicated, especially when combined with some features of C++'s type system, operators and exceptions, and some C++ programmers think that using every last bit of that complexity is a good thing) but obscured it with stupid and irrelevant ranting. (It's not really that important whether the standard library is large or small.) The other was just valueless denialisms from the C++ Internet Defense Force that could only be said to have won anything because the net value of the post being responded to was actually negative.

I wish I hadn't clicked on the "2 hidden comments" link; watching a battle of wits between two unarmed combatants isn't really my thing.

Re:Yay! (0)

Anonymous Coward | about a year and a half ago | (#43383787)

C++ can't be so complex if its fanboys are so simple-minded.

Re:Yay! (1)

K. S. Kyosuke (729550) | about a year and a half ago | (#43384713)

C++ can't be so complex if its fanboys are so simple-minded.

How would that be a contradiction? You'd expect simple-minded people to do unnecessarily complex stuff. As Blaise Pascal once wrote, "I apologize for writing such a long letter, I didn't have enough time to write a short one." Or, another of my favorite quotes, "you don't really understand a problem unless you can simplify it".

Re:Yay! (0)

Anonymous Coward | about a year and a half ago | (#43383317)

It's called C++ and it's the only real coding language for anything that isn't a toy or esoteric

Real programmers can write FORTRAN programs in any language.

Re:Yay! (-1)

Anonymous Coward | about a year and a half ago | (#43382875)

Show us the masterpiece you wrote anon. Oh that's right, you're just a bitter loser with nothing to offer.

Re:Yay! (1)

Anonymous Coward | about a year and a half ago | (#43382959)

Those who can, do. Those who can not, whine.

What's remarkable is that whiners don't whine about their own inabilities. No. They whine about tools or circumstances.

Re:Yay! (1)

tepples (727027) | about a year and a half ago | (#43383705)

What's remarkable is that whiners don't whine about their own inabilities. No. They whine about tools or circumstances.

In circumstances where startups are deliberately given measurably inferior tools, and one needs experience to get experience, how should one proceed without whining? Say, for example, the manufacturer of a device dictates that an application developed by a startup must be written in 100% pure Python for "security reasons", but an application developed by an internationally recognized company may use extensions written in C++. Applications developed by startups would then suffer the disadvantage of poor performance because everything goes through the interpreter, and possibly poor I/O because the Python modules that the manufacturer makes available to Python developers don't expose all of the device's hardware features.

Re:Yay! (1)

dbrueck (1872018) | about a year and a half ago | (#43383849)

Is this a real scenario you've encountered (if so, provide details), or just some made up, straw man scenario trying to illustrate... something?

Not sure it's relevant, but I/O in Python is quite fast, and Python can call non-Python libraries just fine. Also, it seems far more likely that the "internationally recognized company" would be the one with the bizarro artificial coding policies, while the startup would be the one more free to do whatever makes sense.

Cryptographic hardware lockdown (1)

tepples (727027) | about a year and a half ago | (#43384033)

Is this a real scenario you've encountered (if so, provide details)

I haven't seen this happen with Python particularly, but if you replace "Python" with "C#", you end up with the exact difference between Xbox Live Indie Games (C# only) and Xbox Live Arcade (native allowed), or the difference between downloadable Windows Phone 7 applications (C# only) and applications that the carrier bundles with a device (native allowed). Replace "Python" with "JavaScript" and you end up with several devices, where anyone can write a web application but only certain hand-picked developers can write native applications.

and Python can call non-Python libraries just fine.

I'm aware of this. But in the situation I posit, this ability has been locked down for "security reasons".

while the startup would be the one more free to do whatever makes sense

Not if "whatever makes sense" is restricted by a security policy that a device's user isn't allowed to change in the interest of locking out Trojan horse programs.

Re:Cryptographic hardware lockdown (1)

dbrueck (1872018) | about a year and a half ago | (#43384243)

Ok, thanks. I was trying to understand if this was actually relevant to Python or to this sub-topic of whining.

Circling back: how should one proceed without whining? A few thoughts:

1) How effective is whining exactly? Probably not all that much, especially vs e.g. organizing like-minded people/companies into a more powerful group and articulating why a change in policy would be a good thing for all parties involved. Whining is so weak compared to doing something about a problem. Whining is not something that the winners do (but it's not /because/ they are the winners that they don't whine).

2) The xbox example isn't actually a good one. By that I mean, it's not startups vs big companies. A startup that is genuinely serious about developing for that platform can most certainly get ahold of dev kits and publish native apps. It's pretty easy, at least in the US. Also, there are much larger factors than C# vs native when it comes to Live Indie vs Live Arcade - the companies doing the latter are investing far more resources and are held to much higher and stricter standards, not to mention much higher expectations being placed on their output.

3) When your business faces an obstacle and you overcome it, you often find that you want that obstacle to remain in place as it could be an obstacle for your competition. It's easy to think you want a level playing field, but the opposite is almost always the case - you want every advantage possible but you want it for /you/.

4) I think the GP is right in that whining is what people do instead of overcoming challenges. Using the xbox example again, someone who is completely put off by the C# vs native thing, to the point that they feel it's the insurmountable challenge, would probably not be able to succeed anyway - there are much larger challenges they'd have to face on the road to success, so such a minor one up front is probably a filter to weed out those who would later fail on a bigger and more real challenge. In a way, it's a blessing in disguise as it helps divert those people down some other path where they have better odds of success.

Re:Yay! (1)

PiSkyHi (1049584) | about a year and a half ago | (#43383829)

1. A bad craftsmen blames his tools no matter the quality of them.
2. An average craftsmen working with bad tools becomes a bad craftsmen when he is afraid to admit the tools are bad.
3. A good craftsmen blames his tools when they are bad and himself when they are not - otherwise he does good work with good tools for that is why he is a good craftsmen.
From experience, I'd say most people who state no. 1. as paramount are actually number 2. The number 3. people don't usually talk about it too much and they usually think they are number 2. Personally, I think C++ can be replaced by Go and nothing can replace C.

Master Craftsman (1)

gd2shoe (747932) | about a year and a half ago | (#43384027)

It took me some time to figure this out:

A master craftsman is one who produces work that even great craftsman admire. What makes him a master craftsman, and not just a great one? He chooses the very best tools available, and then creates new ones that do what must be done to create his masterpieces.

In other words, once someone is good enough that the very best tools available hold him back, then he is about to master his trade.

Re:Master Craftsman (1)

PiSkyHi (1049584) | about a year and a half ago | (#43384065)

Kind of like Miles Davis: "You gotta learn the rules before you can break them."

Python update (-1)

Anonymous Coward | about a year and a half ago | (#43382759)

My fat python just updated a menstruating woman's vagina with a *pfffbthbtht-pfffbthbtht* cleanout. And by that I mean chunky blood all over my pubis. Red chunks. Brown chunks. Raspberry puree. And man, was it delicious.

-- Ethanol-fueled

Add curly braces and you have C (-1)

Anonymous Coward | about a year and a half ago | (#43382787)

The only real difference between Python and C is the curly braces, and a different library, and a whole new set of bugs. And such stupendous stupidities such as isoweekday() returning a range of 1..7 and sendmail() not being able to automatically construct one's 'From' address.

Try it ... take a chunk of Python code, add the curly braces where appropriate, and take a look at the result.

Re:Add curly braces and you have C (0)

Anonymous Coward | about a year and a half ago | (#43382861)

The only real difference between Python and C is the curly braces, and a different library, and a whole new set of bugs. And such stupendous stupidities such as isoweekday() returning a range of 1..7 and sendmail() not being able to automatically construct one's 'From' address.

What's wrong with isoweekday and what the fuck are you on about with sendmail?

Re:Add curly braces and you have C (5, Informative)

mrvan (973822) | about a year and a half ago | (#43383425)

[...]And such stupendous stupidities such as isoweekday() returning a range of 1..7 [...]

Maybe, from a CS point of view, any index should always be zero-based. However, for weekday there are two compelling arguments why this should not be the case:

1) Authoritative: The ISO specs clearly state that weekday number should be 1..7 [from wikipedia: A date is specified by the ISO week-numbering year in the format YYYY, a week number in the format ww prefixed by the letter W, and the weekday number, a digit d from 1 through 7, beginning with Monday and ending with Sunday."]. So, any library that returns an "ISO week day number" of 0 is simply non-compliant

2) Customary: All human readable date components are 1-based (the first "CE" date is 0001-01-01, not 0000-00-00). So why should weekday (which is intended for human consumption) be different?

Re:Add curly braces and you have C (1)

dkf (304284) | about a year and a half ago | (#43384307)

Customary: All human readable date components are 1-based (the first "CE" date is 0001-01-01, not 0000-00-00).

The first date when that calendar system was used was substantially later; it wasn't invented until 525 and took the best part of 300 years to become widely used.

Of course, the widely used calendar systems from 2000 years ago were mostly pretty weird; the Romans would name the year according to the consuls in office that year. Think of it a bit like calling the current year "the fifth year of Obama" except that was the name that was widely used for things like censuses, commercial transactions, and not just politics. (The other system, counting from the founding of the Roman Republic, was only really used by historians.) To our modern eyes, this is just crazy.

Re:Add curly braces and you have C (0)

Anonymous Coward | about a year and a half ago | (#43384627)

Customary: All human readable date components are 1-based (the first "CE" date is 0001-01-01, not 0000-00-00).

The first date when that calendar system was used was substantially later; it wasn't invented until 525 and took the best part of 300 years to become widely used.

So in other words, you consider the analogy to Python to be spot on.

The Python Launcher (2, Informative)

Anonymous Coward | about a year and a half ago | (#43382829)

So, say i want to make myself a python 3 program in the form of an exe file.

How could i use the "PEP 397: Python Launcher for Windows" in an easy way then?
i would need to make sure python+ the python launcher were installed as well as my program files.

or would it be easier to go with the py2exe solution?

Re: The Python Launcher (1)

Anonymous Coward | about a year and a half ago | (#43382919)

except that py2exe doesnt support py3k.

Re: The Python Launcher (0)

Anonymous Coward | about a year and a half ago | (#43382925)

hm, didn't know that. hm, well the question is still valid though.

Re: The Python Launcher (2)

lattyware (934246) | about a year and a half ago | (#43383359)

Yeah, for 3.x, there is cx_Freeze [sourceforge.net] .

Re: The Python Launcher (1)

Inzkeeper (767071) | about a year and a half ago | (#43383915)

cx_Freeze works for 2.x as well.

Re: The Python Launcher (1)

lattyware (934246) | about a year and a half ago | (#43384001)

Indeed, and for many platforms - I worded my post poorly - I meant to say that unlike py2exe, cx_Freeze works with 3.x as well as 2.x.

Re:The Python Launcher (5, Informative)

Anonymous Coward | about a year and a half ago | (#43383019)

PEP 397 doesn't do what you think it does. It's a program that gets installed when you install Python. It parses a .py file's shebang line and uses that to determine which installed version of Python gets called. It's not designed to bundle Python programs into standalone executables. For that, you'll want to download something like http://cx-freeze.sourceforge.net/ (which works on Python 3, unlike Py2EXE)

Still broken (-1)

Anonymous Coward | about a year and a half ago | (#43382871)

No static type checking. Move along, nothing to see here.

Re:Still broken (2)

dbrueck (1872018) | about a year and a half ago | (#43383859)

lol, there's no static type checking because it's not a statically typed language.

Static and dynamic typing each have their advantages ya know.

Re:Still broken (2, Insightful)

znrt (2424692) | about a year and a half ago | (#43383889)

it's indeed not a language intended for code monkeys. feel free to move along. here, have a banana.

Re:Still broken (0)

Anonymous Coward | about a year and a half ago | (#43385043)

Code monkeys? You mean the parents of Python script kiddies? You do realize that the main Python implementation is written in C, a statically typed language? You can keep your banana. You obviously need it.

Re:Still broken (1)

Waffle Iron (339739) | about a year and a half ago | (#43385021)

No static type checking. Move along, nothing to see here.

Yeah, it would be better make most of the code you write boilerplate like copy constructors and redundant interface declarations in order to comply with a static type system. Then, once you realize that you still can't do what you need with static typing, run everything in a bloated "bean" container to get dynamic typing without having to admit it. And as an added benefit, you get a generous dose of XML to go with that!

Where is the 64 bit dongle support (5, Funny)

PhamNguyen (2695929) | about a year and a half ago | (#43382931)

Python needs to support larger dongles.

Re:Where is the 64 bit dongle support (0)

Anonymous Coward | about a year and a half ago | (#43382963)

I know, with a name like Python, you're expecting at least 9 inches.

Re:Where is the 64 bit dongle support (1)

Anonymous Coward | about a year and a half ago | (#43382985)

Seconded. Anything to keep Joan of Arc wannabes out.

I'd fork that codebase! and make it go to 11 !!! (0)

Anonymous Coward | about a year and a half ago | (#43383079)

re: Python needs to support larger dongles.

I'd fork his codebase!
.
Why I'd fork his codebase into a whitesnake version, and a blacksnake version, and then the special "SpinalTap" version.
;>)
One's well suited to pompous metal-head music, and the other one's bigger, and that third one, well, it goes to 11. 11 ought to be big enough for everybody -- billy gehtes. l'il billy wie gehtes-ihnen. Help, I'm drowing in a stream of consciousness!

2.7.4 (5, Interesting)

JanneM (7445) | about a year and a half ago | (#43382943)

Happy to see another bugfix release for 2.7. Like it or not, 2.7 is going to remain the main or only version of Python for years to come at many installations. Which means tools that depend on Python at such places also only or mostly support the 2.7 series.

The developers for the tool I use have just only begun discussing the possibility of perhaps beginning support for Python 3 in addition to the 2.5-2.7 versions for unspecified later versions; but only if it is possible to do without too much code duplication and maintenance efort.

Re:2.7.4 (2, Interesting)

guacamole (24270) | about a year and a half ago | (#43382999)

The slow speed of Python 3 adoption is surprising. I just started learning python last year, and it seems like some porting effort between Python 2 and 3 may be necessary but the changes between 2 and 3 are pretty small.

Re:2.7.4 (3, Informative)

mrvan (973822) | about a year and a half ago | (#43383149)

I think the current trend in the community is to write a single codebase that support both 2.7 and 3.x. In python 2.x you can "from __future__ import" a lot of the 3.x syntax changes, making it possible to have a shared codebase. For example, this is how django (a major python project) is handling 3.x compatability in its latest version.

(I guess this could be used as an argument that breaking backwards compatability was not really needed and the transition could have been more gradual, but I don't know enough of the specifics on this case...)

Re:2.7.4 (1)

gsnedders (928327) | about a year and a half ago | (#43383987)

On the other hand, some of us supported Python 2.5 pretty much as long as Debian Lenny was supported (until a year ago), and hence __future__ didn't contain the majority of what is needed. Quite a few major projects are only just now moving to requiring 2.6/2.7, and hence only just now making this plausible.

Not that surprising (1)

Viol8 (599362) | about a year and a half ago | (#43383195)

The changes may be small but they're significant, potentially breaking a LOT of old code. This was a foolish decision on the part of Guido IMO. Sure, deprecate some features but don't remove them or change the syntax so old code won't run! Even Larry Wall understood that much and you'd never accuse Perl of being a well designed language.

Re:Not that surprising (4, Insightful)

lattyware (934246) | about a year and a half ago | (#43383369)

That's how you end up being PHP. Python 3 fixes core mistakes made in earlier versions of the language, and makes it harder to write bad code. That's a good thing, and the last thing you want is a language full of 20 ways to do something, 18 of which are deprecated. Removing backwards compatibility for the 3.x line was a good idea.

Re:Not that surprising (0)

Anonymous Coward | about a year and a half ago | (#43383551)

I'll just add a language where the team wasn't afraid to cull and rebuild major parts of it [lua.org] for better and cleaner architecture even though it's quite widely used. As the effect, it's arguably one of most elegantly engineered languages (and with LuaJIT - damn fast as well).

Lua tables vs. JavaScript objects (1)

tepples (727027) | about a year and a half ago | (#43383673)

One statement in the article you linked was a bit hard for me to believe: "Although most scripting languages offer associative arrays, in no other language do associative arrays play such a central role." It then goes on to describe what appear to be the semantics of a JavaScript object, albeit with = separating the name and value instead of :.

Re:Lua tables vs. JavaScript objects (0)

Anonymous Coward | about a year and a half ago | (#43383901)

Yeah, it's an overstatement, though JS objects are certainly less versatile than Lua tables - at least for a simple reason that they actually only map string->object, whereas Lua tables are actual object->object maps. Then there are various goodies added over time like prototype-based being easiest, but not the only one possible inheritance model, ability to set weak ref mode on keys and values separately, and so on.

Mutability (1)

tepples (727027) | about a year and a half ago | (#43385047)

JS objects [...] actually only map string->object, whereas Lua tables are actual object->object maps

Python dicts also map objects to objects, but objects used as keys need some immutable property from which the key's hash is derived. This is why the immutable tuple and the mutable list coexist in Python, as do the immutable frozenset and the mutable set. I think the designers of JavaScript chose to serialize keys to a string in order to have something guaranteed to be hashable, as opposed to falling back on object identity (analogous to Python id(something) [python.org] ) as the key.

Re:Not that surprising (0)

Anonymous Coward | about a year and a half ago | (#43383807)

I'm still looking forward to Python 4, with support for braces, and insignificant whitespace.

Re:Not that surprising (1)

lattyware (934246) | about a year and a half ago | (#43383821)

If you hate it that much, it'd be trivial to write an application that compiles braces into indentation. The reality is it is more readable, and nicer to write. If you are having problems with whitespace being significant, maybe you should find software that isn't crazy - everything I use handles it fine.

Re:Not that surprising (1)

dbrueck (1872018) | about a year and a half ago | (#43383875)

Agreed! The curly braces exist /primarily/ for the computer, not the humans reading/writing the code.

Re:Not that surprising (1)

Paul Carver (4555) | about a year and a half ago | (#43384019)

Does the percent key in vim work?

The most important thing about braces to me is that in vim a single keystroke (%) allows me to bounce back and forth between the start and end of a block.

I haven't tried python yet but it would definitely be a big minus to me if the percent key no longer lets me bounce to block start/end points.

Re:Not that surprising (0)

Anonymous Coward | about a year and a half ago | (#43384021)

Disagreed! Curly braces exist so puny humans with their imperfect brains get fewer chances to make mistakes when telling computers what they want.

You can still use whitespace for readability with curly braces - even more freely so. And even if you misindent something it'll be just a be harder to read, not a syntactic/semantic error (latter being worse).

Re:Not that surprising (4, Insightful)

dbrueck (1872018) | about a year and a half ago | (#43384131)

Try this: take a well-formatted C or Java program and remove all the curly braces, and try to objectively quantify how much this affects your ability to determine the program's structure. Now, take the same program and leave the curly braces but remove all the indentation and again make your best guess about how much this affects your ability to determine the program's structure.

Now ask yourself two questions:
1) Which of the two (indentation or curly braces) is the much stronger indicator of program structure to a human?
2) Which of the two is the much stronger indicator of program structure to the computer?

(hint: if you're completely honest, you'll almost certainly come up with different answers for #1 and #2 :) )

Doesn't it seem just a little weird that the primary indicator of program structure to the human isn't the one that actually matters from the computer's perspective? I'm not saying it's this massive problem, but at the same time it seems odd to fault a language like Python for taking the main block structure indicator from modern languages and have both the human and the computer rely on it. No redundancy, and no chance for two competing block structure indicators to ever be out of sync.

Again, if you want a language where curlies are required, that's fine, but hopefully you can at least see that what Python does is both sensical and pragmatic.

Re:Not that surprising (0)

Anonymous Coward | about a year and a half ago | (#43384253)

Here's the thing - I can restore destroyed indentation from braces in a single keypress/click in any editor. I can't restore program structure from destroyed indentation without careful reading through and manual reindenting.

There's not many ways you can accidentally destroy braces (and yeah, I've cursed at websites swallowing < many times), but there's a lot of ways you accidentally destroy indentation - starting with same websites that swallow your less-thans and going through other Python-insensitive software to careless copypasting and reindenting.

Thank you, but I'll take unambiguous and less prone to accidental failure (though taking some more time in some cases) option every time.

PS: By the way, there is significant whitespace in C. Inside of quotes. In Python you get both significant whitespace (in quotes and at starts of lines) and insignificant (in comments and as separator). Overloading semantics much?

Re:Not that surprising (1)

dbrueck (1872018) | about a year and a half ago | (#43384733)

Here's the thing - I can restore destroyed indentation from braces in a single keypress/click in any editor. I can't restore program structure from destroyed indentation without careful reading through and manual reindenting.

There's not many ways you can accidentally destroy braces (and yeah, I've cursed at websites swallowing < many times), but there's a lot of ways you accidentally destroy indentation - starting with same websites that swallow your less-thans and going through other Python-insensitive software to careless copypasting and reindenting.

Definitely could happen in theory, but it just doesn't tend to happen in practice very much, for the same reasons that the whitespace is used in the first place: it conveys useful information, so people take steps to preserve that information, regardless of the language being used.

Thank you, but I'll take unambiguous and less prone to accidental failure (though taking some more time in some cases) option every time.

More power to you: I'm not in any way trying to argue that people with your perspective should give up what they have selected as their preference. I do, though, object to the earlier comments (from you or some other AC) that imply that languages with significant whitespace are somehow lacking or broken or wrong.

My assertion is that whitespace is significant in pretty much /all/ modern programming languages (otherwise it wouldn't be so universally used and often required by e.g. a company's coding standards). The difference is that in most languages a schism exists because the whitespace is significant to the human but not the computer.

PS: By the way, there is significant whitespace in C. Inside of quotes. In Python you get both significant whitespace (in quotes and at starts of lines) and insignificant (in comments and as separator). Overloading semantics much?

Haha.

Re:Not that surprising (0)

Anonymous Coward | about a year and a half ago | (#43384927)

"Doesn't happen very much" isn't quite comforting for something that introduces a new possible way to break your code.

Even though I don't cross paths with Python very often I saw both syntax errors of this kind and semantic errors - copy-paste programming isn't a good idea, but when a validation function's all copy-pasted blocks to the effect of "if not validate_stuff():\n\t#may be do some stuff\n\treturn False", it's just waiting for some of those returns get miss out a tab. Which happened. Good thing it wasn't return True, which would be worse.

Don't think I saw many of these errors with braces-based code. And don't think it was less readable, thanks to indentation still being permitted, just not being relied upon.

(otherwise it wouldn't be so universally used and often required by e.g. a company's coding standards)

Coding standars also usually require comments with concise and correct explanation of every class, method and function in understandable English, without slang and profanities.

Don't see anyone declaring it "significant" and building it into a language.

The difference is that in most languages a schism exists because the whitespace is significant to the human but not the computer.

You're programming a computer. Of course things that are significant to computer should be of priority. If you're trying to explain something to someone, do you prioritize "it sounds better to me", or "there's less probability of misunderstanding"?

Re:Not that surprising (1)

dbrueck (1872018) | about a year and a half ago | (#43385097)

"Doesn't happen very much" isn't quite comforting for something that introduces a new possible way to break your code.

That's the strongest I can say it without somebody coming up with an obscure counter-example and declaring checkmate. :) In my experience, these problems just don't happen, but asserting an extreme is an invitation for somebody to come along and gleefully pounce on it.

There are plenty of ways to break code via sloppiness. Your experience may differ, but for me significant whitespace causes problems about as often as code breaking because somebody changed it all to upper case or ran it through Google Translator.

Even when copying and pasting code (from e.g. an email or a web page to my editor), I can't remember the last time I had a whitespace problem, but more often I've had problems with e.g. the quote character becoming the quote character a word processor uses.

Even though I don't cross paths with Python very often I saw both syntax errors of this kind and semantic errors - copy-paste programming isn't a good idea, but when a validation function's all copy-pasted blocks to the effect of "if not validate_stuff():\n\t#may be do some stuff\n\treturn False", it's just waiting for some of those returns get miss out a tab. Which happened. Good thing it wasn't return True, which would be worse.

Don't think I saw many of these errors with braces-based code. And don't think it was less readable, thanks to indentation still being permitted, just not being relied upon.

But whitespace /is/ relied upon - by humans who read, write, debug, and refactor the code. That's the rub. I'm sure you've seen the classic errors in C like:

while (condition);
        doSomething();

I'm not suggesting that these types of bugs happen all the time, but do you understand /why/ they can be easy to miss?

(otherwise it wouldn't be so universally used and often required by e.g. a company's coding standards)

Coding standars also usually require comments with concise and correct explanation of every class, method and function in understandable English, without slang and profanities.

Don't see anyone declaring it "significant" and building it into a language.

That's missing the point.

It's telling that that consistent whitespace is such an important factor in code readability that many companies/projects formalize it as part of their coding standards, that's all.

The difference is that in most languages a schism exists because the whitespace is significant to the human but not the computer.

You're programming a computer. Of course things that are significant to computer should be of priority. If you're trying to explain something to someone, do you prioritize "it sounds better to me", or "there's less probability of misunderstanding"?

First of all, the above two aren't opposites. In fact, the more the two converge, the better.

But the underlying principle is that everything you require the programmer to do has a cost, and if the cost doesn't provide sufficient benefit, then it might be good to change it. If you look at the evolution of programming languages, real progress has been made in making languages more expressive and requiring less arbitrary effort on the programmer's part.

The fact of the matter is that programming languages always require something of the programmer that is outside of the domain of whatever problem the programmer is trying to solve. To the extent that you can recognize and eliminate those effectively, that's a good thing. For example, in older C programs you had to declare variables at the start of your function, even if you didn't use them until later. Was that to help the programmer? Some people argued that it helped them think through what they'd need, but in reality it was because it made writing the compiler tools easier. Relaxing that requirement was a good thing.

Remember when Java didn't have autoboxing of primitive types? Not the end of the world, and yet having the programmer care about that detail had really nothing to do with the problem at hand, but it was work being done to satisfy the language and the tools.

There are countless examples of this: work the programmer has to do, not because it really is related to the task at hand per se, but an artifact of the tools and language. Some are more significant than others, but regardless of the magnitude they are a cost, they do add complexity, and they distract from building bigger and bigger things. So as computers get faster and more powerful, we often exchange that new power for making languages and tools that allow for higher forms of expression but also languages and tools that require less busywork by the programmer.

I "get" that you're not a fan of significant whitespace, but those who like it see it as just another example of this sort of evolution of languages that is ongoing. The curly braces can help indicate block structure, but they are secondary to the whitespace to the people writing the code, reading the code, troubleshooting the code, and modifying the code. You could argue that the curly braces also add /some/ readability, but that's more of a side effect - the real reason they are there is to tell the tools e.g. where your multi-statement blocks begin and end. See the earlier comments about taking a program and alternatively removing the braces or the whitespace - of the two, the whitespace is what is really significant to all the humans involved, so it's not /that/ crazy of an idea to include the computer in that group as well.

Re:Not that surprising (1)

jgrahn (181062) | about a year and a half ago | (#43384469)

Again, if you want a language where curlies are required, that's fine, but hopefully you can at least see that what Python does is both sensical and pragmatic.

Sorry, but pragmatic is not the right word. The indentation-is-block-structure assumes people make sane editing choices, don't redefine the size of a TAB, and don't disagree about indentation level. That's just not how the average programmer works, unfortunately. I myself have lost a lot of time on this. When you're familiar with other languages, it's an odd feeling when you realize a small indentation fsckup forces you to start over from the beginning.

On the other hand, it's just one blemish on an otherwise good language, and not a reason to reject it.

Re:Not that surprising (1)

dbrueck (1872018) | about a year and a half ago | (#43384937)

Again, if you want a language where curlies are required, that's fine, but hopefully you can at least see that what Python does is both sensical and pragmatic.

Sorry, but pragmatic is not the right word.

Oh, it most definitely is! Look at all the counterarguments in this thread, including yours below: these are all very realistic problems that could occur /in theory/. In practice they rarely, if ever, occur. Seriously, I've been using Python for well over a decade with many different teams of developers in several different companies, and the problems that curly braces help protect against just don't really happen all that often. Big companies, small companies, big projects, small projects, new Python users, Python experts, large teams, small teams, etc., etc.: every significant variation in situation that I can think of, and not only have these types of problems never been regularly occurring, they have in fact been so rare that I have trouble coming up with specific instances in which they /did/ occur.

So, going back to my earlier suggestion that whitespace is significant to humans in pretty much all modern computer languages, if you use a language like Python for awhile, most people I've worked with (including those who have come to Python with pretty strong bias against it) end up realizing it's actually just fine. You don't run into problems, you aren't constantly at risk of a big mess or anything. It works great. Do that for awhile and then go use e.g. C or Java, and it seems odd to need to use the curly braces. Why? Because you recognize that they aren't the most significant indicator of block structure (to you, the person writing the code or to all the people reading the code). Net result is that the curly braces don't feel all that pragmatic: they add little or no value so why use them?

The indentation-is-block-structure assumes people make sane editing choices, don't redefine the size of a TAB, and don't disagree about indentation level.
That's just not how the average programmer works, unfortunately.

Hehe, I'm tempted to make some quip about what constitutes an average programmer, but again all I can do is observe that these things just don't happen all that often. You hire a new guy and he asks, "tabs or spaces?" and we say "spaces. Most people use 4" and that's it. It's never ever ever an issue. And honestly, it seems like 4-spaces-instead-of-tabs is a pretty common default anyway (regardless of language), such that a lot of times this conversation doesn't even happen.

I myself have lost a lot of time on this. When you're familiar with other languages, it's an odd feeling when you realize a small indentation fsckup forces you to start over from the beginning.

I /am/ familiar with other languages. I've used both types we're discussing for many years, which is why I can from experience observe that these things just don't really happen that often. At my company, for example, we each regularly develop in C#, Java, C, C++, Objective-C, Scala, Javascript, and Python. We use four-spaces-no-tabs in all languages not because of some standard that is enforced, but just because it looks nice and nobody used tabs anyway. We have the full gamut of experience levels of people using Python, and at this company we have experienced these theoretical problems with Python exactly zero times. I'm not saying they couldn't happen. Maybe we're just phenomenally lucky, or maybe these problems don't happen as frequently as detractors of significant whitespace imply. :)

On the other hand, it's just one blemish on an otherwise good language, and not a reason to reject it.

You're entitled to your opinion of course, but I hope you can recognize that many people feel that not only is it not a blemish that you just have to deal with, but a compelling feature and one of the reasons it's a really good language. Further, I hope you can accept that there are a lot of people who feel this way not due to some preconceived notion they are holding to, nor due to a lack of experience with other languages, but that their opinion is based on both having used Python as well as other languages for a long time - i.e. their opinion is based on first-hand experience.

You might be an exception, but it often seems that people who dismiss a language like Python due to significant whitespace are people who haven't really tried it for any significant project or length of time. My initial reaction to Python was "meh". Then for one reason or another I used it on a few projects, then a few more, and so on, until it became my language of choice when the scenario permits it. Along the way I found that many of the theoretical objections to Python are not well-founded, and that its departures from the Java/C family of languages (things including significant whitespace) are often beneficial, well-thought out, and really nice from a programmer's perspective, such that when you go back to those other languages, you really miss them.

Re:Not that surprising (1)

jgrahn (181062) | about a year and a half ago | (#43384535)

That's how you end up being PHP. Python 3 fixes core mistakes made in earlier versions of the language, and makes it harder to write bad code.

I now nothing about PHP, but almost *all* languages try to stay backwards-compatible, because their designers know how surprisingly hard it is in practice to migrate everyone.

Re:Not that surprising (1)

lattyware (934246) | about a year and a half ago | (#43384929)

That doesn't make it a good idea. Go and look at PHP, and you'll see why. PHP is a horrific mess of deprecated stuff, and it's insanely hard to find the right way to do something in the cruft of hacked in features and old ways of doing things. As with all things, we make mistakes when we design languages. Sometimes, we can fix those without breaking backwards compatibility, sometimes we can't. It's worth making the break to make the language better - it's just not wise to do it more than very rarely.

Re:2.7.4 (0)

Anonymous Coward | about a year and a half ago | (#43383309)

The slow speed of Python 3 adoption is surprising. I just started learning python last year, and it seems like some porting effort between Python 2 and 3 may be necessary but the changes between 2 and 3 are pretty small.

The changes may be small but they brake virtually every existing program. So you have to maintain 2.7 for existing customer applications, or persuade them to pay you for an upgrade that brings them no benefits (yeah right). And if you have to maintain 2.7 why bother upgrading your own operation to 3? It just means you'll have to do everything twice.

Breaking existing code is the stupidest thing one can do, and history shows that the languages that do this do not recover from the blow (as an example: VB6 to VB.NET, which still hasn't recovered even though VB.NET has been free for 8 years now, while VB6 generated lot's of cash for Microsoft).

Re:2.7.4 (1)

znrt (2424692) | about a year and a half ago | (#43383827)

So you have to maintain 2.7 for existing customer applications, or persuade them to pay you for an upgrade that brings them no benefits

if you are using python to build "customer applications" you're doing it wrong. your customers are doomed anyway.

python is a beautiful language and a superb tool for dishing out quick tools or prototypes. nowadays it simply isn't stable enough for much else.

as a quick sampling test, try upgrading python on a standard RHEL box. you'll totally screw the effing package system. this is simply not serious.

Re:2.7.4 (1)

gd2shoe (747932) | about a year and a half ago | (#43384133)

as a quick sampling test, try upgrading python on a standard RHEL box. you'll totally screw the effing package system. this is simply not serious.

And that's python's fault, and not Red Hat's?

Re:2.7.4 (1)

fnj (64210) | about a year and a half ago | (#43384625)

Yeah, IMHO it's brain dead language design if a script expecting python 2.6 doesn't continue to work fine with python 2.7, which is only a point upgrade.

It's nothing you can't easily work around, though. You can leave the original python installed, and install a new version in another location. So I'm not overly exercised by what I perceive to be silly language design decisions.

It's CERTAINLY not Redhat's fault, because python 2.6 is a mandatory package whose removal and replacement with some third party package or build-from-source is not supported.

Re:2.7.4 (1)

fnj (64210) | about a year and a half ago | (#43384593)

as a quick sampling test, try upgrading python on a standard RHEL box. you'll totally screw the effing package system. this is simply not serious.

Duh. Yum uses python (it's 2.6 in the latest RHEL 6, BTW; not 2.7). It's got to use SOMETHING. If an upgrade to python changes old behavior, why is that not brain-dead language design? Not anything wrong with yum.

Here's a hint, though. It's linux. You can do almost anything. Just download the source tarball, extract it, ./configure --prefix=/opt/mypython, make, sudo make install. All system scripts that use #!/usr/bin/python will continue to use the original, still-installed python, and you can use #!/opt/mypython/bin/python in your own scripts to use the spiffy version you want.

You can do this even if you have one of the many sites that still use RHEL 5 (python 2.4).

Re:2.7.4 (1)

siride (974284) | about a year and a half ago | (#43383913)

There's no value in VB.NET, though. It's not just that it's different from VB6, it's that it's not really that different from C#. You might as well just use the flagship language for CLR. Also, the CLR environment isn't quite the same as the VB6 environment and is intended to be a full platform for writing real programs, rather than a platform for RAD and one-off crap. Basically, VB.NET doesn't fill a niche that makes sense in the way that VB6 did. Personally, I'd rather they take the few good features that VB.NET has that C# doesn't, put them in C#, and then kill VB.NET. That's assuming they don't kill .NET first.

Re:2.7.4 (1)

baijum81 (840816) | about a year and a half ago | (#43383375)

118 out of 200 most downloaded third party packages in PyPI has Python 3 support. Ref. http://python3wos.appspot.com/ [appspot.com]

Instead of Pygame (2)

tepples (727027) | about a year and a half ago | (#43383681)

Pygame, an interface layer to SDL, doesn't appear to have broken the top 200. What replacement for Pygame that fully supports Python 3 should developers be using?

Re:Instead of Pygame (1)

baijum81 (840816) | about a year and a half ago | (#43383715)

pyglet 1.2beta1 [google.com] has partial support for Python 3

Re:2.7.4 (1, Interesting)

abe ferlman (205607) | about a year and a half ago | (#43383529)

Wake me up when they bring 2.x style print back. Taking away convenience features is not the way to encourage adoption, if anything they should add more.

Re:2.7.4 (1)

gd2shoe (747932) | about a year and a half ago | (#43384191)

Seconded.

I can understand taking away statements in favor of built-in functions, but that was just too darned handy to yank out from beneath us.

(Now making parenthesis optional on some function calls might be cool... if it doesn't cause Python to become as unreadable/ambiguous as Perl! Great care would need to be taken, and I doubt they'd ever consider it.)

Re:2.7.4 (1)

spitzak (4019) | about a year and a half ago | (#43385121)

It seems to me that a simple handling of a space after the first word is all that is needed. The following statement:

      a b

is treated exactly the same as

    a(b)

Then old print would be supported since it would turn into the new print() function. It would also let "help foo" work, which is something I keep typing wrong for some reason.

I'm sure there is some odd interactions with the parsing of some obscure syntax that need to be figured out, but since all the obvious tests I can do produce syntax errors right now, I suspect rules can be made so this works for all the uses people want.

Re:2.7.4 (0)

Anonymous Coward | about a year and a half ago | (#43383561)

It doesn't seem surprising to me at all. Python is currently in dependency hell.

Re:2.7.4 (0)

Anonymous Coward | about a year and a half ago | (#43384095)

Does Google still use 2.x internally? Why did Guido leave?

Re:2.7.4 (1)

spitzak (4019) | about a year and a half ago | (#43385155)

A killer with Python 3 is the stupid handling of strings.

A string should be a sequence of byte values. If they *happen* to be UTF-8 then it "is unicode" but I should not be prevented from using my string just because it does not match a complex pattern called "valid UTF-8". Nobody in the history of computer science would ever have made a scheme where the simple act of *looking* at data that has been sucessfully read from an outside source can throw an exception, but for some reason Unicode and UTF-8 turns otherwise intelligent people, such as Guido, into the most incredible morons or idiot savants.

At least Python 2 does not mangle the strings when you do this, though you have to be careful when you actually want to print them. Python 3 actually makes it impossible to store invalid UTF-8 in a "string". This is counter-productive, as we are forced to use byte arrays for all strings, including ones that are valid UTF-8. That is NOT encouraging use of Unicode, it is going backwards!

Re:2.7.4 (0)

Anonymous Coward | about a year and a half ago | (#43383371)

Happy to see another bugfix release for 2.7. Like it or not, 2.7 is going to remain the main or only version of Python for years to come at many installations. Which means tools that depend on Python at such places also only or mostly support the 2.7 series.

The developers for the tool I use have just only begun discussing the possibility of perhaps beginning support for Python 3 in addition to the 2.5-2.7 versions for unspecified later versions; but only if it is possible to do without too much code duplication and maintenance efort.

Laziness, laziness... I ported few of my projects to py3k and it was pretty straighforward process. You need to pay a bit of attention to IO related calls, but in general you can be done within hours even with some larger projects.

Re:2.7.4 (3, Insightful)

mrvan (973822) | about a year and a half ago | (#43383439)

I think it is 'dependencies dependencies' more than laziness. Few real-world projects depend only on the stdlib, and for these projects it is necessary to wait for at least the majority of depencies to adopt 3.x before porting becomes feasible, even if the porting itself is relatively straightforward. Of course, you can fork any dependencies and port them yourself, but the whole point of not reinventing a wheel is avoiding the maintenance on said wheel...

Re:2.7.4 (1)

fnj (64210) | about a year and a half ago | (#43384451)

Happy to see another bugfix release for 2.7. Like it or not, 2.7 is going to remain the main or only version of Python for years to come at many installations.

Python 2.7! Python 2.7? Users of all those RHEL 6 installations out there only WISH. They have Python 2.6, and they were damn glad to get that, too, since they were saddled with 2.4 for all those dreary RHEL 5 years.

Re: Same reason old IE wont go away (1)

Billly Gates (198444) | about a year and a half ago | (#43384847)

Once something becomes the pillar that everything rests upon its impossible to remove. Witness XP and IE 6.? One 1/4 of corps still have not upgraded to the all so cutting edge 4 year old IE 8 and windows 7! Those that have upgraded still have apps like Dell EMS that cant run on anything newer. IE 10 is considered broken at work even though its the first W3C version.

Python 3 is just that. Broken! Python 2.7x is the standard now and why leave since it works fine? Welcome to the lgacy club! You can have a seat there next to Cobol andXP?

The only reason IE 6 support is dying is because MS is EOLing it. Can the python foundation exert this much conrtol? Too many apps and apis are dependent on it amd its old quirks are hard coded into apps.

Cheap beats by dre (-1)

Abelarddsxd (2890239) | about a year and a half ago | (#43382967)

I'm just extremely vital in http://www.beatsbydresoloireland.com/ [beatsbydre...reland.com] for the reason that Now i am involved with popular music every day. Soft top, New cd, Video tape, and all layouts show that I actually discover not to mention comprehend audio over the headset and even needing ruggedness. When my very own headset bust and also fail, you'll find it similar to reducing someone you care about. Nicely these are flat-out the ideal and we will possibly be mutually for your stretch of time. Typically the foldable the ears keyrings is important as well as the sound quality may not be covered. Someone who feels they aren't cozy needs to have these products pinching perhaps the eardrums rather than "over" the whole head. Might be his / her thus expensive since they will probably outlive the owners! Like these people!I became wishing the actual Betters from Medical professional. Dre Pro's for about 1 year but merely can't deliver personally to lower that type involving money on me.

A feature still missing (1, Insightful)

Urkki (668283) | about a year and a half ago | (#43383329)

A very important feature of any language still seems to be missing: a sane reference documentation.

In a duck-typed language this is even more important, because compiler/IDE can't really help programmer there. Below is a sample from core library docs, links included. To fully appreciate this, there's no link to this "read()" method, and whole BytesIO class documentation does not contain such method, so you're going be manually searching the page to find documentation for read(). Fortunately it is on the same page, which conveniently documents entire module, so it's really easy to quickly find particular piece of information in that wall of text.

read1()

In BytesIO [python.org] , this is the same as read()

Re:A feature still missing (3)

lattyware (934246) | about a year and a half ago | (#43383383)

The documentation is great in general, you seem to have found one missing link in a relatively obscure class. As a whole, Python's docs are great. They generally explain well and give full examples.

Re:A feature still missing (0)

Anonymous Coward | about a year and a half ago | (#43383933)

Compared to Java and C# I always found Python's documentation lacking.

Re:A feature still missing (1)

lattyware (934246) | about a year and a half ago | (#43384007)

Wow, really? I've not dealt with C# much, so I can't talk on that front, but I've found Python's docs far more useful than Java's.

Re:A feature still missing (1, Insightful)

Urkki (668283) | about a year and a half ago | (#43384633)

The documentation is great in general, you seem to have found one missing link in a relatively obscure class. As a whole, Python's docs are great. They generally explain well and give full examples.

Just compare (not, these are not exactly same thing, just pretty close):

Of these, Python's is least clear and useful in my eyes, by quite a margin. YMMV.

Re:A feature still missing (0)

EngnrFrmrlyKnownAsAC (2816391) | about a year and a half ago | (#43384333)

It may not be perfect (e.g. your example) but Python takes documentation seriously. How many other languages allow you to embed the documentation right in the freaking source file?

Re:A feature still missing (1)

Anonymous Coward | about a year and a half ago | (#43384399)

How many other languages allow you to embed the documentation right in the freaking source file?

... All of them?

At least, all the popular ones. You might have heard the name "JavaDoc", for example.

Say what? (0)

Anonymous Coward | about a year and a half ago | (#43383335)

I was the only one who thought, What Monty Python updates....?

Te be followed by a doh?!

Nice work on the update to Python, guys!

GreekGeek :-)

Endless discussions (0)

Anonymous Coward | about a year and a half ago | (#43383725)

It is stupid to compare languages, a programmer or an engineer should know to use which language to use for a given project. This said, all languages have pros and cons. But it still looks like some angry teenagers witnessed some coding practices or discussions come here and critisize things that they dont understand deeply. Thanks to you, good programmers with flexible skills will always take the job while you are still waiting on "thanks for the application, we will call you"

Mac OS X Python madness (1)

danceswithtrees (968154) | about a year and a half ago | (#43384563)

I guess I am firmly in the realm of knowing enough to get myself into trouble. I use Mac OS X 10.7 and have Macports installed. I just installed python 2.7.4 to stay current. When I start up python, it was still v2.7.1. Trying to figure out why, it seems that python is installed in too many places!

The original Apple installs are in /System/Library/Frameworks/Python and include versions 2.3 , 2.5.6, 2.6.7 and 2.7.1.
The python foundation installs into /Library/Frameworks/Python. Furthermore, macports has taken over python and decides which one should be executed using a link from /opt/local/bin/python which currently ->/usr/bin/python2.7 which is the Apple installed 2.7.1.

I once tried to get rid of python 2.3 and 2.5 (who uses those, right?) and found out that iPhoto didn't work anymore!

Has anyone found a saner, neater and more space efficient way to organize all the python installs on Mac OS X?

Re:Mac OS X Python madness (0)

Anonymous Coward | about a year and a half ago | (#43384629)

Yes.
1. Ditch Macports for homebrew (mxcl.github.com/homebrew/) (ok, off-topic and optional, but you won't regret it).
2. Install pythonbrew (https://github.com/utahta/pythonbrew). Everything is installed in the user dir, you can switch easily between versions : right now I am working in a split terminal with 3.3.1 at my left and 2.7.4 at my right.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?