Re: ANN: Dogelog Runtime, Prolog to the Moon (2021)

[Mostowski Collapse]

The Standard Python version of Dogelog runtime
is annoyingly slow. So we gave it a try with
andother Python, and it was 6x times faster.

We could test GraalVM. We worked around the missing
match in Python 3.8 by replacing it with if-then-else.
Performance is a little better, we find:

/* Standard Python Version, Warm Run */
?- time(fibo(23,X)).
% Wall 3865 ms, gc 94 ms, 71991 lips
X = 46368.

/* GraalVM Python Version, Warm Warm Run */
?- time(fibo(23,X)).
% Wall 695 ms, gc 14 ms, 400356 lips
X = 46368.

See also:

JDK 1.8 GraalVM Python is 6x faster than Standard Python
https://twitter.com/dogelogch/status/1437395917167112193

JDK 1.8 GraalVM Python is 6x faster than Standard Python
https://www.facebook.com/groups/dogelog

Mostowski Collapse schrieb:

Yesterday we went into a little programming binge, despite there
was a free parade in Zurich. We could now already implement a transpiler
that targets Python. We simply took the transpiler main.p that targets

JavaScript and moded it into a new transpiler mainpy.p that targets
Python. The code is already on GitHub and we present it also here
as the Python code mainpy.p. We were also busy

on machine.py and special.py. The progress is now:

++   cross  +-+
| loader.p   |   compile    | loader.py   | 100%
| compiler.p | ---> | compiler.py | 100%
++  +-+
     | machine.py  |  66%
     | special.py  |  33%
     +-+

See also:

Python Version of Dogelog Runtime special
https://twitter.com/dogelogch/status/1426884473988292617

Python Version of Dogelog Runtime special
https://www.facebook.com/groups/dogelog


--
https://mail.python.org/mailman/listinfo/python-list

Discussion forum for typing Q&A and review requests

[Sebastian Rittau]

Typing with Python is hard and constantly evolving. This is why we set 
up a forum to help users with typing at 
https://github.com/python/typing/discussions 
. It's fairly new, but at 
the moment we have two categories for general Q&A and for asking for 
reviews. If you have questions about typing, please join us there or on 
our Gitter channel (https://gitter.im/python/typing 
). If you maintain a typing-related 
package or typing-related documentation, we would be happy if you could 
add a link to the discussions forum to your documentation. Contributors 
to the forum and suggestions on how to improve it are most welcome.


The forum is intended as a help forum. Discussions about new features, 
improvements, and implementation should continue to go to the typing-sig 
list or to the appropriate issue trackers.


- Sebastian

--
https://mail.python.org/mailman/listinfo/python-list

Re: Friday Finking: Contorted loops

[Peter J. Holzer]

On 2021-09-12 17:11:58 -0400, Avi Gross via Python-list wrote:
> Yes, large units of code, and even smaller ones, may be a chore to figure
> out. Arguably harder when you use indentation and the next/last parts are
> not even on the same screen as the rest. Sometimes you want to use a
> split-screen in some editor to line up the two parts or some other
> technique.
> 
> But my suggestion is to COMMENT things well and I mean too much!
> 
> do {
>
>   } while 
> 
> Why not add a comment at the top like:
> 
> # The following loop has a WHILE clause controlling it at the end.
> 
> do { # until the while clause below
>
>   } while  # End of the do loop.

Because those comments don't tell me anything that I as a C programmer
don't already know. Even though do/while loops are relatively rare, I've
seen hundreds of them. Seeing "do {" and recognizing it as the top of a
do/while loop takes absolutely no conscious thought - reading a comment
does.

> My code tends to have brief comments especially when I have nested
> constructs such as multiple nested loops or in sequence, or if statements
> inside others. The comment often looks like
> 
> ... # END of inner if 
> 
> ... # END of outer if

Those are a bit better, but they still don't help much. What is the
"inner if", what is the "outer if"? Chances are that I have to find the
corresponding if to find out - I can do that without a comment, too.

There are end-of-construct comments which I do find useful (at least
occasionally) but those are semantic.

Imagine a somewhat longish function which read several files which are
comprised of records which are comprised of field.

for file in files:

some setup for each file here

for record in file:

some setup for each record here

for field in record:

process field

do some postprocessing for the record

do some postprocessing for the file

If each of these blocks is longer than a few lines you might lose track
where you are, so some comments might help:

for file in files:

some setup for each file here

for record in file:

some setup for each record here

for field in record:

process field

# end of field loop

do some postprocessing for the record

# end of record loop

do some postprocessing for the file

# end of file loop


Note that the comments say which part of the input the loop is
processing, not just that it is the end of a loop or "the outer loop",
"the intermediate loop" and "the inner loop" or some other purely
syntactic information.

(In most cases I would just break up such a function into smaller
functions instead of adding comments, though)

hp

-- 
   _  | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| |   | h...@hjp.at |-- Charles Stross, "Creative writing
__/   | http://www.hjp.at/ |   challenge!"


signature.asc
Description: PGP signature
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: ANN: Dogelog Runtime, Prolog to the Moon (2021)

[Terry Reedy]

