New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Solving simple equations #296
Comments
The colon operator was not designed to solve equations. It was introduced for type hints in PEP 484. Type annotations is not a well known feature. However, I don't think this issue fits in the context of this repository. |
I agree with @varunvora, what is the basis for this? |
Of course it wasn't designed for it :-) It's also not working. It was more meant to be a joke like the existing "Teleportation" sample. But I think it's worth mentioning this for two reasons:
Maybe I should give it a better name or make it more clear, what it actually does. What do you think? |
I see. There is a potential for errors if you do not know about type annotations. But if you look at the examples in README, this is not really a wtfpython example. Most examples show valid syntax but unexpected/counterintuitive output. The examples you described are interesting because Python should have reported this as a syntax error but instead allows it. Not really a wtf in my opinion. |
That's exactly the point, it is valid python syntax. Unfortunately the specification does not describe the semantic of the type hint. Therefore the interpreter will not complain. And yes this was really a WTF python moment for me if you will.
As stated above mypy complains with BTW in TypeScript (having a similar syntax for type annotations) the semantic of the typings are specified and the compiler complains:
|
hmm, I think type annotations can be mentioned as a part of https://github.com/satwikkansal/wtfpython#-needles-in-a-haystack- I frequently make the mistake of mixing from pydantic import BaseModel
class User(BaseModel):
user_id str
name: str
followers = int I have made mistakes like this in rush, and I have seen similar ones in code reviews. Of course, it's a valid class definition, but the outcome is unintended. And I think there might be some more subtle technical quirks that can be added as well, but I gotta read the docs for that :) And yes, type annotations not having a side-effect (for example in the case of method args of a dataclass?) by default can be an interesting thing to demonstrate, I think that the majority of Python users know this, but not all. |
您发给我的信件已经收到。我会尽快查看邮件。谢谢!
|
Hi, I have a proposal for a snippet around type annotations. Maybe the title could be a little more catchy.
▶ Solving simple equations *
Output (>= 3.6):
Nice, Python can solve simple equations!
However, it does not work when dividing by other numbers. Why?
💡 Explanation:
The colon character is not a mathematical operator but the syntax for variable annotations introduced with PEP-526. It aims to provide type hints for IDEs and other tools like mypy for more static code checks which rule out a set of common mistakes during design time already like assigning wrong type:
By the way the preferred coding style for type annotations is like you see below.This was another attempt to visual trick you in the initial example.
The text was updated successfully, but these errors were encountered: