Compared to JS performance over the same tasks - that's where WASM improvements should deliver. It doesn't have to be as fast as JS, just fast enough to become an acceptable alternative for the average case.

Or put another way, you're forced to specify the same thing twice: with whitespace for the human and with braces for the compiler, creating the possibility for these specifications to get out of sync. In Python, the compiler reads the same information you already put there for the human.

I'm a huge Python fanboy and this line is absolutely awful.

Comparison chains are great for stuff like "x < y < z" or "x == y == z", but the operators should never be mixed.

"Readability counts" is, IMO, the most important line in the Zen of Python, and that line is unreadable. I imagine it's equivalent to:

    return headers.get('x-foo') == settings.FOO_KEY and settings.FOO_KEY is not None

The closest package was Typer, by the creator of FastAPI, but it looked unmaintained, and didn't support Literal types! Or at least that was the case when I was investigating ~year ago.

Pep was originally even longer and there's planned follow up peps for other tensor related type features like literal arithmetic to allow type hinting function like np.concatenate. I expect 2/3 more peps in that area in the next year or two.

Leaving users having to guess where in the hierarchy you decided to hide something, that they know they’re looking for doesn’t add value. No, just keep it flat and simple.

Who knows, it could be a good feature to earn the 4.0 moniker.

We have a 15 year old setup.cfg in one project at work, many other .ini's... has never been an issue.

But I agree there are loads of missing features in Python :)

This really is the only practical area where Go is superior to Python. No messing with 3rd-party libs, no compromises, no hacks... Everything else is not really critical for most people, and largely not worth losing all the nicer features of Python for; if they could just fix it once and for all in stdlib, just blessing one compilation format and making it well-supported on all the big platforms, it would be a big step forward for the ecosystem.

Easier said that done, of course.

Python 2 is EOL, so that's no longer a concern.

As for differences between Python 3 releases, isn't there a fairly large difference in TOML support as well, since in versions before 3.11 it doesn't work at all? Wouldn't specifying the behaviour of the INI parser as whatever 3.11 is doing (and raising an exception on earlier versions) amount to essentially the same thing?

Toml is ill-defined as well. ini files work fine for these trivial uses.

https://hitchdev.com/strictyaml/why-not/toml/

So now you have two flawed ways to do it, congrats.

It's what your Terraform files are primarily written in

I want to be able to use typing everywhere if I'm going to use it, it really grinds when I have to selectively not use it.

That being said, im glad typing is in the language :)

> PyInstaller bundles a Python application and all its dependencies into a single package. The user can run the packaged app without installing a Python interpreter or any modules. PyInstaller supports Python 3.7 and newer, and correctly bundles many major Python packages such as numpy, matplotlib, PyQt, wxPython, and others.

[1] https://pyinstaller.org/en/stable/

[1] https://github.com/microsoft/pyright/blob/main/package-lock....

I think that's unrelated. Seems to be something that's only for Callables.

As someone who worked briefly on a Common Lisp implementation, including trying to get it to cross-compile, I'm very glad this technique hasn't caught on in the broader community.

The history of Python means that coders make functions whose return is usually quite clear, but when it's not, I'm really glad I have typing.

Also, some libraries like Pydantic make use of types in a very clever and productive way.

Really cool for parts of your code in which runtime type enforcing is important (eg. external interfaces)

Go made multiple decisions that make me face palm. It was so close to being a great systems programming alternative.

The fact that simple reusable utility functions were/are complicated does make it feel half baked to me too.

That's impossible, because it's not a type system at all.

It's type hinting, effectively a documentation feature, and sure, you can misdocument stuff. If people started building tools that rely on it to hack an actual type system on top of it, well, it's their problem. Duck typing is not affected by it in any way.

Well, yeah, because that's a compile-time check, not a runtime check. Use Pydantic if you want runtime validations.

> The new type system goes pretty much against the idea of duck typing,

It's very much orthogonal, due to the aforementioned distinction. Type annotations are compile-time. Duck-typing is run-time. You can still type-hint something and then call an attribute that isn't on the interface, and you can suppress the type error with `# type: ignore`. But also, if you know you are using quack(), you probably want foo(duck: Duck).

How so? Python’s Protocol and TypedDict have their limitations but are structurally typed.

> `a: int = "foo"` goes through the python interpreter without even a warning

As long as you’re validating inputs then you don’t need type validation at runtime. Input validation ensures that static types are representative of runtime types

This typing annotation system is just as half-baked as Python's class system. No, having syntax sugar for instancing "objects" that amount to new dictionaries is not an alternative to proper OOP.

And even having a "proper OOP system" means little when you have to dig knee deep in class hiararchy. Source: just had to debug a Java application today. Not my idea of fun.

Sometimes, planning stuff from the ground-up goes a long way to reducing future "code debt". Otherwise, leaving it at basics is sound enough.

Do you keep the value on the left, the value on the right, error out, try merging the values (if so: how?), add a parameter allowing the user to make that choice, require the user to pass a lambda?

