Better handling of Unicode is inevitably how Python3 kills Python2. Also it's a good reason to have not supported Python2.

Aside from Unicode, I don't like some of the other changes. The overkill on the "one obvious way" bugs me in particular, e.g. the removal of reduce as a core function.

The existence of "one obvious way" isn't set in stone. It depends on context, and it's like the language developers didn't realize that when making their decision.

Moving reduce into functools was more than justified: almost nobody liked it, most people disliked it and if you really want to use if for whatever reason an import is hardly difficult. The decision was made because of the context, not in disregard to it.

The move of reduce to functools makes sense. But it's also inconsistent. map and filter should also be in the functools package tools right alongside partial and reduce. But instead, they're in __builtins__ because .... they're more popular I guess?

I'd actually be OK if map and filter were also in the functools package, but the only way to be consistent while maintaining backwards compatibility is going from the functools package to built-in.

Who disliked it? I used it all the time. Was there any survey or similar?

Guido disliked it. And he's the BDFL.

That's not quite a fair reduction; if it was just down to Guido map would be displaced too, or even gone.

You could quite easily use a process like the one described in the article to select the 'top' 1,000 Python packages, and then scan each of those for occurrences of calls to each of map, filter and reduce, and that way build up a fairly reasonable picture of how commonly each function is used.

While I use reduce a lot, I would guess that even with comprehensions making most uses of map and filter obsolete, that reduce is still the least commonly called of the three.

Better handling of Unicode was also why Python3 adoption has been slow. Upgrading a library or project from Py2 to Py3 is very simple if you already handle bytes vs unicode carefully everywhere in your program.

But for projects that mix unicode and byte strings, and hope for the best (it works okay as long as it is ASCII or UTF8), the upgrade requires substantial work.

Is Unicode handling in Python 3 really better?

http://lucumr.pocoo.org/2014/5/12/everything-about-unicode/

Armin is an incredibly smart guy for sure, but I'm not 100% I agree with him on all points.

I don't think he's wrong. I think he's probably right. And, I know it's a rant. I just don't agree that many of his points are "problems."

There are many, many issues that the change fixes. And, like every change, it does break some things. But, it was done for real reasons, not just because: https://docs.python.org/3.0/whatsnew/3.0.html#text-vs-data-i...

Some of the reasons were technical, some were very "we should be more standard."

I agree with the Python3 team, here. Mostly because it's more obvious what Python is doing now. But, it's also cleaner in my opinion.

It makes things harder, sure, 100%. But that's not always a problem or a bad thing. In this case, the more work comes with clarity and less chance for bugs (less edge cases).

Wow. Now that would be something. Writing desktop apps in Python would actually become viable. You'd essentially only have to distribute your source code and dependencies instead of bloated binaries containing a Python interpreter.

I've found, building Python binaries for Windows, the interpreter and standard library takes up a negligible amount of space (a few MB). Most of the space was taken up by dependencies anyway, e.g. wxPython something like 15 MB! (I think I got it down to 7 MB using UPX to compress the DLLs.)

UPX is not magic -- it compresses machine code and makes sure unpacking code is run every time the executable is loaded. So if you only care about the size of the binaries in transit, don't use UPX, just use eg NSIS with lzma compression. You'll probably end up with a smaller package this way.

I agree, but UPX is magic.

Speaking of that, there's a nice tool to build the installer for you: http://pynsist.readthedocs.org/en/latest/

People already do this - e.g. the original bittorrent app was written in Python. Many users on Windows didn't notice - if you package it correctly it works just like any other app.

Have always hated the half-ass integration Windows has. Half the stuff does not work as it should or is broken, no one tests on Windows and I doubt they will start now. Never been fun doing anything with non-MS stuff on Windows. I doubt it ever will be. As for writing anything, I don't know why I would bother with non-MS stuff on Windows platform, it usually does not come out well. C# is a great language and Visual Studio is great for using it. And it's free.

> Have always hated the half-ass integration Windows has. Half the stuff does not work as it should or is broken, no one tests on Windows and I doubt they will start now.

What? Python has been one of the significant exceptions on this front because Enthought actually shipped a product which was expected to work on Windows. Python also goes out of its way to make sure that things work in sane ways even when Windows has no real equivalent.

I also suspect this is one of the reasons for Python's ascendancy over other scripting languages. By being one of the few scripting languages that runs decently on Windows, you gain an automatic user population advantage.

Maybe I'm dreaming this... Trying to install some Python package on Windows 8.1 and 'the usual' stuff didn't work.

I'm a python newb and maybe I wasn't doing something right. I'm more used to Linux/Perl and doing "Perl -M CPAN ..." which just works. 'pip ...' just didn't.

I was not left with the feeling that Python ran as well on Windows as on Linux.

pip is unfortunately a a bit hit and miss on Windows. The (IMO) 'correct' way to install package on windows is to first install Anaconda Python (https://www.continuum.io/downloads) and then:

0) Check if the package came preinstalled with Anaconda

1) if not try to use conda to install packages,

2) if conda doesn't have the package, see if it's been uploaded here: http://www.lfd.uci.edu/~gohlke/pythonlibs/

3) try pip.

It definitely doesn't. People writing Python packages make reasonable assumptions like that you've got a POSIX command line, a UTF-8-compatible terminal, and a C compiler that's compatible with the Python development headers. On Windows, you probably don't.

It'd be nice if Windows made an effort to provide a sane environment for Python, because the Python devs certainly aren't doing anything to make things sane on Windows.

Don't you want to try Cygwin? You'll get as close to Unix on Windows as possible. pip will definitely work.

Ubuntu server VM in vbox with shared folders works better than anything I've tried to get things working well I native Windows. Sure it's not impossible, but the tax isn't worth it IMO.

Many things are still broken in cygwin still. Examples: uwsgi, gevent

You need to manually add the directory containing pip and other tools to the path.

If it is not, you can often do python -mpip install xxxxx

And you're right there are some gotchas - for instance pip install -U pip won't work to update pip itself as on Windows a program can't seem to overwrite it's own executable.

AFAIK (and I have dozens of virtualenvs running on a Windows box) you can upgrade pip, it's just one of a handful of packages that throws an error at the end because it was unable to delete the folder it created during the install process. The upgrade works, it just looks like it doesn't. But maybe that's only true inside a virtualenv.

I'm under the (quite possibly mistaken memory) impression that the Enthought guys (ScipPy and NumPy) hid installation stuff behind a GUI for Windows people.

I could be wrong as it's been a long time since I helped anybody with that on Windows.

It is up to whoever creates the package. You can create windows installers with setuptools, see: https://docs.python.org/2/distutils/builtdist.html

That hasn't been my experience. It depends on the kind of app you are writing. Are you writing a desktop UI app or game? Yes, C# apps tend to be better and you can use XAML or whatever. But I've written a bunch of build tools and network apps that work flawlessly on Windows and Unix family systems. Not everyone wants to switch to Microsoft tooling for their entire project just to support one more platform.

By comparison, C# tooling makes some things really difficult on Unix-like systems. For example, try spawning a process and redirecting file #3 to a pipe. I honestly do not know how to do that in C#. Python is fantastic at being cross-platform glue.

I've never really had issues with using Python 3 on Windows, as for .NET you can always give IronPython a shot as well, though it has yet to make the leap to "3" in a while, at least last I checked, same with Jython.