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.
I'm used to languages like C and C++ actually taking time and creating a standard from which to program from. Suddenly python and other "languages" pop up with rapid-fire updates and changes and breakages over versions, and people praise it like it's the second coming. This isn't a program where things can change and people just adapt; this is a *programming language* that has to maintain older code as relevant, more so since it's an interpreted one, not a compiled one.
How can this be? C has had only a few "versions" over the last 30+ years, and new versions certainly hasn't significantly *broken* older code.
I can't take languages like this seriously.
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.
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".
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.
Test comment
delete this test