This is the sort of thinking that leads to me still finding IE6 in active use.
Lol. No, it isn't.
IE6 is in use because it depends on incompatible technologies that (most ill-advisedly) must run in the remote client's space. Python, when running as CGI, runs where it should: In the server's space.
IE6 thinking is what led to the incredible Java mess, though. So you're kind of on the right path, but you have to learn how directly polluting the client space differs from making choices within the server space. Here it is: CGI runs on anyone's anything regardless of version. It's a server side tech, and the client does not need to know or care how you got your computing done. Client side tech requires FAR more of the user's platform, and, as you observed, in the case of IE6, can even require a specific platform. I can't even tell you how often I've run into "wrong Java version" or some variant of that. Server side, you don't need to know what language, and I don't care if you're on an old palm pilot or the latest OSX hotness or some mid 2000's version of linux. Because in NO way does hanging with a particular CGI language commit the client to anything. You want to upgrade, go ahead, no harm done. Clear now?
And of course, if Python had been properly written to be backwards compatible, as it should have been, you could just use the latest version no matter what. But, since they broke this and that moving forward, you have to be a little more careful and keep the right environment around. It's not horrible, but it's bad enough that you can't just do it as a matter of course.
1) Python 3 is completely irrelevant to me -- it's a different, incompatible language I have zero interest in.
2) You're misinterpreting advice for libraries with advice for code
So how about YES because....
(a) mixing tabs and spaces has no inherent value,
(b) tabs are higher value than spaces in code because you can change the size of a tab indent with one setting, whereas space indents are what they are and that's the end of it.
(c) Python allows tabs for a reason, and that reason is so you can use them
I've written a lot of Python, am highly effective in that pursuit, and I find the consistent use of tabs to be the way to go. Your advice is bad -- and wrongheaded.
So I am at great pains to only use space characters in what python code I write. That is absolutely pointless extra work to deal with.
[shrug] You're doing it wrong. Mostly because you're stubborn. The technical term for that is "shooting yourself in the foot." You certainly don't have to do it wrong.
The "special" editor I use most often is the one built into midnight commander (mc and mcedit), which, while not specifically designed as a Python editor, works perfectly. Also for Perl, shell scripts, etc. Other times, I use TextWrangler under OSX, which has the additional benefit of being UTF-8 aware, and also handles tabs and spaces in a way that ensures they are easily managed. The benefit is the use of a powerful, clutter-free language with strong visual blocking cues. This is not to say that I can't use vi; because I use tabs exclusively as my leading white space, there's zero confusion on my part about which block is which. I just prefer mcedit, frankly.
I never got a straight answer to how python deals with a mixture of tabs and space characters in the indenting.
Why in the *world* would you mix the two? Just use tabs. This gives you the visual blocking, you can globally change the indents with one move at any time, most decent editors let you see them, they reduce cursor movement keystrokes... seriously man, just apply yourself and it'll all become easy as heck. You're *making* it hard where it isn't hard at all.
Security patches to scripting languages are almost always 100% irrelevant unless you're writing for WAN-facing machines with exposed services. I'm trying to figure out the odds of a deep excursion of the northern polar auroral oval at the desktop, not keep Joe Scriptkiddie from entering Robert');Drop Table Customers; -- into a CGI form.
The changes from Python 2.5 to 2.7 are likely to be much less pa
Why should I accept any pain at all? How about if I just don't upgrade, and my stuff doesn't break, and I continue on making new things? Isn't that more sensible on every possible level?
For all the Microsoft hate that goes on around here, they have historically done a fantastic job at maintaining backward compatibility.
Until XP, yes. Then the creeping incompatibilities began. First down, window metrics. Buttons, title bars, really just about everything GUI oriented began to creep around (and de-register with pointer co-ordinates) as the new "look" used (required, really) window metrics not available to prior versions. This, of course, leaves out the terror-infused side trip into MIPS, PowerPC and Alpha versions of Windows NT. Anyone for inverted font metrics? Oh, the stories I could tell you...
On the other hand I don't expect much better from those who think whitespace is part of the language anyway....
It's easy for a Python programmer to choose an editor that also knows about whitespace. The rest are good enough that they don't even need to. Personally, given the choice between extraneous { } all over the place and indentation, I definitely prefer indentation. It's fast, it's highly visual, and it reduces display clutter.
...which would be a huge PITA, for no particular reason that I can think of.
If it isn't broken -- don't "fix" it.
There's a world of difference between people who do real work for real money and where things operating or not have consequences, and some abstract idea of "it'd be 'nice' to have the newest stuff." The latter is of no consequence; the former means everything to everyone.
Upgrading to 2.7 doesn't introduce the kind of incompatibility that upgrading to 3.0 does.
No, but it still introduces significant incompatibility -- things can and will break -- and so re-testing, re-coding, re-certifying... still required. Now, you have two choices:
a) Don't screw with the system, and everything continues to work just fine, no extra costs or problems are encountered, and everyone is happy except the cluetard who write TFA, who no one cares about anyway. Or:
b) You can upgrade, break everything, incur lots of costs, and everyone in every direction is pissed off except said cluetard.
Now, I ask you: what's obviously the best choice here?
The problem with upgrades is the developers don't take nearly enough care to ensure compatibility with existing software. For instance, I moved a Python script from an older machine (redhat 9) to an Ubuntu 12 system with a later 2.x series Python, and the script immediately bombed out. Turned out that I'd used "as" as a variable name, and it had become a reserved word in the interim. Elsewhere, I was adding ints to floats or vice-versa; now that produces an error. Somewhere, the behavior of "global" changed. I had a procedure written with global VariableName up front so the procedure could see a global switch. I handed the script to someone else, and they had to *remove* that to make it work.
I moved a large system depending on perl scripts (yes, I know, not Python, but the issues are identical) across the same machine pair and it was so broken under the new perl that it took me two months (and cost my client a great deal of money) to adequately debug and update it. From external module changes (use DBI) to how references to hashes were handled, it was one thing after another. What made me fume the entire time is that this stuff worked *perfectly* under redhat 9 with the earlier perl -- it really wasn't broken. Bloody perl was broken! Worse, I'd abandoned Perl for Python years ago, and my Perl skills were very rusty... that's tough when you're trying to work through tens of thousands of lines of sophisticated code. I truly regret every line of Perl I ever wrote, and cringe at the idea of having to revisit it for any reason at all, because Perl, whatever its true merits, is a language that I was destined to hate to my very $core;
This kind of thing makes me extremely unwilling to upgrade; for that matter, it can send me hunting for the old version to install in new machines, although that can present its own set of problems and requires at least some of a different skill set than programming that really leans more into system administration, which I am not in the least enthused about. For some strange reason, enjoying research on auroras does not automatically carry with it a predilection for meddling with OS environments.
This is all part of a larger gripe set I have where makers of languages and APIs break existing code in favor of new ideas. Here's my position: If you ship the language with X features, you have NO BUSINESS breaking ANY of those features. You have a new idea? Fine. Implement it as something completely new within the language or the API. If it's got new keywords, provide the programmer a switch to enable them -- words that were not reserved before may have crept into the user's namespace(s.) Never take a call out of an API. Never make an API call work differently. If you think you need to do that, then *I* think you need an entirely new API. If you even use the word "deprecated", I will burn you in effigy and spit on the ashes. Furthermore, if you do it right, you will NEVER need to say "end of life" because the most current version will still run the first code ever written for API or language 1.0; upgrades will actually be upgrades rather than incompatible replacements.
Windows got this very nearly right for a long time, then with XP, they began to break everything from window metrics to system calls. By the time Windows 7 rolled around, apps that worked perfectly looked like trash and worked even worse, and I tossed my Windows machine in the can both for development and as a user. Apple's guilty of this too, even going so far as to obsolete their own applications and feature-sets. One really irritating example of this is having bought Aperture 1, 2, and 3 for OSX 10.6, I bought a new camera, a Canon EOS 6D. Works *fabulous*, pretty much the first DSLR I've ever been actually satisfied with. Both Lightroom and Aperture required an update to read the RAW images. Lightroom upgrade went smoothly. The Aperture upgrade? Told me that in order to install the updated RAW support, I'd have to upgrade the OS. But 10.7 and later are not highly compatible upgrades, I have to support OSX
[shrug] -- like I said, it's poorly enforced. There are plenty of illegal, unconstitutional laws and practices. Doesn't make them right. Just makes them tools of the oath breakers.
There needs to be an age where gun ownership is illegal or are you advocating the right for four year olds to own guns.
No. There doesn't, and I am not doing anything of the kind.
When I bother to waste my breath explaining it, I advocate competency testing as the line to be crossed, because age is a fucking stupid metric. Now, you show me a four year old that can pass a well administered and conceived firearms, voting, or sexual issues test with flying colors, then you can point the finger at me. The problem with the age line in the sand is that it does exactly that: It unreasonably qualifies people who are obviously unqualified without any relation to competence at all.
Would you put someone on the road without a driving test, just because they're 21? No? Then why the FUCK would you be willing to hand over weapons, allow them to shag your daughter, etc. for the same reason?
Age. Fucking useless metric. Causes no end of misery and pain.
Nope. 14th amendment. No state can violate anything in the bill of rights "downstream", as it were. It's very clearly written. Not that it's well enforced, but it *is* clearly written.
Those rights are not "protected" by the constitution. Those rights are named for the benefit of the government, specifically in aid of explaining to said government that they are not to be fooled with.
Which said government roundly ignores today, but still, that's what it is: restrictions of government action. Not protection of your action, unless you're speaking in the vague sense of being protected from your government, which, sadly, the constitution has not been adequate to do, as it has absolutely no teeth -- if government chooses to ignore any particular thing, nothing happens to anyone. Without people of strict honor in the government (not happening) and the judicial system (also not happening) and law enforcement, the constitution is truly of little value to us.
For example, you have to be 18 to vote, you cannot own a gun if you are certified mentally unstable, and there are limits to your ability to own a gun if you are a felon (you can have one at home for self-defense, but not elsewhere).
Other than amendment 26 (sets voting age to 18 years), your "recognized" issues are not codified in any way in the constitution. The rest is all legislative product, with the occasional collusion of constitutionally ignorant feeble minded fools at the bench.
Guess you weren't around when the government thought we were old enough to go fight and die in Viet Nam, but not old enough to have anything whatsoever to say about it.
I was there. I was in that exact demographic.
So I *do* have a problem with it. It's fucking abusive.
Flash forward to today: There are plenty of minors I'd trust implicitly with a weapon, or a vote, or my daughter's sexuality. Contrariwise, there are plenty of adults I can think of -- without even trying hard -- that probably shouldn't be allowed to handle weapons, ballots, engage in sexual activity with others, or handle sharp objects, until someone takes them aside and bloody well trains them, rather thoroughly, in all of the above.
Lines in the sand defined by age are both wrongheaded and ineffective. Would you hand the keys to a car to a person because they reached some particular age? No. Because they'd probably run over your dog and your wife before next Friday. Instead, you test them for the requisite understandings and skills. This, at a minimum, sets the stage for higher performance in the regime in question.
Tip: Just because something is codified into law, doesn't mean it is sensible, practical, or reasonable. In fact, sometimes just the fact that some blithering legislator put it together makes it a pretty sure bet to be really bad law. Age lines in the sand are a primo example of the legal system proving beyond any doubt that it is largely comprised of total idiots.
If people don't like the Constitution of the United States they should probably leave the country and not let the door hit them on the way out.
No. Stupidest meme ever.
If people -- US citizens, generally -- don't like the Constitution of the United States they can (if they so desire) speak up, attempt to build consensus at various levels, and even agitate for constitutional amendment. This radical idea is, amazingly enough, part of that very constitution you so ignorantly think justifies their ostracism.
Slashdot Mirror
Seems like a dick move to me.
Lol. No, it isn't.
IE6 is in use because it depends on incompatible technologies that (most ill-advisedly) must run in the remote client's space. Python, when running as CGI, runs where it should: In the server's space.
IE6 thinking is what led to the incredible Java mess, though. So you're kind of on the right path, but you have to learn how directly polluting the client space differs from making choices within the server space. Here it is: CGI runs on anyone's anything regardless of version. It's a server side tech, and the client does not need to know or care how you got your computing done. Client side tech requires FAR more of the user's platform, and, as you observed, in the case of IE6, can even require a specific platform. I can't even tell you how often I've run into "wrong Java version" or some variant of that. Server side, you don't need to know what language, and I don't care if you're on an old palm pilot or the latest OSX hotness or some mid 2000's version of linux. Because in NO way does hanging with a particular CGI language commit the client to anything. You want to upgrade, go ahead, no harm done. Clear now?
And of course, if Python had been properly written to be backwards compatible, as it should have been, you could just use the latest version no matter what. But, since they broke this and that moving forward, you have to be a little more careful and keep the right environment around. It's not horrible, but it's bad enough that you can't just do it as a matter of course.
1) Python 3 is completely irrelevant to me -- it's a different, incompatible language I have zero interest in.
2) You're misinterpreting advice for libraries with advice for code
So how about YES because....
(a) mixing tabs and spaces has no inherent value,
(b) tabs are higher value than spaces in code because you can change the size of a tab indent with one setting, whereas space indents are what they are and that's the end of it.
(c) Python allows tabs for a reason, and that reason is so you can use them
I've written a lot of Python, am highly effective in that pursuit, and I find the consistent use of tabs to be the way to go. Your advice is bad -- and wrongheaded.
Saw it anyway. Hilarious. :)
[shrug] You're doing it wrong. Mostly because you're stubborn. The technical term for that is "shooting yourself in the foot." You certainly don't have to do it wrong.
The "special" editor I use most often is the one built into midnight commander (mc and mcedit), which, while not specifically designed as a Python editor, works perfectly. Also for Perl, shell scripts, etc. Other times, I use TextWrangler under OSX, which has the additional benefit of being UTF-8 aware, and also handles tabs and spaces in a way that ensures they are easily managed. The benefit is the use of a powerful, clutter-free language with strong visual blocking cues. This is not to say that I can't use vi; because I use tabs exclusively as my leading white space, there's zero confusion on my part about which block is which. I just prefer mcedit, frankly.
Why in the *world* would you mix the two? Just use tabs. This gives you the visual blocking, you can globally change the indents with one move at any time, most decent editors let you see them, they reduce cursor movement keystrokes... seriously man, just apply yourself and it'll all become easy as heck. You're *making* it hard where it isn't hard at all.
Security patches to scripting languages are almost always 100% irrelevant unless you're writing for WAN-facing machines with exposed services. I'm trying to figure out the odds of a deep excursion of the northern polar auroral oval at the desktop, not keep Joe Scriptkiddie from entering Robert');Drop Table Customers; -- into a CGI form.
A really smart car would probably ID a human as a virus and keep the doors locked.
Google will figure it out just as soon as they can display ads on your windshield.
No, but keep telling yourself that.
THIS is why we shouldn't mix ethanol with driver fuel. Stick with straight cheeseburgers, I say.
Why should I accept any pain at all? How about if I just don't upgrade, and my stuff doesn't break, and I continue on making new things? Isn't that more sensible on every possible level?
Until XP, yes. Then the creeping incompatibilities began. First down, window metrics. Buttons, title bars, really just about everything GUI oriented began to creep around (and de-register with pointer co-ordinates) as the new "look" used (required, really) window metrics not available to prior versions. This, of course, leaves out the terror-infused side trip into MIPS, PowerPC and Alpha versions of Windows NT. Anyone for inverted font metrics? Oh, the stories I could tell you...
It's easy for a Python programmer to choose an editor that also knows about whitespace. The rest are good enough that they don't even need to. Personally, given the choice between extraneous { } all over the place and indentation, I definitely prefer indentation. It's fast, it's highly visual, and it reduces display clutter.
...which would be a huge PITA, for no particular reason that I can think of.
If it isn't broken -- don't "fix" it.
There's a world of difference between people who do real work for real money and where things operating or not have consequences, and some abstract idea of "it'd be 'nice' to have the newest stuff." The latter is of no consequence; the former means everything to everyone.
No, but it still introduces significant incompatibility -- things can and will break -- and so re-testing, re-coding, re-certifying... still required. Now, you have two choices:
a) Don't screw with the system, and everything continues to work just fine, no extra costs or problems are encountered, and everyone is happy except the cluetard who write TFA, who no one cares about anyway. Or:
b) You can upgrade, break everything, incur lots of costs, and everyone in every direction is pissed off except said cluetard.
Now, I ask you: what's obviously the best choice here?
The problem with upgrades is the developers don't take nearly enough care to ensure compatibility with existing software. For instance, I moved a Python script from an older machine (redhat 9) to an Ubuntu 12 system with a later 2.x series Python, and the script immediately bombed out. Turned out that I'd used "as" as a variable name, and it had become a reserved word in the interim. Elsewhere, I was adding ints to floats or vice-versa; now that produces an error. Somewhere, the behavior of "global" changed. I had a procedure written with global VariableName up front so the procedure could see a global switch. I handed the script to someone else, and they had to *remove* that to make it work.
I moved a large system depending on perl scripts (yes, I know, not Python, but the issues are identical) across the same machine pair and it was so broken under the new perl that it took me two months (and cost my client a great deal of money) to adequately debug and update it. From external module changes (use DBI) to how references to hashes were handled, it was one thing after another. What made me fume the entire time is that this stuff worked *perfectly* under redhat 9 with the earlier perl -- it really wasn't broken. Bloody perl was broken! Worse, I'd abandoned Perl for Python years ago, and my Perl skills were very rusty... that's tough when you're trying to work through tens of thousands of lines of sophisticated code. I truly regret every line of Perl I ever wrote, and cringe at the idea of having to revisit it for any reason at all, because Perl, whatever its true merits, is a language that I was destined to hate to my very $core;
This kind of thing makes me extremely unwilling to upgrade; for that matter, it can send me hunting for the old version to install in new machines, although that can present its own set of problems and requires at least some of a different skill set than programming that really leans more into system administration, which I am not in the least enthused about. For some strange reason, enjoying research on auroras does not automatically carry with it a predilection for meddling with OS environments.
This is all part of a larger gripe set I have where makers of languages and APIs break existing code in favor of new ideas. Here's my position: If you ship the language with X features, you have NO BUSINESS breaking ANY of those features. You have a new idea? Fine. Implement it as something completely new within the language or the API. If it's got new keywords, provide the programmer a switch to enable them -- words that were not reserved before may have crept into the user's namespace(s.) Never take a call out of an API. Never make an API call work differently. If you think you need to do that, then *I* think you need an entirely new API. If you even use the word "deprecated", I will burn you in effigy and spit on the ashes. Furthermore, if you do it right, you will NEVER need to say "end of life" because the most current version will still run the first code ever written for API or language 1.0; upgrades will actually be upgrades rather than incompatible replacements.
Windows got this very nearly right for a long time, then with XP, they began to break everything from window metrics to system calls. By the time Windows 7 rolled around, apps that worked perfectly looked like trash and worked even worse, and I tossed my Windows machine in the can both for development and as a user. Apple's guilty of this too, even going so far as to obsolete their own applications and feature-sets. One really irritating example of this is having bought Aperture 1, 2, and 3 for OSX 10.6, I bought a new camera, a Canon EOS 6D. Works *fabulous*, pretty much the first DSLR I've ever been actually satisfied with. Both Lightroom and Aperture required an update to read the RAW images. Lightroom upgrade went smoothly. The Aperture upgrade? Told me that in order to install the updated RAW support, I'd have to upgrade the OS. But 10.7 and later are not highly compatible upgrades, I have to support OSX
[shrug] -- like I said, it's poorly enforced. There are plenty of illegal, unconstitutional laws and practices. Doesn't make them right. Just makes them tools of the oath breakers.
Yeah, sorry about the profanity. Your baseless strawman had me pretty steamed.
No. There doesn't, and I am not doing anything of the kind.
When I bother to waste my breath explaining it, I advocate competency testing as the line to be crossed, because age is a fucking stupid metric. Now, you show me a four year old that can pass a well administered and conceived firearms, voting, or sexual issues test with flying colors, then you can point the finger at me. The problem with the age line in the sand is that it does exactly that: It unreasonably qualifies people who are obviously unqualified without any relation to competence at all.
Would you put someone on the road without a driving test, just because they're 21? No? Then why the FUCK would you be willing to hand over weapons, allow them to shag your daughter, etc. for the same reason?
Age. Fucking useless metric. Causes no end of misery and pain.
Nope. 14th amendment. No state can violate anything in the bill of rights "downstream", as it were. It's very clearly written. Not that it's well enforced, but it *is* clearly written.
Those rights are not "protected" by the constitution. Those rights are named for the benefit of the government, specifically in aid of explaining to said government that they are not to be fooled with.
Which said government roundly ignores today, but still, that's what it is: restrictions of government action. Not protection of your action, unless you're speaking in the vague sense of being protected from your government, which, sadly, the constitution has not been adequate to do, as it has absolutely no teeth -- if government chooses to ignore any particular thing, nothing happens to anyone. Without people of strict honor in the government (not happening) and the judicial system (also not happening) and law enforcement, the constitution is truly of little value to us.
Clearly.
Other than amendment 26 (sets voting age to 18 years), your "recognized" issues are not codified in any way in the constitution. The rest is all legislative product, with the occasional collusion of constitutionally ignorant feeble minded fools at the bench.
Guess you weren't around when the government thought we were old enough to go fight and die in Viet Nam, but not old enough to have anything whatsoever to say about it.
I was there. I was in that exact demographic.
So I *do* have a problem with it. It's fucking abusive.
Flash forward to today: There are plenty of minors I'd trust implicitly with a weapon, or a vote, or my daughter's sexuality. Contrariwise, there are plenty of adults I can think of -- without even trying hard -- that probably shouldn't be allowed to handle weapons, ballots, engage in sexual activity with others, or handle sharp objects, until someone takes them aside and bloody well trains them, rather thoroughly, in all of the above.
Lines in the sand defined by age are both wrongheaded and ineffective. Would you hand the keys to a car to a person because they reached some particular age? No. Because they'd probably run over your dog and your wife before next Friday. Instead, you test them for the requisite understandings and skills. This, at a minimum, sets the stage for higher performance in the regime in question.
Tip: Just because something is codified into law, doesn't mean it is sensible, practical, or reasonable. In fact, sometimes just the fact that some blithering legislator put it together makes it a pretty sure bet to be really bad law. Age lines in the sand are a primo example of the legal system proving beyond any doubt that it is largely comprised of total idiots.
No. Stupidest meme ever.
If people -- US citizens, generally -- don't like the Constitution of the United States they can (if they so desire) speak up, attempt to build consensus at various levels, and even agitate for constitutional amendment. This radical idea is, amazingly enough, part of that very constitution you so ignorantly think justifies their ostracism.