[Tutor] small remark

Alan Gauld alan.gauld at yahoo.co.uk
Wed Jan 11 05:21:32 EST 2017

On 10/01/17 17:56, adil gourinda wrote:
>    When I was surfing in “Python Library” I made some observations and I want to share them 

That's good and as a place to discuss those observations the
tutor list is a suitable forum. However, if you want the
proposals considered for actual implementation, you will
need to submit them via the bug tracker on python.org

> *date.replace(year=self.year, month=self.month, day=self.day)
>    … . For example, if "d == date(2002, 12, 31)", then "d.replace(day=26) == date(2002,    12, 26)".
> ->change to:
> *date.replace(year=self.year, month=self.month, day=self.day)
>     … . For example:
>    >>> d=date(2002,12,31)
>   >>> d.replace(day=26)
>   datetime.date(2002, 12, 26)

I see what you are getting at but I guess the current form is more
compact and that's why it was chosen.

> *date.weekday()
> … . For example, "date(2002, 12, 4).weekday() == 2", a Wednesday. … .
> →change to :
> *date.weekday()
>     … . For example:
>    >>> date(2002, 12, 4).weekday()
>   2 (a Wednesday)

>     Those are examples in script format that the reader can try

They are not really in "script" form, they are in
interactive interpreter form which is actually different
to when used in a script, but I guess that's what you
mean - that they can be typed at the interpreter.

Of course the existing examples can be typed at the interpreter
too, but they just return True...

>    2) If we compare some methods between them we will find 
> some methods more generalized than others,
> So why we continue to use the latter :

There can be many reasons:
1) the specific method might be easier to use in the most common cases
2) the generalised method may be less efficient than the specialized
3) there may be a large body of legacy code that uses the specialised
version and it would be a lot of work to change it.
4) there may be subtle differences in the way the methods work for
certain data types

> * List.insert(i,x) vs List.append(x) vs List.extend(x) :
>    list.append(x) is restricted in the number of items in comparison with list.extend(x) 

No, the both take exactly 1 item each. The item can be a list. but...
They do slightly different things. for example compare

lst = [0]

lst2 = [0]

If we were to get rid of append, say, then the use of
extend to replicate append's functionality gets a bit

lst3 = [0]

> it is restricted in the position of items in comparison 
> with list.insert(i,x),

But you can't replicate extend() with insert() - at
least I can't think of a way. And even for appending, if
you don't know the size of the list you wind up with:

lst.insert(len(lst), data)

Which is both messy and slow.

> So I don’t see the utility of list.append(x) 

Appending is by far the most commonly used of
the three operations and append() is simpler and
it is faster - it doesn't have to do anything complex
like unpack its arguments(extend) or break open a
list and rearrange the contents(insert) it just
adds whatever it is given to the end.

> * For log function I suggest ...

I'm not familiar with the log functions but I suspect
performance of the most common scenarios may be the
reasons here too, but I'll leave others to comment
more fully.

Finally, it is probably possible to build optimised
versions of the general functions that would
recognise the special cases and treat them
differently. And if enough people ask for it somebody
may take the time to do it. But if you really want
it you need to discuss it via the official channels.

Python certainly does have a lot of redundant
functions - just look at how many ways there are to
start an external program (system/popen/command/
call/Popen/fork/exec etc...) And even when the docs
try hard to direct people to the recommended
option (like the subprocess module) many just
prefer the older ways because they know them,
or they are slightly simpler to use.

Alan G
Author of the Learn to Program web site
Follow my photo-blog on Flickr at:

More information about the Tutor mailing list