4 ms·

Longtime pythonista and co-organizer of PyATL here. I appreciate the goals of the library and understand the points being made in the code. There are certain th

Longtime pythonista and co-organizer of PyATL here. I appreciate the goals of the library and understand the points being made in the code. There are certain things that python has acquired over time that are not as nice as they could be. Or maybe we can say that momentum to improve them reduces over time. One of these things is the __init__ method. It is not named in a clear manner and can be verbose. The alternative proposed with store_attr is close, but still falls to be descriptive. Ideally, I'd just adopt the keyword "constructor" or "initialize" and have it be synthathic sugar for __init__. I do like the fact that it provides a shorter way to initialize things. That could be adopted with no drawbacks as long as we keep named parameters. I congratulate and welcome such ideas. Ill invite the library author(s) to join the python core team and discuss the ideas with them. It can take time to get new things into a project like python, but we cant grow a language by doing the same thing over and over. Languages need to evolve (to a certain extent) over time.

jph00 6y ago
Thanks for the message! The challenge here is that fastcore is a deliberate attempt to study the design axis of "what would happen if we focused on Python's dynamic features, and gave up on static analysis entirely". Using it effectively really requires a live coding environment, such as Jupyter Notebooks (which we do all our coding in, using nbdev). The majority of Python programmers are not currently using such an environment. In addition, some of the design choices are literally working around Python design choices which we disagree with, such as the recent change in Python where StopIteration is converted to a RuntimeException, which broke all of our composition of generators. There are some things, however, which might fit into Python, such as: - Our ProcessPoolExecutor takes `0` as max_workers, to mean "run in serial", which we find very helpful for debugging - Something like our `bind` (but less hacky) would be nice - Multiple dispatch would be great (although our version is customized for data processing - a generic python one would be a little different I think) - Would be nice if `partial`'s repr showed the original docstring - Our `delegates` decorator might be worth stealing
- pryelluw 6y ago
  Appreciate the response. Would it be OK if I reach out through email? Id like to extend a friendly professional relationship between fast.ai and PyATL. My email is in my profile :)

jph00 6y ago

Thanks for the message! The challenge here is that fastcore is a deliberate attempt to study the design axis of "what would happen if we focused on Python's dynamic features, and gave up on static analysis entirely". Using it effectively really requires a live coding environment, such as Jupyter Notebooks (which we do all our coding in, using nbdev). The majority of Python programmers are not currently using such an environment. In addition, some of the design choices are literally working around Python design choices which we disagree with, such as the recent change in Python where StopIteration is converted to a RuntimeException, which broke all of our composition of generators. There are some things, however, which might fit into Python, such as: - Our ProcessPoolExecutor takes `0` as max_workers, to mean "run in serial", which we find very helpful for debugging - Something like our `bind` (but less hacky) would be nice - Multiple dispatch would be great (although our version is customized for data processing - a generic python one would be a little different I think) - Would be nice if `partial`'s repr showed the original docstring - Our `delegates` decorator might be worth stealing

pryelluw 6y ago
Appreciate the response. Would it be OK if I reach out through email? Id like to extend a friendly professional relationship between fast.ai and PyATL. My email is in my profile :)