These forums have been archived and are now read-only.

The new forums are live and can be found at https://forums.eveonline.com/

EVE Technology Lab

 
  • Topic is locked indefinitely.
 

Pew - a simple Python EVE API wrapper
Author
Previous Topic Next Topic
Terminal Dogma
Meowniversal Ltd.
#1 - 2012-07-06 03:36:51 UTC
Something I wrote over the past weekend, partially as part of a larger EVE-related development project I had in mind, and partially to brush up on my Python :)

Pew [Python EVE Wrapper], a simple, lightweight Python wrapper for the EVE Online API

https://github.com/crsmithdev/Pew

I'd be particularly interested in feedback from people who might use it. What do you like about it? Not like?

Thanks.
Entity
X-Factor Industries
Synthetic Existence
#2 - 2012-07-06 22:16:18 UTC
I like the name.

I don't really like the hardcoded methods, though. I prefer my black magic voodoo approach :)

╦......║...╔╗.║.║.╔╗.╦║.╔╗╔╦╗╔╗

║.╔╗╔╗╔╣.╔╗╠..╠ ╠╗╠╝.║╠ ╠╝║║║╚╗

╩═╚╝║.╚╝.╚╝║..╚╝║║╚╝.╩╚╝╚╝║.║╚╝

Got Item?
Terminal Dogma
Meowniversal Ltd.
#3 - 2012-07-06 22:47:51 UTC
Entity wrote:
I like the name.

I don't really like the hardcoded methods, though. I prefer my black magic voodoo approach :)


Thanks. Can you explain that a little bit more? As opposed to "hardcoded" methods, are you suggesting that the wrapper not have any specific knowledge of API methods and require the user to pass in the API method URL for each call?
Entity
X-Factor Industries
Synthetic Existence
#4 - 2012-07-06 23:01:50 UTC
Terminal Dogma wrote:
Entity wrote:
I like the name.

I don't really like the hardcoded methods, though. I prefer my black magic voodoo approach :)


Thanks. Can you explain that a little bit more? As opposed to "hardcoded" methods, are you suggesting that the wrapper not have any specific knowledge of API methods and require the user to pass in the API method URL for each call?


Sort of. I'm using python's __getattr__ and friends to handle the magic in my api module.

https://github.com/ntt/eveapi

╦......║...╔╗.║.║.╔╗.╦║.╔╗╔╦╗╔╗

║.╔╗╔╗╔╣.╔╗╠..╠ ╠╗╠╝.║╠ ╠╝║║║╚╗

╩═╚╝║.╚╝.╚╝║..╚╝║║╚╝.╩╚╝╚╝║.║╚╝

Got Item?
Terminal Dogma
Meowniversal Ltd.
#5 - 2012-07-06 23:19:22 UTC
Entity wrote:


Sort of. I'm using python's __getattr__ and friends to handle the magic in my api module.

https://github.com/ntt/eveapi



I see. I'm using, effectively, the inverse to build objects from the API response. I understand the attraction of this from a "future proofing" standpoint, but I have two issues:


  • How often does CCP alter the API significantly enough that this is really an advantage? (I actually don't know)
  • Doesn't this allow the client to attempt to call _any_ method, even a bogus one, and the library will try and execute it as it would a valid one?


Coming from more of a C# background, where you can't really do this, all the API wrappers I've written have been well-defined interfaces, with (usually) one call for each API method. Its an interesting trade-off: it reduces the # of lines of code significantly and does indeed "future proof" the wrapper...on the other hand, it doesn't really present a defined interface for the client, and allows them to potentially do some odd things, ultimately requiring them to have more direct knowledge of what the actual API methods are and how they're used.

Thanks for the feedback / explanation and for pointing me towards your code. I actually initially called mine EveApi as well (sensible) but changed it after finding yours yesterday.
Entity
X-Factor Industries
Synthetic Existence
#6 - 2012-07-06 23:42:26 UTC
Terminal Dogma wrote:


  • How often does CCP alter the API significantly enough that this is really an advantage? (I actually don't know)
  • Doesn't this allow the client to attempt to call _any_ method, even a bogus one, and the library will try and execute it as it would a valid one?


Coming from more of a C# background, where you can't really do this, all the API wrappers I've written have been well-defined interfaces, with (usually) one call for each API method. Its an interesting trade-off: it reduces the # of lines of code significantly and does indeed "future proof" the wrapper...on the other hand, it doesn't really present a defined interface for the client, and allows them to potentially do some odd things, ultimately requiring them to have more direct knowledge of what the actual API methods are and how they're used.


Well, the only things I've done to my library since release were bugfixes for CCP's inconsistencies and changes. Typically the library needed no changes for new functionality, and they've expanded the api considerably since its creation.

I'll admit to my method being a bit arcane and requiring external documentation and knowledge of the EVE API for it to be useful. As you pointed out, it is a trade-off. Also, I'd hate to do all the validation in my code when I can just let the server complain about it and throw an exception instead (I'm lazy)

It's all moot anyway because the current API is pretty much at the end of its life, with the CREST API just around the corner. It'll prolly be a while before it offers the same information, though.

╦......║...╔╗.║.║.╔╗.╦║.╔╗╔╦╗╔╗

║.╔╗╔╗╔╣.╔╗╠..╠ ╠╗╠╝.║╠ ╠╝║║║╚╗

╩═╚╝║.╚╝.╚╝║..╚╝║║╚╝.╩╚╝╚╝║.║╚╝

Got Item?
Terminal Dogma
Meowniversal Ltd.
#7 - 2012-07-07 01:25:01 UTC
Entity wrote:

Well, the only things I've done to my library since release were bugfixes for CCP's inconsistencies and changes. Typically the library needed no changes for new functionality, and they've expanded the api considerably since its creation.

I'll admit to my method being a bit arcane and requiring external documentation and knowledge of the EVE API for it to be useful. As you pointed out, it is a trade-off. Also, I'd hate to do all the validation in my code when I can just let the server complain about it and throw an exception instead (I'm lazy)

It's all moot anyway because the current API is pretty much at the end of its life, with the CREST API just around the corner. It'll prolly be a while before it offers the same information, though.


Ah, cool, I was not aware of CREST. Looks like it will be nice when its ready.
Raketefrau
ConHugeCo
#8 - 2012-07-14 21:37:05 UTC
Any chance you could post a couple of examples of usage?

Almost all of my python work so far has been scripting, so I'm a bit confused on how things are returned in this API.

By that I mean "I write crappy code." Could you post an example of, say, getting research jobs or industry jobs?
Nomad I
University of Caille
Gallente Federation
#9 - 2012-07-27 17:44:49 UTC  |  Edited by: Nomad I
Entity wrote:
Terminal Dogma wrote:
Entity wrote:
I like the name.

I don't really like the hardcoded methods, though. I prefer my black magic voodoo approach :)


Thanks. Can you explain that a little bit more? As opposed to "hardcoded" methods, are you suggesting that the wrapper not have any specific knowledge of API methods and require the user to pass in the API method URL for each call?


Sort of. I'm using python's __getattr__ and friends to handle the magic in my api module.

https://github.com/ntt/eveapi




I'm not a professional with Python and the architectture of eveapi.py impressed me. Even a

result = getattr(api.auth,'corp/WalletTransactions')(**parameters)

is working. Are you able or willing to explain the magic you have done? I understand the concepts of __getattr__ and __call__ but your handling of the context classes is very special.