Python 3 Is Winning Library Developer Support
blogs.msdn.microsoft.com
blogs.msdn.microsoft.com
Aside from Unicode, I don't like some of the other changes. The overkill on the "one obvious way" bugs me in particular, e.g. the removal of reduce as a core function.
The existence of "one obvious way" isn't set in stone. It depends on context, and it's like the language developers didn't realize that when making their decision.
While I use reduce a lot, I would guess that even with comprehensions making most uses of map and filter obsolete, that reduce is still the least commonly called of the three.
But for projects that mix unicode and byte strings, and hope for the best (it works okay as long as it is ASCII or UTF8), the upgrade requires substantial work.
I don't think he's wrong. I think he's probably right. And, I know it's a rant. I just don't agree that many of his points are "problems."
There are many, many issues that the change fixes. And, like every change, it does break some things. But, it was done for real reasons, not just because: https://docs.python.org/3.0/whatsnew/3.0.html#text-vs-data-i...
Some of the reasons were technical, some were very "we should be more standard."
I agree with the Python3 team, here. Mostly because it's more obvious what Python is doing now. But, it's also cleaner in my opinion.
It makes things harder, sure, 100%. But that's not always a problem or a bad thing. In this case, the more work comes with clarity and less chance for bugs (less edge cases).
What? Python has been one of the significant exceptions on this front because Enthought actually shipped a product which was expected to work on Windows. Python also goes out of its way to make sure that things work in sane ways even when Windows has no real equivalent.
I also suspect this is one of the reasons for Python's ascendancy over other scripting languages. By being one of the few scripting languages that runs decently on Windows, you gain an automatic user population advantage.
I'm a python newb and maybe I wasn't doing something right. I'm more used to Linux/Perl and doing "Perl -M CPAN ..." which just works. 'pip ...' just didn't.
I was not left with the feeling that Python ran as well on Windows as on Linux.
0) Check if the package came preinstalled with Anaconda
1) if not try to use conda to install packages,
2) if conda doesn't have the package, see if it's been uploaded here: http://www.lfd.uci.edu/~gohlke/pythonlibs/
3) try pip.
It'd be nice if Windows made an effort to provide a sane environment for Python, because the Python devs certainly aren't doing anything to make things sane on Windows.
If it is not, you can often do python -mpip install xxxxx
And you're right there are some gotchas - for instance pip install -U pip won't work to update pip itself as on Windows a program can't seem to overwrite it's own executable.
I could be wrong as it's been a long time since I helped anybody with that on Windows.
By comparison, C# tooling makes some things really difficult on Unix-like systems. For example, try spawning a process and redirecting file #3 to a pipe. I honestly do not know how to do that in C#. Python is fantastic at being cross-platform glue.
The Perl folks eventually admitted that version 6 was a separate language; we'll see how that turns out. The Python ones can't make the same move, since version 3 offers no major benefits/changes over version 2, so they simply have to continue the beatings until... everyone moves to version 3. What a colossal waste of time!
Developers aren't obligated to please their users in exactly the same way that users aren't obligated to use their software. Just because there's no money, it doesn't mean there's no transaction, and popular free software is based on benefits to both parties.
If they want to help Python users, they should improve performance and add backward-compatible features. If they want to have fun experimenting with programming languages, they should change "Python's" syntax and semantics whenever they want. Either would be better than the current approach.
I think asyncio in python3.4 and async/await keywords in python3.5 is a gamechanger. It's hardly a minor improvement
And 2) I know of no reason those features couldn't be implemented in Python2 other than "we don't want to, because otherwise few people will ever upgrade to 3"
You can build stuff on top of C, Fortran, POSIX, etc. in 2016, and be pretty confident that it will still work with their 2026 versions. That's not valuable if your slapping together an MVP that no one will care about and will die in a few months, but it's incredibly valuable for developing big, complicated software. Or for little personal utilities you want to write once, then not have to maintain. Perl and Python moved away from that longevity, each in its own way. Maybe that will make them better suited to a world of continuous Cloud-based churn, but there's more to life than that.
Actually, I do know why you were downvoted: you summarize the situation rather well. And a lot of people do not want to hear it.
In fact, Google Trends [1] seems to indicate that, too. After what was probably an initial stomach-drop of broken compatibility, python is picking up a lot of new developers again.
https://www.google.com/trends/explore#cat=0-5-31&q=python&cm...
http://www.tiobe.com/tiobe_index
It doesn't, AFAIK, distinguish between Python 2.x and Python 3.x though. But the trend seems generally favourable for Python in general.
That, and the facts that Rust is ahead of Go, and that the two of them sit at only ~0.4% usage combined.
I mean, you have D WAY ahead of Clojure? Seriously? Not to knock D, or @walterbright, but does anybody buy that D has significantly more industry adoption than Clojure does?
Hey, maybe I'm wrong, or maybe it is the "HN effect", but that's why I say that I consider the Tiobe Index "suspect". For the top 10 or so, it's probably a decent approximation, but beyond that I think it's highly, highly questionable.
Android adds to the top of that.
I don't get what you're saying. I didn't say anything about Java being on top, except to specifically say that Tiobe is probably a reasonable approximation near the top. It's the "long tail" that I think gets especially hinky.
I have however not downvoted you, so if anyone did it was somebody else.
(btw: seems I've crossed some magical threshold and people seems to be upvoting almost anything I write now. Might be time to create a new account, again :-P)
Yes. D has a very clear use case and makes sense for it (and didn't have a lot of competition there until the rise of Rust). Clojure has a lot of (often vocal) fans but in practice the compelling case over the more popular Scala just isn't there - at least that's what I've seen in multiple-languages-but-JVM shops (biased by the fact that I'm a Scala programmer myself). You'd get a few Clojure fans who would talk the language up, but nothing in actual use.
Of course, my view may be tainted by the fact that I live very near Relevance and know and interact with a few of the Relevance people.
Anyway, this isn't specifically about D or Clojure. I just generally think that the long tail of the Tiobe index looks pretty fishy at times.
And for exactly that use case, there is industry adoption.
Just to put things in perspective a bit further.
It's the defacto language to learn at the university level. And many large companies use it on the backend (Google and Amazon). Small companies who outsource to cheap labor overseas will probably have their work done in Java on the server-side (though this is changing).
Not surprising at all to me.
Still a great language though.
I believe TIOBE is heavily weighted towards search terms, not job listings though.
Go is a simpler language thats not evolving as quickly as rust is and the hype has started to wear off.
http://www.infoq.com/news/2016/01/swift-overtakes-objective-...
Swift is the de-facto future replacement of Objective-C for Apple ecosystem. It's got a while to go yet - a stable ABI for one - but once that happens (with Swift 3 later this year) then you'll start to see it take off. Plus, since it was open sourced it has been made to run on Linux and Raspberry Pi devices and has attracted a hugely varied and vocal community.
This was optimistic, but at least we see that the community is indeed gradually moving to Python 3, even if it's taking a few more years.
In any case, I'm very happy to see the Python 3 transition moving forward. And let's hope this does not happen again.
Python's back-porting of 3.x features caused Python 3 adoption to take even longer (no pain, no gain). But, I think this was a necessary evil, because if PSF had forced everyone with a "upgrade or perish" attitude, I think many would have abandoned Python.
I think that speed can't be treated like a niche feature (e.g., via PyPy, Cython, etc.) any longer; not with tools like Go out there.
That said, I'm sure there are specific things Dropbox needs to solve for 2.7 which PyPy doesn't do.
I say that with all the appreciation in the world for the work that went into original fabric, which is a wonderful tool. Criticism may be harsh but it's not inaccurate. What's amazing is that the forks to bring fabric to python3 haven't really caught on and I think that's partly because fabric is something you do not use inside your application. It's used in deploy and configuration scripts. It being python 2 hasn't been a problem for most people since most distros and platforms ship with python 2 support. It's just that the people who want to stop writing python 2 for everything including their deploy scripts who are the most vocal and it's not a big enough group.
The fabric dev basically has until platforms start to abandon python 2, and who knows when that will be, so maybe they have forever for their great rewrite.
And if I recall, it's only half of fabric's feature set.
I found it shocking that Fabric was still not supported.
On an unrelated note, a lot of people I have encountered claim Gevent as the reason they haven't switched yet. For now I guess such claims are shaky, assuming the PyPI page isn't false advertising.
I don't know why PyPI isn't updated yet.
the only real selling point is that strings are unicode by default. Unless I'm missing something python 3 just doesn't really seem to be worth the effort, yet.
Can someone enlighten me?
There's no reason you can't be part of the equivalent population for Python.
Very few people still program in 77 and only if they really have to. Everybody who has a choice has moved on to at least Fortran 90 and you won't find anybody seriously arguing that Fortran 90 isn't a massive improvement over 77.
I believe that many of not most Python 3.5 users consider it a massive improvement over Python 2.7. My examples come from the core developers, so is highly suspect to bias.
That's because you can compile Fortran 77 with a modern Fortran compiler and link the old code into your new one without a lot of work.
On the other hand I fail to see how you could use the Pyhton 3 interpreter with some old incompatible Pyhton library.
Some answers are: it's faster, it runs on new OSes, it has better error messages.
Those then become the same answers to the OP's question about shifting from Python 2.x to 3.x.
While with Pyhton 2 to Python 3 there is usually a non trivial amount of work you need to put into migrating an old codebase.
You're siding with a shrinking ecosystem (Python 2) over a growing ecosystem. Depending on your use case, this could range from inconsequential to inconvenient to disastrous.
If you have an existing codebase in Python 2, then perhaps the conversion to 3 isn't worth the effort. But if you're developing new software, the question is why not make the minimal investment to make your work compatible with the future of the language? When I see a new library and the author couldn't be bothered to adopt Python 3, it's a big red flag.
Couple that with 2.7 being good enough just makes the situation "worse" for 3.
Also that's kind of what this post is about. Pretty soon there'll be a bigger risk of finding that some library you want is Python3-only than finding that some library you want is Python2-only.
Probably because of the ecosystem. And that will be when everyone transitions to Py3, when stuff they want to use is Py3 only.
This always bugged me about Python:
>>> exit
Use exit() or Ctrl-D (i.e. EOF) to exit
>>> range 4
Traceback (most recent call last):
File "python", line 1
range 4
^
SyntaxError: unexpected EOF while parsing
>>> print 4
Traceback (most recent call last):
File "python", line 1
print 4
^
SyntaxError: Missing parentheses in call to 'print'
//rant >>> exit
Use exit() or Ctrl-D (i.e. EOF) to exit
Python has no idea that's what you mean.
>>> repr(exit)
'Use exit() or Ctrl-D (i.e. EOF) to exit'
>>> print 4
SyntaxError: Missing parentheses in call to 'print'
Meanwhile...
#include<stdio.h>
int main(void) {
printf "Hello World\n";
return 0;
}
hello.c:4:9: error: expected ';' after expression
printf "Hello World\n";
^
;
hello.c:4:3: warning: expression result unused [-Wunused-value]
printf "Hello World\n";
^~~~~~
hello.c:4:10: warning: expression result unused [-Wunused-value]
printf "Hello World\n";
^~~~~~~~~~~~~~~
2 warnings and 1 error generated.
Sorry I hit a nerve. You insisted it 'wasn't the same' but didn't give an example.
If you don't need what Py2 provides, I don't know why it wouldn't be 'good enough'. And since I built a lot of complex stuff in Py1, I can't imagine why anyone would think it is not good enough for building complex stuff.
1. I got used to it, fairly quickly. That made me care less.
2. I used print-statement debugging less, and unit tests more. This was a good thing generally.
3. For those times when I did need print to debug, I found I could drop in pprint:
import pprint
print = pprint.pprint
I've rarely needed naked print to do anything but quick testing and debugging (because by the time I have a command line script, I want at least to have a -q option, so I need to run output through some kind of proxy function). The standard arguments for print() (i.e. composability, extra arguments), I've not needed, but the ability to replace it, I rely on totally now.
Of course, YMMV, this is just my experience.
print isn't a statement in python 3 and range was never a statement
Additionally, eventually new libraries will also stop supporting 2.7, with the same issues as well as making development harder (or not as easy as your peers/competitors)
It's not a surprise though. This all stems back to the original reasons why Python3 was a bad idea. Some things to keep in mind regarding Python2/3.
- Python3 is pure technical churn, nothing there is true technical innovation. They simply mixed the pot to their liking. Unicode is supported in Python2.
- It is slower than Python2 for most people. Though there are crafty arguments out there that it's a wash. It's really not.
- CPython3 was adopted to benefit the core development team, to make it easier to maintain. Not the community on the whole. The community has paid the price by doing a lot of unnecessary ports.
- CPython3 was deliberately created to not support Python2 code even though modern VMs can easily support this. The CLR is a great example. They did it this way for their good, not for the community.
- In most things in life, you'd always want to be using the latest supported version. That isn't the case here. It may still effectively "fail" with a permanent split. This migration is not even close to being completely in the books and won't be for another 10 to 20 years. So why punish yourself moving before it's in your best interests. The syntactic differences are so slight, it's extremely easy to switch to Python3 if it ever truly reaches Python's momentum (this article does not convey momentum holistically, that includes package downloads and the majority of employers using 3).
- Related to the bullet above, almost all job opportunities are still Python2.
- The ecosystem can't keep up, PyPy is still only production-ready on Python2. Python 3.2 support is essentially experimental by comparison.
- Many changes and additions are being made and they aren't being vetted by the larger community. No significant userbase for Python3 has created this situation. Mistakes are being made and no one is around to speak up because the core devs don't care.
- Python3 is feature-soup. There is now a new 4th and possibly 5th string formatting method in 3.6 incoming. Really jumped the shark on that one. See Mark Lutz's great insight on this topic and more.[0]
- Downloads are still dramatically in Python2's favor, to this day. Judging from downloads, there's a ~10% community userate of Python3.
- The bullet above means that the Python3 packages you do use are far less vetted and tested than the Python2 equivalent.
- CPython3 was slopped together. The initial 3.0 release was mostly pure Python in effort to get it out the door. Many parts of the standard library that are written in C are slower than the modules used in the CPython 2.7 counterpart, to this day. It was not and is not being tested. The users are not there to test it either.
- Community trust has been broken, I'm not sure anyone really believes another big break isn't incoming regardless of statements to the contrary. The core dev team is going to do what they want and you're going to like it, period.
- Python3 zealots have done a lot of harm by not accepting valid criticism, and aggressively attacking those who do what is in their best interests (which we should all do, this should not just apply to the CPython core devs), and continue using Python2 all these years. Watch for downvotes instead of countering my points.
- The 2020 date is a just a big political stunt and scare tactic. Code will continue working after 2020. As noted, it works better in CPython2 and PyPy today, and likely will in 2021 as well.
- Python3 lives off of and is pushed by PSF propaganda. No way around it as there is no innovation involved. Which is what should determine if new technologies are adopted or not.
- Usually when people make mistakes, such as Python3's existence, or the inability to mix Python2 and 3 code in the same VM- they go back and fix them. That has not happened with CPython3.
- Even back in 2014 projects such as Pyston from GvR's employer (Dropbox), were Python(2)-only. It's still Python2 today, which says it all.
All that said about this trainwreck, I'm in favor of getting back to a single major version of Python for the community. I'm using 3.5 for a single project myself but I will still plainly state the truth about the Python3 transition. It was a bad idea, for all the wrong reasons to benefit a rogue band of developers who believe since you aren't paying them- you as a community do not matter and should shutup and get to porting.
I love Python but will eagerly embrace Pythonic language alternatives as more are released. In particular, I'd love to see a Pythonic Erlang variety similar to Elixir. Or better yet, just a concise, minimum featured version of Python without all the extra. Picking 1 string formatting method would suffice, the basics but done well, stable in feature-set like Go and compiled. Something similar to a Pythonic Lua would suit me and would be the ideal case for a Python-reboot. Making it a subset of Python2 would make a lot of sense.
Lesson learned and bottom line is that we should overthrow all BDFLs.
[0]http://learning-python.com/books/python-changes-2014-plus.ht...
That "rogue band of developers" consists of the Python core committers - the people who have been volunteering their time and energy for years to bring you Python in the first place.
"nothing there is true technical innovation" - There is so much innovation in 3.x, I could write for an hour and not list everything.
"CPython3 was slopped together" - From my perspective, most of it has been extremely well thought out. That is not to say that everything turned out perfect. What software project on this scale has NOT has things that, in retrospect, turned out to be mistakes? Hindsight is 20/20.
It's like you are looking at all the many, many, many aspects of the change from Python from 2 to 3, positive and negative, and only seeing the bad things. If that's your mindset, I feel really sorry for you.
Could you give one big example? It all seems like nice to haves to me.
That said, it depends on what you mean by "innovation". To me the above is a worthwhile improvement, and more important than (say) asyncio. It's also a "nice to have", in the exact same sense that 2.7's features are a nice-to-have compared to what's in 2.5. At the end of the day, if you want to continue coding in 2.7, that's what you should do.
If the syntax differences really are that slight, wouldn't the type of python you're fluent in not matter? Feels like you're saying something like, the differences between the two languages is like Australian versus American English, but that all the jobs are in American English?
I would say, really fundamentally python is an extremely 'opinionated' language driven by an extremely 'opinionated' BDFL... this isn't necessarily a bad thing, just saying given the guiding principles of the language it really shouldnt be so shocking that a lot of work has gone into rolling out a 'pythonic' version of python that doesnt bring all that much to the table that isnt subjective...
There is now a new 4th and possibly 5th string formatting method in 3.6 incoming
FFS. Yes, indeed.
For what it's worth, you are not alone in your irritation at the situation.
...but what can we tangibly do?
The best bet is still to write new code in python3, and slowly depreciate python2 code and replace it whole scale with new code either in python3 or 'more appropriate language x here'.
A new python-like compiled language which was a subset of python2 without the standard library would be a welcome breath of fresh air. We can certainly daydream...
...but what can we tangibly do?
- PythonCore should be just what we the people need, rather than feature soup with community promise of compatibility like Go. Python2 subset, removing some extraneous features and removing the std lib.
- One could start with CPython 2.7.11 and disable all the keyword features that weren't wanted or strictly needed. I would go about this by asking the guys behind PyCoders Weekly would send out a survey asking Python developers a series of questions on what to keep. Combined with surveying a few recognized Python experts (not Guido). I think at this point in Python history, we know what we definitely do and do not need.
- As well, ditching the standard library and putting it all as strictly package imports. Forcing it all to compete with other solutions on equal footing but still being there for reference. That would be the basis of the new 'PythonCore' and give people something they could rely on as a stable, unchanging featureset for years. New features would be imported, extremely rarely added to the core.
- This would be declared as a continuation of Python2. Though clearly not supporting all existing code, it may require little more than changing your string formatting in the end.
- After this, two main efforts would be involved. Initially ditching the CPython 2.7.11 base implementation for a compiled alternative. Nuitka would be an interesting solution to look really hard at, PythonCore may be the language that Nuitka has been waiting for to really shine. This shouldn't take long to get up and running considering Nuitka is already working and should compile a strict Python2 subset just as well as it does the entire language today.
- The second and I think most important, and time consuming effort would be in duplicating the success of NPM for PythonCore. This would make or break it.
- You could do the same for a Python3 subset but I think what many, many folks (and businesses) want is some option to continue on Python2. This would be a way forward that could be supported relatively easily as the supported core would always remain small. But it still retains the POSIX oriented nature that we all love about Python rather than the Microsoft/JVM/CLR unicode by default decision with Python3. I like many Python2 users, stick to retro OSes without a text / binary distinction. If it was good enough for Kernigan and Richie, it was good enough for Joe Ossanna, it was good enough for Robert Pike. Well, it's good enough for me.
- In sum, influences would be Lua, Nuitka, CPython2.7, NPM.
edit: added relevant platforms
Edit: Really though, it's a problem of apathy. I'm supposed to care about python 3? Why? When I type "python" on the command line (and everyone else that doesn't care, which is most every "filthy casual", right?), I--and everyone else with a default install of Ubuntu and CentOS/RedHat--gets python 2. Fix that, and overnight you'll have massive python 3 uptake.
In fact, you're suggesting I set myself up to be stuck with the problem Maven is in, which is that everyone has an "m2" repository even though they're onto Maven 3. I'm supposed to hardcode "3" into everything? C'mon.
/Rant
This just seems to validate my choice to stick with Python 2 up until now.
No disagreement there. But I'm surprised at the downvotes I've received.
I honestly can't tell if you are joking or think that using "Python 4" as the name of such a thing is a good idea (no way will the Python Software Foundation let you use their trademark, so if you are serious, you are just setting yourself up for hassles).
I think Python 4 is a good name because most Python users feel that Python 3 was a misstep, and never plan to move to Python 3.