Re: [Python-Dev] Trial balloon: microthreads library in stdlib
On 2/10/07, Steve Holden <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] wrote: > > On Sun, Feb 11, 2007 at 03:35:29AM +0200, Yotam Rubin wrote: > >> Why don't you use Stackless? It's very simple, stable, and solves > >> quite completely the problems in writing concurrect code. > > > > That's a great point -- I'm not necessarily producing this to solve a > > problem I'm having. Rather, I think that the new language features in > > PEP 342 cry out for a batteries-included library that makes asynchronous > > programming both natural and easy. > > > Of course Stackless isn't quite fully integrated with 2.5 (yet). > > When did someone last suggest that Stackless become part of the core > CPython implementation, and why didn't that ever happen? > Don't remember the "when". The "why" has always been that Christian's hacks into the core were complicated and he didn't even think integration was worth it. -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Trial balloon: microthreads library in stdlib
Brett Cannon schrieb: >> Of course Stackless isn't quite fully integrated with 2.5 (yet). >> >> When did someone last suggest that Stackless become part of the core >> CPython implementation, and why didn't that ever happen? >> > > Don't remember the "when". The "why" has always been that Christian's > hacks into the core were complicated and he didn't even think > integration was worth it. With emphasis on the latter. Christian never proposed (to my knowledge) that Stackless should be integrated. Of course, he didn't propose it because he assumed that proposal would be turned down, anyway. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Does Python/Python-ast.c need to be checked in?
Someone checked in Parser/Python.asdl. After rebuilding Subversion tells me that Python/Python-ast.c has been modified. I assume the two are related. Did whoever checked in the former need to check in the latter (and maybe add a note to Misc/NEWS)? Skip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Trial balloon: microthreads library in stdlib
On 2/11/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > Brett Cannon schrieb: > >> Of course Stackless isn't quite fully integrated with 2.5 (yet). > >> > >> When did someone last suggest that Stackless become part of the core > >> CPython implementation, and why didn't that ever happen? > >> > > > > Don't remember the "when". The "why" has always been that Christian's > > hacks into the core were complicated and he didn't even think > > integration was worth it. > > With emphasis on the latter. Christian never proposed (to my knowledge) > that Stackless should be integrated. Of course, he didn't propose it > because he assumed that proposal would be turned down, anyway. As I understand it, given that at that time continuations and actually trying to make Python stackless were a goal of Stackless Python, I would hope people do not assume that the changes it currently makes to the core are the same as the ones mentioned here as hacks. Both of these goals have been discarded and Christian also made it an aim to make very few changes to the core and to "keep it and Stackless' intersection a minimum". One improvement Stackless needs related to what is proposed for the generator coroutines, is wrapping calls out of the Python runtime to things like network and file IO, so that microthreads can naturally take advantage of them. The asyncore module does the job for socket IO and allows monkeypatching the socket module so that the current microthread blocks on the asynchronous IO so the scheduler can continue without the whole runtime being stalled. But there is no support for cross- platform (specifically on Windows) asyncronous file IO for instance. If these generator coroutine microthreads went ahead and part of it was improving the support for asynchronous calls in the runtime and standard library, this would also be something which also benefited Stackless Python. Even if they didn't go ahead I would be interested in hearing about whether these sort of changes would be of interest or not for whatever reason. Regarding the port of Stackless to 2.5, it passes both its own (albeit limited) set of tests and the core's set as well. And there are no known bugs which affect general usage. Hope this helps, Richard. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Does Python/Python-ast.c need to be checked in?
On 2/11/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Someone checked in Parser/Python.asdl. After rebuilding Subversion tells me > that Python/Python-ast.c has been modified. I assume the two are related. > Did whoever checked in the former need to check in the latter Yeah, sorry about that. It took a ``make distclean`` for it to get regenerated for me. I checked in the updated version. > (and maybe add > a note to Misc/NEWS)? > That change to Parser/Python.asdl was cosmetic so there is no need for a NEWS entry. -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Trial balloon: microthreads library in stdlib
Richard Tew schrieb: > If these generator coroutine microthreads went ahead and part > of it was improving the support for asynchronous calls in the > runtime and standard library, this would also be something > which also benefited Stackless Python. Even if they didn't go > ahead I would be interested in hearing about whether these > sort of changes would be of interest or not for whatever reason. For me to respond to such a question, I first need to understand what changes precisely you propose. "wrapping calls out of the Python runtime to things like network and file IO, so that microthreads can naturally take advantage of them." is a bit vague: how precisely would you wrap them? I assume you would like to see operating system mechanism be used that currently aren't used (similar to the way asynchore uses select/poll). If so, what mechanism would you like to use, and on what systems? Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Does Python/Python-ast.c need to be checked in?
Brett Cannon schrieb: > On 2/11/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: >> Someone checked in Parser/Python.asdl. After rebuilding Subversion tells me >> that Python/Python-ast.c has been modified. I assume the two are related. >> Did whoever checked in the former need to check in the latter > > Yeah, sorry about that. It took a ``make distclean`` for it to get > regenerated for me. I checked in the updated version. Actually, the regenerating should happen immediately after commit, as this bumps the revision number of the asdl file. This means you have to make two commits per AST grammar change: one to change the grammar, and the other to update the regenerated file. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Trial balloon: microthreads library in stdlib
Hi Martin, On Sun, Feb 11, 2007 at 07:09:29PM +0100, "Martin v. L?wis" wrote: > > hacks into the core were complicated and he didn't even think > > integration was worth it. > > With emphasis on the latter. Christian never proposed (to my knowledge) > that Stackless should be integrated. Of course, he didn't propose it > because he assumed that proposal would be turned down, anyway. 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. On a side note, I also wrote "greenlets", which is a C extension module for the regular CPython that uses some code from Stackless to provide coroutines without changing the core. I have even built an experimental I/O library for it, which I'm using with some success, and I personally like the style; but I also know that it's a very subjective matter, so I'm happy to keep it outside the stdlib. As far as I gather from discussing with Christian, he has got a similar point of view. Armin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Does Python/Python-ast.c need to be checked in?
On 2/11/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > Actually, the regenerating should happen immediately after commit, > as this bumps the revision number of the asdl file. This means > you have to make two commits per AST grammar change: one to change > the grammar, and the other to update the regenerated file. 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.) -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] New syntax for 'dynamic' attribute access
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, method_name))
from Lib/distutils/dist.py could be rewritten
self.(method_name) = self.metadata.(method_name)
The new syntax would also be usable in augmented assignments, as in
obj.(attr_name) += 1
There was some discussion on python-ideas, which I've linked to in the
draft PEP below. In particular, Guido van Rossum wrote:
> I've thought of the same syntax. I think you should submit this to the
> PEP editor and argue on Python-dev for its inclusion in Python 2.6 --
> there's no benefit that I see of waiting until 3.0.
so here I am. Does anybody have any opinions/suggestions, particularly
on the "open questions" referred to in the draft PEP? To summarise
these open questions:
* 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, 'default string')
I agree that it looks odd, but perhaps the extra expressive power
gained might be worth the oddness.
* The draft implementation (a sourceforge patch, linked to in the draft
PEP) may have a general performance penalty of around 1%, although my
initial measurements were quite noisy. Josiah Carlson thought this
would not be too substantial, but he did suggest a couple of other
implementation routes which could be explored. The general
performance hit is offset by a speed gain of around 40% for attribute
access using the new syntax over getattr etc. Is 1% "too much" for
this feature?
Ben.
- - - - 8< - - - -
PEP: 363 [PROVISIONAL NUMBER]
Title: Syntax For Dynamic Attribute Access
Version: $Revision$
Last-Modified: $Date$
Author: Ben North
Status: Draft
Type: Standards Track
Content-Type: text/plain
Created: 29-Jan-2007
Post-History:
Abstract
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) += 1
z = y.('foo_%d' % n).('bar_%s' % s)
instead of
attr_name = 'foo_%d' % n
setattr(x, attr_name, getattr(x, attr_name) + 1)
z = getattr(getattr(y, 'foo_%d' % n), 'bar_%s' % s)
Note
(I wrote this patch mostly to advance my own understanding of and
experiment with the python language, but I've written it up in the
style of a PEP in case it might be a useful idea.)
Rationale
Dictionary access and indexing both have a friendly invocation
syntax: instead of x.__getitem__(12) the coder can write x[12].
This also allows the use of subscripted elements in an augmented
assignment, as in "x[12] += 1". The present proposal brings this
ease-of-use to dynamic attribute access too.
Attribute access is currently possible in two ways:
* When the attribute name is known at code-writing time, the
".NAME" trailer can be used, as in
x.foo = 42
y.bar += 100
* When the attribute name is computed dynamically at run-time, the
"getattr" and "setattr" builtins must be used:
x = getattr(y, 'foo_%d' % n)
setattr(z, 'bar_%s' % s, 99)
The "getattr" builtin also allows the coder to specify a default
value to be returned in the event that the object does not have
an attribute of the given name:
x = getattr(y, 'foo_%d' % n, 0)
This PEP describes a new syntax for dynamic attribute access ---
"x.(expr)" --- with examples given in the Abstract above. The new
syntax also allows the provision of a default value in the "get"
case, as in:
x = y.('foo_%d' % n, None)
This 2-argument form of dynamic attribute access is not permitted as
the target of an (augmented or normal) assignment. Also, this part
of the new syntax was not as well received [6] in initial
discussions on python-ideas, and I agree that it does not fit so
cleanly. I'm happy to prepare a revised PEP/patch without the
2-argument form if the consensus is that this would be preferred.
Finally, the new syntax can be used with the "del" statement, as in
del x.(attr_name)
Impact On Existing Code
The proposed new syntax is not currently valid, so no existing
well-formed programs have their meaning altered by this proposal.
Across all "*.py" files in the 2.5 distribution, there are around
600 uses of "getattr", "setattr" or "delattr". They break down as
follows (figures have some room for error because they were
arrived at by partially-manual inspection):
c.300 uses of plain "getattr(x, attr_name)", which could be
Re: [Python-Dev] New syntax for 'dynamic' attribute access
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, or to force a binding to the builtin "gettattr" at compile time (two common (ab)uses of default arguments)? If they are, they would be better served by the new syntax. Overall, +1 on obj.(attr_name) -0 on obj.(attr_name, default_value) Tim Delaney ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New syntax for 'dynamic' attribute access
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, method_name)) > > from Lib/distutils/dist.py could be rewritten > > self.(method_name) = self.metadata.(method_name) I like it. > The new syntax would also be usable in augmented assignments, as in > > obj.(attr_name) += 1 Even nicer; much, much better than the current spelling. > *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, 'default string') > > I agree that it looks odd, but perhaps the extra expressive power > gained might be worth the oddness. It's not just odd, but because you can't use the result of that syntax as an assignment target (according to the PEP), it smells special-casey. Neil ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Does Python/Python-ast.c need to be checked in?
On 2/11/07, Guido van Rossum <[EMAIL PROTECTED]> wrote: > On 2/11/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > > Actually, the regenerating should happen immediately after commit, > > as this bumps the revision number of the asdl file. This means > > you have to make two commits per AST grammar change: one to change > > the grammar, and the other to update the regenerated file. > > 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.) > Don't think so. How about this for wording for the file's documentation? /* File automatically generated by %s. This module must be committed separately from each AST grammar change; the __version__ number is set to the revision number of the commit containing the grammar change. */ -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New syntax for 'dynamic' attribute access
"Ben North" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] | so here I am. Does anybody have any opinions/suggestions, particularly | on the "open questions" referred to in the draft PEP? To summarise | these open questions: Need: Runtime attributes are a fairly frequent 'How?' question on c.l.p. Syntax: I initially did not like it and was surprised at its current invalidity (I expected the 'surperfluous' parens to be ignored) but could not think of anything better, and after 10 min. it looks better for a couple of reasons. First, I vaguely remember () being used for a similar purpose of indicating indirection in some assembly languages. Second, parens are already special cased as the call operator when following an object expression (without an intervening operator). So I can swallow a new special case when they follow '.'. The 'two-arg' form: this analogizes .() as being like a obj() call, but the sematics are different enough that I think it confuses. So I suggest drop it at least for now. Terry Jan Reedy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Does Python/Python-ast.c need to be checked in?
On Monday 12 February 2007 13:57, Brett Cannon wrote: > On 2/11/07, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > On 2/11/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > > > Actually, the regenerating should happen immediately after > > > commit, as this bumps the revision number of the asdl file. > > > This means you have to make two commits per AST grammar > > > change: one to change the grammar, and the other to update > > > the regenerated file. > > > > 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.) > > Don't think so. How about this for wording for the file's > documentation? > > /* >File automatically generated by %s. > >This module must be committed separately from each AST grammar > change; the __version__ number is set to the revision number of > the commit containing the grammar change. > */ Note that the welease.py script that builds the releases does a "touch" on the relevant files to make sure that make gets the build right. We had bugs opened at one point because the timestamps meant you needed a python interpreter to build python. I'm not _too_ stressed if the svn isn't always perfect in this regard - the number of people who are checking out svn to build their very first python interpreter would be low, I'd think. Anthony ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Does Python/Python-ast.c need to be checked in?
On 2/11/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > Brett Cannon schrieb: > > On 2/11/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > >> Someone checked in Parser/Python.asdl. After rebuilding Subversion tells > >> me > >> that Python/Python-ast.c has been modified. I assume the two are related. > >> Did whoever checked in the former need to check in the latter > > > > Yeah, sorry about that. It took a ``make distclean`` for it to get > > regenerated for me. I checked in the updated version. > > Actually, the regenerating should happen immediately after commit, > as this bumps the revision number of the asdl file. This means > you have to make two commits per AST grammar change: one to change > the grammar, and the other to update the regenerated file. > Revision 53751 adds a comment to Python-ast.c about this now, along with putting __version__ in the header as well. -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New syntax for 'dynamic' attribute access
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, 'default string') > > I agree that it looks odd, but perhaps the extra expressive power > gained might be worth the oddness. I don't think it is. getattr can just be kept around if need be in order to support this use case. It just makes it look like too much of a function call at that point to me, especially if someone ends up writing some expression that is so long that they put in a newline between the two values: s = obj.(attr_name, 'default_string') So -1 on the two-item version, +0 on the one-item version. -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New syntax for 'dynamic' attribute access
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. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New syntax for 'dynamic' attribute access
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, allusions to MATLAB and assembly indirection syntax not withstanding. Ignoring the syntax, I'm -1 on the 2-argument form, especially since it can only be used in an expression context; getattr() can be kept around for this. I'm +0 on the idea, -1 on the means. Collin Winter ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Trial balloon: microthreads library in stdlib
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 never actually submitted a patch for inclusion (at least not in public; he may have approached Guido in private). The oldest discussion I could find quickly is from August 2000 (Python 2.0 and Stackless); there, it was Ben Wolfson who asked whether it could be integrated. I also found a message where I said that it couldn't be integrated as-is, for a number of reasons I listed; I didn't mean to imply that it can never be integrated. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New syntax for 'dynamic' attribute access
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 like a syntax error" argument holds much weight, because any new syntax is likely to be a syntax error until the syntax is changed. :) "No hints" is a decent argument against it, though. Parenthesis are already used for tuples, function calls, precedence, and generator comprehensions. The more something gets overloaded, the more ambiguous it looks. How about obj.*str_expression instead? "*" is pretty common in the C family of languages as a dereferencing operator. Neil ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Does Python/Python-ast.c need to be checked in?
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! Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New syntax for 'dynamic' attribute access
On Monday 12 February 2007 18:38, Neil Toronto wrote: > 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 like a syntax error" argument holds much > weight, because any new syntax is likely to be a syntax error > until the syntax is changed. :) 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. > "No hints" is a decent argument > against it, though. Parenthesis are already used for tuples, > function calls, precedence, and generator comprehensions. The > more something gets overloaded, the more ambiguous it looks. How > about > >obj.*str_expression > > instead? "*" is pretty common in the C family of languages as a > dereferencing operator. I don't know. This all still smacks of magic line noise to me :-) Although I should also add that after thinking about it a bit, I'm still not convinced this is something that needs shorthand syntax - particularly not one that's so line-noisy... Hey, we could always use backticks in Python 3.0! Anthony ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Does Python/Python-ast.c need to be checked in?
Brett Cannon schrieb: > /* > File automatically generated by %s. > > This module must be committed separately from each AST grammar change; > the __version__ number is set to the revision number of the commit > containing the grammar change. > */ It doesn't completely show up in "svn diff" (when only the number changes). I don't think that's a problem. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Does Python/Python-ast.c need to be checked in?
Anthony Baxter schrieb: >>This module must be committed separately from each AST grammar >> change; the __version__ number is set to the revision number of >> the commit containing the grammar change. >> */ > > Note that the welease.py script that builds the releases does > a "touch" on the relevant files to make sure that make gets the > build right. We had bugs opened at one point because the timestamps > meant you needed a python interpreter to build python. > > I'm not _too_ stressed if the svn isn't always perfect in this > regard - the number of people who are checking out svn to build > their very first python interpreter would be low, I'd think. Still, an editor of Python.asdl should really commit Python-ast.c *after* committing Python.asdl (or perhaps committing it twice): not because of time stamps, but because the subsequent compile run will regenerate the file and modify it in the process. Then, all other developers will find modifications in their tree that they didn't make. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New syntax for 'dynamic' attribute access
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 think > it's a syntax error, allusions to MATLAB and assembly indirection > syntax not withstanding. > > Ignoring the syntax, I'm -1 on the 2-argument form, especially since > it can only be used in an expression context; getattr() can be kept > around for this. > > I'm +0 on the idea, -1 on the means. -1 here too. I fear that this gets too indistinguishable from normal calling syntax, leading to confusion. (Of course, one could propose other syntax, such as obj->(attr) or whatnot, but I doubt an ideal and Pythonic syntax can be found here...) To me, dynamic attribute access is something "special", and it justifies a different way of doing it, namely getattr and setattr. 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. Georg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
