In article ,
Steve Holden wrote:
>Terry Reedy wrote:
>> On 4/1/2010 6:34 PM, kj wrote:
>>>
>>>
>>> When coding C I have often found static local variables useful for
>>> doing once-only run-time initializations. For example:
>>>
>>> int foo(int x, int y, int z) {
>>>
>>>static int first_time
On Apr 5, 6:50 pm, Ethan Furman wrote:
(Posted some code with a timeit...)
Well, I'm not going to debug this, but with the *original* thing you
posted, and the thing I posted, with a call and everything (more
realistic scenario), the exception version seems slower on my machine:
#!/usr/bin/env
Ethan Furman wrote:
Steven D'Aprano wrote:
On Fri, 02 Apr 2010 19:48:59 -0700, Ethan Furman wrote:
The heuristic I use is, if I expect the try block to raise an exception
more than about one time in ten, I change to an explicit test. In this
case, since the exception should only be raised onc
> Another approach would be to stuff the static values in the function's
> __dict__.
That's how I did it when I wanted something similar.
I created this decorator:
def static(**kw):
'''
Used to create a decorator function that will add an
attribute to a function and initialize it.
On Apr 4, 1:57 pm, John Nagle wrote:
> If you want functions with state, use an object. That's what they're
> for. Don't muck with the internal representation of functions.
>
While "Don't muck with the internal representation of functions" is
excellent advice over 99% of the time, it is also
kj wrote:
When coding C I have often found static local variables useful for
doing once-only run-time initializations.
If you want functions with state, use an object. That's what they're
for. Don't muck with the internal representation of functions.
John N
On 2010-04-02 20:24:46 -0700, Patrick Maupin said:
On Apr 2, 10:11 pm, Stephen Hansen wrote:
I don't know if properties are really faster or slower then a
__getattr__, but I find them a lot cleaner if I want to delay some
calculation until needed like that.
Well, the relative speed of prope
Steven D'Aprano wrote:
On Fri, 02 Apr 2010 19:48:59 -0700, Ethan Furman wrote:
The heuristic I use is, if I expect the try block to raise an exception
more than about one time in ten, I change to an explicit test. In this
case, since the exception should only be raised once, and then never
aga
On Fri, 02 Apr 2010 19:48:59 -0700, Ethan Furman wrote:
>> The heuristic I use is, if I expect the try block to raise an exception
>> more than about one time in ten, I change to an explicit test. In this
>> case, since the exception should only be raised once, and then never
>> again, I would use
On Apr 2, 10:11 pm, Stephen Hansen wrote:
>
> I don't know if properties are really faster or slower then a
> __getattr__, but I find them a lot cleaner if I want to delay some
> calculation until needed like that.
Well, the relative speed of properties vs. __getattr__ can become
irrelevant in at
On 2010-04-02 19:42:29 -0700, Ethan Furman said:
Terry Reedy wrote:
In Duncan
Booth writes:
class Spam(object):
mongo = None
def __call__(self, x, y, z):
if self.mongo is None:
self.mongo = heavy_lifting_at_runtime()
return frobnicate(x, y, z, self.mongo)
Unless one wants the intializat
Steven D'Aprano wrote:
On Fri, 02 Apr 2010 12:39:16 -0700, Patrick Maupin wrote:
On Apr 2, 2:38 pm, Ethan Furman wrote:
[...]
Sounds like a personal preference issue, rather than a necessary /
unnecessary issue -- after all, if you call that function a thousand
times, only once is mongo n
Terry Reedy wrote:
In Duncan
Booth writes:
class Spam(object):
mongo = None
def __call__(self, x, y, z):
if self.mongo is None:
self.mongo = heavy_lifting_at_runtime()
return frobnicate(x, y, z, self.mongo)
Unless one wants the intialization of mongo delayed
On 4/2/2010 1:28 PM, Paul McGuire wrote:
On Apr 1, 5:34 pm, kj wrote:
When coding C I have often found static local variables useful for
doing once-only run-time initializations. For example:
Here is a decorator to make a function self-aware, giving it a "this"
variable that points to itsel
On 4/2/2010 6:59 PM, kj wrote:
In Duncan
Booth writes:
class Spam(object):
mongo = None
def __call__(self, x, y, z):
if self.mongo is None:
self.mongo = heavy_lifting_at_runtime()
return frobnicate(x, y, z, self.mongo)
Unless one wants the intialization of mo
On Apr 2, 6:57 pm, Steven D'Aprano wrote:
> On Fri, 02 Apr 2010 12:39:16 -0700, Patrick Maupin wrote:
> > On Apr 2, 2:38 pm, Ethan Furman wrote:
> [...]
> >> Sounds like a personal preference issue, rather than a necessary /
> >> unnecessary issue -- after all, if you call that function a thousan
On Fri, 02 Apr 2010 12:39:16 -0700, Patrick Maupin wrote:
> On Apr 2, 2:38 pm, Ethan Furman wrote:
[...]
>> Sounds like a personal preference issue, rather than a necessary /
>> unnecessary issue -- after all, if you call that function a thousand
>> times, only once is mongo not defined... clearl
In Duncan Booth
writes:
>class Spam(object):
> mongo = None
> def __call__(self, x, y, z):
> if self.mongo is None:
> self.mongo = heavy_lifting_at_runtime()
> return frobnicate(x, y, z, self.mongo)
>spam = Spam()
>ham = spam(1, 2, 3)
I really like this. Thanks.
>T
On Apr 2, 3:33 pm, Ethan Furman wrote:
> My main point, though, was using __call__, and not some weird _ method. ;)
Yes, __call__ is good. In general, not naming things that don't need
to be named is good (but if you have too many of them to keep track
of, then, obviously, they need to be named
Patrick Maupin wrote:
[snippage]
Well, I think the whole discussion has basically been about personal
preference. OTOH, but if you call the function a few million times,
you might find the cost of try/except to be something that you would
rather not incur -- it might become a performance issue
On Apr 2, 2:38 pm, Ethan Furman wrote:
> Patrick Maupin wrote:
> > On Apr 2, 1:21 pm, Ethan Furman wrote:
> >> For this type of situation, my preference would be:
>
> >> class spam(object):
> >> def __call__(self, x, y, z):
> >> try:
> >> mongo = self.mongo
> >>
Patrick Maupin wrote:
On Apr 2, 1:21 pm, Ethan Furman wrote:
For this type of situation, my preference would be:
class spam(object):
def __call__(self, x, y, z):
try:
mongo = self.mongo
except AttributeError:
mongo = self.mongo = heavy_lifting_a
On Fri, 02 Apr 2010 16:08:42 +, kj wrote:
> Other responses advocated for global variables. I avoid them in
> general,
In general this is wise, but remember that because Python globals are not
globally global, but local to a single module, they're safer than globals
in other languages. St
On Apr 2, 1:21 pm, Ethan Furman wrote:
> For this type of situation, my preference would be:
>
> class spam(object):
> def __call__(self, x, y, z):
> try:
> mongo = self.mongo
> except AttributeError:
> mongo = self.mongo = heavy_lifting_at_runtime(
kj wrote:
class _Spam(object):
@classmethod
def _(cls, x, y, z):
try:
mongo = cls.mongo
except AttributeError:
mongo = cls.mongo = heavy_lifting_at_runtime()
return frobnicate(x, y, z, mongo)
ham = _Spam._(1, 2, 3)
Is this really more n
kj wrote:
> I suppose one could refactor this:
>
>
> def spam(x, y, z):
> try:
> mongo = spam.mongo
> except AttributeError:
> mongo = spam.mongo = heavy_lifting_at_runtime()
> return frobnicate(x, y, z, mongo)
>
> ham = spam(3, 4, 5)
>
>
> into this:
>
>
> class
kj wrote:
> In Steve Holden
> writes:
>
>>But the real problem is that the OP is insisting on using purely
>>procedural Python when the problem is screaming for an object-oriented
>>answer.
>
> My initial reaction to this comment was something like "What? switch
> from procedural to OO just to
On Apr 1, 5:34 pm, kj wrote:
> When coding C I have often found static local variables useful for
> doing once-only run-time initializations. For example:
>
Here is a decorator to make a function self-aware, giving it a "this"
variable that points to itself, which you could then initialize from
In Steve Holden
writes:
>But the real problem is that the OP is insisting on using purely
>procedural Python when the problem is screaming for an object-oriented
>answer.
My initial reaction to this comment was something like "What? switch
from procedural to OO just to be able to do some one-t
kj writes:
> When coding C I have often found static local variables useful for
> doing once-only run-time initializations. For example:
>
> int foo(int x, int y, int z) {
> static int first_time = TRUE;
> static Mongo *mongo;
> if (first_time) { ...
Here are some cheesy ways.
1. Put an
* kj:
When coding C I have often found static local variables useful for
doing once-only run-time initializations. For example:
int foo(int x, int y, int z) {
static int first_time = TRUE;
static Mongo *mongo;
if (first_time) {
mongo = heavy_lifting_at_runtime();
first_time = FAL
Terry Reedy wrote:
> On 4/1/2010 6:34 PM, kj wrote:
>>
>>
>> When coding C I have often found static local variables useful for
>> doing once-only run-time initializations. For example:
>>
>> int foo(int x, int y, int z) {
>>
>>static int first_time = TRUE;
>>static Mongo *mongo;
>>if
On Apr 1, 6:10 pm, Steve Holden wrote:
> Chris Rebert wrote:
> > Personally, I hate such abuse with a passion; I think a global
> > variable is clearest.
>
> But the real problem is that the OP is insisting on using purely
> procedural Python when the problem is screaming for an object-oriented
>
On 4/1/2010 6:34 PM, kj wrote:
When coding C I have often found static local variables useful for
doing once-only run-time initializations. For example:
int foo(int x, int y, int z) {
static int first_time = TRUE;
static Mongo *mongo;
if (first_time) {
mongo = heavy_lifting_at_
Chris Rebert wrote:
> On Thu, Apr 1, 2010 at 3:34 PM, kj wrote:
>> When coding C I have often found static local variables useful for
>> doing once-only run-time initializations.
>
>> Another approach would be to stuff the static values in the function's
>> __dict__. This is less satisfactory th
On Thu, Apr 1, 2010 at 3:34 PM, kj wrote:
> When coding C I have often found static local variables useful for
> doing once-only run-time initializations.
> Another approach would be to stuff the static values in the function's
> __dict__. This is less satisfactory than the closure approach
> be
When coding C I have often found static local variables useful for
doing once-only run-time initializations. For example:
int foo(int x, int y, int z) {
static int first_time = TRUE;
static Mongo *mongo;
if (first_time) {
mongo = heavy_lifting_at_runtime();
first_time = FALSE;
37 matches
Mail list logo
