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 def
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
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 threading
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):
Nick
[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
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 whether or
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
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 and
setters?
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 costs
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 return self.__name
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 assert
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
-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
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
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 :
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
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
-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
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()
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 these be
20 matches
Mail list logo
