In article mailman.1441.1270165718.23598.python-l...@python.org,
Steve Holden st...@holdenweb.com 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
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.
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
On Apr 5, 6:50 pm, Ethan Furman et...@stoneleaf.us 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
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
On Apr 4, 1:57 pm, John Nagle na...@animats.com 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
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 a
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
On 2010-04-02 20:24:46 -0700, Patrick Maupin said:
On Apr 2, 10:11 pm, Stephen Hansen apt.shan...@gmail.invalid 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,
In mailman.1437.1270163476.23598.python-l...@python.org Steve Holden
st...@holdenweb.com 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
On Apr 1, 5:34 pm, kj no.em...@please.post 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
kj wrote:
In mailman.1437.1270163476.23598.python-l...@python.org Steve Holden
st...@holdenweb.com 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
kj no.em...@please.post wrote:
I suppose one could refactor this:
procedural
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)
/procedural
kj wrote:
OO
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)
/OO
Is this really
On Apr 2, 1:21 pm, Ethan Furman et...@stoneleaf.us 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 =
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.
Patrick Maupin wrote:
On Apr 2, 1:21 pm, Ethan Furman et...@stoneleaf.us 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 =
On Apr 2, 2:38 pm, Ethan Furman et...@stoneleaf.us wrote:
Patrick Maupin wrote:
On Apr 2, 1:21 pm, Ethan Furman et...@stoneleaf.us wrote:
For this type of situation, my preference would be:
class spam(object):
def __call__(self, x, y, z):
try:
mongo =
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
On Apr 2, 3:33 pm, Ethan Furman et...@stoneleaf.us 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,
In xns9d4ec021dc8eaduncanbo...@127.0.0.1 Duncan Booth
duncan.bo...@invalid.invalid 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 =
On Fri, 02 Apr 2010 12:39:16 -0700, Patrick Maupin wrote:
On Apr 2, 2:38 pm, Ethan Furman et...@stoneleaf.us 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
On Apr 2, 6:57 pm, Steven D'Aprano st...@remove-this-
cybersource.com.au wrote:
On Fri, 02 Apr 2010 12:39:16 -0700, Patrick Maupin wrote:
On Apr 2, 2:38 pm, Ethan Furman et...@stoneleaf.us wrote:
[...]
Sounds like a personal preference issue, rather than a necessary /
unnecessary issue --
On 4/2/2010 6:59 PM, kj wrote:
Inxns9d4ec021dc8eaduncanbo...@127.0.0.1 Duncan
Boothduncan.bo...@invalid.invalid writes:
class Spam(object):
mongo = None
def __call__(self, x, y, z):
if self.mongo is None:
self.mongo = heavy_lifting_at_runtime()
return
On 4/2/2010 1:28 PM, Paul McGuire wrote:
On Apr 1, 5:34 pm, kjno.em...@please.post 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
Terry Reedy wrote:
Inxns9d4ec021dc8eaduncanbo...@127.0.0.1 Duncan
Boothduncan.bo...@invalid.invalid 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,
Steven D'Aprano wrote:
On Fri, 02 Apr 2010 12:39:16 -0700, Patrick Maupin wrote:
On Apr 2, 2:38 pm, Ethan Furman et...@stoneleaf.us wrote:
[...]
Sounds like a personal preference issue, rather than a necessary /
unnecessary issue -- after all, if you call that function a thousand
times,
On 2010-04-02 19:42:29 -0700, Ethan Furman said:
Terry Reedy wrote:
Inxns9d4ec021dc8eaduncanbo...@127.0.0.1 Duncan
Boothduncan.bo...@invalid.invalid writes:
class Spam(object):
mongo = None
def __call__(self, x, y, z):
if self.mongo is None:
self.mongo = heavy_lifting_at_runtime()
return
On Apr 2, 10:11 pm, Stephen Hansen apt.shan...@gmail.invalid 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
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;
On Thu, Apr 1, 2010 at 3:34 PM, kj no.em...@please.post wrote:
When coding C I have often found static local variables useful for
doing once-only run-time initializations.
snip
Another approach would be to stuff the static values in the function's
__dict__. This is less satisfactory than the
Chris Rebert wrote:
On Thu, Apr 1, 2010 at 3:34 PM, kj no.em...@please.post wrote:
When coding C I have often found static local variables useful for
doing once-only run-time initializations.
snip
Another approach would be to stuff the static values in the function's
__dict__. This is less
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 =
On Apr 1, 6:10 pm, Steve Holden st...@holdenweb.com 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
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 (first_time) {
* 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 =
kj no.em...@please.post 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
37 matches
Mail list logo
