On Tuesday, October 31, 2006 12:29 PM Martin Albrecht wrote:
> ...
> Bill Page wrote:
> > I strongly support Martin's view on this.
>
> I'm confused: If I understand your suggestion above correctly you
> want every undefined name to be a variable, so e.g.
> bigfattypo would be the variable bigfattypo. As you noted this
> is not valid Python code.
No, I was confused.
> It would be something that would have to live in the preparser
> and could be pretty fragile. On the other hand you support my
> "give-me-back-my-Python-way-of-doing-things"? That sounds
> contradictory to me.
I'll choose your "give-me-back-Python..." (almost).
I had expected that providing this behaviour for variables in
Python would not be difficult. I was wrong.
>
> Basically, I'm suggesting never to create global variables implicitly
> and you suggest treating everything as a global
> variable implicitly.
>
No, not really. What I wanted was that all Python names would
be available as a new class, sort of like this:
class variable(str):
def __new__(self,val): return str.__new__(self, val)
... plus other smarter methods for variables
then by default bigfattype would have the value
bigfattypo=variable('bigfattypo')
bigfattypox=variable('bigfattypox')
etc. for all Python names not otherwise defined
And when I use bigfattypo, e.g. in
sage: p = QQ[bigfattypo]
QQ[...] would be expecting generators to be specified, not just
strings, and a coercion from variable to generators in QQ would
be provided (somewhere). But the value of bigfattypo would not
be changed. Similarly, in
sage: q1 = p(1) + bigfattypo
bigfattypo would be coerced to a generator and the result would
have p as a parent, the same as if I had typed
sage: q2 = 1 + p(bigfattypo)
But we still have
sage: q3=p(bigfattypox)
<type 'exceptions.TypeError'>: Unable to coerce variable
The new variable class could have additional methods which
might allow things like subscripted and superscripted variables
and customizable latex rendering like \alpha for alpha, etc.
--------
Anyway, it seems that because Python exceptions are "terminating"
exceptions it is not possible to intercept NameError in the way
I had anticipated. :-(
Maybe locating the name insertion so that it only occurs inside of
the variable class itself would be "ok", so for example one might
declare, like this:
sage: variable('bigfattypo','bigfattypox')
with the side-effect then that bigfattype becomes a name of a
member of the variable class.
But perhaps all of this is worrying over minor details and
William's current proposal for the default
>> ... no namespace injection and one has the
>> R.<x,y,z> = PolynomialRing(QQ,3) constructor.
is really sufficient for Sage.
Regards,
Bill Page.
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to [email protected]
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/
-~----------~----~----~----~------~----~------~--~---
