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

What's Coming in Python 3.8

lwn.net

Post reply on HN
Print view View original

541–550 of 558 posts

Re: What's Coming in Python 3.8

#541

Post by masklinn »

joshuamorton wrote: post #527
masklinn wrote: post #443

Earlier quoted context omitted.

> F strings are %-based interpolation done right, and the sooner the latter are relegated to "backward compatibility only" status the better. They are also more visually consistent with format strings. No, f-strings handle a subset of %-based interpolation. They're nice and convenient but e.g. completely unusable for translatable resources (so is str.format incidentally).

What makes % better than .format for translations (and isn't something like Django's _(str) better anyway? F strings are obviously non-lazy, but _(tmpl).format(_(part)) seems fine?

`.format` lets you dereference arbitrary attributes and indices (I don't think it lets you call methods though), meaning you can run code and exfiltrate data through translated strings if they're not extremely carefully reviewed, which they often are not.

% only lets you format the values you're given.

> and isn't something like Django's _(str) better anyway

They're orthogonal. You apply string formatting after you get the translated pattern string from gettext. In fact, Django's own documentation demonstrates this:

    def my_view(request, m, d):
        output = _('Today is %(month)s %(day)s.') % {'month': m, 'day': d}
        return HttpResponse(output)

Re: What's Coming in Python 3.8

#542

Post by dannyfraser »

newen wrote: post #281
tomkat0789 wrote: post #230

Earlier quoted context omitted.

What's stopping people from forking the language at python 2.7? Let the pythonistas add whatever feature they feel like while people who need stability use "Fortran python" or whatever.

I truly wish this would become a thing. It's really frustrating having to update my installed packages and my code for some stupid change the language designers thought is sooo worth it. Just stabilize the bloody thing so I can do some work. Updating code so it meshes with the "latest and greatest" is _not real work_.

Containers or environment management solve this problem quite easily. All of my major projects have a conda environment alongside them, and I expect I'll be shifting things over to Docker containers as my org starts shifting things to the cloud.

Re: What's Coming in Python 3.8

#543

Post by Grue3 »

kazinator wrote: post #516
Grue3 wrote: post #492

Earlier quoted context omitted.

>I don't understand why you think print or log debugging is inherently bad. I use it myself all the time, but it just shows the weakness of the tooling that people have to resort to such measures. Fortunately, some people are working on it [1]. >Also, it's part of the format string and not a special print function so that it can be used for logs and other output as well, not just the console. Since print (and hypothe…

That's poor compared to just logging.warning('Unusual situation', foo, bar). I.e. since print isn't a statement, you can give other functions the same argument conventions that it has, instead of making the programmer use a string-generating shim. Speaking of Common Lisp, it has functions other than format which take format arguments. $ clisp -q [1]> (error "value of ~s should be less than ~s" 'bloop 42) *** - value…

I don't expect logging.warning to change in future versions of Python (currently it substitutes extra args as % operator, so you'd have to write logging.warning('Unusual situation foo=%s, bar=%s', foo, bar)) since it would unnecessarily break too much code. But since print doesn't return any usable value, it can be easily updated to return a useful value.

Re: What's Coming in Python 3.8

#544

Post by linsomniac »

dual_basis wrote: post #517
linsomniac wrote: post #206

Earlier quoted context omitted.

I've literally been wanting something like the walrus operator since I first started using Python in '97. Mostly for the "m = re.match(x, y); if m: do_something()" sort of syntax.

I mean, that isolated example doesn't really demonstrate the benefit of a walrus operator does it? You could have just written "if re.match(x, y): do_something()". If you re-used the result of computation within the if statement, I feel that would be a better example, eg. "m = re.match(x, y); if m: do_something(m)".

True enough, as you point out I would be expecting to do_something with m. :-)

Re: What's Coming in Python 3.8

#545

Post by stakhanov »

uryga wrote: post #468
stakhanov wrote: post #132

Earlier quoted context omitted.

The philosophy that most of Python's language design is based on is that for everything you want to do, there should be one and only one obvious way to do it. The first part of the statement (at least one obvious way to do it) goes to gaining a lot of expressive power from having learned only a subset of the language specification corresponding to the most important concepts. So you invest only a small amount of time…

> "iterate through a list of strings, and print each one" print(*lst, sep='\n') :)

That's exactly what I'm talking about. A REAL python programmer would immediately recognize that to be the bullshit way that someone would do it, if proving what a f*ing master they are were more important to them than clarity.

Re: What's Coming in Python 3.8

#547

Post by TheRealKing »

yxhuvud wrote: post #434
colechristensen wrote: post #157

Earlier quoted context omitted.

This is why a lot of scientific code still uses fortran, code written several decades ago still compiles and has the same output. How long has the code which was transitioned to python lasted?

Fortran has added a whole lot of features over time though.

but you can still compile F66 with Intel Fortran compiler 2020 (and other compilers as well)

Re: What's Coming in Python 3.8

#548

Post by TheRealKing »

stefco_ wrote: post #400
colechristensen wrote: post #157

Earlier quoted context omitted.

This is why a lot of scientific code still uses fortran, code written several decades ago still compiles and has the same output. How long has the code which was transitioned to python lasted?

This isn't that good of a metric for code utility. Sure, very-long-lived code probably solved the problem well (though it can also just be a first-mover kind of thing), but a lot of code is written to solve specific problems in a way that's not worth generalizing. I write a lot of python for astrophysics. It has plenty of shortcomings, and much of what's written will not be useful 10 years from now due to changing AP…

by the way, three-decades has gone since FORTRAN became Fortran.

Re: What's Coming in Python 3.8

#549

Post by ben509 »

sametmax wrote: post #406
ben509 wrote: post #325

Earlier quoted context omitted.

Quoth the PEP[1], Guido changed his mind when he found proof that coders would write redundant (and expensive) code to avoid using a separate line to construct a temporary variable. So one might argue that a principle of python is that the language is dictated by how people read and write rather than the other way around... it's pretty hard to say what principles are "core" when they all conflict and you have to weig…

20 years after. It took 2 decades. My impression from the debate, and taking in consideration the political context, is that he saw that as the tipping point of the BDFL transition and a good test run as much as a language feature.

I'm not following what you're saying it's a test run of. I agree that he probably wanted to cease being BFDL because it's a big job, but with the caveat that I'm terrible at following Internet drama, he did seem genuinely surprised at the outrage.

Regarding that it took 25 years, the normal Python syntax has been enormously successful. People don't tend to look for problems in things that work.

Re: What's Coming in Python 3.8

#550

Post by owaislone »

mkl wrote: post #329
owaislone wrote: post #302

Earlier quoted context omitted.

If feel Go solves this in a much more readable way. if m := re.match(...); m { ... do something ... } Still not as readable as splitting it over multiple lines but quite a lot better than Python's syntax IMO especially once you learn how the if statement works in Go.

How is that more readable? It's identical except for ":" -> ";", and some extra symbols added. Needing to repeat "m" seems seems redundant, and particularly bad for readability as it moves the actual condition far away from the "if".

It is better IMO because it doesn't merge two things into one. It simply translates to `if ; { }` as a generic rule. Variable used in condition may or may not be the same one in assignment. Bundling assignment and condition is what people don't like about this feature.
Post reply on HN