I don’t think there’s a ‘best’ answer here, but if you want to make one of them easier to write as a|b, you can only support one.

And as (almost) always, Pyright has already implemented the provisional PEP!

[0] https://github.com/python/peps/pull/2620

Python has a lot of things in the standard library, though I think the tendancy has been to stop adding things (case in point: I believe there is very little argument against putting requests into the standard library. I get why they don't but I disagree with the reasoning)

The second you aren't just passing raw bytes around, you have to take into consideration what can and can't be sent between processes in Python, as some objects can't be pickled and thus can't be passed between processes.

You can concurrently load a lot more coroutines than processes and threads, as well.

Another reason, if you're using the Trio async library, is that managing and cancelling multiple tasks is really easy, and you can be sure that none get lost. This update to Python brings some of that to core asyncio (but I'll stick with Trio for now, thanks).

This is far easier to work with than multiprocessing.

When doing, e.g. AWS work, multiprocessing is additional pain for little gain.

Maybe 3.11 will make threads less painful.

The docs even warn about this for subprocess and suggest using asyncio to avoid it, although the docs are misleading - it only busy-loops if the timeout is not None, and only when running on Mac/Linux not Windows.

Multiprocessing provides parallelism up to what the machine supports, but no additional degree of concurrency, asyncio provides a fairly high degree of concurrency, but no parallelism.

OF course, you can use them together to get both.

https://github.com/omnilib/aiomultiprocess

Second: it's not a good function to use. Checking if something is present in an array is not something you should do often and thoughtlessly. It has its uses, I agree, but in general a "dict", or if you really need an array, binary search, should be used. Where's the one liner for that in python? O wait, there isn't one. Go does have it, though, since a long time.

But it's a good thing we no longer use LoC as a measure.

Hu, says who? Says the junior developer so as not to get overwhelmed?

If you've done any kind of expertise work, digging under third party layers is a very regular exercise.

A billion requests per month is 400 requests per second. My toaster can do better than that :)

Not to say that your product isn’t capable for many use cases, but the fact that the 1krps range is something impressive in Python world is indicative of the issue: Python is not built for speed, it’s built for convenience, and increasingly it’s competing against more modern languages that offer both.

You could maybe count the import, but you'd have to do that once and could do multiple bisections, so it's amortized.

Setting the variable doesn't count because you do, of course, need a variable to perform an operation on a variable. Sorting the array also wouldn't count because you can't use binary search if the array isn't sorted.

True. However, the hardest part of the binary search algorithm is implemented through bisect, so it still saves a lot of developer time.

PHP has a long history of doing things in a "right way" that subscribes to copying whatever one language is doing for 5 years. It first did things the C way, then the Java way, then got inspired by Ruby and Javascript, etc. The features are there, but executed in very awkward ways.

Ruby as a language explicitly blesses many ways to do the same thing.

Every new release in C# seems to bring in as many features as you'd get in 4 or 5 major Python or Java releases.

