dded

I came here to basically enter the same reply. Though I am perhaps not as bad as you make yourself sound.

It's easier to control myself these days, because I like buying books in book stores and those are disappearing. With the exception of certain titles that I really know I want and am searching for (which I buy on Amazon), almost all the books I buy now come from one used book store. It's the last book store within a half-hour drive from home, and there is no book store within a half-hour drive from work.

I thought about this, as someone with reasons to prefer Python2. But then I quit worrying. Python2 isn't going anywhere, for starters. But more to the point, if lots of people move to Python3, some of them will share my issues. They'll make noise, push for resolution, offer solutions, etc. Widespread adoption makes it more likely that my concerns will be addressed.

Many modern processors hash some of the address bits before using them as a cache index to avoid these problems.

To avoid them in code, it's often sufficient to round to convenient decimal numbers when allocating arrays, instead of powers-of-2. That is, allocate an array of 1000, instead of an array of 1024.

> This is unnecessarily pessimistic

Remember, he's looking at using Python for the first time. I work in Perl-heavy environments, and I can assure you that the 2/3 split in Python is a reason that many will give for not using Python at all. It's very different among those who are already comfortable with Python.

> Most of the major packages support Py3k and if they don't it's usually very simple to port over

For you, maybe. He's just starting with Python.

With regards to scientific Python, I took a peek at the install link on the Ipython site. It says that Ipython works with Python 2.6, 2.7, and >= 3.2. That was only mention I saw (in an admittedly casual look) for Python3. All the examples were in Python2.

A very smart move by Fossil--it makes it safe to try. There's a path out.

One of the reasons I chose GNU Emacs over XEmacs was a feeling that GNU Emacs will be maintained, even advanced, for as long as RMS has the strength to type. It's his baby.

(There were other reasons, the big one being momentum. XEmacs didn't run on the platform I was on for a long time, so it would have been a switch.)

I'm entirely ignorant of bzr, but I've got to say that this surprises me. We use svn, which certainly works well with patch.

> a compiled binary can often be a good choice

Uh, well, sure. From the context, I thought little ad hoc utilities were meant. The kind that are changed frequently. We keep many right in our svn repository, so you make a check-out and make use of a little script right in the same directory as your project source code.

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.)

There are over 300 replies in the discussion here (About Python 3): https://news.ycombinator.com/item?id=6985207 From what I've gleaned from that discussion, here are reasons why people aren't moving from Python2 to Python3. These are in no particular order, other than I repeat the two you mention first.

1. Lack of library support (as you indicated). I'll confess to not paying careful enough attention to know what specific libraries are desired.

2. Lack of a big enough carrot. I think this is what you mean when you mention the GIL. After all, Python2 also has the GIL, so its presence in Python3 is not a reason not to upgrade; but its absence might be a big enough motivation for some people to upgrade. Other wanted features that I recall include JIT compilation and tail call optimization; but I probably didn't pay enough attention to specifics here, either.

3. A claim that Python3 is inferior for interactive use. One complaint is that print is no longer a statement, but I can't help but wonder if some people don't realize that if a variable or expression is entered in the REPL it is automatically printed (the P in REPL). The prevalence of iterators over lists is also cited in this space.

4. Byte strings don't work well for those who need them. The Mercurial folks had something interesting to say about this, but others had complaints too. Sometimes little things don't work: one poster mentioned that byte strings can't be used as a key to a shelve object, element selection can't be combined with concatenation, etc.

5. The mismatch between Unicode strings in Python3 and C strings in Unix-like operating systems. This one is the one I care about and is thus the direct answer to your question.

6. What I might call petty complaints, but won't lest people call my complaints petty: lack of print statement (I don't get it, but it was very popular), true division, etc.

I suppose this is intended as a sports-themed The Onion. But I didn't find any of the articles funny.

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.

> 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.

  >    >>> 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])
  <class 'int'>

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).

> 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.

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.)

Here are my what-can-chromebooks-do questions:

1. What kind of VPN connectivity is there? Cisco? Sonicwall? PPP? Ipsec?

2. What kind of remote connection software runs? I believe ssh is available. How about VNC? How about NX?

I could make a Chromebook work if I could connect to work and run ssh in a terminal as well as a graphical VNC client.

The factor of five applies to commercial sales to businesses and schools and such. I suspect a large fraction of Macbooks (and all Apple products) are consumer sales.

I agree that the survey is poor, but it is not bunk.

It should have had more questions attempting to discover why those who don't adopt Python3 don't. Then, if a major problem turns out to be misinformation, it could be addressed with evangelism. If a problem is a shortcoming of Python3, that shortcoming could be addressed. Etc.

> 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 that Unix/C strings can be made to go away in the near future. I do not believe this. (I'm not even certain that it's a good idea.)

> Utilities seems like a good use of Go

Can you elaborate? I'm unfamiliar with Go, but most of my Python (and Perl, sigh) coding could be classified as "utilities for work". I would have thought that any language with an explicit compile step would be at a disadvantage in this space.

Reminds me of the scene from the Tom Hanks movie The Wonders where the band is originally cute with the spelling, Oneders, and an emcee introduces them as the Oh-Nee-Ders.

For the opposite effect, does anyone else find themselves pronouncing gnu (the animal) with a hard G, a la GNU?

I don't have Python3 handy, but in Python2 I do this:

  >>> answer = 1 + 1
  >>> answer
  2

Doesn't Python3 work the same way?

In any case, my PYTHONSTARTUP has this line:

  from pprint import pprint as pp

and I find pp() very nice for printing various structures.

I was careful to say "Unix strings", not "ASCII". A Unix string contains no nul byte, but that's about the only rule. It's certainly not necessarily human-readable.

I don't think a programming language can take the position that an OS needs to "adopt better encodings". Python must live in the environment that the OS actually provides. It's probably a vain hope that Unix strings will vanish in anything less than decades (if ever), given the ubiquity of Unix-like systems and their 40 years of history.

I understand that Python2 does not handle Unicode well. I point out that Python3 does not handle Unix strings well. It would be good to have both.

Another great book about this expedition is Shackleton's own South.

A list comprehension would work for GP, who wants a calculator. But others like to try out snippets of code in the REPL before using them in programs, and in that case you want the code to be the same.

Would the following work? It's been a while since I've had Py3 installed, so I can't casually try it. In your PYTHONSTARTUP, place the following:

  _map = map
  def map(f, *args):
    return list(_map(f, *args))

So you get lists in interactive mode, but iterators in actual scripts.

Personally, I prefer function. I can understand that others have a different preference; what I find surprising is the number of people who seem to care so much about this. Nevertheless, it is very evident that you are not alone.

> 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.

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.)

> 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.