"no variable or argument declarations are necessary."

[Paul Rubin]

Brian Quinlan <brian at sweetapp.com> writes:
> OK. The Python compiler would check that the name is declared but it
> would not check that it is defined before use? So this would be
> acceptable:
> 
> def foo():
>      local x
>      return x

Come on, you are asking silly questions.  Any reasonable C compiler
would flag something like that and Python (with the flag set) should
do the same.  If you want to ask substantive questions, that's fine,
but stop wasting our time with silly stuff.

> > XML_NAMESPACE would be declared in the xml.dom module and the type
> > info would carry over through the import.
> 
> 1. your type checking system is optional and xml.dom does not use it

If type checking is implemented then the stdlib should be updated to
add declarations for public symbols.  If not, the compiler would flag
the undeclared symbol.  You could always declare it to be of type 'object'.

>      try:
>           unicode
>      except NameError:
>           XML_NAMESPACE<str> = "..."
>      else:
>           XML_NAMESPACE<unicode> = u"..."

This wouldn't be allowed.

> 2. the compiler does not have access to the names in other modules anyway

You're being silly again.  The compiler would examine the other module
when it processes the import statement, just like it does now.

> How would you find the class definition for the Node object at
> compile-time? 

By processing the xml.dom module when it's imported.

> And by "slots" do you mean the existing Python slots concept or
> something new?

Probably something new, if the existing concept is incompatible in some way.

> So only pre-defined slotted attributes would be accessable (if the
> object uses slots). So the following would not work:
> 
> foo = Foo() # slots defined
> foo.my_attribute = 'bar'
> print foo.my_attribute

Yes, correct, many people already think the existing __slots__
variable is intended for precisely that purpose and try to use it that
way.  Note you can get the same effect with a suitable __setattr__
method that's activated after __init__ returns, so all we're
discussing is a way to make the equivalent more convenient.