PEP318

[ajsiegel]

Arthur wrote:

And either intuitively, or consciously, he is doing something that
offsets it from something truly intergrated into the core of the
language. By breakling all of his own rules.

But it *isn't* part of the core language. I think that's the whole
point. @decorator does something that no other statement in Python does,
so why should it *look* like a normal statement? Or are you suggesting
that a keyword should be used instead of a symbol? I must not understand your argument.

I'm not making an argument. I'm speculating.

The design goals of PEP318 include:

"""
make it obvious what is happening; at the very least it should be obvious that new users can safely ignore it when writing their own code
"""

I'm supportive (I guess) of that design goal, but I guess I am speculating that
the actual decision as to the syntax might have been different had this not
have been among the design goals. And that a lot of the discussion regarding the syntax seems to not take consideration of this particular design goal and how it might have impacted Gudio's decision.

Art

[Josef Dalcolmo]

Hello,

I just would like to add my vote against using '@' in the Python language.

I use Leo (the intelligent folding editor written in Python), which makes heavy use of @ and using the same character in Python might create some incompatibilities.

I don't think @ looks good in ANY context and I don't want Python to start looking as ugly as some other languages. (Though I like how in Oberon - which is ugly otherwise because of its use of uppercase keywords - a variable is declared public by marking it with a '*', like in var*).

On many non-English keyboards it isn't exactly simple to type an '@', but since decorators aren't going to be used everywhere, I guess this is a weak point.

- Josef

[Peter Otten]

Josef Dalcolmo wrote:

On many non-English keyboards it isn't exactly simple to type an '@', but
since decorators aren't going to be used everywhere, I guess this is a
weak point.

Let me add that temporarily switching to an American keyboard layout (*) for
programming helps with all of the following chars: @\[]{}|`.

Peter
(*) clearly an obsession of mine

[Ville Vainio]

>>>>> "Peter" == Peter Otten <__*******@web.de> writes:

Peter> Let me add that temporarily switching to an American
Peter> keyboard layout (*) for programming helps with all of the
Peter> following chars: @\[]{}|`.

US layout is indeed the only sensible way to program in languages
designed for US layouts, which pretty much includes most mainstream
languages.

If you are not man enough to learn Dvorak, that is ;-). I recently
switched over, and did some additional keymap tweaking like switching
'8'/'(' and ')'\'9' so that I won't need to press shift for
parens. Numbers like 8 and 9 are useless for coding - everything
beyond 0 and 1 implies a flawed design.

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

[Michael Hudson]

Ville Vainio <vi***@spammers.com> writes:

Numbers like 8 and 9 are useless for coding - everything beyond 0
and 1 implies a flawed design.

Snarf!

Cheers,
mwh

--
48. The best book on programming for the layman is "Alice in
Wonderland"; but that's because it's the best book on
anything for the layman.
-- Alan Perlis, http://www.cs.yale.edu/homes/perlis-alan/quotes.html

[Sion Arrowsmith]

Josef Dalcolmo wrote:

On many non-English keyboards it isn't exactly simple to type an '@'
[ ... ]

As someone who's just started using a Mac for the first time(*),
I'd like to add that it's not always plain-sailing on an English
keyboard. (Yes, I know in terms of keystrokes it's no more
difficult than on a PC, but it's not *marked*. And I have a great
aversion to remapping keyboards so that they generate characters
other than those on the keycaps.)

(* ... for about fifteen years, when all I wanted it for was
word processing)

--
\S -- si***@chiark.greenend.org.uk -- http://www.chaos.org.uk/~sion/
___ | "Frankly I have no feelings towards penguins one way or the other"
\X/ | -- Arthur C. Clarke
her nu becomeþ se bera eadward ofdun hlæddre heafdes bæce bump bump bump

[Arthur]

On Thu, 12 Aug 2004 09:00:56 +0200, Josef Dalcolmo <da******@vh-s.de>
wrote:

Hello,

I just would like to add my vote against using '@' in the Python language.

I must say that after days of waffling, and I think an honest effort
to accept where things were going, I woke this morning hating
@decorator.

The existing syntax for this kind of transformation is, in fact,
exactly what one would expect:

foo=staticmathed(foo).

That is the universal langauge for transformations. And when we try
to explain to anybody what it is that @decorator means, we go back to
the pseudo code that is in fact the existing syntax.

