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

Dictionary union (PEP 584) is merged

github.com

Post reply on HN
Print view View original

61–70 of 87 posts

Re: Dictionary union (PEP 584) is merged

#61

Post by teddyh »

martopix wrote: post #54
tempay wrote: post #41

Earlier quoted context omitted.

One of the issues with Python 3 is that there isn’t really one killer feature, it’s countless little ones. Many believe 3.6 was the first release where they added up to enough of a benefit (though f-strings are a big help for many projects). Regardless it no longer matters, the Python 2 ecosystem is now rotting as packages drop support. Every week I have to make one or two hot fixes somewhere to forcibly pin to an ol…

I would definitely mention integer division as a massive change in py3 too. In my field, the @ multiplication operator is also useful.

> I would definitely mention integer division as a massive change in py3 too.

To be fair, you can get that in Python 2 too:

  from __future__ import division

Re: Dictionary union (PEP 584) is merged

#62

Post by bjterry »

eesmith wrote: post #35
saagarjha wrote: post #20

Earlier quoted context omitted.

It sailed long before that.

Go back to 1.0 and we still had two ways to write strings ("abc" and 'abc'), and two ways to write not equal ("!=" and " "). The last died with 3.0. But my point is that the Zen of Python must be seen as a post hoc description overlaid onto whatever the actual Python philosophy is. Aligned, certainly, but at times only roughly aligned. So I don't see it as having sailed (with string formatting, or other specific even…

    The Tao that can be told
    is not the eternal Tao

Re: Dictionary union (PEP 584) is merged

#63

Post by fulafel »

anentropic wrote: post #59
fulafel wrote: post #55

Earlier quoted context omitted.

I think that's cryptic too for most people, intuitive just for people who are conversant in bitwise operations.

these are standard set operations, not bitwise

The choice of the "|" operator for set union comes from bitwise operations: bitwise OR works as a union operator if you are using integers as bit vectors to represent sets of boolean attributes. And it was a common idiom back in the day when people used to program in C/assembly, using words as bit vectors was a common way to save memory.

Hence "|" as set union is intuitive for people who are familiar with this application of bit vectors.

Re: Dictionary union (PEP 584) is merged

#64

Post by cochne »

orf wrote: post #45
ehsankia wrote: post #19

Earlier quoted context omitted.

That ship had long sailed with string formatting anyways.

F-strings are the one obvious way to do string formatting. There may be other ways, for legacy backwards compatibility reasons, but f-strings are the way to do string formatting.

I disagree. In logging for example, ‘%s’ with the value as an argument to the logger is preferred because the formatting can be ignored if the log level is not sufficient to print.

Re: Dictionary union (PEP 584) is merged

#65

Post by pwdisswordfish2 »

mokus wrote: post #33
saagarjha wrote: post #20

Earlier quoted context omitted.

It sailed long before that.

It sailed with Turing completeness! At least, the popular interpretation of the phrase that ignores the word “obvious” did.

Ah, so that's what the migration to Python 3 was all about!

Re: Dictionary union (PEP 584) is merged

#67

Post by orf »

cochne wrote: post #64
orf wrote: post #45

Earlier quoted context omitted.

F-strings are the one obvious way to do string formatting. There may be other ways, for legacy backwards compatibility reasons, but f-strings are the way to do string formatting.

I disagree. In logging for example, ‘%s’ with the value as an argument to the logger is preferred because the formatting can be ignored if the log level is not sufficient to print.

Log formatting is a different problem than string formatting. With log formatting you pass the formatting arguments as function parameters, which is completely different from any other way you format strings.

Re: Dictionary union (PEP 584) is merged

#68

Post by anon102010 »

orf wrote: post #46
mokus wrote: post #33

Earlier quoted context omitted.

It sailed with Turing completeness! At least, the popular interpretation of the phrase that ignores the word “obvious” did.

It sailed when they added the for loop - everyone was happy using while loops, things worked and it was simple. Now there are TWO ways of calling a block of code repeatedly based? How confusing for new users. Python really went downhill since then.

I think go dropped one of these (for vs while) to keep to just one approach on loops so python providing lots of ways to do same thing is something other languages targeting entry level folks are seeking to avoid

Re: Dictionary union (PEP 584) is merged

#69

Post by heavenlyblue »

edudobay wrote: post #60
tempay wrote: post #41

Earlier quoted context omitted.

One of the issues with Python 3 is that there isn’t really one killer feature, it’s countless little ones. Many believe 3.6 was the first release where they added up to enough of a benefit (though f-strings are a big help for many projects). Regardless it no longer matters, the Python 2 ecosystem is now rotting as packages drop support. Every week I have to make one or two hot fixes somewhere to forcibly pin to an ol…

For me, proper handling and distinction of Unicode vs. binary data was a game changer. I don't know if that's related to my first language being non-English, but I remember it being really important to me and a strong reason why I made the switch years ago.

I used to work for a huge SEM business working with keywords in all languages of the world. No-brainer.

Re: Dictionary union (PEP 584) is merged

#70

Post by heavenlyblue »

cochne wrote: post #64
orf wrote: post #45

Earlier quoted context omitted.

F-strings are the one obvious way to do string formatting. There may be other ways, for legacy backwards compatibility reasons, but f-strings are the way to do string formatting.

I disagree. In logging for example, ‘%s’ with the value as an argument to the logger is preferred because the formatting can be ignored if the log level is not sufficient to print.

Except log formatting isn’t the same as actually executing the expression passed to the logging function.
Post reply on HN