TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

Making Python 3 more attractive

141 pointsby explosionabout 10 years ago

34 comments

mangecoeurabout 10 years ago
I think the obsession with the GIL is sort of missing the point - people on python2 live with the GIL and don&#x27;t really miss it, I don&#x27;t think that&#x27;s really the killer feature to drive python3 adoption. Especially considering its almost impossible to do without breaking something (most likely C extensions) and when you see the wailing and gnashing of teeth that came from python3 forcing people to fix their text encodings it doesn&#x27;t look seem like more breaking changes are going to drive python3 further. What&#x27;s more, python already has quite convenient multiprocessing, and python3 concurrent.futures makes it even easier - frankly I think too many people complain about the GIL without having tried multiprocessing (doesn&#x27;t help that it seems every tutorial starts with multithreading, then tells you it doesn&#x27;t really work, and only then tells you about multiprocessing). You only get to complain if that doesn&#x27;t work for you!<p>Personally I think the driver is going to turn out to be type annotations. When you see the enthusiasm for adding type annotations to JS (typescript, ES6, etc) its easy to see that translating to python. Static analyzers can be a huge help (you can already get a taste of it with PyCharm) and I for one would like to move away from &quot;traceback driven development&quot; where you just have to keep re-running the code until all the preventable glitches are worked out...
评论 #9382577 未加载
plesnerabout 10 years ago
Making python 3 more attractive is not the solution, it&#x27;s part of the problem.<p>I can&#x27;t use just python 3 because python 2 is still widely used. I can write code that works on both but now I&#x27;m using the worst of both worlds, and even worse I now have to test on both. And that&#x27;ll last until python 2 goes away completely which, - when has a language ever gone away quickly?<p>These aren&#x27;t fun problems. Improving python 3, making it more attractive, that&#x27;s fun. But that&#x27;s problem 2. Making migration less painful for me should be problem 1. Who&#x27;s working actively on that?<p>What particularly grinds my gears is the apparent disregard for migration in the design. Take the changes to the print statement. Often this is the only thing that prevents my existing code from working in python 3. And it&#x27;s in my muscle memory so I <i>always</i> get snagged when debugging on python 3. For what? Take a read through the rationale: <a href="https:&#x2F;&#x2F;www.python.org&#x2F;dev&#x2F;peps&#x2F;pep-3105&#x2F;#rationale" rel="nofollow">https:&#x2F;&#x2F;www.python.org&#x2F;dev&#x2F;peps&#x2F;pep-3105&#x2F;#rationale</a>. Most of the benefits you could have had if you&#x27;d named the new print function something else. I can understand that you regret adding it in the first place. What&#x27;s even worse though? Adding it and then removing it in an incompatible way.<p>If you want to make python 3 more attractive maybe make migration easier before going on to the fun improvements? There are low-hanging fruits for migration too. How about adding back the print statement?
评论 #9379639 未加载
评论 #9379720 未加载
评论 #9379347 未加载
评论 #9380080 未加载
评论 #9379356 未加载
评论 #9380377 未加载
评论 #9379315 未加载
评论 #9383851 未加载
评论 #9380071 未加载
sagoabout 10 years ago
GIL seems to me to be only a niche problem in reality. But it is a bit of a storm in a powerpoint (i.e. people see it on a list of features of python and panic. Even though, as the article says, Javascript has much more constrained single-threadedness).<p>I&#x27;ve been deploying python for almost 20 years, and I haven&#x27;t had a single performance issue that was caused by GIL and couldn&#x27;t easily be worked around. In my experience, building big multithreaded applications with shared memory access isn&#x27;t great design anyway. I prefer systems that share as little as possible, and can therefore scale beyond a single machine when needed.<p>So I think the focus on the GIL is a false quest. It isn&#x27;t a bad compromise to a thorny implementation issue (it allows certain performance optimisations, without forcing you to worry about re-entrancy and atomicity when writing simple code). Removing the GIL will be a big thing for pundits, I think, but won&#x27;t make much of a difference to big python deployments. It certainly isn&#x27;t the killer app for Py3 adoption.
评论 #9379602 未加载
评论 #9384758 未加载
rdtscabout 10 years ago
&gt; The Unicode support that comes with Python 3 is &quot;kind of like eating your vegetables&quot;, he said. It is good for you, but it doesn&#x27;t really excite developers<p>Saddly I agree with that. There needs to be either a big stick (Python 2 being really bad, but it is actually pretty good) or a large carrot (&quot;Oh look 3x performance improvement!&quot;).<p>Something like a carrot was presented during Pycon and that was gradual types (optional types). These reduce some cases covered by unit tests, make code more readable for new developers, help with IDE support, and of course assist with general static checkers. According to Guido 3.5 should start having a partial support for it.<p>But in general I would have liked either one of these instead (some are contradictory, arbitrary hard, or downright impossible):<p>* At least 2-3x performance improvement<p>* No GIL<p>* Merge greenlet library in the core (to make eventlet or gevent work)<p>* Some kind of an ahead of time compiler that bundles just the needed interpreter library parts into an executable<p>* Firefox and Chrome agree to add browser suport for it<p>* Mobile support (native Android support or Apple ditches Swift and uses Python instead).
评论 #9379101 未加载
评论 #9379321 未加载
评论 #9379512 未加载
eeZiabout 10 years ago
Reasons I am excited about Python 3:<p>* &quot;yield from&quot;<p>* Unicode support (I&#x27;m German and the clear distinction between bytes and unicode really makes my life easier)<p>* function annotations (PyCharm interprets them and uses them for static type checking)<p>* cleaned up stdlib (not only names, but also features)<p>* asyncio<p>Library support is very good nowadays, pretty much all of the important libraries are either ported to Python 3 or have an active fork. Even OpenStack is working on Py3 support.
评论 #9379426 未加载
评论 #9379337 未加载
评论 #9379413 未加载
cookiecaperabout 10 years ago
I don&#x27;t think any of the things proposed will really drive conversion from Py2 to Py3. I don&#x27;t think developers need to be excited about it, it just needs to be plausible. Python 3 has some significant momentum now (these talks seem overly negative about it). Developers are waiting for the signal from the enterprise Linux distributions that Py3 is &quot;truly stable&quot;, i.e., they&#x27;re waiting for it to be made the default Python. Once this happens, any remaining holdouts, which, again, are not that many of the actual libraries that people regularly use (cf. <a href="https:&#x2F;&#x2F;python3wos.appspot.com" rel="nofollow">https:&#x2F;&#x2F;python3wos.appspot.com</a> ), will stop their moaning and finally catch up.<p>I think if someone hasn&#x27;t moved to Python 3 yet, no iterative change is really going to get them to do it. It&#x27;s OK if old software is resistant to breaking changes; this is about building a good ecosystem for the software to come. If it was about making things easy for people who&#x27;ve already written their software, Python 3 would not have been released in the first place.<p>Honestly I don&#x27;t really see why anyone cares about whether Mercurial is Py2 or Py3, since it&#x27;s not a library and isn&#x27;t holding up new development. Mercurial can use the Py2 interpreter to its heart&#x27;s content and it shouldn&#x27;t have any effect on the prosperity of Py3.<p>The Python community needs to get serious about pushing adoption of Py3 by the distros, and then we can put this navel gazing to rest and move on with Py3 finally realized as the standard.
评论 #9379121 未加载
vessenesabout 10 years ago
Python developers would almost all upgrade in a single minute for 30%+ better performance.<p>It&#x27;s interesting that performance wasn&#x27;t a topic at this rump session as reported; I moved over to Go about a year ago, and while I miss Python&#x27;s expressivity at least once a week, I&#x27;m just not willing to slow down all my programs by 5x.<p>On the other hand, if Python could double in speed, I&#x27;d likely try to rework it into our workflows. Well, maybe. I really dig Go.
评论 #9379322 未加载
评论 #9379197 未加载
评论 #9379251 未加载
iandanforthabout 10 years ago
Nothing in that article matters to me and I use Python every single day. I guess if you know too much about a thing it&#x27;s easy to lose sight of what &quot;normal&quot; users care about. So here&#x27;s my list:<p>1. Speed<p>2. Language warts (e.g. del, __init__, import *, while: else:)<p>3. Lack of a modern UI toolkit<p>4. No native support in Android, iOS, or Browsers worth mentioning.<p>Right now Python is the perfect prototyping, glue, and modest workload language.<p>You can make it better for heavy loads by fixing 1. You can make it even more attractive to novice programmers by fixing 2.<p>But you really have to get to 3 or 4 before it becomes truly attractive and you get a mass adoption.
评论 #9379253 未加载
评论 #9379154 未加载
评论 #9379146 未加载
评论 #9379248 未加载
评论 #9379707 未加载
byuuabout 10 years ago
&gt; Windows has the CreateFiber() API that creates &quot;fibers&quot;, which act like threads, but use &quot;cooperative multitasking&quot;. For POSIX, using a combination of setjmp(), longjmp(), sigaltstack(), and some signal (e.g. SIGUSR2) will provide coroutine support though it is &quot;pretty awful&quot;. While it is &quot;horrible&quot;, it does actually work.<p>I do this, and it works perfectly well. Here&#x27;s a full implementation demonstrating this approach: <a href="https:&#x2F;&#x2F;gitlab.com&#x2F;higan&#x2F;higan&#x2F;blob&#x2F;master&#x2F;libco&#x2F;sjlj.c" rel="nofollow">https:&#x2F;&#x2F;gitlab.com&#x2F;higan&#x2F;higan&#x2F;blob&#x2F;master&#x2F;libco&#x2F;sjlj.c</a><p>It&#x27;s been successfully used on x86, amd64, ppc32, ppc64, mips, arm and sparc in several projects.<p>However, it still has a good bit of overhead. But you can implement this concept absolutely trivially on any platform for maximum speed. All you need to do is save the non-volatile registers, swap the stack pointer, restore the non-volatile registers from the swapped-in stack, and return from the function. If you haven&#x27;t realized, one function can reciprocally save and restore these contexts. Here&#x27;s an x86 implementation, for example:<p><pre><code> co_swap: ;ecx = new thread, edx = old thread mov [edx],esp mov esp,[ecx] pop eax ;faster than ret (CPU begins caching new opcodes here) mov [edx+4],ebp ;much faster than push&#x2F;pop on AMD CPUs mov [edx+8],esi mov [edx+12],edi mov [edx+16],ebx mov ebp,[ecx+4] mov esi,[ecx+8] mov edi,[ecx+12] mov ebx,[ecx+16] jmp eax </code></pre> This turns out to be several times faster than abusing setjmp&#x2F;longjmp.<p>I turned this into the simplest possible library called libco (public domain or ISC, whichever you prefer.) The entire API is four functions, taking 0-2 arguments each: create, delete, active, switch.<p>The work&#x27;s already been done for several processors. Plus there&#x27;s backends for the setjmp trick, Windows Fibers and even the slow-as-snails makecontext.<p>If Python does decide to go this route, I&#x27;d certainly appreciate if the devs could be directed at libco for consideration. It&#x27;d save them a lot of trouble making these, and it&#x27;d get us some much-needed notoriety so that we could produce more backends and finally have a definitive cothreading library.
评论 #9379437 未加载
评论 #9379402 未加载
mrweaselabout 10 years ago
Honestly I thought that we where done with 2 vs. 3. Every new project we start is Python 3 and I don&#x27;t hear anyone in the office preferring Python 2.<p>Dealing with Scandinavian languages having the Python 3 Unicode support is the killer feature in Python 3, it just make everything so much easier. In terms of performance it&#x27;s fine and library support is no longer an issue (for us at least), everything we use just works.
评论 #9379649 未加载
kylebgormanabout 10 years ago
This post seems to conflate language and implementation. IMO, Python 3 the language has tons of improvements and no regressions. The grief on the internet about Python 3 makes me seriously wonder how many people who don&#x27;t like Python 3 have actually tried it yet. (There are legitimate critiques of Python 3, but they&#x27;re few on the ground and none are presented here.)<p>The suggestions in this post are mostly changes to the implementation (i.e., make it go faster), not the language itself. While CPython 2.7 and CPython 3.4 (implementations) surely have interesting implementational differences that don&#x27;t boil down to just language changes, I&#x27;m not aware of them.
评论 #9385363 未加载
abusqueabout 10 years ago
I find it somewhat unfortunate that a LWN subscriber link is being abused like that. I don&#x27;t think such a link should be shared on a widely accessible platform like Hacker News. I find LWN articles to always be of great quality, and the subscription cost is definitely worth it if you can afford it. Also, &quot;subscriber-only&quot; content becomes publicly available after only a week. There is consequently no reason to share a subscriber link like this on Hacker News. The discussion could have waited a week.
评论 #9379163 未加载
评论 #9379158 未加载
评论 #9379137 未加载
dansoabout 10 years ago
This year I&#x27;ve been spending a lot of time learning Python as I can tell, even being a longtime Rubyist, that Python is the better language for teaching and for general purpose usage...and since Python 3 is already pretty mature, I figured I should just pretend that Python 2 doesn&#x27;t exist...<p>Well, after a month of studying, using, and teaching the language...all I can say is, the conflict between 2 and 3 definitely lives up to the hype :)...Most of the changes make sense to me, and even as a &quot;do-whatever-you-feel-like-aesthetically&quot; Rubyist, I appreciate what Guido did&#x2F;attempted to do in the clean-up. But things like lambda...there obviously was no easy answer...I love lambdas, but it&#x27;s so functionally limited and awkward in Python that I also see Guido&#x27;s point about just removing it from the language (ultimately, he gave up on that)...<p>But what about the built-in reduce()? Again, it&#x27;s another function that I instinctively reach for as a Rubyist...and yet it&#x27;s so awkward in Python that, again, like lambda, maybe it should die? But in this case, Guido halfway-won, and now it&#x27;s been pushed into the functools package. Mmmkay. And so it is with so many of the 2 to 3 changes at the interface level...as a newbie, it&#x27;s just mostly amusing since I have no legacy code to port over, but I definitely understand the strife.<p>But the conflict is still hard to avoid as a newbie...many of the most used guides (LPTHW, Codecademy&#x27;s Python track) are just done in Python 2...LPTHW says right up front to stay the fuck away from 3.x. I don&#x27;t think Codecademy even bothers to mention what version they&#x27;re teaching...obviously, beginners don&#x27;t need to get into the version wars, but as soon as they get past Codecademy and start Googling around, they&#x27;re going to be in for some surprises.<p>Hell, the act of Googling is itself affected by the version-wars...everytime I google for commands&#x2F;subsections in the official Python docs, the version 2.x docs are always at top. Sometimes the 3.x docs don&#x27;t even show up. At least I know that there&#x27;s a 3.x and how to manually switch to those docs...imagine all the novices who are also Googling for references...it&#x27;s not hard to think that the cycle of 2.x indoctrination is propped up by the simple fact that 2.x docs&#x2F;help are always at the top of the Google results.
tdicolaabout 10 years ago
I really wish there was more thought put into allowing code to be compatible with both Python 2 and 3. The fact that the six library (which supports writing Python 2 and 3 compatible code) isn&#x27;t in the core Python library is a big fail IMHO.<p>I&#x27;ve written a few things that are meant to support Python 2 and 3 from the same codebase and it was a bit of a nightmare finding all of the gotchas. Stupid little stuff like changing dict.iteritems() and replacing it with dict.items() (which still exists in Python 2 but doesn&#x27;t do what you expect!) in 3 are a big pain to deal with when writing code that has to work with python 2 and 3.<p>This page has a lot of good advice, but the fact it&#x27;s so long is just a testament to how painful the 2 to 3 transition is for people: <a href="http:&#x2F;&#x2F;python-future.org&#x2F;compatible_idioms.html" rel="nofollow">http:&#x2F;&#x2F;python-future.org&#x2F;compatible_idioms.html</a>
mellingabout 10 years ago
People are always going to whine about any change. The Python community should have been more adamant about dropping 2.x updates. Spreading out the pain doesn&#x27;t make it easier...more code is still being written in 2.x. Ugh, I think I said this 5 years ago. Imagine the tens of millions of new 2.x code that&#x27;s been written in the last 5 years. Oh well, good luck.
评论 #9379080 未加载
wiz21zabout 10 years ago
I&#x27;ve ported a 100KLOC project. Took me a week or so to do it. But it took me months to iron out the last bugs. Had no problem with libraries (so I just had to support the language)<p>Fact is 2to3 is nice but it doesn&#x27;t give you any guarantee about its code coverage. So you go almost just as fast working by hand.<p>But the lack of guarantees, that makes working in production very dangerous.<p>Tried to support 2 and 3 at the same time, but that&#x27;s just too exhausting and error prone (one has to check in both python2 and python3)<p>Projects with 100% test coverage don&#x27;t exist, spare time project have even less test coverage.<p>For me unicode was the driver to change. And it paid off. And I think that&#x27;s the only P3 feature that actually improves expressivity (now I can clearly express unicode strings). The yield stuf, etc. is fine but nothing &#x2F;that&#x2F; impressive.<p>For performance, forget PyPy, a 5x&#x2F;7x improvements is not enough : you still can&#x27;t write high perf code with that. If PyPy was 50x faster than CPython, that would be something.<p>So basically, after a lot of efforts I&#x27;d say write Python3 code because it helps Python or because you use unicode. Any other reason seems a bit weak to me. And that&#x27;s sad, I&#x27;ve bet on Python 4 years ago and it didn&#x27;t evolve much (it surely became very stable, which is not funny but damn useful!).<p>I guess the point of the 2-3 war is precisely that : 2 and 3 are different but not different enough... So people have hard time to make a choice.
kbdabout 10 years ago
The article mentions stackless Python. My understanding is Guido didn&#x27;t want to merge it because it would break backwards compatibility with extensions.<p>That was a <i>long</i> time ago when Python&#x27;s userbase was much smaller. I wonder if Python be in better shape today had they merged stackless back then.
评论 #9379438 未加载
rburhumabout 10 years ago
OK... so from a _practical_ perspective, can someone tell me why I should move to python 3? None of the arguments presented to switch are strong enough :-&#x2F;
评论 #9379453 未加载
Animatsabout 10 years ago
It&#x27;s not about a need for new features. It&#x27;s about basic quality control. I recently ported a medium-sized production system (the back end of &quot;sitetruth.com&quot;) from Python 2 to Python 3. It took about a month. Not because of the language changes, but because several major third-party packages were discontinued for Python 3, and their replacements were buggy.<p>Specifically:<p>- Python 3 forces you to use CPickle instead of the Python version of Pickle. In some multi-thread&#x2F;multiprocess situations, CPickle has some memory allocation error, Python&#x27;s memory becomes corrupted, and things go downhill to a crash. The Python version is fine. I submitted a bug report, but nothing will happen unless I come up with a simple test case, which is hard. Meanwhile I found out how to use the Python version, which works, despite Python 3, and am using that.<p>- PyMySQL (a &quot;drop in replacement&quot; for MySQLdb) originally didn&#x27;t implement LOAD DATA LOCAL. When it was implemented, it wasn&#x27;t tested for large data loads. I kept getting random database disconnects, until I figured out that it was trying to send the entire bulk data load as one 16MB MySQL connection packet. This only works if you configure insanely big buffers in your MySQL server. There&#x27;s no reason to send a packet that big; LOAD DATA LOCAL will use multiple packets when necessary. It was just a lame default.<p>- HTML parsing uses different packages under Python 3. The HTML5parser&#x2F;BS4 combination blows up on some bad HTML, usually involving misplaced items that belong in the HEAD section. The HTML5 parser, obeying the HTML5 spec for tolerating bad HTML, tries to add to the tree being produced at points other than after the last item. BS4 is buggy in that area. I wrote a function to check and fix defective BS4 trees, came up with a simple test case, and submitted a bug report. I have a workaround for now.<p>- Python 3 finally has TLS support in SSL. (That&#x27;s also been backported to Python 2.7.9). SSL cert checking is now on by default. It doesn&#x27;t work for certain sites, including &quot;verisign.com&quot;. This is because of a complicated interaction between a cross-signed root certificate Verisign created, a feature of OpenSSL, and how the Python &quot;ssl&quot; package calls OpenSSL. It took weeks of work to get that fixed. Because it&#x27;s a core Python package, it will remain broken until the next release of Python, 3.5, whenever that happens.<p>- Running FCGI&#x2F;WSGI programs from Apache requires a different package than with Python 2. There are 11 different packages and versions of packages for doing this. The Python documentation recommended one that hadn&#x27;t been updated since 2007, and its SVN repository was gone. There are six forks of it on Github, three of them abandoned. I finally found a derivative version from which much of the unnecessary stuff had been stripped out, and it worked.<p>- Python&#x27;s installer program, &quot;pip3&quot;, doesn&#x27;t know which packages work under Python 3, and tried to install a version of one of them that only worked with Python 2.5-2.6. You have to know to install &quot;dnspython3&quot;, not &quot;dnspython&quot;, for example.<p>These are all bugs that should have been found by now, and would have if Python 3 had a more substantial user base. We&#x27;re six years into Python 3. I shouldn&#x27;t be finding beta-version bugs like these at this late date.<p>Python&#x27;s Little Tin God&#x27;s position on third-party library problems is that it&#x27;s not Python&#x27;s problem. His fanboys follow along. (Comment on comp.lang.python: &quot;You have found yet another poorly-maintained package which is not at all the responsibility of Python 3. Why are you discussing it as if Python 3 is at fault?&quot;) As a result, PyPi (Python&#x27;s third-party package list) has no quality control. Perl&#x27;s CPAN has reviews, testing, and hosts the actual packages. Most of Go&#x27;s key packages are well-exercised within Google and maintained there. PyPi is just a link farm.<p>That&#x27;s why Python 3 isn&#x27;t getting used. It&#x27;s not a need for new features. It&#x27;s that Python 3 doesn&#x27;t work out of the box. Its supporters are in heavy denial about this.
评论 #9379467 未加载
bad_userabout 10 years ago
NumPy&#x2F;SciPy have been the blessing and the curse of Python.
hanlecabout 10 years ago
You&#x27;ve probably read this over and over, but for me there were 2 reasons why Python 3 wasn&#x27;t a top priority: 1) lack of support in some libraries --- this got a lot better; 2) lack of support on Google App Engine.<p>On the other hand, I didn&#x27;t find the new features in Python 3 appealing enough to make me fight the above drawbacks.<p>Last but not least, while I use most of the tools I&#x27;ve developed in Python on a daily basis, they are just that: tools meant to make my life nicer.
peteretepabout 10 years ago
If the Perl6 rewrite is validated by it having a larger user base than Python 3 in 5 years&#x27; time, part of me that has died will be reborn. Unlikely, though.
评论 #9379202 未加载
busterabout 10 years ago
Maybe it would have been great to just say &quot;python3 will be based on pypy&quot;..
评论 #9379760 未加载
r00fusabout 10 years ago
I wonder how much of the Python 2.x stickiness is due to OSX still having 2.x as the default version. I mean, even Yosemite still defaults to 2.7!
评论 #9381356 未加载
mahouseabout 10 years ago
Just make it faster and everybody will move. No need for fancy new stuff... I&#x27;m eager.
评论 #9379454 未加载
评论 #9379470 未加载
willvarfarabout 10 years ago
The way to make Python 3 more attractive is to backport the best bits to Python 2.8...
评论 #9379407 未加载
评论 #9379296 未加载
TsukasaUjiieabout 10 years ago
&quot;For another, conventional wisdom holds that reference counting and &quot;pure garbage collection&quot; (his term for mark and sweep) are roughly equivalent performance-wise, but the performance impact wouldn&#x27;t be known until after the change was made, which might make it a hard sell.&quot;<p>AFAIK there exists RC GC&#x27;s which are performance equivalent to MarkSweep, but these aren&#x27;t super common out of academia? What is the state of GC performance in python currently?
nnessabout 10 years ago
Python should institute &quot;migration&quot; notices on all of the 2.x documentation, making it clear that the intent of the community should be to move to Python 3. I know they plan to support Python 2 for a while longer, but no reason they can&#x27;t make the statement that everyone should be using the latest versions available.
belornabout 10 years ago
I noticed a while back that what really made me want to use python 3 is new features. Several script I use currently has a bunch of try-except that looks for functionality, and then monkey patch some python 3 feature into python 2. This will only get worse until library support allows me to switch.
k_bxabout 10 years ago
I think that Python3 should had got only single big braking change, like unicode story, for example. Then python4 could get rid of print statement etc., one breaking change at a time, with a tempo suitable to overall migration.
andrewstuartabout 10 years ago
These articles that assert low take up of Python never quantify in any scientific way why they think there is low take up of Python 3.<p>It&#x27;s opinion presented as fact that Python 3 has low take up.<p>Without tangible proof I call bullshit.
pc2g4dabout 10 years ago
Quick impression from the article: CPython holds back the larger Python language from its potential. Maybe?
mark_szabout 10 years ago
I would like to learn Python to use it for web apps - what version would you recommend now to begin with?
评论 #9379495 未加载
mpdehaan2about 10 years ago
The Python 2&#x2F;3 problem has created a decision point.<p>Namely, Python3 is sufficiently different for applications supporting distributions.<p>If you are doing Software-as-a-Service hosted webapps, fine, you can choose your platform, but if you are shipping software, you have to make concious choices about usually supporting what the distros have.<p>And the Linux distros are inconsistent.<p>This problem sounds solveable by saying &quot;users, install a newer Python&quot;, though this seldom is effective -- and long lifetimes of things such as RHEL 5 (yes, still afield - and some folks have to support version 2) ship versions that are less compatible with Python 3 compatible hacks than newer Pythons.<p>As a result, this intent to &quot;clean things up&quot;, I feel, has massively undercut Python&#x27;s growth rate. Maybe it&#x27;s not declining, but there&#x27;s been what feels to be an inflection point.<p>I suppose looking at download curves for hundreds of long-standing PyPi projects relative to the growth rates of other systems could provide this is a thing or not.<p>Anyway, I do love Python. The problem is not the GIL. Most folks who are making web services get by far with a pre-forking webserver (mod_wsgi, etc) and something like celery for backend jobs. multiprocessing is ok enough for some other cases.<p>It doesn&#x27;t matter whether Python 3 is attractive so much, and that&#x27;s what I mean about a decision point - the confusion gave people a chance to shop around, and some people are trying things in other languages now.<p>For instance, Go seems misapplied - it has a different expressiveness and domain area. I&#x27;m writing a fair amount of clojure, which also feels a bit more low level (sometimes, just in places). But I felt compelled to look around.<p>The crux of the theory is this - changing something singificantly will allow people the opportunity to think is this something they still want to do.<p>I still believe Python strikes a great balance between expressiveness and readability, and it&#x27;s surpression of &quot;clever&quot; in programming makes it ideal for a lot of problem domains. And it&#x27;s kind of old enough that people are going to want to look around.<p>Still, I begin to feel some of the directions being made in 3 are out of touch, just as the resistance to some more expressive language features (crippled lambdas, I vaguely recall) were that way. This happens when those that write the language don&#x27;t neccessarily use the language, and the (percieved) BFDL approach of &quot;fixing regrets&quot; I am not sure it looks after the good of the whole, the way the 2-&gt;3 transition happened. Those should have been evolved slowly, keeping things compatible, rather than creating what is essentially a new language.<p>I&#x27;m still pleasantly surprised by how widely deployed Python is to the rate at which people talk about it (say, vs Rails), I think a lot of that is because it&#x27;s <i>NOT</i> complicated, and you don&#x27;t need to talk about it so much. It&#x27;s a quiet workhorse.<p>But I&#x27;ve also started new projects in Python 2 - because I&#x27;ve needed them to work everywhere. Python 3 is almost sort of having the Perl 6 stigma to it in my mind, it&#x27;s available now, but it&#x27;s made a compatible break that has shaken trust.<p>Since Python 2 is essentially the deployed standard, there&#x27;s no real reason for most apps that must be distro installable to work on hybrid support - until the distros move to a version that makes it easier to be compatible, it&#x27;s more important to support where the users are than risk possible bugs and implementation trouble. Resources are better spent elsewhere.