I guess I am mystified what it is that is perceived to have been
gained ... by moving magic outside the function block to the top of a
function in lieu of expressive code outside the function block at the
bottom of the function. Something is created, and then transofrmed -
in the language of transformation that transcends the implementation
detail of what programming language is doing the work.

Art

[Roy Smith]

Sion Arrowsmith <si***@chiark.greenend.org.uk> wrote:

As someone who's just started using a Mac for the first time(*),
I'd like to add that it's not always plain-sailing on an English
keyboard.
What's wrong with Mac keyboards? I've used a number of Mac keyboards
over the past 15 or so years, and have found the variety of layouts to
be no better or worse (or more or less standardized) than any other
keyboards in general. I'm currently using a 12" PowerBook and other
than finding the control key to be uncomfortably close to the space bar,
I find it perfectly reasonable for programming and emacs-ing.
And I have a great
aversion to remapping keyboards so that they generate characters
other than those on the keycaps.)

Yes, that's evil. I was just in the UK a couple of weeks ago and was
using a semi-UK keyboard. As far as I could tell, the keycaps were
labeled with the UK layout, but the codes they generated were US style.
I touch-type, so as long as I ignored what was printed on the keycaps
and just typed normally, everything was fine. But it's amazingly
difficult to ignore the printed keycaps.

[Antoon Pardon]

Op 2004-08-12, Roy Smith schreef <ro*@panix.com>:

Sion Arrowsmith <si***@chiark.greenend.org.uk> wrote:

As someone who's just started using a Mac for the first time(*),
I'd like to add that it's not always plain-sailing on an English
keyboard.

What's wrong with Mac keyboards? I've used a number of Mac keyboards
over the past 15 or so years, and have found the variety of layouts to
be no better or worse (or more or less standardized) than any other
keyboards in general. I'm currently using a 12" PowerBook and other
than finding the control key to be uncomfortably close to the space bar,
I find it perfectly reasonable for programming and emacs-ing.

And I have a great
aversion to remapping keyboards so that they generate characters
other than those on the keycaps.)

Yes, that's evil. I was just in the UK a couple of weeks ago and was
using a semi-UK keyboard. As far as I could tell, the keycaps were
labeled with the UK layout, but the codes they generated were US style.
I touch-type, so as long as I ignored what was printed on the keycaps
and just typed normally, everything was fine. But it's amazingly
difficult to ignore the printed keycaps.

It's not that difficult if you gain some experience with it. Half
the keboards here are qwerty the other half is azerty. On all machines
I have to work on with an azerty I have configured my account to
treat the keyboard as if the keyboard is qwerty. After a little
getting used to that works easier and faster than always adjusting
to the keyboard of the specific computer.

--
Antoon Pardon

[Sion Arrowsmith]

Roy Smith <ro*@panix.com> wrote:

Sion Arrowsmith <si***@chiark.greenend.org.uk> wrote:

As someone who's just started using a Mac for the first time(*),
I'd like to add that it's not always plain-sailing on an English
keyboard.

What's wrong with Mac keyboards?

No @, hence tangential relevance to PEP318 (and a point against
pies, before or after the def). Unless you can remember it's on
option-3.

--
\S -- si***@chiark.greenend.org.uk -- http://www.chaos.org.uk/~sion/
___ | "Frankly I have no feelings towards penguins one way or the other"
\X/ | -- Arthur C. Clarke
her nu becomeþ se bera eadward ofdun hlæddre heafdes bæce bump bump bump

[Roy Smith]

Arthur <aj******@optonline.com> wrote:

I must say that after days of waffling, and I think an honest effort
to accept where things were going, I woke this morning hating
@decorator.

The existing syntax for this kind of transformation is, in fact,
exactly what one would expect:

foo=staticmathed(foo).

That is the universal langauge for transformations. And when we try
to explain to anybody what it is that @decorator means, we go back to
the pseudo code that is in fact the existing syntax.

I'm with Arthur.

I think the core problem is that the def statement is kind of wierd. It
does two different things. First, it creates a function body, then it
binds the function to a name.

One of the objections to:

def foo ():
whatever
foo = decorator (foo)

is that you have to type the word "foo" three times. It's not so much
the effort of repeating the keystrokes, but the fact that it feels so
unfactored. The only reason you need to do this is because you have no
way of getting at the newly-generated function (what CS types would call
a "lambda form") before it's bound to the name.

A solution to that is to factor out the function definition from the
name binding, so you would do something like:

