On 2018-06-13 23:37, Chris Angelico wrote:
str.re can be a descriptor object which "knows" which string
instance it is bound to. This kind of thing is common in many libraries.
Pandas for example has all kinds of things like df.loc[1:3],
df.column.str.startswith('blah'), etc. The "loc" and "str" attributes give
objects which are bound (in the sense that bound methods are bound) to the
objects on which they are accessed, so when you use these attributes to do
things, the effect takes account of on the "root" object on which you
accessed the attribute.
Personally I think this is a great way to reduce namespace clutter
and group related functionality without having to worry about using up all
the short or "good" names at the top level. I'm not sure I agree with the
specific proposal here for allowing regex operations on strings, but if we
do do it, this would be a good way to do it.
How is this materially different from:
"some string".re_match(...)
? It's not a grouped namespace in any technical sense, but to any
human, a set of methods that start with a clear prefix is functionally
a group.
Do you really mean that? :-)
As far as I can see, by the same argument, there is no need for
modules. Instead of math.sin and math.cos, we can just have math_sin
and math_cos. Instead of os.path.join we can just have os_path_join.
And so on. Just one big namespace for everything. But as we all know,
namespaces are one honking great idea!
Now, of course there are other advantages to modules (such as being
able to save the time of loading things you don't need), and likewise
there are other advantages to this descriptor mechanism in some cases.
(For instance, sometimes the sub-object may want to hold state if it is
going to be passed around and used later, rather than just having a
method called and being thrown away immediately.) But I think it's
clear that in both cases the namespacing is also nice.
--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is no
path, and leave a trail."
--author unknown
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
