Slashdot Mirror
Python Family Gets a Triplet Of Updates
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.
Are you proposing that there are languages that could be considered not to be shitty?
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?
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?
It's called C, foo.
Python needs to support larger dongles.
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.
Trust the Computer. The Computer is your friend.
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.
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!
hair-raisingly complex
You're an idiot.
extremely bloated
Nonsense.
poor libraries
Maybe.
quite limited functionality
Ridiculous.
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.
I get it, don't allow facts to get in the way of a good quarrel. ;-)
Ezekiel 23:20
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.
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 , this is the same as read()
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 :-)
[...]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?
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 :.
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?
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.
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"
C++ can't be so complex if its fanboys are so simple-minded.
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.
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.
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.
it's indeed not a language intended for code monkeys. feel free to move along. here, have a banana.
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!
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.
I won't join Slashcott. OTOH, If Beta goes live, I just won't be back until it's fixed. Sorry Dice.
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.
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.
"Little does he know, but there is no 'I' in 'Idiot'!"
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.
"Little does he know, but there is no 'I' in 'Idiot'!"
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. /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.
The python foundation installs into
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?
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.
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".
Ezekiel 23:20
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.
http://saveie6.com/
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!
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.
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) ) as the key.
Static and dynamic typing each have their advantages ya know.
Then why not have both?
Maybe, from a CS point of view, any index should always be zero-based.
And even that isn't particularly clear. The only real good argument for starting indexes at zero is that it's more efficient in some cases. Other than that, it's entirely preference. In some languages, like Pascal, indexes start at 1 (or any other number of your choosing).
"First they came for the slanderers and i said nothing."
Maybe some languages do. But if I were to guess, it's probably a couple of things:
- design - it's a pretty fundamental decision in a language's design, and has implications that kind of ripple through everything. Both the language/tool maintainers as well as the users need to be able to reason about how things behave, and having both and not violating the principle of least surprise (among others) might be tricky, I dunno. There's a sweet spot between firm decisions around the "right" way to do things in a language and having a language be flexible enough to do things many different ways; I suspect that doing both would make it hard to remain in that sweet spot.
- resources - it's reasonable to assume that most language designers/implementors have finite resources, so they'd probably prefer to spend them on making new language features or libraries, improving performance, etc. than implementing and maintaing the complexity associated with supporting both.
- philosophy - a language designer probably has an opinion about the general benefits of one vs the other and therefore probably has less interest in whatever that "other" is. It has been shown that both types of languages can be used to build large, complex, reliable systems, so neither has inherent, complete, and overwhelming advantages over the other.
Just guesses though.
The first date when that calendar system was used was substantially later....
True. But, the first date in the Anno Domini series IS 0001-01-01. It doesn't matter when it's use was started or became popular.
The intro crawler at the beginning of the original Star Wars did not include "Episode IV". That system of number was developed later. Lucas can say that he always had nine movies planned out, but he's full of shit. Just like the writers of Lost saying they had the whole story mapped out before the first season.
i doubt there are many languages out there whose implementation isn't written in C, or on a language whose implementation isn't written in C in turn, or in another language with static typing. this doesn't alter the fact that you completely fail to see the benefits of having dynamic untyped languages around, to the extent to say "they are broken". my first guess then is that you must be a code monkey. my second guess is that you are some sort of director/manager of a team of code monkeys. if i'm still wrong, my third guess would be that you have no clue about programming whatsoever. but if you don't like the banana, that's just fine. move along :-)
--
i like bananas!
But back on topic, I'll bet all you homos would love to witness the release of my python.
At least all of us Linux faggots would enjoy seeing that kind of package being released.
Never argue with an idiot. Bystanders won't be able to tell the difference.
Or something like that.
Because of the nonsense at the last PyCon, we're switching to Perl
The only real good argument for starting indexes at zero is that it's more efficient in some cases.
Or more specifically, it's more efficient in a low-level language with compile-time-fixed-length arrays. If your array isn't a fixed block of memory referenced by index+offset, there's no technical reason to have a zero-index. All you're left with is "we've always done it that way". (Which is a fair point considering the number of errors that would arise if people got confused switching from one to the other.)
Got them moderator blues I blieve I walk out the do', With these mod-points I been gettin', I 'most never post no mo'
Static and dynamic typing each have their advantages ya know.
Then why not have both?
What interpreted language does have static typing? Static typing is carried out by the compiler, and we don't have a compiler here....
Anyway, the architecture of Python has particular rules about scoping, and you do not know until a function is called what will be in scope at the time. I have my concerns that this is powerful in a "more than enough rope to hang yourself" kind of way, but it's there, it's part of the language, and (yeah) it's mostly a consequence of being an interpreted language....
Got them moderator blues I blieve I walk out the do', With these mod-points I been gettin', I 'most never post no mo'
And you, in turn, realise that when you drill down your C toolchain, you'll eventually find something called "assembler", which hardly classes as having typing of any description. Integers and floats, and that's pretty much your lot... and nothing stopping you from misreading one as the other.
Got them moderator blues I blieve I walk out the do', With these mod-points I been gettin', I 'most never post no mo'
No, more specifically, it's more efficient in a low-level language where arrays are actually simply pointers to raw memory and indexing is simply syntax sugar for addition and dereferencing. I believe, actual "compile-time-fixed-length arrays" only appeared in C++ and even there their legacy pointerness shows up here and there. Uses of Pascal arrays can be compiled as efficiently as C arrays, whether their index range is stated as [1..256], [0..255] or [char] (in fact accesses to those three will likely look the same after compilation).
Yes, but here's the thing: Python, regardless of version number, identifies itself to the shell interpreter as a single thing by its shebang string -- "/usr/bin/python". It shouldn't do that.
It's broken design -- if you write something that's not backward compatible, you have to give it a new command so that it's different in the shebang, meaning that when a user runs the script, the computer knows which shell interpreter to use.
Recompiling and non-standard installs work, yes, but they also mean your code is no longer portable, because you're using a non-standard execution mechanism.
Guido needs to sort out the shebangs....
Got them moderator blues I blieve I walk out the do', With these mod-points I been gettin', I 'most never post no mo'
I believe, actual "compile-time-fixed-length arrays" only appeared in C++ and even there their legacy pointerness shows up here and there.
C arrays have their length fixed at compile time too, you know....
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 missed the point. Python is not *written* in assembler. It's written in C. If static typing is so bad, then why does Guido use a statically typed language to implement Python? He could have chosen Perl for instance.
What interpreted language does have static typing?.
These came to my mind:
* Dart has an interpreter and supports both dynamic and static typing
* Pike has an interpreter that supports both dynamic and static typing
* TypeScript is a typed superset of JavaScript that supports dynamic typing, but is first compiled into JavaScript
The first two fulfil your requirement. The last one doesn't, but is nevertheless an interesting approach.
You're missing the point. I'll give you a clue: "high-level language". And another: "low-level language". The two have different goals. One is more computer-friendly, the other is (intended to be) either more human-friendly or simply more logically self-complete.
Got them moderator blues I blieve I walk out the do', With these mod-points I been gettin', I 'most never post no mo'
Or more specifically, it's more efficient in a low-level language with compile-time-fixed-length arrays. If your array isn't a fixed block of memory referenced by index+offset, there's no technical reason to have a zero-index. All you're left with is "we've always done it that way".
The actual distinction is not between 0-based and 1-based, but between end-exclusive and end-inclusive - i.e. [0..n) vs [1..n]. There are some languages which tried to do both at the same time, but the result is the worst of both worlds, and unintuitive to boot - e.g. in BASIC, DIM a(10) actually declares an array of 11 elements, indexed from 0 to 10.
So if your upper bounds tend to be exclusive, then it makes more sense to start counting from zero, so that the length of the array is also its starting bound. And exclusive upper bound is pretty convenient in general because of various associated properties - e.g. the length of the interval is then always upper bound minus lower bound, and upper bound is never less than lower bound (when it's inclusive, it is less for an empty interval). Simply put, [0..n) tends to be more convenient in practice because your code will have fewer +1 and -1 in it.
I understand that you want to feel as being the winner of this argument, but it doesn't happen by replacing the premise with something you can easily argue about. What you say about high and low level languages is true, it's in fact obvious, but still besides the point. I'll reiterate the question: if static typing makes one a code monkey, then why did Guido choose to be a code monkey, and not use a language where he wasn't one? He could have chosen Perl or assembly. Neither of them is statically typed, and one is higher level than C and the other lower. Of course we know the answer. It's obvious. Static typing is not such a bad idea that it renders language unusable. There were other practical concerns that were more important than babbling about the evil of static typing.
The other interesting question is why call language broken, when it doesn't have static typing. I can give you a hint: code coverage and readability. These two things become important factors in large code bases. Software projects tend to grow larger than they were intended, and at some point Python's lack of static checking becomes a burden.
I infer that your only exposure to static typing is from Java and C++. In that case, I wouldn't blame static typing, but the overly verbose language in general. Try Haskell for a change.
Then how does it make you feel that your beloved language was then written by a code monkey by your own definition?
You only manage to appear to posses small intelligence when you throw derogatory terms so casually. I doubt that knowing this will make you any wiser, but all your assumptions are wrong.
Then how does it make you feel that your beloved language was then written by a code monkey by your own definition?
in absolutely no way. i know the benefits of static typing pretty well. what i assume is that someone who says "is broken because it's not statically typed" must be a code monkey. at best.
You only manage to appear to posses small intelligence when you throw derogatory terms so casually. I doubt that knowing this will make you any wiser, but all your assumptions are wrong.
my small intelligence suggests you got lost on the very first post of this thread already. reread slowly if you care.
The actual distinction is not between 0-based and 1-based, but between end-exclusive and end-inclusive - i.e. [0..n) vs [1..n]. There are some languages which tried to do both at the same time, but the result is the worst of both worlds, and unintuitive to boot - e.g. in BASIC, DIM a(10) actually declares an array of 11 elements, indexed from 0 to 10.
So if your upper bounds tend to be exclusive, then it makes more sense to start counting from zero, so that the length of the array is also its starting bound. And exclusive upper bound is pretty convenient in general because of various associated properties - e.g. the length of the interval is then always upper bound minus lower bound, and upper bound is never less than lower bound (when it's inclusive, it is less for an empty interval). Simply put, [0..n) tends to be more convenient in practice because your code will have fewer +1 and -1 in it.
I would argue that most newcomers to programming would be more comfortable with an ordinal number, which would imply that the first element is 1 and the final element is "len", and so to look at one end or the other as the "actual distinction" would be to ignore the validity of this argument.
I can't think of any technical situation that benefits greatly from the end-exclusive notation. Javascript's array[n]=((whatever)) is generally frowned upon (implement a .append() method instead!) and array[n+1] is functionally identical if the array is 1...n . The tiny performance advantage in the former assumes that you're statistically significantly more likely to append than to access the last element, which seems counter-intuitive to me on the grounds that you normally read values more often than writing them.
But I'd be genuinely interested in hearing of any technical benefits of [0...n), because I'm geeky like that.
Got them moderator blues I blieve I walk out the do', With these mod-points I been gettin', I 'most never post no mo'
I can't think of any technical situation that benefits greatly from the end-exclusive notation.
Think about STL algorithms and how they specify ranges. It's the same thing really, just abstracted away from numbers.
It's not really about perf so much so as less need to add/subtract ones for typical operations.