People say that it's good for "short scripts", but whenever I decide to write something in Python instead of TS, I'm instantly met with so many runtime type errors that I wonder how people can honestly believe lack of static typing increases productivity in these "short scripts". For instance, the second I decide to refactor, I know that even once I think I've cleaned everything up, the next few minutes will be spent running the code a few times to flush out all the type errors.
Python is not my primary language, so that could play a part in the issues I have, but if I am allowed to lose humility for a second or two: even though I primarily use TS, my Python is still, in my opinion, stronger than many of my (college student) peers. I hate to imagine all the issues a novice would face.
To be fair, I haven't used mypy in a while. I remember that being decent, but nowhere near the level of TS, in terms of both the power of the type system and the editor support.
Writing scientific/academic code and writing business application code is somewhat different, but the speed at which you can develop and maintain Python code is very high, as is the volume of aid available should you run into trouble.
I don't think there's a language out there that's both easy to initially pick up and as well supported by its community as Python. The speed at which you can develop application code is astounding, once you get the hang of it and the noise out of the way (CI/CD, code coverage, unit and integration testing, a general familiarity with the major frameworks, etc.), and the maintenance is... tolerable.
Personally, I use Python as a Bash replacement a lot, that's what I think of when I hear "short scripts." Sort of what people used to use Perl for. Pushing strings around, complicated repetitive filesystem manipulations. (And data sciencey stuff of course.)
Python it is! If it doesn't already have something in the standard library for your task, it's definitely in the PyPI. This reduces your work to importing a library and writing 5-20 lines of code.
Used to? People still do this (I should know; I'm one of them).
Static analysis tooling is excellent and type annotations only aid their accuracy.
It's my impression that developers tend to learn to love static typing if they didn't cut their teeth on a statically typed platform. It takes experience to know that certain errors can be mitigated via language features and to know how annoying those errors are when they needlessly pop up.
Unenforced explicit typing was and is still a boon for Python. Typing is often lost on developers who are still in "Hello, world!" territory and scientists who are using it as an adjunct to MATLAB. It can be a hindrance to rapid development, as well.
I'm not alone in thinking that, the creator of Python himself has devoted his recent work to adding types to Python. Is that just because he doesn't write his code "the correct way"? Does he simply know the syntax but not hoe to effectively use the language? I don't think so.
1. Love that it doesn't use structural typing, NewType seems great.
2. The syntax is bad. Maybe this is a "it just takes getting used to" thing, but I actually find it really bad. In TS, the syntax for typing almost always directly matches the syntax for the rest of the language. In Python, its a weird sort of LISPy DSL think that they made... compare:
Py: Callable[[List[Tuple[int, string]], Dict[string, string]], int]
TS: ([number, string][], { [key: string]: string }) => int
3. Admittedly, the TS dict syntax isn't beautiful, but it becomes very helpful for things like `{ [K in keyof T]: K extends number ? T[K] : never }`, which does not seem to be possible in Py.
4. Related to 3, but no never type? I see NoReturn, but it does not seem to actually cause any errors when you try to assign it to a variable. See below.
5. Type narrowing... does it exist? Seemingly not, see below.
6. Literals as types (enums)?
7. Generics, do I really need to pass in the internal representation of the type I'd like to use? That seems absurd. Will bad things happen if these internal identifiers collide? (Reference: `T = Generic('T')` creates a generic type)
Demo code that should throw an error at the assertUnreachable and nowhere else, but actually throws errors everywhere but the assert unreachable (types seemingly aren't narrowed by `type() == ...` checks):
def foo(x: Union[str, int, float]):
if (type(x) == int):
return x / 3
if (type(x) == str):
return x.upper()
return assertUnreachable()
def assertUnreachable() -> NoReturn:
raise RuntimeError('no way')
When you say type narrowing do you mean floats should be automatically interpreted as int? There is typing.{SupportsInt, SupportsFloat} which can be considered "number" base classes which you may consider as type narrowing. Otherwise if you mean "type of x is known in this if-block" you do get that with `isinstance` type checks (which is the preferred, pythonic way).
I agree that mypy should warn if a NoReturn is assigned; apparently it just ignores typechecking below the NoReturn function call, and is really only used to ensure the NoReturn function is guaranteed to raise before it returns.
3 and 4 are disappointing though.
0: I'm assuming the extra [ after Callable is a typo.
The extra [ is not a typo, the syntax is: `Callable[[Arg1Type, Arg2Type], ReturnType]`. Or, if the arguments don't matter, `Callable[..., ReturnType]`, but this does not mean that the type is not a valid expression.
Edit: I was missing a ] actually, separating the arguments from the return value.
Well somewhat[0], but the main putative benefit would be having types be valid expressions in the target language, since you can do type-checking with function decorators, and generally interact with types useing the normal language mechanism for interacting with values, rather than some horrid bolted-on piece of crap like C++ templates.
Server = Tuple[Address,ConnectionOptions] # array subscipt might not the best choice here, but it works
UserId = NewType('UserId',int) # ordinary function call
Scalar = int | str # could be equivalent to Union[int,str] with appropriate value of Type.__or__
def intBit(N):
if N==0: return type(None)
if N==1: return Bool
if N>INT_WIDTH: return long
return int error:invalid type comment or annotation
note:Suggestion: use intBit[...] instead of intBit(...)
And even if the code were valid, it's relying on N being a statically known value, which is a bit off because sure, you could have N be some global const config variable, but it would be very weird for configuring the value of the variable to require you to also go into the code and change things around to work with bool's or None's instead of int's.
Yeah, that sounds about par for the course for bolt-on static-y typing in languages that aren't supposed to be statically typed.
Combined with aiohttp-json-rpc I had a very effective websocket-based JSON RPC backend service up and running in a very short time and with very little boilerplate. I'll be using this pattern again for sure.
What would have been the advantage of me using Sanic instead (I haven't RTFM for sanic yet but I'm about to...)?
Sanic also makes performance a key development goal so you can feel comfortable the project will scale gracefully. But I will stress I don't have current benchmarks to compare against aiohttp
With aiohttp you can make neat things it is operating a level below Sanic - in my experience people end up writing their own half-baked undocumented framework based on a combination of aiohttp, some ORM and a template engine - sometimes with half a dozen combinations in the same company.
This is how we get to async Django, and I think that's part of why Tom Christie is helping out. I also doubt Reitz thinks this is the usurper of Django anyway. It's more than an experiment, but less than "the new One True Way".
As for ASGI python web frameworks, there are no mature winners in the space yet (compare uvicorn's quickstart example to this project's before you throw that project out as an example). This is Truly New Shit, and I'm pumped these two devs are working on it together.
For example, I'd like to see Python's async frameworks building on ASGI middleware rather than all re-writing their own middleware APIs. That way we end up with lots of cross-framework compatible middleware implementations, and we're all working together much more coherently.
Similarly for test clients. We don't really need frameworks to all be building their own individual test clients to interact against their own interfaces, when we can instead build test clients to interface against ASGI, and then be able to use them against any ASGI framework.
That's part of what the Starlette project (which Responder uses) is all about: https://www.starlette.io/
(FWIW Starlette also composes all those bits and pieces into a framework in its own right)
From what I understand ASGI was developed by Andrew Godwin for Django Channels.
But just thinking about my own experiences, being able to look at what other people have done so far with it would help immensely when building the nuts and the bolts of the feature. This project will help immensely with that.
It seems that Tornado is now offering the choice of its own event loop or the asyncio event loop. I built something recently in aiohttp because it felt like it had been built on asyncio from the ground up but will explore Tornado again.
By django like I meant a batteries included framework with an integrated async ORM, auth, DRF and etc. From what I've seen we'll probably have to wait for django to get there, which might take a few years.
Perhaps... Maybe ... its because I have been "cheating" on Python with JS. I mean, it is a pain in the booty to code up a web app in python without JS. Try to code a mobile app with Python and Kivy... not all that fun (not practical). In less than a week with React, I have done both. So... why not just skip Python all together? I have been asking myself that question.
Bottom line: The authors of this "service framework" states the Python world doesn't need another web framework, I agree.
It needs some serious love in GUI land.