Greetings folks!
Is anyone on this forum doing any work in Python? Are you converting current source code into Python?
THX!
~Doc
------------------------------
Doc Ruckel
Part time programmer
Rocket Forum Shared Account
------------------------------
Yes, lots of Python: but only where it makes sense to do so.
Generally where it's adding value, performing things that are more tiresome in UniBasic or leveraging packages. In some cases for improved performance, but again that is specific.
So to your second question, no, not looking to convert existing code to Python unless there is a clear and obvious reason for doing so. I have tools for converting UniBasic to other languages (e.g. C#) that I've used on occasion, but I haven't targeted them to Python.
It's another very useful tool in the chest alongside the existing ones.
------------------------------
Brian Leach
Director
Brian Leach Consulting
Chipping Norton GB
------------------------------
Yes, lots of Python: but only where it makes sense to do so.
Generally where it's adding value, performing things that are more tiresome in UniBasic or leveraging packages. In some cases for improved performance, but again that is specific.
So to your second question, no, not looking to convert existing code to Python unless there is a clear and obvious reason for doing so. I have tools for converting UniBasic to other languages (e.g. C#) that I've used on occasion, but I haven't targeted them to Python.
It's another very useful tool in the chest alongside the existing ones.
------------------------------
Brian Leach
Director
Brian Leach Consulting
Chipping Norton GB
------------------------------
Brian,
Deeply appreciate your timely reply.
If I may ask, what criteria do you use to determine "Generally where it's adding value, performing things that are more tiresome in UniBasic".
I have only cursory exposure to Python so interested to know what things in a Pick environment is Python less tiresome than UniBasic.
Thanks in advance for your helpful replies!
~Doc
Yes, lots of Python: but only where it makes sense to do so.
Generally where it's adding value, performing things that are more tiresome in UniBasic or leveraging packages. In some cases for improved performance, but again that is specific.
So to your second question, no, not looking to convert existing code to Python unless there is a clear and obvious reason for doing so. I have tools for converting UniBasic to other languages (e.g. C#) that I've used on occasion, but I haven't targeted them to Python.
It's another very useful tool in the chest alongside the existing ones.
Brian,
Deeply appreciate your timely reply.
If I may ask, what criteria do you use to determine "Generally where it's adding value, performing things that are more tiresome in UniBasic".
I have only cursory exposure to Python so interested to know what things in a Pick environment is Python less tiresome than UniBasic.
Thanks in advance for your helpful replies!
~Doc
Yes, lots of Python: but only where it makes sense to do so.
Generally where it's adding value, performing things that are more tiresome in UniBasic or leveraging packages. In some cases for improved performance, but again that is specific.
So to your second question, no, not looking to convert existing code to Python unless there is a clear and obvious reason for doing so. I have tools for converting UniBasic to other languages (e.g. C#) that I've used on occasion, but I haven't targeted them to Python.
It's another very useful tool in the chest alongside the existing ones.
The best use I've found for using python is the excel creation library that can be included. With that, you can generate Excel spreadsheets with just about any feature you want: fonts, colors, column-widths, ...
------------------------------
Marcus Rhodes
marcus1@thinqware.com
------------------------------
Brian,
Deeply appreciate your timely reply.
If I may ask, what criteria do you use to determine "Generally where it's adding value, performing things that are more tiresome in UniBasic".
I have only cursory exposure to Python so interested to know what things in a Pick environment is Python less tiresome than UniBasic.
Thanks in advance for your helpful replies!
~Doc
Yes, lots of Python: but only where it makes sense to do so.
Generally where it's adding value, performing things that are more tiresome in UniBasic or leveraging packages. In some cases for improved performance, but again that is specific.
So to your second question, no, not looking to convert existing code to Python unless there is a clear and obvious reason for doing so. I have tools for converting UniBasic to other languages (e.g. C#) that I've used on occasion, but I haven't targeted them to Python.
It's another very useful tool in the chest alongside the existing ones.
Doc
A typical example might be anything that is handling complex JSON or XML, since those are more immediate and easy to work with (JSON maps directly onto Python types with a single function) than the UDO or XDOM libraries. Naturally I already have libraries in UniBasic for handling those using mapping definitions, but they are slower.
Handling large volumes of data in memory, which is actually a good use for UDOs (rather than old style dimensioned arrays and lookups) are also better handled through Python types.
Financial calculations where higher levels of precision are required and where standard fincalc libraries exist...
Specific little things like 'I need to generate a guid' ...
...the list goes on.
Some stuff is still better handled through communicating with C# or other quicker languages, especially where peformance, multithreading and complexity are required (Python multithreading is just blech) which is why my products still major on those. But Python is emerging as a simple option for a lot of things.
------------------------------
Brian Leach
Director
Brian Leach Consulting
Chipping Norton GB
------------------------------
Doc
A typical example might be anything that is handling complex JSON or XML, since those are more immediate and easy to work with (JSON maps directly onto Python types with a single function) than the UDO or XDOM libraries. Naturally I already have libraries in UniBasic for handling those using mapping definitions, but they are slower.
Handling large volumes of data in memory, which is actually a good use for UDOs (rather than old style dimensioned arrays and lookups) are also better handled through Python types.
Financial calculations where higher levels of precision are required and where standard fincalc libraries exist...
Specific little things like 'I need to generate a guid' ...
...the list goes on.
Some stuff is still better handled through communicating with C# or other quicker languages, especially where peformance, multithreading and complexity are required (Python multithreading is just blech) which is why my products still major on those. But Python is emerging as a simple option for a lot of things.
------------------------------
Brian Leach
Director
Brian Leach Consulting
Chipping Norton GB
------------------------------
Appreciate you Brian, many thanks for the reply!
~Doc