Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

About Python 3

alexgaynor.net

Post reply on HN
Print view View original

281–290 of 358 posts

Re: About Python 3

#281

Post by rmc »

pjmlp wrote: post #192
xradionut wrote: post #185

Earlier quoted context omitted.

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.

Microsoft are a massive tech company though.

Re: About Python 3

#282

Post by exDM69 »

koshak wrote: post #278

about python 3: $ python Python 3.3.3 (default, Nov 26 2013, 13:33:18) [GCC 4.8.2] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import timeit >>> timeit.repeat('for i in range(100): i**2', repeat=3, number=100000) [4.451958370991633, 4.446133581004688, 4.4439384159923065] >>> timeit.repeat('for i in range(100): pow(i,2)', repeat=3, number=100000) [5.343420933000743, 5.3414130810…

Your benchmark results could use a little explanation.

I notice that all your examples involve using the range() function, which was changed from returning a list to a generator. In Python2 the memory usage is O(n) where as in Python3 it is O(1), albeit a little slower.

The first two cases being compared are 3-4x slower in Python 3 but why? Is it related to Integer->Float conversion? What has changed from Python 2 to 3 here?

The difference in the rest of the examples is not huge.

In my opinion, changing range, zip, map, etc to be "lazy", ie. return generators not lists, is one of the best things that happened in Python 3. What you lose in speed will be gained back in memory use.

These toy example micro benchmarks don't really prove anything, it's not like the cost of iterating a range of integers would ever be a bottle neck in a practical application. However, the advantage of O(1) vs. O(n) memory usage is a major benefit and will make zip, map and other related functions a lot more useful, especially for large lists.

Re: About Python 3

#283

Post by dded »

Sami_Lehtinen wrote: post #255
cies wrote: 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 clearly aren't running extensive production systems with little administrative resources. Code is written 15 years ago, and it's still running. Any changes that break something are major headache, usually leading rolling things back to working version. Nobody knows or cares to fix those things to achieve compatibility with new version. This leads to situation where nothing at all is ever updated. And even known b…

> But when I'm writing new code, I'm of course using Python 3.

There's no "of course" about it, which is the point of the article. It is interesting that you're using Python3. It means that you're not blocked by library availability (public or company-internal). It means that you are permitted by management to use it. It probably means that you prefer it.

My situation is different on the last two points, but I am also not blocked by library availability.

Re: About Python 3

#284

Post by dded »

gkya wrote: post #271
keyme wrote: post #147

Earlier quoted context omitted.

I don't like Python 3. Iterators everywhere are incredibly annoying, especially with my development workflow, where I don't put a line of code into a file before I run it manually in the interpreter. When I run a map over a list, I just want to see the freaking results. Default unicode strings are obscenely annoying to me. Almost all of my code deals with binary data, parsing complex data structures, etc. The only "h…

> Why the hell should I worry about text encoding before sending a string into a TCP socket... A string represents a snippet of human readable text and is not merely an array of bytes in a sane world. Thus is it fine & sane to have to encode a string before sticking it into a socket, as sockets are used to transfer bytes from point a to b, not text.

Not arguing that you're wrong, but Unix/Linux is not a sane world by your definition. Whether we like it or not (I do like it), this is the world many of us live in. Python3 adds a burden in this world where none existed in Python2. In exchange, there is good Unicode support, but not everyone uses that. I can't help but wonder if good Unicode support could have been added in a way that preserved Python2 convenience with Unix strings.

(Please note that I'm not making any statement as to what's appropriate to send down a TCP socket.)

Re: About Python 3

#285

Post by sixbrx »

PopsiclePete wrote: post #223
falcolas wrote: post #82

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…

Linux is the new Windows XP. "We can't install that web app, we are standardized on IE6 and WinXP until 2035 or the Second Coming, whichever comes first".

Make that just "the new Windows" and I'd agree. There's plenty of standardizing on "Server 2003" and other Windows versions, that didn't stop with XP.

Or, in other words, both platforms have firms that like to standardize on particular versions for stability. Which isn't really much of an attribute of Windows or Linux themselves, really.

Re: About Python 3

#286

Post by dded »

donaldstufft wrote: post #232
saurik wrote: post #227

Earlier quoted context omitted.

So, I'm going to agree with your first comment: today things are much better than normal, and I apparently skimmed the top-level comments too quickly and didn't give them enough credit. I've taken the parts of what I said that I believe you are correct for pointing out "are in error", modified them, and will go so far as to apologize for not giving today's thread enough consideration. > I obviously can't speak for an…

Realistically there is a value to porting to Python 3, in a year and some months Python2 will no longer be receiving security updates from Python Core. This will get taken care of by third parties for awhile but I fully suspect this support to be incomplete and eventually relegated only to RHEL.

> in a year and some months Python2 will no longer be receiving security updates from Python Core

Is this an official statement? A few minutes with Google produced a number of articles that claimed five (or sometimes six) years of support for 2.7 starting in 2010, but I couldn't find a clear statement on python.org.

Re: About Python 3

#287

Post by pixelmonkey »

Is there a tool that will take a requirements.txt file and let you know whether all the packages in that file are already Python 3 compatible (by looking up corresponding packages on PyPI)?

If not, that tool seems worth writing, and then we can do a poll of some major production codebases and see whether Python 3 support is actually missing.

As for "Python 2.8": meh. I think we should just support the development of tulip / asyncio in Python 3.4 (see docs, this is looking awesome already: http://docs.python.org/3.4/library/asyncio.html), then use our blog platforms as Pythonistas to promote all the new async programming you can do using asyncio + Futures + yield from, port over important async frameworks like Tornado/Twisted, etc.

In that case, Python 3.4 becomes the Python release that gives you all the power / convenience of Python 2.x with a complete cleanup of callback spaghetti code as demonstrated in the "hello, world" co-routine example: http://docs.python.org/3.4/library/asyncio-task.html#example... -- I think async programming is mainstream enough, especially in web/mobile/API applications, that this will be a compelling draw for people.

I think the only thing GvR and crew got wrong is the timing -- it probably won't take 5 years from release for everyone to migrate to Python 3, but it will take more like 8-10. But it'll happen.

Re: About Python 3

#289

Post by hyp0 »

userbinator wrote: post #249
_delirium wrote: post #238

Earlier quoted context omitted.

Differences in userbases could be part of it. Scientific computing is an increasingly important part of the Python community, for example, and they tend to be averse to backwards-incompatible changes. In part that's because you have many good but very lightly maintained libraries that stick around forever, so people prefer if they stay working when nobody touches them, rather than bitrotting and needing constant upda…

It seems that communities that mainly use programming languages for reasons of "getting stuff done" value backwards compatibility the most; they are the ones who would rather not have to spend the time "upgrading" things that used to work perfectly fine, and would rather use that time to do something more useful and related to their ultimate goals. Personally I think backwards compatibility is getting less attention…

Similar to Innovators/Visionaries vs Pragmatists (http://www.chasminstitute.com/METHODOLOGY/TechnologyAdoption...)

Re: About Python 3

#290

Post by hyp0 » 

  [Python 3 releases live in parallel to Python 2] In retrospect this was a mistake,
  it resulted in a complete lack of urgency for the community to move
Adoption comes from solving urgent problems - not from creating them.
Post reply on HN