20 comments

[ 5.0 ms ] story [ 53.4 ms ] thread
Hi, nice job.

A few unsolicited code tips that seem to come up often if I may:

- `if <somestuff>: return True; else: return False` is always best spelled `return <somestuff>`

- You only need the global statement when you want to assign to a global, not access one

- `foo = d["bla"] if "bla" in d else None` is just `foo = d.get("bla")`

- You have mutable default args. They probably are not what you want. See http://docs.python-guide.org/en/latest/writing/gotchas/#muta... for e.g. for an explanation.

- Lots of your dicts with enumerates to set indices should just probably be lists

If I get a chance later I'll try to throw together a quick pull request, but otherwise, thanks for sharing.

thanks for the feedback, i'm new to Python and will take them onboard & fix those points in a couple of days if you follow the repository
mutable default args is probably the thing that will bite you the hardest!
I will agree with everything but the first one. I prefer functions that claim to return True or False to return precisely that, rather than Truthy/Falsy values. Otherwise, if I want to do "if func() is other_val" where "other_val" is True or False, it will fail.
Yes, you should never do ‛foo is True either :).

Also, here the point is that <some stuff> was a boolean expression already.

Well, how else would you check if a return value matches a True/False variable? if <var> and <retval>? That's horrible!
Obviously its a matter of personal preference but PEP 8 (official Python style guide) disagrees with you.
PEP 8 only mentions truth checks, it doesn't mention if functions' return values should be True or the truthy value. Personally, I find it very unclean to have your function return half a string, or some unrelated int or something similar when your function is called, e.g. "is_member()".
Ah, sorry think we are talking about different things. I thought you where complaining about:

  if [something]:
VS

  if [something] is True:
In the case I think you are talking about I would probably agree with you that returning some non-boolean is less clean, though I would probably just use the equality operator to force a boolean result:

  def foo(i):
    return i == 0
Yep, we agree exactly. I just don't like "return i", and would rather do "return i is True" or something.
In that case, you can always opt to return bool(return_value), which lets you return True or False without the ugly if / else : )
Indeed, or just "return var == True".
I'm guessing this is against their TOS?
IANAL, so I couldn't tell from the TOS if API use like this is acceptable or not, but at least on the "root page" of app.imdb.com, they say:

For use by clients authorized in writing by IMDb.

-- http://app.imdb.com/

OP: Did you ask for authorization?

The API also returns

  'copyright': 'For use only by clients authorized in writing by IMDb.  Authors and users of unauthorized clients accept full legal exposure/liability for their actions.'
as part of the json with every request made.

Since he is using the API key taken from the official app (see: https://github.com/maddox/imdb-party/issues/8#issuecomment-1... ) i really doubt he got anything from them.

Not sure why this is big news.

There has been a ruby library called imdb-party that I used several years ago to do this: https://github.com/maddox/imdb-party. Leverages the IMDB iOS API also.

Here is part of the code I used for simulating their id system (ex: tt0903624): # http://www.imdb.com/title/tt0903624/

require "imdb_party"

imdb = ImdbParty::Imdb.new

all_movies = (1..999999).map{ |m| "tt" + ("%07d" % m).to_s }

    (all_movies - current_movies).each do |movie_id|

      movie = imdb.find_movie_by_id(movie_id) rescue next
Nice project! A few years ago I hacked together a python IMDB API to help me cheat err... 'practice' for a trivia game:

https://github.com/dpiers/pymdb

Last I checked it still worked, surprising since I was just scraping html. :)