foo = def ():
whatever

although by the time you do that, you might as well have just gotten rid
of def and used lambda() directly. If you wanted it to be a
static/class method, you would do:

foo = staticmethod_def ():
whatever

The other big objection to the current syntax is that it puts the
wrapper way down at the bottom of the function body, away from the name.
The above syntax solves that too.

The big problem with the above is that it changes the semantics of the
def statement in a way which is incompatible with current usage, and
thus I would expect it's a complete non-starter. Not to mention
inventing new keywords.

On the other hand, doing:

def (staticmethod) foo ():
whatever

(you can pick whatever bits of punctuation turn you on) seems like it
should work just fine. I think it achieves all the goals:

1) It puts the decorator before the function body.

2) It keeps the decorator right next to the function name.

3) It doesn't re-define any currently valid syntax.

4) It looks enough like current Python syntax that most add-on tools
should handle it just fine.

5) If you've got lots of decorators (I'm still not sure if people really
think this will happen in real life), it's easy enough to break it up
into multiple lines:

def @decorator1 \
@decorator2 \
@decorator3 foo (a, b, c):
print a, b, c

but I'm assuming that will be the exception, just like really long
argument lists are the exception. Define the order of application of
multiple decorators in whichever way floats your boat; I'm guessing
outside-in (i.e. the last one gets done first) makes the most sense.

I suppose you could take this one step further and put the decorators
inside ()'s, so you'd have any of (as auto-indented by emacs):

def (decorator) foo (a, b, c):
pass

def (decorator1, decorator2, decorator3) foo (a, b, c):
pass

def (decorator1,
decorator2,
decorator3) foo (a, b, c):
pass

def (decorator1,
decorator2,
decorator3) foo (a,
b,
c):
pass

with the last example being a bit ugly, but at least it seems to follow
the expected indenting rules. In any case, you'd only have to resort to
something like that if you had lots of decorators and lots of arguments,
and in that case, I suspect you might want to be refactoring things to
simplify it all anyway.

I haven't done an exhaustive search of all the proposed syntaxen which
have come flying by here in the past week or so. My apologies if I've
accidentally duplicated somebody else's work here.

In retrospect (this has been written in dribs and drabs over the past
several hours, as I've been called away repeatedly to do real work), I
see I started out by agreeing with Arthur that the current (i.e. pre
PEP-318) way of doing things is good enough, then managed to head off
into a different direction and suggest YADS (Yet Another Decorator
Syntax). Oh, well.

I'm also not at all convinced that using decorators for things like doc
strings makes any sense at all. It's just the wrong tool. Docstrings
work just fine the way they are. If it ain't broke, don't fix it.
Which I guess brings me full-circle back to agreeing with Arthur :-)

[Arthur]

On Thu, 12 Aug 2004 12:33:50 -0400, Roy Smith <ro*@panix.com> wrote:

Arthur <aj******@optonline.com> wrote:

I must say that after days of waffling, and I think an honest effort
to accept where things were going, I woke this morning hating
@decorator.

The existing syntax for this kind of transformation is, in fact,
exactly what one would expect:

foo=staticmathed(foo).

That is the universal langauge for transformations. And when we try
to explain to anybody what it is that @decorator means, we go back to
the pseudo code that is in fact the existing syntax.
I'm with Arthur.

Yes and no.

I am contendingt that that staus quo (pre 2.4 alpha2), all things
considered, is the best we are going to do, realistically.

Within the framwork of Python as it is, and without making changes to
Python as it is out of proportion to the need that is being addressed.

I certainly thing that @decorator is a chnage out of proportion to the
need being addressed.

But you are proposing a non-starter, which implicitly rejects the
status quo. And proposes other changes out of proportion to the need
being addressed.

One of the objections to:

def foo ():
whatever
foo = decorator (foo)

is that you have to type the word "foo" three times.

Big f**king deal - all things considered. ;)

Art

[Mark Bottjer]

Arthur wrote:

I guess I am mystified what it is that is perceived to have been
gained ... by moving magic outside the function block to the top of a
function in lieu of expressive code outside the function block at the
bottom of the function. Something is created, and then transofrmed -
in the language of transformation that transcends the implementation
detail of what programming language is doing the work.

I'm in the same boat. I wanted something (anything!) to get around the
ugliness that is f=foo(f) after the def. Now that we have it (in spades,
considering all the variants), I don't find it to be any more satisfying
than what we already had.

