91–100 of 236 posts
lazy from typing import Iterator
def stream_events(...) -> Iterator[str]: while True: yield blocking_get_event(...)
events = stream_events(...)
for event in events: consume(event)
Earlier quoted context omitted.
Ah, thanks for the update. My only check before asking was to check if the future feature for annotations had been enabled by default yet. It has then effectively been abandoned instead, I guess.
Yup, "from __future__ import annotations" will eventually be removed: > from __future__ import annotations (PEP 563) will continue to exist with its current behavior at least until Python 3.13 reaches its end-of-life. Subsequently, it will be deprecated and eventually removed.
Earlier quoted context omitted.
3.15: https://docs.python.org/3.15/whatsnew/3.15.html#whatsnew315-...
> When an AttributeError on a builtin type has no close match via Levenshtein distance, the error message now checks a static table of common method names from other languages (JavaScript, Java, Ruby, C#) and suggests the Python equivalent Oh, that is such a nice thing.
The example:
>> 'hello'.toUpperCase()
Traceback (most recent call last):
...
AttributeError: 'str' object has no attribute 'toUpperCase'. Did you mean '.upper'?Earlier quoted context omitted.
If you’re asking some some kind of abstract moral value sense, I have idea. If you’re asking whether project leads give more weight to a single, tangible, vocal stakeholder than they do to unknown numbers of anonymous and lightly-engaged stakeholders? Yes.
Not to mention when the single, tangible, vocal stakeholder can also be asked to be responsible for documentation (PEPs, etc) and PRs. Especially in open source there is a huge difference between "a lot of people asked about this" and "one person asked about this, but was passionate enough about it and open enough to following the process and the feedback loops to champion it all the way across the finish line".
Earlier quoted context omitted.
Lambdas are intentionally kneecapped in python because Guido van Robson doesn't want to make a functional language. (As in "functional programming", not that it doesn't work.)
Guido van Rossum didn't oppose functional programming, but he wanted to keep the language (and the interpreter) simple.
"I don't think it makes much sense to try to add "functional" primitives to Python, because the reason those primitives work well in functional languages don't apply to Python, and they make the code pretty unreadable for people who aren't used to functional languages (which means most programmers). I also don't think that the current crop of functional languages is ready for mainstream." https://developers.slashdot.org/story/13/08/25/2115204/inter...
Earlier quoted context omitted.
IMO the main reasons people use Python are: 1. The very first steps are quite simple. Hello world is literally just `print("hello world")`. In other languages it can be a lot more complex. 2. It got a reputation as a beginner-friendly language as a result. 3. It has a "REPL" which means you can type code into a prompt and it will execute it interactively. This is very helpful for research (think AI) where you're tryi…
I think "Python is slow" is reductive and frankly just as useful as saying "Python begins with a 'P'". The story is more complicated than simply speed of execution. Choosing a language is a game of trade-offs: potentially slower execution in return for faster development time, for example. If your team is already familiar with Ruby, will asking them to write a project in Rust necessarily result in a better product? M…
Earlier quoted context omitted.
Yup, "from __future__ import annotations" will eventually be removed: > from __future__ import annotations (PEP 563) will continue to exist with its current behavior at least until Python 3.13 reaches its end-of-life. Subsequently, it will be deprecated and eventually removed.
So the future behavior is deprecated before it ever became the default?
Ironically, the new default behavior (making type annotation evaluation lazy) is not backwards compatible with the "from __future__ import annotations" behavior of converting annotations to strings, so they can't just rip out "from __future__ import annotations" and instead it needs to be deprecated and removed over multiple releases.
Oh, what tangled webs we weave! :-)
Earlier quoted context omitted.
the funny thing is that everyone, including myself, posited that python would be the winner of the ai coding wars, because of how much training data there is for it. My experience has been the opposite.
I felt the opposite, because Python isn’t a great language. It won because of Google, fast prototyping, and its ML interop (e.g. pandas, numpy), but as a language it’s always been subpar. Indentation is a horrible decision (there’s a reason no other language went this way), which led to simple concepts like blocks/lambdas having pretty wild constraints (only one line??) Type decoration has been a welcome addition, bu…
I will never understand why people are upset about this.
You HAVE multi-line lambdas. They're called functions.
Yeah, I know you want a function that's only used once to be able to be defined in-line, but tbh I've always found that syntax to be pretty ugly, especially once you're passing two functions to a single call, or have additional parameters AFTER the function (I'm looking at you, setTimeout/setInterval).
Earlier quoted context omitted.
Yup, "from __future__ import annotations" will eventually be removed: > from __future__ import annotations (PEP 563) will continue to exist with its current behavior at least until Python 3.13 reaches its end-of-life. Subsequently, it will be deprecated and eventually removed.
So the future behavior is deprecated before it ever became the default?
But this is a "...will continue to exist with its current behavior at least..." is an important bit there.
From pep-0749:
Sometime after the last release that did not support PEP 649 semantics (expected to be 3.13) reaches its end-of-life, from __future__ import annotations is deprecated. Compiling any code that uses the future import will emit a DeprecationWarning. This will happen no sooner than the first release after Python 3.13 reaches its end-of-life, but the community may decide to wait longer.
Earlier quoted context omitted.
> When an AttributeError on a builtin type has no close match via Levenshtein distance, the error message now checks a static table of common method names from other languages (JavaScript, Java, Ruby, C#) and suggests the Python equivalent Oh, that is such a nice thing.
It's unrelated to the lazy keyword. Instead it's another feature related to error messages. The example: >> 'hello'.toUpperCase() Traceback (most recent call last): ... AttributeError: 'str' object has no attribute 'toUpperCase'. Did you mean '.upper'?
I really appreciate them going out of their way to do this, being quite aware of the hidden complexity in doing it.