Guido van Rossum wrote:
> Hm.
>
> On my Linux box, in the trunk:
>
> Before the patch:
> Pystone(1.1) time for 5 passes = 1.16
> This machine benchmarks at 43103.4 pystones/second
>
> After the patch:
> Pystone(1.1) time for 5 passes = 1.14
> This machine benchmarks at 43859.6 pystones/s
On Nov 29, 2007 11:54 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> But then I thought, what if we renamed the __builtin__ module instead
> to builtins, and left __builtins__ alone?
Hmm. __builtins__ is a magic hook, but __builtin__-the-module isn't
the thing it hooks, exactly, not the way __
On Nov 29, 2007 3:12 PM, Terry Reedy <[EMAIL PROTECTED]> wrote:
> "Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> | But then I thought, what if we renamed the __builtin__ module instead
> | to builtins, and left __builtins__ alone?
> |
> | In Python 0.1, __builtin
2007/11/29, Greg Ewing <[EMAIL PROTECTED]>:
>
> __ubiquitous__
>
Uh! Great!
+1
--
.Facundo
Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/l
"Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| But then I thought, what if we renamed the __builtin__ module instead
| to builtins, and left __builtins__ alone?
|
| In Python 0.1, __builtin__ *was* called builtin, and I think the
| reason for renaming it wasn't p
> __the_dictionary_where_all_the_builtins_are_now__
__the_entry_formerly_known_as_builtins__
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/option
Another idea:
__ubiquitous__
--
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
On Fri, Nov 30, 2007 at 11:22:03AM +1300, Greg Ewing wrote:
> The next step up from global would be __galactic__.
Let me skip __universe[al]__ and go directly to The Ultimate Questions:
Is there __life__ after __death__? Does __Deity__ exist? What attributes,
properties and keys has __He__ got?
Nick Coghlan wrote:
> why not call it __implicit__?
But isn't __explicit__ better than __implicit__? :-)
I tend to agree about __root__, though -- it just
doesn't seem quite right somehow.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http
The next step up from global would be __galactic__.
--
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
"Nick Coghlan" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| [EMAIL PROTECTED] wrote:
| > Sorry if this is a dumb question, but are there actually good reasons
to remove "types"?
|
| Mainly because it is an unrelated grab bag of types that could be put in
| more topical locations
On Nov 29, 2007 1:07 PM, Neil Toronto <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > Cool! Can't wait to get my hands on it. How does it affect pystone?
>
> Pystone likes it, according to my tests and Chris's. On his machine, if
> I'm reading these stones right, it takes about 7% off the
Guido van Rossum wrote:
> Cool! Can't wait to get my hands on it. How does it affect pystone?
Pystone likes it, according to my tests and Chris's. On his machine, if
I'm reading these stones right, it takes about 7% off the run time on
average. On mine it takes off 4%.
> What happens if the glo
I nearly choked on my coffee when I read the "naming rights" suggestion. :-)
Then I started leaning towards __universal__.
But then I thought, what if we renamed the __builtin__ module instead
to builtins, and left __builtins__ alone?
In Python 0.1, __builtin__ *was* called builtin, and I think
Cool! Can't wait to get my hands on it. How does it affect pystone?
What happens if the globals are not a real dict but an instance of
another collections.MutableMapping (virtual or real) subclass?
We've worked hard (well, some folks have) to enable this. It would be
a show-stopper if this broke
> No, the SSL code should NOT be allowed to block anything in any case,
> even though the handshake is still not completed, in which case just
> retry it at a later time.
That's why there's "do_handshake_on_connect" in the first place. I'm
just talking about what the SSL module should do if you d
At 11:16 PM 11/29/2007 +1000, Nick Coghlan wrote:
>Function locals, module globals and program universals would make more
>sense to me - outer layers have a broader scope than inner layers.
+1 for __universal__
___
Python-Dev mailing list
Python-Dev@py
On Thu, Nov 29, 2007 at 10:27:37AM -0500, Barry Warsaw wrote:
> > Perhaps someone here can draw some inspiration from __monty__ python's
> > flying __circus__. It would be nice to have a name with a pythonic
> > __ground__.
>
> Clearly then, it should be called __bruce__.
No, __spam__!
__Ole
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Nov 29, 2007, at 8:47 AM, Graham Horler wrote:
> Perhaps someone here can draw some inspiration from __monty__ python's
> flying __circus__. It would be nice to have a name with a pythonic
> __ground__.
Clearly then, it should be called __bruce__
Nick Coghlan wrote:
> And svnmerge committers get lots of LoC credits. Thomas's 58k line
> commit in September must have taken a while :)
Exactly! Most of my LoC credits must either come from svnmerge or my
work on PCBuild9. Visual Studio's project xml files contain a *lot* of
space and meaningle
On 29 Nov, 06:00, Bill Janssen <[EMAIL PROTECTED]> wrote:
> I think it's simpler to let the SSL module do it, even though it comes
> at the expense of blocking the thread till the handshake is complete.
> That's essentially what happens already. The question is whether the
> SSL setup code is al
On Thu, 29 Nov 2007, Graham Horler wrote:
> Perhaps someone here can draw some inspiration from __monty__ python's
> flying __circus__. It would be nice to have a name with a pythonic
> __ground__.
>
> Unfortunately that show is not my __staple__ entertainment, and although
> I have a __general__
Are we scraping the __bottom__ of the English language __barrel__?
Perhaps someone here can draw some inspiration from __monty__ python's
flying __circus__. It would be nice to have a name with a pythonic
__ground__.
Unfortunately that show is not my __staple__ entertainment, and although
I hav
Nick Coghlan wrote:
> Function locals, module globals and program universals would make more
> sense to me - outer layers have a broader scope than inner layers.
__universal__ rhymes with the other __*al__ names, too. I'm shifting my
vote from __root__ to __universal__. All hail the Aussies! :)
C
Christian Heimes wrote:
> I tend to agree that local, nonlocal, global and the-other-thingie are
> more like the layers of an onion than a tree. It makes sense to me. The
> name lookup starts at the local level and goes all the way out until it
> reaches the universal level. Or does it go in until
This is an interesting thread, here is my 1c :-)
Unless one is feeling chronologically challenged, it is always the
__last__ layer looked in as Christian Heimes described, so maybe
__lastns__ or __latter__, or even __zns__.
Perhaps __final__ or __finalns__ sounds too similar to "finally:".
How a
On Nov 28, 2007 4:20 PM, Christian Heimes <[EMAIL PROTECTED]> wrote:
> What name do you prefer? I'm +1 with Raymond on __root__ but I'm still
> open for better suggestions.
Perhaps __basic__?
Fredrik
___
Python-Dev mailing list
Python-Dev@python.org
htt
Neil Toronto wrote:
>> Since Python 3.0 supports all unicode chars I vote for __überglobal__.
>
> Make it untypeable to most Americans so as to discourage use? If that's
> what we're going for, I suggest the somewhat more self-documenting and
> less impossible __the_dictionary_where_all_the_buil
On 2007-11-29 11:52, Titus Brown wrote:
> Hi all,
>
> is there a good, or standard memory benchmarking system for Python?
> pybench doesn't return significantly different results when Python 2.6
> is compiled with pymalloc and without pymalloc. Thinking on it, I'm not
> too surprised -- pybench p
Given that the *effect* of __builtins__ is to make the contents of the
__builtin__ module implicitly available in every module's global
namespace, why not call it __implicit__?
I really don't like all of these __root__ inspired names, because
__builtin__ isn't the root of any Python hierarchy t
Christian Heimes wrote:
> Greg Ewing wrote:
>> __uberglobal__
>
> Since Python 3.0 supports all unicode chars I vote for __überglobal__.
Make it untypeable to most Americans so as to discourage use? If that's
what we're going for, I suggest the somewhat more self-documenting and
less impossible
Brett Cannon wrote:
> On Nov 28, 2007 3:25 PM, Joseph Armbruster <[EMAIL PROTECTED]> wrote:
>> All,
>>
>> I was looking at statsvn today at work and gave it a test-run on a repo
>> there.
>> I wondered what it would look like for python3k. And... here are the
>> results:
>>
>> http://www.joevi
Hi all,
is there a good, or standard memory benchmarking system for Python?
pybench doesn't return significantly different results when Python 2.6
is compiled with pymalloc and without pymalloc. Thinking on it, I'm not
too surprised -- pybench probably benchmarks a lot of stuff -- but some
guidan
Greg Ewing wrote:
> __uberglobal__
Since Python 3.0 supports all unicode chars I vote for __überglobal__.
Christian
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org
[EMAIL PROTECTED] wrote:
> Sorry if this is a dumb question, but are there actually good reasons to
> remove "types"?
Mainly because it is an unrelated grab bag of types that could be put in
more topical locations - what they're for is more interesting than the
mere fact that they happen to be
I've posted a patch here:
http://bugs.python.org/issue1518
for 2.6a0 that speeds up LOAD_GLOBAL to where it's just barely slower
than LOAD_FAST for both globals and builtins. It started life here, in
Python-ideas:
http://mail.python.org/pipermail/python-ideas/2007-November/001212.html
The ide
36 matches
Mail list logo
