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

331–340 of 358 posts

Re: About Python 3

#331

Post by ekimekim »

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.

Not to mention common idioms like x.y vs x._y where one is a property and the other the actual member.

Re: About Python 3

#332

Post by gkya »

dded wrote: post #319
gkya wrote: post #316

Earlier quoted context omitted.

> I was careful to say "Unix strings" This is the first time I encounter the idiom Unix strings . I'll map it to array of bytes in my table of idioms. > I don't think a programming language can take the position that an OS needs to "adopt better encodings". I do think that programming languages should take a position on things, including but not limited to how data is represented and interpreted in itself. A language…

> This is the first time I encounter the idiom Unix strings The usual idiom is C-strings, but I wanted to emphasize the OS, not the language C. >> [...] probably a vain hope that Unix strings will vanish [...] >If only we wait for them to vanish, doing nothing to improve. The article is about the lack of Python3 adoption. In my case, Python3's poor handling of Unix/C strings is friction. It sounds like you believe th…

I do not insist that C strings must die, I insist that C strings are indeed arrays of bytes, and we cannot use them to represent text correctly at present. I fully support strings to be Unicode-by-default in Python, as most people will put text in between double quotes, not a bunch of bytes represented by textual characters.

I do not expect C or Unix interpretations of strings to change, but I believe that they must be considered low-level and require higher-level language user to explicitly request the compiler to interpret a piece of data in such fashion.

My first name is "Göktuğ". Honestly, which one of the following is rather desirable for me, do you think?

  Python 2.7.4 (default, Sep 26 2013, 03:20:26) 
  >>> "Göktuğ"
  'G\xc3\xb6ktu\xc4\x9f'
or

  Python 3.3.1 (default, Sep 25 2013, 19:29:01) 
  >>> "Göktuğ"
  'Göktuğ'

Re: About Python 3

#333

Post by wiremine »

dded wrote: post #100
wiremine wrote: post #53

Python 3 is a different language from Python 2. Yes, they are _almost_ the same language, but they are far enough apart to keep people from making the switch. It feels closer to Perl 5 => 6 vs. Ruby 1.x => Ruby 2.x. That's a gross over simplification, but it is closer to the truth than the Python 3 community likes to think. I wonder: have there ever been a successful language rewrite, post critical pass, in the histo…

> have there ever been a successful language rewrite, post critical pass, in the history of computer languages? Does K&R C to C89 count? > If so, what lessons can be brought to the current Python 2/3 situation? C89 programs could use K&R libraries [1], and C89 compilers could compile K&R code. [1] Well, so could Pascal or Fortran programs for that matter. Where K&R-->C89 fails as an analogy to py2-->py3 may be import…

> C89 programs could use K&R libraries

That's probably the key. If I could use Py2 libraries as-is in Py3, moving to Py3 would be a minor issue.

Re: About Python 3

#334

Post by Flimm »

dded wrote: post #116
anilshanbhag wrote: post #9

Python3 is not exciting because well there is nothing to be excited about. Consider me an average programmer, I have been using python for a year+ now. Most of the everyday stuff can be done in 2.7, some functionality I need / can't do I google and get a solution which works in 2.7. Why Py3 is not adopted is because there is not much benefit you get for doing the extra work (think chemistry - activation energy) On an…

> Python3 is not exciting because well there is nothing to be excited about. I think this depends on whether or not you use, or will ever need to use, Unicode. I don't, and so Python3 is not only not exciting, but it creates a new problem for me: suddenly, I need to think about the difference between bytes and strings. Now maybe this is healthy for me, maybe it builds character. But it also adds effort and work that…

Separating byte strings from Unicode strings is as close to solving the Unicode problem without thinking about it as you'll get.

Re: About Python 3

#335

Post by dded »

gkya wrote: post #332
dded wrote: post #319

Earlier quoted context omitted.

> This is the first time I encounter the idiom Unix strings The usual idiom is C-strings, but I wanted to emphasize the OS, not the language C. >> [...] probably a vain hope that Unix strings will vanish [...] >If only we wait for them to vanish, doing nothing to improve. The article is about the lack of Python3 adoption. In my case, Python3's poor handling of Unix/C strings is friction. It sounds like you believe th…

I do not insist that C strings must die, I insist that C strings are indeed arrays of bytes, and we cannot use them to represent text correctly at present. I fully support strings to be Unicode-by-default in Python, as most people will put text in between double quotes, not a bunch of bytes represented by textual characters. I do not expect C or Unix interpretations of strings to change, but I believe that they must…

