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. :-/
Why not write it yourself, as a utility method rather than something built-in? Granted it would be nice to be built in, but that shouldn't stop anyone. Or is there some other reason?
Speed is another big concern. You want your DVCS to be as fast as possible. You don't want to wait even half a second to see the output of "hg status" just to see which files you've modified.
Mercurial is a big project. Surely there's one skilled C programmer who could write a relatively-portable, efficient, limited version of this feature (or find one, I assume something extremely similar exists in several flavors). Once that's done, have a Python fallback for those esoteric systems where it doesn't work, and move on with life. Since it's apparently a critical code-path, that's normal development for great performance.
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.
It's more work than it appears. And it's work that doesn't seem to have immediate benefit, since Python 2 is still around. Augie Fackler has started tackling it, but even if we do get the change to Python 3 itself, it also requires a substantial rewrite of the hg codebase, since we use strings everywhere. And again, it's a lot of work with no huge payoff.
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 :)
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.
I don't think it's a leading question - I think if they get a large enough sample size, it will be a worthwhile survey of the Python community's 2/3 behavior.
Ultimately, you did pro-Python 3 supporters a disservice by not speaking up.
I suspect the survey is probably selection biased towards 3 as it is. In any event, whether respondents considered it a mistake or not, it's a mistake.
I think that's a very significant question. I would guess that 50%+ of Python users don't use Python 3, and thus would be counted as anti-Python-3, if not for that question which allows them to say "I don't think Python 3 is inherently a bad idea."
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.
It's way way way higher than 50%, if my sample is accurate.
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.
Being a newbie at Python myself and seeing how much the Python devs are trying to get people using Python 3, I was initially planning on just using Python 3 for all my Python coding. That was until I realized how many libraries exist only for Python 2.
Why not the question "Is staying on Python 2.x a mistake?"
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.
I agree that the survey is poor, but it is not bunk.
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.
Depends on how you interpret "mistake." I don't think that improving the language is necessarily a mistake, but the way they did it is a mistake. It should have been an absolute requirement that, one way or t'other, a user could employ 2.x libraries transparently. No change should have been allowed until and unless a way was found to make it not impact backward ecosystem compatibility. This is a law of nature that was ignored and 3.x is paying the price that anyone could have predicted (and most did.)
Not ensuring library compatibility was lazy, egotistical arrogance and will ultimately relegate 3.x to being a historical footnote.
I really wish there was an "undecided" option for that particular question. I said "yes", but only because I think having backward compatibility trumps cleaning the language up.
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 wouldn't, not yet. There's not enough support. Great ideas, but the support isn't there for it yet: not in libraries, not in operating systems, not in documentation.
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.
But for the newbie user it's a nightmare. If you google "Python training" you're going to get books, sites that offer training from 2.5 to 3.3. And those are recent sites (like 2012+).
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.
> If you google "Python training" you're going to get books, sites that offer training from 2.5 to 3.3. And those are recent sites (like 2012+).
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.
I wish it were true that existing online materials are appropriate for both Python 2 and 3.
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.
Might I be so bold as to recommend not using print in the first place? Print's behavior changes depending on the environment, the capabilities of your terminal, and if you're piping to something else.
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.
You're always going to have old documentation on the Internet (and it's a good thing!). The more annoying problem I encounter (not Python specific) is blog posts or news stories without publish dates.
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).
This isn't actually true anymore for many, many things:
- 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
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?
No, if it is a library, that you use all over your code. And you will not risk that your project fails, just because somebody wants to use only the newest stuff. Nobody in a time critical project (when it is not?), will switch from Py2 to Py3 just because it is the most recent version of Python and replace at least one library that is written in C and does not work in Py3. Either you have to replace the whole lib or you have to port the lib itself (what is not easy, when you don't have an experienced extension coder in team -- and also than, it is a risk!).
But the GP comment wasn't just addressing porting projects (which I would understand), it was "one single dependency that doesn't support py3 is the death knell to using it for anything, EVER" (emphasis theirs).
That's a fairly strong opinion to take, and in my opinion, goes far enough to be ridiculous.
When you have the option of starting a project with py2 or py3 and you choose py3, and discover X days into the project that you have a broken dependency that wouldn't have been broken in py2, you've just increased the cost and time to deliver the project by an unknown factor.
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)
When you have the option of starting a project with py2 or py3 and you choose py3, and discover X days into the project that you have a broken dependency that wouldn't have been broken in py2, you've just increased the cost and time to deliver the project by an unknown factor.
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.
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.
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.
(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)
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.
Its all well saying Django supports Python 3, but when you reply on a dependency, such as MySQL connector (which I assume a LOT of Django users will want to use), then Django effectively doesn't work with Python 3.
I have problems with the way this is worded as well. I don't think Python 3.x was a mistake. I think the mistake is continuing to develop it in parallel with 2.x with no definitive end of life for 2.x is the mistake.
No, I disagree. So many programs rely on further support for Python 2. When you would end the life of Python 2, I myself would think, if I have to make a switch, should I switch to a more reliable codebase??? (Ruby, maybe -- I don't know enough about Ruby, but I would have a look on it)
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!
Setting an end of life for Python 2 would be the forcing function needed to ensure Python 3 is reliable and the migration path is clear. Knowing the end is coming would drive us (the community) together to discuss and resolve these issues.
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.
Even than, I doubt that it would be helpful, since still so many C extensions are just not available in Python 3. I also don't think that it is a problem of apathy, but of wrong initial planning. With better initial compatibility, a bigger momentum could be reached. Now the decisive point is over and we will have to live long with both versions around (even when Guido sets a date).
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.
Dear Apple. Please include python 3 as /usr/bin/python3 in all future Releases. And Microsoft, if you're listening, it would be extremely sweet if you would install python by default as well...
Yes, well, that's why I said it would be sweet of them. You know, like, a grouchy old military dad taking his daughter to see Snow White. It may not he his choice of entertainment, but it's very sweet of him to take her. :-)
The biggest thing that drives me nuts about py3 is just that its repl doesn't evaluate generators. I'm sure they had their reasons, but I use python as my go-to calculator, and when simple operations with maps/ranges give me a representation of a generator ("<map object at ...", whatever), then it's just less useful to me. I could be alone in that use case though...
Those things return generators now to avoid wasting memory (you don't need to create possibly humongous list and keep it in memory during the iteration). If you want a list, just do list(your expression). If you forgot about it then do: list(_) as the very next thing. Like this:
Yeah, it's definitely something that can be worked around, but it's something I don't have to get around in python2, so I keep using python2. Nothing truly major, just a sticky point.
> The biggest thing that drives me nuts about py3 is just that its repl doesn't evaluate generators.
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.
You are definitely correct; it's really the combination of py3 using generators more frequently (which is a definite good thing) with the py3 repl not evaluating them that keeps me going back to py2 for my repl needs. A more fair comparison is with ghci, which expands thunks and runs IO actions when functions return them. As others have pointed out, this can be "dangerous" in the sense of flooding your console with crap (try typing [1..] in ghci; its' annoying, but not the end of the world either), but it's also really convenient when that's what you want. The python2 repl/functions do what I want, and the python3 repl/functions don't, or at least don't often enough that I keep going back to python2 for all my repl needs. Just a random chunk of anecdata, I guess.
It's really only a solution if the calculator usage is on a small number of computers, but you can just import * an override of the map function that behaves however you want.
The override is easy:
pymap=map
def map(...)...
(and maybe for calculator style usage you would name your list returning map and range m and r, which would also help with not confusing them with the usual behavior)
A list comprehension would work for GP, who wants a calculator. But others like to try out snippets of code in the REPL before using them in programs, and in that case you want the code to be the same.
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:
The Python interactive shell could check the user's input: If it'll take infinitely long to run (e.g., an infinite generator), then it'll halt. If the code will eventually return, then it'll be run, displaying results to the user. Seems simple enough, no?
That is the approach that Haskell takes. If the repl responds to ^C by aborting whatever line it was evaluating then infinite results are little more than annoying, and you quickly learn to restrict what it prints to the first few elements (in python this would just involve appending [:n]). Ultimatly this is a question of which uses you want to optimize. Personally, I find Haskell's approach more useful as a calculator.
A middle ground that I have not seen is automatically evaluating the first few elements and showing those as part of the <object> output.
Only reason I still use 2 over 3 is that 2 gets the job done, is well supported and I don't see a big enough reason to move to 3. If 3 had a big performance increase, then maybe I would switch. Anyhow, I'll probably move to 3 at some point just because at some point more people use it (more code on the Internet in 3, more StackOverflow answers in 3 etc.)
The survey is missing sets of answers for users who rejected or moved away from python because they were turned off by the disconnect between core devs and the community when python 3 got released.
I can't say I understand this attitude. It's analogous to cutting off your nose to spite your face. Both Python 2 and 3 are actively supported, and there's a clear migration path defined. The migration isn't complete yet, but it's progressing at a development friendly pace.
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.
What language would you recommend, that would have a similar jump in syntax, and still give you more speed and resolve memory usage?
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'm actually leaning towards Haskell and Clojure these days. They get me more of the simplicity that Python won me over with along with other benefits.
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.
I would actually pick Go. Yes, the strong static typing is a pain in the ass, but the rules are simple and regular. It's easy to understand and implement.
The same cannot be said for the multitude of changes to Python.
I use/used Go for a while, but early on I thought the type system was stronger than it was. I was disappointed in a later project, and started looking at languages with stronger type systems.
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.
Go would be my first recommendation. The strictly enforced coding habits, lack of generics, the packaging system without dependency versioning and quirks like typed nil are a small price to pay for the sane syntax, impressive performance and a very easy to use CSP implementation.
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.
Missing a question. "Would you switch to python 3 if they brought back the print statement"
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.
Personally, I prefer function. I can understand that others have a different preference; what I find surprising is the number of people who seem to care so much about this. Nevertheless, it is very evident that you are not alone.
I don't mind the print statement/function thing but I am bothered by the pain when dealing with byte strings. I use Python to talk to hardware that doesn't speak unicode, the contortions I have to go through to get byte strings to behave correctly on py3 are frustrating. I have no problem with the default string being unicode, but why can't byte strings be implemented like the unicode strings were done on py2.x?
What's the specific issue? I find it solves loads of issues before where you could mix bytes and unicode by accident. Not only are they more explicit, I find the fact that `b'\0'[0] == 0` - way better when working with actual bytes.
What do you mean by "string manipulation"? bytes are not text strings. If you actually mean text operations, then converting them is something you should also do in py2.
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?
I read it all, and to be honest I think I agree the most with http://bugs.python.org/issue3982#msg180441 (.format may be making some things simpler, but it goes against the idea of well separated bytes -vs- text)
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 :)
As many comments in that thread point out, byte arrays are not strings, and casually conflating or implicitly converting the two is terrible mental hygiene.
That's why I'm asking really - not only those two would be pretty much equivalent, there's really nothing that can be expressed with one, but not the other. I mean that's kind of like saying "would you use it if they called the binary snake instead of python3" - what's the reason apart from personal preference for the syntax?
What is the advantage of python 2 print over python 3 print? I believe that python 3 print can do everything python 2 print can do on the same level of elegancy. Also, python 2 print has a weird trailing-comma syntax. When a trailing comma is added to a print statement, a space is printed when another print statement is used. For example,
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?
no trailing space is a convenient shorthand - print by itself prints with a newline (so it might make sense to have print() vs println()); print + comma omits the newline and waits for the next print statement, so that
I understand this, but couldn't you simply wrap print itself in a function, and do that in Python 2.7 already? Granted, your method saves you one line and it's more 'natural'.
Not really, since the Python 2 version is a keyword, and not a function, you can't simply provide keyword arguments to it. You would instead have to build up a string and eval it. It would have to be something like this (completely untested):
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 += ','
eval(print_stmt)
if outfile is not None: outfile.close()
sep and other end values for anything other than ' ' would not be possible.
In my view, the importance of the 2 vs 3 issue depends on who you think the typical Python user is, and the user population may be changing rapidly.
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.
I may be old, but this just reminds me of Larry Wall's Perl 6 and in my opinion Python 3 should have been a hobby project / incubator for changes that could be introduced to Python 2 eventually.
I'd also like to see the results. Curious, did you create this survey to see if there would be interest in a long-running Python 2.x fork?
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.
I'm curious what the Python 3 adoption status is inside of Google, which I think of as a place that's relatively pro-Python, very pro-new stuff, but also possessing a lot of institutional inertia and giant amounts of code. Have parts of Google overcome the inertia and switched to 3? Do fights break out in the halls? Is it 2 forever and always?
There was a dynamic graph somewhere showing the number Python 3 and Python 2 packages on PyPi against time, no amount of googling can find it, does anyone know what I'm referring to? I'd love that link.
My only question is... does Gunicorn+Gevent work on Python 3 yet? Last time I checked one worked and the other only had a branch which you could use but wasn't in master yet.
http://bugs.python.org/issue3982
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. :-/