Sigh.

-- Mark

[Arthur]

On Thu, 12 Aug 2004 17:03:19 GMT, Arthur <aj******@optonline.com>
wrote:

One of the objections to:

def foo ():
whatever
foo = decorator (foo)

is that you have to type the word "foo" three times.
Big f**king deal - all things considered. ;)

Mathematical notation looks to achieve conciseness, and precision of
expression. And on settled matters of notation, assumedly that attempt
has been optimized.

Why is that not good enough for Python?

Art

[Mark Bottjer]

Roy Smith wrote:

A solution to that is to factor out the function definition from the
name binding, so you would do something like:

foo = def ():
whatever

although by the time you do that, you might as well have just gotten rid
of def and used lambda() directly. If you wanted it to be a
static/class method, you would do:

foo = staticmethod_def ():
whatever

I agree that this seems to be the cleanest solution, but I also agree
with you that it is a non-starter. Maybe when we get subclassable
statements in Python 3.0. :)

-- Mark

[David Eppstein]

In article <7t********************************@4ax.com>,
Arthur <aj******@optonline.com> wrote:

foo=staticmathed(foo).

That is the universal langauge for transformations. And when we try
to explain to anybody what it is that @decorator means, we go back to
the pseudo code that is in fact the existing syntax.

I guess I am mystified what it is that is perceived to have been
gained ... by moving magic outside the function block to the top of a
function in lieu of expressive code outside the function block at the
bottom of the function.

Not having to write the function name three times? If it's just foo,
that would be one thing, but have you seen the PyObjC examples?

Also, it's not in the Zen of Python, but maybe declarative is better
than imperative?

--
David Eppstein
Computer Science Dept., Univ. of California, Irvine
http://www.ics.uci.edu/~eppstein/

[Robin Becker]

David Eppstein wrote:

In article <7t********************************@4ax.com>,
Arthur <aj******@optonline.com> wrote:

foo=staticmathed(foo).

That is the universal langauge for transformations. And when we try
to explain to anybody what it is that @decorator means, we go back to
the pseudo code that is in fact the existing syntax.

I guess I am mystified what it is that is perceived to have been
gained ... by moving magic outside the function block to the top of a
function in lieu of expressive code outside the function block at the
bottom of the function.

Not having to write the function name three times? If it's just foo,
that would be one thing, but have you seen the PyObjC examples?

Also, it's not in the Zen of Python, but maybe declarative is better
than imperative?

I think I'm with Arthur in that the current transformation notation is sufficient.

If people wish to avoid three names then we need proper anonymous functions as
others stated.

To avoid lots of extra parentheses we need a function call composition mechanism
or for people to define the functions they need rather than have arbitrary lists
of operators.
--
Robin Becker

[Arthur]

On Thu, 12 Aug 2004 10:35:02 -0700, David Eppstein
<ep******@ics.uci.edu> wrote:

In article <7t********************************@4ax.com>,
Arthur <aj******@optonline.com> wrote:

foo=staticmathed(foo).

That is the universal langauge for transformations. And when we try
to explain to anybody what it is that @decorator means, we go back to
the pseudo code that is in fact the existing syntax.

I guess I am mystified what it is that is perceived to have been
gained ... by moving magic outside the function block to the top of a
function in lieu of expressive code outside the function block at the
bottom of the function.
Not having to write the function name three times? If it's just foo,
that would be one thing, but have you seen the PyObjC examples?

Does

def __f(something):
dosomething

the_name_I_really_ant_to_call=transform(__f)

work?

Also, it's not in the Zen of Python, but maybe declarative is better
than imperative?

Starting now, I guess. ;)

Art

[David Eppstein]

In article <f3********************************@4ax.com>,
Arthur <aj******@optonline.com> wrote:

Also, it's not in the Zen of Python, but maybe declarative is better
than imperative?

Starting now, I guess. ;)

Well, I think starting with list comprehensions in place of imperative
append-loops.

--
David Eppstein
Computer Science Dept., Univ. of California, Irvine
http://www.ics.uci.edu/~eppstein/

[paolo veronelli]

On Thu, 12 Aug 2004 14:29:07 -0700, David Eppstein <ep******@ics.uci.edu>
wrote:

In article <f3********************************@4ax.com>,
Arthur <aj******@optonline.com> wrote:

