From david.crisp at gmail.com Thu Apr 19 19:32:39 2018 From: david.crisp at gmail.com (David Crisp) Date: Fri, 20 Apr 2018 09:32:39 +1000 Subject: [melbourne-pug] Fronius API and Python - queries about a third party module. Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jni.soma at gmail.com Thu Apr 19 21:10:53 2018 From: jni.soma at gmail.com (Juan Nunez-Iglesias) Date: Fri, 20 Apr 2018 11:10:53 +1000 Subject: [melbourne-pug] Fronius API and Python - queries about a third party module. In-Reply-To: References: Message-ID: <1524186653.3968656.1344359024.643FD4FE@webmail.messagingengine.com> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.crisp at gmail.com Thu Apr 19 23:24:25 2018 From: david.crisp at gmail.com (David Crisp) Date: Fri, 20 Apr 2018 13:24:25 +1000 Subject: [melbourne-pug] Fronius API and Python - queries about a third party module. In-Reply-To: <1524186653.3968656.1344359024.643FD4FE@webmail.messagingengine.com> References: <1524186653.3968656.1344359024.643FD4FE@webmail.messagingengine.com> Message-ID: 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 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: From daryl at commoncode.io Fri Apr 20 02:07:30 2018 From: daryl at commoncode.io (Daryl Antony) Date: Fri, 20 Apr 2018 06:07:30 +0000 Subject: [melbourne-pug] Common Code & Infoxchange Roles. Peer 2 Peer Learning Night 1st Thursday of the Month in 2018 Message-ID: Hello python people, A couple of announcements from Common Code. + Common Code is seeking staff from capable mid-level to senior developers with strong backgrounds in python and/or javascript + Additionally, we have contract roles for similarly skilled folks + Personally, I'm helping Infoxchange to recruit a mid-level web-developer with a Django background and a full-stack mindset. Really great social impact focused company in Richmond. Please email work at commoncode.io if that sounds like you. + We had a really nice MelbDjango meetup last night https://twitter.com/MelbDjango/status/986895468108988416 - plenty of familiar and new faces. Great pizza and drinks in our garage bar and plenty of socializing. 3rd Thursday of every month; you can count on it. It's been running over 5 years now :) https://twitter.com/DarylAntony/status/986904920363220992 Join here. https://www.meetup.com/melbdjango/ We're at 960 members, the 1000th member is going to get a sweet prize! We're also running a Peer 2 Peer Learning Night on the 1st Thursday of each month in 2018. It's Django based, but we've branched out to web-development and agile concepts in general. A great mix of people have been attending; and you'll be fed Rita's pizza and local micro-brewery keg beer. https://www.meetup.com/MelbDjango/events/trlznpyxhbfb/ Thanks for everything MPUG. ~ Daryl, Common Code. -- ~ Daryl -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew.wakefield at wehi.edu.au Thu Apr 19 20:31:42 2018 From: matthew.wakefield at wehi.edu.au (Matthew Wakefield) Date: Fri, 20 Apr 2018 00:31:42 +0000 Subject: [melbourne-pug] Fronius API and Python - queries about a third party module. In-Reply-To: References: Message-ID: <231AC99A-5EBE-48A9-9BE1-57BE66579C3D@wehi.edu.au> Two quick comments that are not really on topic so will send directly. Any reason not to use sunspec modbus TCP? This would be more generic and the libraries may reflect the broader use case. Victron code is open source and they interact a lot with Fronius. (Their controller is a raspberry pi like Linux box, but they do use hard tabs in their python code) I have not dived into the nitty gritty yet, but after my system goes in later this quarter I plan to write some solar/battery/heating-cooling time of use charge aware code. --=-=--=-=--=-=--=-=--=-=-- Matthew Wakefield matthew at wakefield.id.au +61 402 916 018 > On 20 Apr 2018, at 9:33 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 From ed at pythoncharmers.com Wed Apr 25 17:56:52 2018 From: ed at pythoncharmers.com (Ed Schofield) Date: Thu, 26 Apr 2018 07:56:52 +1000 Subject: [melbourne-pug] Speakers wanted! Message-ID: Hi everyone! We're looking for more speakers for the Melbourne Python user group (in May and beyond). This is an opportunity to connect with the Python community, get the word out about something important, or get feedback. You may be interested if ... You're working on an interesting Python-related project that the world should know about? You've discovered an amazing new Python-related tool recently? You'd like to share your experiences learning Python ... or using it in your workplace? You'd like a trial run for a potential talk at PyCon AU in August? If so .. please let me (or the list) know! Best wishes, Ed -- Dr. Edward Schofield Python Charmers http://pythoncharmers.com -------------- next part -------------- An HTML attachment was scrubbed... URL: