Live data from Hacker News

What’s New in Python 3.8

docs.python.org

331–340 of 381 posts

Re: What’s New in Python 3.8

#331
post #301
post #150

Earlier quoted context omitted.

Why didn’t Python ship with the opposite functionality as well? Parsing instead of formatting. Given a string and a format string, return a list of variables (or a dictionary).

Are you talking about parsing f-strings? How would that look like? As far I understand the following: print(f"your name is {name}") is roughly equivalent to: print(f"your name is " + format(name)) What is there to parse?

For example, to checkpoint a model, I would save it as “ckpt-{epoch_number}-{val_loss}”. Given this file name and the original format string, I would like to recover the epoch number and validation loss variables back.

From: ckpt-8-0.300 To: epoch=8, val_loss=0.300

Re: What’s New in Python 3.8

#332
post #44

Earlier quoted context omitted.

Yes, "path dependence" is a good way to describe it. (And Python has been my favorite language for 16+ years now) For https://www.oilshell.org/ , which has Python/JS-like functions, I chose to use Julia's function signature design, which is as expressive as Python's, but significantly simpler in both syntax and implementation: Manual: https://docs.julialang.org/en/v1/manual/functions/index.html... Comparison: https:/…

But the Julia syntax can not represent arguments that can be passed either positional or named, right?

Yes it can't, unless of course you just make two variables (one positional and one named) and inside the function you choose one.

Because of Julia's multiple dispatch paradigm, positional arguments are special compared to named arguments because they decide what method to dispatch to (in Julia f(x) is equivalent to x.f() in object oriented language, and it's extended to all positional arguments). That means that if you called f(a, b=nothing, c=nothing), f(1, c=1) it would dispatch to f(Int64, Nothing, Int64), while if you called f(a; b=nothing, c=nothing) with the same args it would dispatch to f(Int64). In Julia named arguments are effectively a way to pass more arguments without complicating the dispatch rules, and since there is only one way to call a function (outside of optional arguments, which appears to the end user as another implementation of a function) there is no ambiguity to where it dispatches to.

So basically, every language has it's own quirks, which the syntax decisions usually reflects, and Julia's scenario is fundamentally different from Python's.

Re: What’s New in Python 3.8

#333
post #283

Earlier quoted context omitted.

Problem with bisect is that bisect.insort() insertion is O(n), whereas C++ set.insert() is O(log n).

It is somewhat strange that Python does not have a binary tree in the standard library. I also couldn't find any discussion on the topic either. It might be a nice contribution. Edit: it was coined a few times on the python-ideas mailing list but it seems it just died a silent death there. https://mail.python.org/archives/list/python-ideas@python.or...

I suspect it's because you rarely need them in Python because the existing built-ins (list, tuple, dict, set) usually work well enough for a given job, or you're already using e.g. Pandas or something.

FWIW: https://github.com/calroc/xerblin/blob/master/xerblin/btree....

Re: What’s New in Python 3.8

#334
post #247
post #5

Earlier quoted context omitted.

I'm stoked about the walrus operator. Ever since I heard it was being added I've grumbled when writing code that would have been clearer with it. Of course I have to ask, what was your preferred syntax?

Not OP, but maybe it's "as": if re.match(pattern, string) as m: #use m Seems a bit more Pythonic, as "as" is already used like this with "with". Either one would be fine with me and useful.

It's already used in imports as well! It was the better choice, I don't know which arguments convinced them otherwise

Re: What’s New in Python 3.8

#335

This got missed from the release announcement, but now there's `functools.singledispatchmethod`,[1] as the class method sibling to `functools.singledispatch`.[2] This allows you to overload the implementation of a function (and now a method) based on the type of its first argument. This saves you writing code like: def foo(bar): if isinstance(bar, Quux): # Treat bar as a Quux elif isinstance(bar, Xyzzy): # Treat bar…

