On 2013-10-20, Ben Finney wrote:
> Roy Smith writes:
>
>> Scott Meyers is an incredibly smart C++ wizard. His books are amazing.
>> The fact that it takes somebody that smart, and books that amazing, to
>> teach you how not to shoot yourself in the foot with a C++ compiler says
>> a lot abou
Am Montag, 21. Oktober 2013 06:31:36 UTC+2 schrieb Peter Cacioppi:
> That sound you hear is Roy Smith hitting the nail on the head.
PLONK: The sound you hear, when a context-less troll is hitting the bottom of
my killfile.
--
https://mail.python.org/mailman/listinfo/python-list
That sound you hear is Roy Smith hitting the nail on the head.
--
https://mail.python.org/mailman/listinfo/python-list
That sound you here is Roy Smith hitting the nail on the head re: C++ and Scott
Meyers.
--
https://mail.python.org/mailman/listinfo/python-list
Roy Smith writes:
> Scott Meyers is an incredibly smart C++ wizard. His books are amazing.
> The fact that it takes somebody that smart, and books that amazing, to
> teach you how not to shoot yourself in the foot with a C++ compiler says
> a lot about the language.
+1 QotW
--
\ “[W]
In article ,
Peter Cacioppi wrote:
> I read Scott Meyers books on C++ and STL a couple of times
> each and helped design the protocol that kept us reasonably safe.
Scott Meyers is an incredibly smart C++ wizard. His books are amazing.
The fact that it takes somebody that smart, and books t
At the risk of sounding like a fogey, I actually think I did, at one time, know
the distinctions between "our projects protocol" and "the language proper" for
C++. I read Scott Meyers books on C++ and STL a couple of times each and helped
design the protocol that kept us reasonably safe.
But t
On Mon, Oct 21, 2013 at 4:57 AM, Peter Cacioppi
wrote:
>> You certainly don't have to write a constructor for a subclass in C++.
>
> Ahh, this message board is so collectively well informed (once you get past
> the trolls)
>
> The C++ project I worked on was religious about always overwriting pa
In article <0e9b51a9-bd78-4d34-b277-c463347e8...@googlegroups.com>,
Peter Cacioppi wrote:
> > You certainly don't have to write a constructor for a subclass in C++.
>
> Ahh, this message board is so collectively well informed (once you get past
> the trolls)
>
> The C++ project I worked on
> You certainly don't have to write a constructor for a subclass in C++.
Ahh, this message board is so collectively well informed (once you get past the
trolls)
The C++ project I worked on was religious about always overwriting parent class
constructors. I had assumed this was because the lan
On Sat, Oct 19, 2013 at 2:44 PM, Peter Cacioppi
wrote:
> Is the following considered poor Python form?
>
> class Foo (object) :
> _lazy = None
> def foo(self, x) :
> self._lazy = self._lazy or self.get_something(x)
> def get_something(self, x) :
> # doesn't really matte
On 20/10/2013 08:09, Peter Cacioppi wrote:
Personally, I find the ability of Python to subclass without overriding the
constructor very elegant.
__new__ is the constructor which to my knowledge you've not mentioned,
__init__ is the initialiser as mentioned by Ben Finney.
--
Roses are red,
In article ,
Peter Cacioppi wrote:
> Personally, I find the ability of Python to subclass without overriding the
> constructor very elegant. I don't believe the other languages I've worked in
> can do this (C++, C#, Java)...
I'm not sure what point you're trying to make here. You certainly d
Peter Cacioppi writes:
> I was laboring under some misconception that there was Python magic
> that allowed __init__ and only __init__ to add class attributes by
> setting their values. Good to know this piece of magic isn't part of
> Python, and thus lazy eval can be handled more cleanly than I
> Why not simply have one, and use it to initialize your attributes,
> even if it is to None?
Think about it this way. None here really means "not yet initialized". It is a
value that cannot occur naturally and thus functions as a not-initialized flag.
But for different contexts, this value co
>The use of getattr here seems unfortunate
Unfortunate how? It's a perfect for what I want here ... remember the context
is such that the lazily stored value is always truthy (I assert this elsewhere).
> I'm not sure why you want to avoid an __init__ method.
Why do you want to keep it? The
On 10/19/13 8:42 PM, Peter Cacioppi wrote:
To be clear, my original post had a goof.
So my original, de-goofed, idiom was
class Foo (object) :
_lazy = None
def foo(self, x) :
self._lazy = self._lazy or self.get_something(x)
def get_something(self, x) :
# doesn'
To be clear, my original post had a goof.
So my original, de-goofed, idiom was
class Foo (object) :
_lazy = None
def foo(self, x) :
self._lazy = self._lazy or self.get_something(x)
def get_something(self, x) :
# doesn't really matter, so long as it returns truthy res
Yes, I see the light now. My idiom works, but Steven has shown me the droids I
am looking for.
Thanks!
--
https://mail.python.org/mailman/listinfo/python-list
On Sat, 19 Oct 2013 14:44:55 -0700, Peter Cacioppi wrote:
> Is the following considered poor Python form?
>
> class Foo (object) :
> _lazy = None
> def foo(self, x) :
> _lazy = _lazy or self.get_something(x)
> def get_something(self, x) :
> # doesn't really matter
>
>
On 2013-10-19 22:55, Ned Batchelder wrote:
On 10/19/13 5:44 PM, Peter Cacioppi wrote:
Is the following considered poor Python form?
class Foo (object) :
_lazy = None
def foo(self, x) :
_lazy = _lazy or self.get_something(x)
def get_something(self, x) :
# doesn't
On Saturday, October 19, 2013 2:44:55 PM UTC-7, Peter Cacioppi wrote:
> Is the following considered poor Python form?
>
>
>
> class Foo (object) :
>
> _lazy = None
>
> def foo(self, x) :
>
> _lazy = _lazy or self.get_something(x)
>
> def get_something(self, x) :
>
>
On 10/19/13 5:44 PM, Peter Cacioppi wrote:
Is the following considered poor Python form?
class Foo (object) :
_lazy = None
def foo(self, x) :
_lazy = _lazy or self.get_something(x)
def get_something(self, x) :
# doesn't really matter
I like this idiom for certai
Is the following considered poor Python form?
class Foo (object) :
_lazy = None
def foo(self, x) :
_lazy = _lazy or self.get_something(x)
def get_something(self, x) :
# doesn't really matter
I like this idiom for certain situations, just wondering if it will raise the
24 matches
Mail list logo