Hi everybody on the list !
Sorry about the off-topic message, but giving the nature of the
message and the nature of the list (after all, everybody here uses
Internet or develops for web in some way), I decided to post this here
and see what you guys think about it.
Calvin Spealman wrote:
I'd like to make a claim about the following example, that
update_wrapper should be improved to preserve the behavior of known,
built-in decorators. In this case, I'm talking about staticmethod. The
order I list here feels natural, but it obviously doesn't work. The only
Benjamin Peterson wrote:
On Wed, Jun 11, 2008 at 1:03 PM, Raymond Hettinger [EMAIL PROTECTED] wrote:
Function names should be lowercase, with words separated by underscores as
necessary to improve readability. -- PEP 8
If I'm reading this correctly, then underscores are not required
At 08:32 PM 6/11/2008 -0400, Terry Reedy wrote:
The Data Model chapter of the Reference Manual lists .__dict__ as a special
attribute of callables, modules, classes, and instances. It describes
__dict__ as a namespace dictionary or implementation of the namespace
thereof. Since namespaces map
Curt Hagenlocher wrote:
If I recall correctly, Jython handles this by appending a trailing
underscore to the imported name and there's no reason why we couldn't
do something similar.
It also has the virtue of being the common convention for attribute
names that shadow keywords even in CPython
At 02:59 AM 6/12/2008 +0200, Maciej Fijalkowski wrote:
It's about abusing locals, which are not even given that they'll
modify this dict.
Note that class bodies are a special case: as of PEP 3115, it's
possible for a class body's locals to be a non-dictionary object, so
it makes no sense to
Guido van Rossum wrote:
On Wed, Jun 11, 2008 at 4:35 AM, Barry Warsaw [EMAIL PROTECTED] wrote:
So I had planned to do a bunch of work last night looking at the release
blocker issues, but nature intervened. A bunch of severe thunderstorms
knock out my 'net access until this morning.
I'll try
Hi,
could someone look for this ... or I am the only one which noticed that.
ping works but http://bugs.python.org giges after a timeout:
Proxy Error
The proxy server received an invalid response from an upstream server.
The proxy server could not handle the request GET /.
Reason: Error
That's odd - I've been doing all of the mp work on osx 10.5.3 - I'll
run the units in a loop today to see if I can catch it.
-Jesse
On Jun 12, 2008, at 1:00 AM, Barry Warsaw [EMAIL PROTECTED] wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Much thanks to Benjamin Peterson and Alexandre
On Thu, Jun 12, 2008 at 11:48 AM, anton [EMAIL PROTECTED] wrote:
ping works but http://bugs.python.org giges after a timeout:
Seeing the same thing here, so it's not just you.
Schiavo
Simon
___
Python-Dev mailing list
Python-Dev@python.org
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jun 12, 2008, at 5:48 AM, anton wrote:
could someone look for this ... or I am the only one which noticed
that.
ping works but http://bugs.python.org giges after a timeout:
Proxy Error
The proxy server received an invalid response from an
Phillip J. Eby wrote:
At 08:32 PM 6/11/2008 -0400, Terry Reedy wrote:
The Data Model chapter of the Reference Manual lists .__dict__ as a
special
attribute of callables, modules, classes, and instances. It describes
__dict__ as a namespace dictionary or implementation of the namespace
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jun 12, 2008, at 7:08 AM, Jesse Noller wrote:
That's odd - I've been doing all of the mp work on osx 10.5.3 - I'll
run the units in a loop today to see if I can catch it.
-Jesse
Thanks. It's definitely reproducible on both my Leopard boxes.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jun 11, 2008, at 2:03 PM, Raymond Hettinger wrote:
Function names should be lowercase, with words separated by
underscores as necessary to improve readability. -- PEP 8
If I'm reading this correctly, then underscores are not required
At 01:34 PM 6/12/2008 +0200, Carl Friedrich Bolz wrote:
Phillip J. Eby wrote:
As it happens, most objects' __dict__ slots are settable by default, and
*require* that you set it to a dict or subclass thereof.
This is wrong for types:
Which is why I said most - to exclude types, and objects
2008/6/12 Barry Warsaw [EMAIL PROTECTED]:
function:: active_count()
method:: Thread.get_name()
method:: Thread.is_alive()
method:: Thread.is_daemon()
method:: Thread.set_daemon(daemonic)
+1 on opting for properties in the specific cases here where it makes sense.
I'm +1 too... but
2008/6/12 anton [EMAIL PROTECTED]:
ping works but http://bugs.python.org giges after a timeout:
I can enter into it.
Also note that my issues showing system [1] was updated 6.5 hours ago,
so it was up at that time (my system goes and get some info twice a
day, you have the last updated info
On Thu, Jun 12, 2008 at 7:29 AM, Facundo Batista
[EMAIL PROTECTED] wrote:
+1 on opting for properties in the specific cases here where it makes sense.
If you can get Guido to agree to it, I'll implement it.
I'm +1 too... but which is the normal procedure here?
Should it be...
2.n :
Phillip J. Eby wrote:
At 01:34 PM 6/12/2008 +0200, Carl Friedrich Bolz wrote:
Phillip J. Eby wrote:
As it happens, most objects' __dict__ slots are settable by default,
and
*require* that you set it to a dict or subclass thereof.
This is wrong for types:
Which is why I said most - to
On Thu, Jun 12, 2008 at 2:56 PM, Carl Friedrich Bolz [EMAIL PROTECTED] wrote:
Of course attribute name lookups are affected, because you can have a
non-string key that has a __hash__ and __eq__ method to make it look
sufficiently like a string to the dict. Then the attribute lookup needs
to
[Barry]
http://bugs.python.org/issue643841
[Guido]
I've added a comment. Let me know if anything I said is unclear.
On Thu, Jun 12, 2008 at 3:35 AM, Nick Coghlan [EMAIL PROTECTED] wrote:
The bugtracker seems to be offline atm - I'll reply there once I can get to
it again (as well as
If you want to have a meaningful discussion about this, the addition
of the multiprocessing package and the recent threading.py API changes
must be rolled back, so we can design a proper API without the beta 1
pressure. Some observations:
- If it's isAlive() in Java style, it should be is_alive
Guido van Rossum wrote:
[Barry]
http://bugs.python.org/issue643841
[Guido]
I've added a comment. Let me know if anything I said is unclear.
On Thu, Jun 12, 2008 at 3:35 AM, Nick Coghlan [EMAIL PROTECTED] wrote:
The bugtracker seems to be offline atm - I'll reply
Guido van Rossum wrote:
[Barry]
http://bugs.python.org/issue643841
[Guido]
I've added a comment. Let me know if anything I said is unclear.
On Thu, Jun 12, 2008 at 3:35 AM, Nick Coghlan [EMAIL PROTECTED] wrote:
The bugtracker seems to be offline atm - I'll reply there once I can get to
it
Michael Foord wrote:
Guido van Rossum wrote:
Whether they'll care about this issue of course depends on whether
they need overloaded operators and other special delegations to be
delegated transparently. We'll have to see how important this is.
New-style classes have been around and recommended
M.-A. Lemburg wrote:
On 2008-06-11 17:15, Walter Dörwald wrote:
M.-A. Lemburg wrote:
On 2008-06-11 13:35, Barry Warsaw wrote:
So I had planned to do a bunch of work last night looking at the
release blocker issues, but nature intervened. A bunch of severe
thunderstorms knock out my 'net
Should it be...
2.n : .is_alive()
2.n+1 : .is_alive() (deprecated), .alive (recommended)
2.n+2 : .alive
Barry Personally, I'd go with a property .is_alive
I'm not fond of using a property for this since it can lull you into the
false belief that what you are doing
Hi,
On Wed, Jun 11, 2008 at 10:44:17PM -0400, Scott Dial wrote:
The only reason the test used locals() was
because it was the only way to insert a non-string key into the class
namespace.
This discussion is mistakenly focused on locals(). There is a direct
way to have arbitrary keys in the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jun 12, 2008, at 11:21 AM, [EMAIL PROTECTED] wrote:
Should it be...
2.n : .is_alive()
2.n+1 : .is_alive() (deprecated), .alive (recommended)
2.n+2 : .alive
Barry Personally, I'd go with a property .is_alive
I'm not fond of using a
On 2008-06-12 16:59, Walter Dörwald wrote:
M.-A. Lemburg wrote:
.transform() and .untransform() use the codecs to apply same-type
conversions. They do apply type checks to make sure that the
codec does indeed return the same type.
E.g. text.transform('xml-escape') or data.transform('base64').
I haven't been following this thread very closely, so I'm not sure
what the status is, but I'd just like to point out that yesterday I
used the fact that a[None] = b works, when I used the @memoize
decorator from the wiki. This seems to provide an argument that, for
symmetry's sake, we might want
On Thu, Jun 12, 2008 at 10:13 AM, Leif Walsh [EMAIL PROTECTED] wrote:
I haven't been following this thread very closely, so I'm not sure
what the status is, but I'd just like to point out that yesterday I
used the fact that a[None] = b works, when I used the @memoize
decorator from the wiki.
On Thu, Jun 12, 2008 at 10:28 AM, Guido van Rossum [EMAIL PROTECTED] wrote:
That makes about as much sense as wanting to support a.42 = b since
a[42] = b works. :-)
Well don't I feel silly now.
--
Cheers,
Leif
___
Python-Dev mailing list
On 6/12/08, Nick Coghlan [EMAIL PROTECTED] wrote:
documentation patch for the language reference ...
following categories:
...
2. Method lookup MAY bypass __getattribute__, shadowing the attribute in
the instance dictionary MAY have ill effects. (slots such as __enter__ and
__exit__ that
Phillip J. Eby [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
| At 08:32 PM 6/11/2008 -0400, Terry Reedy wrote:
| The Data Model chapter of the Reference Manual lists .__dict__ as a
special
| attribute of callables, modules, classes, and instances. It describes
| __dict__ as a
On Thu, Jun 12, 2008 at 8:24 AM, Armin Rigo [EMAIL PROTECTED] wrote:
This discussion is mistakenly focused on locals(). There is a direct
way to have arbitrary keys in the dict of a type:
MyClass = type('MyClass', (Base,), {42: 64})
MyClass.__dict__[42]
64
There is, however, no way to
On Thu, Jun 12, 2008 at 9:46 PM, Guido van Rossum [EMAIL PROTECTED] wrote:
The intention was for these dicts to be used as namespaces. I think of
it as follows:
(a) Using non-string keys is a no-no, but the implementation isn't
required to go out of its way to forbid it.
That will allow
At 12:46 PM 6/12/2008 -0700, Guido van Rossum wrote:
The intention was for these dicts to be used as namespaces.
By these do you mean type object __dict__ attributes, or *all*
__dict__ attributes?
___
Python-Dev mailing list
Python-Dev@python.org
On Thu, Jun 12, 2008 at 1:01 PM, Willem Broekema [EMAIL PROTECTED] wrote:
On Thu, Jun 12, 2008 at 9:46 PM, Guido van Rossum [EMAIL PROTECTED] wrote:
The intention was for these dicts to be used as namespaces. I think of
it as follows:
(a) Using non-string keys is a no-no, but the
On Thu, Jun 12, 2008 at 2:42 PM, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 12:46 PM 6/12/2008 -0700, Guido van Rossum wrote:
The intention was for these dicts to be used as namespaces.
By these do you mean type object __dict__ attributes, or *all* __dict__
attributes?
Hadn't thought of
On Wed, Jun 11, 2008 at 4:25 PM, Daniel Bonekeeper [EMAIL PROTECTED]
wrote:
Hi everybody on the list !
Sorry about the off-topic message, but giving the nature of the
message and the nature of the list (after all, everybody here uses
Internet or develops for web in some way), I decided to
On Wed, Jun 11, 2008 at 5:27 PM, Curt Hagenlocher [EMAIL PROTECTED] wrote:
If I recall correctly, Jython handles this by appending a trailing
underscore to the imported name and there's no reason why we couldn't
do something similar.
In truth the current implementation of Jython allows keywords
On Thu, Jun 12, 2008 at 8:06 PM, Frank Wierzbicki [EMAIL PROTECTED] wrote:
On Wed, Jun 11, 2008 at 5:27 PM, Curt Hagenlocher [EMAIL PROTECTED] wrote:
If I recall correctly, Jython handles this by appending a trailing
underscore to the imported name and there's no reason why we couldn't
do
On Wed, Jun 11, 2008 at 5:50 AM, Nick Coghlan [EMAIL PROTECTED] wrote:
Greg Ewing wrote:
Implementations are also permitted to restrict namespace dictionaries to
only accept string keys (I believe Jython does this for performance reasons
- CPython just optimised the hell out of normal
My colleague and SVN developer Ben Sussman-Collins occasionally blogs
about the social side of (mostly open source) software development. He
just posted a new one that struck a chord:
http://blog.red-bean.com/sussman/?p=96
The story's main moral: submit your code for review early and often;
work
On Thu, Jun 12, 2008 at 8:19 PM, Frank Wierzbicki [EMAIL PROTECTED] wrote:
On Wed, Jun 11, 2008 at 5:50 AM, Nick Coghlan [EMAIL PROTECTED] wrote:
Greg Ewing wrote:
Implementations are also permitted to restrict namespace dictionaries to
only accept string keys (I believe Jython does this for
On Thu, Jun 12, 2008 at 8:41 PM, Guido van Rossum [EMAIL PROTECTED] wrote:
My colleague and SVN developer Ben Sussman-Collins occasionally blogs
about the social side of (mostly open source) software development. He
just posted a new one that struck a chord:
It's water under the bridge now, but IMO it was too rash to *remove*
the old threading API from Py3k, and doubly rash to do so one day
before the beta release. Running up to a release (whether alpha, beta
or final) we should practice extra restraint, not rush to get things
in right before the
On Thu, Jun 12, 2008 at 8:49 PM, Neal Norwitz [EMAIL PROTECTED] wrote:
On Thu, Jun 12, 2008 at 8:41 PM, Guido van Rossum [EMAIL PROTECTED] wrote:
My colleague and SVN developer Ben Sussman-Collins occasionally blogs
about the social side of (mostly open source) software development. He
just
49 matches
Mail list logo
