[prev in list] [next in list] [prev in thread] [next in thread] 

List:       python-ideas
Subject:    Re: [Python-ideas] str(slice(10)) should return "slice(10)"
From:       Nick Coghlan <ncoghlan () gmail ! com>
Date:       2016-11-14 13:35:02
Message-ID: CADiSq7cxQmjexBSVjUZRMg=2-7aD_=cPfj5xbb5Aw2Nb0AU8CA () mail ! gmail ! com
[Download RAW message or body]

On 13 November 2016 at 21:25, Ivan Levkivskyi <levkivskyi@gmail.com> wrote:
> This reminds me @ vs .dot() for matrix multiplication a bit. Pandas has
> IndexSlicer, NumPy has index_exp, etc. I think it would be nice to have a
> simple common way to express this.
> But here we have an additional ingredient -- generic types. I think that a
> reasonable compromise would be to simply continue the way proposed in
> http://bugs.python.org/issue24379 -- just add operator.subscript for this
> purpose. Pros:
> * subscript is not a class, so that subscript[...] will be not confused with
> generics;
> * this does not require patching built-ins;
> * all libraries that need this will get a "common interface" in stdlib,
> operator module seems to be good place for this.

From an educational point of view, it also makes it a bit easier to
give interactive examples of how slicing syntax maps to the subscript
parameter on __getitem__, __setitem__ and __delitem__: you can just do
"print(operator.subscript[EXPR])" rather than having to build a dummy
__getitem__ implementation of your own.

If an actual use case is found for it, that approach would also leave
"operator.subscript('EXPR')" available for a micro-eval implementation
that evaluated a given string as a subscript rather than as a normal
top level expression.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan@gmail.com   |   Brisbane, Australia
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
[prev in list] [next in list] [prev in thread] [next in thread]