Hacker News Reader

Comment by ed25519FUUU | Hacker News Reader

> "foobar".removeprefix("foo")

I can't say how much of a nice improve removeprefix() and removesuffix() is. lstrip and rstrip prefix and suffix trimming bugs crop up in people's code constantly. This seems like a nice change, especially since the alternatives are so ugly.

View on HN

They got rid of the super ugly [:] but introduced a new ugliness.. | and |= operators for dictionaries. Why is this so important that this needs special operators? Python should be readable by everyone who can understand English. I hate when languages keep inventing hieroglyphs, twisting my fingers to type |= takes even longer than typing .join.

You can still do `a.update(b)`

The existing alternative to `a | b` was

  {**a, **b}

You could see this as an improvement.

As someone who started out in C I love the pointer style syntax

But it doesn't have anything to do with pointers....

Yeah but it’s the aesthetic (tho to be fair everything is a pointer in python.)

So.. you love asterisks?

No? I think the asterisks (two of which acts as a “pointer” to an expanded dict, instead of the dict itself) is straightforward and yes more aesthetic for my taste. Not sure what the circle jerk of non-sequitor comments and downvotes is for?

Oh my god yes.

as pointed out elsewhere in this thread, `"a" or "b"` evaluates to "a", which kind of makes me think that `a | b` (with a and b as dicts) would take values for overlapping keys from a, not from b.

The dict literal with dict-splats conveys a sense of ordering that makes the behavior of taking values for overlapping keys from the lattermost dict make more sense to me.

This is my favorite change in this release and cause me to upgrade to the RC version a few days ago. It's a huge QoL improvement for so much code I write.

I'm also a fan of the walrus operator. These are small, rare, clear, useful, idiomatic new features, in my opinion.

It is outstanding that that the new features have an audience.

One frets that Python could become a victim of 'featuritis' as the devs try to shop for a new kitchen sink for each release.

I personally feel walrus operator is a much more prominent improvement, considering how prevalent it can be used (like, I use it in almost every single `re.search()`, and at least half of conditional list comprehensions and `while`), while I don't find the old way of updating dict (`{a, b}` etc.) too bad.

But of course, both are very welcomed!

> They got rid of the super ugly [:]

What do you mean by that? Can't we clear a list by doing:

    L[:] = []

(useful when L is defined in another scope, or when you want to keep a reference to the same list object)

Unfortunately it's not possible to search for "[:]", so pointers appreciated

Wait, why not just L.clear()?

Good point. But you might still want e.g.:

    L[1:] = []

I just meant that you need the "[:]-operator" less often because of the new methods removeprefix, not that the thing is completely removed.

They already existed for sets and some people want dicts to have analogous behavior.

I feel the same way about -> in JavaScript. You would think after all these years I'd have come around by now. Nope, I'm still pissed off about that decision.

Huh? What's this do in JavaScript? (No sarcasm; I'm mostly in this ecosystem, but I have no idea what this is in reference to.)

They are called arrow functions (-> looks a bit like an arrow).

It's confusing to write it like -> because the actual operator is =>, which is close but not the same.

isn't it =>

I find this operator intuitive and idiomatic. It's widely understood and used as a binary OR operator in many languages, and it's easy to understand its functionality when both operands are dictionaries.

It’s also already an established part of the set syntax - it’s been possible to ^, | and & sets for a while now (symmetric difference, union and intersection). While not all of those make sense for dicts, | for union does and is quite intuitive.

It's also consistent with the set notation, which makes it easier to remember. Dict keys already kind of work like a set, this extends the behavior to deal with the values as well.

It's not introduced at all, its already there for sets

It doesn't replace the `lstrip` or `rstrip` methods; it replaces the need for an `if` statement using `startswith` and `endswith` methods.

    if "foobar".startswith("foo"): "foobar"[len("foo"):]

The parent comment referred to bugs from use of lstrip and rstrip for this purpose. The problem is that they often appear to work for this job, so they can make it all the way into code. Your own example strings illustrate that:

   > "foobar".lstrip("foo")
   "bar"

Of course, if the developer making this mistake tested with "foofbar" instead then they would realise their mistake. A more typical example of this type of mistake would be url.lstrip("http://").

If the developer is using str.lstrip or str.rstrip, they're doing it wrong (because they're using the wrong method).

    > "foobar".lstrip("wooowweeezoweeef")
    bar

Yes, that's what both comments you replied to have said.

That always bites people. `lstrip` and `rstrip` take a set of characters to be removed not a prefix/suffix.

    >>> "foobarbaz".lstrip("fo")
    'barbaz'

Reply on news.ycombinator.com