There is the (obscure) Ellipsis object that, only in the context of a multi-dimensional slice list, is represented by '...' (exactly three dots). Exactly two subsequent dots is illegal.
I don't think there is a suitable binary operation to hijack, however I think '[' expr1 [,]..[,] expr2 ']' # the commas here are optional, and expr doesn't contain unbalanced strings or un-quoted brackets (not regex, but easy to check). could be easily and reliably pre-parsed into something like "sage_range(expr, Ellipsis, expr2)" Note that "[1,2,3,..,10]" would get turned into "sage_range(1,2,3, Ellipsis,10)" which would then return [1,2,3,4,5,6,7,8,9,10]. Using the same logic, there would be no need to limit an expression to a single Ellipsis, e.g. "[1..4,6..10]" would be "sage_range(1,Ellipsis, 4,6,Ellipsis,10)" = [1,2,3,4,6,7,8,9,10]. We could even let sage_range(2,4,...,10) = [2,4,6,8,10]. A similar expression in ()'s would yeild a generator (and could even lack an upper bound). - Robert On Sep 17, 2007, at 9:39 PM, Mike Hansen wrote: > Yeah, I'm not sure if the benefits would be worth breaking such a > strong Python convention. I'd rather have consistency since it > appears so often in other places. > > I'd vote against. > > --Mike > > On 9/17/07, Nick Alexander <[EMAIL PROTECTED]> wrote: >> >>> Robert, Since you do so much work on Cython, maybe you could think >>> about the formal specification of the Python language and see >>> whether >>> .. >>> not appearing in a string is ever valid Python. I.e., could we add >>> [expr1 .. expr2] >>> to the language without running into problems? >> >> Much like generators (K.<x>), this cannot be added to the preparser >> without parsing arbitary python expressions (expr1 and expr2 in this >> case). At the moment, you can make the preparser barf and it would >> be a great deal of work to fix. Are we willing to do another >> "correct 90% of the time" hack? If this is considered very valuable, >> I suggest we hijack a Python binary operator and repurpose it. Or we >> could uniformly preparse '..' to be that redefined operator; that >> would be better. >> >> I vote against. >> >> Nick >> >> >> >> >>> >> > > --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~----------~----~----~----~------~----~------~--~---
