On Wed, 28 Nov 2007 16:20:05 +0100, you wrote:
>What name do you prefer? I'm +1 with Raymond on __root__ but I'm still
>open for better suggestions.
how about making it (a little bit) more explicit with
__rootdict__ or
__root_dict__
--
Ton
___
Python
On Nov 28, 2007 10:11 PM, Ron Adam <[EMAIL PROTECTED]> wrote:
> Keeping __root__ relatively short has the benefit of being able to easily
> use "__root__.name" in the case where "name" was/is used in the local
> scope. I don't see any reason to make it harder. There might even be a
> use case for
On 11/28/07, 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.
>
I think __root__ is a fine name. Anyway, here some suggestions (in no
particular order):
__top__
__syswide__
__outer__
__t
Fred Drake wrote:
> On Nov 28, 2007, at 9:31 PM, Brett Cannon wrote:
>> +1 for either __root_namespace__ or __root__.
>
>
> What is it with nutrient extractors for plants that makes sense here?
Root is a word that takes on a specific meaning depending on the context.
Root as in tooth
> IMO, it's not reasonable since the application could use something
> different than select.select(), like select.poll() or something else
> again.
As I said before, you can do away with select or poll altogether if
you write a state machine for your asyncore dispatcher. Asyncore will
tell you w
"Christian Heimes" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
||
| What name do you prefer? I'm +1 with Raymond on __root__ but I'm still
| open for better suggestions.
Ok with me, or __rootnames__, but __root_namespace__ is too long for me ;-)
__
On 29 Nov, 03:27, Bill Janssen <[EMAIL PROTECTED]> wrote:
> > It does raise the same exception.
>
> Hmmm, not in my version.
>
> > Are there plans for fixing this?
>
> Yes, it's fixed in my CVS, and I'll upload a new version to PyPI when
> I get a chance.
>
> > Using that kind of workaround is not
On Nov 28, 2007, at 9:31 PM, Brett Cannon wrote:
> +1 for either __root_namespace__ or __root__.
What is it with nutrient extractors for plants that makes sense here?
The goal is to make it blindingly obvious to someone reading code they
didn't write (or even that they did) what's going on.
+
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.joevial.com/statsvn/
Interesting. Un
On Nov 28, 2007 12:45 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On Nov 28, 2007 12:28 PM, Laurent Gautier <[EMAIL PROTECTED]> wrote:
> > I find __root_namespace__ rather explicit without being unbearably long.
>
> Perhaps the length is even an advantage -- this is not something that
> shoul
> It does raise the same exception.
Hmmm, not in my version.
> Are there plans for fixing this?
Yes, it's fixed in my CVS, and I'll upload a new version to PyPI when
I get a chance.
> Using that kind of workaround is not acceptable in any case (select
> module shouldn't even get imported when u
On 29 Nov, 00:26, Bill Janssen <[EMAIL PROTECTED]> wrote:
> > I tried to write a simple asyncore-based server code, then I used a
> > simple client to establish a connection with it.
> > Once the client is connected server raises the following exception:
>
> I think this is a bug. Thanks!
You're
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.joevial.com/statsvn/
Enjoy,
Joseph Armbruster
___
Python-Dev mailing list
P
> I tried to write a simple asyncore-based server code, then I used a
> simple client to establish a connection with it.
> Once the client is connected server raises the following exception:
I think this is a bug. Thanks!
The issue is that the internal call to do_handshake() doesn't handle
non-b
Guido van Rossum wrote:
> You can do that but the special entry in globals is still required in
> order to pass it on to all scopes that need it.
Unless you use something other than a plain dict for
module namespaces.
--
Greg
___
Python-Dev mailing list
Steve Holden wrote:
> The namespace should really be called __global__. I doubt this will fly,
> because it's too radical, and unfortunately would undermine the "global"
> keyword
__uberglobal__
--
Greg
___
Python-Dev mailing list
Python-Dev@python.or
[EMAIL PROTECTED] wrote:
> Sorry if this is a dumb question, but are there actually good reasons to
> remove "types"?
> IMHO the types module helps keeping code readable.
> For example
> "if type(obj) == FloatType"
> is just more readable than
> "if type(obj) == type(1.0)".
>
if isinstance(ob
On Nov 28, 2007 2:23 PM, <[EMAIL PROTECTED]> wrote:
> Sorry if this is a dumb question, but are there actually good reasons to
> remove "types"?
> IMHO the types module helps keeping code readable.
> For example
> "if type(obj) == FloatType"
> is just more readable than
> "if type(obj) == type(1.
Sorry if this is a dumb question, but are there actually good reasons to remove
"types"?
IMHO the types module helps keeping code readable.
For example
"if type(obj) == FloatType"
is just more readable than
"if type(obj) == type(1.0)".
Luckily Python does not distinguish float and double like oth
On Wed, 2007-11-28 at 16:20 +0100, Christian Heimes wrote:
> What name do you prefer? I'm +1 with Raymond on __root__ but I'm still
> open for better suggestions.
My suggestions, in descending degrees of seriousness:
__core__
__fixtures__
--
Carsten Haese
http://informixdb.sourceforge.net
__
Hi,
Christian Heimes cheimes.de> writes:
>
> GvR likes to rename the __builtin__ to reduce confusing between
> __builtin__ and __builtins__. He wanted to start a poll on the new name
> but apparently he forgot.
>
> >From http://bugs.python.org/issue1498
>
> What name do you prefer? I'm +1 with
On Nov 28, 2007 12:28 PM, Laurent Gautier <[EMAIL PROTECTED]> wrote:
> I find __root_namespace__ rather explicit without being unbearably long.
Perhaps the length is even an advantage -- this is not something that
should be messed with lightly.
> If length is an issue, and __root__ not found expl
I find __root_namespace__ rather explicit without being unbearably long.
If length is an issue, and __root__ not found explicit, I am
suggesting __session__.
L.
2007/11/28, Stephen Hansen <[EMAIL PROTECTED]>:
> (The lurker awakes...)
>
>
> >
> > > If not that I suggest something like __inject
(The lurker awakes...)
> > If not that I suggest something like __inject_builtins__. This
> > implies it's a command to eval/exec, and doesn't necessarily reflect
> > your current builtins (which are canonically accessible as an
> > attribute of your frame.)
>
> You're misunderstanding the reason
Christian Heimes schrieb:
> Adam Olsen wrote:
>> -1 on __python__. It seems to be an abbreviation of "python
>> interpreter core" or the like, but on its own it implies nothing about
>> what it means.
>>
>> Contrast that with __root__ where we all know what a root is, even
>> though it doesn't im
Adam Olsen wrote:
> -1 on __python__. It seems to be an abbreviation of "python
> interpreter core" or the like, but on its own it implies nothing about
> what it means.
>
> Contrast that with __root__ where we all know what a root is, even
> though it doesn't imply what kind of root it is or how
On Nov 28, 2007 11:02 AM, Facundo Batista <[EMAIL PROTECTED]> wrote:
> 2007/11/28, Guido van Rossum <[EMAIL PROTECTED]>:
>
> > ATM I'm torn between __root__ and __python__.
>
> __root__ gives me the idea of the base of a tree, its primary node. +0
Which it is, if you consider nested namespaces as
On Nov 28, 2007 11:50 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On Nov 28, 2007 10:46 AM, Adam Olsen <[EMAIL PROTECTED]> wrote:
> > On Nov 28, 2007 8:20 AM, Christian Heimes <[EMAIL PROTECTED]> wrote:
> > > I'm sending this mail to Python-dev in the hope to reach more developers.
> > >
> >
2007/11/28, Guido van Rossum <[EMAIL PROTECTED]>:
> ATM I'm torn between __root__ and __python__.
__root__ gives me the idea of the base of a tree, its primary node. +0
__python__ gives me the idea of something very deep inside python. +1
Regards,
--
.Facundo
Blog: http://www.taniquetil.
On Nov 28, 2007 10:46 AM, Adam Olsen <[EMAIL PROTECTED]> wrote:
> On Nov 28, 2007 8:20 AM, Christian Heimes <[EMAIL PROTECTED]> wrote:
> > I'm sending this mail to Python-dev in the hope to reach more developers.
> >
> > GvR likes to rename the __builtin__ to reduce confusing between
> > __builtin_
On Nov 28, 2007 8:20 AM, Christian Heimes <[EMAIL PROTECTED]> wrote:
> I'm sending this mail to Python-dev in the hope to reach more developers.
>
> GvR likes to rename the __builtin__ to reduce confusing between
> __builtin__ and __builtins__. He wanted to start a poll on the new name
> but appare
On Nov 28, 2007 9:39 AM, Georg Brandl <[EMAIL PROTECTED]> wrote:
> Steve Holden schrieb:
>
> >> What name do you prefer? I'm +1 with Raymond on __root__ but I'm still
> >> open for better suggestions.
> >>
> > The namespace should really be called __global__. I doubt this will fly,
> > because it's
Steve Holden schrieb:
>> What name do you prefer? I'm +1 with Raymond on __root__ but I'm still
>> open for better suggestions.
>>
> The namespace should really be called __global__. I doubt this will fly,
> because it's too radical, and unfortunately would undermine the "global"
> keyword, use
Hello everybody! I really should introduce myself before stating my
opinion. But I'll keep this short and sweet --
I have been "trolling" python-dev for a while just to keep up on its
development and have never posted but I thought I'd share my opinion on
this thread simply because it's a simple
Paul Moore wrote:
> What about __global__? If that's not an option, I'm OK with __root__.
__global__ was also on my list but I've abolished it. It could create
confusing with globals().
Christian
___
Python-Dev mailing list
Python-Dev@python.org
http://
Christian Heimes wrote:
> I'm sending this mail to Python-dev in the hope to reach more developers.
>
> GvR likes to rename the __builtin__ to reduce confusing between
> __builtin__ and __builtins__. He wanted to start a poll on the new name
> but apparently he forgot.
>
>>From http://bugs.python
Paul Moore schrieb:
> On 28/11/2007, Georg Brandl <[EMAIL PROTECTED]> wrote:
>> Christian Heimes schrieb:
>> > What name do you prefer? I'm +1 with Raymond on __root__ but I'm still
>> > open for better suggestions.
>>
>> FWIW, +1 for __root__ too.
>
> What about __global__? If that's not an optio
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Nov 28, 2007, at 10:20 AM, Christian Heimes wrote:
>
> What name do you prefer? I'm +1 with Raymond on __root__ but I'm still
> open for better suggestions.
>
The only other thing I can suggest is __python__ built __root__ works
fine for me too.
On 28/11/2007, Georg Brandl <[EMAIL PROTECTED]> wrote:
> Christian Heimes schrieb:
> > What name do you prefer? I'm +1 with Raymond on __root__ but I'm still
> > open for better suggestions.
>
> FWIW, +1 for __root__ too.
What about __global__? If that's not an option, I'm OK with __root__.
Paul.
Christian Heimes wrote:
> I'm sending this mail to Python-dev in the hope to reach more developers.
>
> GvR likes to rename the __builtin__ to reduce confusing between
> __builtin__ and __builtins__. He wanted to start a poll on the new name
> but apparently he forgot.
>
>>From http://bugs.pyth
Christian Heimes schrieb:
> I'm sending this mail to Python-dev in the hope to reach more developers.
>
> GvR likes to rename the __builtin__ to reduce confusing between
> __builtin__ and __builtins__. He wanted to start a poll on the new name
> but apparently he forgot.
>
>>From http://bugs.pyth
Christian Heimes wrote:
> I'm sending this mail to Python-dev in the hope to reach more developers.
>
> GvR likes to rename the __builtin__ to reduce confusing between
> __builtin__ and __builtins__. He wanted to start a poll on the new name
> but apparently he forgot.
>
> >From http://bugs.python.
I'm sending this mail to Python-dev in the hope to reach more developers.
GvR likes to rename the __builtin__ to reduce confusing between
__builtin__ and __builtins__. He wanted to start a poll on the new name
but apparently he forgot.
>From http://bugs.python.org/issue1498
---
In http://bugs.pyt
Titus Brown schrieb:
> Dear Python-Dev-ers,
>
> about half of the tasks for the GHOP contest (described below) are
> currently on the stdlib, Python core, or Py3K:
>
>
> http://code.google.com/p/google-highly-open-participation-psf/issues/list?q=label:stdlib
>
>
> http://code.googl
Nick Coghlan wrote:
> 'new' has now been deprecated for 3.0, GvR suggested it would be nice to
> get rid of 'types' as well.
I've removed the 'new' module from py3k and also removed a lot of types
from the 'types' module in py3k. It only contains types that aren't
easily available through builtin
Redirecting discussion from python-checkins to python-dev.
'new' has now been deprecated for 3.0, GvR suggested it would be nice to
get rid of 'types' as well.
Christian Heimes wrote:
> Georg Brandl wrote:
>> I've just looked, and the types you can't get trivially via builtin or
>> type(singleto
46 matches
Mail list logo
