3 ms·

Great looking site, and good luck. My IP data was pretty much bang on, something I haven't seen before. However, I was just looking at your Python SDK: https:/

by orf 9y ago

Great looking site, and good luck. My IP data was pretty much bang on, something I haven't seen before. However, I was just looking at your Python SDK: https://github.com/ipdata/python/blob/master/ipdata/ipdata.py#L20 https://github.com/ipdata/python/blob/master/ipdata/ipdata.p... What are you thinking. Never do this in a library. Also it looks a bit amaterish, as it's your only currently supported library I'd fix it up a bit - don't add .pyc/dist files to git, make it pep8, remove sys.exit() in a library (!!!) etc.

jonathan-kosgei 9y ago
You're absolutely right! Not sure how/why that got in there in the first place. I'm fixing a new release right now. I'm also going to have the repo/package cleaned up. Pushed a new release: https://pypi.python.org/pypi/ipdata/2.6 https://pypi.python.org/pypi/ipdata/2.6
- kelnos 9y ago
  Calling 'print' from within a library is pretty bad form too... responses and errors should always be returned as data that can be inspected programmatically. In this case it's even worse, as the code will just return None on error, and you don't know why.
  - orf 9y ago
    ^ This. Never call print from a library, what if I'm using a script to pipe stdout somewhere. Just throw a custom GeolocationException or something, with some useful data about what went wrong. In this specific case though, just don't bother catching the exception. It's not useful and it indicates something is terribly wrong.
    - jonathan-kosgei 9y ago
      Fixed https://github.com/ipdata/python/blob/master/ipdata/ipdata.py https://github.com/ipdata/python/blob/master/ipdata/ipdata.p... will add enhancements when I can.
  - jonathan-kosgei 9y ago
    You're right. I guess it makes sense to let Request's exceptions propagate in case there are network issues. I'll work on ensuring pep-8 adherence and adding custom exceptions for the error codes in https://ipdata.co/docs.html#status-codes https://ipdata.co/docs.html#status-codes
deleted 9y ago
[deleted]

by orf 9y ago

jonathan-kosgei 9y ago

You're absolutely right! Not sure how/why that got in there in the first place. I'm fixing a new release right now. I'm also going to have the repo/package cleaned up. Pushed a new release: https://pypi.python.org/pypi/ipdata/2.6 https://pypi.python.org/pypi/ipdata/2.6

kelnos 9y ago
Calling 'print' from within a library is pretty bad form too... responses and errors should always be returned as data that can be inspected programmatically. In this case it's even worse, as the code will just return None on error, and you don't know why.
- orf 9y ago
  ^ This. Never call print from a library, what if I'm using a script to pipe stdout somewhere. Just throw a custom GeolocationException or something, with some useful data about what went wrong. In this specific case though, just don't bother catching the exception. It's not useful and it indicates something is terribly wrong.
  - jonathan-kosgei 9y ago
    Fixed https://github.com/ipdata/python/blob/master/ipdata/ipdata.py https://github.com/ipdata/python/blob/master/ipdata/ipdata.p... will add enhancements when I can.
- jonathan-kosgei 9y ago
  You're right. I guess it makes sense to let Request's exceptions propagate in case there are network issues. I'll work on ensuring pep-8 adherence and adding custom exceptions for the error codes in https://ipdata.co/docs.html#status-codes https://ipdata.co/docs.html#status-codes

deleted 9y ago

[deleted]