On Sun, Jun 15, 2008 at 3:49 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Georg Brandl wrote:
>>
>> Nick Coghlan schrieb:
>>>
>>> This has become a lot more complicated than what I thought we were doing:
>>> adding PEP 8 compliant aliases for the existing methods without otherwise
>>> changing the
Georg Brandl wrote:
Nick Coghlan schrieb:
This has become a lot more complicated than what I thought we were
doing: adding PEP 8 compliant aliases for the existing methods without
otherwise changing the threading implementation. As far as I can
recall, that is all that was contained in the 2.x
Nick Coghlan schrieb:
Benjamin Peterson wrote:
On Fri, Jun 13, 2008 at 12:14 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
On Fri, Jun 13, 2008 at 9:42 AM, Benjamin Peterson
<[EMAIL PROTECTED]> wrote:
On Fri, Jun 13, 2008 at 11:40 AM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
Nick>
Benjamin Peterson wrote:
On Fri, Jun 13, 2008 at 12:14 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
On Fri, Jun 13, 2008 at 9:42 AM, Benjamin Peterson
<[EMAIL PROTECTED]> wrote:
On Fri, Jun 13, 2008 at 11:40 AM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
Nick> def getName(self):
On Fri, Jun 13, 2008 at 12:14 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On Fri, Jun 13, 2008 at 9:42 AM, Benjamin Peterson
> <[EMAIL PROTECTED]> wrote:
>> On Fri, Jun 13, 2008 at 11:40 AM, Raymond Hettinger <[EMAIL PROTECTED]>
>> wrote:
Nick> def getName(self):
Nick>
On Fri, Jun 13, 2008 at 9:42 AM, Benjamin Peterson
<[EMAIL PROTECTED]> wrote:
> On Fri, Jun 13, 2008 at 11:40 AM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
>>> Nick> def getName(self):
>>> Nick> assert self.__initialized, "Thread.__init__() not called"
>>> Nick> retu
On Thu, Jun 12, 2008 at 8:40 AM, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> Ideally, I would like for those considerations [i.e. whether an access is
> expensive]
> to not enter into the API
> design. I'd rather keep it clean, with sufficient documentation to give
> hints about any additional cost
On Fri, Jun 13, 2008 at 11:40 AM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
>> Nick> def getName(self):
>> Nick> assert self.__initialized, "Thread.__init__() not called"
>> Nick> return self.__name
>
> Why is __name private to begin with? Any reason for the getters
Nick> def getName(self):
Nick> assert self.__initialized, "Thread.__init__() not called"
Nick> return self.__name
Why is __name private to begin with? Any reason for the getters and setters?
Why isn't this just an attribute?
Raymond
__
Nick> Have you looked at what the methods we're proposing to turn into
Nick> properties are actually doing?:
Nick> def getName(self):
Nick> assert self.__initialized, "Thread.__init__() not called"
Nick> return self.__name
...
Nick> Checking whet
[EMAIL PROTECTED] wrote:
I'm not fond of using a property for this since it can lull you into the
false belief that what you are doing is less expensive than it really is
(attribute access vs method call). I think this is a case where explicit is
better than implicit.
Have you looked at what t
-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 prope
>> 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
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 in
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jun 12, 2008, at 8:29 AM, Facundo Batista wrote:
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 o
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.
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
-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
ever
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
everyw
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
> everywhere. Can some of
"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 everywhere.
Can some of these be shortened?
function:: active_count()
method:: Thread.get_name()
m
21 matches
Mail list logo
