181–190 of 460 posts
Earlier quoted context omitted.
Whenever I nest a list comprehension I feel dirty anyway, I wonder if a better error message will help solve something that is just hard to grasp sometimes.
All list comprehensions should error with message "FATAL PARSE ERROR: Will you really understand this in six months?"
Earlier quoted context omitted.
> I find asyncio to be horrendous, both because of the silliness of its demands on how you build your code and also because of its arbitrarily limited scope. Do you compare it to threads and pools, or judge it on its merits as an async framework (with you having experience of those that you think are done better elsewhere, e.g. in Javascript, C#, etc)? Because both things you mention "demands on how you build your co…
> Because both things you mention "demands on how you build your code" and "limited scope" are part of the course with async in most languages I don't see how "asyncio is annoying and can only be used for a fraction of scenarios everywhere else too, not just here" is anything other than reinforcement of what I said. OS threads and processes already exist, can already be applied universally for everything, and the poo…
Well, I didn't try to refute what you wrote (for one, it's clearly a personal, subjective opinion).
I asked what I've asked merely to clarify whether your issue is with Python's asyncio (e.g. Python got it wrong) or with the tradeoffs inherent in async io APIs in general (regardless of Python).
And it seems that it's the latter. I, for one, am fine with async APIs in JS, which have the same "problems" as the one you've mentioned for Python's, so don't share the sentiment.
Earlier quoted context omitted.
That's because the core team wasn't friendly to them making changes in CPython. Not because they deliberately only wanted to build an alternative interpreter.
That's absolutely not the case with IronPython, where being tied to the .NET ecosystem was very much the point. But if it was just core-team resistance and not a more fundamentally different objective than just improving the core interpreter performance, maintaining support for native extensions while speeding up the implementation would have been a goal even if it had to be in a fork. They were solving a fundamental…
That might very well be, but I talked about UnladdedSwallow and such "native" attempts.
Not attempts to port to a different ecosystem like Jython or IronPython or the js port.
>maintaining support for native extensions while speeding up the implementation would have been a goal even if it had to be in a fork.
That's not a necessary goal. One could very well want to improve CPython, the core, even if it meant breaking native extensions. Especially if doing so meant even more capabilities for optimization.
I, for one, would be fine with that, and am pretty sure all important native extensions would have adapted quite soon - like they adapted to Python 3 or the ARM M1 Macs.
In fact, one part of the current proposed improvements includes some (albeit trivial) fixes to native extensions.
Earlier quoted context omitted.
When you only have so many hours to go around, you concentrate on the main goals.
My point is that you can write fast code just as easily as you can write slow code. So engineers should write fast code when possible. Obviously you can spend a lot of time making things faster, but that doesn't mean you can't be fast by default.
I think some people can do this and some can't. For some, writing slow code is much easier, and their contributions are still valuable. Once the bottlenecks are problems, someone with more performance-oriented skills can help speed up the critical path, and slow code outside of the critical path is just fine to leave as-is.
If you somehow limited contributions only to those who write fast code, I think you'd be leaving way too much on the table.
Earlier quoted context omitted.
When is that coming? Yes the error messages are confusing in a big list comprehension.
Whenever I nest a list comprehension I feel dirty anyway, I wonder if a better error message will help solve something that is just hard to grasp sometimes.
Although, personally, I enjoy python list comprehensions.
Earlier quoted context omitted.
> Because both things you mention "demands on how you build your code" and "limited scope" are part of the course with async in most languages I don't see how "asyncio is annoying and can only be used for a fraction of scenarios everywhere else too, not just here" is anything other than reinforcement of what I said. OS threads and processes already exist, can already be applied universally for everything, and the poo…
> I don't see how "asyncio is annoying and can only be used for a fraction of scenarios everywhere else too, not just here" is anything other than reinforcement of what I said. Well, I didn't try to refute what you wrote (for one, it's clearly a personal, subjective opinion). I asked what I've asked merely to clarify whether your issue is with Python's asyncio (e.g. Python got it wrong) or with the tradeoffs inherent…
Both, but the latter part is contextual.
> I, for one, am fine with async APIs in JS
Correct me if you think I'm wrong, but JS in its native environment (the browser) never had access to the OS thread and process scheduler, so the concept of what could be done was limited from the start. If all you're allowed to have is a hammer, it's possible to make a fine hammer.
But
1. Python has never had that constraint
2. Python's asyncio in particular is a shitty hammer that only works on special asyncio-branded nails
and 3. Python already had a better futures interface for what asyncio provides and more before asyncio was added.
The combination of all three of those is just kinda galling in a way that it isn't for JS because the contextual landscape is different.
Earlier quoted context omitted.
> Inlined python functions are called in pure python without needing to jump through C Given that Python is interpreted, it's quite unclear what this could mean. Also, what does it mean to "call" an inlined function?? Isn't the point of inline functions that they don't get called at all?
> Given that Python is interpreted, it's quite unclear what this could mean. Python is compiled. CPython runs bytecode. (If Python is interpreted, then so is Java without the JIT).
This is really incredible work. The "What's New" page has an item-by-item breakdown of each performance tweak and its measured effect[1]. In particular, PEP 659 and the call/frame optimizations stand out to me as very clever and a strong foundation for future improvements. [1]: https://docs.python.org/3.11/whatsnew/3.11.html
One of the biggest features I'm looking forward to is the more specific error messages. I can't tell you how much time I've wasted with cryptic errors that just point to a line that has a list comprehension or similar.
When is that coming? Yes the error messages are confusing in a big list comprehension.
Cool improvement but changes very little when Python is x100 times slower than other GC languages.
It will still improve the data center power bill of thousands of companies, while saying to them "just Rewrite it in Rust" will not.
Does not sounds like Rust.
(But other than that I agree with your point.)