4 ms·

I don't like the idea of introducing a new keyword. We need a backward compatible solution. I feel like Python needs some kind of universal annotation syntax su

• Alir3z4 1y ago
  Me neither. Introducing new keyword has become a recent thing in Python. Seems Python has a deep scare since Python2 to Python3 time and is scared to do anything that causes such drama again. For me, the worst of all is "async". If 2to3 didn't cause much division, the async definitely divided Python libraries in 2. Sync and Async. Maybe if they want backward compatible solution, this can be done by some compile or runtime flag like they did with free threading no-gil.
  • sigmoid10 1y ago
    Async or not in modules is a huge pain in the ass for web-dev, but thankfully a lot of Python still isn't web dev. As a Data Scientist you can live your life peacefully without ever worrying about this. But I can see why web devs like it, even though personally I really don't want to see anymore Javascript sneaking inty my Python. Especially when there is already support for IO bound concurrency elsewhere in the language. If I want to do JS syntax, I'll fucking use JS. And I really don't want to see Python go the C++ route where it just wants to be everything and do everything so that you end up with so many possible approaches to the same problem that two devs can't read each others code anymore.
    • vvpan 1y ago
      I'm relatively new to Python - how does one do concurrent IO without async/await? My main complaint, though, about Python async is - because it is opt-in I never know if I forgot a sync IO call somewhere that will block my worker. JS makes everything async by default and there is effectively no chance of blocking.
      • blibble 1y ago
        take your pick: threads, fork, non-explicit coroutines (gevent), io multiplexing (select/poll/epoll/kqueue), virtual threads/goroutines
      • baq 1y ago
        The same way you always did it: sync io in threads. Caveats are similar to async/await, but stack traces don’t suck.
  • BiteCode_dev 1y ago
    Async was a soft keyword for many, many years in order to maintain compat. And before that, asyncio used yield to be even more compatible. They took a decade to solidify that. At some point, you have to balance evolution and stability. For a language as popular as Python, you can not break the world every week, but you can't stay put for 5 years.
• ashu1461 1y ago
  Not sure if this can be made backward compatible. Right now all the imports are getting resolved at runtime example in a code like below from file1 import function1 When you write this, the entire file1 module is executed right away, which may trigger side effects. If lazy imports suddenly defer execution, those side effects won’t run until much later (or not at all, if the code path isn’t hit). That shift in timing could easily break existing code that depends on import-time behavior. To avoid using lazy, this there is also a proposal of adding the modules you want to load lazily to a global `__lazy_modules__` variable.
  • bkettle 1y ago
    I think they mean backwards-compatible syntax-wise, rather than actually allowing this feature to be used on existing code. If I’m understanding correctly they would prefer for the Python grammar to stay the same (hence the comment about updating parsers and IDEs). But I don’t think I really agree, the extensible annotation syntaxes they mention always feel clunky and awkward to me. For a first-party language feature (especially used as often as this will be), I think dedicated syntax seems right.
  • f311a 1y ago
    I was talking about syntax. I'm pretty sure there will be new features that will require a new keyword or syntax given the speed of Python growth. It can be universal, for example same as decorator, but it can be applied anywhere. from lazy import make_lazy from package import module @make_lazy @local @nogil Let's say this syntax gets introduced in Python 3.16. The @nogil feature can be introduced in 3.17. If such code is running in Python 3.16, the @nogil marker will be ignored. The problem with new keywords is that you have to stick to the newest Python version every time a new keyword is added. Older Python versions will give a syntax error. It's a big problem for libraries. You need to wait for 3-5 years before adding it to a library. There are a lot of people who still use Python 3.8 from 2019.
    • ashu1461 1y ago
      Understood make sense
• baq 1y ago
  Yeah I like the feature but hate the keyword. Dunder lazy imports sounds good enough imho.
• BiteCode_dev 1y ago
  They thought about backward compatibility, and offer an alternative syntax that use no keyword for library that want to activate it yet stay compact with old version. It's already in the spec.