×

Announcing: Slashdot Deals - Explore geek apps, games, gadgets and more. (what is this?)

Thank you!

We are sorry to see you leave - Beta is different and we value the time you took to try it out. Before you decide to go, please take a look at some value-adds for Beta and learn more about it. Thank you for reading Slashdot, and for making the site better!

Python 3.4 Released

Soulskill posted about 9 months ago | from the onward-and-upward dept.

Python 196

New submitter gadfium writes: "Python 3.4 has been released. It adds new library features, bug fixes, and security improvements. It includes: at standardized implementation of enumeration types, a statistics module, improvements to object finalization, a more secure and interchangeable hash algorithm for strings and binary data, asynchronous I/O support, and an installer for the pip package manager."

Sorry! There are no comments related to the filter you selected.

Ubuntu Install? (2)

LifesABeach (234436) | about 9 months ago | (#46521583)

That would be nice.

Re:Ubuntu Install? (-1)

Anonymous Coward | about 9 months ago | (#46521653)

who the fuck uses Ubuntu? fuckin' noob ass bitch. Get Debian or get the fuck out!

Re:Ubuntu Install? (-1)

Anonymous Coward | about 9 months ago | (#46521665)

Yo stupid ass mama does!

Re: Ubuntu Install? (1, Funny)

Anonymous Coward | about 9 months ago | (#46523023)

Your Momma Uses My Python, Bitch.

Re:Ubuntu Install? (-1)

Anonymous Coward | about 9 months ago | (#46521849)

gentoo > debian

Re:Ubuntu Install? (-1)

Anonymous Coward | about 9 months ago | (#46522313)

Rolling your own > gentoo

Re:Ubuntu Install? (0)

Anonymous Coward | about 9 months ago | (#46522515)

emacs >= rolling your own
*grabs popcorn*

Re:Ubuntu Install? (-1)

Anonymous Coward | about 9 months ago | (#46522621)

Niggers >> Hipsters > Nerds. Pass me dat popcorn

Re:Ubuntu Install? (1)

gatkinso (15975) | about 9 months ago | (#46523093)

Ubuntu Server is pretty nice actually.

Re:Ubuntu Install? (0)

Anonymous Coward | about 9 months ago | (#46522161)

pyenv?

I already have it installed on my Mac and on my Ubuntu (Kubuntu, awesome, i3, whatever... at this time the only thing *buntu on that box is the kernel).

Re:Ubuntu Install? (1)

wjcofkc (964165) | about 9 months ago | (#46523653)

I am a little confused about your request. On my very modest system, Python takes just under three-minutes to compile from: extract > cd > ./configure > make > make install

I run several Ubuntu derivatives and honestly never considered apt-get - but I also often run more than one version of Python on any given system and compiling manually makes that easier to maintain. If you are a Linux user so stuck on apt-get that you cannot work with source code at all, I highly suggest you download the source from here: https://www.python.org/downloa... [python.org] and give it a try.

Re:Ubuntu Install? (1)

wjcofkc (964165) | about 9 months ago | (#46523863)

In fact I will even get you started:
cd ~/Downloads
tar -zxvf Python-3.4.0.tgz
cd Python-3.4.0
./configure
make
sudo make install

This harmless method will only install python in the directory you built it in. So if you type "python" you will still get the old interpreter. If you type ./python you will get 3.4 - As far as replacing your existing installation completely or doing something more complicated, I will leave it to you to Google that so I don't lead you down an irreversible path you did not intend to go down.

and... (5, Insightful)

Anonymous Coward | about 9 months ago | (#46521627)

And everyone will keep using 2.6/2.7, the windows XP of python.

Re:and... (1)

jasonla (211640) | about 9 months ago | (#46521647)

And in about 20 years, it will make it into the REHL derivative my company uses... sigh.

Re:and... (1)

sg_oneill (159032) | about 9 months ago | (#46521679)

In fairness Python 3 isn't really as widespread as it should be. I think people have found the 2.7 branch just works well for them.

With that said I do wish people WOULD move to python 3. 2.7's unicode handling is infinitely awful and fragile compared to 3.

Re: and... (1)

electrosoccertux (874415) | about 9 months ago | (#46521757)

Paraphrasing other Slashdot posts I have seen, there are no compelling reasons to upgrade to Python 3. Removing the global interpreter lock would be one major reason to, but no one has submitted a good patch for that, and besides, someone would probably just backport it to Python 2.7.

Re: and... (4, Insightful)

dmbasso (1052166) | about 9 months ago | (#46521929)

There are plenty of good reasons to use Python 3, it is way more elegant and consistent. The way text and binary data is dealt with is incomparably better. I doubt that anyone who ever had done any serious coding in Python 2 escaped from the mindfuckery of mixing unicode and ascii.

The problem for a wider acceptance continues to be the libraries... for instance, Twisted. It is good that there is an async module in the standard library now, but too bad that my code already relies heavily on Twisted.

And about the GIL: if you are complaining about it, you most probably are not using the right language for the job.

Re: and... (1)

Kremmy (793693) | about 9 months ago | (#46522001)

The way I've heard it the manner in which Python 3 has modified the Python Standard Library has made it so cases where you aren't working with pure Unicode data (such as in any real world problem) get all the hassle and more of Python 2. Interoperability with foreign systems is kind of a basic foundation of data processing, having to workaround inconsistencies with the Python 3 Standard Library to do so probably means it's no longer the right tool for the job.

Re: and... (3, Informative)

spitzak (4019) | about 9 months ago | (#46522055)

This exactly.

If your UTF-8 string is not completely valid, Python 3 barfs in useless and unpredictable ways. This is not a problem with Python 2.x.

Until they fix the string so that an arbitrary sequence of bytes can be put into it and pulled out *UNCHANGED* without it throwing an exception then it cannot be used for any serious work. Bonus points if this is actually efficient (ie it is done by storing the bytes with a block copy).

Furthermore it would help if "\xNN" produced raw byte values rather than the UTF-8 encoding of "\u00NN" which I can get by typing (gasp!) "\u00NN".

Re: and... (5, Informative)

Anonymous Coward | about 9 months ago | (#46522289)

This is why there's a bytes type.

If what you have is not text, don't use the text type.

Re: and... (0)

Anonymous Coward | about 9 months ago | (#46522607)

If your UTF-8 string is not completely valid, be grateful that the corruption is caught early.

Re: and... (0)

Anonymous Coward | about 9 months ago | (#46522117)

The way I've heard it the manner in which Python 3

What about you stop hearing what others have to say, and try it for yourself? You'll find out that it just works and makes sense. There are no inconsistencies.

Re: and... (1)

Kremmy (793693) | about 9 months ago | (#46522221)

I have tried it myself, I actually decided to stick with Python 2 because I ran into plenty of awkward behavior and found that most of the third party modules I was interested in weren't available. Just now, as an example, I've visited this page (note the 3 in the URL) [python.org] . Trying to get up to date GUI library bindings for Python 3, I find the state of them to be quite disheartening. The PyGTK+ binding has been replaced by PyGObject in Python 3, but the PyGTK+ recommends staying with PyGTK+ on Windows. The rest aren't looking much better - our options are Tkinter and Qt if want to be '3 clean'. This exercise actually reminded me of something I discovered the last time I made the attempt to support Python 3 on Windows, the finding that I was explicitly limited to installing particular combinations of Python versions and libraries if I expected the libraries to actually work. Something was severely broken along the way, and I get the impression that it's one of those things that nobody will ever admit to.

Re: and... (0)

Anonymous Coward | about 9 months ago | (#46522295)

Maybe actually use Python 3? Unless you're a framework author, chances are you'll have to care very little about mucking with bytes.

Re: and... (5, Informative)

Anonymous Coward | about 9 months ago | (#46522307)

The inconsistencies are fully within Python 2. My experience is closer to full-scale horror when having to consider different encodings in Python 2, and since I am from a country that actually needs these "bells and whistles" regarding encoding for regular I/O on a regular basis, I have met these issues many times. Using chains of codecs to read and write files, having to intercept exceptions and .encode() .decode() in differing combinations to be able to avoid Python 2 "double-crashing" when reporting an exception, deep level hacking to reinitialize sys.stdout before output on certain machines, etc.

In Python 3, it does not "just work", but that is because character encoding is never a "just works" problem, and languages that say it is fail miserably in this regard as soon as it meets real world international encodings. Python 3 defines the problem correctly, and solves it natively in the best way I can imagine, by always being aware of the problem. No more prepending the u qualifier to every single string that might or might not be output (or combined with any other string that might or might not be output). Python 3 solves it correctly, by acknowledging character encoding as something that is actually an issue, and it does not make the silly assumption that ASCII is the way of the world. This assumption has been silly for at least 40 years, but many products were developed in ASCII centric regions, or at least in regions where you seldom saw more than one encoding, and never fully addressed the problem.

The Python 3 standard library does strings right , and should get credit for it. Instead it gets flac from programmers who do not like that it does not inherit the quirks from Python 2 that we have become accustomed to (and are still miles better than in many other languages; PHP and unicode, anyone?).

Heck, the number one reason that I have converted as many projects as I can to Python 3 is because of the blocks of encoding centered Python 2 code I can just throw out the window, and ease future maintenance. There are still some big module holdouts, but that was a much larger problem in ~2010. Today, the ones I miss in Python 3 are e.g. WXPython (where work is ongoing in the Phoenix project) and MySQLdb (the MySQL connection alternatives for Python 3 are outright silly -- either non-functional or non-documented).

There are several introductory programming courses I know of that focuses on Python, and they all use Python 3 by default. I am sincerely looking forward to the day when Python 3 is the natural order.

It takes a lot of motivation to change language structures from Python 2, and those working on the drafts are certainly top-class in their fields, so if one finds any design changes weird, the first instinct should be to read up on the rationales for the decisions. I have yet to encounter a change that seems "silly" or unnecessary after reading about the process.

Also, for the early adopters, not that Python 3.3 (och 3.4, as this article is about) is not 3.0 or 3.1. There is a lot of things that have been fixed along the way.

Re: and... (1)

ultranova (717540) | about 9 months ago | (#46523323)

In Python 3, it does not "just work", but that is because character encoding is never a "just works" problem, and languages that say it is fail miserably in this regard as soon as it meets real world international encodings.

What's wrong with simply presenting everything with Unicode? It might not be the most efficient possible way of representing text, but that's unlikely to matter much, given that you're using Python.

Re: and... (1)

Megol (3135005) | about 9 months ago | (#46523583)

I guess you have no experience with Unicode? It isn't a character encoding, it isn't a glyph encoding and so one have to support all other "features" of it to be compliant. Most code doesn't.

Re: and... (0)

Anonymous Coward | about 9 months ago | (#46522017)

if you are complaining about it, you most probably are not using the right language for the job.

There's absolutely no reason to use Python anymore. There are plenty of languages that are equally expressive while still being far faster and more efficient. Deal with it.

Re: and... (0)

Anonymous Coward | about 9 months ago | (#46522325)

I'm legitimately curious, what are some that come to mind?

Re: and... (1)

gbjbaanb (229885) | about 9 months ago | (#46522627)

I'm legitimately curious, what are some that come to mind?

IronPython? :-)

Re: and... (0)

Anonymous Coward | about 9 months ago | (#46522957)

I don't know how many are equally expressive, but faster than Python would mean any other language except Ruby and PHP.

Re: and... (1)

Billly Gates (198444) | about 9 months ago | (#46523359)

BASIC!!

Just kidding

Re: and... (0)

Anonymous Coward | about 9 months ago | (#46522647)

And that enjoy the fantastic support from the scientific community through projects equivalent to numpy, multigrid solvers, the various scikits, opencv and the like?

I don't know any of those and I'm very curious.

Support on shared web hosts (1)

tepples (727027) | about 9 months ago | (#46523659)

There are plenty of languages that are equally expressive while still being far faster and more efficient.

And available on entry-level web hosting? The only language I know of that's more widely supported on shared hosting is one that's been called a fractal of bad design [veekun.com] .

Re: and... (0)

Anonymous Coward | about 9 months ago | (#46522333)

Python 3 does strings "right", but in doing so, it has to leave some incorrect assumptions behind, which sadly not everyone appreciates. The library support issue is a big bullet to bite, but that was known the first time Py3k was released, and the "difficult years" that we have just been through/are just going through of lacking support will in the long run be worth it. I could not see Python continuing to be a relevant language 15 years from now, unless the Py3k transition had taken place as early as it did.

The Python 3 change is yet another thing that I believe the Python community got "right", even though they have received enormous amounts of crap from many who are not in the know of the underlying reasons. Of course one is free to be opposed even if one knows the details and the situations that led up to the decision, but mostly, that is not the case.

Re: and... (0)

Anonymous Coward | about 9 months ago | (#46522369)

But... but ... they've replaced nice, neat functions like find, index, split, strip... with a poorly documented, crappy, pseudo-regexp load of junk [python.org] . How can anyone work with that?

Re: and... (0)

Anonymous Coward | about 9 months ago | (#46523165)

Are you drunk?
[code]
Python 3.3.5 (default, Mar 10 2014, 03:21:31)
[GCC 4.8.2 20140206 (prerelease)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> 'wtf'.find('f')
2
>>> 'wtf'.index('f')
2
>>> '!!wtf!!'.strip('!')
'wtf'
>>> 'w,t,f'.split(',')
['w', 't', 'f']
>>>
[/code]

Re: and... (-1)

Anonymous Coward | about 9 months ago | (#46522629)

Yep. Python 3 be teh suck

Religeous arguments abound (4, Interesting)

EmperorOfCanada (1332175) | about 9 months ago | (#46522213)

I have recently started bathing in the waters of Python. What I have realized is that it is a core group within Python who are rightfully proud of their 3.x accomplishment. But they are solidly ignoring the fact that only a tiny percentage of people are using it. The reasons are quite simple people will need 8 modules for their system and 1 barely works with 3.x and the other says something like "mostly works" Well most people aren't willing to depend upon "mostly".

Now module after module is going 3.x but the other problem is that for most people having two pythons on their machine is a pain in the ass. I know there are tools to make this less painful but I can tell you an easy way to make it painless, Don't have two versions.

Then there is this call that you should begin new projects in 3.x; but the problem again is the two versions issue.

What bothers me about all this is that I come from a C++ / PHP world. With C++ I have upgraded countless times over many years and had close to zero problems with my code. I don't even know which compiler XCode is even using right now. With PHP my various upgrades have broken exactly one module and I hear rumours that the next big version of PHP will break one module in my older code. But I don't care as I am replacing my PHP with Python.

Where I am worried is that the core Python people will do something stupid like announce an end of support date for 2.7. The problem there is that it might be easier for some people to install a whole different language to sit alongside Python 2.7 and start playing with that instead of smashing their machine in the teeth and simultaneously installing 3.x.

Re:Religeous arguments abound (1)

Anonymous Coward | about 9 months ago | (#46522513)

Now module after module is going 3.x but the other problem is that for most people having two pythons on their machine is a pain in the ass.

What are you talking about? Most Linux distributions are shipping 2.x and 3x in parallel and have been doing so for years without issues.

Parallel 2/3 didn't work in Windows until 3.3 (1)

tepples (727027) | about 9 months ago | (#46523679)

Most Linux distributions are shipping 2.x and 3x in parallel and have been doing so for years without issues.

That's fine if your audience is willing to install Linux, either as a dual boot or in a VM. It took until Python 3.3 before Windows could practically run 2.x and 3.x in parallel.

Re:Religeous arguments abound (0)

Anonymous Coward | about 9 months ago | (#46522811)

I bet you started using C++ after it was already quite mature.

Remeber that Python is really quite a young language compared to most other languages of wide popularity.

Re:Religeous arguments abound (1)

MurukeshM (1901690) | about 9 months ago | (#46523487)

Python is 4 years older than Java, PHP and Ruby.

Re:and... (0)

Anonymous Coward | about 9 months ago | (#46523025)

The reason for this is python's dependency hell... python breaks support for old version libraries and forces you to update "everything".

Re:and... (0)

Anonymous Coward | about 9 months ago | (#46521877)

My company runs debian stable. They've just started to support this newfangled "ls" command.

Re:and... (0)

Anonymous Coward | about 9 months ago | (#46522081)

I envy you. I run Debian on my personal stuff... if only I could convince the Ops people...

Re:and... (-1)

Anonymous Coward | about 9 months ago | (#46521791)

Upgrade now! You'll only experience slightly worse performance than the 2.7 line (which was already ridiculously slow) and hopefully you'll only introduce a few hundred bugs in the process related to idiotic dynamic typing!

I don't see why more people aren't jumping at the chance!

Re:and... (2)

gweihir (88907) | about 9 months ago | (#46521853)

There are very few reasons to stick with the old model. Sure, it takes a bit to get used to some of the changes, but it is not that hard. And most good libraries have already moved over or are compatible with both.

Re:and... (1)

Marginal Coward (3557951) | about 9 months ago | (#46521901)

Yup. In fact, the lack of any new features in 2.7 is a primary feature that the 3.x line sadly will lack for the foreseeable future. ;-)

Re:and... (1)

gnupun (752725) | about 9 months ago | (#46522743)

Python 3 // division operator breaks division polymorphism:

Let's do integer division first.

Python 2:
>>> 20 / 2 # int divide int -> int
10

Python 3:
>>> 20 // 2 # int divide int -> int
10

>>> 20 / 2 # int divide int -> float (wtf?)
10.0

Now let's do floating point division.

Python 2:
>>> 2.5 / 5.0 # float divide float -> float
0.5

Python 3:
>>> 2.5 // 5.0 # float intdivide float -> rounded float
0.0

# You have to use "/" for floating-pt division for the right answer:
>>> 2.5 / 5.0
0.5

With python 2, it doesn't matter if the numerator and denominator is int or float, it automatically returns the correct answer all the time -- division operator is polymorphic. With python 3, if operands are integers, you must use "//" for division. If operands are floating-pt, you must use "/" for division. This is retarded because sometimes the programmer can't know what types of a, b and c are in the expression "a = b divide c." If a, b and c can be int or float, how can a programmer implement "a = b divide c" without a lot of ugly type checking? Another poor design in Python 3.

Re:and... (1)

MurukeshM (1901690) | about 9 months ago | (#46523511)

I take issue with your "musts". The way I see it, if I want a real answer to x/y I use x/y. If I want some special meaning of / (like integer division or rounded answers or blah blah), I use //. That is good design.

The type of the result (1)

tepples (727027) | about 9 months ago | (#46523711)

If a, b and c can be int or float, how can a programmer implement "a = b divide c" without a lot of ugly type checking?

By determining what type you want in the result and choosing the operator that produces that type. And you can get Python 3 division behavior in Python 2.6 or 2.7 using from __future__ import division.

Re:and... (1)

uneek (107167) | about 9 months ago | (#46523073)

And everyone will keep using 2.6/2.7, the windows XP of python.

2.6 is the standard that is packaged with popular OSes like Red Hat. Also who has the time to upgrade their python code to the new object model?

Teeny peeny (-1)

Anonymous Coward | about 9 months ago | (#46521635)

Only 3.4? The Python in my pants is 9 inches and that's when flaccid!

Re:Teeny peeny (0)

Anonymous Coward | about 9 months ago | (#46521973)

Only 3.4? The Python in my pants is 9 inches and that's when flaccid!

Sorry AC you like many americans are easily confused when you see metric you were looking at the millimeters side of the ruler.

yeah but... (-1)

Anonymous Coward | about 9 months ago | (#46521645)

I'll stick to 2.6 thank you

Re:yeah but... (-1)

Anonymous Coward | about 9 months ago | (#46521855)

2.6 for life bitches, fuck 3.x!

Re:yeah but... (0)

Anonymous Coward | about 9 months ago | (#46522371)

Didn't you actually mean to say, "FUCK BETA!!"?

And it still has the GIL (1, Insightful)

halfdan the black (638018) | about 9 months ago | (#46521767)

Yup, Global Interpreter Lock so Python is still fundamentally single threaded -- only a single thread can be executing any python code at any given instance.

Its 2014 and we still can't have a multi-threaded python, this is ridiculous.

If you read Guido's criteria for getting rid of the GIL, he lists so many things that are specific to the current single threaded system (which is evidently perfect) that the only solution that meets his criteria is the current system.

I guess the only solution is to either live with single threaded system or fork it.

Re:And it still has the GIL (-1)

Anonymous Coward | about 9 months ago | (#46521829)

It's blatantly obvious that Python is dying. Prominent community members are leaving in droves, the primary implementation is painfully slow (the 3 series is actually slower), and having a GIL in 2014 is spectacularly retarded. Dynamic typing has also shown time and time again that it's utterly idiotic and unmaintainable.

Re:And it still has the GIL (0)

halfdan the black (638018) | about 9 months ago | (#46521863)

I could not agree more. Its virtually impossible to perform any sort of type inference in Python, hence there are no viable JITs. Basically the whole design of Python was so any part of the runtime can be overwritten at runtime, i.e. monkey patching.
I think the big problem with Python is all the hacker types who think it so cool to swap out bits bits of the runtime at runtime just because you can. Now this leads to some truly incomprehensible and unmaintainable code.
Dynamic typing is OK, at least its done correctly in JavaScript so one can actually perform type inference and JIT compile it.
I really wish some other languages like Scala would gain more traction.

Re:And it still has the GIL (1)

Anonymous Coward | about 9 months ago | (#46522025)

Dynamic typing is OK if done well. But JavaScript and typing in JavaScript are a disaster. Python gets some things wrong, but nowhere near as badly as JavaScript.

Re:And it still has the GIL (0)

Anonymous Coward | about 9 months ago | (#46522027)

I could not agree more. Its virtually impossible to perform any sort of type inference in Python, hence there are no viable JITs. Basically the whole design of Python was so any part of the runtime can be overwritten at runtime, i.e. monkey patching..

Err..you know that there already is a working python implentation with a type-inferring JIT which produces notable speed ups. It's called pypy.

http://pypy.org/

Re:And it still has the GIL (0)

Anonymous Coward | about 9 months ago | (#46522105)

They've been working on it for years and they have barely any funding. Creating a decent JIT for an incredibly dynamic language takes a huge investment and PyPy doesn't have it. As it stands now, PyPy is only faster in rare cases, still has a GIL, and uses far more memory.

Re:And it still has the GIL (1)

halfdan the black (638018) | about 9 months ago | (#46522225)

And therein likes the problem: python is a "incredibly dynamic language" which makes any sort of performance difficult if not impossible. The problem is Python is so dynamic that its impossible to perform any sort of meaningful validation before the code is actually run.

Re:And it still has the GIL (0)

Anonymous Coward | about 9 months ago | (#46522591)

Lisps are incredibly dynamic and fast, if verbose.

http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?test=all&lang=sbcl&lang2=python3&data=u64q

Re:And it still has the GIL (0)

Anonymous Coward | about 9 months ago | (#46522463)

Yep, Python is dying:

http://blog.codeeval.com/codeevalblog/2014

Re:And it still has the GIL (1)

BreakBad (2955249) | about 9 months ago | (#46523291)

Those stats are just for submissions to codeeval challenges. I believe python is about 7th on the chart, while C/Java top it. Then C++,C#,PHP. Even Obj C is widely used due to iOS. I find it impossible to believe that python has a 30% share...but that would be nice.

Re:And it still has the GIL (5, Insightful)

steveha (103154) | about 9 months ago | (#46521879)

You make it sound as if it were no big deal to remove the GIL. It has been tried, and Python got 2x slower, so that attempt was abandoned. Python 3.2 gained a different implementation of the GIL, and that fixed some problems, but other problems still occur.

The GIL is Python's hardest problem.

https://www.jeffknupp.com/blog/2012/03/31/pythons-hardest-problem/ [jeffknupp.com]

https://www.jeffknupp.com/blog/2013/06/30/pythons-hardest-problem-revisited/ [jeffknupp.com]

As noted in the above referenced blog, you can use Jython or IronPython to avoid the GIL; PyPy will be using Software Transactional Memory to avoid the GIL; and you can use the multiprocessing module to use multiple cores without GIL problems. You do have options other than just using CPython.

If removing the GIL was as easy as you seem to think, it would be gone now, at least in a fork of CPython. Yet still it remains.

Re: And it still has the GIL (0)

Anonymous Coward | about 9 months ago | (#46521931)

Python slow? Why not use C instead? With the right libs can do much more then some script lang could ever do and will run your properly written code fast as the bat out of hell.

Re:And it still has the GIL (0)

Anonymous Coward | about 9 months ago | (#46521957)

You make it sound as if it were no big deal to remove the GIL.

1. Nobody cares if it's easy to fix. There are tons of languages without a GIL already and most of the relatively popular new languages don't have a GIL (F#, Scala, Clojure, Go, Rust, Nimrod, Julia, Ceylon, Kotlin etc.).

2. The only reason it's hard to fix is because certain parts of Python are overly dynamic. Since they broke backwards compatibility in Python 3 it would have been the perfect time to fix it. Instead they broke backwards compatibility for stuff 99% of the community doesn't give a fuck about and now nobody is upgrading even though Python 3 has been out for over 5 years.

3. Jython and IronPython are barely supported anymore, and a lot of the popular Python libraries don't work on either of them since Python is slow as shit and so much functionality has to be written in C. If you're targeting the JVM or the CLR there are far better languages to use anyways.

Re:And it still has the GIL (1)

halfdan the black (638018) | about 9 months ago | (#46522243)

2. The only reason it's hard to fix is because certain parts of Python are overly dynamic. Since they broke backwards compatibility in Python 3 it would have been the perfect time to fix it. Instead they broke backwards compatibility for stuff 99% of the community doesn't give a fuck about and now nobody is upgrading even though Python 3 has been out for over 5 years.

That is really insightful, seriously. Python 3 did break backwards computability, this really would have been the time to fix some original design flaws, but they didn't, instead, they focused on stuff, like you said 99% of the people out there don't care about, hence why so many use 2.7 today and how many new projects are even started with 2.7.

There's nothing wrong with design flaws, we all make them, you just at some point have to go back and realize you made a mistake and fix it.

Re:And it still has the GIL (1)

halfdan the black (638018) | about 9 months ago | (#46522063)

I never said it was easy removing the GIL, nor do I know how to do it and meet all of Guido's requirements.

The GIL is a design flaw of the language. If Python remained just a way to add quick scripting to existing programs, just like TCL, I would have no problem with its design. But I do have problems with Python becoming a systems language. Its far far far too dynamic for its own good, it should not encourage dynamically replacing bits of the runtime at runtime. The GIL really shows the age and intent of Python.

These sort of ultra dynamic language may be good at writing quick and dirty scripts, but such dynamic features make maintaing and understanding any large system a nightmare. After all, bugs are so much more fun to find months after you've released an app that right away that a static analyzer could have found.

Re:And it still has the GIL (1)

steveha (103154) | about 9 months ago | (#46522263)

You actually have two complaints, not really related.

One complaint is the GIL. As I understand it, the GIL is mainly needed because the CPython reference counting model needs to touch a whole bunch of reference counts when churning objects, and this needs to not screw up. Thus Jython and IronPython, leveraging the garbage collection of their respective underlying VM platforms, didn't need a GIL.

The other complaint is that the language is too dynamic. That's just part of the design of the language. I can somewhat sympathize; I don't overuse the dynamic nature of the language (I know I can rebind "list" to do my own thing, but I never ever do that), and since I don't do that I would rather not pay the runtime penalty for it.

PyPy's JIT works by watching what the code is actually doing, and when it sees that (for example) your code never rebinds "list" it can strip out the dynamic lookup of "list" and just hard-code in a reference to the builtin "list" class. It can gain an extreme speedup when it detects a simple for loop, because it can replace all the Python VM machinery (creating new int objects, then freeing them) with a simple loop.

And, on the other hand, I do use the dynamic "duck typing" features to write less code, and I don't want to lose that. I love writing functional Python code where you can pass a function object in to another function and get a lot done with a relatively small amount of code.

It's possible that someday, some other language with a different static/dynamic tradeoff might eclipse Python; but I'm still using it because I get work done in it, and it is fast enough for the things I am doing.

Re:And it still has the GIL (1)

kyrsjo (2420192) | about 9 months ago | (#46522765)

Yeah, it would be nice if there was some way of *voluntary* declaring the type of a variable - i.e. state that this variable wil ONLY accept an Integer etc. - and that trying to store something else in the variable would raise a TypeError. Same goes for function arguments.

That could lead to
(1) safer code where the mistake is caugth earlier and at the point where the data is stored as the unexpected type, not when you in a completely different piece of code do some operation on it which expects it to be a different type, and backtrace fireball ensues.
(2) Potential performance increase

For me, when writing Python, (1) would be the main thing.

Re:And it still has the GIL (1)

WinstonWolfIT (1550079) | about 9 months ago | (#46522455)

Jesus if the whole damn stack isn't thread safe the whole damn stack should be deuce-canned. Grow up and adopt a 21st century stack.

Re:And it still has the GIL (1)

Daniel Hoffmann (2902427) | about 9 months ago | (#46523251)

If you call C code from python the GIL is released so it can run in parallel in normal python threads. Many of the libraries and most of the core of the language are written in C. How much parallelism that nets you depends on your application, but simply using python threads does provide some parallelism.

Re:And it still has the GIL (0)

Anonymous Coward | about 9 months ago | (#46522179)

Does Jython fix this problem, since it does not use a GIL?

Re:And it still has the GIL (1)

Anonymous Coward | about 9 months ago | (#46522309)

Ruby also has a GIL.

Perl clones the entire interpreter for every thread.

This is not a new problem, and there are not yet any great solutions. You only hear about it with Python because Python's succeeded well enough for people to be bumping against the limitation.

The async IO in Python 3.4 should help relieve the need for using threads in the first place in a good few cases, at least.

Re:And it still has the GIL (0)

Anonymous Coward | about 9 months ago | (#46522373)

Python apps single threaded ?!
Please stop trolling and RTFM http://docs.python.org/3/library/multiprocessing.html

There is something called multi-process you know (3, Interesting)

Viol8 (599362) | about 9 months ago | (#46523161)

And python has supported it (at least on unix) virtually since it was first released.

I've never really seen much virtue in multi threading - its useful in a limited number of cases but usually it creates more problems than it solves (compared to multi process) and is usually used by people who don't really know what they're doing. Essentially multi threading takes all the advantages of protected process virtual memory and throws them in the bin.

Re:There is something called multi-process you kno (1)

halfdan the black (638018) | about 9 months ago | (#46523865)

Of course I know about multiprocessing. Why have one copy of the interpreter and libraries loaded when you can have N, plus its so much more efficient to marshal data across process boundaries than to access a global shared memory block.

I've heard this processes are so much better because we can't do threads for so long. Kind of like if I cut off my right arm, its so much better to only have a left arm because you only need to move 5 fingers instead of 10.

And yet compatability is still non-existant. (0)

Anonymous Coward | about 9 months ago | (#46521805)

.. and 2.7 works better and can more easily be deployed so when I write code in python, it can ACTUALLY GET USED.

Python 3 is effectively worthless unless I can deploy it; and right now none of the major, fair priced hosts can support large websites support it.

lost of python hate here (0)

Anonymous Coward | about 9 months ago | (#46521903)

There's the old parable about two programmers that are told to double the speed of their program. One guy spends a month rewriting the core in assembly and using hardware acceleration. The other guy waits 6 months and buys a new computer. They both succeeded.

I realize that python will probably never be used in post production of HD video. But if I want to deploy a web site with readable reliable code that can be easily maintained, I'm not using java or php. So long as I can scale by throwing machines at the problem, python wool solve my problems wonderfully.

Re:lost of python hate here (0)

Anonymous Coward | about 9 months ago | (#46522267)

There's the old parable about two programmers that are told to double the speed of their program. One guy spends a month rewriting the core in assembly and using hardware acceleration. The other guy waits 6 months and buys a new computer. They both succeeded.

I realize that python will probably never be used in post production of HD video. But if I want to deploy a web site with readable reliable code that can be easily maintained, I'm not using java or php. So long as I can scale by throwing machines at the problem, python wool solve my problems wonderfully.

Ah so Python copies the standard Microsoft strategy. Design shit software that can only be redeemed by powerful hardware.
It's a pity that all new computers are multithreaded and Python still only uses 1 fucking thread. Throwing more hardware at the problem doesn't fix it. Removing the GIL is a software problem. No hardware can fix it, and if we've arrived at a point where Python is a jack of all trades and master of none, well maybe it's time to ditch the language a design a more version incorporating all the "advancements" in language design from the last 20 years. That should make it quite useful for next 2-3 decades. Otherwise it will end up like Perl 6.

Re:lost of python hate here (0)

Anonymous Coward | about 9 months ago | (#46522473)

1 thread per process in the most common Python implementation

You can

a) have many processes - it is trivial with multiprocessing
b) use another implementation

Arguing that given chainsaw is bad because cutting steel with it sucks is lame.

There are millions of problems and there are hundreds of tools to solve them. Python has its drawbacks but is fun to use and read.

Re:lost of python hate here (0)

Anonymous Coward | about 9 months ago | (#46522963)

have many processes - it is trivial with multiprocessing

Apart from, you know, that pesky moving data around between processes all the time.

Re:lost of python hate here (0)

Anonymous Coward | about 9 months ago | (#46522379)

Oh, but Python is very likely to be used in video processing.

It is just that Python does high level scripting while all the heavy-lifting is done by C/C++ underneath.

String Hash Bike Shedding (0)

Anonymous Coward | about 9 months ago | (#46521937)

Waaaayyyyy too much effort went into their treatment of string hashing for their dictionary objects. It seems like a useless distraction and a sad opportunity for endless bike shedding.

Python, like Perl, is just ridiculously slow. (Disclaimer: I love Perl.) Even a tight loop doing nothing is slow compared to some other, non-JITd scripting languages**, let alone JITd or compiled languages. A 5% change in string hashing performance is not only imperceptible in real work loads, it's nearly immeasurable in something like Python.

You use Python because you enjoy the language and its ecosystem of libraries. You most certainly do not use Python because of it's choice of micro-optimizations.

** Proof: Lua is an order of magnitude quicker even with just a simple loop. Compare

local x = 0
for i = 1,(20 * 1048576) do
        x = x + 1
end

to

x = 0
for i in range(0, 20 * 1048576):
        x = x + 1

Re:String Hash Bike Shedding (1)

EmperorOfCanada (1332175) | about 9 months ago | (#46522215)

Try xrange if you are using 2.7. Its use of memory for such a massive loop so much better.

Python is the new Pascal (-1)

Anonymous Coward | about 9 months ago | (#46521991)

Other than teaching CS101 to girls and non-majors what the fuck use is it anymore? Clearly Guido is no Linus. Dude ran Python into the fucking ground with his idiotic 3.x bullshit. Did he not learn from "Perl6" that if you break backwards compatibility to add features people will just switch to a new language that already has those features...it shouldn't have been a surprise that it would spell doom for Python to fork it into two incompatible branches for a couple of "it would be nice" type features.

Re:Python is the new Pascal (3, Insightful)

Anonymous Coward | about 9 months ago | (#46522141)

it shouldn't have been a surprise that it would spell doom for Python to fork it into two incompatible branches for a couple of "it would be nice" type features.

No.

The Python community, overall, approves of Python 3.x. The major breakages have to do with Unicode, but that's because Python 3.x does it right and Python 2.x didn't.

If you don't think Unicode matters, my guess is you are an English-speaking American. Others disagree.

There are efforts underway to port the major Python projects to support 3.x. SciPy will be the big one... Django already has support for Python 3.x.

Perl6 never went anywhere, Python 3.x is in wide use.

Re:Python is the new Pascal (1)

Anonymous Coward | about 9 months ago | (#46522185)

Python 3.x is in wide use.

PyPI download stats [alexgaynor.net] indicate that Python 3 packages account for less than 3% of all Python package downloads. That's hardly "widespread use" for something that's been released for over 5 years.

You Fail It!! (-1)

Anonymous Coward | about 9 months ago | (#46522357)

formed hiS own [goat.cx]

Jesus called (1)

WinstonWolfIT (1550079) | about 9 months ago | (#46522489)

And he asks nicely that Python programmers stop invoking his name in vain.

Honestly, this entire stack is so non-deterministic, what is it doing in the Enterprise again? I haven't seen anything this Rube Goldberg since the 50s. Shit-can this stinking pile of merde for almost anything and the world will be a better place.

Re:Jesus called (0)

Anonymous Coward | about 9 months ago | (#46522655)

YEah!

Everyone isn't listening to you because everyone is a fucking idiot.

PyPy (1)

Adam Jorgensen (1302989) | about 9 months ago | (#46522717)

I am personally more interested in the PyPy release that will bring transactional memory.

The project I work on right now is proudly PyPy compatible and I hope to keep it so :-)

Re:PyPy (1)

Adam Jorgensen (1302989) | about 9 months ago | (#46522745)

I suppose I should add that with the adoption of STM PyPy will be essentially removing the GIL, something people have been asking to be done for a very long time...

Ob (4, Funny)

Hognoxious (631665) | about 9 months ago | (#46522861)

Have they fixed the whitespace bug yet?

Python 3.4 Released ... Alligator 2.0 Devoured (0)

Anonymous Coward | about 9 months ago | (#46522927)

(no text)

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?