Now following my series of \"python newbie questions\" and based on another question.
Go to http://python.net/~goodger/projects/pyco
Probably you should not define these two functions as good and bad. You can use the first one with list or dictionaries to implement in place modifications of the corresponding objects. This method can give you headaches if you do not know how mutable objects work but given you known what you are doing it is OK in my opinion.
So you have two different methods to pass parameters providing different behaviors. And this is good, I would not change it.
The extremely specific use case of a function that lets you optionally pass a list to modify, but generates a new list unless you specifically do pass one in, is definitely not worth a special-case syntax. Seriously, if you're making a number of calls to this function, why ever would you want to special-case the first call in the series (by passing only one argument) to distinguish it from every other one (which will need two arguments to be able to keep enriching an existing list)?! E.g., consider something like (assuming of course that betterappend
did something useful, because in the current example it would be crazy to call it in lieu of a direct .append
!-):
def thecaller(n):
if fee(0):
newlist = betterappend(foo())
else:
newlist = betterappend(fie())
for x in range(1, n):
if fee(x):
betterappend(foo(), newlist)
else:
betterappend(fie(), newlist)
this is simply insane, and should obviously be, instead,
def thecaller(n):
newlist = []
for x in range(n):
if fee(x):
betterappend(foo(), newlist)
else:
betterappend(fie(), newlist)
always using two arguments, avoiding repetition, and building much simpler logic.
Introducing special-case syntax encourages and supports the special-cased use case, and there's really not much sense in encouraging and supporting this extremely peculiar one -- the existing, perfectly regular syntax is just fine for the use case's extremely rare good uses;-).
This is better than good_append(), IMO:
def ok_append(new_item, a_list=None):
return a_list.append(new_item) if a_list else [ new_item ]
You could also be extra careful and check that a_list was a list...
I think you're confusing elegant syntax with syntactic sugar. The python syntax communicates both approaches clearly, it just happens that the correct approach appears less elegant (in terms of lines of syntax) than the incorrect approach. But since the incorrect approach, is well...incorrect, it's elegance is irrelevant. As to why something like you demonstrate in better_append is not implemented, I would guess that There should be one-- and preferably only one --obvious way to do it.
trumps minor gains in elegance.
What if you were not talking about lists, but about AwesomeSets, a class you just defined? Would you want to define ".local" in every class?
class Foo(object):
def get(self):
return Foo()
local = property(get)
could possibly work, but would get old really quick, really soon. Pretty soon, the "if a is None: a = CorrectObject()" pattern becomes second nature, and you won't find it ugly -- you'll find it illuminating.
The problem is not one of syntax, but one of semantics -- the values of default parameters are evaluated at function definition time, not at function execution time.
This is called the 'mutable defaults trap'. See: http://www.ferg.org/projects/python_gotchas.html#contents_item_6
Basically, a_list
is initialized when the program is first interpreted, not each time you call the function (as you might expect from other languages). So you're not getting a new list each time you call the function, but you're reusing the same one.
I guess the answer to the question is that if you want to append something to a list, just do it, don't create a function to do it.
This:
>>> my_list = []
>>> my_list.append(1)
Is clearer and easier to read than:
>>> my_list = my_append(1)
In the practical case, if you needed this sort of behavior, you would probably create your own class which has methods to manage it's internal list.