Martin v. Löwis schrieb:
Guido van Rossum schrieb:
Is this documented somewhere? It wouldn't hurt if there was a pointer
to that documentation right next to the line in Python-ast.c that gets
modified by the regeneration. (I've been wondering about this a few
times myself.)
Done!
I didn't
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,
Thanks for the comments so far on this. First, on the general idea:
Neil Toronto:
I like it.
[...]
obj.(attr_name) += 1
Even nicer; much, much better than the current spelling.
Brett Cannon:
+0 on the one-item version.
Anthony Baxter:
-1 from me.
Collin Winter:
I like the general
Apologies: I overlooked a couple of replies in my summary earlier. Tim
Delaney and Terry Reedy both responded in positive terms to the
one-argument form and its syntax, and in negative terms to the
two-argument form.
Also, I missed the fact that Neil Toronto had made the same point as me
when he
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
I was wondering today how I could convince myself that a sequence of
Py_CLEAR() calls in a tp_clear function was safe. Take for example a
really trivial sequence of code on frame_clear():
Py_CLEAR(f-f_exc_type);
Py_CLEAR(f-f_exc_value);
Py_CLEAR(f-f_exc_traceback);
* Richard Tew [EMAIL PROTECTED] [2007-02-12 13:46:43 +]:
I currently use Windows. By using asyncore and monkeypatching in a
replacement socket module based on it [1] I can give users of Stackless
socket operations which invisibly block at the microthread level allowing
the scheduler to
On 2/12/07, Tristan Seligmann [EMAIL PROTECTED] wrote:
* Richard Tew [EMAIL PROTECTED] [2007-02-12 13:46:43 +]:
Perhaps there is a better way. And I of course have no concept of
how this might be done on other platforms.
Building on an existing framework that does this seems better
I propose modifying PyString_InternInPlace to better cope with string
subtype instances.
Current implementation of PyString_InternInPlace does nothing and
returns if passed an instance of a subtype of PyString_Type. This is a
problem for applications that need to support string subtypes, but
On 2/12/07, Martin v. Löwis [EMAIL PROTECTED] wrote:
Armin Rigo schrieb:
The history as I remember it is that Christian tried hard to integrate
the first versions of Stackless with CPython, but was turned town by
python-dev.
Are there public records of that? As I remember it, Christian
Looking for where tp_clear() is being called, the only caller is line
713 in gmodule.c, which explicitly surrounds the call with an
INCREF/DECREF pair. Perhaps that's the clue you're looking for?
--Guido
On 2/12/07, Jeremy Hylton [EMAIL PROTECTED] wrote:
I was wondering today how I could
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
On 2/12/07, Guido van Rossum [EMAIL PROTECTED] wrote:
Looking for where tp_clear() is being called, the only caller is line
713 in gmodule.c, which explicitly surrounds the call with an
INCREF/DECREF pair. Perhaps that's the clue you're looking for?
Yes, of course. The INCREF guarantees that
Richard Tew wrote:
See A Bit Of History
http://svn.python.org/view/stackless/trunk/Stackless/readme.txt
I admit that I haven't given Stackless more than a cursory look over,
but it seems to me that the real source of its complexity is because its
trying to add a fundamental architectural
Richard Tew schrieb:
I can't point you to the posts, but I can point you to something
Christian has written on the subject which may indicate why
it was never actually submitted for inclusion.
See A Bit Of History
http://svn.python.org/view/stackless/trunk/Stackless/readme.txt
I have not
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, Hrvoje Nikšić [EMAIL PROTECTED] wrote:
cause problems for other users of the interned string. I agree with the
reasoning, but propose a different solution: when interning an instance
of a string subtype, PyString_InternInPlace could simply intern a copy.
Interning currently
[Jeremy Hylton]
I was wondering today how I could convince myself that a sequence of
Py_CLEAR() calls in a tp_clear function was safe. Take for example a
really trivial sequence of code on frame_clear():
Py_CLEAR(f-f_exc_type);
Py_CLEAR(f-f_exc_value);
Mike Klaas schrieb:
cause problems for other users of the interned string. I agree with the
reasoning, but propose a different solution: when interning an instance
of a string subtype, PyString_InternInPlace could simply intern a copy.
Interning currently requires an external reference to
Hrvoje Nikšić schrieb:
The patch could look like this. If there is interest in this, I can
produce a complete patch.
I can't see a problem with that (although I do wonder why people create
string subtypes in the first place).
Regards,
Martin
___
Hrvoje Nikic [EMAIL PROTECTED] wrote:
I propose modifying PyString_InternInPlace to better cope with string
subtype instances.
Any particular reason why the following won't work for you?
_interned = {}
def intern(st):
#add optional type checking here
if st not in _interned:
Martin v. Löwis [EMAIL PROTECTED] wrote:
Richard Tew schrieb:
but at that stage I need to
poll two different resources for events. In order to avoid this it makes
sense to stop using asyncore for sockets and to write a new
replacement socket object based on IO completion ports.
I
Sidnei da Silva asked on the pybots mailing list if we should be
testing packages with py3k. I think it's probably too early for that,
but on the other hand I'm sure many package creators/maintainers would
be curious to see how their packages fare with py3k.
So is there any value or interest in
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:
Guido van Rossum wrote:
- There's near-universal dislike for the two-arg form, so let's drop
that part of the proposal.
This is a strong consensus, definitely, so we can conclude that this
point has been decided. I will remove it from the PEP.
Guido also wrote:
- There's a lot of support
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
Richard Tew wrote:
The ideal mechanism at the high level would be expanding asyncore into
a one-stop shop. Where all these things can be passed into it and
it can do the work to notify of events on the objects in a standard way.
+1. This sounds like an excellent idea. It's downright
silly
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
Talin wrote:
What I am getting at is that rather that doing heroic efforts to add
stackless-ness to the current Python code base without changing it,
instead define a migration path which allows Python to eventually
acquire the characteristics of a stackless implementation.
I think you've
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
I've been working this past week at converting the stdlib's compiler
package to use 2.5's new _ast module instead of the package's own AST.
Overall, _ast was a joy to work with, save for the following nitpicks:
1) There are times when the _fields attribute on some AST nodes is
None; if this was
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
On Tue, Feb 13, 2007 at 12:33:46PM +1300, Greg Ewing wrote:
Richard Tew wrote:
The ideal mechanism at the high level would be expanding asyncore into
a one-stop shop. Where all these things can be passed into it and
it can do the work to notify of events on the objects in a standard way.
On 2/12/07, Collin Winter [EMAIL PROTECTED] wrote:
I've been working this past week at converting the stdlib's compiler
package to use 2.5's new _ast module instead of the package's own AST.
Overall, _ast was a joy to work with, save for the following nitpicks:
1) There are times when the
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,
Josiah Carlson wrote:
def intern(st):
...
If I remember the implementation of intern correctly, that's more or
less what happens under the covers.
That doesn't quite give you everything that real interning
does, though. The string comparison method knows when both
strings are interned,
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
Patch / Bug Summary
___
Patches : 417 open ( -6) / 3565 closed (+12) / 3982 total ( +6)
Bugs: 960 open ( -3) / 6498 closed (+19) / 7458 total (+16)
RFE : 266 open ( +6) / 251 closed ( +1) / 517 total ( +7)
New / Reopened Patches
__
stream
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
Greg Ewing schrieb:
The other thing is that, even if some kind of migration
path could be found, Guido et al wouldn't want to follow
that path anyway -- because the end result would be too
convoluted for ordinary people to understand and maintain.
That very much depends on what the end result
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
Collin Winter schrieb:
1) There are times when the _fields attribute on some AST nodes is
None; if this was done to indicate that a given node has no
AST-related attributes, it would be much easier if _fields was [] in
this case. As it is, I had to special-case node._fields is None in
the
62 matches
Mail list logo