The issue with this and `singledispatch` is that they no longer support pseudo-types from the `typing` module [1] so you can't use them with containers of type `x`, e.g. `List[str]`, or protocols like `Sequence`. [1] https://bugs.python.org/issue34498

Yea, this one is really annoying... required a lot of rewriting of code to make some old code work with 3.7.

Re: What’s New in Python 3.8

#336

Buried in the notes for the `typing` module: > “Final” variables, functions, methods and classes. See PEP 591, typing.Final and typing.final(). The final qualifier instructs a static type checker to restrict subclassing, overriding, or reassignment: > pi: Final[float] = 3.1415926536 As I understand it, this means Python now has a way of marking variables as constant (though it doesn't propagate into the underlying va…

The thing is, it is only enforced in mypy... code that modifies a Final object (pi = 3 for example) later on will run fine.

Re: What’s New in Python 3.8

#337
post #92

Earlier quoted context omitted.

The issue, in my opinion, is when you want something like this: while m := f(many, args): # do stuff with m Now, if you're writing this in Python 3.7, you often end up with some code duplication: m = f(many, args) while m: # do stuff with m m = f(many, args) # duplicate Or something like this: while True: m = f(many, args) if not m: break # do stuff with m Personally, I consider the last version to be the most elegan…

I literally wrote your last example twice last week to hash files in 4k chunks. Those 4 lines would be reduced to 1 with the walrus operator. I welcome it, as well. Edit: 1 line, not 2 (excluding the "do stuff")

This comes up in recursive descent implementations as well https://gist.github.com/cellularmitosis/53913ad229bad5d0a3bb...

Re: What’s New in Python 3.8

#338

The expansion of f-strings is a welcome addition. The more I use them, the happier I am that they exist https://docs.python.org/3/whatsnew/3.8.html#f-strings-suppor...

I saw that and was like "Oh, that'd be a handy feature for a lot of other programming languages too." But the more I think about it, the more I'd rather have a feature that takes a list of expressions and converts it into a dict where the keys are the expression text and the values are the values of those expressions. Basically, syntactic sugar for this: { k: eval(k) for k in ('theta', 'delta.days', 'cos(radians(thet…

Can't you build your own function using format()? f-strings are just syntactic sugar for format() so presumably you can

Re: What’s New in Python 3.8

#339

Earlier quoted context omitted.

Coming from Perl, I used to want this badly, but then I thought that there's absolutely nothing wrong with m = re.match(...) if m is not None: pass Now, I wonder what you meant saying that single-line version is less error-prone, because I don't think so. I believe they're exactly the same in this regard, except for a bizarre case when someone would bastardize the code by putting some irrelevant lines between the ass…

Think about if you match multiple patterns: for line in f: if (m:= pat1.search(line)) is not None: ... do stuff .. elif (m:= pat2.search(line)) is not None: ... do other stuff .. elif (m:= pat3.search(line)) is not None: ... do something else .. In older Python that's: for line in f: m = pat1.search(line) if m is not None: ... do stuff .. else: m = pat2.search(line) if m is not None: ... do other stuff .. else: m = p…

That's... lovely. I propose making this the standard example of why you might want to use the walrus operator.

Re: What’s New in Python 3.8

#340
post #228

Earlier quoted context omitted.

IMHO walrus operator goes against the zen of python. https://www.python.org/dev/peps/pep-0572/#differences-betwee... https://www.python.org/dev/peps/pep-0572/#relative-precedenc... Even examples of the spec shows how unintuitive and "unpythonic" this is. Explicit is better than implicit. IMHO adding features to the language to save 1 line of code for 10% of cases when you need it (I agree that there's occasional case…

Well the zen of python also states: - Complex is better than complicated. Using the walrus operator makes the code more complex, but less complicated.

I vehemently disagree - these walrus vars are still in scope outside of the condition block. And on top of that, now there are special conditions for these walrus vars which are completely not obvious.

Reference: https://www.python.org/dev/peps/pep-0572/#scope-of-the-targe...

Post reply on HN