On Thu, Sep 25 2014, Saager Mhatre wrote:
[...]
Alternatively, would it be possible to model Stats/StatsList as a composite
hierarchy (potentially with Courtesy Implementations
http://martinfowler.com/bliki/CourtesyImplementation.html)?
[...]
I didn't know about Courtesy implementations
On Thu, Sep 25 2014, Saager Mhatre wrote:
[...]
Alternatively, would it be possible to model Stats/StatsList as a composite
hierarchy (potentially with Courtesy Implementations
http://martinfowler.com/bliki/CourtesyImplementation.html)?
[...]
I didn't know about Courtesy implementations
On Sat, Sep 20, 2014 at 6:53 AM, Noufal Ibrahim KV nou...@nibrahim.net.in
wrote:
On Sat, Sep 20 2014, Anand Chitipothu wrote:
[...]
Oh, that feels like PHP. That style seems to be popular in that side of
the
world.
It might be a good idea to add consolidate method on the return
I've recently come across something that I'd like some comments on. It's
a stylistic issue so not something that there's an objective answer
for. Nevertheless.
I have a function that gets some statistics from some source and returns
it to the user as a Stats object. Let's call it get_stats. This
Couple of approaches:
- Break the api into two. get_stats and get_stats_consolidated. This way,
the caller who doesn't know what is your default value of consolidated
argument is will not be confused.
- Change the return value to be a list always. Without consolidated set,
it will just be
On Sat, Sep 20, 2014 at 5:04 PM, Noufal Ibrahim KV nou...@nibrahim.net.in
wrote:
This has a
parameter `consolidate`. If consolidate is True, it will combine all the
statistics and return just one Stats object. If not, it will return a
list of Stats objects.
The problem now is that this
On Sat, Sep 20, 2014 at 2:34 PM, Noufal Ibrahim KV nou...@nibrahim.net.in
wrote:
I've recently come across something that I'd like some comments on. It's
a stylistic issue so not something that there's an objective answer
for. Nevertheless.
I have a function that gets some statistics from
Hi Noufal
Why not create two methods, get_stats() and get_stats_list(). Both can
share logic in a common function which takes the consolidate flag - meaning
your logic is localised to one point only. It makes for more readable code
when called as well.
Cheers
Vivek
On Sat, Sep 20, 2014 at 2:34
On Sat, Sep 20 2014, Senthil Kumaran wrote:
[...]
One option to me looks like, don't have consolidate as parameter for
this function, but do the operation outside. Like providing a
function called get_consolidated_stats, which will call get_stats and
provide the consolidated result.
The
On Sat, Sep 20 2014, Anand Chitipothu wrote:
[...]
Oh, that feels like PHP. That style seems to be popular in that side of the
world.
It might be a good idea to add consolidate method on the return value.
Something like:
class StatsList(list):
def consolidate(self):
..
On Sat, Sep 20 2014, Vivek Ramakrishna wrote:
Hi Noufal
Why not create two methods, get_stats() and get_stats_list(). Both can
share logic in a common function which takes the consolidate flag - meaning
your logic is localised to one point only. It makes for more readable code
when called
On Sat, Sep 20, 2014 at 2:50 PM, Senthil Kumaran sent...@uthcode.com
wrote:
One option to me looks like, don't have consolidate as parameter for this
function, but do the operation outside.
Like providing a function called get_consolidated_stats, which will call
get_stats and provide the
On Sat, Sep 20, 2014 at 4:18 PM, Noufal Ibrahim KV nou...@nibrahim.net.in
wrote:
On Sat, Sep 20 2014, Harish Vishwanath wrote:
Couple of approaches:
- Break the api into two. get_stats and get_stats_consolidated. This way,
the caller who doesn't know what is your default value of
On Sat, Sep 20 2014, Sriram Karra wrote:
[...]
I think the comparison is not strictly apples to apples. In case of sort
ascending / descending flag parameterises the same sort algorithm. In your
case, you do some additional things (loop through and add up stuff,
perhaps) based on the value
On Sat, Sep 20 2014, Sriram Karra wrote:
[...]
Having a method do two different things based on a flag is not
a clean answer to anything.
[...]
That's a useful rule of thumb. Thank you.
--
Cordially,
Noufal
http://nibrahim.net.in
___
BangPypers
On Sat, Sep 20, 2014 at 4:24 PM, Noufal Ibrahim KV nou...@nibrahim.net.in
wrote:
This approach (especially with many calls) will make the API really
big. I don't remember but I've seen things with get_something,
get_something_list, get_something_dict and what not which don't really
help
On Sat, Sep 20, 2014 at 4:47 PM, Noufal Ibrahim KV nou...@nibrahim.net.in
wrote:
Of course but the API should hide that in a neat way from you shouldn't
it? If I have two switches an operation, I'd still like to have just
one function. Not 4 representing all the combinations.
I will agree
On Sat, Sep 20 2014, Sriram Karra wrote:
[...]
But your problem can be addressed by naming the functions after what they
do - after all your consolidate function does something tangible other than
just return a different type of data.
[...]
Let me give you a specific example.
The psutils
On Sat, Sep 20, 2014 at 5:15 PM, Noufal Ibrahim KV nou...@nibrahim.net.in
wrote:
From the thread so far, Anand's solution is the one I like
best. Although it's something tailored for my problem rather than a
general pattern.
Anand's solution is good. But with the added context you have
On Sat, Sep 20 2014, Sriram Karra wrote:
[...]
Anand's solution is good. But with the added context you have given - why
are you not creating classes for CPU and Machine, with get_stats() and
set_stats() methods for them? Something like:
This is a higher level abstraction and something I
Dear Noufal,
Have not gone through all the replies...so may be i am repeating...may be I
am not in my senses :))
I would create a stats_bundle object, with members like stats_val
and stats_list,
which are initialized to None. So you always get a stats_bundle object
which you can pass around to
21 matches
Mail list logo
