Slashdot Mirror
Python 3.3.0 Released
An anonymous reader writes "After just over a month of release candidates, the final version of Python 3.3 launched today. This version includes new syntax, including the yield from expression for generator delegation; new library modules, including fault handler (for debugging crashes), ipaddress, and lzma (for data compression using the XZ/LZMA algorithm); a reworked OS and I/O exception hierarchy; the venv module for programmatic access to Python virtual environments; and a host of API changes. The full list of features and the change log are both available."
* Even slower than before, however impossible that may seem
Is anything major using Python 3 already? Most distributions still use Python 2 as their default Python interpreter, the big libs (twisted and Django come to mind) aren't ported yet. Is there any reason to use it?
And...But...I just downloaded 3.2 -_-
I'm waiting for that
While I like some of the changes in python3, breaking compatibility with python2 was a huge fail.
From python3 release notes (dated December 3rd, 2008):
'''Python 3.0 (a.k.a. "Python 3000" or "Py3k") is a new version of the language that is incompatible with the 2.x line of releases. The language is mostly the same, but many details, especially how built-in objects like dictionaries and strings work, have changed considerably, and a lot of deprecated features have finally been removed. Also, the standard library has been reorganized in a few prominent places.'''
This was four (4) years ago. Major linux distributions are still on python2. Many python2 packages are still hard to come by for python3. Popular libraries (for example opencv) still link to python2. Even google searches for python docs go to python2.
Python 2.7.3 is the new IE6.
One reason why Python 3 hasn't taken off is that it didn't adopt .py3 as a file name suffix for Python 3 programs. This makes side-by-side installation of Python 2 and Python 3 much more difficult. Does Python 3.3 yet have a feature where I can have both Python 2 and Python 3 installed on a PC running Windows, and double-clicking a .py file in Windows Explorer runs the correct interpreter version? Until that's fixed, with a .py handler that starts Python 2 or Python 3 depending on future statements or the shebang line, Python 3 won't take off.
if any of y'all want to have some fun then take a stab at converting MakeHuman to Python 3.* (please note if you can get it to run contact the Project Managers)
Of course if you want to play with an Open Source version of Poser you can also have fun.
Any person using FTFY or editing my postings agrees to a US$50.00 charge
Atleast better than .ps1-files (powershell scripts) which is named ".ps1" for all released versions, 1.0, 2.0 and 3.0.
Atleast better than .ps1-files (powershell scripts) which is named ".ps1" for all released versions, 1.0, 2.0 and 3.0.
Sony might have objected had PowerShell scripts been named with the interpreter version in the manner that you appear to imply. PS2, for example, was taken twice: one by an IBM PC model that introduced the keyboard and mouse connector used for years before USB, and once by a game console.
but when will they replace that stupid whitespace shit with {/} or begin/end blocks?
The trouble with Python 3 is that nobody took responsibility for converting the third-party libraries. Many major libraries became abandonware in that transition. Rather than converting the old ones, in some cases, new incompatible libraries were developed. So not only do you have to convert your code from Python 2 to 3 (for which there is a tool to help), you have to change your code to use new libraries. Python doesn't have enough market share that major projects like MySQL and OpenSSL maintain the Python bindings for their project. At one point, the Python binding for OpenSSL was maintained by a World of Warcraft guild.
Perl has CPAN, which actually hosts library source and has some Q/A functions. Python just has PyPi (formerly "Cheese Shop"), which is just a directory of links.
This is Python's real problem. Python's Little Tin God For Life doesn't want the headaches of managing library maintenance. But he's not willing to let go and turn control over to an organization that can manage the grunt work of getting all the parts to work together. That's also why there is no Python ISO standard, and why none of the implementations other than CPython support 3.x.
There's usually no need to make the implementation language user-visible.
I agree in some cases, such as on a Linux or *BSD server where shebangs or rewriting or type-maps or MultiViews can safely keep the implementation language out of the URL space. But on the Windows desktop, Microsoft tried this with "Hide extensions for known file types", and it led to all sorts of trojans where the user didn't realize that what the user thought was a document was actually an executable.
The launcher is added with 3.3
Thank you. Side-by-side on Windows was broken in 3.0, 3.1, and 3.2, but now that it appears fixed, one more obstacle to adoption of Python 3.3 is out of the way.
Suddenly python pops up? Lol. I bet you can't code for shit.
Well, for one thing C is so basic, that there are fewer places that it needs to adapt. Even so, it *REALLY* needs to improve the handling of unicode strings and utf-8 files. This can't be patched by add-on libraries. And for my purposes, garbage collection would be a real benefit. (I mean standard garbage collection. And a decent garbage collection would mean that you couldn't freely inter-convert integers and pointers, or do pointer arithmetic, though properly constrained pointer arithmetic is feasible. [See Vala.])
If your purposes are different, it's reasonable that you may not need these features. But don't presume that everyone has your same use case.
I think we've pushed this "anyone can grow up to be president" thing too far.
It's a part of PEP 380, which is mostly about "yield from", but this little gem actually matters elsewhere. You can now return values from iterators. I.e.:
Since return from an iterator just raises StopIteration exception, they've added a field to propagate the value. Previously you could only use the no-argument return.
Why this matters is because it gives you the final bit needed to provide full syntactic sugar to write asynchronous functions (task-based, chained callback model - think Node.js, or Twisted in Python land) as if they were synchronous, except that you use "yield" at the points where you want to cooperatively yield control. Of course yield is the bigger part of it anyway, and it was there before, but you had to use some magic function call to implement final return. Now it really looks exactly like a synchronous function, except for "yield".
>unicode strings and utf-8 files
C11 supports this.
>garbage collection
One of the worst ideas for a language. I can handle my own memory usage, thanks; I don't want the program to automatically deallocate things when I don't need or want it to. A program should be predictable, not on the whim of an interpreter that decides to deallocate everything during a critical section of code.
There sure are a lot of posts here declaring what various people think "went wrong" with python 3. I find it pretty funny that each post describes a different perceived problem, yet reveals a similarly self-absorbed view, and in many cases a presumption that the 2-to-3 transition should have been universally complete by now. Folks, consider this: A project might not actually be a failure just because it's different from whatever you're used to.
What's wrong with .sh for your Python programs?
The fact that I'd have to replace Windows Explorer on end users' Windows PCs with a UNIX style shell. This was a problem until Python 3.3, which associates .py files with a limited shebang interpreter as AC mentioned.
Whether you can handle your own memory management or not depends on what you are doing. In relatively small applications it's no problem. Start getting larger, and you can't tell which processes are using, or going to use, which pieces of memory. It does, however, place constraints on what lower level operations are allowed. But so does parallel processing in general, even if it's small enough that you CAN manually handle memory allocation.
FWIW, even algorithmic garbage collectors run into problems when one is processing multiple streams of instructions, which is why so many languages are currently stressing immutable or final data allocation. That way data can safely be copied from place to place. But for this to be possible, any included pointers MUST be managed by the language, not by the programmer.
OTOH, for small programs, garbage collection does slow everything down, so in that context you have a good point. But that's not the entire context that computer languages need to handle.
Am I recommending that C adopt mandatory garbage collection? No. But I am recommending that it be built into the language. It could be a compile-time option, which, if enabled, would forbid certain kinds of activity (casting pointers back and forth to integers, etc.), and allow the compiler that handle the allocation and freeing of memory. This allows one to be maximally efficient when that's what's needed.
OTOH, I can see an argument that C should remain closer to the metal. But it's been moving away from that for a very long time. Still...perhaps it's best that one major language keep as much purity (in the sense of close to the metal) as reasonable. But do note that this is an argument against including even ASCII string literals in the language, and realize that you don't really want to be as pure as possible, or you'd be using assembler, and not even a macro-assembler. (I suppose that since there's memory mapping hardware that these days relocatable assembler code *is* close to the metal. Once it wasn't.)
I think we've pushed this "anyone can grow up to be president" thing too far.
Test comment
delete this test