On 8/24/07, Robert Brewer <[EMAIL PROTECTED]> wrote: > > Thomas Wouters wrote: > > > 1) It (passively) promotes supporting only simple slicing, > > as observed by the builtin types only supporting extended > > slicing many years after extended slicing was introduced > > Should that read "...only supporting simple slicing..."? > Yes :)
> The proposed solution, as implemented in the p3yk-noslice > > SVN branch, gets rid of the simple slicing methods and > > PyType entries. The simple C API (using ``Py_ssize_t`` > > for start and stop) remains, but creates a slice object > > as necessary instead. Various types had to be updated to > > support slice objects, or improve the simple slicing case > > of extended slicing. > > Am I reading this correctly, that: since the "simple C API > remains", one can still write S[3:8] with only one colon > and have it work as before? Or would it have to be rewritten > to include two colons? > No. We're just talking about the underlying object API. The methods on objects that get called. The changes just mean that S[3:8] will behave exactly like S[3:8:]. Currently, the former calls __getslice__ or __getitem__ (if __getslice__ does not exist), the latter always calls __getitem__. -- Thomas Wouters <[EMAIL PROTECTED]> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
_______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