>Also, it's not in the Zen of Python, but maybe declarative is better
>than imperative?

Starting now, I guess. ;)

Well, I think starting with list comprehensions in place of imperative
append-loops.

I don't think there is a clear similarity,in fact I don't have any
declarative feeling when I use list comprehension,for me it's a shortcut.
With decorators before defs I have a new feeling,but not the good
declarative one I have with haskell (which would be nice to melt with).
I'm not erudite enough to explain it anyway.

Paolino
--
.....lotta dura per la verdura

[Michael J. Fromberger]

In article <ep****************************@news.service.uci.e du>,
David Eppstein <ep******@ics.uci.edu> wrote:

Also, it's not in the Zen of Python, but maybe declarative is better
than imperative?

This one comment particularly caught my attention.

I generally agree with your above statement, but I don't think that this
alone really justifies the proposed "decorators" (leaving aside the fact
that they are still a moving target, semantically).

The basic idea behind PEP-318 wasn't too bad, in my opinion -- but I
think in discussion it's been overloaded with a lot of declaration work
that would be better off factored out over other parts of the language
(e.g., type declarations in the parameter list; method transformations
wherever the syntactic dust settles over PEP-318; documentary metadata
preferably left out of the syntax and parsed from comments or doc
strings).

To use the example of list comprehensions, I think we can agree that
declarative constructs have excellent potential. But this is Python,
not Perl, we don't need to make a Swiss Army knife out of this one piece
of syntax. I realize you're not proposing we do so -- but, "declarative
is better than imperative" could be taken too far by others.

-M

--
Michael J. Fromberger | Lecturer, Dept. of Computer Science
http://www.dartmouth.edu/~sting/ | Dartmouth College, Hanover, NH, USA

[Anthony Baxter]

On Thu, 12 Aug 2004 17:03:19 GMT, Arthur <aj******@optonline.com> wrote:

def foo ():
whatever
foo = decorator (foo)

is that you have to type the word "foo" three times.

Big f**king deal - all things considered. ;)

When this name is a PyObjC name that might be 70 characters long,
it becomes a big deal.

[Pierre-Frédéric Caillaud]

Proposal :

Make def an expression (always returns the function):

# this one behaves as usual
def funcname(params):
function body

# this one is new
# it allows us to name a function (func.__name__ ?) and also use it in
expressions
variable = def funcname(params):
function body

# or
variable = def (params):
function body

# or
return def funcname(params):
function body

Now we could write :
funcname = classmethod(
def funcname( params ):
body
)

But it looks lispish and introduces a lot of confusing parentheses...

Now, I propose (oops) a new operator, whatever name it has, which means
"the value of the expression on the next line of code". Let's say this is
a new use for "*" :

a = function1( x,*,z )
function2( f,g,h )

This would be translated by the compiler as

a = function1( x,function2( f,g,h ),z )

So we can have :

funcname = decorator1(*)
decorator2(*, other params)
def funcname( params ):
function body

What do you think ?

Yet another proposition :

execute:
funcname = classmethod( funcname )
after:
def funcname(params):
body

On Thu, 12 Aug 2004 12:33:50 -0400, Roy Smith <ro*@panix.com> wrote:

Arthur <aj******@optonline.com> wrote:

I must say that after days of waffling, and I think an honest effort
to accept where things were going, I woke this morning hating
@decorator.

The existing syntax for this kind of transformation is, in fact,
exactly what one would expect:

foo=staticmathed(foo).

That is the universal langauge for transformations. And when we try
to explain to anybody what it is that @decorator means, we go back to
the pseudo code that is in fact the existing syntax.

I'm with Arthur.

I think the core problem is that the def statement is kind of wierd. It
does two different things. First, it creates a function body, then it
binds the function to a name.

One of the objections to:

def foo ():
whatever
foo = decorator (foo)

is that you have to type the word "foo" three times. It's not so much
the effort of repeating the keystrokes, but the fact that it feels so
unfactored. The only reason you need to do this is because you have no
way of getting at the newly-generated function (what CS types would call
a "lambda form") before it's bound to the name.

A solution to that is to factor out the function definition from the
name binding, so you would do something like:

foo = def ():
whatever

although by the time you do that, you might as well have just gotten rid
of def and used lambda() directly. If you wanted it to be a
static/class method, you would do:

foo = staticmethod_def ():
whatever

The other big objection to the current syntax is that it puts the
wrapper way down at the bottom of the function body, away from the name.
The above syntax solves that too.

