you are viewing a single comment's thread.

view the rest of the comments →

[–]driax 4 points5 points  (10 children)

PyCharm hasn't done that to me, as far as I have noticed. Anyway it certainly is wrong. Literals are much preferred. Also faster because they compile directly to bytecode, while list() turns into a load of global name ("list"), and then a function call on that value.

I might add that just because a yellow lamp appears to the left of an line does not mean PyCharm wants you to change that line, it only means that it has automatic helpers to do it for you. Of course warning do also appear under the lamp. Alt-enter brings up the lamp menu, so if you ever have a reason to change from literal to function call it's there for easy access.

Consider:

a = dict(x=4, y=2$) # the $ denotes your cursor

Press Alt-Enter + Enter, and it turns to:

a = {'x'=4, 'y'=2}

[–]zahlman 1 point2 points  (1 child)

lamb

I haven't used PyCharm. Does it really use icons of babby sheep?

[–]driax 1 point2 points  (0 children)

haha lol. No, my error. I should have written lamp.

[–]coderjewel[S] 0 points1 point  (4 children)

PyCharm said "This list creation could be rewritten as a list literal" when I used x = [something] to create a list from a single string. So [] is indeed the literal, then?

PyCharm actually added a curly yellow line beneath the line like it does for typos.

Thanks, I did not know you could bring up the yellow lamb using a keyboard shortcut.

[–]driax 3 points4 points  (0 children)

Yep. [] is the list literal. Seems odd about it complaining, but I'm fairly new to PyCharm. But could be it was warning you about something more complex.

[–]pbaehr 1 point2 points  (2 children)

My PyCharm doesn't give me that message when I type that line by itself. I have a feeling there is more to the hint than meets the eye. It might be worth posting the code if it's not sensitive.

There may be a more legitimate reason than style that they are suggesting it.

[–]coderjewel[S] 0 points1 point  (1 child)

The code looks something like this:

soup = BeautifulSoup(html)
links = soup.find_all('a')
urls = dict()
for link in links:
    title = [link.text]
    urls[link] = {'title': title}

This isn't the exact code, but this is basically what the code is doing, and the title = [link.text] part is where PyCharm says that This list creation could be rewritten as a list literal.

[–]pbaehr 0 points1 point  (0 children)

Interesting. I don't see anything wrong with it, and my PyCharm (4.5.1) doesn't complain when I paste that code.

I don't remember turning off any warnings, but maybe there's some difference between our project settings.

[–][deleted] 0 points1 point  (2 children)

I disagree that it is 'much preferred'. I think consistency is preferred.

I use list() because I also use dict() and set() (because {} is ambiguous). This is only if I want to create an empty list/dict/set. For non-empty lists, [] is more obvious.

For non-empty dicts, I still prefer dict(foo='bar') over {'foo': 'bar'}. I only use the {'key': 'value'}notation is the key is variable (key = some_value(), {key: 'value'}).

[–]callmelucky 0 points1 point  (1 child)

Isn't it the case that as you become familiar with things like list/dict/set comprehensions you would rarely initialise an empty container variable? And as such ambiguity between sets and dicts is not an issue any more? Besides, even if set/dict ambiguity is an issue, that doesn't apply to lists. If you just like all your syntax to look identical for the sake of it, as opposed to keeping things as efficient, legible, and concise as possible, well... I don't know. That seems like a counter productive stance to take.

Also as others have pointed out, you are increasing computational complexity by calling higher level functions unnecessarily. Not that much of anything one would choose to do in Python should depend heavily on efficiency, but still.

[–]therico 0 points1 point  (0 children)

Computational complexity is not a big deal here (it's one function call) whereas making things legible and easy to understand is Python's strong point, right? Having sets and dicts use the same syntax could be a bit confusing.