Python Family Gets a Triplet Of Updates 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.
The Python Launcher (Score:2, Informative)
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 (Score:5, Informative)
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)
Re: (Score:2)
It doesn't make .py files executable (there's no way to make a random file executable in Windows unless it's an actual executable). However, Python interpreter associated .py files with the launcher, so that they're run when double clicked in Explorer and anything else that hooks into OS program association settings. From command line, though, you still need to type the usual "python foo.py".
Re: (Score:2)
Here's a list of tools that will help with that [freehackers.org]:
Py2exe
PyInstaller
cx_Freeze
bbfreeze
py2app
Re: (Score:3)
Re: (Score:2)
Where is the 64 bit dongle support (Score:5, Funny)
2.7.4 (Score:5, Interesting)
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: (Score:3, Interesting)
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 (Score:4, Informative)
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: (Score:2)
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.
Re: (Score:2)
At least one installation I know about still has only 2.5 and will likely never get updated to anything newer. This is not an uncommon situation, so to the tools I use have to support 2.5 upwards too (2.4 support just disappeared last year). Which means any solution for supporting Python 3 would need to allow for that.
Not that surprising (Score:2)
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 (Score:5, Insightful)
Re: (Score:2)
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: (Score:2)
Re: (Score:2)
I disagree. Python 3 uptake has been really slow. The result is that a lot of the good stuff in the Python 3.x series isn't in wide-spread use yet, and if you're writing reusable library code, you can't really assume the majority of your users will have access to it yet.
Guido should have said: we'll break these things we have to break, and for the rest add shim layers with deprecation warnings instead of just opening the gates. That would probably have seen much faster adoption rates.
The gradual approach ha
Lua tables vs. JavaScript objects (Score:2)
Mutability (Score:2)
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: (Score:2)
Re: (Score:2)
Agreed! The curly braces exist /primarily/ for the computer, not the humans reading/writing the code.
Re: (Score:2)
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: (Score:3)
I just use % for e.g. matching parentheses, but see e.g.:
http://stackoverflow.com/questions/896145/more-efficient-movements-editing-python-files-in-vim [stackoverflow.com]
Re:Not that surprising (Score:5, Insightful)
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: (Score:2)
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 otherw
Re: (Score:2)
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 impl
Re: (Score:2)
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
Re: (Score:2)
"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 Transla
Re: (Score:2)
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.
Err, same to you. You're just brushing me off with "But it didn't happen to me!"
To an extent perhaps, but I also tried to articulate that it /wasn't/ just me: not only are there gobs and gobs of people using these types of languages without constantly falling into these pitfalls, I have also witnessed firsthand the same thing across several companies, many projects (of all levels of scale and complexity), and many developers (of all ranges of experience with the language). So while I do readily understand how these problems could happen in theory, I think it's significant that after al
Re: (Score:2)
Well, that's what I keep repeating - whatever someone does to indentation of brace-delimited code, you can easily make it readable. It's just a matter of presentation.
If someone sends you a snippet of code and somewhere along the road indentation gets stripped by inconsiderate software (don't tell me it never happened to you), as long as it didn't break the block markers, you can just hit "reformat" in your code editor and start reading and understanding it. In Python's case indentation is block markers, so if it's longer than 3-5 lines, you can just hit "reply" and ask your respondent to send it again and stop using dated software. I'd say it's pretty clear which one helps understanding and readability there.
IOW, explicit markers = original author can write how he pleases, software inbetween can do how it pleases, reader can get it presented how he pleases, implicit markers = all three stages have to be aware of restrictions. At least, reader can change indentation from 3 spaces to 4.
So is the contention that code needs to be sent through unreliable media a lot?. The issue is not really one of explicit vs implicit block delimiters (in both Python and e.g. C the delimiters are quite explicit and part of the syntax), so we're talking about cases where you're allowing the code to be transferred /and modified/ en route - a byte-for-byte transfer of the code doesn't introduce any errors, it's only cases where you are assuming it's acceptable for modifications to occur. Again, yeah, it could
Re: (Score:2)
So is the contention that code needs to be sent through unreliable media a lot?
No, contention is that this can happen at all, and there's likely no way to reconstruct the code afterwards. You were talking about implicit blocks as evolution of languages, but this evolution makes unhealthy assumptions about every media and every program only doing verbatim transfers. This is far from reality.
I was talking of programmers doing less busywork just to satisfy the language as the evolution of languages. As far as verbatim transfers, to me it seems strange that a language designer would spend any time at all trying to worry about the case where code might be copied through some medium that can't be relied upon. Not saying it can't be a problem, just that it seems to be far outside the realm of what a language designer should care about.
But regardless of which way you end up on this, I have to emphasi
Re: (Score:2)
I would argue that it's a feature. Dig up that old C code with the defective indentation in a few years and I'll bet you'll read it wrong even though it compiles fine.
OTOH, the python code has to be indented correctly for reading or it won't work at all.
Re: (Score:2)
(hint: if you're completely honest, you'll almost certainly come up with different answers for #1 and #2 :) )
You must free your mind even more, grasshopper.
I don't see why #2 would be different from #1.
Try the experiment I suggested and then you'll see.
What makes you (reader) think a byte is "stronger" than another for a parser ?
Nothing, because I don't think that. Try the experiment, and re-read my posts.
I find the mindstate about spaces being "weak" chars annoying.
Er... okie dokie. I'm not suggesting that spaces are weak characters, so if that's the conclusion you've reached I encourage you to re-read my post, as well as those in the related sub-thread.
I still encourage you to try the experiment for yourself, but here's the answers to the earlier two questions:
1) indentation - many people would recognize this intuitively, but if you don't,
Re: (Score:2)
Most people /use/ both in typical modern languages of course; but in terms of conveying the structure of the code to a person reading it, the whitespace is more significant (that's the point of the suggested experiment - to give you first-hand knowledge of the relative importance of each, independent of the other).
It's not "wrong" that both are used, but this whole sub-thread is in response to the implication that Python is somehow broken because it doesn't have the braces. But what Python has done is neith
Re: (Score:2)
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.
I have two problems with that.
1: There is no reason whatsoever that a code editor couldn't automatically and dynamically handle the indenting. "Human readable code" is basically a myth, because it takes a properly-configured computer to render a series of magnetic polarities into a series of ASCII/Unicode characters and display them on-screen. Any computer recent enough to run something like Python is powerful enough for dynamic code management. I could be writing code with Python-style spacing, and the
Re: (Score:2)
1. Why bother? The language can support it natively, so why not just do that?
2. It should never reach that point - it sounds like your code is convoluted and poorly laid out. If the cost of the function call is actually affecting your program, then the code you are talking about is hugely performance-sensitive, and should probably be offloaded into an extension module.
Re: (Score:2)
My problem is that I'm generating a huge dataset -- at last count I had over 797,000 items in it -- as permutations of a few dozen atomic items and several dozen combinable rules. Using explicit, clear labelling (for function names, arguments and variables) is good practice, but I keep running out of horizontal screen space even before I include much nesting. It provides a disincentive to me from using clear naming conventions, and also from using parameterised/named function arguments (which are essentia
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
but the gains from improving the language far outweigh those.
No, no they do not. Unless you don't have to maintain a very large codebase. Then it's no problem.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
That's fine, go ahead and use Python if it suits your purposes. I'm going to use some other language that doesn't make me rewrite my code at the whim of the creator.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
The 2.x->3.x transition is the one and only time I have seen any breakage. Even there, there are pools that come with the distribution that assist with the porting effort.
I am slowly but surely bring all of my code forward, with no issues thus far.
Re: (Score:2, Interesting)
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: (Score:2)
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: (Score:2)
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
Re: (Score:2)
That's exactly what I was driving at. It's simple. It's clear, and it's far easier to type.
The problem is avoiding garbage like this:
dir asdf qwer, wert poiu, gfds bvcx
Do you parse this as:
dir( asdf(qwer) ), wert(poiu), gfds(bvcx)
Or as:
dir(asdf( qwer, wert( poiu,gfds(bvcx) ) ))
It's not immediately obvious or clear. Thus, great care would need to be taken in designing the change. First word only (first alnum token) would avoid problems like this, but wouldn't be real elegant.
Re: (Score:2)
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 o
Re: (Score:2)
So, out of curiosity, how do you handle strings in other encodings, such as Shift-JS or EUC-JP?
Re: (Score:2)
You need to know that strings in other encodings are in those encodings, however allowing the string to contain an arbitrary sequence of bytes, rather than limiting it to valid UTF-8, will allow you to defer the decision about handling the alternative encoding until usage of the string, rather than having to do it during storage and copying. This is usually a lot easier and failures are more predictable and understandable.
It is also extremely easy to distinguish UTF-8 from another encoding, because a huge m
Re: (Score:2)
If you want to work with byte arrays, then use byte arrays. Python API gives you that ability.
Strings are more than byte arrays. By definition, they are meaningful sequences of human characters, not bytes, and they provide operations that are only sensible on such sequences (like, say, length in characters). If you're using them to store random data which may or may not be a valid string, you're doing it wrong. It's like complaining that you can't store random bit patterns in a double - well duh, that's not
Re: (Score:2)
Yes, you can use byte arrays everywhere in every api. But that kind of defeats the purpose of Python strings, since you are no longer using them!
And a 1000-byte UTF-8 string with a single error in is 99.9% UTF-8 characters. In fact I may not be able to figure out it is this magical "not UTF-8" without a very expensive scan! That is incredibly stupid.
You know your precious UTF-16 can have errors, too? Did you notice that nothing throws exceptions on them? Think hard about why this is, rather than spouting id
Re: (Score:2)
If you have a string of bytes that MAY be UTF-8, it can be used in an incredible number of ways. For instance it can be the name of a file. It can be data in that file. It can be copied from one file to another. It can be passed to some code that checks to see if it is UTF-8.
You seem to be under the impression that somehow I want ASCII. That is absolutely false, and the problem is that this refusal to handle invalid sequences is by far the biggest thing FORCING the use of ASCII (or other 8-bit codes where t
Re: (Score:2)
If you have a string of bytes that MAY be UTF-8, it can be used in an incredible number of ways. For instance it can be the name of a file.
How are you going to encode invalid UTF-8 into an UTF-16 string to store on NTFS and UDF (and, I believe, also HFS+)?
Re: (Score:2)
How to encode invalid UTF-8 into UTF-16 for NTFS filenames
Python itself is the originator of the most popular mapping that preserves errors. In this case the error bytes (which are only going to have the high bit set and thus in the range 0x80-0xFF) are mapped to the UTF-16 code units 0xDC80..0xDCFF. These are unpaired surrogates and thus technically the UTF-16 string is invalid as well, which is a nice property.
These are not unique mappings, as most UTF-8 to UTF-16 encoders will convert the 3-byte UTF-8 e
Re: (Score:2)
Concrete example: You have a filesystem that stores filenames as strings of bytes and any byte sequence is supported. You want to encourage use of UTF-8 for these filenames. Figure out how to write something in Python that can rename a file with a "bad" filename (ie invalid UTF-8) to have a "good" filename that is valid UTF-8. You must use the Unicode api.
You will quickly find that this is impossible. Instead you have to use some other API, one THAT IS NOT UNICODE. That is absolutely the wrong direction. No
Re: (Score:2)
A UTF-8 string with an "error" in it is NOT a "not an UTF-8 string object". It absolutely is a UTF-8 string but it has an error in it. This should be plenty obvious with simple transforms: append an error to a UTF-8 string can't possibly change it's type to "not UTF-8" because if you take a substring near the start it suddenly IS UTF-8 again, which is not true of a byte array which would remain a byte array!
More to the point, if there is a mistake it is MUCH more useful to display as much of the string as p
Re: (Score:2)
A UTF-8 string with an "error" in it is NOT a "not an UTF-8 string object". It absolutely is a UTF-8 string but it has an error in it. This should be plenty obvious with simple transforms: append an error to a UTF-8 string can't possibly change it's type to "not UTF-8" because if you take a substring near the start it suddenly IS UTF-8 again, which is not true of a byte array which would remain a byte array!
By this argument, a sequence of bytes representing a 64-bit double will remain a double "with errors" no matter how many bytes you append (or prepend) to it - after all, if you truncate enough bytes, it's a valid double again!
Your logic is broken. Appending "an error" to an UTF-8 string should not be legal in the first place, because the types are not compatible. If you want the types to be compatible, you represent both the string and the "error" as byte arrays, and then concatenating them yields another b
Re: (Score:2)
You seem to have forgotten that a string is an ARRAY. Adding a multiple of 64 bits of garbage to an array of 64 bit doubles, you will have a larger array of 64 bit doubles (in case you can't figure out how to do this in your favorite language, imagine binary i/o of a data structure containing such an array). I am unaware of any language where it turns into a "not a 64 bit double array" because one of the doubles has an invalid pattern. In fact all I/O in modern systems prints "NaN" or even the entire bit
Instead of Pygame (Score:3)
Re: (Score:2)
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
Re: (Score:2)
And that's python's fault, and not Red Hat's?
Re: (Score:2)
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 pa
Re: (Score:2)
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, su
Shebangs, shebangs.... (Score:2)
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
Re: (Score:2)
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:2.7.4 (Score:4, Insightful)
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...
A feature still missing (Score:2, Insightful)
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 sam
Re:A feature still missing (Score:4)
Re: (Score:2, Insightful)
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: (Score:2)
Re: (Score:2)
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?
I think the problem is, what Python community considers good documentation does not match what I consider good documentation.
Many parts of Python docs are quite ok even to me, and I guess it's mostly issue with presentation, cross-linking, and how the whole thing is split into chapters. Also, I think the bad parts are more concentrated on areas used by less experienced Python programmers, seldom really used by those who might get around to fixing them. It could possibly be fixed just by modifying documentat
Mac OS X Python madness (Score:2)
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 take
The python foundation installs into
Re:Add curly braces and you have C (Score:5, Informative)
[...]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: (Score:2)
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
Re: (Score:2)
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).
Re:Add curly braces and you have C (Score:4, Informative)
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.)
Re: (Score:2)
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.
Re: (Score:2)
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....
Re: (Score:2)
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 perf
Re: (Score:2)
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 (Score:2)
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
Re: (Score:2)
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 tha
Re: (Score:2)
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 t
Master Craftsman (Score:2)
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: (Score:2)
Re: (Score:2)
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 an
Re: (Score:2)
Or something like that.
Re: (Score:2)
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: (Score:3)
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: (Score:2)
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
Re: (Score:2)
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....
Re: (Score:2, Insightful)
it's indeed not a language intended for code monkeys. feel free to move along. here, have a banana.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
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!