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(singleton)
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
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
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
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
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
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
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.
-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.
-
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 option, I'm OK with
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
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
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
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, used in 2.x
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 too radical,
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__ and
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:
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 apparently
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 a tree
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 its
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.
GvR likes to
(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 why
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 imply what kind
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
Hi,
Christian Heimes lists at 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
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
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 other
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.0).
But you
[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(obj, float)
or
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.org
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
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
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
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 welcome.
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
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 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
should be
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 acceptable in
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 ;-)
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
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 root,
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 using
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
___
44 matches
Mail list logo
