;`On Thu, 2007-02-22 at 01:26 +0100, Giovanni Bajo wrote:
> On 20/02/2007 16.07, Steven Elliott wrote:
>
> > I'm finally getting back into this. I'd like to take one more shot at
> > it with a revised version of what I proposed before.
> >
> > For those of you that did not see the original th
On 20/02/2007 16.07, Steven Elliott wrote:
> I'm finally getting back into this. I'd like to take one more shot at
> it with a revised version of what I proposed before.
>
> For those of you that did not see the original thread it was about ways
> that accessing builtins could be more efficien
On Tue, 2007-02-20 at 07:48 -0800, Guido van Rossum wrote:
> If this is not a replay of an old message, please move the discussion
> to python-ideas.
It's a modified version of an old idea, so I wasn't sure where to post
it since previously it was discussed here. I'll look into python-ideas.
--
If this is not a replay of an old message, please move the discussion
to python-ideas.
On 2/20/07, Steven Elliott <[EMAIL PROTECTED]> wrote:
> I'm finally getting back into this. I'd like to take one more shot at
> it with a revised version of what I proposed before.
>
> For those of you that did
I'm finally getting back into this. I'd like to take one more shot at
it with a revised version of what I proposed before.
For those of you that did not see the original thread it was about ways
that accessing builtins could be more efficient. It's a bit much to
summarize again now, but you sh
| [ Raymond Hettinger ]:
| > If someone really cared about the double lookup, they could
| > flatten a level by starting their modules with:
| >
| >from __builtin__ import *
| >
| > However, we don't see people writing this kind of code. That
| > could mean that the double lookup has
On Thu, 2006-03-09 at 08:51 -0800, Raymond Hettinger wrote:
> [Steven Elliott]
> > As you probably know each access of a builtin requires two hash table
> > lookups. First, the builtin is not found in the list of globals. It is
> > then found in the list of builtins.
>
> If someone really cared
At 02:47 PM 3/13/2006 -0500, Jim Jewett wrote:
>Paul Moore wrote:
>
> > Is there any practical way of detecting and flagging
> > constructs like the above (remotely shadowing a
> > builtin in another module)?
>
>Phillip J. Eby wrote:
> > the patch ended up being backed out ... too strict
> > of a c
Phillip J. Eby wrote:
> At 02:47 PM 3/13/2006 -0500, Jim Jewett wrote:
>
>>Paul Moore wrote:
>>
>>
>>>Is there any practical way of detecting and flagging
>>>constructs like the above (remotely shadowing a
>>>builtin in another module)?
>>
>>Phillip J. Eby wrote:
>>
>>>the patch ended up being bac
Paul Moore wrote:
> Is there any practical way of detecting and flagging
> constructs like the above (remotely shadowing a
> builtin in another module)?
Phillip J. Eby wrote:
> the patch ended up being backed out ... too strict
> of a check to be accepted for Python 2.4.
http://svn.python.org/vi
Steven Elliott wrote:
> The important difference between builtins and globals is that with
> builtins both the compiler and the runtime can enumerate all
> references
> to builtins in a single consistent way. That is "True" can always be
> builtin #3 and "len" can always be builtin #17, or whate
Steven Elliott wrote:
> a pyc file referencing a global in a module may
> have been compiled with a different version of that module (that is
> "some_module.some_global" can't compiled to single fixed index since
> stuff may shift around in "some_module").
Not sure I quite follow that. Since the
Guido van Rossum wrote:
> I don't see why everything that doesn't make sense to be shadowed
> ought to become a keyword.
That wasn't the reason. I was thinking it
would be nice if one could use True and False
instead of 1 and 0 in the knowledge that it
wasn't costing a couple of dictionary lookup
On Fri, 2006-03-10 at 12:46 +1300, Greg Ewing wrote:
> Steven Elliott wrote:
> > One way of handling it is to
> > alter STORE_ATTR (op code for assigning to mod.str) to always check to
> > see if the key being assigned is one of the default builtins. If it is,
> > then the module's indexed array o
On 3/10/06, Neil Schemenauer <[EMAIL PROTECTED]> wrote:
> Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > Not even True and False.
> >
> > I don't see why everything that doesn't make sense to be shadowed
> > ought to become a keyword. That way lies madness.
>
> Have you considered whether P3K will
Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Not even True and False.
>
> I don't see why everything that doesn't make sense to be shadowed
> ought to become a keyword. That way lies madness.
Have you considered whether P3K will disallow names from being
shadowed in such as way as to prevent the
On 3/10/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
>
> > I don't think we should make any of these keywords.
>
> Not even True and False? The only good reasons
> I can see for anyone wanting to shadow these
> are backwards compatibility ones.
Not even True and False.
I do
Guido van Rossum wrote:
> I don't think we should make any of these keywords.
Not even True and False? The only good reasons
I can see for anyone wanting to shadow these
are backwards compatibility ones.
Greg
___
Python-Dev mailing list
Python-Dev@pyth
At 12:46 PM 3/10/2006 +1300, Greg Ewing wrote:
>Steven Elliott wrote:
> > One way of handling it is to
> > alter STORE_ATTR (op code for assigning to mod.str) to always check to
> > see if the key being assigned is one of the default builtins. If it is,
> > then the module's indexed array of built
On 3/9/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> BTW, are there any plans to make True and False hard
> constants in 3.0 (like None is now)? Maybe also
> others like Ellipsis, NotImplemented, etc.
I don't think we should make any of these keywords.
--
--Guido van Rossum (home page: http://www.p
Raymond Hettinger wrote:
> That is going to be difficult as long as it is legal to write:
>
> True = 0
BTW, are there any plans to make True and False hard
constants in 3.0 (like None is now)? Maybe also
others like Ellipsis, NotImplemented, etc.
Greg
___
Steven Elliott wrote:
> One way of handling it is to
> alter STORE_ATTR (op code for assigning to mod.str) to always check to
> see if the key being assigned is one of the default builtins. If it is,
> then the module's indexed array of builtins is assigned to.
As long as you're going to all that
Phillip J. Eby wrote:
> I think this is a reasonable implementation limit on dynamicity,
Absolutely.
> although to be conservative I think we should only do this with -O in
> Python 2.5, if we do it at all.
Or with a __future__ directive?
Just
___
Py
At 08:51 AM 3/9/2006 -0800, Raymond Hettinger wrote:
> > Perhaps what I'm suggesting isn't feasible for reasons that have already
> > been discussed. But it seems like it should be possible to make "while
> > True" as efficient as "while 1".
>
>That is going to be difficult as long as it is legal
* Paul Moore wrote:
> If it *is* possible, I'd say it's worth implementing at least a
> warning sooner rather than later - the practice seems questionable at
> best, and any progress towards outlawing it would help in work on
> optimising builtins.
FWIW, this practice is very handy for unit tes
Steven Elliott <[EMAIL PROTECTED]> wrote:
> I'm interested in how builtins could be more efficient. I've read over
> some of the PEPs having to do with making global variables more
> efficient (search for "global"):
> http://www.python.org/doc/essays/pepparade.html
> But I think the problem c
[Steven Elliott]
> As you probably know each access of a builtin requires two hash table
> lookups. First, the builtin is not found in the list of globals. It is
> then found in the list of builtins.
If someone really cared about the double lookup, they could flatten a level by
starting their m
At 08:50 AM 3/9/2006 -0600, Steven Elliott wrote:
>I believe that currently "mod.str = my_str" alters the module's global
>hash table (f->f_globals in the code). One way of handling it is to
>alter STORE_ATTR (op code for assigning to mod.str) to always check to
>see if the key being assigned is o
On Thu, 2006-03-09 at 12:00 +, Paul Moore wrote:
> On 3/9/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> > Steven Elliott wrote:
> > > I'm interested in how builtins could be more efficient. I've read over
> > > some of the PEPs having to do with making global variables more
> > > efficient (se
On 3/9/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Steven Elliott wrote:
> > I'm interested in how builtins could be more efficient. I've read over
> > some of the PEPs having to do with making global variables more
> > efficient (search for "global"):
> > http://www.python.org/doc/essays/pe
Steven Elliott wrote:
> I'm interested in how builtins could be more efficient. I've read over
> some of the PEPs having to do with making global variables more
> efficient (search for "global"):
> http://www.python.org/doc/essays/pepparade.html
> But I think the problem can be simplified by f
I'm interested in how builtins could be more efficient. I've read over
some of the PEPs having to do with making global variables more
efficient (search for "global"):
http://www.python.org/doc/essays/pepparade.html
But I think the problem can be simplified by focusing strictly on
builtins.
O
32 matches
Mail list logo
