On Thu, Jun 24, 2021 at 09:19:36AM -0700, Christopher Barker wrote:
Steven, you're making a pretty good case here, but a couple questions:
1) The case of newer versions of python adding methods to builtins, like .bit_length is really compelling. But I do wonder how frequently that comes up. It seems to me on this list, that people are very reluctant to add methods to anything builtin (other than dunders) -- particularly ABCs, or classes that might be subclassed, as that might break anything that currently uses that same name. Anyway, is this a one-off? or something that is likely to come up semi-frequently in the future?
Of course there is no way of knowing how conservative future Steering Councils will be. As Python gets older, all the obviously useful methods will already exist, and the rate of new methods being added will likely decrease. But if you look at the docs for builtins: https://docs.python.org/3/library/stdtypes.html and search for "New in version" you will get an idea of how often builtins gain new methods since Python 3. Similarly for other modules.
Note also that the py2 to py3 transition was (Hopefully) an anomaly -- more subtle changes between versions make it less compelling to support old versions for very long.
Large frameworks and libraries will surely continue to support a large range of versions, even as they drop support for 2.7.
2) Someone asked a question about the term "Extension Methods" -- I assume it's "Extension attributes", where the new attribute could be anything, yes?
In principle, sure. That's a design question to be agreed upon. [...]
No -- we're not assuming Python users are idiots -- there is an important difference here:
from extensions import flatten flatten(mylist)
very clearly adds the name `flatten` to the current module namespace. That itself can be confusing to total newbies, but yes, you can't get anywhere with Python without knowing that. Granted, you still need need to know what `flatten` is, and what it does some other way in any case.
Indeed. There's nothing "very clearly" about that until you have learned how imports work and why `from... import...` is different from `import`.
Whereas:
from extensions use flatten mylist.flatten()
does NOT import the name `flatten` into the local namespace
Correct -- it "imports" it into the relevant class namespace, or whatever language people will use to describe it.
-- which I suppose will be "clear" because it's using "use" rather than a regular import, but that might be subtle. But importantly, what it has done is add a name to some particular type -- what type? who knows?
That's a fair observation. Do you think that C# uses of LINQ are confused by what is being modified when they say this? using System.Linq; Of course extension methods will be *new and different* until they become old and familiar. It may be that the syntax will make it clear not just where you are "importing" extensions from but what types will be included. That is an excellent point to raise, thank you.
In this example, you used the name "mylist", so I can assume it's an extension to list. But if that variable were called "stuff", I"d have absolutely no idea.
Yes, and we can write obfuscated variable names in Python today too :-)
And as above, you'd need to go find the documentation for the flatten extension method, just as you would for any name in a module, but somehow functions feel more obvious to me.
You're not wrong. I dare say that there will be a learning curve involved with extension methods, like any new technology. If you've never learned about them, it might be confusing to see: mylist.flatten() in code and then try `help(list.flatten)` in the interactive interpreter and get an AttributeError exception, because you didn't notice the "using" at the top of the module. But how is that different from seeing: now = time() in code and then `help(time)` raises a NameError because you didn't notice the import at the top of the module? There's a learning curve in learning to use any tool, and that includes learning to program. [...]
Are you thinking that you could extend an ABC? Or if not that, then at least a superclass and get all subclasses? I'm a bit confused about how the MRO might work there.
If ABCs use normal attribute lookup, there's no reason why extension methods shouldn't work with them. -- Steve