I look at the Python I wrote 8 years ago and it's _fine_. Even Python 2.6 code written with large frameworks looks similar enough to modern Python. The same can't be said for Javascript, Java (Java's best practices have changed a lot since then), C++, or C#.

    >>> class C:
    ...     def __len__(self):
    ...             return 10
    ...     def __getitem__(self, i):
    ...             if i >= 10:
    ...                     raise IndexError('out of range')
    ...             return i+1
    ... 
    >>> c = C()
    >>> import bisect
    >>> bisect.bisect_left(c, 1)
    0
    >>> bisect.bisect_left(c, 4)
    3

    class Dependant:
        def __init__(
            self,
            *,
            path_params: Optional[List[ModelField]] = None,
            query_params: Optional[List[ModelField]] = None,
            header_params: Optional[List[ModelField]] = None,

Compare that to code bases like Django, Celery, Matplotlib, where it's kwargs, kwargs, everywhere and nary a type hint to speak of.

The number of open issues is due to the massive popularity of the library (46K stars) compared to the number of actual maintainers. Some actual questions on the Issues tab right now:

- How to add admin page? - Is safe to remove value from list in asyncio - Best practice to run FastAPI on Cloud Run with server port as $PORT

These are all n00b questions that could readily be answered with general-purpose resources, but this is the blight that super popular FOSS libs and their maintainers have to deal with.

My example of error handling done right would be Rust's `Result<T, E>`. There's the ? operator for syntactic sugar to propagate errors upwards. Otherwise, to skip error handling, you're generally forced to unwrap() the result, which is a noticeable smell, and it will crash your program if the operation failed (as opposed to continuing despite the error). Finally, it maintains the error code advantage of keeping the control flow explicit and visible.

We've had decades of erroneous error handling from C codebases to learn from. Frankly, it's insane that we have a modern language that still uses error codes in essentially the same way.

But the flipside is that encoding every failure condition in the type system quickly becomes unfeasible. Every allocation can fail. Every array/slice indexing can be out of bounds. Some errors might just not be recoverable at all while maintaining consistent state. Go has the null pointer problem...

That's why both Go and Rust hide certain error conditions and have a fallback mechanism (panic/recover).

There is a balance between the two idioms, and which one is right depends on the language and the facilities the type system provides.

Interesting. For me it's very much the opposite. What about them do you find confusing?

> I don't even accept, philosophically speaking, the concept of exception: there are no "exceptions" when running a program [...]

I think you're looking at it wrong. Exceptions, as implemented in the languages I know, are more about having a framework of allowing inner/library code to drop the ball and run away screaming, without making more of a mess.

But our vocabulary is full of such things. A "method" is not a particularly descriptive term given what we use it for these days, either. At the end of the day, so long as everybody knows what it is, it's not a big deal.

Conceptually, though, it can be treated as an error monad.

If you're not familiar with algebraic data types, they're well worth learning about, and not a difficult concept. Once you use a language with them, heading back to a language without them feels like developing with one hand tied behind your back.

Exceptions, aka faults, are a time-tested feature of CPUs that have been around for half a century:

https://wiki.osdev.org/Exceptions

Since messages in this channel propagates up the call stacks they are very handy to stop an application and therefore used for error handling.

But they can just as well be used for all sorts of other messaging. In base Python they are used to communicate that you’ve reached the end of an iteration.

If you’ve ever made a function that returns both a value and a status in as a tuple, chances are you are better off using exceptions to communicate the status, especially if there is a “stop” status.

Yes, but panics are intended to represent an actually exceptional situation, like dereferencing nil, or the machine running out of memory ... things that normally shouldn't happen, and from which the logic cannot easily recover.

> Error handling for an API etc usually make the most sense in a central location (

Which is doable:

    if err := couldFail(); err != nil {
        return err
    }

The old-fashioned

    if (condition):
            statement_1
    else:
            statement_2

    try:
            assert(condition)
            statement_1
    except AssertionFailed:
            statement_2

This is a way of thinking that I don't get. Yes it's fine that an IOLibrary has to be able to handle a FileDoesNotExistError condition. But from the caller POV: I clearly instructed you to open a file of some description. I expect you to return to me a handle for said file. Everything that does not match that expectation is exceptional (to the caller).

And it is that violation of expectations that is communicated by (Python's) exceptions.

No, they are not.

    func couldFail() error { /*...*/ }
    func ohNoes() {
        couldFail()
    }

This is intended. Error returns are not special; they are just another return value. Error handling by the caller includes "I don't care if there is an error". Yes, in some situations that's a bad code smell. In others, it really doesn't matter. Go puts the responsibility to decide which applies in the hands of the programmer.

To get the same effect in python, I'd have to wrap the call in

    try:
        couldFail()
    except:
        pass

Because unless the caller of foo uses a catchall, it may not actually catch the exception raised by bar. Lets say bar opens a file, and callerOfFoo says `except FileNotFoundError:` ... what if bar opens a file that exists with insufficient Permissions? Then it's `PermissionError`, and callerOfFoo won't catch it.

Sure, its possible that callerOfFoo is prepared for that, but my point is, I don't know that unless I check its code.

Your second point is dubious; I've never seen any crate use anything other than Result. Afaik, it works everywhere and is so idiomatic that if somebody suggested reimplementing it, I'd immediately question their credentials.

I agree with clumsy part, if that means error handing being more explicit.

I've personally never faced 2nd example, so I'll limit my discussion to 1st one. If you don't want to use an extra crate (anyhow/thiserror), you could always do a `map_err` which in my opinion is a superior choice as you get to know what kind of error you're dealing with and how to map it to your domain error.

In Rust you would use an Enum (a discriminated Union) for this not an Union and you wouldn't need unsafe.

Probably not very often? But they probably should?

If you're printing something, there's probably a case where you care about that being printed, and if it's not in that case, that's bad?

This also applies to logs too. Just because you're not always looking at the logs doesn't mean they're not important when you need them.

Sure, if you have some chatty logs going through a distributed logging system you might not want to crash the whole thing, and in that case you might want to ignore the exception. But this is a very fringe case.

Consider a go function foo which returns some value and an error. What can you do with that error? You mention control flow being broken by python and others, but the control flow of

    def myfunc():
        if foo():
            do_a()
        else:
            do_b()

    def myfunc():
        try:
            cond = foo()
        except:
            raise
        
        if cond:
            do_a()
        else:
            do_b()

    func myfunc() err {
        cond, err := foo()
        if err != nil {
            return err
        }
        if cond {
            do_a()
        } else {
            do_b()
        }

In exception based languages the "pass the error" case is done for you, but if you do want to retry retriable errors, you can actually use a language feature to know that. In go, you have to hope the library creator created an interface (and that all of the possible errors that could percolate up have compatible error-extension interfaces!) that includes some kind of type information, which almost no one does.

You're talking about "sensible" control flow, but go doesn't have it!