They got rid of format for ordinary strings, and since we have to use bytestrings for handling hg's binary format, converting back and forth with .decode and .encode just to get the formatting is a lot of work.
The Python devs have actually acknowledged this use case and apologised to hg. Kinda weird, considering how Python itself is hosted with hg. :-/
I could easily be underestimating the difficulty of integrating C with Python - I've never done it personally, but I gather that's one of its strengths. But this seems like a pretty simple problem, which has a pretty simple implementation in any language (there's an included Python implementation on the linked page, ~20 LOC?), and if it's a critical performance piece it's surely worth the cost to make that piece.
I completely believe that, and good point about Python 2. I wasn't considering that side of things.
Is it a complicated rewrite, or just big? Superficially it seems pretty mechanical, `bytes.format` to `bytes_format` (though finding them might be hard). I never feel like I have free time, but I don't tend to get exhausted from things like that, maybe I can contribute a bit. It would be good to get exposed to some decent, real Python code :)
That's where I stop filling out the survey.
And that's the python community biggest problem. Moving forward, everyone needs to pick a version (and I'd pick 3). A new user just sits and spins his head. Even the training materials are all over the place.
Ultimately, you did pro-Python 3 supporters a disservice by not speaking up.
It would be nice if the question were more specific and more positive, but the survey would be worse if it were simply taken out.
I've been teaching Python in China, Europe, Israel, and the US for years. In the last four years alone, I've taught about 2-3 Python courses (usually intro, but sometimes advanced or on specific topics) each month, at companies like Apple, Cisco, Intel, and SANDisk.
In only one case did a company ask me to teach them Python 3. The rest of them ask specifically for Python 2. In some, more advanced and unusual cases, they ask me to describe the changes that will happen in Python 3. They all have legacy code in Python 2 that they cannot imagine upgrading, mostly because there are libraries (internal or external) holding them back -- and the benefits aren't obvious.
(I should note that almost none of my courses are at startups. So it's quite possible that I'm seeing a sample of large companies, which are inherently more conservative than smaller ones.)
I thought that the survey was fine. But really, there's a problem in the whole Python 2/3 split, and while I've convinced myself over the years that people are switching, I've rarely met any of them. Which is really too bad.
The whole survey is bunk. Too much misinformation and misbeliefs regarding Python 3. The only valid informed answers would be from those who've used (or used and failed) >= Py3.3 for something significant.
It should have had more questions attempting to discover why those who don't adopt Python3 don't. Then, if a major problem turns out to be misinformation, it could be addressed with evangelism. If a problem is a shortcoming of Python3, that shortcoming could be addressed. Etc.
Not ensuring library compatibility was lazy, egotistical arrogance and will ultimately relegate 3.x to being a historical footnote.
It's like any software project. It's always tempting to throw everything out and start fresh, but that always takes about 100x more work than what is budgeted for.
I don't think Python3 was a mistake, but the migration is going to take time. Cutting off either group would have been a terrible decision, and I'm glad they didn't.
Not to mention pip and package management - which compared to ruby, is just terrible. I mean there isn't even an update all command in pip. And of course if you have different versions of python you have different versions of pip. With different version of packages installed.
And now for virtualenv. Ok great tool. But even in this area there's confusion. Different people use different environment managers. And virtualenv isn't the easiest thing to setup - from a new users point of view. Where in ruby there's gem. It's installed with ruby. Period.
The community isn't doing itself any favors by dragging their feet. Everyone should jump onboard the python3 wagon. And if you need a package that isn't 3, then rewrite or look for something else. Maybe if the maintainers of said packages knew that their users weren't gonna stand for not supporting version 3 they'd get off their butts and convert - or release the code and let the community convert the package for them.
That's because these are all still valid versions of Python (which are still shipped with OSes). Most of the concepts you learn in Python 2.5 are still valid in Python 3.3; the changes weren't that dramatic. There are still strings, the control mechanisms didn't change, logic still uses the same operator precedence, the syntax didn't change...
Yes, there are now byte and unicode strings (as there were in Python 2), yes, print is now a function, yes, a few functions now return iterators instead of lists, and yes, a few functions/packages were renamed. Pretty minor changes, in the long run; breaking changes yes, but still minor for all that.
> Everyone should jump onboard the python3 wagon.
No, they shouldn't. You should never risk your production critical code just because a language wants to evolve. Perhaps this is a difference from Ruby (particularly Rails) where there appears to be an "evolve or die" philosophy, whereas Python says "we're here when you're ready, but we're not going to ignore you". It honestly makes me happy to work with Python, where I don't have to chase down a production fire because a developer decided to make a breaking change.
I will personally move to Python 3 when it's prudent to do so - when the environment I develop for supports it natively. Until then, I'm glad I'm not being forced to move ahead. It makes my day to day life as a developer simple.
It's true that experienced Python programmers can easily identify the distinctions, and thus translate back and forth in their minds.
But for a newbie, the fact that print("abc") works on Python 3 and 2.7, but not on earlier editions of 2 (and yes, many people still use those earlier versions) is confusing and frustrating.
When I teach my Python classes, I always tell them that they should check a tutorial, blog post, or Stack Overflow answer before using it, to see if it's relevant to Python 2 or 3.
Instead teach people how to use sys.stdout to get properly deterministic behavior.
Print is useful in the repl, and in quick one-offs, but I would never use it for production deployments. And I never let it survive a code review either. It's bad practice to rely on it.
It's better in Python3, but I'd still probably use explicit file streams.
All of the Python communities I've seen have a "Python 2 or 3?" section that's pretty clear--"depends on what you want to get done. Python 2 is most widely deployed. Python 3 is complete but lacking an install base and library support." I've written a small amount of code in Python 3 and they're not that different.
I entirely agree about package management (and virutalenv). It finally appears they have a way forward with package management. If that's implemented in Python 3, it'd be a significant reason to adopt. Virtualenv is already part of Python 3.
At my workplace, we're still transitioning from Cent5 (ships with Python2.4, but we're using 2.6) to Cent6 (ships with 2.6). Our third-party packages are still on 2.6 and the newest versions of them are finally using 2.7. So we've brought up Python3, but are still just talking about moving to 2.7. I, too, wish adoption of Python3 was faster, but even if there were more enticing features my workplace is beholden to the platform we're using. I think now that newer distros default to Python3 is fantastic, and it will take the long term versions defaulting to them before most companies are convinced to switch (still a few years off).
- The major scientific/numerical packages support Python 3 (pandas, numpy, scipy).
- The best database library supports Python 3 (SQLAlchemy)
- A substantial fraction of important support libraries support Python 3 (e.g. lxml, PIL/pillow)
- Django supports Python 3
I'm honestly a little confused by people who claim that library support for 3.x "isn't there yet". My entire office has switched to Python 3 for everything.
one single dependency that doesn't support py3 is the death knell to using it for anything, EVER
I use python daily at work and you can be safely assured the state of py3 on pypi is fu$$$$ed.
(we use pyramid not django for what it's worth)
Can't you logically extend that across language boundaries, and if so, why would you ever try to use a different language? A needed library or feature of a library might be missing.
Is it really that hard to take whatever dependency isn't supported and patch it? Isn't that one of the benefits of running an interpreted language?
That's a fairly strong opinion to take, and in my opinion, goes far enough to be ridiculous.
Perhaps for some projects, that factor is small.
...and for some of them, it turns out to be huge. So big you have to roll back to py2, and suck it up for lost time/money spent doing so.
When you have a project that is time/cost critical, that risk is absolutely unacceptable.
If you're working on your own projects, in your own time, sure thing. ...but professionally, on project work? No. Never.
Until you get the reverse, where continuing to work in py2 introduces an equivalent risk, because new libraries are 'py3 only', there is no justification whatsoever for using python 3.
Worse, because of this, when you're writing libraries, you have to make your py3 code py2 compatible, which means using the syntax-feature subset that works with py2, which basically defeats the entire purpose of migrating to py3.
Kivy is great example. The next version is going to support py3; great! ...but it's going to continue to natively support py2 on the same code base; ie. no new python 3 features. It will simply 'work' under the python 3.X interpreters.
That's why I will probably not end up using python3 in any professional work for the foreseeable future.
(If you think that's ridiculous... what can I say? Clearly you haven't worked under time/cost pressures where you have to be personally responsible for delivering on time and budget)
But you can easily replace py3 in this sentence with any other programming language. Does it still hold true? I think that's worth looking at, as groups have both successfully and unsuccessfully started projects in other languages than the core one they've been using. There are examples here of varying degrees of similarity, why not examine them?
When you have a project that is time/cost critical, that risk is absolutely unacceptable. If you're working on your own projects, in your own time, sure thing. ...but professionally, on project work? No. Never.
Obviously there will better and worse project candidates. High pressure, cannot fail projects are not good candidates. I think any company that consists only of high pressure, cannot fail projects is not very well managed. Hopefully yours is not like that.
Ostensibly, there are reasons why py3 made changes. Those reasons may still apply. Whether you think they are justified, or worth concern, is up to you.
Let's see, you make a clearly hyperbolic statement, and when I call it out, you resort to an ad-hominem regarding my credentials. I see where this is going.
I only responded originally because your statement was ridiculous on it's face, and you keep making more of them. You seem to traffic in absolutes, and general absolutes, not just for yourself; "...death knell to using it for anything, EVER", "...but professionally, on project work? No. Never." Here's a hint, all it takes to disprove never is once.
I thought I could pull some interesting information out of you as to why you held such strong convictions regarding py3 (not because I'm an advocate, I don't know/write python), and compare those reasons to how other people and groups justify exploring other languages at work, because it interests me, even if I'm generally of the opinion it's not worthwhile.
Obviously you care a lot about this, at least at the moment (at least I hope that explains why you are throwing around words like "never"). Perhaps in the future when you're less emotionally invested you'll be able to step back and look at the issue again, and maybe you'll see it the same way, maybe not.
CyMySQL and oursql are also viable options.
The reliability is one of Pythons strength and one of the reasons I use it. Take away the reliability and you will loose a lot. You will loose also many friends (like myself).
There was a blog post recently and stated an other option: Bring Py2 and Py3 nearer together to make the switch easier -- than more people would willingly move.
Some obstacles for moving where removed -- but a little late (e.g. the u"-Syntax was used many times in Py2 (at least outside english speaking countries or where localization is a topic) -- but abandoned in Py3. That was not necessary, but blocked an easy migration, because there are so many positions the code can be in. Now Py3 also supports the syntax and just ignores it ... why was that option not taken in the first place???) and not all. As much I know, there are still major differences when programming C extension libraries .... that makes porting existing libraries unnecessary troublesome.
Such things where not recognized early enough and still hamper adoption of Py3. Remove the blocks and you will gain more ground!
I for one never even considered that C extensions would be a serious road block. Which is obvious now that you mention it. And my main point, I've never bothered to research moving to Python 3 because there's no sense of urgency.
If Guido set a date, say Jan 1st 2015, it would remove allot of the apathy we're currently seeing.
Only thing that could really help, I think, would be a really big improvement in Python 3 that makes it more attractive to move, but that could also widen the gap between the two.
>>> map(lambda x: x*x, range(1,10))
<map object at 0x02DDDB90>
[1, 4, 9, 16, 25, 36, 49, 64, 81]
If by evaluate you mean "convert to a list", that's sensible, since a generator may or may not be safe to convert to a list. If you want a list, wrap the generator to a call to the list() builtin function, and, voila.
Python 2.7.5 (default, Aug 25 2013, 00:04:04)
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
The override is easy:
Would the following work? It's been a while since I've had Py3 installed, so I can't casually try it. In your PYTHONSTARTUP, place the following:
_map = map
def map(f, *args):
return list(_map(f, *args))
A middle ground that I have not seen is automatically evaluating the first few elements and showing those as part of the <object> output.
I say this as someone still on Python 2.6 due to environment restrictions.
Speaking personally, I sought to move away to a utf8-friendly language from php a few years back, and seriously considered Python back then. It came highly recommended on Stack Overflow.
Upon investigating the matter further, however, it became clear that the community suffered greatly from the divide introduced by Python 3. As if the core devs went in one direction while the community at large went in another.
It wasn't exactly a welcoming place for a newcomer. As if you needed to pick sides on day one. I ended up selecting another language and have never looked back.
If anything, I'm bemused that the debate still rages on years later. And I can readily picture seasoned Python users being put off by the same, and looking elsewhere for a saner ecosystem.
Case in point: As some have already hinted in the thread, the point is becoming moot nowadays, not so much because the community is slowly making the switch to Python 3, but because community members are moving en masse to Node, Go, Scala, Clojure, etc.
Go? Go is painfully statically typed (painful example: requiring you to cast an int to float32 to do a `>` or `<` operation) and feels a lot more like writing C than Python (not to mention its lack in the "batteries included" department).
Ruby? Same speed and memory "problems" as Python.
Perl? Faster, but its language design philosophy is diametrically opposed to that of Python.
Clojure/Haskel? Syntax and program structure are so radically different from Python there's no comparing them to Python3 when discussing differences from Python2.
I gave Go a chance to supplant Python as my main language, and I thin it could do that. I had a few other problems with Go though which led to me looking at Haskell.
I'm giving Haskell a chance to supplant Python/Go as my "go to" language atm and it seems to be winning me over, but only time will tell.
The same cannot be said for the multitude of changes to Python.
I came across Haskell and Hindley Milner ;)
I believe Haskell replaces Go for me and with some experience (when I can picture types in my head better) it will replace python as my go to dynamic language.
P.S.: I don't know what you mean by that example. You don't need to cast an int to anything in order to use comparison operators.
Edit: I really just like the statement for the interpreter, and IPython Notebook. To me the statement syntax feels less like programming, and more like using a computer.
print(<SOMETHING I'M TRYING TO DEBUG>) or
Edit: now that I thought about it - since you're able to decode the bytes you're using, it means you are operating on text - why not convert it then?
But really, I just don't like how http/ftp/similar protocols were designed in the first place. They're mixing binary and text in the same stream. That's ugly and when you have strict rules about text encoding in your language, the implementation also turns out ugly - what a surprise :)
Explicit is better than implicit.
print 'hi', # prints hi (no extra space in the end)
print 'hi',; print 'hi' # prints hi hi
I personally dislike this syntax because I don't find this natural. Wouldn't it make more sense to print an extra space after the print statement with trailing comma instead of before the next print statement?
print 'hi', 'there'
pprint = functools.partial(print, end=' ')
print('hi', 'there', sep=' ')
fprint = functools.partial(print, file='/var/log/foo.log')
fprint("I'm writing to a file!")
fprint("So am I")
def print_wrapper(*args, **kwargs)
outfile = None
print_stmt = "print "
if 'file' in kwargs:
outfile = open(kwargs['file'], 'a')
print_stmt += '>>outfile '
print_stmt += ", ".join(*args)
if 'end' in kwargs and kwargs['end'] == ' ':
print_stmt += ','
if outfile is not None: outfile.close()
I'm not a CSist or professional programmer. I use programming as a tool, typically to solve short term problems for myself or for a small circle of colleagues. When I started using Python, not too long ago, it seemed like I had discovered a secret productivity tool. A project manager asked me: "What's a Python?"
Today, Python seems to be everywhere. It's been taken up by curious characters such as scientists and hobbyists. It seems to be the lingua franca of the Raspberry Pi. My non-CSist colleagues are getting into it, and I don't think it's just because of my incessant evangelism. ;-) A great thing about Python is that you can use it at whatever skill level you happen to be at, by ignoring its advanced features until you need them.
I could switch from 2 to 3 today, but I'm lazy. I'd get bonked by errant print statements for a while, and probably not experience any other hurdles. I spend more time already, keeping up with the changes that I make to my own libraries.
IIRC the Python community was already expecting a fork to happen eventually (because 2.7 is the "final" 2.x release) so getting the community involved would be a good thing.
I would imagine that the purpose of maintaining 2.x would be for fixes, security, and back-porting of features that make it easier to have 2.x and 3.x-compatible code.
Before PyCon SurveyMonkey(my employer) will be deploying a major part of our application on Python3.
But I'm fascinated by the debates over the merits of the two. Thanks for posting the survey!