Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What’s New in Python 3.7

docs.python.org

Post reply on HN
Print view View original

51–60 of 70 posts

Re: What’s New in Python 3.7

#51

Post by namelost »

akvadrako wrote: post #49
mixmastamyk wrote: post #48

Earlier quoted context omitted.

Why add that crazy syntax when a + would be a lot clearer?

It makes sense in context. {} is a dict literal, and * * dict is already used other places to expand a dict into key-value pairs. Given a = {1: 1} b = {2: 2} This c = {**a, **b} is equivalent to c = {1: 1, 2: 2}

a|b would be the obvious choice, because it already works for set:

    {1,2}|{2,3} == {1,2,3}
I guess the reason they went for the weird {∗∗a, ∗∗b} syntax is that it is not a commutative operation.

Re: What’s New in Python 3.7

#52

Post by aisofteng »

fiddlerwoaroof wrote: post #8
drizze wrote: post #7

Earlier quoted context omitted.

I think *iterable would just pass one argument that's a list, not pass each argument individually

>>> print([1,2,3]) [1,2,3] >>> print(*[1,2,3]) 1 2 3

That doesn't tell you anything about when the list is expanded.

Re: What’s New in Python 3.7

#53

Post by joelthelion »

saurik wrote: post #42
joelthelion wrote: post #35

Earlier quoted context omitted.

Ah, great. This used to be rather clunky to do.

Really? This is how that was done in Python 2.7 and it doesn't seem that much clunkier to me... dict(dict1, **dict2)

It has a lot of issues. The biggest one for me is the following: Dicts are intended to take hashable keys (e.g. frozensets or tuples), but this method fails in Python 3 when keys are not strings.

Source: https://stackoverflow.com/questions/38987/how-to-merge-two-d...

Re: What’s New in Python 3.7

#54

Post by heinrich5991 »

saurik wrote: post #42
joelthelion wrote: post #35

Earlier quoted context omitted.

Ah, great. This used to be rather clunky to do.

Really? This is how that was done in Python 2.7 and it doesn't seem that much clunkier to me... dict(dict1, **dict2)

That's only allowed if the keys in the second dictionary are valid Python identifiers (don't contain spaces etc.). I think CPython is OK with this, but PyPy is not.

Re: What’s New in Python 3.7

#55

Post by qquark »

winterlight wrote: post #12
orf wrote: post #6

Earlier quoted context omitted.

Perhaps it could trigger if you do function(*iterable), with a huge iterable?

Nope, that works just fine. >>> def f(*x): print(x[-1]) >>> f(range(300)) 299 And surprisingly, in python 2.7, I was able to define a function that takes more than 255 arguments. But perhaps this only worked because I cheated and used exec. >>> exec("def f(" + ",".join("f" + str(x) for x in range(300)) + "): print(f299)" >>> f(*range(300)) 299

Interestingly enough, the function def (the exec part) does not work in 3.6, as one could expect, but in 2.7 even though the function definition works, you can make the call fail by generating actual parameters:

  >>> exec("def f(" + ",".join("f" + str(x) for x in range(300)) + "): print(f299)")
  >>> f(*range(300))
  299
  >>> exec("f(" + ", ".join(str(i) for i in range(300)) + ")")
  Traceback (most recent call last):
    File "", line 1, in 
    File "", line 1
  SyntaxError: more than 255 arguments
When reducing the number of parameters to be invalid for f, the following error is shown:

  >>> exec("f(" + ", ".join(str(i) for i in range(30)) + ")")
  Traceback (most recent call last):
    File "", line 1, in 
    File "", line 1, in 
  TypeError: f() takes exactly 300 arguments (30 given)
Which seems a bit paradoxical - "You need 300 arguments" - "No, wait, actually, you can't have more than 255" ... ;)

It looks like they either had changed the internals of python 3, making it fail at the definition as a side effect instead of when calling, or used the same underlying logic but purposely chose to issue the exception to potentially catch the problem earlier...

Re: What’s New in Python 3.7

#56

Post by raymondh »

dorfsmay wrote: post #3

"More than 255 arguments can now be passed to a function, and a function can now have more than 255 parameters." There are human devs who needed this? Or is this a sign that AI bots are now involved in language design?

Guido had stated that he didn't want the implementation to place arbitrary limits on the language specification.

This particular limit was not present in the early Python 2 releases.

When the limit was added, limiting arguments wasn't the goal; instead, it was just an artifact of a patch regarding how keyword arguments and positional arguments we encoded in Python's bytecode scheme.

Re: What’s New in Python 3.7

#57

Post by raymondh »

CaliforniaKarl wrote: post #32

> Support for building --without-threads is removed. (Contributed by Antoine Pitrou in bpo-31370.). Woooo! That means, at some future time, I'll be able to remove code checks for non-threading Pythons.

This patch was a little aggressive and may get reverted (it caused immediate code breakage in downstream distros and projects). Changes like this typically need a deprecation period (that said, to the extent the current feature didn't really work in the first place, we can immediately take it out).

Re: What’s New in Python 3.7

#58

Post by mixmastamyk »

namelost wrote: post #51
akvadrako wrote: post #49

Earlier quoted context omitted.

It makes sense in context. {} is a dict literal, and * * dict is already used other places to expand a dict into key-value pairs. Given a = {1: 1} b = {2: 2} This c = {**a, **b} is equivalent to c = {1: 1, 2: 2}

a|b would be the obvious choice, because it already works for set: {1,2}|{2,3} == {1,2,3} I guess the reason they went for the weird {∗∗a, ∗∗b} syntax is that it is not a commutative operation.

Wouldn't mind that either.

Re: What’s New in Python 3.7

#59

Post by warbiscuit »

user5994461 wrote: post #44
noselasd wrote: post #15

Earlier quoted context omitted.

If it was changed from ascii to utf-8, how does it break everyting else ?

ASCII doesn't exist as such. Characters are encoded in one byte and ascii leaves the highest 128 characters undefined. They are interpreted system-wise, depends on the locale and user settings.

"ascii" the codec does exist under python. It's strictly defined as byte values 0-127, anything in the 128-255 range causes a decoding error...

    >>> b"abc\xf0".decode("ascii")
    UnicodeDecodeError: 'ascii' codec can't decode byte 0xf0 in position 3
Thus, moving the default from "ascii" to an ASCII-superset should have no decoding issues for previously valid files, since those bytes were never valid to start with.

Re: What’s New in Python 3.7

#60

Post by fulafel »

coldtea wrote: post #16
fulafel wrote: post #2

Switching the default encoding from ASCII to utf-8 sounds like a pretty big change.

Isn't ASCII a strict subset of UTF-8? If anything this should make sure programs don't break because they read some utf-8 extended character when expecting just ascii -- which is the most common case.

I didn't say it's a bad change!

But since you raise the issue, there are downsides: Many programs developed on 3.7 will inadvertently break on pre-3.7 Python versions. As we know, this is a big thing on parts of the Python ecosystem because users frequently rely on the Python version that come with their OS or framework (eg AWS Lambda), and many developers want to stay compatible with the most common platform-shipped Python versions.

Post reply on HN