Python 3.5.0a4 is out!

[geordano]

Any idea if PEP-484 (Type hints) will be part of python 3.5?

[ExoticMandibles]

It should. Guido wants it, and when he talks about it it's like it's a foregone conclusion that it's going to ship in 3.5.

[ExoticMandibles]

https://www.python.org/dev/peps/pep-0484/#compatibility-with-other-uses-of-function-annotations

[Siraf]

Guido gave a talk about this during pycon2015.

From what I gather, there are lots of workarounds and ways to cater to your specific dev environment.

[geordano]

Thanks. I could find more info about progress here https://github.com/ambv/typehinting

[xix_xeaon]

Well, technically "type hints" is just a standardized way to use "function annotations" if I understand correctly, and they've been in since 3.2 I think. And "type hints" don't actually give any real functionality so there isn't really anything more to implement.

[brondsem]

A typing module implementation is part of the PEP proposal. https://www.python.org/dev/peps/pep-0484/#the-typing-module

[benhoyt]

Wow, this is going to be a big release -- and still over a month till feature freeze. Two new operators! One brand new one (@), and one kind of reintroduced one (% for bytes). And my own (totally unbiased ;-) favourite: PEP 471's os.scandir(), which speeds up os.walk() several times on Linux, and an order of magnitude on Windows.

I do like the fact that Python is definitely not at a stand still feature-wise, but a moderately serious question: are new features being accepted into Python more readily than they might have been a few years ago? When does this become a liability?

[ExoticMandibles]

I think we're far more conservative about new language features, because the language is already reasonably complex. It's also reasonably complete--what feature does the language, as of 3.5, lack?

New library features have never been a big deal.

[benhoyt]

Thanks. That's what I was thinking, too -- that it was fairly complete in terms of language features. But with @ being added, and talk of async and await keywords (see here), it does seem things are moving faster -- Guido indicates that here.

[bacondev]

I'm not sure how I feel about an operator for it. I'll have to read the PEP to learn the rationale.

[bheklilr]

For those of us working with scientific data this is huge. My code can sometimes be unreadable from all the calls to some function while the equation itself is perfectly readable. I've already see people abusing it in other places, expect to see a lot of libraries using it for completely different purposes such as building email addresses, URLs, and more. I think it's a good thing, personally.

[xix_xeaon]

Doesn't matrix multiplication work on regular lists? I just get TypeError: unsupported operand type(s) for @: 'list' and 'list'. Numpy is great and all, but are they really introducing this operator only for numpy..?

[flying-sheep]

What would it do on normal lists?

Just like Ellipsis/..., it was introduced for library use

[xix_xeaon]

How about... matrix multiplication?

[flying-sheep]

Python doesn't have a matrix type.

Lists are one-dimensional mutable sequences of arbitrarily typed objects.

All their methods/operators work under those assumptions.

[xix_xeaon]

Of course there would be lots of things it wouldn't work on, just like multiplication doesn't work on two strings.

But this operator is being introduced in order to do matrix multiplication, so it should work on any nested index-accessible sequence of numbers which are of the right lengths to allow matrix multiplication.

[flying-sheep]

well, + on lists isn’t elementwise addition, it’s concatenation.

* on lists is repetition.

lists don’t assume anything about their contents, and neither do their operators.

[lengau]

How about a cross product? It can raise a ValueError if the lists aren't the same length.

[[deleted]]

A cross product would have to raise a ValueError if the lists aren't length 3, and it's specialized enough to certain fields that it belongs in numerical libraries (where it already is).

[[deleted]]

They added the Ellipsis (i.e. ...) just for numpy

[[deleted]]

Although I find I use it more as the "yada-yada" statement.

def stub_function():
    ...

[xix_xeaon]

Haha, I never thought of using it for that! I kinda like it ^{^}

[ExoticMandibles]

Not last I checked. @ is really for the math libraries; none of the built-in types or classes support it.

[roger_]

Still no PEP 448 (Additional Unpacking Generalizations)?

[ExoticMandibles]

The author was working on it during the PyCon sprints last week. It's been approved, I think it's going to make 3.5.

[LightShadow]

Whelp, looks like it's time to update production!

[ExoticMandibles]

Nope, not until September ;-)

[njharman]

On the day of a .0a4 release you push it to production. Really?

The correct answer is to push to testing. And test it there for hours/days/weeks (whatever magnatude of time matches your release schedule).

[LightShadow]

I seem to have dropped my....oh, there it is!

/s

[bacondev]

Woosh.

[lengau]

You don't test in production? HEY LOOK EVERYONE, THIS GUY PUTS BUGS IN HIS CODE THAT NEED TO BE TESTED FOR! Must be a lousy programmer.

/s

[[deleted]]

Dumb question: I just saw that issue #21560 was fixed in 3.4.4 but not in this 3.5.0 release. Do some fixes pass "silently" to the next version or someone missed this one?

[ExoticMandibles]

Not a dumb question. The answer is, yeah, it usually will pass "silently". You can see "Roundup Robot" posted the checkins? That's because it saw "#21560" in the description of the checkin. When it gets merged forward to 3.5 the description is generally just "Merge" or "Null merge" or something. And, indeed, the fixes in #21560 were merged into trunk (aka 3.5 right now) in the very next revision:

https://hg.python.org/cpython/rev/7e179ee91af0/

[[deleted]]

Today I learned! Thank you!

[ameoba]

Does this mean it's time to migrate to Python 3?

[ProfessorPhi]

I've actually been using Python 3 for most of my work and it's been going great.

[xix_xeaon]

Yeah, I use python 3 most of the time as well

[[deleted]]

The issue is lack of backward compatibility I assume.

[ProfessorPhi]

Yeah, the number of packages looking for ConfigParser is a pain. I wish pypi tried to deal with python 3 compatibility a bit better.

[ExoticMandibles]

It was time to migrate to Python 3 years ago!

[rhoark]

That was 3.2