On Nov 11, 2019, at 04:11, Random832 <[email protected]> wrote:
>
> Possible alternate mechanisms:
>
> Make any such expression implicitly call a special function named e.g.
> __matrixhook__
> - called by name, so a default in builtins and one could be set locally in a
> module or imported from numpy
> - or have the special function be installable in sys.matrixhook rather than
> based on a lexically scoped special name
This could also be a use for user-defined prefixes or suffixes:
c = a[1, 2, 3]
d = a[[1,2,3],[4,5,6]]
e = [a[1,2,3], a[4,5,6]]
This looks up the installed prefix “a” and calls its handler with the stream of
tokens, or their text, or the AST subtree, or the cooked list value. There
could even be a default handler that recommends NumPy before raising the “no
installed handler” error.
Maybe you could even do this:
f = a[1,2,3]f32
… to specify the dtype as a suffix.
And if you want to reuse most of your code in Jython with a Java array library
instead of NumPy, it could install the same affix as NumPy. And if NumPy one
day goes the way of Numeric, merging with another library into something even
better, Python wouldn’t be calling an obsolete library forever, it would be
calling whatever you installed.
You can create arrays, and multidimensional arrays, and even lists of arrays,
and it all seems pretty obvious to read. And I think a prefix or suffix signals
what’s going on better than whether or not there a semicolon somewhere inside.
(If there are cases where a semicolon actually helps readability rather than
being just noise, which I think may be the case for some multidimensional
arrays, especially where one of the dimensions is 1, then that wouldn’t be too
hard to allow.)
Last time user-defined affixes were discussed a few months ago, it fizzled out.
But that discussion was about strings primarily, numbers secondarily, with only
brief offhand mentions of container displays. It’s possible that affixing
displays would have fewer problems or read more compelling or just have an
advocate willing to push harder than with strings.
There are a couple of added issues, but neither one seems insurmountable.
First, if you go with tokens or text, a display is a stream of tokens rather
than a single one. Also, you’d have to figure out what to do about
comprehensions, because they’re (at least as far as the grammar) a kind of
display.
On the other hand, except for dtype example, you can already do all of this
exactly the same without changing Python just by using A(...) instead of
a[...], and I don’t think it looks that much worse.
_______________________________________________
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/RDH7KETZZUBQHBSAJLQMKDI42I4ETQQX/
Code of Conduct: http://python.org/psf/codeofconduct/