The big problem with the above is that it changes the semantics of the
def statement in a way which is incompatible with current usage, and
thus I would expect it's a complete non-starter. Not to mention
inventing new keywords.

On the other hand, doing:

def (staticmethod) foo ():
whatever

(you can pick whatever bits of punctuation turn you on) seems like it
should work just fine. I think it achieves all the goals:

1) It puts the decorator before the function body.

2) It keeps the decorator right next to the function name.

3) It doesn't re-define any currently valid syntax.

4) It looks enough like current Python syntax that most add-on tools
should handle it just fine.

5) If you've got lots of decorators (I'm still not sure if people really
think this will happen in real life), it's easy enough to break it up
into multiple lines:

def @decorator1 \
@decorator2 \
@decorator3 foo (a, b, c):
print a, b, c

but I'm assuming that will be the exception, just like really long
argument lists are the exception. Define the order of application of
multiple decorators in whichever way floats your boat; I'm guessing
outside-in (i.e. the last one gets done first) makes the most sense.

I suppose you could take this one step further and put the decorators
inside ()'s, so you'd have any of (as auto-indented by emacs):

def (decorator) foo (a, b, c):
pass

def (decorator1, decorator2, decorator3) foo (a, b, c):
pass

def (decorator1,
decorator2,
decorator3) foo (a, b, c):
pass

def (decorator1,
decorator2,
decorator3) foo (a,
b,
c):
pass

with the last example being a bit ugly, but at least it seems to follow
the expected indenting rules. In any case, you'd only have to resort to
something like that if you had lots of decorators and lots of arguments,
and in that case, I suspect you might want to be refactoring things to
simplify it all anyway.

I haven't done an exhaustive search of all the proposed syntaxen which
have come flying by here in the past week or so. My apologies if I've
accidentally duplicated somebody else's work here.

In retrospect (this has been written in dribs and drabs over the past
several hours, as I've been called away repeatedly to do real work), I
see I started out by agreeing with Arthur that the current (i.e. pre
PEP-318) way of doing things is good enough, then managed to head off
into a different direction and suggest YADS (Yet Another Decorator
Syntax). Oh, well.

I'm also not at all convinced that using decorators for things like doc
strings makes any sense at all. It's just the wrong tool. Docstrings
work just fine the way they are. If it ain't broke, don't fix it.
Which I guess brings me full-circle back to agreeing with Arthur :-)

[Michael Hudson]

Sion Arrowsmith <si***@chiark.greenend.org.uk> writes:

Roy Smith <ro*@panix.com> wrote:

Sion Arrowsmith <si***@chiark.greenend.org.uk> wrote:

As someone who's just started using a Mac for the first time(*),
I'd like to add that it's not always plain-sailing on an English
keyboard.

What's wrong with Mac keyboards?

No @, hence tangential relevance to PEP318 (and a point against
pies, before or after the def). Unless you can remember it's on
option-3.

Huh? On *my* mac <wink> @ is shift-2 and # is option-3. And I live
with the latter, and I type it far more often than anyone is ever
going to type @ for decorators...

Now, if someone would like to fix \ in place for the purposes of
LaTeX, then you're really talking!

Cheers,
mwh

--
<Erwin> I recompiled XFree 4.2 with gcc 3.2-beta-from-cvs with -O42
and -march-pentium4-800Mhz and I am sure that the MOUSE
CURSOR is moving 5 % FASTER!
-- from Twisted.Quotes

[Ronald Oussoren]

On 13-aug-04, at 13:39, Michael Hudson wrote:

Sion Arrowsmith <si***@chiark.greenend.org.uk> writes:

Roy Smith <ro*@panix.com> wrote:

Sion Arrowsmith <si***@chiark.greenend.org.uk> wrote:
As someone who's just started using a Mac for the first time(*),
I'd like to add that it's not always plain-sailing on an English
keyboard.
What's wrong with Mac keyboards?

No @, hence tangential relevance to PEP318 (and a point against
pies, before or after the def). Unless you can remember it's on
option-3.

Huh? On *my* mac <wink> @ is shift-2 and # is option-3. And I live
with the latter, and I type it far more often than anyone is ever
going to type @ for decorators...

Now, if someone would like to fix \ in place for the purposes of
LaTeX, then you're really talking!

Use a real keyboard? On my powerbook @ is shift-2, # is shift-3 and \
is near return and left-shift :-)

