This question already has answers here:
Why is it string.join(list) instead of list.join(string)?
(11 answers)
Closed 7 years ago.
I have some previous experience with C++ and just getting started up with Python. I read this text from Dive into Python :
In my experience, a general idea is, if you want to perform an operation on object 'O', you call a method on that object to do it.
Eg. If I have a list object, and I want to get summation of all elements, I would do something like :
listObject.getSumOfAllElements()
However, the call given in above book excerpt looks a little odd to me. To me this would make more sense :
return (["%s=%s" % (k, v) for k, v in params.items()]).join(";")
i.e. join all the elements of the list as a string, and here, use this parameter ';' as a delimiter.
Is this a design difference or just syntactically a little different than what I am thinking ?
Edit:
For completion, the book says this a little later :
Is this a design difference or just syntactically a little different than what I am thinking?
Yes, I think it is by design. The join function is intentionally generic, so that it can be used with any iterable (including iterator objects and generators). This avoids implementing join for list, tuple, set etc separately.
Related
This question already has answers here:
What is the return value of the range() function in python?
(5 answers)
Closed 6 months ago.
On an online course, the teacher says that range() produces a tuple, adding that this is the reason why we have to convert it into a list (thanks to the list() function) if we want to modify it.
Is this statement true ?
Because in the official documentation, they dont talk about tuple at all in the range() section : https://docs.python.org/3/tutorial/controlflow.html#the-range-function
Starting with python3, range returns a range object which is a sequence type which, among other things, can be iterated to create a list out of it.
Relevant docs about the range type.
Before that, it used to return a list, like Klaus commented. (docs)
This question already has answers here:
Empty set literal?
(7 answers)
Closed 1 year ago.
I am currently learning Python and was answering questions on a practice quiz where I encountered the following questions:
What is the output of print(type({}) is set) ?
What is the output of print(type([]) is list) ?
I am unsure on how to approach the justification as to why Q1. yields False, yet Q2. yields True. I am following the guidance from a relevant post detailing the nuances of the keyword is, yet I fail to see where the two differ when comparing lists vs sets.
This is not about the nuances of is.
{} in Python is an empty dictionary. There is no literal for creating an empty set in Python (see this answer, and the actual docs). If you were to try type(set()) is set, you would produce True.
This question already has answers here:
What are type hints in Python 3.5?
(5 answers)
Closed 4 years ago.
I have seen people using
def testing(cha: List[Dict]) -> List[List[Dict]])
I would like to know what is this function for and what is the "->" for?
I understand that it take the dictionary with value "cha" which is in list of dictionaries and convert it to list list of dictionaries.
Is my understanding above a correct one? If no, could someone please show me some simple example?
That is Python's type hinting. It's just syntactic sugar to help the developer reading your code get a sense of what type of input your function is expecting and what type of output it should return. Types to the left of -> denote the input type, and types to the right of -> denote the return type. In your example,
def testing(cha: List[Dict]) -> List[List[Dict]]:
...
testing is a function that is supposed to accept a list named cha which contains dictionaries and return a list which contains lists which in turn contain dictionaries. Something like this,
>>> testing([{'a':12, 'b':34}])
>> [[{'a':12, 'b':34}], [{'a':24, 'b':68}]]
That being said, Python is still a dynamically typed language and type hints don't add any compiler optimizations to your code. All type checking still happens at runtime. There is nothing stopping you from violating type hints of your function, which means I could pass any type of argument to testing and it would still try to use it as valid input.
This question already has answers here:
Python string join performance
(7 answers)
Closed 5 years ago.
I know that ''.join(list) is the preferred method to concatenate strings as opposed to say:
for x in list:
s += x
My question is why is this much faster?
Also, what if I need to concatenate items that are not already in a list? Is it still faster to put them in a list just for the purpose of doing the ''.join(list)?
EDIT: This is different than the previously linked question because I'm specifically interested in knowing if the items are not in a list already, is it still recommended for performance reasons to put them in a list for the sole purpose of joining.
This is faster because the join method gets to dive "under the surface" and use lower-level optimizations not available from the Python layer. The loop has to plod through the sequence generator and deal with each object in turn. Also, your loop has to build a new string on each iteration, a slow process. join gets to use mutable strings on the C layer or below.
If the objects aren't already in a list ... it depends on the application. However, I suspect that almost any such application will have to go through that loop-ish overhead somewhere just to form the list, so you'd lose some of the advantage of join, although the mutable string would still save time.
Yes, join is faster because it doesn't need to keep building new strings.
But you don't need a list to use join! You can give it any iterable, such as a generator expression:
''.join(x for x in lst if x != 'toss')
It appears that join is optimized when you use a list though. All of these are equivalent, but the one with a list comprehension is fastest.
>>> timeit("s=''.join('x' for i in range(200) if i!=47)")
15.870241802178043
>>> timeit("s=''.join(['x' for i in range(200) if i!=47])")
11.294011708363996
>>> timeit("s=''\nfor i in range(200):\n if i!=47:\n s+='x'")
16.86279364279278
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
What is the difference between LIST.append(1) and LIST = LIST + [1] (Python)
I'm new to Python and new to programming. I followed the book ThinkPython and here is one thing I can't get straight.
Exercise 10.7 Write a function that reads the file words.txt and builds a list with one element per word. Write two versions of this function, one using the append method and the other using the idiom t = t + [x]. Which one takes longer to run? Why?
I tried the two methods and found the later one (t=t+[x]) took much longer time than append method. Here is my first question, why would this happen?
I changed the line t=t+[x] to t+=[x] just for no reason only to find this revised version take almost the same time as the append method. I thought t=t+[x] is equal to t+=[x], apparently they are not. Why?
BTW: I tried search Google using python += as key words but it seems Google won't take += as a key word even I put a quotation mark to it.
t = t + [x]
takes t, concatenates with [x] (calling t's method __add__), which creates a new list, which is then named t.
t += [x]
calls the t's method __iadd__ which works directly on the list itself. There is no extra list created.
First, you need to know, that the add method results creating a new object, while append() just modifies the existing object, thus resulting in better performance.
As for the second question, knowing the above, you may find out what the '+=' or 'plus equals' operator is equivalent to in python and therefore behave differently to '+' operator.
You might also want to check out this link which explains the difference between add and iadd methods which are being called in your example and perhaps this one as well to establish your knowledge.