Re: [BangPypers] Return values

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 > )? [...] I didn't know about Courtesy implementation

Re: [BangPypers] Return values

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 > )? [...] I didn't know about Courtesy implementation

Re: [BangPypers] Return values

Hi Noufal, Looks like we already have different style preferences here. So let me throw some more to the mix :) Wearing a functional programmers cap, I would suggest creating one get_stats() function that always returns the stat values as a list. Then, there could be potentially several Higher Or

Re: [BangPypers] Return values

Hi, On Sat, Sep 20, 2014 at 2:34 PM, Noufal Ibrahim KV wrote: > > The problem now is that this function sometimes returns a single thing > and some times a list. I don't like this since I have to alter my > calling code to handle this. > I generally try to make the return type consistent.

Re: [BangPypers] Return values

On Sat, Sep 20, 2014 at 6:53 AM, Noufal Ibrahim KV 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 value. > > So

Re: [BangPypers] Return values

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

Re: [BangPypers] Return values

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 m

Re: [BangPypers] Return values

On Sat, Sep 20, 2014 at 5:15 PM, Noufal Ibrahim KV 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 given - why are you

Re: [BangPypers] Return values

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 psuti

Re: [BangPypers] Return values

On Sat, Sep 20, 2014 at 4:47 PM, Noufal Ibrahim KV 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 with you in prin

Re: [BangPypers] Return values

On Sat, Sep 20, 2014 at 4:24 PM, Noufal Ibrahim KV 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 readability. That is

Re: [BangPypers] Return values

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 ___ BangPyper

Re: [BangPypers] Return values

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 val

Re: [BangPypers] Return values

On Sat, Sep 20, 2014 at 4:18 PM, Noufal Ibrahim KV 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 "consolidated" > >

Re: [BangPypers] Return values

On Sat, Sep 20, 2014 at 2:50 PM, 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 resul

Re: [BangPypers] Return values

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 cal

Re: [BangPypers] Return values

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): >

Re: [BangPypers] Return values

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. > >

Re: [BangPypers] Return values

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 "consolidated" > argument is will not be confused. This explodes the API. It's similar to

Re: [BangPypers] Return values

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 P

Re: [BangPypers] Return values

On Sat, Sep 20, 2014 at 2:34 PM, Noufal Ibrahim KV 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 some source and re

Re: [BangPypers] Return values

On Sat, Sep 20, 2014 at 5:04 PM, Noufal Ibrahim KV 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 function sometimes re

Re: [BangPypers] Return values

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 [Sta

Re: [BangPypers] Return values

Can you please tell at how many places you make the call. That is the problem with these stupid dynamic languages :-) On Sep 20, 2014 2:35 PM, "Noufal Ibrahim KV" 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

[BangPypers] Return values

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