[melbourne-pug] Fronius API and Python - queries about a third party module.

[David Crisp]

Hi Juan,

Thank you for that analysis,  it has given me another perspective.  I was
going to contact the original author but wanted to see which of the things
I saw were actually something i should be asking about.

One of the things I am trying to do here is practice writing my own
modules.    Luckily the Fronius API is actually well documented.  (When
compared to many other APIs that are out there)

Let me write the module first before offering to give a talk on it :)

Regards,
David


On 20 April 2018 at 11:10, Juan Nunez-Iglesias <jni.soma at gmail.com> wrote:

> Hi David,
>
> The __init__ design is certainly unusual. The original author does seem to
> welcome contributions as pull requests, so if you feel like you can improve
> the layout, I suggest you go for it! My guess is that they felt that it is
> a small enough file that they couldn't be bothered doing it "the right way".
>
> Regarding asyncio vs requests, it looks like it originally was indeed
> requests! The relevant change happened Jan 3 amid not much discussion:
> https://github.com/nielstron/pyfronius/pull/1
>
> I've never truly grokked asyncio but this *is* in fact the kind of use
> case that it was designed for: to enable responsive applications when
> running IO operations that may or may not take a while. (I don't know how
> fast/reliable the inverter API is?) So I imagine that this was a useful
> change for the use cases discussed in that PR.
>
> iirc converting an async coroutine to a regular blocking call is easy:
> loop = asyncio.get_event_loop()
> loop.run_until_complete(my_coroutine(args)).
>
> So, it's a bit more cumbersome, but you can still get the info you need —
> and you can of course wrap this all in your own API that is more
> "traditional".
>
> All of this is written from an outsider's perspective. The beauty of open
> source is in its openness though! So I recommend you raise an issue in the
> GitHub repo, and get answers straight from the horse's mouth, so to speak.
>
> And, in the worst case, the whole commit history is there, and it's MIT
> licensed, so you can just grab the earlier requests version and roll your
> own package, "simplefronius", so to speak. I would normally discourage this
> approach but the code is tiny enough that I think it would be ok here. This
> kind of "vendoring" goes on all the time in the BSD/MIT world, because too
> many dependencies for small things are a liability. (Google "left-pad" for
> more.)
>
> Good luck! We look forward to your MPUG talk about your experiences with
> this! =)
>
> Juan.
>
>
> On Fri, Apr 20, 2018, at 9:32 AM, David Crisp wrote:
>
> A couple of questions to the more experienced Python developers here.
> I have been working with my Fronius Symo solar inverter to extract data
> from the onboard API.   It's actually a reasonably simple process of making
> a web request and then processing the resulting JSON.
> There is one third party module, pyfronius, that has been written already
> that sort of performs these requests, but when I look inside the code I
> find myself asking lots of whys.    There are a couple of things that the
> author has done that don't seem Pythonic  and I was wondering if somebody
> could help clear up my thoughts.
>
> The two things I have noticed that I want to query
>
> 1)  Everything in the __init__.py
> 2)  Using Asynchronous web calls to the API
> Everything in the __init__.py file:
> The functional part of the module consists of a single __init__.py file.
> All the code is in this file.  My understanding of the usage of this file
> is to provide a layout of the actual code files and perform global imports
> etc.  The __init__.py references online never talk about putting actual
> code in there.   Putting code in the file doesn't seem to be the right
> thing to do.      I have seen this a couple of times with more obscure
> modules and my uninformed gut instinct is to say that the developer didnt
> quite know what they were doing.
>
> Using Asynchronous web calls to the API:
> The developer has used the asyncio module to perform the web queries and
> has used a lot of @asyncio.coroutine functions throughout the code.
> This doesn't seem... right for a module that simply goes to the web server
> and says "gime what you got... hmm.. yup.. thanks"
> This one is a little more along the lines of "developer choice"  I think
> the method chosen overly complicates the design of the module.
> It seems something like requests could have been a better choice of module
> to use.
>
> Now,  I'm not trying to point fingers at the original developer.  There
> may be perfectly logical and sensible and Pythonic reasons for doing what
> they have done.    I'm hoping a more experienced developer can hypothesis.
> I am writing my own module to talk to the inverter.  Originally it was
> based on pyfronius but I have found myself completely reworking the methods
> to try and add exception handling and layout the code in a slightly better
> layout.
> I would be interested to know other peoples comments about the style..
> David
> *_______________________________________________*
> melbourne-pug mailing list
> melbourne-pug at python.org
> https://mail.python.org/mailman/listinfo/melbourne-pug
>
>
>
> _______________________________________________
> melbourne-pug mailing list
> melbourne-pug at python.org
> https://mail.python.org/mailman/listinfo/melbourne-pug
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/melbourne-pug/attachments/20180420/e2c3fde6/attachment-0001.html>