
Python 3.3.0 beta 1 released - hynek
http://mail.python.org/pipermail/python-dev/2012-June/120790.html
======
saurik
It continues to be dissapointing that new releases of Python continue to be
useless due to the (I will claim needless and arbitrary, although I could
totally argue the other side if forced: I am not ignorant of the reasons, I
just disagree with the opinions) decision to make the new builds incompatible
with the previous ones (and in some cases for the obvious worse, such as how
Unicode is now less correctly handled when iterating filenames in
directories).

I mean: I do almost all of my "business logic" coding in Python these days,
and yet when I hear of a new version of Python it carries as much weight to me
as a new version of COBOL (which, honestly, probably has more use cases, and
almost certainly more users, than Python 3.x). This is the first time I have
simply totally felt stranded by a development environment since Microsoft
abandoned Visual Basic and replaced it with "Visual Fred" (aka, Visual Basic
.NET): and in that case I had already jumped ship to C++ years earlier.

At this point, the cost of trying to get all the libraries I rely on set up on
3.x--especially when a ton of them have decided either 1) to slightly change
the semantics of the API "as everything is breaking anyway" or 2) that they
are obsolete and that you should use some other newer library if you want 3.x
--is sufficiently high that one may as well switch to an entirely different
language (in my case, probably Clojure).

~~~
hynek
I respect your opinion and maybe you’re in a unique position that makes Python
3 really awful to you, but in general your comment seems more like a knee-jerk
"lolpython3" reaction that was appropriate while 3.0 & 3.1. But now, that
situation changed.

Many, many high profile projects are already on Python and many will follow,
now porting has been made even easier.

Django tries to support Python 3 with 1.5, Pyramid already does support it,
Twisted has a GSoC student that tries to bring it to Py3… And funnily enough,
“normal” code that doesn’t screw around too much with advanced features is
rather trivial to port. I have written a Python 3.2 program myself only to
find out later that it also works on Python 2.7 without changes. :)

With every bigger change you lose some – and I’m sorry if it’s inevitably you
– but you also win some. Because all in all, Python 3 is great.

~~~
sho_hn
There's a bunch of developments that make me feel that the Python 3 ball has
started rolling in a much more significant way lately. Some you've already
mentioned; another is Canonical insisting on everything in the "main" section
of Ubuntu running on Python 3 by 2014, and doing some of the work to make that
happen.

~~~
briancurtin
> another is Canonical insisting on everything in the "main" section of Ubuntu
> running on Python 3 by 2014, and doing some of the work to make that happen.

Everything on the install CD is planned to be Python 3 by this fall. I'm
already working to port what's necessary for Ubuntu One.

------
sigzero
I think 3.3 is going to be an awesome release myself:

    
    
        * Reworking of OS and I/O exceptions
        * Built-in virtualenv
        * yield from (proxy generators)
        * Old Unicode literals allowed (but no-op)
    

Just to name a few...

~~~
nine_k
Yes, finally a 3.x release that made me seriously consider switching from
2.6+.

------
ConceitedCode
It's great to see virtualenv apart of python now.

~~~
k_bx
if only virtualenvwrapper would also somehow got there :)

~~~
mattdeboard
I am generally opposed to including the batteries for things but in this case
I agree. The virtualenvwrapper API and path/folder management is far superior.
That being said, maybe that IS the API that's included in this release, I
don't actually have any idea.

------
gouranga
I feel there is too much churn in Python. No-one is ready to say "we're
stopping here and bug fixing". It just churns and churns and everyone gets
confused. It's too much of a rollercoaster to trust at the moment and I assume
this is why a large number of Linux distributions are stuck on 2.6 and 2.7
still.

~~~
sho_hn
> I assume this is why a large number of Linux distributions are stuck on 2.6
> and 2.7 still.

This doesn't match my experience at all. Most distributions I can think of had
no problem replacing 2.6 with 2.7, and have offered fresh Python 3 packages
alongside them as well for years now. My distro of choice (Fedora) has dozens
of Python 3 libs packaged.

Ubuntu is aiming for "no Python 2 in main" by 2014 now, and Arch even switched
to Python 3 by default already.

I'd go as far as claiming that the distros are actually at the forefront of
and partly driving the transition right now.

