PEP318 alternate syntax idea

[Stephen Horne]

It just occurred to me that if decorators really catch on, there could
be cases where they are applied repeatedly to many functions, and
possibly with many decorators. Combine that with many (and variable
numbers of) parameters per function and readability could be seriously
hit.

In C++, the 'private', 'public' and 'protected' modifiers for class
members are not applied individually to every single member. This
always struck me as being a good thing, and it irritates me that in C#
and java every single definition needs to specify it's visibility.
Yes, there's a default, but you still often get a lot of definitions
that don't match the default. Some classes present a lot of public
member functions as their interface, for instance.

If I were inventing a language, I would allow more modifiers to be
moved away from the definitions/declarations to some kind of preamble.
In C++, for instance, it bugs me if I have to individually declare
each of a group of members to be static, or mutable, or whatever.

With that in mind, how about...

def [staticmethod, ...] :
# could use alternate keyword such as 'decorate'

def a (a1, a2) :
"this function is decorated"
...

def b (b1, b2) :
"this function is also decorated"
...

def c (c1, c2) :
"this function is _not_ decorated"
...
--
Steve Horne

steve at ninereeds dot fsnet dot co dot uk

[Ville Vainio]

>>>>> "Stephen" == Stephen Horne <st***@ninereed s.fsnet.co.uk> writes:

Stephen> It just occurred to me that if decorators really catch
Stephen> on, there could be cases where they are applied
Stephen> repeatedly to many functions, and possibly with many
Stephen> decorators. Combine that with many (and variable numbers
Stephen> of) parameters per function and readability could be
Stephen> seriously hit.

d = publishdecorato r

def f() [d]:
pass

def g() [d]:
pass

d = hidedecorator

def f2() [d]:
pass

def g2() [d]:
pass

--
Ville Vainio http://tinyurl.com/2prnb

[Stephen Horne]

On 23 Mar 2004 12:08:01 +0200, Ville Vainio <vi***@spammers .com>
wrote:

>> "Stephen" == Stephen Horne <st***@ninereed s.fsnet.co.uk> writes:

Stephen> It just occurred to me that if decorators really catch
Stephen> on, there could be cases where they are applied
Stephen> repeatedly to many functions, and possibly with many
Stephen> decorators. Combine that with many (and variable numbers
Stephen> of) parameters per function and readability could be
Stephen> seriously hit.

d = publishdecorato r

def f() [d]:
pass

Do we really want people writing...

d = lambda x : staticmethod (someotherdecor ation (whateverdeco (x))

def f() [d] :
pass
--
Steve Horne

steve at ninereeds dot fsnet dot co dot uk

[Ville Vainio]

>>>>> "Stephen" == Stephen Horne <st***@ninereed s.fsnet.co.uk> writes:

Stephen> Do we really want people writing...

Stephen> d = lambda x : staticmethod (someotherdecor ation (whateverdeco (x))

Probably not - but the 'as' syntax should accept any iterable, so it
could be

d = [d1, d2, d3]

or with currently proposed syntax

d = functional.comp ose([d1,d2,d3])

Which just needs the not-yet-implemented 'functional' module :-).

--
Ville Vainio http://tinyurl.com/2prnb

[Marco Aschwanden]

Python has the concept that names with a preceding underscores (__) will
be mangled in some way. I suppose the "compiler"/interpreter does this
name-mangling. Why not use the same concept:

def __static__theRe alFunctionName( self, var1, var2):
pass

The compiler will do some name mangling. The function is called without
the __static__ part:

--> theRealFunction Name(3,4)
The advantages:

- Old code won't break (except if someone has functions starting with
__static__).
- It is an already used concept for "private" variables --> they might be
migrated to __private__
- well they even might be joined:
__static____pri vat__theRealFun ctionName(...)
- don't use it if you don't need it (this probably defaults to a
__public__)
- The definition tells us what kind of method (class?) this is

The disadavantage:
- long names

Stupid idea? I guess so, but I am too stupid to see why?

Bye,

Marco

[Peter Harris]

Ville Vainio wrote:

d = functional.comp ose([d1,d2,d3])

Which just needs the not-yet-implemented 'functional' module :-).

Well, PEP 309 has been submitted for review, so with any luck (since
it's not very controversial) we'll have somewhere to put compose().

But I only asked for partial(). Someone else can propose how to do The
Right Thing for function composition ;)

Peter Harris