The poll, as stated, asked voters to vote for the syntax suggestion
they liked the /most/. Some of the conclusions people are trying to
draw from it are what syntaxes people liked the /least/. This is
probably not the right conclusion to be drawing from the poll that was
given.
It is, however, the kind of conclusion I think we'd like to draw. I'm
not sure we're going to agree fully on a single "best" proposal, but
it would help to get rid of any proposals that are overwhelmingly
dispreferred. So I suggest a new poll of which syntax suggestions
people like the /least/. I know that GvR is not interested in polls
(and probably rightfully so), so I suggest this only as a means of
directing our discussion -- if an overwhelming majority dislikes a
certain option, we can stop discussing it, and focus on the remaining
options.
I think it's also important not to limit the options so much. I
didn't vote at the last one because I didn't like any of the options.
I'd actually propose 4 different polls, based on the syntax breakdown
in the wiki:
Indicator:
* keyword
* symbol
* function
* none
Location:
* pre-def
* on same line, preceding def
* between def and function name
* between function name and argument list
* between argument list and colon
* at beginning of function body
List notation:
* one per line
* commas only
* as list
* as tuple
Indentation:
* indent decorators and def
* indent only decorators
* none
I think it should be pretty easy for us to throw out some of these
options pretty quickly. (For example, I haven't seen much support for
"Location: between function name and argument list".)
Does this seem like a better polling strategy? If so, can someone
post such polls somewhere?
Steve
12  1526 
Steven Bethard wrote: The poll, as stated, asked voters to vote for the syntax suggestion
they liked the /most/. Some of the conclusions people are trying to
draw from it are what syntaxes people liked the /least/. This is
probably not the right conclusion to be drawing from the poll that was
given.
That's certainly true (after all, the one with the fewest votes could
actually be everyone's _second_ favorite choice!), but I don't think
it's the most serious problem with the accuracy of the poll. The
problem is that since it's an unofficial poll, and it's not clear that
Guido will give much credence to it at all, there is really no incentive
for people who are happy, or at least satisfied, with the current
decorator syntax to vote in order to express their approval. Now,
that's probably true in an official vote as well, but it's probably much
more strongly the case here, where there's not even any good indication
that the poll will be paid attention to, and it hasn't been commissioned
by any entity actually in charge of making the final decision.
So only people who are dissastisfied with the proposal are likely to
vote, and indeed that seems to be the case. Furthermore, perhaps the
only case where the results of the poll might raise eyebrows would be if
there were a landslide, so to speak, but a landslide is going to be far
more indicative of the poll being horribly biased, rather than it
showing any real intentions of the community (and I'd certainly claim
that based on the initial reactions of people to the decorator syntax --
lots of people expressed their support; they've just been drowned out by
proposal after proposal after proposal).
--
__ Erik Max Francis && ma*@alcyone.com && http://www.alcyone.com/max/
/ \ San Jose, CA, USA && 37 20 N 121 53 W && AIM erikmaxfrancis
\__/ My long is strong enough, you know / Strong enough to let you go
-- Xscape
Steven Bethard wrote: The poll, as stated, asked voters to vote for the syntax suggestion
they liked the /most/. Some of the conclusions people are trying to
draw from it are what syntaxes people liked the /least/. This is
probably not the right conclusion to be drawing from the poll that was
given.
What the poll found is that when given a choice between the current
decorator syntax and two specific alternatives, people overwhelmingly
choose the two alternatives. So there are at least two specific
alternative syntaxes out there (and of course probably more) that most
people would prefer over the current one.
So it is reasonable to conclude that most people do not think the
current decorator syntax is the best option.
Although that might seem obvious to some, that conclusion alone had not
yet been clear based on mailing list traffic.
So if Guido does want to pay attention to the opinions of Python users
(and he doesn't have to), then changing the current syntax probably
wouldn't be an unpopular decision. The question though, is what
specific alternative syntax should it be? There are at least two other
popular syntaxes and very likely many more, but Guido asked for help in
narrowing them down to one or two or three specific proposals so he
could decide.
At the same time though, Guido has rejected all alternative syntaxes
that have been presented, so the decorators will likely stay as is. In
the long long long term, decorators will be less important anyway, if we
get features like optional static typing that Guido has expressed
support for (no need for accepts and requires decorators), anonymous
code blocks, etc.
Doug Holton wrote: So if Guido does want to pay attention to the opinions of Python users
(and he doesn't have to), then changing the current syntax probably
wouldn't be an unpopular decision.
The point is that even if Guido does want to pay attention to the
opinions of Python users, the results of this particular poll may not be
the best way to do it.
--
__ Erik Max Francis && ma*@alcyone.com && http://www.alcyone.com/max/
/ \ San Jose, CA, USA && 37 20 N 121 53 W && AIM erikmaxfrancis
\__/ She's your moon, she's your sun / She could even be the one
-- Nik Kershaw
Erik Max Francis wrote: So only people who are dissastisfied with the proposal are likely to
vote, and indeed that seems to be the case.
That seems to be a perfect situation then. Why do we need
votes from people who are happy with the @pie syntax? It's
already in Python.
On the other, if there are people who are dissatisfied with
@pie, they can vote, use the results to help them focus
their energies on the most likely alternate candidate(s),
and finally present a united front saying "uh, @pie
sucks, and we have a wide consensus that syntax XXXX
would be much better for these reasons..."
Wouldn't that make sense?
-Peter
Doug Holton wrote: At the same time though, Guido has rejected all alternative syntaxes
that have been presented, so the decorators will likely stay as is.
I believe until there is a "pronouncement" , which hadn't happened
the last time I checked, there is still the possibility that
an alternate will be accepted. Guido has expressed his opinion
on most of the alternative syntaxes, and it has been generally
negative, but opinions can change.
-Peter
Peter Hansen wrote: On the other, if there are people who are dissatisfied with
@pie, they can vote, use the results to help them focus
their energies on the most likely alternate candidate(s),
and finally present a united front saying "uh, @pie
sucks, and we have a wide consensus that syntax XXXX
would be much better for these reasons..."
Wouldn't that make sense?
Yes, that would probably make the poll results more closely match up
with reality. The problem is, that isn't the purpose of the poll as
stated. On the contrary, they are used the certainly biased results of
the poll to show that the @decorator syntax is unwanted, which is highly
suspect.
--
__ Erik Max Francis && ma*@alcyone.com && http://www.alcyone.com/max/
/ \ San Jose, CA, USA && 37 20 N 121 53 W && AIM erikmaxfrancis
\__/ No man who needs a monument ever ought to have one.
-- Nathaniel Hawthorne
On Thu, 12 Aug 2004 23:12:56 -0400, Peter Hansen <pe***@engcorp. com> wrote: On the other, if there are people who are dissatisfied with
@pie, they can vote, use the results to help them focus
their energies on the most likely alternate candidate(s),
and finally present a united front saying "uh, @pie
sucks, and we have a wide consensus that syntax XXXX
would be much better for these reasons..."
But then you end up with the opposite problem - a pile of
people say "we want this one" (say, list-before-def), it's
implemented, then all the people who prefer pie-decorators
start jumping up and down.
I don't think there's as wide a concensus as I keep hearing
about. The people who hate pie-decorators post a _lot_ -
most people seem to either not care, or else post once or
twice and then disappear. I think I'm about the only person
posting in any volume to c.l.py in favour of the syntax, and
even then, my liking of it is also driven by a dislike of the
other proposed syntaxes.
Anthony
Anthony Baxter wrote: On Thu, 12 Aug 2004 23:12:56 -0400, Peter Hansen <pe***@engcorp. com> wrote:
On the other, if there are people who are dissatisfied with
@pie, they can vote, use the results to help them focus
their energies on the most likely alternate candidate(s),
and finally present a united front saying "uh, @pie
sucks, and we have a wide consensus that syntax XXXX
would be much better for these reasons..."
But then you end up with the opposite problem - a pile of
people say "we want this one" (say, list-before-def), it's
implemented, then all the people who prefer pie-decorators
start jumping up and down.
Why on earth would it be *implemented* before we rationally
faced that phase of the debate? Nobody that I know is silly
enough to think that we should immediately rip out @pie
if there's an alternative that lots of people like better,
since it's pretty obvious there are people who like (and
have invested significant mindshare in getting used to) @pie.
No, this phase doesn't involve the @pie-ists... it's a
reasonable discussion amonst those who don't like it. Someone
asked us to do that. Now we're doing it, so don't complain.
When, or if, we reach a consensus, then we start to involve
the @pie folks but until then it's not their argument.
I don't think there's as wide a concensus as I keep hearing
about.
Where have you heard there *was* a consensus? I don't recall
seeing such a thing, though I've raised the question of whether
it exists yet.
The people who hate pie-decorators post a _lot_ -
most people seem to either not care, or else post once or
twice and then disappear. I think I'm about the only person
posting in any volume to c.l.py in favour of the syntax, and
even then, my liking of it is also driven by a dislike of the
other proposed syntaxes.
Well, for the record then (and in spite of my "not their
argument" rant above), could you please provide your opinion
and reasons on the "decorate:" syntax? To be completely
honest about it, I haven't seen very many negative comments
about it. In fact, almost none, and that's why I was
starting to think there *might* be a consensus forming,
which is why I started asking.
-Peter
Erik Max Francis <ma*@alcyone.co m> wrote in message news:<41******* ********@alcyon e.com>... The problem is that since it's an unofficial poll, and it's not clear that
Guido will give much credence to it at all, there is really no incentive
for people who are happy, or at least satisfied, with the current
decorator syntax to vote in order to express their approval.
Your point is valid if the goal of the poll would be to influence
Guido. The point of the polls I'm suggesting are not to influence
Guido at all, but to direct the discussion among the rest of us. If
it so happens that those who are happy with the current proposal don't
vote, it actually doesn't make much of a difference, because those who
are happy with the current proposal and not interested in the
discussion enough to vote won't really be contributing to the
discussion anyway.
What I'm really interested in here is trying to build a consensus
among the dissatisfied people. If you scan the list right now, you
can see that there are a hundred people going in a hundred directions.
I'm sure this looks to Guido like an insoluble problem that is best
handled by a "pronouncement" . On the other hand, if all (or at least
a substantial majority) of the people complaining about @decorators
now all got together and pushed the same counter-proposal, even if we
didn't have representatives from the happy-with-@decorators group, I
think we'd hold a lot more sway in Guido's eyes.
I don't actually expect to be able to get a consensus on everything.
Location especially I expect we won't come to an agreement on. But if
it looks like most of us want, say a keyword instead of a symbol, then
at least that's a step.
Steve This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics | |
by: Sandy Norton |
last post by:
If we are going to be stuck with @decorators for 2.4, then how about
using blocks and indentation to elminate repetition and increase
readability:
Example 1
---------
class Klass:
def __init__(self, name):
|
by: Steven Bethard |
last post by:
I think one of the biggest reasons we're having such problems coming
to any agreement on decorator syntax is that each proposal makes a
number of syntax decisions, not just one. For decorators, I see the
following decisions that must be made:
1) Indicator
Proposals differ on how some sort of indicator of "decoratorhood" is
use. These...
|
by: Ville Vainio |
last post by:
It might just be that @decorator might not be all that bad. When you
look at code that uses it it's not that ugly after all.
A lot of the furor about this is probably because it happened so
quicly. The situation might have been different if we had seen a
pronouncement a week before, in the vein of "I have chosen this syntax
- it will go in...
|
by: Steven Bethard |
last post by:
So here's the state of the decorator debate as I see it:
*** Location
GvR pretty strongly wants decorators before the function:
http://mail.python.org/pipermail/python-dev/2004-August/047112.html
http://mail.python.org/pipermail/python-dev/2004-August/047279.html
|
by: John Marshall |
last post by:
How about the following, which I am almost positive
has not been suggested:
-----
class Klass:
def __init__(self, name):
self.name = name
deco meth0:
staticmethod
def meth0(x):
| | |
by: Jim Jewett |
last post by:
Guido has said that he is open to considering *one* alternative
decorator syntax. At the moment, (Phillip Eby's suggestion) J4
<URL: http://www.python.org/moin/PythonDecorators > (section 5.21 J4)
looks very good to me -- and it is the only alternative without negatives.
def func(arg1, arg2)
@version("Added in 2.4")
@returns(None)
|
by: Paul McGuire |
last post by:
Well, after 3 days of open polling, the number of additional votes have
dropped off pretty dramatically. Here are the results so far:
Total voters: 55 (with 3 votes each)
Votes for each choice or group of choices:
Any J 81
J2 78
Any C 40
C1 29
Any D 9
|
by: Larry Hastings |
last post by:
I didn't see this form of decorator syntax listed on the Python
Decorator Wiki, but that page is now frozen so I'm posting it here. I
realize the futility (and ignominy!) of posting such a thing,
especially at such a late date, so I'm happy to say I have absolutely
no ego invested in it ;)
Behold:
def foo(a, b),
classmethod,
|
by: Peter Otten |
last post by:
I took the freedom to forward GvR's mail concerning decorator cosmetics.
I think you should know about it.
Peter
---------- Forwarded Message ----------
Subject: Strawman decision: @decorator won't change
Date: Wednesday 15 September 2004 23:46
From: Guido van Rossum <gvanrossum@gmail.com>
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it.
First, let's disable language...
| | |
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed.
This is as boiled down as I can make it. ...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows Update option using the Control Panel or Settings app; it automatically checks for updates and installs any it finds, whether you like it or not. For...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then...
|
by: adsilva |
last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
|
by: muto222 |
last post by:
How can i add a mobile payment intergratation into php mysql website.
| | |
by: bsmnconsultancy |
last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating...
| |
