Does Python compete with Java?

["Martin v. Löwis"]

Jakub Fast wrote:
  > would having the possibility of using
> 
> def static mymethod():
> 
> instead of the standard = staticmethod(...) do anything bad to python as 
> it is? 

In Python, people actually use static methods much less frequently than
in, say, Java - there is absolutely no problem with having global
functions (rather than class-static methods) most of the time. This is
partially due to the fact that static methods did not exist for a long
time.

However, this issue is being considered. Most likely, the new syntax
will read

     [staticmethod]
     def mymethod():
         ...

The debate is only about where the [staticmethod] should go. Solutions
introducing new keywords are not acceptable. See PEP 318 for details

 > Same question goes for something along the lines  of
> __operator__['='] (self, etc).

Overloading assignment will never happen, for two reasons:
- assignment is not an operator, but a statement
- assignment does not modify an object, atleast not in the
   form

     variable = value

   (in the form object.variable=value, it does modify object,
   and you can overload the assignment by implementing __setattr__
   or using by using properties)

> On quite another note, is it possible to define your own operators in 
> python?

No, it isn't. People would not like it because it looks like line noise.

> nothing can beat 
> the intuitive appeal of
> 
> S ==> (NP and VP) or VP
> 
> over CFGProduction(S, NP, VP), CFGProduction(S, VP) for specifying your 
> simple cfg, dcg or ebnf rules if you're completely new to programming 
> and have just been given a programming assignment :)

With several years of computing experience, I cannot understand neither
notation without some background. They look like a logical implication
to me, but I'm uncertain whether you are aiming at an assertion to be
tested, or merely at the grammatical structure.

If it is the structure, you should be able to write this as

   S.implies(NP.and_(VP).or_(VP))

(assuming I have the grouping of your logical notation right - I have
troubles guessing whether ==> or `or´ should have higher precedence)

Regards,
Martin