1. 23

  2. 6

    I’m pleased about TopologicalSorter - I’ve implemented that ad-hoc several times, so I’m looking forwards to being able to delete some code.

    1. 3

      It’s worth pointing out that the HTTP 418 status code they’re pointing out is from an April fools’ RFC. If memory serves, the RFC was for the hypertext coffee pot control protocol, and its intended usage was that a teapot should return a 418 “I’m a teapot” status code if a client tried to get it to brew coffee using that protocol.

      It is amusing that it has just now leaked into a python client library. Here’s the list of real HTTP status codes.

      1. 4

        I used 418 in some tests in some Go code to serve as a clearly on purpose incorrect HTTP status. Kinda similar to 0xDEADBEEF in hex domain.

        1. 3

          And I use the 418 response code in my gopher server because I had several stupid webbots hitting it.

        2. 3

          oh wow, I’ve had a remove_prefix in so many utils.py files. nice to finally see it in the standard lib!

          1. 2

            Looks like it’s returning the original string if the string does not start/end with the prefix/suffix. A valid way to implement it, but I’ll have to keep my helpers which throw an exception in that case..

          2. 2

            Until now, you would have to chose from one of the following 3 options for merging dictionaries

            And now we have 4. Great.

            1. 13

              The PEP that specified the feature is worth reading, and points out that of the existing options, only update() is really front-and-center discoverable, and for the case of creating a third dict that’s the union of two existing ones, update() doesn’t permit it to be done in a single expression. It also has a long section responding to arguments about “there should be only one obvious way” and effectively saying that if the operator is implemented, that becomes the one obvious way to do it.

              The alternatives like unpacking syntax also have the disadvantage of not playing well with mapping types other than dict, or even with subclasses of dict – you always get an instance of plain dict back even if none of the inputs were plain dict. For example, if you have d1 and d2 and both are instances of collections.defaultdict, doing d3 = {**d1, **d2} results in d3 being a plain dict, not a defaultdict.

              The PEP also cited examples of existing Python libraries doing cumbersome things to get this behavior, and examples of Stack Overflow posts looking for a feature that does this concisely.

              1. 5

                Well, two of them aren’t really complete: dict(d1, **d2) doen’t work for non-string keys in d2, and d1.update(d2) can’t be used in an expression. {**d1, **d2} does work, but to me it’s not the reason to not support d1 | d2 because this operator just makes sense and should always have just worked. https://www.python.org/dev/peps/pep-0584/#motivation

              2. 2

                Does anyone know the status of PEP 554 (https://www.python.org/dev/peps/pep-0554/). In the PEP it is planned for Python 3.9, but I am pretty sure it’s not part of the release?

                1. 0

                  Off-topic, but this is a cool blog theme for a developer blog.

                  The post itself is quite good, too!

                  1. 7

                    It doesn’t work without javascript. For a developer blog, that’s pretty bad.

                    1. 3

                      It looks cool but is hard to use for me on mobile. Scrolling to the bottom, I wanted to click home and see other articles but the nav bar kept popping up and I couldn’t figure out how to close it. I could just fiddle with the address bar, but seems like the design should let people read. Weird that the three options are previous/subscribe/next. It seems like people would only click subscribe once but would likely click home many times.

                      1. 2

                        It doesn’t even load here… I only see this spinning thingy.

                        1. 2

                          The visual design and layout is good. The implementation of the overall experience could be much better. Most (possibly, all) of the JavaScript is unnecessary. This detracts from the experience. That said, there are good choices:

                          • Making the post content the focus of the page. The domain name carries the name of the author. Almost all sites frame the content within a brand of some kind.
                          • Homepage acts as the about page. This is a different choice from many sites which focus only on it listing the latest blog posts. I check out the about page on almost any blog post I read, so not having to click from home to about got my attention.