Live data from Hacker News

About Python 3

alexgaynor.net

191–200 of 358 posts

Re: About Python 3

#191
Fix the GIL.

Python 3 isn't getting used because it breaks backwards compatibility without offering many meaningful benefits. Sure, the syntax clean ups and the new sugar are nice and all. But you don't rewrite a working code base because of "nice".

So, fix the GIL; Replace the spaces indentations with tabs; Take out the stupid 79 line limit off PEP8; Even clean up the standard library... After all, if you don't need to worry about backwards compatibility, then you might as well re-do it all properly.

Re: About Python 3

#192
post #166

Earlier quoted context omitted.

i like fast movement, i like communities that dare to break things every now and then (see semver.org for the widely accepted versioning rules and should be honoured). much do i prefer an increasingly better solution to a stable one. i'm not agueing "perfect" over "good enough"; i'm argueing "awesome" over "good enough" :)

You might be a great Microsoft developer. Use this API, no this one, nope now this one, you almost caught up, so we released a newer, more better one! Please buy Awesome Studio and RDMS 2015 or you are a loser. Here's a free version that can't do shit, the Pro version is only $2000, plus lots of your time adjusting to a newer mono/flat chrome development environment. Hot keys only for touch screen users!

I can give such examples for any commercial vendor and in terms of breaking compatibility, there are a few examples in FOSS land as well.

Re: About Python 3

#193

Python fell into the Winamp trap. If anyone remembers, version 3 was pretty much crap, and many users stayed with 2.95 for ages. Now, I'm not saying Python 3 was bad, not at all, but the benefits don't outweigh the cost of switching for many people. Here's my idea. Make a new "Python 5" (2+3=5, or call it whatever you want), based on Python 3. Put back everything that was deprecated or removed along the way, includin…

Your idea is good but i think it has to be taken one step further. You should be able to import ANY module, third party or not, and specify under which version to run it. What we need is interop between python 2 and 3.

Just look at this thread. Everybody who disses python 3 does it for library support, library support and library support. If you could write your own code in python 3 but still use libraries remaining on 2.7 most people would switch in a heartbeat. After that it's just a matter of time before the libraries transition to 3. Now we are stuck in a chicken and egg situation where nobody wants to make a move.

Re: About Python 3

#194
post #75
post #23

I like to think of engineering as "solving problems within a system of constraints". In the physical world, engineering constraints are things like the amount of load a beam will bear. One of the primary easily-overlooked constraints in the software world is backwards compatibility or migration paths. There are many examples of systems where many look at them today and say: "This is terrible, I could design a better/…

Exactly. This is why something like Java 8 is admirable. They've been able to introduce two major new features from newer "productive" languages – lambdas and traits – without breaking anything; not only that, old libraries will actually enjoy better APIs thanks to the new features without recompilation. Sure, there might be better ways to implement these features, but introducing them in a way that feels natural to…

Same with C#. That language has really exploded with new features, and still code and precompiled libraries written for 1.2 compiles and runs perfectly on 5.0.

Re: About Python 3

#195

Earlier quoted context omitted.

Matz has also said no breaking changes until ruby 3.0, which is 'ten years away.' I don't expect this to actually be true, but it speaks to an attitude.

I've seen breaking changes between Ruby 1.8.6 and 1.8.7, so I'm really suspicious of this claim. Start with which version of Ruby are breaking changes not to be expected until 3.0?

From 2.0 -> 3.0.

Ruby doesn't follow SemVer, so expecting no breaking changes between 1.8.6 and 1.8.7 wouldn't necessarily be correct. I don't remember what the policy was at the time.

Re: About Python 3

#196
post #121
post #76

Earlier quoted context omitted.

Just out of curiosity, have you actually tried getting NumPy/SciPy working on Python 3? Because they've been fully supported for quite a while now. I don't understand how this myth keep perpetuating itself.

I'm not interested in even playing any more. Like I said, I haven't used Python 3 before today (after 18 years of programming Python). I would have cared, for example if Python 3 had any impact in the real world. Anyway, it took years for numpy support; it wasn't available until recently for python3. That's the problem: it took years before these common tools were proted.

> Anyway, it took years for numpy support;

Python 3.0 release date: December 3rd, 2008. Numpy 1.5 (Full 3.0 support) release date: August 31st 2010.

It took 21 months.

Re: About Python 3

#197

As a development lead, we recently abandoned our plans to migrate to Python 3. Here's a short summary of why: To begin the migration, we needed to move from Python 2.6 (which is the default on our CentOS6 production boxes) to Python 2.7. This transition is actually rather hard. We can't use the packages provided in CentOS base or EPEL, because they are all complied against Python 2.6. To re-produce all of our package…

Can you elaborate why you need to use a version shipped with the distro instead of simply using virtualenv+pip to install all third party dependencies?

Re: About Python 3

#198
I think it's just starting to roll. Only a month ago I argued in my company's mailing list, that now is the time to finally start moving to Py3. Py3 is more stable now, most of the big libraries have finally moved. In a commercial set up it is just stupid to move forward, when the ecosystem hasn't. But now it has, so now we start. I think people should just continue to improve in that direction. Maybe it will take 10 years, not 5. But it's definitely going in the direction of Py3.

Re: About Python 3

#199
post #6

I used Python 3 for the first time a few days ago (I've been programming in Python for 18 years). When I used python heavily (I've switched back to C++ and now Go) I depended a lot on a small number of really good libraries- ElementTree, NumPy, SciPy, etc. Unless/until all of those get ported to Python 3 (along with hundreds of other programs), and those ports are considered Correct (in the QA validation sense), it's…

I don't regard the lack of practical multithreading as a problem. We routinely use multiprocessing and IPC via queues for parallelism, and for me the main limitation is Python's excessive memory use: even atomic data types are objects which cause quite a bit of overhead (a memory efficient dictionary with support for a few basic data types would be great). Thankfully everything still fits in the server's memory, othe…

See the recent post on __slots__ .

Re: About Python 3

#200
post #86
post #62

Earlier quoted context omitted.

Mags have a significant presence in enterprise these days.

Yes, Macs have a decent presence in enterprises these days--although it's easy to overstate it; Mac overall market share is still pretty low. Somewhere in the 10% percent range I believe. Furthermore. and to the original point, a lot of those Macs are BYOD or otherwise not managed as a corporate desktop/laptop. (Where I work is a case in point. You see a fair number of Macs but IT doesn't formally support them.)

My last two jobs were at fortune 100 companies, and both had IT supported macs and a lot of them. A work with a lot of people from other large enterprises and the same is true. This is anecdotal, but more evidence than the guy claiming they don't have a presence
Post reply on HN