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

341–350 of 358 posts

Re: About Python 3

#341

Post by tungwaiyip »

maxerickson wrote: post #310
tungwaiyip wrote: post #309

Earlier quoted context omitted.

Keyme, you and I are the few that have serious concern with the design of Python 3. I started to embrace it in a big way 6 months ago when most libraries I use are available in Python. I wish to say the wait is over and we should all move to Python 3 then everything will be great. Instead I find no compelling advantage. Maybe there will be when I start to use unicode string more. Instead I'm really annoyed by the def…

>>> bytes(list(b'abc')) b'abc' >>> That is, the way to turn a list of ints into a byte string is to pass it to the bytes object. (This narrowly addresses that concern, I'd readily concede that the new API is going to have situations where it is worse)

Thank you. This is good to know. I was rather frustrated to find binary data handling being changed with no easy translation in Python 3.

Here is another annoyance:

    In [207]: 'abc'[0] + 'def'
    Out[207]: 'adef'

    In [208]: b'abc'[0] + b'def'
    ---------------------------------------------------------------------------
    TypeError                                 Traceback (most recent call last)
     in ()
    ----> 1 b'abc'[0] + b'def'

    TypeError: unsupported operand type(s) for +: 'int' and 'bytes'

Re: About Python 3

#342

Post by tungwaiyip »

agentultra wrote: post #321
keyme wrote: post #311

Earlier quoted context omitted.

Yes! Thank you. All the other commenters here that are explaining things like using a list() in order to print out an iterator are missing the point entirely. The issue is "discomfort". Of course you can write code that makes everything work again. This isn't the issue. It's just not "comfortable". This is a major step backwards in a language that is used 50% of the time in an interactive shell (well, at least for so…

The converse problem is having to write iterator versions of map, filter, and other eagerly-evaluated builtins. You can't just write: >>> t = iter(map(lambda x: x * x, xs)) Because the map() call is eagerly evaluated. It's much easier to exhaust an iterator in the list constructor and leads to a consistent iteration API throughout the language. If that makes your life hard then I feel sorry for you, son. I've got 99…

What you are looking for is imap(). In Python 2 there are entire collection of iterator variants. You can choose to use either the list or the iterator variants.

The problem with Python 3 is the list version is removed. You are forced to use iterator all the time. Things become inconvenient and ugly as a result. Bugs are regularly introduced because I forget to apply list().

  >>> "".join(map(lambda byte: chr(byte), b'abc'))
Compares to ''.join('abc'), this is what I call fuck'd. Luckily maxerickson suggested a better method.

Re: About Python 3

#343

Post by SwellJoe »

yxhuvud wrote: post #328
SwellJoe wrote: post #313

Earlier quoted context omitted.

I still think you don't understand. RHEL (and thus CentOS) backports security fixes. An Apache package downloaded today from the CentOS 5 repository will have the security fixes, and many stability related bugfixes, that the latest tarball from apache.org would have, while still being an old version of Apache (and having the same configuration file syntax and working with whatever code you've deployed and tested on t…

And I think you didn't understand my point. Sometimes these security fixes will not be compatible with the application you are running. It will usually not be an issue if every single line of code you run is from the distro manager, but I've had CentOS security fixes breaking my apps because the security fix forced some other way of doing things, and because they didn't bother backport the subsequent bug fixes to the…

Certainly, software is complicated, and we're always managing risk and complexity when choosing our tools.

The reality is that CentOS is a more stable platform than most of the alternatives. It doesn't provide cutting edge software across the board (though it is possible to get newer versions of common tools that people want to stay on top of, like languages), but it does provide a reasonable level of confidence that what you deployed years ago will continue to run today. Moreso than any other Linux distro out there (in my, not at all limited[1], experience), most likely. And, the security concerns you raised are the ones I wanted to address in my original reply to you; you alleged that CentOS/RHEL provided old and thus insecure software. I wanted to make it clear that's not the case; all software is subject to bugs, including security bugs, but CentOS/RHEL are not shipping software with known exploits. It gets fixed, along with the upstream. In fact, the RHEL developers are often providing the upstream fixes, as well; Red Hat employs huge swaths of FOSS developers...really good ones.

1-I work on systems management software that is installed a million times a year, on every Linux distro and nearly every UNIX variant, and have done so for ~15 years. I don't know everything, but I know which Linux distros provide a stable platform and which ones have a good security record.

Re: About Python 3

#344

Post by gpvos »

lmm wrote: post #299
gpvos wrote: post #61

Earlier quoted context omitted.

Nobody expects Perl 6 to be widely used yet. The Python community seems to expect Python 3 to be widely used by now.

Bullshit. I was there in 2002 looking at Perl 6 and we expected it to replace Perl 5 within a couple of years.

You're right that back then the expectations were a lot higher, but I don't think anyone even then expected it to replace Perl 5 that fast.

Also, Perl 6 turned out rather quickly to become a new language (although very much in the spirit of earlier Perls), while Python 3 was, as far as I can see (I'm not really a Python person) as an update to fix some important issues in the language, which despite by necessity being backwards incompatible, was intended to still be the same language.

Re: About Python 3

#346

Post by steven_yue »

thatthatis wrote: post #156

I'm going to go against the grain here and say that moving slowly is one of my absolute favorite features about python and its libraries. Rails and django were released about the same time, rails is on version 4, django is on 1.6. Moving slowly means I can spend more of my time writing code and less of my time upgrading old code. More importantly, every release requires a perusal: did the API change, what's new, are…

Apparently you didn't use Rails, or at least on real project.

Re: About Python 3

#347

Post by maxerickson »

tungwaiyip wrote: post #341
maxerickson wrote: post #310

Earlier quoted context omitted.

>>> bytes(list(b'abc')) b'abc' >>> That is, the way to turn a list of ints into a byte string is to pass it to the bytes object. (This narrowly addresses that concern, I'd readily concede that the new API is going to have situations where it is worse)

Thank you. This is good to know. I was rather frustrated to find binary data handling being changed with no easy translation in Python 3. Here is another annoyance: In [207]: 'abc'[0] + 'def' Out[207]: 'adef' In [208]: b'abc'[0] + b'def' --------------------------------------------------------------------------- TypeError Traceback (most recent call last) in () ----> 1 b'abc'[0] + b'def' TypeError: unsupported operan…

I don't have enough experience with either version to debate the merits of the choice, but the way forward with python 3 is to think of bytes objects as more like special lists of ints, where if you want a slice (instead of a single element) you have to ask for it:

    >>> [1,2,3][0]
    1
    >>> [1,2,3][0:1]
    [1]
    >>> b'abc'[0]
    97
    >>> b'abc'[0:1]
    b'a'
    >>>
So the construction you want is just:

    >>> b'abc'[0:1]+b'def'
    b'adef'
Which is obviously worse if you are doing it a bunch of times, but it is at least coherent with the view that bytes are just collections of ints (and there are situations where indexing operations returning an int is going to be more useful).

Re: About Python 3

#348

Post by dded »

userbinator wrote: post #324
gizbot wrote: post #267

The arrogance burns. It burns. Python 3.0 was derailed by arrogance that developers should commit to a one-way transition that would touch every function rather than accept that, in Python 3.0, 'x = u"Hello"' should have been a valid statement. It didn't help that it ran slower, added nothing, and broke tools. Python 3.3 was the first release that had a prayer, but there are mistakes everywhere. For example, virtuale…

I would love to see Python seriously consider dropping case and underscore sensitivity in order to speed up developers How? By making it harder to find all occurrences of an identifier? Case sensitivity is debatable since editors have the option to ignore case during searches, but ignoring underscores isn't something any text editor I've seen has as a default search feature.

And in my world, underscore is more common as a word separator than mixed case. That is, people use 'foo_bar' instead of 'FooBar' or 'fooBar'. (This is more often true in C or Verilog than Python, however.)

Re: About Python 3

#349

Post by chromatic »

gpvos wrote: post #344
lmm wrote: post #299

Earlier quoted context omitted.

Bullshit. I was there in 2002 looking at Perl 6 and we expected it to replace Perl 5 within a couple of years.

You're right that back then the expectations were a lot higher, but I don't think anyone even then expected it to replace Perl 5 that fast. Also, Perl 6 turned out rather quickly to become a new language (although very much in the spirit of earlier Perls), while Python 3 was, as far as I can see (I'm not really a Python person) as an update to fix some important issues in the language, which despite by necessity bein…

You're right that back then the expectations were a lot higher, but I don't think anyone even then expected it to replace Perl 5 that fast.

The goal was to run existing Perl code in the same process, so that you could gradually adopt new features or use existing libraries with new code. If that had worked out, there'd have been less of the Python 2/3 gap.

Then again, the idea that Perl and P6 are different languages is something that's come up after the fact, after it became obvious that P6 wouldn't be ready for general use any time soon.

Re: About Python 3

#350

Post by [deleted] »

gpvos wrote: post #344
lmm wrote: post #299

Earlier quoted context omitted.

Bullshit. I was there in 2002 looking at Perl 6 and we expected it to replace Perl 5 within a couple of years.

You're right that back then the expectations were a lot higher, but I don't think anyone even then expected it to replace Perl 5 that fast. Also, Perl 6 turned out rather quickly to become a new language (although very much in the spirit of earlier Perls), while Python 3 was, as far as I can see (I'm not really a Python person) as an update to fix some important issues in the language, which despite by necessity bein…

[deleted]
Post reply on HN