Ronald

[Sion Arrowsmith]

Michael Hudson <mw*@python.net> wrote:

Huh? On *my* mac <wink> @ is shift-2 and # is option-3.

Er, sorry everyone, yes, I'm talking complete bollocks. Ignore me.

--
\S -- si***@chiark.greenend.org.uk -- http://www.chaos.org.uk/~sion/
___ | "Frankly I have no feelings towards penguins one way or the other"
\X/ | -- Arthur C. Clarke
her nu becomeþ se bera eadward ofdun hlæddre heafdes bæce bump bump bump

[Stefan Eischet]

On 13.08.2004, at 13:39, Michael Hudson wrote:

Sion Arrowsmith <si***@chiark.greenend.org.uk> writes:

Roy Smith <ro*@panix.com> wrote:

Sion Arrowsmith <si***@chiark.greenend.org.uk> wrote:
As someone who's just started using a Mac for the first time(*),
I'd like to add that it's not always plain-sailing on an English
keyboard.
What's wrong with Mac keyboards?

No @, hence tangential relevance to PEP318 (and a point against
pies, before or after the def). Unless you can remember it's on
option-3.

Huh? On *my* mac <wink> @ is shift-2 and # is option-3. And I live
with the latter, and I type it far more often than anyone is ever
going to type @ for decorators...

My german iBook uses ALT-L for @, which by itself is not a very big
problem. But as an added bonus, the german PC keyboard puts @ at
ALTGR+Q (right alt key), which directly translates into APPLE-Q. You
know, like in "Quit".
Common exclamation: "I just want to type an email address. Where is the
program gone?!"
(This means that if I use my usual PC-worker's keypress to type @, it
should kill IDLE. Considering how I like the decorator syntax, this
might actually be a feature... ;-) )

// st****@eischet.com //

[Donn Cave]

Quoth Michael Hudson <mw*@python.net>:
....
| Huh? On *my* mac <wink> @ is shift-2 and # is option-3.

What kind of keyboard has a key for <wink> @?

Donn Cave, do**@drizzle.com

[Arthur]

On Fri, 13 Aug 2004 16:43:05 +1000, Anthony Baxter
<an***********@gmail.com> wrote:

On Thu, 12 Aug 2004 17:03:19 GMT, Arthur <aj******@optonline.com> wrote:

>def foo ():
> whatever
>foo = decorator (foo)
>
>is that you have to type the word "foo" three times.

Big f**king deal - all things considered. ;)

When this name is a PyObjC name that might be 70 characters long,
it becomes a big deal.

PyOdjC keeps being mentioned as the poster project for @decorator.

Isn't it fair to note that projects where the naming of functions is
outside the control of the developers are blue moon situations?

The kind of constraint that might be expected to lead to some extra
effort. Which the PyObjC developers seemed to be quite willing and
able to face with some equanimity, in the absence of a native
@decorator facility.

Just a debating point, or at least an effort to neutralize, a bit, a
statement that seems to be little more than a debating point.
Art

[Roman Suzi]

On Sat, 14 Aug 2004, Arthur wrote:

On Fri, 13 Aug 2004 16:43:05 +1000, Anthony Baxter
<an***********@gmail.com> wrote:

On Thu, 12 Aug 2004 17:03:19 GMT, Arthur <aj******@optonline.com> wrote:

>def foo ():
> whatever
>foo = decorator (foo)
>
>is that you have to type the word "foo" three times.

Big f**king deal - all things considered. ;)

When this name is a PyObjC name that might be 70 characters long,
it becomes a big deal.

PyObjC keeps being mentioned as the poster project for @decorator.

Maybe its better idea to store decorators in resource fork ;)
Sincerely yours, Roman Suzi
--
rn*@onego.ru =\= My AI powered by GNU/Linux RedHat 7.3

[Greg Ewing]

Donn Cave wrote:

Quoth Michael Hudson <mw*@python.net>:
...
| Huh? On *my* mac <wink> @ is shift-2 and # is option-3.

What kind of keyboard has a key for <wink> @?

Aha! Folks have been calling it a "pie" here, but maybe
the @ in @decorator is secretly meant to represent a
wink? That would explain a lot...

--
Greg Ewing, Computer Science Dept,
University of Canterbury,
Christchurch, New Zealand
http://www.cosc.canterbury.ac.nz/~greg