~~~
pdeuchler
"Most distributions I can think of had no problem replacing 2.6 with 2.7, and
have offered fresh Python 3 packages alongside them as well for years now."

That may be well and good for startups, or smaller companies, but larger
companies with infrastructure running on CentOS/RedHat (and old-ish versions
of them at that) still have trouble with Python 3. In CentOS 5 if you change
the default python distribution to 3.0 > yum _completely_ dies. Not to mention
various other little bits and pieces.

~~~
sho_hn
Hm, so? It's not like you need /usr/bin/python to be Python 3 to use Python 3,
especially considering that Python upstream is recommending for it to remain
pointed at Python 2 for now and essentially guaranteeing/mandating the
existence of /usr/bin/python3. I doubt there's any Python 3 code out there
that is meant for public consumption and relies on /usr/bin/python being
Python 3.

~~~
pdeuchler
Please note I do make the distinction of the _default_ python distribution
(aka /usr/bin/python). Some companies that aren't startups cannot or will not
(policy or otherwise) either maintain separate installs of python on hundreds
of servers, or require use of the default install.

~~~
sho_hn
Even if that separate install is a regular package of the distribution? I get
not wanting to install from third-party repositories or even building your own
(I try hard to avoid both myself, and there are good reasons not to want to
invite that deployment overhead), but consider regular packages to be non-
scary.

------
ushi
LZMA support - YES! I am waiting for this so long. I hope it is not horribly
slow.

~~~
andreasvc
I find it really strange that every compression format gets its own top-level
stdlib module. Why not compress.lzma and compress.gzip etc., or even
compress.open(..., format="lzma") ? It seems ad-hoc and disorganized to me.

~~~
sigzero
Try opening a PEP...and volunteering to move them into that namespace. I
actually think that is a good idea myself.

------
dvirsky
Wasn't cPython going to have some sort of JIT in 3.2 or 3.3? Or did I miss it?

~~~
densh
I've never heard of any plans regarding JIT in CPython. You might have mixed
it up with PyPy or Unladen Swallow. Both of them use JIT to speed up their
python interpreters.

CPython developers quite often expressed their opinion against having JIT or
more sophisticated GC because such changes would make Python interpreter too
complex. (See Guido's keynote from last PyCon.)

~~~
the_mitsuhiko
> I've never heard of any plans regarding JIT in CPython. You might have mixed
> it up with PyPy or Unladen Swallow. Both of them use JIT to speed up their
> python interpreters.

Unladen swallow was supposed to be in CPython at one point.

------
henryl
I hate to be _that guy_ , but the key thing on my mind and the thing that
constantly pushes me towards hybrid solutions: performance. Whats the verdict?

~~~
scott_w
I don't know about the performance of Python 3.3; although I think that if
performance is critical, then you should be looking at something other than
Python (or a hybrid solution, as you say).

~~~
dbaupp
There a few options that allow you to stay (mostly) in Python: Numpy/Scipy for
numerics; using Cython[0]; or using an alternative interpreter (specifically
PyPy[1]).

(This assumes that your specific use case is covered, e.g. PyPy doesn't
support Python 3 yet.)

[0]: <http://www.cython.org/> [1]: <http://pypy.org/>

------
ghostrockt
we can all agree that the decision to make python 3.x incompatible with 2.x
has greatly fractured the community. regardless of one's opinion on the
matter, this divide is hurting the community. how long until we actually come
to resolution on it?

~~~
briancurtin
What resolution do you want to hear?

------
est
[http://docs.python.org/dev/library/ipaddress.html#module-
ipa...](http://docs.python.org/dev/library/ipaddress.html#module-ipaddress)

Am I the only one worries that Python is slowly turning into Java?

Instead of simple text/string for everything, now Class for everything, with
nauty weird ill-defined Exceptions.

~~~
irahul
> I am worried that Python is slowly turning into Java. Instead of simple
> text/string for everything, now Class for everything, with nauty weird ill-
> defined Exceptions.

The example your are pointing out is for the module ipaddress which is for
inspecting and manipulating ip addresses. It's not that Python now requires
you to use ipaddress objects in place of strings for sockets.

~~~
est
> It's not that Python now requires you to use ipaddress objects in place of
> strings for sockets.

In that case it's good to hear.

