On Fri, Feb 16, 2007 at 12:40:54PM +1300, Greg Ewing wrote:
The quote is actually a camel is a *racehorse* designed by a committee.
Camels are very good at surviving in the desert, but not so good at
winning a horse race (not camel race). Which is the point of the saying.
That changes the
I think a committee is better than nothing, and I believe CP4E has
been dropped from the agenda.
The general CP4E idea is part of the General Pythonic Ideal,
whatever it may be :P
--
EduardoOPadoan (eopadoan-altavix::com)
Bookmarks: http://del.icio.us/edcrypt
Oleg Broytmann schrieb:
That changes the meaning, but... have you ever tried to ride a horse
designed by a group of Clever Individuals loosely connected by email? ;) I
am afraid of even thinking of its ugliness and speed. (-:
I think a committee is better than nothing, and I believe CP4E
* Ben North [EMAIL PROTECTED] [2007-02-11 23:45:05 +]:
Dynamic attribute access is currently possible using the getattr
and setattr builtins. The present PEP suggests a new syntax to
make such access easier, allowing the coder for example to write
x.('foo_%d' % n)
A few of you have expressed concern about how would that look to a
newbie. Being one, this is what I think:
- The idea sounds good. Setattr and getattr seems both unpythonic and illegible.
- please.(dont_torture) =
me(with_dots,that_look,like.(function),calls). Ok, so the dot _is_
needed in
On Thu, Feb 15, 2007 at 12:48:48AM +, Steve Holden wrote:
Given that they say a camel is a horse designed by a committee
Metaphors can go that far but not farther. And, BTW, camels are very
suited for their environments...
I am not afraid of committees for large tasks. Well, that has
Oleg Broytmann wrote:
Given that they say a camel is a horse designed by a committee
BTW, camels are very suited for their environments...
The quote is actually a camel is a *racehorse* designed by a committee.
Camels are very good at surviving in the desert, but not so good at
winning a
Greg Ewing wrote:
Oleg Broytmann wrote:
Given that they say a camel is a horse designed by a committee
BTW, camels are very suited for their environments...
The quote is actually a camel is a *racehorse* designed by a
committee. Camels are very good at surviving in the desert, but not
Greg Ewing wrote:
Oleg Broytmann wrote:
Given that they say a camel is a horse designed by a committee
BTW, camels are very suited for their environments...
The quote is actually a camel is a *racehorse* designed by a committee.
Camels are very good at surviving in the desert, but not so
Hi Michael,
On Tue, Feb 13, 2007 at 11:55:46PM +, Michael Foord wrote:
x = *('variable%d' % n)
f(a, b, *('keyword%d' % n) = c)
class *('33strangename'):
pass
def *(funcname)(x, y, *(argname), *args, **kwds):
pass
import *modname as mymodule
Oleg Broytmann wrote:
On Tue, Feb 13, 2007 at 10:10:37AM +, Steve Holden wrote:
Python further away from the Computer Programming for Everyone arena
and closer to the Systems Programming for Clever Individuals camp.
That's because Python is being developed by Clever Individuals and
On Wed, Feb 14, 2007 at 03:24:30PM +, Steve Holden wrote:
Oleg Broytmann wrote:
On Tue, Feb 13, 2007 at 10:10:37AM +, Steve Holden wrote:
Python further away from the Computer Programming for Everyone arena
and closer to the Systems Programming for Clever Individuals camp.
Oleg Broytmann wrote:
On Wed, Feb 14, 2007 at 03:24:30PM +, Steve Holden wrote:
Oleg Broytmann wrote:
On Tue, Feb 13, 2007 at 10:10:37AM +, Steve Holden wrote:
Python further away from the Computer Programming for Everyone arena
and closer to the Systems Programming for Clever
Martin v. Löwis schrieb:
Ron Adam schrieb:
I think it's gets a bit awkward in some situations.
if bar-'__%s__' % attr -42: print 'Hello World'
if bar.['__%s__' % attr] -42: print 'Hello World'
To me it's easier to parse the second one visually.
Ah, precedence.
It
Ben North wrote:
Hi,
A few days ago I posted to python-ideas with a suggestion for some new
Python syntax, which would allow easier access to object attributes
where the attribute name is known only at run-time. For example:
setattr(self, method_name, getattr(self.metadata,
On 13/02/07, Anthony Baxter [EMAIL PROTECTED] wrote:
The killer problem with backticks (to pick the syntax that currently
causes this problem the most) is with webpages and with printed
books with code. Sure, everyone can pick a font for coding that
they can read, but that's not the only way
On 13/02/2007 7.39, Martin v. Löwis wrote:
And again. Apparently, people favor hasattr over catching
AttributeError. I'm not sure why this is -
Because the code becomes longer, unless you want to mask other exceptions:
name = 'http_error_%d' % errcode
-if hasattr(self, name):
-method
On 13/02/2007 5.33, Maric Michaud wrote:
I really dislikes the .[ or .( or .{ operators.
Just on my mail editor the two expressions
a.[b]
and
a,[b]
are quite hard to differentiate while completely unrelated.
I'll propose a new color for this bikeshed:
a.[[b]]
handlers =
Taking a step back a bit... the basic issue is that we have an attribute
namespace (compile time key determination) that we want to access in a
dictionary style (runtime key determination).
This is currently done by switching from syntactic access to the
getattr/setattr/delattr builtin
Nick Coghlan wrote:
I've tried this out on Brett's urllib urllib2 examples below. (calling
the new builtin attrview() to emphasise the fact that it retains a
reference to the original instance).
Ooh, ooh! I wanna change my vote! +1 on attrview(), +0.25 on .[].
Maybe I haven't written
On 2/13/07, Nick Coghlan [EMAIL PROTECTED] wrote:
Taking a step back a bit... the basic issue is that we have an attribute
namespace (compile time key determination) that we want to access in a
dictionary style (runtime key determination).
This is currently done by switching from syntactic
On 2/13/07, Nick Coghlan [EMAIL PROTECTED] wrote:
[snip]
I've tried this out on Brett's urllib urllib2 examples below. (calling
the new builtin attrview() to emphasise the fact that it retains a
reference to the original instance). I don't consider it any uglier than
the proposed syntax
On 2/13/07, Nick Coghlan [EMAIL PROTECTED] wrote:
[snip]
I've tried this out on Brett's urllib urllib2 examples below. (calling
the new builtin attrview() to emphasise the fact that it retains a
reference to the original instance). I don't consider it any uglier than
the proposed syntax
Hi,
On Mon, Feb 12, 2007 at 12:38:27AM -0700, Neil Toronto wrote:
obj.*str_expression
x = *('variable%d' % n)
f(a, b, *('keyword%d' % n) = c)
class *('33strangename'):
pass
def *(funcname)(x, y, *(argname), *args, **kwds):
pass
import *modname as
Armin Rigo wrote:
Hi,
On Mon, Feb 12, 2007 at 12:38:27AM -0700, Neil Toronto wrote:
obj.*str_expression
x = *('variable%d' % n)
f(a, b, *('keyword%d' % n) = c)
class *('33strangename'):
pass
def *(funcname)(x, y, *(argname), *args, **kwds):
Martin v. Löwis wrote:
Apparently, people favor hasattr over catching
AttributeError. I'm not sure why this is - I would probably
rewrite them all to deal with AttributeError if I use the new
syntax in the first place.
Actually, I prefer using getattr with a default value over
either of
Martin v. Löwis wrote:
BTW, which of these would be correct
My thoughts would be
(a).[b] Okay
(a.)[b] Not okay
a.[(b)] Okay
a.([b]) Not okay
a . [ b ]Okay
and what is the semantics of
a.[42]
The same as getattr(a,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Feb 13, 2007, at 7:24 PM, Greg Ewing wrote:
I'm still -1 on the basic idea, though, on the grounds of
YAGNIOE (You Aren't Going to Need It Often Enough).
I can't really add much more than what's already be stated, but I
echo Greg's sentiment.
Martin v. Löwis wrote:
OTOH, you can't write
x + = 2
or
a = 2 * * 4
Although oddly enough you *can* write
a[. . .]
I guess whoever added the ellipsis couldn't be bothered
defining a new token for it.
It's something of an arbitrary choice, but to me it just
seems that the
This seems to be the overwhelming feedback at this point, so I'm
withdrawing my support for the proposal. I hope that Ben can write up
a PEP and mark it rejected, to summarize the discussion; it's been a
useful lesson. Occasinoally, negative results are worth publishing!
On 2/13/07, Barry Warsaw
On 2/13/07, Greg Ewing [EMAIL PROTECTED] wrote:
Martin v. Löwis wrote:
OTOH, you can't write
x + = 2
or
a = 2 * * 4
Although oddly enough you *can* write
a[. . .]
I guess whoever added the ellipsis couldn't be bothered
defining a new token for it.
But if we ever
Guido van Rossum wrote:
But if we ever turn it into a single token (which we just may for
Py3k) don't complain if your code breaks.
I won't. I always treat it as a single token
anyway, unless I'm entering an obfuscated
python competition. :-)
--
Greg
On 12-feb-2007, at 0:45, Ben North wrote:
self.(method_name) = self.metadata.(method_name)
I like the functionality, but I don't like the syntax, to me it looks
too much like a method call.
To me self.[method_name] = self.metadata.[method_name] looks better:
what we're doing here is
Terry Reedy wrote:
Need: Runtime attributes are a fairly frequent 'How?' question on c.l.p.
That's true, but how many of those are due to an actual
need for runtime attributes, as opposed to someone trying
to transplant idioms from another language that would be
better served by a dict?
In my
Georg Brandl wrote:
For the speed argument -- there were quite a few proposals to take builtins as
constants under certain conditions, in which case getattr() usage could be
optimized just as well as new syntax.
Even more aggressively, the compiler could recognise it
and make a direct call to
[Jack Jansen]
I like the functionality, but I don't like the syntax, to me it looks
too much like a method call.
To me self.[method_name] = self.metadata.[method_name] looks better:
what we're doing here is more like dictionary lookup than calling
functions.
I also like the functionality.
On 2/11/07, Ben North [EMAIL PROTECTED] wrote:
Hi,
A few days ago I posted to python-ideas with a suggestion for some new
Python syntax, which would allow easier access to object attributes
where the attribute name is known only at run-time. For example:
setattr(self, method_name,
Ben North wrote:
Jack Jansen:
To me self.[method_name] = self.metadata.[method_name] looks better:
what we're doing here is more like dictionary lookup than calling
functions.
In the same way, though, would this be viewed as too similar to normal
dictionary/list indexing?
I
On 2007-02-12 16:19, Georg Brandl wrote:
Tim Delaney asked in particular:
Have you checked if [the existing uses of getattr, where getattr in
that scope is a function argument with default value the built-in
getattr] are intended to bring the getattr name into local scope
for fast lookup, or
My perspective:
- There's a lot of support for the basic idea, and only a few
naysayers, so let's keep looking for a syntax that works.
- There's near-universal dislike for the two-arg form, so let's drop
that part of the proposal.
- I can't recall that x.[y] has been proposed yet, but thinking
On Mon, 12 Feb 2007 18:50:35 +1100, you wrote:
Yes and no. My point is that it's extremely similar to existing
syntax. (Worse yet, it looks the same but for what's possibly the
smallest and hardest-to-see character in any character set)
foo(baz) vs foo.(baz) is... not good.
To me (as a newbee
[Raymond Hettinger]
Rather than munge existing syntaxes, an altogether new one would be
more clear:
self-name = self.metadata-name
[Ben North]
One thing which comes to mind about this one is that, for C/C++
programmers, the difference between
obj.memberand
Guido van Rossum schrieb:
PS Thanks to Ben for excellent summaries of the discussion so far!
I'd like to second this. This is how PEPs ought to work.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
On 2/12/07, Raymond Hettinger [EMAIL PROTECTED] wrote:
[Jack Jansen]
I like the functionality, but I don't like the syntax, to me it looks
too much like a method call.
To me self.[method_name] = self.metadata.[method_name] looks better:
what we're doing here is more like dictionary
On 2/12/07, Raymond Hettinger [EMAIL PROTECTED] wrote:
[Raymond Hettinger]
Rather than munge existing syntaxes, an altogether new one would be
more clear:
self-name = self.metadata-name
[Ben North]
One thing which comes to mind about this one is that, for C/C++
programmers, the
On 2/12/07, Brett Cannon [EMAIL PROTECTED] wrote:
On 2/12/07, Raymond Hettinger [EMAIL PROTECTED] wrote:
[Jack Jansen]
I like the functionality, but I don't like the syntax, to me it looks
too much like a method call.
To me self.[method_name] = self.metadata.[method_name] looks
FWIW, I'm strongly -1 on the - notation. As a C programmer it's got
too many neurons committed to it.
I recommend that you do some experiments with the readability of the
.[...] notation, e.g. write a program that randomly generates x.[foo]
and x[foo], and see how fast you can spot the
Is even more syntactic sugar really what Python really needs?
--
mvh Björn
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
Ben North wrote:
Generally gently positive, with the exception of Anthony Baxter's
-1, which I understand to be motivated by concerns about newcomers to
the syntax
The more I think about it, the more I'm leaning
towards -1 as well. Adding syntax is a very big
step, and it needs a very solid
On 2/12/07, BJörn Lindqvist [EMAIL PROTECTED] wrote:
Is even more syntactic sugar really what Python really needs?
Yes, I need my fix!!!
my 2 cents:
I'm +1 on either the '.(name)' or '.[name]' syntax. I'm leaning more
towards the parentheses though. I don't really buy into the argument
that
2007/2/12, Benji York [EMAIL PROTECTED]:
Collin Winter wrote:
There's a connection, but I'd say it's the wrong one. In C, x-y
dereferences x, while in Python, x-y would dereference y. That's
just begging for trouble.
Then the syntax should obviously be x-y.
delurk
Someone with OCaml
On 2/12/07, Guido van Rossum [EMAIL PROTECTED] wrote:
FWIW, I'm strongly -1 on the - notation. As a C programmer it's got
too many neurons committed to it.
I recommend that you do some experiments with the readability of the
.[...] notation, e.g. write a program that randomly generates
Benji York wrote:
Collin Winter wrote:
On 2/12/07, Brett Cannon [EMAIL PROTECTED] wrote:
I actually kind of like that. The connection to pointer indirection
meshes well with the idea of indirectly figuring out what attribute
to access at runtime.
There's a connection, but I'd say it's
On Tuesday 13 February 2007 10:10, Ben North wrote:
(Gently wandering off-topic,
but: do people use proportional fonts for coding? Doesn't it
cause general awkwardness for indentation, especially relevant
for python?)
The killer problem with backticks (to pick the syntax that currently
Brett Cannon wrote:
On 2/12/07, Guido van Rossum [EMAIL PROTECTED] wrote:
I recommend that you do some experiments with the readability of the
.[...] notation, e.g. write a program that randomly generates x.[foo]
and x[foo], and see how fast you can spot the difference. I bet that
you won't
Oh, now I am definitely in favor of .[]! I read it in gmail in FireFox
which uses a small variable-pitch font whose dot is a single pixel.
The .() example was hard to find; the .[] jumped out immediately.
(When do you ever see self[anything]?)
On 2/12/07, Brett Cannon [EMAIL PROTECTED] wrote:
On
Raymond Hettinger wrote:
Rather than munge existing syntaxes, an altogether new one would be more
clear:
self-name = self.metadata-name
My problem with this is that it isn't a name. It should grammatically
be a test (i.e. it can take on the expression any function argument
could
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Feb 12, 2007, at 7:32 PM, Guido van Rossum wrote:
Oh, now I am definitely in favor of .[]! I read it in gmail in FireFox
which uses a small variable-pitch font whose dot is a single pixel.
The .() example was hard to find; the .[] jumped out
A few of you have expressed concern about how would that look to a
newbie. Being one, this is what I think:
(again, newbie alert)
- The idea sounds good. Setattr and getattr seem kinda unpythonic and
difficult to read.
- please.(dont_torture) =
me(with_dots,that_look,like.(function),calls). Ok,
Barry Warsaw wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Feb 12, 2007, at 7:32 PM, Guido van Rossum wrote:
Oh, now I am definitely in favor of .[]! I read it in gmail in FireFox
which uses a small variable-pitch font whose dot is a single pixel.
The .() example was hard to
Le mardi 13 février 2007 01:36, Barry Warsaw a écrit :
On Feb 12, 2007, at 7:32 PM, Guido van Rossum wrote:
Oh, now I am definitely in favor of .[]! I read it in gmail in FireFox
which uses a small variable-pitch font whose dot is a single pixel.
The .() example was hard to find; the .[]
M.-A. Lemburg [EMAIL PROTECTED] wrote:
You can add a -1 from me to the list as well: I don't think that
dynamic lookups are common enough to warrant new syntax.
I agree. Also, I think the special syntax may make them too
inviting to new programmers, who haven't figured out that usually
there
On 2/12/07, Maric Michaud [EMAIL PROTECTED] wrote:
Le mardi 13 février 2007 01:36, Barry Warsaw a écrit:
On Feb 12, 2007, at 7:32 PM, Guido van Rossum wrote:
Oh, now I am definitely in favor of .[]! I read it in gmail in FireFox
which uses a small variable-pitch font whose dot is a single
Brett Cannon schrieb:
name = 'open_' + urltype
self.type = urltype
name = name.replace('-', '_')
if not hasattr(self, name):
if proxy:
return self.open_unknown_proxy(proxy, fullurl, data)
else:
return
Ron Adam schrieb:
I think it's gets a bit awkward in some situations.
if bar-'__%s__' % attr -42: print 'Hello World'
if bar.['__%s__' % attr] -42: print 'Hello World'
To me it's easier to parse the second one visually.
Ah, precedence.
It definitly should be a bracketed
Ben North wrote:
c.5 uses which would have to stay as getattr because they
are calls of a variable named getattr whose default
value is the builtin getattr;
Have you checked if these are intended to bring the getattr name into
local scope for fast lookup,
On 2/11/07, Ben North [EMAIL PROTECTED] wrote:
[SNIP]
* The draft currently allows a two-argument form, to supply a default
value if the object has no attribute of that name. This mimics the
behaviour of the three-argument form of getattr, but looks a bit wrong:
s = obj.(attr_name,
I have to say that I'm not that impressed by either the 1-arg or
2-arg versions. Someone coming across this syntax for the first
time will not have any hints as to what it means - and worse, it
looks like a syntax error to me. -1 from me.
___
I like the general idea, but the syntax looks like dirt on my monitor.
The period is too easy to lose visually and without it, there's
nothing to distinguish this from a function call. Also, like Anthony
Baxter said, someone coming across this for the first time will think
it's a syntax error,
Anthony Baxter wrote:
I have to say that I'm not that impressed by either the 1-arg or
2-arg versions. Someone coming across this syntax for the first
time will not have any hints as to what it means - and worse, it
looks like a syntax error to me. -1 from me.
I'm not sure the looks
Collin Winter schrieb:
I like the general idea, but the syntax looks like dirt on my monitor.
The period is too easy to lose visually and without it, there's
nothing to distinguish this from a function call. Also, like Anthony
Baxter said, someone coming across this for the first time will
71 matches
Mail list logo
