Python 3.5.0 (opens in new tab)

You mean, second gear up to fifth?

I tried writing some Python 3 code and the lack of parameter tuple unpacking by itself stunned me and drove me crazy, never mind other stuff. Python 3 seems very user-unfriendly compared to Python 2. Won't touch it with a ten foot pole unless my life depends on it.

  [*range(i) for i in range(5)]

  {**d for d in ds}

> >>> filter(lambda x: x in 'ABC', 'ABCDEFA') > 'ABCA'

it was a special case for a few types, didn't (couldn't) work for all types e.g.

    >>> filter(lambda x: x in 'ABC', set('ABC'))
    ['A', 'C', 'B']

I like Python 3's print. It's kind-of a pain because my day-to-day uses Python 2 and the context switch is annoying, but 3's is way more flexible and readable:

    print <<f, foo, bar # (or is it >>file? I can never remember)

               actually makes sense, no sigil soup
                       ||
                       \/
    print(foo, bar, file=f, flush=True)
                               /\
                               ||
                   separate statement necessary in P2

I feel you on the loss of argument unpacking, it was a very convenient feature (though not too common IME)

    >>> sum((range(i) for i in range(5)), [])
    [0, 0, 1, 0, 1, 2, 0, 1, 2, 3]

    >>> import itertools
    >>> list(itertools.chain.from_iterable(range(i) for i in range(5)))
    [0, 0, 1, 0, 1, 2, 0, 1, 2, 3]

    >>> filter(lambda x: x in 'ABC', {'A','B','C','D','E','F','A'})
    ['A', 'C', 'B']

I use 's.encode("hex")' often. I realize why hex/base64 are gone, but it's so short and easy in Python 2.7.

    >>> [x for y in (range(i) for i in range(5)) for x in y]

    [y for x in range(5) for y in range(x)]

That really bugged me for a while, but then I added a "snippet" into my editor. Now I type: pr then the tab-key, and it transforms to:

    print('', )  # with cursor between quotes

    >>> codecs.encode(b'Python', 'base64')
    b'UHl0aG9u\n'

The optional typing is a tricky subject. I'll have to wait until there are tools actually using it to see. One of my biggest hesitances with it is that until runtime checking or really good static analysis exists, annotating things incorrectly can be too easy. I am cautiously optimistic though. The theory is fantastic, just have to wait for the follow through. The best way to sort-of statically type things right now(imo) is through namedtuples (which I make use of heavily for lightweight, strict datatypes)

Formatting for bytes and bytearray is actually one I run into a ton trying to port py2 code to py3. Pretty excited about that.

Looking forward to this as well. So far the only static analysis tool I'm aware of that makes use of the PEP 484 framework is mypy [1] -- does anybody happen to know of other tools in the works?

[1] http://mypy-lang.org/

Feels like such a step back when I have to use a Python 2.x codebase - so many little annoyances.

Unfortunately, not always an option. Or rather, it is, but would require an immense amount of effort. Not to mention, the client wouldn't be too happy with the increase in bugs.

Working on a legacy C++/Python implementation stuck with 2.5. It's not as bad as it sounds, really. You learn to improvise, and work on python 2.7/3+ in off-hours.

https://github.com/klen/py-frameworks-bench/blob/develop/fra...

(from: http://klen.github.io/py-frameworks-bench/)

[1] http://aiohttp.readthedocs.org/en/stable/

It's hard to write an asynchronous ORM though. Your options are either to use some existing synchronous ORM (like SQLAlchemy) in a thread pool (`loop.run_in_executor`) or use more low-level db driver: https://github.com/aio-libs/aiopg#example-of-sqlalchemy-opti...

[1] http://pythonhosted.org/pulsar/ [2] https://pypi.python.org/pypi/pulsar-odm

I have taken to using the 3 syntax in 2.7 so that I am prepared, but until this particular library moves, I cannot.

P.S. That flask warning is definitely very out of date. I used Flask with Python3 quite happily, literally this week.

Sadly the situation for using asyncio for web was not that great last I checked, because that would be a strong incentive.

Hypothesis: distributions started installing python3 by default now, so people don't have to download it separately anymore. Python 2 downloads will stay at the same level as they were and actually 2.6 will go up as it's not available in supported distributions anymore. This is strangely opposite trend to actual adoption.

You do have a point, right? Coming in to a thread about a python release and trying to stir up controversy?

Or are you just doing it for kicks?

For stability it's best to keep the system managed through packages from the standard repositories. If you install things that are not from the repositories the packaging system won't be able to track dependencies - it will have bad information about some capabilities as some items won't have been installed using the packaging system. Overwriting official system libraries is a common cause of problems.

It's best to only upgrade something when the repository for your release makes it available: it pays to be conservative about the repositories you use, sticking to the standard ones and thinking very carefully about adding any others (e.g PPA's).

If you want 'newer' versions of frameworks/libraries for development then you're better off installing them away from the main system - traditionally that is /usr/local, or using a partitioning system such as chroot.

For Python specifically there's a really nice option of use venv/virtualenv.

https://github.com/yyuu/pyenv

In that case, `pyenv install 3.5.0` and then `pyenv shell 3.5.0` or `pyenv global 3.5.0` to switch which Python gets used. With pyenv's virtualenv plugin, you can also get rid of the need to use virtualenvwrapper for managing dependencies.

(I understand that adding os.scandir might require a PEP)

    def some_co():
        yield 2
        yield 3

But you don't return more than once from a coroutine. You can suspend it as often as you like, and that's what "await" does.

I thought that Python3 removed 'u' strings, was this just a bit of humour in the PEP?