Re: [Python-Dev] Does Python/Python-ast.c need to be checked in?
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 notice that my commit failed because my code wasn't up-to-date. So it's done, but not my doing (but Brett's). Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org 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 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 more like dictionary lookup than calling functions. -- Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Python-Dev mailing list Python-Dev@python.org 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
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 experience, the amount of code which truly needs to use getattr is extremely small. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | Carpe post meridiem! | Christchurch, New Zealand | (I'm not a morning person.) | [EMAIL PROTECTED] +--+ ___ Python-Dev mailing list Python-Dev@python.org 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
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 the __getattr__ method, or maybe even have a new opcode for doing that. In other words, "special syntax" doesn't necessarily have to look like special syntax. :-) -- Greg ___ Python-Dev mailing list Python-Dev@python.org 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
[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. Rather than munge existing syntaxes, an altogether new one would be more clear: self->name = self.metadata->name I like the arrow syntax because is the lookup process can be more involved than a simple dictionary lookup (perhaps traveling up to base classes). IOW, getattr(a,n) is not always the same as a.__dict__[n]. The a.__getattribute__(n) process can be more complex than that and a bracketed dictionary-like syntax would misleadingly mask the lookup process. Raymond ___ Python-Dev mailing list Python-Dev@python.org 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: 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 -1 from me. It does not solve a common problem, therefore it does not deserve a special syntax. Moreover, the existing syntax may be longer to type but is far more readable. -- Gustavo J. A. M. Carneiro "The universe is always one step beyond logic." ___ Python-Dev mailing list Python-Dev@python.org 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
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 idea [...] I'm +0 on the idea
Jack Jansen:
> I like the functionality,
Raymond Hettinger:
> I also like the functionality.
Generally gently positive, with the exception of Anthony Baxter's
"-1", which I understand to be motivated by concerns about newcomers to
the syntax:
> 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.
This was echoed by Collin Winter:
> 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. [...] -1 on the means.
I think the argument "someone who hasn't come across it before won't
know what it is" could be applied to any new syntax, for instance the
new "with" statement, or going further back in time, the introduction of
Booleans, semantics of "__slots__", the "extended print" syntax, the
"list comprehension" syntax, the "augmented assignment" syntax, etc.
Some of these were perhaps more transparent than others, but for
instance "with" needs a bit of study to fully understand what's going
on. I would argue that the newness itself is not sufficient reason to
reject this.
Also, I think it's a good thing that it looks like a syntax error --- it
*is* currently a syntax error. A newcomer will be alerted to the fact
that something new is going on and will know to go and find out about
it. I am happy to write a paragraph for the "what's new" release notes,
and/or new section(s) for the documentation describing the new syntax.
On the two-argument form, feeling was generally pretty negative, with a
few "-1"s thrown in. I propose to cut this piece out of the PEP,
leaving just the one-argument form. If a default value is required, the
coder can still use the three-argument form of "getattr". To be clear
(and I'll put this in the PEP), I'm *not* suggesting that python loses
"getattr", "setattr", or "delattr".
On the syntax:
Brett Cannon:
> It just makes it look like too much of a function call at that point
> to me
Collin Winter:
> 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.
Jack Jansen:
> I don't like the syntax, to me it looks too much like a method call.
(Some of the initial comments in python-ideas were along these lines
too.) My personal opinion is that "obj.(foo)" is distinct enough from
"obj(foo)" to not cause confusion, but perhaps in a proportional font it
is less clear.
Some people made concrete suggestions as to what syntax could be used
instead:
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?
Raymond Hettinger:
> Rather than munge existing syntaxes, an altogether new one would be
> more clear:
>
>self->name = self.metadata->name
One thing which comes to mind about this one is that, for C/C++
programmers, the difference between
obj.memberand obj->member
is the interpretation of the thing on the *left* of the dot or arrow,
whereas the PEP is discussing a new interpretation of the thing on the
*right* of the dot.
One idea mentioned in the PEP is to bring {}s into service here, but I
think the dot should be kept to keep it looking like an attribute
access. What would the reaction be to
obj.{member}
instead? Braces are already used to construct dictionaries, so this has
some of the right connotations. It could not be confused with either a
function call or a dictionary lookup/list indexing.
(Nobody had any comments on the potential 1% performance hit --- is this
because it's too early to worry about implementation details?)
Thanks,
Ben.
___
Python-Dev mailing list
Python-Dev@python.org
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: > 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 was meaning wrapping on the Stackless side of things and it was not meant as a reference to how better support for asynchronous calls might be added. You can see how wrapping is done with Stackless channels in the examples I linked to at the end of this mail on the off chance you were curious about that instead and I am happy to give any further detail needed. > 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). Yes. > If so, what mechanism would you like to use, and on what systems? It depends what you mean by mechanism. I can't go into low level details because I do not have the necessary experience or knowledge to know which approach would be best. But I do have some general thoughts and would be willing to do any work involved, if there was a feasible solution and the changes required were thought worthwhile. Let me describe the situation I currently face in order to give context, please excuse the Windows specifics and the lack of consideration for other platforms. 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 continue to run. However there is no support for asynchronous file IO. Now I can monkeypatch in a replacement file object which uses IO completion ports [2], 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. Then there are other calls which come into the mix. Like in the subprocess module. As I understand it I would need to monkeypatch the Popen.wait, and os.waitpid calls so that they were polled internally to the monkeypatching and Stackless could handle the wake up of the caller there as well. And there might be other blocking calls in the runtime which it would be worth handling also, which might not have methods any way of operating asynchronously (like sockets, files and subprocesses). 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. However even if this were judged feasible, one immediate hurdle is that files passed to it would need to have been opened in overlapped mode for IO completion ports could be used with it. I presume generally opening all files in overlapped mode on Windows would address this thought. And I guess all the other "stuff" which does not relate to IO completion ports like subprocesses would be bundled into a WaitForMultipleObject call. Perhaps there is a better way. And I of course have no concept of how this might be done on other platforms. Thanks, Richard. [1] http://svn.python.org/view/stackless/sandbox/examples/stacklesssocket.py [2] http://svn.python.org/view/stackless/sandbox/libraries/slpmonkeypatch/resources/iocp.py ___ Python-Dev mailing list Python-Dev@python.org 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
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 said: > 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. :) he also suggested: >obj.*str_expression but I'm a bit uneasy about this, although the similarity with C's dereferencing is in its favour. Also, '*' in python is already used for "and the rest" arguments in function calls. Anthony Baxter cooled off a bit on the idea too: > after thinking about it a bit, I'm still not convinced this is > something that needs shorthand syntax Maybe not, but for the cases where you do want to do dynamic attribute access, I think there is a win in readability from nested getattr and/or setattr calls. Georg Brandl: > -1 here too. I fear that this gets too indistinguishable from normal > calling syntax, I think, from the context, that this is "-1" on the syntax rather than the idea as a whole, but I could have misread Georg's message. Possibly a "-0" on the idea? Greg Ewing: > In my experience, the amount of code which truly needs > to use getattr is extremely small. Another "-0"? Gustavo Carneiro: > -1 from me. It does not solve a common problem, therefore it does not > deserve a special syntax. It's not *that* uncommon, judging by the c.600 uses in the existing library code. > Moreover, the existing syntax may be longer > to type but is far more readable. I disagree, although I can see that there might be a small time during which one is getting familiar with the new syntax. Others have voiced the opinion that it's a readability win. 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 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. They're all in Lib/codecs.py, and are of the form: class StreamRecoder: def __getattr__(self, name, getattr=getattr): """ Inherit all other methods from the underlying stream. """ return getattr(self.stream, name) Without digging deeper into that code I'm afraid I can't say precisely what is going on. Ben. ___ Python-Dev mailing list Python-Dev@python.org 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:
> Thanks for the comments so far on this.
Count me as a +0 on the general idea, -1 on the specific proposed syntax
(based on the 'syntax shall not look like grit on Tim's monitor'
guideline, and the fact that nested parentheses make it hard to separate
the dynamic attribute lookup from function calls in the same expression)
I'd probably be +0 for a "x.{some_str}" brace based syntax, with the
caveat that I think this would also prevent future use of the
"x{whatever}" syntax. The 'probably' is based on the fact that I'd like
to see some examples of standard library code converted to that syntax.
And a -1 on the two argument version either way (we can keep getattr
around for that).
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http://www.boredomandlaziness.org
___
Python-Dev mailing list
Python-Dev@python.org
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 schrieb: > 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 said: >> 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. :) IMO there's a difference between e.g. "with" and this new syntax. Looking at code that uses the "with" statement, one cannot think other than "ah, a new keyword, let's look what it means". Here, when someone comes across "obj.(name)" the situation is different. You also have to take into account that not all programmers know the language to the fullest extent, so it won't only be newbies who'll be confused and probably say "hey, that doesn't look right to me". > he also suggested: >>obj.*str_expression > > but I'm a bit uneasy about this, although the similarity with C's > dereferencing is in its favour. Also, '*' in python is already used for > "and the rest" arguments in function calls. Additionally, if you want to use a more complicated expression, you'll still have to put parentheses there. > Anthony Baxter cooled off a bit on the idea too: >> after thinking about it a bit, I'm still not convinced this is >> something that needs shorthand syntax > > Maybe not, but for the cases where you do want to do dynamic attribute > access, I think there is a win in readability from nested getattr and/or > setattr calls. As said in the "grit" argument, not necessarily. It's more easily overlooked that "getattr". > Georg Brandl: >> -1 here too. I fear that this gets too indistinguishable from normal >> calling syntax, > > I think, from the context, that this is "-1" on the syntax rather than > the idea as a whole, but I could have misread Georg's message. Possibly > a "-0" on the idea? A +0 on the idea, but as I wrote in that post, I doubt an ideal and Pythonic syntax can be found here. > 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 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. > > They're all in Lib/codecs.py, and are of the form: > > class StreamRecoder: > def __getattr__(self, name, > getattr=getattr): > > """ Inherit all other methods from the underlying stream. > """ > return getattr(self.stream, name) > > Without digging deeper into that code I'm afraid I can't say precisely > what is going on. Since that is a special method and ought to have the signature __getattr__(self, name), I think it's safe to assume that that's meant as an optimization. Georg ___ Python-Dev mailing list Python-Dev@python.org 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:
> 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 think that's its strength; it's pleasantly symmetric to using [] on a
dict:
dictattribute behavior
[] .[] pulls out named thing, throws exception
on failure, no default, is an lvalue
.get() .getattr()pulls out named thing, returns default
value on error (specifiable as second
argument), not an lvalue
List comprehensions look like funny lists, generator expressions look
like funny expressions, I see no reason why attribute dereferencing
shouldn't look like funny dict dereferencing.
+1.
> What would the reaction be to
>obj.{member}
> instead? Braces are already used to construct dictionaries, so this has
> some of the right connotations.
-0.5. You're not constructing anything, you're looking up something.
For the record, I'm also -1 on the two-argument form--this isn't a
function call.
/larry/
___
Python-Dev mailing list
Python-Dev@python.org
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 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 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.
>> They're all in Lib/codecs.py, and are of the form:
>>
>> class StreamRecoder:
>> def __getattr__(self, name,
>> getattr=getattr):
>>
>> """ Inherit all other methods from the underlying stream.
>> """
>> return getattr(self.stream, name)
>>
>> Without digging deeper into that code I'm afraid I can't say precisely
>> what is going on.
>
> Since that is a special method and ought to have the signature
> __getattr__(self, name), I think it's safe to assume that that's meant
> as an optimization.
I can confirm that: it's a case of fast-local-lookup optimization.
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.
Even if you do add a new syntax for this, using parenthesis is
a poor choice IMHO as the resulting code looks too much like a
function call (e.g. "callable.(variable)").
Other choices would be square brackets [], but these have the
same problem as they are in use for indexing.
The only brackets that are not yet overloaded in the context
of applying them to an object are curly brackets, so
"callable.{variable}" would cause enough raising eyebrows
to not think of a typo.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Feb 12 2007)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/
Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free !
___
Python-Dev mailing list
Python-Dev@python.org
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
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 about it, that actually makes more sense than x.(y). (In fact, in JavaScript you can write x[y] to the same effect. I wouldn't discount the JS example; JS is probably closer to Python than almost any other language currently in existence except for Boo, and JS has successfully borrowed from Python.) - I'm not too concerned by the '.' being such a small character with this new proposal. x[y] is a lot less common than x(y), so you'll look twice when you think you see x[y] and it doesn't make sense, and then you'll notice it's really x.[y], which you either know or don't, and in the latter case you'll be looking it up or asking around. PS Thanks to Ben for excellent summaries of the discussion so far! -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] safety of Py_CLEAR and self
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); Py_CLEAR(f->f_trace); We use Py_CLEAR() so that multiple calls to frame_clear() are safe. The first time this runs it sets exc_type to NULL before calling DECREF. This guarantees that a subsequent frame_clear() or frame_dealloc() won't attempt to DECREF it a second time. I think I understand why that's desireable and why it works. The primary risk is that via DECREF we may execute an arbitrary amount of Python code via weakref callbacks, finalizers, and code in other threads that gets resumed while the callbacks and finalizers are running. My question, specifically, then: Why it is safe to assume that f doesn't point to trash after a particular call to Py_CLEAR()? Any particular call to Py_CLEAR() could break the cycle that the object is involved in an lead to a call to frame_dealloc(). The frame could get returned to an obmalloc pool, returned to the OS, or just re-used by another object before we get back to Py_CLEAR(). It seems like such behavior would be exceedingly unlikely, but I can't convince myself that it is impossible. Which is it: improbable or impossible? If it is only improbable, should we figure out how to write code that is safe against such an improbable event? Jeremy ___ Python-Dev mailing list Python-Dev@python.org 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 <[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 continue to run. However there is no support for > asynchronous file IO. Now I can monkeypatch in a replacement file > object which uses IO completion ports [2], 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. ...sounds kinda like the Twisted reactor. Except the IOCP implementation thereof is still underway, I believe. > 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 than reinventing the wheel, for something of this magnitude. -- mithrandi, i Ainil en-Balandor, a faer Ambar signature.asc Description: Digital signature ___ Python-Dev mailing list Python-Dev@python.org 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/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 than > reinventing the wheel, for something of this magnitude. This to me seems to be the low level support you would build something like Twisted on top of. Pushing Twisted so that others can get it seems a little over the top. In any case I'm not building an application. I am transparently making standard library calls yield to a scheduler while whatever they would do happens asynchronously. Generic support for this allows me to make Stackless usage like normal Python usage but with microthreads. I would hope if Dustin went ahead with a generator based microthread solution he find it useful as well. Lumbering Stackless at least with a framework like Twisted pushes complexity up to the user, something Stackless cannot afford. Cheers, Richard. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Interning string subtype instances
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 also
must intern the strings for faster equivalence testing. Such an
application, upon receiving a string subtype, will silently fail to
work.
There is good reason for PyString_InternInPlace not accepting string
subtypes: since a subtype can have modified behavior, interning it can
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.
This should be a fully backward compatible change because: 1) code that
passes PyString instances (99.99% cases) will work as before, and 2)
code that passes something else silently failed to intern the string
anyway. Speed should be exactly the same as before, with the added
benefit that interning PyString subtype instances now does something,
but without the problems that interning the actual instance can produce.
The patch could look like this. If there is interest in this, I can
produce a complete patch.
@@ -5,10 +5,6 @@
PyObject *t;
if (s == NULL || !PyString_Check(s))
Py_FatalError("PyString_InternInPlace: strings only please!");
- /* If it's a string subclass, we don't really know what putting
- it in the interned dict might do. */
- if (!PyString_CheckExact(s))
- return;
if (PyString_CHECK_INTERNED(s))
return;
if (interned == NULL) {
@@ -25,6 +21,18 @@
*p = t;
return;
}
+ /* Make sure we don't intern a string subclass, since we don't
+ really know what putting it in the interned dict might do. */
+ if (!PyString_CheckExact(s)) {
+ PyObject *copy;
+ copy = PyString_FromStringAndSize(PyString_AS_STRING(*p),
+ PyString_GET_SIZE(*p));
+ if (!copy)
+ return;
+ Py_DECREF(*p);
+ *p = copy;
+ s = (PyStringObject *) copy;
+ }
if (PyDict_SetItem(interned, (PyObject *)s, (PyObject *)s) < 0) {
PyErr_Clear();
___
Python-Dev mailing list
Python-Dev@python.org
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/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 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. 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 talked to Christian about it but as the current maintainer of Stackless I was under the impression that there was a complete lack of interest in even considering it for integration. If addition of microthreading is being considered please consider Stackless. One reason why Stackless is not so popular is that as a fork people shy away from it because it is not the main version. It would benefit Stackless to be integrated and I would be willing to do any work involved to either integrate or maintain it afterwards. Cheers, Richard. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] safety of Py_CLEAR and self
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 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); > Py_CLEAR(f->f_trace); > > We use Py_CLEAR() so that multiple calls to frame_clear() are safe. > The first time this runs it sets exc_type to NULL before calling > DECREF. This guarantees that a subsequent frame_clear() or > frame_dealloc() won't attempt to DECREF it a second time. I think I > understand why that's desireable and why it works. The primary risk > is that via DECREF we may execute an arbitrary amount of Python code > via weakref callbacks, finalizers, and code in other threads that gets > resumed while the callbacks and finalizers are running. > > My question, specifically, then: Why it is safe to assume that f > doesn't point to trash after a particular call to Py_CLEAR()? Any > particular call to Py_CLEAR() could break the cycle that the object is > involved in an lead to a call to frame_dealloc(). The frame could get > returned to an obmalloc pool, returned to the OS, or just re-used by > another object before we get back to Py_CLEAR(). It seems like such > behavior would be exceedingly unlikely, but I can't convince myself > that it is impossible. Which is it: improbable or impossible? If it > is only improbable, should we figure out how to write code that is > safe against such an improbable event? > > Jeremy > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org 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 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 to the language) I only see possible confusion if one gives
'static' looking examples like:
x.(foo) += 1
which does indeed look a bit like a function call.
However when giving more 'dynamic' looking examples like:
x.('foo_%d' % n) += 1
I don't get confused at all and intuitively recognize the intention
immediately. In this example I consider the parenthesis 'grouping operators'
(which would not be the case when square brackets would have been used)
So, +1 for the idea from me, since the main intention is to use it in a
'dynamic' context, and there it would improve readability.
All IMHO as a newbee of course :)
Ton.
___
Python-Dev mailing list
Python-Dev@python.org
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
[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 obj->member > > is the interpretation of the thing on the *left* of the dot or arrow, > whereas the PEP is discussing a new interpretation of the thing on the > *right* of the dot. Try not to get hung-up on meanings from other languages. Any simple syntax will have associations in other languages. It is more important that we don't create a syntax which already has strong associations in Python (i.e. curly braces, dots, and square brackets). Those syntaxes would make the language harder to mentally parse. I would like to give the -> syntax a chance as is it simple and it is provides a nice visual distinction between closely related concepts: a.name --getattr(a, 'name') a->name --getattr(a, name) Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] safety of Py_CLEAR and self
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 the object can't be collected until the tp_clear() returns. Thanks. Jeremy > > --Guido > > On 2/12/07, Jeremy Hylton <[EMAIL PROTECTED]> wrote: > > 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); > > Py_CLEAR(f->f_trace); > > > > We use Py_CLEAR() so that multiple calls to frame_clear() are safe. > > The first time this runs it sets exc_type to NULL before calling > > DECREF. This guarantees that a subsequent frame_clear() or > > frame_dealloc() won't attempt to DECREF it a second time. I think I > > understand why that's desireable and why it works. The primary risk > > is that via DECREF we may execute an arbitrary amount of Python code > > via weakref callbacks, finalizers, and code in other threads that gets > > resumed while the callbacks and finalizers are running. > > > > My question, specifically, then: Why it is safe to assume that f > > doesn't point to trash after a particular call to Py_CLEAR()? Any > > particular call to Py_CLEAR() could break the cycle that the object is > > involved in an lead to a call to frame_dealloc(). The frame could get > > returned to an obmalloc pool, returned to the OS, or just re-used by > > another object before we get back to Py_CLEAR(). It seems like such > > behavior would be exceedingly unlikely, but I can't convince myself > > that it is impossible. Which is it: improbable or impossible? If it > > is only improbable, should we figure out how to write code that is > > safe against such an improbable event? > > > > Jeremy > > ___ > > Python-Dev mailing list > > Python-Dev@python.org > > http://mail.python.org/mailman/listinfo/python-dev > > Unsubscribe: > > http://mail.python.org/mailman/options/python-dev/guido%40python.org > > > > > -- > --Guido van Rossum (home page: http://www.python.org/~guido/) > ___ Python-Dev mailing list Python-Dev@python.org 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 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 feature to Python without completely re-writing it. Writing a purely stateless, "stack-less" language interpreter is not that hard, as long as you are willing to drink the KoolAid from the very start - in other words, you don't allow any function call interfaces which are not continuable. This does make writing C extension functions a little bit harder than before, as you now have to explicitly manage all of your local variables instead of just pushing them on the hardware stack. (Actually, for "simple" C subroutines that don't call any other interpreted functions, you can write it like a normal C functions just as you always have.) The nightmare comes when you try to glue all this onto an existing language interpreter, which wasn't written from the start with these principles in mind - AND which doesn't want to suffer the impact of a large number of global changes. To be honest, I can't even imagine how you would do such a thing, and the fact that Stackless has done it is quite impressive to me. Now, I'm very interested in Stackless, but, as you say, like many people I've tended to shy away from using a fork. Now, the question I would like to ask the Stackless people is: Rather than thinking about wholesale integration of Stackless into Python mainline, what would make it easier to maintain the Stackless fork? In other words, what would you change about the current Python (it could be a global change) that would make your lives easier? What I'd like to see is for the Stackless people to come up with a list of design principles which they would like to see the implementation of Python conform to. Things like "All C functions should conform to such and such calling convention". 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. The idea is to gradually shrink the actual Stackless patches to the point where they become small enough that a direct patch becomes uncontroversial. -- Talin ___ Python-Dev mailing list Python-Dev@python.org 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: > 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 talked to Christian about it but as the current maintainer > of Stackless I was under the impression that there was a complete > lack of interest in even considering it for integration. I think this comes from a major misunderstanding of how free software works. This is not commercial software, so there is no "company agenda" that drives it forward. There are various contributors, each having their own agenda; for most of us, it's "scratch your own itches". Surely, the voices of people have varying significance (in Python, Guido is the BDFL, for example), but "there was a complete lack of interest in even considering" just cannot be true: clearly, some contributors and users *were* interested. There were surely objections to the implementation strategy, and I also had objections to the specific execution of this implementation strategy, see http://tinyurl.com/27v23r Now, the question is whose "job" it would have been to integrate Stackless to Python. Apparently, Christian tried to make it happen (see http://tinyurl.com/3bqe5d), although I'm still uncertain whether he ever got to a point where he said: "this is a patch, please review it" (of that, I can find no archives, as I said). I find it understandable that nobody else took over to work on integrating it (although there is PEP 219, so apparently some people worked at some point on it). From my point of view, people suggesting to incorporate code as-is often misunderstand that it is not sufficient for the code to work in the applications were it is used. It must also be sound (i.e. work in some meaningful way also in cases for which it wasn't designed), and it must be maintainable. I can understand how discouraging it is when you see that your code "works" that then people object to incorporating it as-is. However, I believe the long-term quality of Python can only be guaranteed when careful review is applied to every change made, or else we will regret changes in the future (and indeed, Python 3000 would not have been necessary if no mistakes had been made). > If addition of microthreading is being considered please consider > Stackless. One reason why Stackless is not so popular is that > as a fork people shy away from it because it is not the main > version. It would benefit Stackless to be integrated and I would > be willing to do any work involved to either integrate or maintain > it afterwards. This is what I'm talking about: nothing "is" ever considered. Instead, individuals make contributions, individuals review them, and individuals support and object to changes. There is no abstract python-dev entity that likes or dislikes changes. Individuals have individual opinions. Now, where is the SF patch that makes Stackless part of Python ?-) (and if you are serious about it, try to break it down into multiple pieces, each individually correct and useful; start with one where the effort isn't too big in case it gets rejected by BDFL pronouncement) I haven't reviewed the Stackless code in a while; last I looked, I found it was possible to crash the interpreter if you use it "incorrectly". I *personally* object to changes where it is easy to crash the interpreter, unless there is a clear specification when this may happen, and there is a systematic way to avoid that (this is the ctypes clause). Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org 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
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 http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Interning string subtype instances
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 requires an external reference to prevent garbage collection (I believe). What will hold a reference to the string copy? -Mike ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] safety of Py_CLEAR and self
[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); > Py_CLEAR(f->f_exc_traceback); > Py_CLEAR(f->f_trace); > > We use Py_CLEAR() so that multiple calls to frame_clear() are safe. > The first time this runs it sets exc_type to NULL before calling > DECREF. This guarantees that a subsequent frame_clear() or > frame_dealloc() won't attempt to DECREF it a second time. I think I > understand why that's desireable and why it works. The primary risk > is that via DECREF we may execute an arbitrary amount of Python code > via weakref callbacks, finalizers, and code in other threads that gets > resumed while the callbacks and finalizers are running. > > My question, specifically, then: Why it is safe to assume that f > doesn't point to trash after a particular call to Py_CLEAR()? Any > particular call to Py_CLEAR() could break the cycle that the object is > involved in an lead to a call to frame_dealloc(). The frame could get > returned to an obmalloc pool, returned to the OS, or just re-used by > another object before we get back to Py_CLEAR(). It seems like such > behavior would be exceedingly unlikely, but I can't convince myself > that it is impossible. Which is it: improbable or impossible? If it > is only improbable, should we figure out how to write code that is > safe against such an improbable event? As Guido pointed out, tp_clear is called by gc from only one place, which sticks an incref/decref pair around the call so that the refcount on `f` can't fall to 0 while frame_clear() is active. That doesn't mean frame_clear is always safe to call, it only means that gc's use of the tp_clear slot is safe. Nobody else "should be" calling frame_clear (and it so happens nothing else in the core does), but it's something to be dimly aware of. For example, IIRC, some of ZODB's C code internally invokes its XXX_clear() functions directly, as part of removing persistent object state (unrelated to object deallocation). Determining whether those kinds of uses are safe requires case-by-case analysis. ___ Python-Dev mailing list Python-Dev@python.org 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: > It depends what you mean by mechanism. I can't go into low level details > because I do not have the necessary experience or knowledge to know > which approach would be best. Indeed, low-level details is what I'm interested in. > 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 continue to run. However there is no support for > asynchronous file IO. That's actually a limitation of Windows: in a UNIX system, you can pass sockets and file descriptors alike to select(2) or poll(2) (in fact, sockets *are* file descriptors). > Now I can monkeypatch in a replacement file > object which uses IO completion ports [2] Ok, so you want to use IO completion ports on Windows. This is the mechanism I was asking for (overlapped IO would have been another mechanism available on Win32). Adding support for IO completion ports is certainly something that would be worthwhile. > 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 don't know whether/how this is possible. The underlying WaitForMultipleObjects routine does not accept WinSock objects, to my knowledge (perhaps it does in Vista, with the rewriting of WinSock?). However, if it would be possible, I would suggest to add support for this into the select module, and allow then to pass non-socket objects to select on Windows (just as it is possible on Unix). If this can't work (as you need to associate the file handle with a io completion port, after which you can't use ReadFile anymore), a new poll-like routine may be added, and then support for that may be added to asyncore. Notice that WaitForMultipleObjects is limited to MAXIMUM_WAIT_OBJECTS, which I believe is 64. So this is somewhat limiting. > Perhaps there is a better way. And I of course have no concept of > how this might be done on other platforms. For file descriptors, other platforms are ahead of Windows. For child process IDs, it's somewhat more tricky: you get a POSIX signal when some of them terminates, and any system call should terminate with EINTR. So the universal poll routine would abort when a child dies, and could then check a global variable set by the signal handler. In any case, one needs to specify such a "universal event loop" precisely, or else it will just fail. Look at Tcl's even mechanism for an example that has failed (IMO). Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org 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'll take this opportunity to pipe in with a response, since Guido summed up the many issues nicely and its a good bouncing point to mention my own thoughts. On 2/12/07, Guido van Rossum <[EMAIL PROTECTED]> wrote: > 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 about > it, that actually makes more sense than x.(y). (In fact, in JavaScript > you can write x[y] to the same effect. I wouldn't discount the JS > example; JS is probably closer to Python than almost any other > language currently in existence except for Boo, and JS has > successfully borrowed from Python.) I'll second that. The JS case is valuable and a good representation of the mindset behind using foo.[bar] > - I'm not too concerned by the '.' being such a small character with > this new proposal. x[y] is a lot less common than x(y), so you'll look > twice when you think you see x[y] and it doesn't make sense, and then > you'll notice it's really x.[y], which you either know or don't, and > in the latter case you'll be looking it up or asking around. I definitely see the downside of using the nearly invisible . here. Looking like dirt on the screen, being misunderstood, deleted because someone thought it was a typo, etc. could all be problems. I am not convinced they will be problems, only that they could. Now, do we need a more readable attribute deference or is there some optimizational need to make a syntax specifically for it? Why can't we just wrap the object in question with some attribute lookup type? attr(o)[methodname]() vs o.[methodname]() I think if you read those two, at a quick glance the first is a lot more readable than the second. It also has the advantage of not modifying the language syntax, or introducing nearly as much new code. -- Read my blog! I depend on your acceptance of my opinion! I am interesting! http://ironfroggy-code.blogspot.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Interning string subtype instances
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 prevent garbage > collection (I believe). What will hold a reference to the string > copy? For PyString_InternInPlace, the caller will receive a reference; the original object passed in is decref'ed. A typical caller of PyString_InternInPlace will just store the reference in some global/static variable. builtin_intern will return it to the caller, which then needs to store it. This was always the case with intern(); the usage pattern is foo = intern(foo) as intern may return a different object (e.g. if the string was already interned). Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Interning string subtype instances
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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Interning string subtype instances
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:
_interned[st] = st
return _interned[st]
If I remember the implementation of intern correctly, that's more or
less what happens under the covers.
- Josiah
___
Python-Dev mailing list
Python-Dev@python.org
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
"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 don't know whether/how this is possible. The underlying > WaitForMultipleObjects routine does not accept WinSock objects, > to my knowledge (perhaps it does in Vista, with the rewriting > of WinSock?). It "works" in Windows 2000. I've got a variant of a prototype (and abandoned) Twisted Reactor that uses WaitForMultipleObjects for an alternate asyncore.poll() implementation on Windows. It sucks up 100% processor when sending trivial amounts of data from a single socket (where asyncore uses about 2%), but you do get the data. - Josiah ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Any value in setting up pybots for py3k?
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 setting up a svn notification hook for py3k commits that would go to the pybots buildbot master? Grig -- http://agiletesting.blogspot.com ___ Python-Dev mailing list Python-Dev@python.org 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/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 lookup than calling > > functions. > > I also like the functionality. > > Rather than munge existing syntaxes, an altogether new one would be more > clear: > >self->name = self.metadata->name > > I like the arrow syntax because is the lookup process can be more involved > than a simple dictionary lookup (perhaps traveling up to base classes). > IOW, getattr(a,n) is not always the same as a.__dict__[n]. > The a.__getattribute__(n) process can be more complex than that > and a bracketed dictionary-like syntax would misleadingly mask the lookup > process. > 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. -Brett ___ Python-Dev mailing list Python-Dev@python.org 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/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 difference between
> >
> > obj.memberand obj->member
> >
> > is the interpretation of the thing on the *left* of the dot or arrow,
> > whereas the PEP is discussing a new interpretation of the thing on the
> > *right* of the dot.
>
> Try not to get hung-up on meanings from other languages.
> Any simple syntax will have associations in other languages.
An example of where Python has been willing in the past to hijack
syntax and give it a tweaked meaning is decorators compared to Java
annotations.
> It is more important that we don't create a syntax which already
> has strong associations in Python (i.e. curly braces, dots, and square
> brackets).
> Those syntaxes would make the language harder to mentally parse.
>
I think this is a nice argument against using square brackets as well.
Currently square brackets are used for getting an item from a
container (__getitem__) or generating one (list comprehensions).
While using the .[] syntax does connect with the "container" idea if
you want to treat an object as a container and its attributes as its
items, I don't think the connection is that strong.
Guido said he would be much more willing to look twice at a use of
brackets for a dot, but that seems to require mental backtracking to
me. If I am skimming some source and I see square brackets, right
now I know that either something has defined __getitem__ and is
probably a dict or list, or it is a listcomp if it contains 'for'.
But with this I would now have to stop and look for that dot which
could be lost in the noise.
I think people are calling the syntax "dirt" because you have two
pieces of syntax ('.' and '[') that are a single character. And on
top of that they are extremely thin (which sucks for non-monospaced
fonts). We don't have issues with dots these days since there is
usually several characters of information specifying the meaning of
what the dot is modified by the dot. But in this case there is very
little visual queue for that.
> I would like to give the -> syntax a chance as is it simple
> and it is provides a nice visual distinction between closely
> related concepts:
>
> a.name --getattr(a, 'name')
> a->name --getattr(a, name)
Yeah, I am definitely liking this one more. It's making the
``.[name]`` or ``.(name)`` look more like "dirt on Tim's monitor" to
me.
-Brett
___
Python-Dev mailing list
Python-Dev@python.org
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/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 better: > > > what we're doing here is more like dictionary lookup than calling > > > functions. > > > > I also like the functionality. > > > > Rather than munge existing syntaxes, an altogether new one would be more > > clear: > > > >self->name = self.metadata->name > > > > I like the arrow syntax because is the lookup process can be more involved > > than a simple dictionary lookup (perhaps traveling up to base classes). > > IOW, getattr(a,n) is not always the same as a.__dict__[n]. > > The a.__getattribute__(n) process can be more complex than that > > and a bracketed dictionary-like syntax would misleadingly mask the lookup > > process. > > > > 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 the wrong one. In C, "x->y" dereferences x, while in Python, "x->y" would dereference y. That's just begging for trouble. Collin Winter ___ Python-Dev mailing list Python-Dev@python.org 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 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 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". [insert in-Soviet-Russia-variables-dereference-you joke here] -- Benji York ___ Python-Dev mailing list Python-Dev@python.org 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
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 difference. I bet that
you won't have any trouble.
--Guido
On 2/12/07, Brett Cannon <[EMAIL PROTECTED]> wrote:
> 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 difference between
> > >
> > > obj.memberand obj->member
> > >
> > > is the interpretation of the thing on the *left* of the dot or arrow,
> > > whereas the PEP is discussing a new interpretation of the thing on the
> > > *right* of the dot.
> >
> > Try not to get hung-up on meanings from other languages.
> > Any simple syntax will have associations in other languages.
>
> An example of where Python has been willing in the past to hijack
> syntax and give it a tweaked meaning is decorators compared to Java
> annotations.
>
> > It is more important that we don't create a syntax which already
> > has strong associations in Python (i.e. curly braces, dots, and square
> > brackets).
> > Those syntaxes would make the language harder to mentally parse.
> >
>
> I think this is a nice argument against using square brackets as well.
> Currently square brackets are used for getting an item from a
> container (__getitem__) or generating one (list comprehensions).
> While using the .[] syntax does connect with the "container" idea if
> you want to treat an object as a container and its attributes as its
> items, I don't think the connection is that strong.
>
> Guido said he would be much more willing to look twice at a use of
> brackets for a dot, but that seems to require mental backtracking to
> me. If I am skimming some source and I see square brackets, right
> now I know that either something has defined __getitem__ and is
> probably a dict or list, or it is a listcomp if it contains 'for'.
> But with this I would now have to stop and look for that dot which
> could be lost in the noise.
>
> I think people are calling the syntax "dirt" because you have two
> pieces of syntax ('.' and '[') that are a single character. And on
> top of that they are extremely thin (which sucks for non-monospaced
> fonts). We don't have issues with dots these days since there is
> usually several characters of information specifying the meaning of
> what the dot is modified by the dot. But in this case there is very
> little visual queue for that.
>
> > I would like to give the -> syntax a chance as is it simple
> > and it is provides a nice visual distinction between closely
> > related concepts:
> >
> > a.name --getattr(a, 'name')
> > a->name --getattr(a, name)
>
> Yeah, I am definitely liking this one more. It's making the
> ``.[name]`` or ``.(name)`` look more like "dirt on Tim's monitor" to
> me.
>
> -Brett
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/guido%40python.org
>
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
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
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: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] New syntax for 'dynamic' attribute access
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 for the basic idea, and only a few
> naysayers, so let's keep looking for a syntax that works.
If we can take that as a decision, then the various proposals for the
syntax break down as follows.
By raw numbers, the most popular choice is
self.(method_name) = self.metadata.(method_name)
but many of the "I like that" messages were in the context of the idea
as a whole, so can't really be counted as explicit votes for "obj.(foo)"
as such.
Next, and Guido's preferred choice, is
self.[method_name] = self.metadata.[method_name]
(I haven't been following long enough to know whether "Guido likes it"
overrides everything else (the "D" of BDFL), or is more of a casting
vote in the event of a tie.)
With regard to the potential overlookability of the dot, Guido says:
> 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 have any trouble.
I agree --- just as it's important to have a font that makes it easy to
distinguish "I" from "l" and "1", "0" from "O", "(" from "{", etc., I
would say it's important to program using a font which makes it easy to
tell whether there's a "." in your code. I can imagine that a
proportional font where "." might be a single pixel wouldn't help,
though. (Gently wandering off-topic, but: do people use proportional
fonts for coding? Doesn't it cause general awkwardness for
indentation, especially relevant for python?)
Also mentioned was
self.{method_name} = self.metadata.{method_name}
which could not be confused either with function call or indexing but
perhaps would preclude braces from any potential future use.
Exploring other ideas, the "arrow" notation
self->method_name = self.metadata->method_name
has support, and is clearly different, but I personally would be misled
to think, from the meaning in C, that it ought to be the left-hand
operand which is dereferenced somehow. Guido has the same opinion, and
is "strongly -1" on this.
The "star" form has the "dereference" meaning from C, and is certainly
visually distinctive:
self.*method_name = self.metadata.*method_name
and explicit parentheses could be put in as a syntax requirement, or by
individual coder preference, or for more complex attribute calculations:
self.*(method_name) = self.metadata.*(method_name)
self.*('foo_%d' % n) = self.metadata.*('foo_%d' % n)
The downside is that it could be considered "visually distinctive" to
the point of being line noise.
Could we cut down the choice to
self.[method_name] = self.metadata.[method_name]
if the danger of overlooking the dot were deemed small enough, or
self.*(method_name) = self.metadata.*(method_name)
if the consensus was that something more noticeable was needed?
(Or there's always the late arrival
> > In C, "x->y" dereferences x, while in Python, "x->y" would
dereference y.
>
> Then the syntax should obviously be "x<-y".
> [insert in-Soviet-Russia-variables-dereference-you joke here]
from Benji York.)
Ben.
___
Python-Dev mailing list
Python-Dev@python.org
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: > 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 reason to jusify it. I don't see this filling a use case that's anywhere near common enough to reach that threshold. -- Greg ___ Python-Dev mailing list Python-Dev@python.org 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/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 people will confuse it for a function call. That seems like more of an argument against the dot operator in general than the new syntax. I'm -1 on the '->' syntax. It just doesn't look very clean to me. -Farshid ___ Python-Dev mailing list Python-Dev@python.org 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
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". Someone with OCaml background could confuse that with an assignment -- Marek Baczyński ___ Python-Dev mailing list Python-Dev@python.org 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 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 having each thing that uses async I/O doing its own thing. There should be a standard mechanism in the stdlib that everything can use. -- Greg ___ Python-Dev mailing list Python-Dev@python.org 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/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 x.[foo]
> and x[foo], and see how fast you can spot the difference. I bet that
> you won't have any trouble.
>
OK, so real-world examples. First, ``foo.(name)``, from urllib.py::
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 self.open_unknown(fullurl, data)
try:
if data is None:
return self.(name)(url)
else:
return self.(name)(url, data)
except socket.error, msg:
raise IOError, ('socket error', msg), sys.exc_info()[2]
and also::
name = 'http_error_%d' % errcode
if hasattr(self, name):
method = self.(name)
if data is None:
result = method(url, fp, errcode, errmsg, headers)
else:
result = method(url, fp, errcode, errmsg, headers, data)
if result: return result
return self.http_error_default(url, fp, errcode, errmsg, headers)
And here is urllib2.py for ``.[]`` (used different files so you
wouldn't just remember where the change was)::
if attr[:12] == '_Request__r_':
name = attr[12:]
if hasattr(Request, 'get_' + name):
self.['get_' + name]()
return self.[attr]
raise AttributeError, attr
and::
handlers = chain.get(kind, ())
for handler in handlers:
func = handler.[meth_name]
result = func(*args)
if result is not None:
return result
Neither version jumps out at me strongly, although between the two the
``.[]`` version shows up the best. But that might also be because of
the lower noise when used in a call.
-Brett
___
Python-Dev mailing list
Python-Dev@python.org
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
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 already answered your own question. This is not the sort of thing that can be done piecemeal -- it requires everything to change simultaneously to a very different underlying model. 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. -- Greg ___ Python-Dev mailing list Python-Dev@python.org 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
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 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".
I'd actually gone through this process myself, and concluded that I
wouldn't be happy with either.
"x->y: is currently invalid syntax, but has *very* strong connotations
from C. Whilst I'm happy to consider things that deviate from other
languages' use, this one is just too strong.
"x<-y" is currently valid syntax, and gives (to mee) the wrong
impression that y is that thing that's going to be modified.
Of all the proposals I've seen, I think I like "x.{y}" best. The use of
{} has connotations of interpolation and they're the only braces that
currently don't have meaning as x{} (and probably never will).
I do worry that giving syntax to getattr/setattr/delattr will encourage
the use of dynamic attributes, when they are a fairly advanced feature.
OTOH, when you're using advanced features, you want the code to be as
readable as possible, and I think this will improve readability over
using getattr/setattr/delattr.
So I think I've changed to +0.5.
Tim Delaney
___
Python-Dev mailing list
Python-Dev@python.org
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 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 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 you read code. This is my issue with the foo.(bar) syntax. The period is far far too small and easy to miss. -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Recent experience with the _ast module
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 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 visitor so that I don't accidentally iterate over it.
2) {BinOp,AugAssign,BoolOp,etc}.op is an instance of, eg, Add, Sub,
Mult, Mod, meaning you have to dispatch based on tests like
"isinstance(node.op, x)" or "type(node.op) is x". I would much, much
prefer to spell this "node.op is x", ie, use "node.op = Add" rather
than the current "node.op = Add()" when constructing the nodes.
3) I'd like there to be an Else() node for If.orelse, While.orelse,
etc. My motivation is that I need the lineno and col_offset values of
the "else" statement for a code-coverage utility; as it is, I have to
find the last lineno of the if/while/etc suite and the first lineno of
the "else" suite and then search between those two for the "else"
statement.
Thoughts?
Thanks,
Collin Winter
___
Python-Dev mailing list
Python-Dev@python.org
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
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 have any trouble. >> > > OK, so real-world examples. First, ``foo.(name)``, from urllib.py:: > [snip] > > Neither version jumps out at me strongly, although between the two the > ``.[]`` version shows up the best. But that might also be because of > the lower noise when used in a call. > > -Brett After seeing a real-world example of the notation, I'm not a fan. Like Brett, of the two I find ".[]" to be the most readable. I do in fact immediately associate an identifier next to "()" with being a function call, regardless of the dot. The "[]" immediately associates me with a type of dereferencing action which is more appropriate for the context. The danger here is that "foo.bar" and "baz.(bar)" use "bar" in drastically different ways and it is not made obvious enough. "baz.[bar]" gets you closer because we are used to seeing "bar" as a variable containing a key (as opposed to "foo.bar" where 'bar' is in fact the key). At the risk of needing flame retardant, I would propose the use of something more visually jarring. The first thing that came to mind was something like "[EMAIL PROTECTED]". The only usage of the @ symbol I can recall is in Ruby where it is used instead of "self." for attribute access, which is in the right ballpark for what we mean here and the brackets differentiate it still. To borrow the urllib2.py example: if attr[:12] == '_Request__r_': name = attr[12:] if hasattr(Request, 'get_' + name): [EMAIL PROTECTED]'get_' + name]() return [EMAIL PROTECTED] raise AttributeError, attr -Scott -- Scott Dial [EMAIL PROTECTED] [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org 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
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 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 x.[foo]
> > and x[foo], and see how fast you can spot the difference. I bet that
> > you won't have any trouble.
> >
>
> OK, so real-world examples. First, ``foo.(name)``, from urllib.py::
>
> 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 self.open_unknown(fullurl, data)
> try:
> if data is None:
> return self.(name)(url)
> else:
> return self.(name)(url, data)
> except socket.error, msg:
> raise IOError, ('socket error', msg), sys.exc_info()[2]
>
> and also::
>
> name = 'http_error_%d' % errcode
> if hasattr(self, name):
> method = self.(name)
> if data is None:
> result = method(url, fp, errcode, errmsg, headers)
> else:
> result = method(url, fp, errcode, errmsg, headers, data)
> if result: return result
> return self.http_error_default(url, fp, errcode, errmsg, headers)
>
>
> And here is urllib2.py for ``.[]`` (used different files so you
> wouldn't just remember where the change was)::
>
> if attr[:12] == '_Request__r_':
> name = attr[12:]
> if hasattr(Request, 'get_' + name):
> self.['get_' + name]()
> return self.[attr]
> raise AttributeError, attr
>
> and::
>
> handlers = chain.get(kind, ())
> for handler in handlers:
> func = handler.[meth_name]
> result = func(*args)
> if result is not None:
> return result
>
>
>
> Neither version jumps out at me strongly, although between the two the
> ``.[]`` version shows up the best. But that might also be because of
> the lower noise when used in a call.
>
> -Brett
>
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
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
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 take). How do you spell "getattr(self, 'req_' + state)" with that arrow? You need some kind of grouping delimiters to make this operator be a syntax benefit otherwise you didn't shorten anything. -Scott -- Scott Dial [EMAIL PROTECTED] [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org 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
-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 immediately. > (When do you ever see self[anything]?) Raymond's -> suggestion was nice. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRdEIB3EjvBPtnXfVAQLENQP+KlLGE0rldGbOdpeMdsZ6dX7ga9Fb2mZR wkOIEYJW6H8n6OyzawPgkvQWpuJzUlC+5A42gxYUdkC4pTxWqzJQ6i6csoVOD+ya 1vztCUavDTG9HznH4tX6L2bRJI2fhBdfMxkNCnSpmRaW1SOpOgutLMQv5ZxmLzHU xjkaqp9ogPY= =gu74 -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org 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 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. > > +1. This sounds like an excellent idea. It's downright > silly having each thing that uses async I/O doing its > own thing. There should be a standard mechanism in the > stdlib that everything can use. I'm workin' on it! ;) I guess #2 wasn't so hard, after all, Brett! Dustin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Recent experience with the _ast module
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 _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 visitor so that I don't accidentally iterate over it.
>
That makes total sense to me.
> 2) {BinOp,AugAssign,BoolOp,etc}.op is an instance of, eg, Add, Sub,
> Mult, Mod, meaning you have to dispatch based on tests like
> "isinstance(node.op, x)" or "type(node.op) is x". I would much, much
> prefer to spell this "node.op is x", ie, use "node.op = Add" rather
> than the current "node.op = Add()" when constructing the nodes.
>
I can't think of a reason, off the top of my head, why they can't be
singletons. It actually makes sense since they are basically an
enumeration value in the AST grammar.
> 3) I'd like there to be an Else() node for If.orelse, While.orelse,
> etc. My motivation is that I need the lineno and col_offset values of
> the "else" statement for a code-coverage utility; as it is, I have to
> find the last lineno of the if/while/etc suite and the first lineno of
> the "else" suite and then search between those two for the "else"
> statement.
>
Ouch. I don't know how much work it would be to make this change, but
it seems reasonable to want.
> Thoughts?
>
They all sound reasonable. And it's nice to have a wanted feature be
found from actual use. =)
-Brett
___
Python-Dev mailing list
Python-Dev@python.org
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
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, so the dot _is_
needed in order to indicate that we are talking about objects. But if
I see something like spam.(eggs) , I would feel tempted to delete the
dot thinking it's a typo. Besides, the parenthesis make the dot even
harder to read.
- x->y feels like assignment. I even recall that in Mathematica it IS
some kind of assignment. Besides, it lacks the dot that tells me "this
is an object".
- Square brackets have a lot of overloading but are not so bad.
- Braces feel good. I think they are the best choice of the ones
proposed. Because spam{eggs} doesn't mean anything, then there would
be no confusion with a typo in spam.{eggs}
--Sergio
On 2/12/07, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> 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 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.
> >> They're all in Lib/codecs.py, and are of the form:
> >>
> >> class StreamRecoder:
> >> def __getattr__(self, name,
> >> getattr=getattr):
> >>
> >> """ Inherit all other methods from the underlying stream.
> >> """
> >> return getattr(self.stream, name)
> >>
> >> Without digging deeper into that code I'm afraid I can't say precisely
> >> what is going on.
> >
> > Since that is a special method and ought to have the signature
> > __getattr__(self, name), I think it's safe to assume that that's meant
> > as an optimization.
>
> I can confirm that: it's a case of fast-local-lookup optimization.
>
> 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.
>
> Even if you do add a new syntax for this, using parenthesis is
> a poor choice IMHO as the resulting code looks too much like a
> function call (e.g. "callable.(variable)").
>
> Other choices would be square brackets [], but these have the
> same problem as they are in use for indexing.
>
> The only brackets that are not yet overloaded in the context
> of applying them to an object are curly brackets, so
> "callable.{variable}" would cause enough raising eyebrows
> to not think of a typo.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Feb 12 2007)
> >>> Python/Zope Consulting and Support ...http://www.egenix.com/
> >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
> >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/
>
>
> Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free !
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/sergio.correia%2Bpydev%40gmail.com
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Interning string subtype instances
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, so it can compare them quickly whether they are equal or not. Your version could detect equal strings quickly, but not unequal strings. -- Greg ___ Python-Dev mailing list Python-Dev@python.org 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
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 find; the .[] jumped out immediately. >> (When do you ever see self[anything]?) > > Raymond's -> suggestion was nice. 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. Ron ___ Python-Dev mailing list Python-Dev@python.org 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
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 .[] jumped out immediately.
> > (When do you ever see self[anything]?)
>
> Raymond's -> suggestion was nice.
>
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.
Why did the brace syntax wasn't even discussed ? Seems clean to me.
obj{expr} can be read as "given obj as a namespace, retrieve the name
resulting by expr in obj and enclosing namespaces (supers)".
We can even use slice-like syntax for further improvements :
obj{expr:default}
obj{expr:default:type_}
something like getattr(super(type_, obj), expr, default), or even
obj{expr::}
for getattr(super(obj.__class__, obj), expr)
and, why not, even obj{:} for super(obj.__class__, obj),
regards,
___
Python-Dev mailing list
Python-Dev@python.org
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
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 are better ways of doing things. > Even if you do add a new syntax for this, using parenthesis is > a poor choice IMHO as the resulting code looks too much like a > function call (e.g. "callable.(variable)"). Yes. The .[] notation looks much better, IMO. Neil ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Weekly Python Patch/Bug Summary
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 writing support in wave.py (2007-02-05) http://python.org/sf/1652328 opened by tom tarfile append behavior (2007-02-05) CLOSED http://python.org/sf/1652681 opened by Witten operator.c slice functions need to parse ssize_t (2007-02-07) http://python.org/sf/1654417 opened by Andy Wingo sys.excepthook shows relevant bindings. (2007-02-08) http://python.org/sf/1654974 opened by Nefarious CodeMonkey, Jr. socketmodule fails to build because missing NETLINK_DNRTMSG (2007-02-11) http://python.org/sf/1657276 opened by Aleksandr Koltsoff Add syntax for dynamic attribute access (2007-02-11) http://python.org/sf/1657573 opened by Ben North documentation for element interface (2007-02-12) http://python.org/sf/1657613 opened by Tim Mitchell Patches Closed __ CodeContext visibility (2006-08-15) http://python.org/sf/1540869 closed by kbk Auto-completion list placement (2006-12-23) http://python.org/sf/1621265 closed by kbk Make Python Editor Useful Without Full IDLE (2005-01-26) http://python.org/sf/1110205 closed by kbk allow using normal indent width in shell in IDLE (2005-05-06) http://python.org/sf/1196946 closed by kbk configHandler support for raw data (2007-02-01) http://python.org/sf/1650174 closed by kbk tarfile append behavior (2007-02-05) http://python.org/sf/1652681 closed by gustaebel except too broad (2006-08-15) http://python.org/sf/1540849 closed by kbk Creating dicts for dict subclasses (2006-12-14) http://python.org/sf/1615701 closed by rhettinger Fix dict and set docs, re: immutability (2006-01-05) http://python.org/sf/1397711 closed by rhettinger Remove bad PREDICT in ceval.c (2006-03-04) http://python.org/sf/1443159 closed by rhettinger make trace.py --ignore-dir work (2006-10-05) http://python.org/sf/1571379 closed by montanaro Bugfix for #847665 (XMLGenerator dies in namespace mode) (2006-04-02) http://python.org/sf/1463026 closed by loewis New / Reopened Bugs ___ IDLE Hung up after open script by command line... (2006-09-20) CLOSED http://python.org/sf/1562193 reopened by faramir2 Nested Objects scope problem (2007-02-05) CLOSED http://python.org/sf/1652387 reopened by kkelchev Nested Objects scope problem (2007-02-05) CLOSED http://python.org/sf/1652387 reopened by kkelchev Nested Objects scope problem (2007-02-05) CLOSED http://python.org/sf/1652387 reopened by kkelchev Nested Objects scope problem (2007-02-05) CLOSED http://python.org/sf/1652387 opened by kkelchev logging formatter %(lineno)d does not work (2007-02-06) http://python.org/sf/1652788 opened by lx_jakal Double free/corruption? (2007-02-06) http://python.org/sf/1653121 opened by Jarek Zgoda print >> f, "Hello" produces no error: normal? (2007-02-06) http://python.org/sf/1653416 opened by E.-O. Le Bigot Python misbehaves when installed in / (patch attached) (2007-02-06) http://python.org/sf/1653457 opened by Chris Webb Problems in datetime.c and typeobject.c. (2007-02-07) CLOSED http://python.org/sf/1653736 opened by ked-tao crash / abort during install (2007-02-06) CLOSED http://python.org/sf/1653753 opened by SAndreason configure does not check/warn/stop for tk/tcl (2007-02-06) CLOSED http://python.org/sf/1653757 opened by SAndreason popen - wrong order on fileobjects in tuple returned (2007-02-07) CLOSED http://python.org/sf/1653940 opened by Emil Lind Installer should split tcl/tk and tkinter install options. (2007-02-07) http://python.org/sf/1654408 opened by Ron Adam thread join() with timeout hangs on Windows 2003 x64 (2007-02-07) http://python.org/sf/1654429 opened by bentoi thirdparty extensions, --enable-shared, static linking (2007-02-08) http://python.org/sf/1655392 opened by Marien Zwart hotshot.stats.load (2004-02-19) http://python.org/sf/900092 reopened by bcannon 3.4.1 comparison methods content (2007-02-09) CLOSED http://python.org/sf/1655683 opened by Jeffrey Miller email.Generator docs contain a bad off-site link (2007-02-08) CLOSED http://python.org/sf/1655800 opened by Forest Wilkinson Typo in Docs (2007-02-09) CLOSED http://python.org/sf/1656078 opened by Thomas Guettler I think, I have found this bug on time.mktime() (2007-02-10) http://python.org/sf/1656559 opened by Sérgio Monteiro Basto shutil.copyfileobj description is incomplete (2007-02-10) http://python.org/sf/1656578 opened by Witten tarfile.TarFile fileobject use needs clarifica
Re: [Python-Dev] New syntax for 'dynamic' attribute access
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 pixel.
> > > The .() example was hard to find; the .[] jumped out immediately.
> > > (When do you ever see self[anything]?)
> >
> > Raymond's -> suggestion was nice.
> >
> 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.
Yeah, so are 1.2 and 1,2. This is why the style guide (PEP 8) insists
on a space after a comma but not after a period.
> Why did the brace syntax wasn't even discussed ? Seems clean to me.
Because they are arbitrary -- if x{y} or x.{y} would be acceptable,
why not x. or x.|y| or x./y/? Or indeed why not [EMAIL PROTECTED] (Not that
I'm
in favor of that. :-)
That x.[y] and x.(y) resemble x[y] and x(y) is an *advantage* of the
proposed new notation, not a disadvantage; the new operator is
semantically closer to x[y] than to x(y) so x.[y] makes sense.
> obj{expr} can be read as "given obj as a namespace, retrieve the name
> resulting by expr in obj and enclosing namespaces (supers)".
Yeah, it can just as well be read as "call obj with 2**expr as
argument". Also, your reference to enclosing namespaces and supers is
misplaced -- this should map to the existing __getattr__ operation,
which can have many different semantics depending on the type of obj.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
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
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 would be. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org 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
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 self.open_unknown(fullurl, data)
> try:
> if data is None:
> return self.(name)(url)
> else:
> return self.(name)(url, data)
> except socket.error, msg:
> raise IOError, ('socket error', msg), sys.exc_info()[2]
Also notice that this leaves a hasattr call in, as there is no
replacement proposed for that.
> name = 'http_error_%d' % errcode
> if hasattr(self, name):
> method = self.(name)
> if data is None:
> result = method(url, fp, errcode, errmsg, headers)
> else:
> result = method(url, fp, errcode, errmsg, headers, data)
> if result: return result
> return self.http_error_default(url, fp, errcode, errmsg, headers)
Likewise.
> if attr[:12] == '_Request__r_':
> name = attr[12:]
> if hasattr(Request, 'get_' + name):
> self.['get_' + name]()
> return self.[attr]
> raise AttributeError, attr
And again. 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.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
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
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 form, or else people always wonder what the precedence is, and add parenthesis anyway just to be on the safe side. BTW, which of these would be correct (a).[b] (a.)[b] a.[(b)] a.([b]) a . [ b ] and what is the semantics of a.[42] Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Recent experience with the _ast module
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 visitor so that I don't accidentally iterate over it.
That can be done, I think.
> 2) {BinOp,AugAssign,BoolOp,etc}.op is an instance of, eg, Add, Sub,
> Mult, Mod, meaning you have to dispatch based on tests like
> "isinstance(node.op, x)" or "type(node.op) is x". I would much, much
> prefer to spell this "node.op is x", ie, use "node.op = Add" rather
> than the current "node.op = Add()" when constructing the nodes.
Please look at Python.asdl. This things are really belong to sum nodes,
and Add, Sub etc. are really operators.
I *think* they are singletons, and I don't mind making it a guarantee
that they are: i.e. all operators that have no fields and where the
sum has no attributes.
If you want to write "is", you can also write
node.op.__class__ is Add
> 3) I'd like there to be an Else() node for If.orelse, While.orelse,
> etc. My motivation is that I need the lineno and col_offset values of
> the "else" statement for a code-coverage utility; as it is, I have to
> find the last lineno of the if/while/etc suite and the first lineno of
> the "else" suite and then search between those two for the "else"
> statement.
Notice that you cannot restore the original source code, anyway. You
cannot tell whether something was else:if or elif.
I don't understand why you need the line number of the else keyword
(which, as I said, may not exist in the source) for code coverage:
The 'else' is never executed (only the statements in it are).
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
