>> The worst was ibm_db.
>
> Absolutely agree. You are not imagining it, and the problem isn't
> simply being "insufficiently acclimated" to the Python ecosystem.
FWIW, I think the ibm_db interface was copied directly from PHP. When it
does seemingly idiotic things like:
ibm_db.set_option(obj, options, type)
where obj can be a connection or statement object and type must be 0 or 1
depending on whether it's a statement or connection. Then of course the C
code checks what the actual type of obj is and ensures it matches what you
said it was (and whether it was really an ibm_db statement or connection
object), ie. totally redundant, but probably necessary for PHP (at least
at one point, can't speak of current PHP limitations). I've also seen
comments in the source code for fetch_array, but it was renamed to
fetch_tuple to match Python terminology which gives even more hints that
the API started its life in a different language.
Thankfully, there's ibm_db_dbi to hide all this awfulness from the
programmer. :)
Kevin Adler
Software Development - PASE, Open Source, IBM i Access ODBC
IBM Systems, Dept 47U
Phone: +1-507-253-5111
Email: kadler@xxxxxxxxxx
015-3 C117
3605 HWY 52 N
Rochester, MN 55901-1407
United States
----- Original message -----
From: John Yeung <gallium.arsenide@xxxxxxxxx>
Sent by: "OpenSource" <opensource-bounces@xxxxxxxxxxxx>
To: IBMi Open Source Roundtable <opensource@xxxxxxxxxxxx>
Cc:
Subject: Re: [IBMiOSS] Python 2 on IBM i 7.3 experience report
Date: Wed, Mar 8, 2017 7:33 PM
On Wed, Mar 8, 2017 at 12:02 PM, Buck Calabro <kc2hiz@xxxxxxxxx> wrote:
> I wanted to see how the 'as shipped' 5733-OPS would feel.
> And so, it never occurred to me to even /try/ the PASE python3
command.
> In fact I only knew I was using Python 2.7 because python --version
> reported 2.7.11
Makes sense, though in some configurations, the "python" (with no
number) command will bring up Python 3. This is the case in a few
Linux distributions as well as the current Python Litmis Space (though
Aaron's working on a Python-2-based space).
> Python has really nice docs. Very friendly to the 'brute force and
> ignorance' learner :-)
I like them too. It's one of the things that attracted me to the
language. I get that different people learn differently, but I'm
always surprised and a little dismayed when someone goes "OK, I've
just downloaded and installed the latest Python, now where I can I get
me some good Python learning and reference materials?".
> XlsxWriter... so so for me. I sort of prefer the Javadoc-ish format
> where I can easily drill down into the particulars. This doc is more
> task oriented which would be great if I had any idea what task I
wanted
> to accomplish. I have a strong tendency to browse the doc API by API,
> which might be excessive for most people. Might be. :-)
I agree those docs are more task-oriented, but they do have an API
section kind of buried in the middle, immediately following the
tutorials and before the "Working with..." chapters. Perhaps it would
be helpful to have one more layer of organization, splitting the book
into three or four sections instead of one vast sea of chapters.
Granted, even the API chapters are pretty "talky" rather than a (dry
or programmatic) dump of the signatures and docstrings.
FWIW, Python does include Pydoc, which is roughly analogous to
Javadoc. And when you're at the interactive prompt, you can use help()
and dir() to get a lot of information.
> The worst was ibm_db.
Absolutely agree. You are not imagining it, and the problem isn't
simply being "insufficiently acclimated" to the Python ecosystem.
[Re: Python's unsuitability as a subprocedure language for
dyed-in-the-wool RPG programmers]
> I am an IBM i programmer coming
> to Gnu. My brain has decades of 'if a program goes awry, it throws an
> exception and the caller needs to deal with it'. I don't expect that
> PASE or Python will go casters up; the far more likely scenario is an
> authority issue - the user profile isn't authorised to the table it's
> trying to read.
>
> If I were doing this in RPG/CL, I'd have the RPG program send a
*ESCAPE
> message to *CALLER. The CLP would do a MONMSG and take the
appropriate
> action, which might even be sending a *ESCAPE message to *CALLER.
Right. IBM i has extensive operating-system-level support for error
messages. This is definitely one of the strengths of the platform, and
something that is much more developed and robust than what you'll find
in Windows or the Unix-likes. All I can say to that is: Python has
very rich and extensive language-level support for error messages. So
you can take your "closed loop" thinking with you into Python,
including your modular architecture, if you're willing to stay in
Python once you're there.
John Y.
--
This is the IBMi Open Source Roundtable (OpenSource) mailing list
To post a message email: OpenSource@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: [1]
http://lists.midrange.com/mailman/listinfo/opensource
or email: OpenSource-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at [2]
http://archive.midrange.com/opensource.
References
Visible links
1.
http://lists.midrange.com/mailman/listinfo/opensource
2.
http://archive.midrange.com/opensource
midrange.com
