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

271–280 of 358 posts

Re: About Python 3

#271

Post by gkya »

keyme wrote: post #147
agentultra wrote: post #39

I like Python 3. I prefer it. It is better to program in than 2.x. Iterators everywhere, no more unicode/encoding vagueness, sub-generators and more. It is a much better language and it's hard to see how it could have evolved without a clean break from its roots. However it has been interesting to follow over the last five years. It has been a sort of, "what if p5 broke the CPAN," scenario played out in real-life. Br…

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.

Re: About Python 3

#272

Post by coldtea »

kamaal wrote: post #264
coldtea wrote: post #260

Earlier quoted context omitted.

Rust appeared publicly as a project to build a language in 2010 (it was a personal, private, project kept under wraps by Graydon a few years before which is irrelevant). Perl 6 was first started on 2000. I've been reading Larry's apocryphal descriptions of its "features to be" for 4 times more years than Rust exists. Rakudo is just a particular attempt at Perl 6, not the first and neither it consists of first time th…

I remember Larry also saying(On a youtube video, may be at the O'reilly conference) that he has been working on Perl 6 since 1987. That's how he wishes to describe it. Even beyond that those are not "features to be". They are already available for use - http://perl6.org/compilers/features Therefore I'm not sure what you've been reading, or if you are even reading them. Because if you would- you would know, Rakudo cov…

>I remember Larry also saying(On a youtube video, may be at the O'reilly conference) that he has been working on Perl 6 since 1987. That's how he wishes to describe it.

That's all well, but he announced it circa 2000. I don't care how he feels about it or how long he hacked it alone, I care since when the language was expected.

>Even beyond that those are not "features to be". They are already available for use http://perl6.org/compilers/features

Therefore I'm not sure what you've been reading, or if you are even reading them. Because if you would- you would know, Rakudo covers much of the Perl 6 specification.

In a half-arsed form and with 1/100 the community of Perl doing anything with them. And still not all of them.

Personally I stopped caring somewhere around 2006. And I've read all of Larry's "apocalypses" back when they used to be on Oreillynet, as well as followed the internal implementation politics for a few years.

>By the way. Rust is still not complete. The wikipedia article says, work started in 2006- Which makes it 8 years and still incomplete.

No, it says that it started as a "part-time side project in 2006". That could be 2 weeks total spend in those years writing a list of desired features in a napkin and getting a hello world compiled for all I know.

I only care about the time since the project was publicly announced and the community started working on it.

Re: About Python 3

#273

Post by baq »

keyme wrote: post #215
baq wrote: post #159

Earlier quoted context omitted.

this post is a great example of why python 3 didn't go far enough. it's too close to python 2 to be still called python and too far from python 2 to be still called python 2. personally, coming from a country that needs to deal with non-ascii, i love unicode by default and there are b'' strings if you need them. str.encode is a non-issue - you wasted more words on it than the two-line function enc() it takes to fix i…

If I recall, writing no boilerplate code was a big deal in python once... And while 2 lines are not worth my rant, writing those 2 lines again and again all the time, is.

i'd argue this is not boilerplate, more like a shortcut for your particular use case:

    import codecs
    enc = lambda x: codecs.encode(x, 'hex')
i have a program in python 2 that uses this approach, because i have a lot of decoding from utf and encoding to a different charset to do. python 3 is absolutely the same for me.

Re: About Python 3

#274

Post by codygman »

mburst wrote: post #202

As sad as it may sound, the most annoying thing about Python 3 for me is this: print "Hi" vs print("hi") Other than that, as Alex said there isn't much difference between the two.

Yeah, I personally find the first example makes code a lot cleaner.

Re: About Python 3

#275

Post by codygman »

revskill wrote: post #52

I wonder why Django doesn't have the same strength (both technically and community) as Rails ? I think the philosophy "Everything is an object" makes sense actually, and in combination with functional programming built-in really makes Ruby is perfect choice for non-professional programmer (even woman) to love coding.

I don't come to HN to see blatantly obvious sexism. I come to HN to avoid it. Please stop.

Re: About Python 3

#276

Post by Argorak »

_delirium wrote: post #238
Argorak wrote: post #177

Earlier quoted context omitted.

This is where the Ruby and Python communities fundamentally disagree. The Ruby community is great at moving fast and replacing bad things, while the Python community takes a much slower approach to the whole thing. I wouldn't say any approach is better or worse, it has to fit your personal style. I like the Ruby approach, others love the Python approach. This means that Ruby breeds a lot of interesting stuff, but wit…

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…

Differences in userbases are definitely part of it.e.g. Ruby is very often used in the whole devops space - where constant forward-change is usual, because of the mindset of "never being done".

Constant change is a thing that doesn't get enough mindshare as well. Not training your team at handling change is probably as bad as not having programmers care about backwards compatibility.

To be quite clear: I think it is very beautiful to have 2 languages in the same space, evolving into different community directions.

Re: About Python 3

#277

Post by nostrademons »

dekhn wrote: post #125
freyrs3 wrote: post #71

Earlier quoted context omitted.

A lot of people cite that lack of NumPy support is what's keeping them from moving to Python 3, I've seen this comment more times than I can count. It seems most of them haven't done their research and found that NumPy/SciPy has had complete support for Python 3 for 4 years now.

Please don;t interpret my comments above as ignorance. I am quite aware of what is available (and was available, when I considered switching to python3 ). I did my research at the time (which was some 5 years ago). It looks like scipy was added about 3-4 years ago... at which point I don't care any more.

If it was valid at the time but your concerns have since been addressed, then your complaints aren't exactly relevant to someone who's reading this now and looking for information on Python 3, right?

Re: About Python 3

#278

Post by koshak »

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.341413081012433, 5.3455389970040414]
  >>> timeit.repeat('for i in range(100): i*i', repeat=3, number=100000)
  [0.8348780410015024, 0.8323301089985762, 0.8313860019989079]

  $ python2
  Python 2.7.6 (default, Nov 26 2013, 12:52:49) 
  [GCC 4.8.2] on linux2
  Type "help", "copyright", "credits" or "license" for more information.
  >>> import timeit
  >>> timeit.repeat('for i in range(100): i**2', repeat=3, number=100000)
  [0.9710979461669922, 0.9630119800567627, 0.9619340896606445]
  >>> timeit.repeat('for i in range(100): pow(i,2)', repeat=3, number=100000)
  [1.7429649829864502, 1.7306430339813232, 1.729590892791748]
  >>> timeit.repeat('for i in range(100): i*i', repeat=3, number=100000)
  [0.6579899787902832, 0.6526930332183838, 0.6540830135345459] 

  $ python -m timeit '"-".join(str(n) for n in range(100))'; python -m timeit '"-".join([str(n) for n in range(100)])'; python -m timeit '"-".join(map(str, range(100)))'
  10000 loops, best of 3: 49.4 usec per loop
  10000 loops, best of 3: 40.6 usec per loop
  10000 loops, best of 3: 32.8 usec per loop

  $ python2 -m timeit '"-".join(str(n) for n in range(100))'; python2 -m timeit '"-".join([str(n) for n in range(100)])'; python2 -m timeit '"-".join(map(str, range(100)))' 
  10000 loops, best of 3: 30.2 usec per loop
  10000 loops, best of 3: 25 usec per loop
  10000 loops, best of 3: 19.4 usec per loop

  $ uname -rom
  3.12.6-1-ARCH x86_64 GNU/Linux

Re: About Python 3

#279

Post by saurik »

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.

Which is really just going to be read as another "fuck you" to the Python community, the vast majority of which is probably still going to be using Python 2...

Re: About Python 3

#280

Post by yxhuvud »

SwellJoe wrote: post #162
marcosdumay wrote: post #108

Earlier quoted context omitted.

Even Debian is using Pyhon 2.7 for a while already, looks like CentOS is being quite slow.

CentOS keeps the same major version of everything through the entire life of the OS; so, five years plus two more for vital security updates. This is by design, and a completely reasonable choice. Often, you can install additional packages that bring newer versions into the system, but they don't become the "default". So, for PHP in CentOS 5, there was a php53 package (and maybe later ones, too, I dunno), that instal…

It is a reasonable choice until the day when you get hacked because you use a prehistoric version of something that doesn't get security updates anymore.

Sure, sometimes that will get backported security fixes, but that is not always possible. Heck, sometimes the installation depends on said security hole.

Post reply on HN