I'm not arguing against you. I just don't write any code that has to deal with people's names, so that's just not a problem that I face. I fully acknowledge that lack of Unicode is a big problem of Python2, but it's not my problem.

A Unix filename, on the other hand, might be any sort of C string. This sort of thing is all over Unix, not just filenames. (When I first ever installed Python3 at work back when 3.0 (3.1?) came out, one of the self tests failed when it tried to read an unkosher string in our /etc/passwd file.) When I code with Python2, or Perl, or C, or Emacs Lisp, I don't need to worry about these C strings. They just work.

My inquiry, somewhere up this thread, is whether or not it would be possible to solve both problems. (Perhaps by defaulting to utf-8 instead of ASCII. I don't know, I'm not a language designer.)

Re: About Python 3

#336

Post by dded »

gkya wrote: post #332
dded wrote: post #319

Earlier quoted context omitted.

> This is the first time I encounter the idiom Unix strings The usual idiom is C-strings, but I wanted to emphasize the OS, not the language C. >> [...] probably a vain hope that Unix strings will vanish [...] >If only we wait for them to vanish, doing nothing to improve. The article is about the lack of Python3 adoption. In my case, Python3's poor handling of Unix/C strings is friction. It sounds like you believe th…

I do not insist that C strings must die, I insist that C strings are indeed arrays of bytes, and we cannot use them to represent text correctly at present. I fully support strings to be Unicode-by-default in Python, as most people will put text in between double quotes, not a bunch of bytes represented by textual characters. I do not expect C or Unix interpretations of strings to change, but I believe that they must…

> I insist that C strings are indeed arrays of bytes, and we cannot use them to represent text correctly at present

OK, maybe I do see one small point to argue. A C string, such as one that might be used in Unix, is not necessarily text. But text, represented as utf-8, is a C string.

It seems like there's something to leverage here, at least for those points at which Python3 interacts with the OS.

Re: About Python 3

#337

Post by pmelendez »

xradionut wrote: post #185
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 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!

>"Here's a free version that can't do shit"

Depends what you are doing. I worked in a multinational mobile game studio and developers were using Visual C++ express, which was actually pretty capable for what we were doing.

Re: About Python 3

#338

Post by dded »

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…

  >    >>> list(b'abc')
  >    [97, 98, 99]
  >That's not a list of numbers... that's a list of bytes!
No, it's a list of numbers:

  >>> type(list(b'abc')[0])
I think the GP mis-typed his last example. First, he showed that ''.join('abc') takes a string, busts it up, then concatenates it back to a string. Then, with ''.join(b'abc'), he appears to want to bust up a byte string and concatenate it back to a text string. But I suspect he meant to type this:

  >>> b''.join(b'abc')
That is, bust up a byte string and concatenate back to what you start with: a byte string. But that doesn't work, when you bust up a byte string you get a list of ints; and you cannot concatenate them back to a byte string (at least not elegantly).

Re: About Python 3

#339

Post by dded »

Too wrote: post #193
captainmuon wrote: post #182

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…

> Everybody who disses python 3 does it for library support, library support and library support

I like to think I'm somebody, I diss Python3, but I don't diss it for library support (which is good enough for me). The trouble for me, and at least a few others, is that Python3 has replaced C strings with byte strings and Unicode strings and uses the later where Unix expects and provides the former.

If byte strings were actually used instead, there would likely be other issues. Near as I can tell from this discussion, those who have actually tried to use byte strings in Python3 have found they don't work well.

Re: About Python 3

#340

Post by dded »

Flimm wrote: post #334
dded wrote: post #116

Earlier quoted context omitted.

> Python3 is not exciting because well there is nothing to be excited about. I think this depends on whether or not you use, or will ever need to use, Unicode. I don't, and so Python3 is not only not exciting, but it creates a new problem for me: suddenly, I need to think about the difference between bytes and strings. Now maybe this is healthy for me, maybe it builds character. But it also adds effort and work that…

Separating byte strings from Unicode strings is as close to solving the Unicode problem without thinking about it as you'll get.

Perhaps you misread my intended meaning, or I didn't state my position well. I don't have a Unicode problem. There is one (suppose HN forum software were written in Python2, for example). Python3's approach to solving an important problem that I don't have makes solving problems that I do have awkward. So I stick with Python2. I have to believe that there are people with both problems.
Post reply on HN