[Mr. Lawrence spaketh:]
> Do we really have to feed this guy, he's worse than the RUE?
While it may seem like an impossible goal, is it unworthy? Is there something
*better* for high-level, interpreted languages to be good for?
The truth is, that all the theory is worked out, as well as the hea
Op 13-05-15 om 02:19 schreef Gregory Ewing:
> Antoon Pardon wrote:
>> But that doesn't answer the question why the developers chose "True"
>> to be a
>> keyword and "int" to be a looked-up name.
>
> Probably because True, False and None are very frequently
> used constants.
I don't care about the
Op 12-05-15 om 15:56 schreef Steven D'Aprano:
> On Tue, 12 May 2015 09:55 pm, Antoon Pardon wrote:
>
>> Op 11-05-15 om 16:13 schreef Chris Angelico:
>>
>>> Why does Python have most built-ins as simply looked-up names that can
>>> be overridden? Because otherwise, there would be a veritable ton of
On Wednesday 13 May 2015 02:22, Skip Montanaro wrote:
> I did find this interesting blog post about encapsulation and
> test-driven development:
>
> https://jasonmbaker.wordpress.com/2009/01/08/enemies-of-test-driven-
development-part-i-encapsulation/
>
> I found the author's perspective interes
On Tuesday, May 12, 2015 at 10:43:44 AM UTC-5, Chris Angelico wrote:
> On Wed, May 13, 2015 at 1:34 AM, zipher wrote:
> > Name one "significant and important" use case for shadowing built-in types.
> > Functions, I don't have a problem with, but types are more fundamental
> > than functions.
>
On Wednesday, May 13, 2015 at 7:47:03 AM UTC+5:30, Paul Rubin wrote:
> Rustom Mody writes:
> > You made TRUE into FALSE!!
>
> The answer is: yes! Haskell can do that.
>
>Prelude> let 2+2=5 in 2+2
>5
:-)
And we come back to the OP.
It *looks* like this is some profound question about O
Rustom Mody writes:
> You made TRUE into FALSE!!
The answer is: yes! Haskell can do that.
Prelude> let 2+2=5 in 2+2
5
--
https://mail.python.org/mailman/listinfo/python-list
On Wednesday, May 13, 2015 at 6:17:41 AM UTC+5:30, John Ladasky wrote:
> On Monday, May 11, 2015 at 3:16:16 AM UTC-7, Antoon Pardon wrote:
>
> > Try overriding None, True or False in python3 and see what happens.
>
> Much fun was able to be had in Python 2, though:
>
> Python 2.7.6 (default,
On Monday, May 11, 2015 at 3:16:16 AM UTC-7, Antoon Pardon wrote:
> Try overriding None, True or False in python3 and see what happens.
Much fun was able to be had in Python 2, though:
Python 2.7.6 (default, Mar 22 2014, 22:59:56)
[GCC 4.8.2] on linux2
Type "help", "copyright", "cre
Antoon Pardon wrote:
But that doesn't answer the question why the developers chose "True" to be a
keyword and "int" to be a looked-up name.
Probably because True, False and None are very frequently
used constants. Making them keywords means that things
like 'while True:' don't incur the overhea
On 5/12/2015 9:56 AM, Steven D'Aprano wrote:
The consensus among the core developers is:
* in general, the harm and inconvenience from accidentally
shadowing built-ins is not great, and it usually easy to
spot, debug and prevent;
* when it comes to built-in functions (e.g. sum, map, pow)
On Tue, May 12, 2015 at 9:34 AM, zipher wrote:
>> * when it comes to built-in functions (e.g. sum, map, pow)
>> and types (e.g. int, str, list) there are significant and
>> important use-cases for allowing shadowing;
>
> Name one "significant and important" use case for shadowing built-in type
On Tue, May 12, 2015 at 10:34 AM, zipher wrote:
>> The general principle here is of consenting adults: Python allows you to
>> shadow built-ins because sometimes it is useful, and the good outweighs the
>> potential harm.
>
> I think you'll have to give examples, either from the developer communit
On 12/05/2015 16:43, Chris Angelico wrote:
On Wed, May 13, 2015 at 1:34 AM, zipher wrote:
On Tuesday, May 12, 2015 at 8:56:32 AM UTC-5, Steven D'Aprano wrote:
* when it comes to built-in functions (e.g. sum, map, pow)
and types (e.g. int, str, list) there are significant and
important us
On 05/12/2015 04:55 AM, Antoon Pardon wrote:
Op 11-05-15 om 16:13 schreef Chris Angelico:
Why does Python have most built-ins as simply looked-up names that can
be overridden? Because otherwise, there would be a veritable ton of
keywords:
But that doesn't answer the question why the developers
On Wed, May 13, 2015 at 1:34 AM, zipher wrote:
> On Tuesday, May 12, 2015 at 8:56:32 AM UTC-5, Steven D'Aprano wrote:
>> * when it comes to built-in functions (e.g. sum, map, pow)
>> and types (e.g. int, str, list) there are significant and
>> important use-cases for allowing shadowing;
>
> Na
On 2015-05-12, alex23 wrote:
> On 12/05/2015 1:39 AM, zipher wrote:
>> On Monday, May 11, 2015 at 10:34:24 AM UTC-5, Grant Edwards wrote:
>>> That Python, like COBOL, is an eminently practical language.
>>
>> LOL! Good one.
>
> I would make an incredibly substantial wager that you've never develo
On Tuesday, May 12, 2015 at 8:56:32 AM UTC-5, Steven D'Aprano wrote:
> The consensus among the core developers is:
> * in general, the harm and inconvenience from accidentally
> shadowing built-ins is not great, and it usually easy to
> spot, debug and prevent;
Where is that the consensus? Pl
On Tue, 12 May 2015 09:55 pm, Antoon Pardon wrote:
> Op 11-05-15 om 16:13 schreef Chris Angelico:
>
>> Why does Python have most built-ins as simply looked-up names that can
>> be overridden? Because otherwise, there would be a veritable ton of
>> keywords:
>
> But that doesn't answer the questi
Op 11-05-15 om 17:44 schreef Steven D'Aprano:
> On Mon, 11 May 2015 11:27 pm, Antoon Pardon wrote:
>
>> The point is that all too often someone wants to defend a specific choice
>> the developers have made and cites some general rule or principle in
>> support, ignoring the fact that python breaks
On 12/05/2015 06:02, alex23 wrote:
On 12/05/2015 1:39 AM, zipher wrote:
On Monday, May 11, 2015 at 10:34:24 AM UTC-5, Grant Edwards wrote:
That Python, like COBOL, is an eminently practical language.
LOL! Good one.
I would make an incredibly substantial wager that you've never developed
an
Op 11-05-15 om 16:13 schreef Chris Angelico:
> Why does Python have most built-ins as simply looked-up names that can
> be overridden? Because otherwise, there would be a veritable ton of
> keywords:
But that doesn't answer the question why the developers chose "True" to be a
keyword and "int" to
Op 11-05-15 om 16:03 schreef Marko Rauhamaa:
> Antoon Pardon :
>
>> The point is that all too often someone wants to defend a specific
>> choice the developers have made and cites some general rule or
>> principle in support, ignoring the fact that python breaks that
>> rule/principle in other are
Steven D'Aprano wrote:
With programming languages, the designer can take the same route as Pascal
or Java, and define standard functions as keywords that cannot be shadowed
or redefined.
Nit: Pascal's standard types and functions are not reserved
words, they're predeclared identifiers, much as
On 12/05/2015 1:39 AM, zipher wrote:
On Monday, May 11, 2015 at 10:34:24 AM UTC-5, Grant Edwards wrote:
That Python, like COBOL, is an eminently practical language.
LOL! Good one.
I would make an incredibly substantial wager that you've never developed
anything of note in either Python or
On Tue, 12 May 2015 06:48 am, Mel Wilson wrote:
> On Tue, 12 May 2015 02:35:23 +1000, Steven D'Aprano wrote:
>
>> On Mon, 11 May 2015 11:37 pm, Mel Wilson wrote:
>>
>>> On Sun, 10 May 2015 14:12:44 -0500, boB Stepp wrote:
>>>
I have to admit being surprised by this, too. I am just now stud
On Tue, 12 May 2015 02:43 am, zipher wrote:
> For example, have you ever contemplated this:
>
> class WeightedVertex(vertex_common(Vertex(dict))):
> """test class"""
No.
> That currently isn't valid Python code,
Yes it is. You just have to arrange matters so that
vertex_common(Vertex(dict))
On 5/11/2015 8:34 AM, Grant Edwards wrote:
> Yow! YOU PICKED KARL
> MALDEN'S NOSE!!
I'd bet most people familiar with Karl Malden wouldn't have a
problem picking his from a selection of twenty random noses. :)
Emile
--
https://mail.python.org/mailman/listinfo/python-list
On Tue, 12 May 2015 02:35:23 +1000, Steven D'Aprano wrote:
> On Mon, 11 May 2015 11:37 pm, Mel Wilson wrote:
>
>> On Sun, 10 May 2015 14:12:44 -0500, boB Stepp wrote:
>>
>>> I have to admit being surprised by this, too. I am just now studying
>>> on how to write my own classes in Python, and hav
On Monday, May 11, 2015 at 10:49:01 AM UTC-5, Skip Montanaro wrote:
> On Mon, May 11, 2015 at 10:11 AM, zipher wrote:
> > I also bought the idea of everything as an object, it has a unbeatable
> > purity to it. But we won't ever get to the point were OOP is like the
> > purity of math because t
On Mon, 11 May 2015 11:37 pm, Mel Wilson wrote:
> On Sun, 10 May 2015 14:12:44 -0500, boB Stepp wrote:
>
>> I have to admit being surprised by this, too. I am just now studying on
>> how to write my own classes in Python, and have come to realize that
>> doing this is *possible*, but the *surpris
On Monday, May 11, 2015 at 10:44:51 AM UTC-5, Steven D'Aprano wrote:
> On Mon, 11 May 2015 11:27 pm, Antoon Pardon wrote:
>
> > The point is that all too often someone wants to defend a specific choice
> > the developers have made and cites some general rule or principle in
> > support, ignoring t
On 11/05/2015 16:48, Skip Montanaro wrote:
On Mon, May 11, 2015 at 10:11 AM, zipher wrote:
I also bought the idea of everything as an object, it has a unbeatable purity
to it. But we won't ever get to the point were OOP is like the purity of math
because the greatest utility of OOP is workin
On Tue, 12 May 2015 12:23 am, zipher wrote:
> On Monday, May 11, 2015 at 1:11:26 AM UTC-5, Steven D'Aprano wrote:
>> On Monday 11 May 2015 10:57, zipher wrote:
>> > I guess everyone expects this behavior since Python implemented this
>> > idea of "everything is an object", but I think this branch
On Mon, May 11, 2015 at 10:11 AM, zipher wrote:
> I also bought the idea of everything as an object, it has a unbeatable purity
> to it. But we won't ever get to the point were OOP is like the purity of
> math because the greatest utility of OOP is working with real-world data.
> And that rea
On Mon, 11 May 2015 11:27 pm, Antoon Pardon wrote:
> The point is that all too often someone wants to defend a specific choice
> the developers have made and cites some general rule or principle in
> support, ignoring the fact that python breaks that rule/principle in other
> area's.
"It's a fre
On Monday, May 11, 2015 at 10:34:24 AM UTC-5, Grant Edwards wrote:
> On 2015-05-11, Skip Montanaro wrote:
> >> Python is in production use in hundreds of thousands of
> >> organisations. It has been heavily used for over twenty years, in
> >> everything from quick and dirty one line scripts to hun
On 2015-05-11, Skip Montanaro wrote:
>> Python is in production use in hundreds of thousands of
>> organisations. It has been heavily used for over twenty years, in
>> everything from quick and dirty one line scripts to hundred-thousand
>> LOC applications.
>
> Mark> Yeah, so was COBOL. Boom.
>
On Monday, May 11, 2015 at 9:52:16 AM UTC-5, Skip Montanaro wrote:
> Steven> Python is in production use in hundreds of thousands of
> organisations. It
> Steven> has been heavily used for over twenty years, in everything
> from quick and
> Steven> dirty one line scripts to hundred-thousand LOC app
On Monday, May 11, 2015 at 9:03:43 AM UTC-5, Marko Rauhamaa wrote:
> Antoon Pardon :
>
> > The point is that all too often someone wants to defend a specific
> > choice the developers have made and cites some general rule or
> > principle in support, ignoring the fact that python breaks that
> > r
Further posts on this thread should delete pydev-list or
gmane.comp.python.devel. It was a mistake by the troll to ever post
this there.
--
Terry Jan Reedy
--
https://mail.python.org/mailman/listinfo/python-list
Steven> Python is in production use in hundreds of thousands of
organisations. It
Steven> has been heavily used for over twenty years, in everything
from quick and
Steven> dirty one line scripts to hundred-thousand LOC applications.
Mark> Yeah, so was COBOL. Boom.
Your point being?
The software
On Monday, May 11, 2015 at 1:11:26 AM UTC-5, Steven D'Aprano wrote:
> On Monday 11 May 2015 10:57, zipher wrote:
> > I guess everyone expects this behavior since Python implemented this idea
> > of "everything is an object", but I think this branch of OOP (on the
> > branch of the Tree of Programm
On Mon, May 11, 2015 at 11:38 PM, Antoon Pardon
wrote:
> "We allow buitins to be overridden", doesn't sound as a very accurate
> description of the underlining reason, when you know that things have
> been removed from builtins and made a keyword in order to prevent them
> from being overridden.
Antoon Pardon :
> The point is that all too often someone wants to defend a specific
> choice the developers have made and cites some general rule or
> principle in support, ignoring the fact that python breaks that
> rule/principle in other area's.
Granted, but you have set the trap for them by
On Sun, 10 May 2015 14:12:44 -0500, boB Stepp wrote:
> I have to admit being surprised by this, too. I am just now studying on
> how to write my own classes in Python, and have come to realize that
> doing this is *possible*, but the *surprise* to me is why the language
> design allowed this to ac
Op 11-05-15 om 14:34 schreef Steven D'Aprano:
> On Mon, 11 May 2015 09:39 pm, Antoon Pardon wrote:
>
>> There is no
>> a priori reason why we should turn "True" into a keyword and allow
>> "int" in the builtins.
> Why should there be an *a priori* reason?
I don't say there should be an *a priori*
Op 11-05-15 om 13:58 schreef Marko Rauhamaa:
> Antoon Pardon :
>
>> Which is exactly the point! They were turned into keywords because the
>> developers didn't want to allow them being overridden. There is no a
>> priori reason why we should turn "True" into a keyword and allow "int"
>> in the buil
On Mon, May 11, 2015 at 2:40 AM, Mark Lawrence wrote:
> On 10/05/2015 20:12, boB Stepp wrote:
>> I'm surprised that this thought has not been added to the "Zen Of
>> Python", as I see it as more and more recurrent as I continue my
>> studies. What I would like to comprehend is what is the essenti
On Mon, May 11, 2015 at 2:44 AM, Chris Angelico wrote:
> On Mon, May 11, 2015 at 5:12 AM, boB Stepp wrote:
>>> Common Python thought:: "We're all adults here."If you want to override
>>> a builtin within your own namespace, who are we to stop you?
>>
>> I'm surprised that this thought has no
On Mon, 11 May 2015 09:39 pm, Antoon Pardon wrote:
> There is no
> a priori reason why we should turn "True" into a keyword and allow
> "int" in the builtins.
Why should there be an *a priori* reason?
There's no a priori reason why I speak English, instead of communicating
through the medium of
On 11/05/2015 02:18, zipher wrote:
Huh? Python has plenty of keywords, and indeed, none of them can be
redefined or shadowed.But you would gain nothing (and lose a bit or
dynamic-language freedom) by making int a keyword.
Okay. I apologize for thinking in C and believing "int" was a keyw
Antoon Pardon :
> Which is exactly the point! They were turned into keywords because the
> developers didn't want to allow them being overridden. There is no a
> priori reason why we should turn "True" into a keyword and allow "int"
> in the builtins.
>
> We are only allowed to be adults, for as f
On 11/05/2015 12:39, Antoon Pardon wrote:
Op 11-05-15 om 12:40 schreef Mark Lawrence:
On 11/05/2015 11:15, Antoon Pardon wrote:
Op 10-05-15 om 19:28 schreef Gary Herron:
Common Python thought:: "We're all adults here."If you want to
override a builtin within your own namespace, who are w
Op 11-05-15 om 12:40 schreef Mark Lawrence:
> On 11/05/2015 11:15, Antoon Pardon wrote:
>> Op 10-05-15 om 19:28 schreef Gary Herron:
>>
>>> Common Python thought:: "We're all adults here."If you want to
>>> override a builtin within your own namespace, who are we to stop you?
>>> Besides, it's
On 11/05/2015 11:15, Antoon Pardon wrote:
Op 10-05-15 om 19:28 schreef Gary Herron:
Common Python thought:: "We're all adults here."If you want to
override a builtin within your own namespace, who are we to stop you?
Besides, it's still available as __builtins__.int (unless you've also
ov
Op 10-05-15 om 19:28 schreef Gary Herron:
> Common Python thought:: "We're all adults here."If you want to
> override a builtin within your own namespace, who are we to stop you?
> Besides, it's still available as __builtins__.int (unless you've also
> overridden that).
This is a common p
On Mon, May 11, 2015 at 5:12 AM, boB Stepp wrote:
>> Common Python thought:: "We're all adults here."If you want to override
>> a builtin within your own namespace, who are we to stop you?
>
> I'm surprised that this thought has not been added to the "Zen Of
> Python", as I see it as more and
On 10/05/2015 20:12, boB Stepp wrote:
On Sun, May 10, 2015 at 12:28 PM, Gary Herron wrote:
Common Python thought:: "We're all adults here."If you want to override
a builtin within your own namespace, who are we to stop you?
I'm surprised that this thought has not been added to the "Zen
I am in process learning Python and normally hang out on the Tutor
list, but monitor this one hoping to learn what I can. This thread is
of interest to me from the standpoint of trying to understand the
Python way of doing things.
On Sun, May 10, 2015 at 12:28 PM, Gary Herron wrote:
> On 05/10/20
On Monday, May 11, 2015 at 2:58:09 AM UTC+2, zipher wrote:
> I guess everyone expects this behavior since Python implemented this idea of
> "everything is an object", but I think this branch of OOP (on the branch of
> the Tree of Programming Languages) has to be chopped off. The idea of
> every
On Monday 11 May 2015 10:14, Mark Rosenblitt-Janssen wrote:
> In case the example given at the start of the thread wasn't
> interesting enough, it also works in the other direction:
>
class str(int): pass
>
str('2')
> 2 #<- an integer!!!
Thank the gods that you're around to poi
On Monday 11 May 2015 10:57, zipher wrote:
> I guess everyone expects this behavior since Python implemented this idea
> of "everything is an object", but I think this branch of OOP (on the
> branch of the Tree of Programming Languages) has to be chopped off. The
> idea of everything is an object
On Mon, 11 May 2015 03:28 am, Gary Herron wrote:
> On 05/10/2015 09:48 AM, Rustom Mody wrote:
>> On Sunday, May 10, 2015 at 10:14:36 PM UTC+5:30, Ian wrote:
>>> On Sun, May 10, 2015 at 10:34 AM, Mark Rosenblitt-Janssen wrote:
Here's something that might be wrong in Python (tried on v2.7):
>>>
On Mon, May 11, 2015 at 12:12 PM, Rustom Mody wrote:
> On Monday, May 11, 2015 at 7:23:44 AM UTC+5:30, Chris Angelico wrote:
>> And I still don't see how this has anything to do with your confusion
>> about shadowing the name 'int'.
>
> Speaking as a compiler-writer -- everything :-)
>
> In C 'int
On Monday, May 11, 2015 at 7:23:44 AM UTC+5:30, Chris Angelico wrote:
> And I still don't see how this has anything to do with your confusion
> about shadowing the name 'int'.
Speaking as a compiler-writer -- everything :-)
In C 'int' is tagged off as different from 'myvar' earlier than say
'myva
> > Okay. I apologize for thinking in C and believing "int" was a keyword. It
> > isn't in Python as you remind me. However, this is where I'm arguing the
> > purity has hammered practicality into the ground.
> >
> > Python is trying to be as elegant as LISP in trying to make everything an
>
On Mon, May 11, 2015 at 11:18 AM, zipher wrote:
> Okay. I apologize for thinking in C and believing "int" was a keyword. It
> isn't in Python as you remind me. However, this is where I'm arguing the
> purity has hammered practicality into the ground.
>
> Python is trying to be as elegant as L
> Huh? Python has plenty of keywords, and indeed, none of them can be
> redefined or shadowed.But you would gain nothing (and lose a bit or
> dynamic-language freedom) by making int a keyword.
Okay. I apologize for thinking in C and believing "int" was a keyword. It
isn't in Python as y
On 05/10/2015 05:48 PM, zipher wrote:
On Sunday, May 10, 2015 at 11:44:36 AM UTC-5, Ian wrote:
On Sun, May 10, 2015 at 10:34 AM, Mark Rosenblitt-Janssen
wrote:
Here's something that might be wrong in Python (tried on v2.7):
class int(str): pass
This defines a new class named "int" that is a
On Sunday, May 10, 2015 at 7:20:13 PM UTC-5, Mark Lawrence wrote:
> On 11/05/2015 01:14, Mark Rosenblitt-Janssen wrote:
> > In case the example given at the start of the thread wasn't
> > interesting enough, it also works in the other direction:
> >
> class str(int): pass
> >
> str('2')
On Sunday, May 10, 2015 at 11:44:36 AM UTC-5, Ian wrote:
> On Sun, May 10, 2015 at 10:34 AM, Mark Rosenblitt-Janssen
> wrote:
> > Here's something that might be wrong in Python (tried on v2.7):
> >
> class int(str): pass
>
> This defines a new class named "int" that is a subclass of str. It
On 11/05/2015 01:14, Mark Rosenblitt-Janssen wrote:
In case the example given at the start of the thread wasn't
interesting enough, it also works in the other direction:
class str(int): pass
str('2')
2 #<- an integer!!!
Mark
Thanks for this, I've not found anybody new for my dream
In case the example given at the start of the thread wasn't
interesting enough, it also works in the other direction:
>>> class str(int): pass
>>> str('2')
2 #<- an integer!!!
Mark
--
https://mail.python.org/mailman/listinfo/python-list
On 10/05/2015 23:59, Mark Rosenblitt-Janssen wrote:
On 5/10/15, Mark Rosenblitt-Janssen wrote:
Here's something that might be wrong in Python (tried on v2.7):
class int(str): pass
int(3)
'3'
Mark
Here's where this exploration came from. I've (once again) been
contemplating the OO natu
Along those lines, it makes no sense for mix-in classes to inherit
from Object at all -- they're neither expanding on object nor
specializing it.
For example, I'm refactoring my python Graph class so that people can
have different Vertex behaviors by using different composition of
mix-in classes.
Here's where this exploration came from. I've (once again) been
contemplating the OO nature.
It's clear to me that there needs to be a distinction between
specialization of an object vs. expansion of an object (a new term I'm
proposing to the OOP lexicon). The latter *adds* more functionality
(l
On 05/10/2015 09:48 AM, Rustom Mody wrote:
On Sunday, May 10, 2015 at 10:14:36 PM UTC+5:30, Ian wrote:
On Sun, May 10, 2015 at 10:34 AM, Mark Rosenblitt-Janssen wrote:
Here's something that might be wrong in Python (tried on v2.7):
class int(str): pass
This defines a new class named "int" th
On 10/05/2015 17:48, Rustom Mody wrote:
On Sunday, May 10, 2015 at 10:14:36 PM UTC+5:30, Ian wrote:
On Sun, May 10, 2015 at 10:34 AM, Mark Rosenblitt-Janssen wrote:
Here's something that might be wrong in Python (tried on v2.7):
class int(str): pass
This defines a new class named "int" that
On 5/10/2015 12:34 PM, Mark Rosenblitt-Janssen wrote:
Here's something that might be wrong in Python (tried on v2.7):
You are being hypnotized by the fact the 'int' is a builtin name.
Builtin names are not keywords and can intentionally be rebound. If you
rebind randomly, the result may seem
On Sunday, May 10, 2015 at 10:14:36 PM UTC+5:30, Ian wrote:
> On Sun, May 10, 2015 at 10:34 AM, Mark Rosenblitt-Janssen wrote:
> > Here's something that might be wrong in Python (tried on v2.7):
> >
> class int(str): pass
>
> This defines a new class named "int" that is a subclass of str. It
On Sun, May 10, 2015 at 10:34 AM, Mark Rosenblitt-Janssen
wrote:
> Here's something that might be wrong in Python (tried on v2.7):
>
class int(str): pass
This defines a new class named "int" that is a subclass of str. It has
no relation to the builtin class int.
int(3)
> '3'
This crea
On Mar 22, 10:03 pm, Tim Roberts <[EMAIL PROTECTED]> wrote:
> Godzilla <[EMAIL PROTECTED]> wrote:
>
> >Just found out that win32api.GetTickCount() returns a tick count in
> >milli-second since XP started. Not sure whether that is reliable.
> >Anyone uses that for calculating elapsed time?
>
> What
Godzilla <[EMAIL PROTECTED]> wrote:
>
>Just found out that win32api.GetTickCount() returns a tick count in
>milli-second since XP started. Not sure whether that is reliable.
>Anyone uses that for calculating elapsed time?
What do you mean by "reliable"? The tick count is updated as part of
schedu
On 21 mar, 03:13, Godzilla <[EMAIL PROTECTED]> wrote:
> Just found out that win32api.GetTickCount() returns a tick count in
> milli-second since XP started. Not sure whether that is reliable.
> Anyone uses that for calculating elapsed time?
I use GetTickCount on other languages because it's easy
On 20 mar, 08:47, Godzilla <[EMAIL PROTECTED]> wrote:
> Thanks Ross and John for your help. I apologise for the code I posted
> earlier not being the full picture of what I was trying to achieve. I
> had instantiated multiple instances of elapseTime class and each of
> them gets called approximate
Just found out that win32api.GetTickCount() returns a tick count in
milli-second since XP started. Not sure whether that is reliable.
Anyone uses that for calculating elapsed time?
--
http://mail.python.org/mailman/listinfo/python-list
Thanks Ross and John for your help. I apologise for the code I posted
earlier not being the full picture of what I was trying to achieve. I
had instantiated multiple instances of elapseTime class and each of
them gets called approximately the same time. Below is the updated
code:
import time
impo
On Mar 19, 11:17 pm, Godzilla <[EMAIL PROTECTED]> wrote:
> Hi John,
>
> I am using time.clock to calculate the elapsed time. Below is an
> example of what I was trying to do:
>
> import time
> import thread
Silly me, not being able to infer that from your initial post!
[snip]
>
> But the time.clo
Godzilla <[EMAIL PROTECTED]> wrote:
>But the time.clock() sometimes return a value of between -3.5 to -4.5
>seconds backward.
There are race conditions in your code. In between the time you execute
"curTime = time.clock()" and calculate "curTime - self.timeStamp" in one
thread, the other thread
Hi John,
I am using time.clock to calculate the elapsed time. Below is an
example of what I was trying to do:
import time
import thread
class elapseTime:
def __init__(self, name=''):
self.name = name
self.timeStamp = None
self.checkTimeFlag = False
thread.start_new_t
On Mar 18, 9:43 pm, Godzilla <[EMAIL PROTECTED]> wrote:
> Thanks Roel. If there is a way to pass in the PRESERVE_PRECISION
> constant in the python time.clock library, that would be great
Re-read Roel's message. Something like PRESERVE_PRECISION is to be
passed to whatever is setting up DirectX.
Thanks Roel. If there is a way to pass in the PRESERVE_PRECISION
constant in the python time.clock library, that would be great. But
I'm afraid it's not possible. I think I will change away from using
time.clock() from now on... seems too edgy to me.
Thank you for sharing your experience with me n
Godzilla schreef:
> Hello,
>
> I have been reading a thread about time.clock() going backward, which
> is exactly what I am seeing... the thread generally leaning toward the
> problem is caused by multi-processor machines. But I am seeing it at a
> single CPU computer, and running XP.
>
> The err
venk <[EMAIL PROTECTED]> wrote:
> Cool,
> i got it now... accessing thru attribute reference always
> returns a bound or unbound method... so, D.f is an unbound method
Right. Specifically, accessing through a (newstyle) class or instance
always calls the __get__ method of a descriptor [
Cool,
i got it now... accessing thru attribute reference always
returns a bound or unbound method... so, D.f is an unbound method
whereas i want the "function" of the unbound method... ok, this
example and the nice explanations definitively thought me about
function, bound method (for
venk <[EMAIL PROTECTED]> wrote:
> Hi,
> given below is my interaction with the interpreter In one case, i
> have created the class method using the "famous idiom"... and in the
> other, i have tried to create it outside the class definition... why
> isn't the latter working ? (of course, the
On 3 Nov 2005 03:19:22 -0800, "venk" <[EMAIL PROTECTED]> wrote:
>Hi,
> given below is my interaction with the interpreter In one case, i
>have created the class method using the "famous idiom"... and in the
>other, i have tried to create it outside the class definition... why
>isn't the latter
98 matches
Mail list logo