On 9/13/2021 8:46 AM, Mostowski Collapse wrote:

The Standard Python version of Dogelog runtime
is annoyingly slow. So we gave it a try with
andother Python, and it was 6x times faster.

We could test GraalVM. We worked around the missing
match in Python 3.8 by replacing it with if-then-else.
Performance is a little better, we find:

/* Standard Python Version, Warm Run */
?- time(fibo(23,X)).
% Wall 3865 ms, gc 94 ms, 71991 lips
X = 46368.

/* GraalVM Python Version, Warm Warm Run */
?- time(fibo(23,X)).
% Wall 695 ms, gc 14 ms, 400356 lips
X = 46368.

See also:

JDK 1.8 GraalVM Python is 6x faster than Standard Python
https://twitter.com/dogelogch/status/1437395917167112193

JDK 1.8 GraalVM Python is 6x faster than Standard Python
https://www.facebook.com/groups/dogelog


You need to test more than fibonacci to make that claim.  There is a 
benchmark test that times around 40 different similarly small benchmarks.



--
Terry Jan Reedy

--
https://mail.python.org/mailman/listinfo/python-list

RE: Friday Finking: Contorted loops

[Avi Gross via Python-list]

Peter,

Choosong when and how to comment is an invidual thing and certainly the
interpreter does not care.

Yes, I gave an example where my comment used inner/outer as the words but
more often I am more explicit along the lines you mention. Sometimes I
include most of the text into the comment such as
if x <10 {
... MANY LINES
} # END if x <10

But please understand the goal is many fold. One simple goal is that by
having to comment the code, you sort of have to explain it to yourself and
use the opportunity to see if it makes sense and matches any requirements or
perhaps even adds new functionality not already documented. 

Secondarily, it is for you to read much later when returning to the code to
refresh your memory.

In many organizations, including where I worked, there can be levels of code
review that work better if others have a clue what they are reviewing or
why.

And of course, others often take over your code or examine it.

At one point I was doing field support on a project, way back when it meant
something to carry a beeper. I had written some of the code but the vast
majority was done by others on the team. When I got beeped at 3 AM from a
place like Japan, I often had to make rapid decisions on how big a problem
was and whether I should wake someone up, including developers and their
management or even rarely upper management. I often dove into the code to
find the likely locus of a problem and even to see if I could spot the place
that might be patched. That often let me wake up the right person and work
with them to expedite an emergency change. Even in less chaotic or major
times, I had to work with getting a problem acknowledged and scheduled for
inclusion in a future release. Being able to read all kinds of source code
and figuring it out quickly was important and sometimes comments were
helpful. In particular, some people did not need to be woken up if I was
able to see the problem was not in their code!

Comments do often have a rather weird purpose. Sometimes we collected
metrics on how many lines of code were new or changed between releases and
unless the tools removed comments, ...

But I have found over the years that too many comments are badly done. For
example, rather than ending every line of a function definition with all
kinds of things that clutter things, it is often better to place a few block
comments above a function definition explaining the general purpose of the
function, what inputs are expected on the command line, what assumptions are
made about them, whether it uses any other resources (including dreaded
global variables) and what it returns or what errors it may generate and so
on. You can also discuss the overall idea of how the function does the job.
Then, within the function, you can have smaller mainly one-liners like:
   #  This section checks if the variables are all within expected bounds.
   ...
   # Combine ...
   ...
   # quit if not satisfied
   ...
   # Make the changes requested.
   ...
   # return successfully with a structure holding ...
   ...

Again individual taste. My personal commenting style has evolved and varies
from language to language. In many cases, I have used well-chosen variable
names that are meaningful to me but not keywords. Sadly for some others, I
sometimes choose variable names in other human languages, sometimes
transliterated as sticking to ASCII requires. Most people are not able to
even guess, so say commenting in Hungarian or German or Hebrew may only be
of use to me and other weird people.

I do find that for frequent enough usage of something, such as an object
like a deque, you get to know it so well that you may stop commenting on how
you are using some built-in feature as it seems routine.

-Original Message-
From: Python-list  On
Behalf Of Peter J. Holzer
Sent: Monday, September 13, 2021 3:28 PM
To: python-list@python.org
Subject: Re: Friday Finking: Contorted loops

On 2021-09-12 17:11:58 -0400, Avi Gross via Python-list wrote:
> Yes, large units of code, and even smaller ones, may be a chore to 
> figure out. Arguably harder when you use indentation and the next/last 
> parts are not even on the same screen as the rest. Sometimes you want 
> to use a split-screen in some editor to line up the two parts or some 
> other technique.
> 
> But my suggestion is to COMMENT things well and I mean too much!
> 
> do {
>
>   } while 
> 
> Why not add a comment at the top like:
> 
> # The following loop has a WHILE clause controlling it at the end.
> 
> do { # until the while clause below
>
>   } while  # End of the do loop.

Because those comments don't tell me anything that I as a C programmer don't
already know. Even though do/while loops are relatively rare, I've seen
hundreds of them. Seeing "do {" and recognizing it as the top of a do/while
loop takes absolutely no conscious thought - reading a comment does.

> My code tends to have brief comments especially when I have nested 
> constructs such as mul