Mailing List Archive

I think I already agreed with much of your point. That is indeed the
problem. You are allowed to do some possibly non-standard things. A static
evaluation/replacement may show the wrong function being called and a
dynamic one may still mess up as there are many ways to do indirection.

I mention this partially because of a recent discussion on another computer
where the question was why they got an error message that the object being
given a function was not a data.frame or something compatible. What was
being passed was a data structure meant to hold some simulation of an EXCEL
spreadsheet. Not quite the same. But they insisted it had to be a data.frame
because they called functionA() and it is documented to return a data.frame.


It turned out that they had loaded lots of packages (modules but not) and
had not paid attention when they got a message that one function called
functionA was now being covered by another with the same name. Each such
package loaded often gets a new namespace/environment and when searching for
a function by name, the new package was ahead of the older package, hence
the warning.

So one solution was to change his code in one of several ways, but more
generally to call any functions that may be hidden this way in a fully
qualified manner as in packageA::functionA(...) do you do not accidentally
get package::functionA(...)

Now note this is not so much a bug as a feature in that language and It is
quite common to sort of redefine a function name to do what you want.

But if you have developed your own package and want to guarantee the user
does not undo your work in specific cases, you should also call some things
as explicitly within your own namespace.

Back to Python, it is a tad too flexible in some places and my point was
that it would be interesting, along the lines of a linter, to have some
tools that help explain what the program might be doing a tad more
explicitly. But as an interpreted language, so much can happen at runtime
that this may not be very effective or accurate. The language is full of
places where slipping in another object means you over-rode the meaning of
+= for instance.

-----Original Message-----
From: Python-list <python-list-bounces+avigross=verizon.net@python.org> On
Behalf Of Richard Damon
Sent: Tuesday, September 7, 2021 10:09 PM
To: python-list@python.org
Subject: Re: on writing a while loop for rolling two dice

On 9/7/21 3:51 PM, Avi Gross via Python-list wrote:
> and similarly changes any function imported directly to also be fully
> qualified.

One danger with this is that it can actual change the behavior of the
program. Maybe more likely with global objects than functions, but still an
issue.

Remember, "from module import fun" will bind the name fun in this modules
namespace to the current definiton of the object fun in the other modules
name space. If after that point, something rebinds the name in the other
module, the module that did the from import won't see that change, but if
the reference is changed to module.fun, it will.

Since that rebinding might even be some third module doing a 'monkey patch',
detecting if it is safe is basically impossible.

Admittedly, if this is an issue, the sensitivity to timing makes the
difference something very fussy to exactly the order you do things, the
cases where the difference is intended is likely fairly small.

--
Richard Damon

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

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

On 2021-09-08, charles hottel <chottel@earthlink.net> wrote:

> So what do yoy think or feel about a language like RATFOR (Rational
> FORTRAN) which was implemented as macros? Should they instead have
> simply adapted themselves to FORTRAN?

That's an interesting question. If the langauge is complete,
well-defined, and well-documented then it's not that much different
than any other source language than gets translated into a lower level
language (e.g. C -> assembly). My recollection of RATFOR was that it
provided enough signifcant "features" that weren't available in the
underlying FORTRAN to make it worthwhile.

That seems to me to be qualitatively different than a set of macros
that simply make one language look (somewhat) like a different
language with a similar level of abstraction -- without providing
anything other than cosmetic changes.

--
Grant

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

On 2021-09-08, charles hottel <chottel@earthlink.net> wrote:

> So what do yoy think or feel about a language like RATFOR (Rational
> FORTRAN) which was implemented as macros?

The RATFOR implementations I've seen weren't done using macros. It was
a preprocessor, yes. But it generates code for the various structured
statement types (while, for, if/then/else) and source structures
(open/close brace) the way a compiler does, even though the generated
code is FORTRAN66 rather than assembly or bytecode or whatever.

> Should they instead have simply adapted themselves to FORTRAN?


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

On Wed, 8 Sep 2021 00:24:44 +0100, Alan Gauld via Python-list
<python-list@python.org> declaimed the following:

>
>That was quite common in C before it became popular(early/mid 80s).
>I've seen Pascal, Algol and Coral macro sets in use.
>You could even download pre-written ones from various
>bulletin boards (remember them?!) for a while.

And if one wants to expose themselves to real horror -- look at the
output of one of those "structured FORTRAN" preprocessors (RATFOR, TEXTFOR,
others) that were cropping up in the late 70s to generate FORTRAN-IV from
code written with block IF, WHILE, etc.

I spent close to 20 years (80s-90s) maintaining the /output/ of such a
preprocessor. The software had apparently originated with a sub-contractor,
and we did not have access to their preprocessor (and/or no one ported it
to the VAX-11 from PDP-11).

At first my practice was to study a file in detail, and then rewrite it
using F77 with separately compiled subroutines (the preprocessor was "one
file per program" and implemented BASIC-style GOSUB, relying on shared
variables and ASSIGNed GOTO for the return address -- I had to move the
shared variables to COMMON blocks to make separate subroutines usable).

By the end of those decades, I'd been exposed to the preprocessor
enough to hand-write smaller patches within its style. The only good thing
is that is left the structured source as comments, and tended to
right-justify the F-IV output, so easy to locate...



--
Wulfraed Dennis Lee Bieber AF6VN
wlfraed@ix.netcom.com http://wlfraed.microdiversity.freeddns.org/

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

On 2021-09-08, Dennis Lee Bieber <wlfraed@ix.netcom.com> wrote:

> I spent close to 20 years (80s-90s) maintaining the /output/ of such
> a preprocessor.

Ouch. I hope it paid well. ;)

Back when I did a lot of TeX/LaTeX stuff on VMS, I used to make
occasional fixes and add (very minor) features to one of the dvi
handling executables (I don't remember if it was the VT2xx previewer,
or the laser-printer "driver") using the VMS "PATCH" utility. I also
can't remember how we ended up without source code for that piece of
the toolchain when we build all of the reset of it from source.

> The software had apparently originated with a sub-contractor, and we
> did not have access to their preprocessor

Allowing that to happen is definitely a major management F*%k-up for
which somebody should have had their career ended.

> (and/or no one ported it to the VAX-11 from PDP-11).

I would have though that would have been pretty trivial compared to
maintaining the output source for 20 years.

--
Grant




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

On Wed, 8 Sep 2021 14:46:28 -0000 (UTC), Grant Edwards
<grant.b.edwards@gmail.com> declaimed the following:

>On 2021-09-08, charles hottel <chottel@earthlink.net> wrote:
>
>> So what do yoy think or feel about a language like RATFOR (Rational
>> FORTRAN) which was implemented as macros? Should they instead have
>> simply adapted themselves to FORTRAN?
>
>That's an interesting question. If the langauge is complete,
>well-defined, and well-documented then it's not that much different
>than any other source language than gets translated into a lower level
>language (e.g. C -> assembly). My recollection of RATFOR was that it
>provided enough signifcant "features" that weren't available in the
>underlying FORTRAN to make it worthwhile.
>

Primarily providing block structured IF/ELSE and loops -- in a language
that only really provided IF/GOTO...

My college tried using one of these (for some reason the name TextFOR
sticks with me)... The experiment only lasted one term. The preprocessor
ate CPU and I/O time -- with the result that the FORTRAN class used two or
three times the times of the COBOL class! (The native compilers were
designed as re-entrant, allowing multiple compiles to share one in-core
image; the preprocessor no doubt ran as one image per compile, triggering
lots of page swapping to disk)


--
Wulfraed Dennis Lee Bieber AF6VN
wlfraed@ix.netcom.com http://wlfraed.microdiversity.freeddns.org/

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

Charles,

This forum is for python discussions so I will clarify that there is nothing
wrong with making up a new language, including by bootstrapping an old
language. But why not call it new and do not try to confuse people using the
old.

Python has grown and added much over the years and even had a fairly
negative experience in a transition from versions 2 to 3 as some people
complain their old software no longer works.

If you look at a language like C which was remade into C++, guess what? It
has a new name and makes no claims to be fully compatible.

If RATFOR was a more pleasant programming environment for some people and
purposes, fine.

I note Python has many modules that for some people become the most used
parts even when the base language might allow some similar functionality.
Someone who learns python but has never experienced those, may feel a bit
lost. And you can customize Python to a point where it does things in fairly
hidden ways too. There are no promises of purity.

What this particular discussion began with was much lower level and about
various ways of writing a while loop within very basic Python and seems to
be heading away into discussions of other languages. I happen to enjoy
learning and contrasting lots of languages but doubt many others do and most
people want to learn just a few good tools and use them to get their job
done. My point was if you have a tool you like and you try another you
don't, then rather than trying to force the new one, just use what works and
leave others that like it alone. Make your own religion and let others keep
theirs.

However, improvements and increased functionality may be more welcome, than
examples where the interface was changed with no benefits.

-----Original Message-----
From: Python-list <python-list-bounces+avigross=verizon.net@python.org> On
Behalf Of charles hottel
Sent: Tuesday, September 7, 2021 11:31 PM
To: python-list@python.org
Subject: Re: on writing a while loop for rolling two dice

<SNIP>

So what do yoy think or feel about a language like RATFOR (Rational
FORTRAN) which was implemented as macros? Should they instead have simply
adapted themselves to FORTRAN?
--
https://mail.python.org/mailman/listinfo/python-list

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

On Wed, 8 Sep 2021 16:32:45 -0000 (UTC), Grant Edwards
<grant.b.edwards@gmail.com> declaimed the following:

>On 2021-09-08, Dennis Lee Bieber <wlfraed@ix.netcom.com> wrote:
>
>> I spent close to 20 years (80s-90s) maintaining the /output/ of such
>> a preprocessor.
>
>Ouch. I hope it paid well. ;)

Only if one ignores the bloody cost of apartments (given the rent paid
over the 30 years I spent in that 1BR 680sq.ft. unit I should have owned
it, if not half the facility <G>)
>
>> The software had apparently originated with a sub-contractor, and we
>> did not have access to their preprocessor
>
>Allowing that to happen is definitely a major management F*%k-up for
>which somebody should have had their career ended.
>
For all I know, someone might have... Back when the application was
running on PDP-11 (I joined the program early 80s, when the "mission
planning" software was being ported to the VAX-11).

Most of the "mission planning" software was local-grown, so was DEC
FORTRAN (may have started as F-IV, and developed F77 during maintenance and
the porting to the VAX). Not the part I maintained -- which drove a Ramtek
9300 graphics engine (only one engine could be installed into a VAX, it was
that archaic). It got to the point where I think Ramtek service was
recycling the parts when ever we had a service call. Eventually I proposed
that a VAXstation (DECWindows) and GKS could replace most of the display
side. We weren't approved to rewrite the application to directly display --
but rewriting the Ramtek library to send the plotting data to a separate
program, which managed the display window, was in the budget.

>
>I would have though that would have been pretty trivial compared to
>maintaining the output source for 20 years.

I'm not so sure -- that "one file per executable" would have led to
long compile times (first for the preprocessor, then for the generated F-IV
output), vs my rewrites into multiple files, where only isolated changes
needed to be recompiled.

Humorously, the graphics application suite was known as "MESS" (I can't
go deeper into the acronym without violating security classification).


--
Wulfraed Dennis Lee Bieber AF6VN
wlfraed@ix.netcom.com http://wlfraed.microdiversity.freeddns.org/

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

On 31/08/2021 01.50, Chris Angelico wrote:
> On Mon, Aug 30, 2021 at 11:13 PM David Raymond <David.Raymond@tomtom.com> wrote:
>>
>>> def how_many_times():
>>> x, y = 0, 1
>>> c = 0
>>> while x != y:
>>> c = c + 1
>>> x, y = roll()
>>> return c, (x, y)
>>
>> Since I haven't seen it used in answers yet, here's another option using our new walrus operator
>>
>> def how_many_times():
>> roll_count = 1
>> while (rolls := roll())[0] != rolls[1]:
>> roll_count += 1
>> return (roll_count, rolls)
>>
>
> Since we're creating solutions that use features in completely
> unnecessary ways, here's a version that uses collections.Counter:
>
> def how_many_times():
> return next((count, rolls) for count, rolls in
> enumerate(iter(roll, None)) if len(Counter(rolls)) == 1)
>
> Do I get bonus points for it being a one-liner that doesn't fit in
> eighty characters?


Herewith my claim to one-liner fame (assuming such leads in any way to
virtue or fame)

It retains @Peter's preference for a more re-usable roll_die() which
returns a single event, cf the OP's roll() which returns two results).


import itertools, random

def roll_die():
while True:
yield random.randrange(1, 7)

def how_many_times():
return list( itertools.takewhile( lambda r:r[ 0 ] != r[ 1 ],
zip( roll_die(), roll_die() )
)
)

Also, a claim for 'bonus points' because the one-liner will fit within
80-characters - if only I didn't have that pernicious and vile habit of
coding a more readable layout.

It doesn't use a two-arg iter, but still rates because it does use a
relatively-obscure member of the itertools library...


https://docs.python.org/3.8/library/itertools.html#itertools.takewhile
--
Regards,
=dn
--
https://mail.python.org/mailman/listinfo/python-list

On Sat, Sep 11, 2021 at 3:26 PM dn via Python-list
<python-list@python.org> wrote:
>
> On 31/08/2021 01.50, Chris Angelico wrote:
> > On Mon, Aug 30, 2021 at 11:13 PM David Raymond <David.Raymond@tomtom.com> wrote:
> >>
> >>> def how_many_times():
> >>> x, y = 0, 1
> >>> c = 0
> >>> while x != y:
> >>> c = c + 1
> >>> x, y = roll()
> >>> return c, (x, y)
> >>
> >> Since I haven't seen it used in answers yet, here's another option using our new walrus operator
> >>
> >> def how_many_times():
> >> roll_count = 1
> >> while (rolls := roll())[0] != rolls[1]:
> >> roll_count += 1
> >> return (roll_count, rolls)
> >>
> >
> > Since we're creating solutions that use features in completely
> > unnecessary ways, here's a version that uses collections.Counter:
> >
> > def how_many_times():
> > return next((count, rolls) for count, rolls in
> > enumerate(iter(roll, None)) if len(Counter(rolls)) == 1)
> >
> > Do I get bonus points for it being a one-liner that doesn't fit in
> > eighty characters?
>
>
> Herewith my claim to one-liner fame (assuming such leads in any way to
> virtue or fame)
>
> It retains @Peter's preference for a more re-usable roll_die() which
> returns a single event, cf the OP's roll() which returns two results).
>
>
> import itertools, random
>
> def roll_die():
> while True:
> yield random.randrange(1, 7)
>
> def how_many_times():
> return list( itertools.takewhile( lambda r:r[ 0 ] != r[ 1 ],
> zip( roll_die(), roll_die() )
> )
> )
>
> Also, a claim for 'bonus points' because the one-liner will fit within
> 80-characters - if only I didn't have that pernicious and vile habit of
> coding a more readable layout.
>
> It doesn't use a two-arg iter, but still rates because it does use a
> relatively-obscure member of the itertools library...
>

Nice, but that's only going to give you the ones that don't match. You
can then count those, and that's a start, but how do you capture the
matching rolls?

I smell another opportunity for gratuitous use of a language feature:
nonlocal. In a lambda function. Which may require shenanigans of epic
proportions.

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

On 11/09/2021 18.03, Chris Angelico wrote:
> On Sat, Sep 11, 2021 at 3:26 PM dn via Python-list
> <python-list@python.org> wrote:
>>
>> On 31/08/2021 01.50, Chris Angelico wrote:
>>> On Mon, Aug 30, 2021 at 11:13 PM David Raymond <David.Raymond@tomtom.com> wrote:
>>>>
>>>>> def how_many_times():
>>>>> x, y = 0, 1
>>>>> c = 0
>>>>> while x != y:
>>>>> c = c + 1
>>>>> x, y = roll()
>>>>> return c, (x, y)
>>>>
>>>> Since I haven't seen it used in answers yet, here's another option using our new walrus operator
>>>>
>>>> def how_many_times():
>>>> roll_count = 1
>>>> while (rolls := roll())[0] != rolls[1]:
>>>> roll_count += 1
>>>> return (roll_count, rolls)
>>>>
>>>
>>> Since we're creating solutions that use features in completely
>>> unnecessary ways, here's a version that uses collections.Counter:
>>>
>>> def how_many_times():
>>> return next((count, rolls) for count, rolls in
>>> enumerate(iter(roll, None)) if len(Counter(rolls)) == 1)
>>>
>>> Do I get bonus points for it being a one-liner that doesn't fit in
>>> eighty characters?
>>
>>
>> Herewith my claim to one-liner fame (assuming such leads in any way to
>> virtue or fame)
>>
>> It retains @Peter's preference for a more re-usable roll_die() which
>> returns a single event, cf the OP's roll() which returns two results).
>>
>>
>> import itertools, random
>>
>> def roll_die():
>> while True:
>> yield random.randrange(1, 7)
>>
>> def how_many_times():
>> return list( itertools.takewhile( lambda r:r[ 0 ] != r[ 1 ],
>> zip( roll_die(), roll_die() )
>> )
>> )
>>
>> Also, a claim for 'bonus points' because the one-liner will fit within
>> 80-characters - if only I didn't have that pernicious and vile habit of
>> coding a more readable layout.
>>
>> It doesn't use a two-arg iter, but still rates because it does use a
>> relatively-obscure member of the itertools library...
>>
>
> Nice, but that's only going to give you the ones that don't match. You
> can then count those, and that's a start, but how do you capture the
> matching rolls?
>
> I smell another opportunity for gratuitous use of a language feature:
> nonlocal. In a lambda function. Which may require shenanigans of epic
> proportions.


The stated requirement is: "I'd like to get the number of times I
tried". Given such: why bother with returning any of the pairs of values?

Further, if you look at the OP's original solution, it only publishes
the last pair, ie the match, without mention of the list of non-matches.
Was it perhaps only a means of testing the solution?

Regret that I'll settle for (or continue to seek) 'fame'. I don't play
guitar, so have no use for epic.
--
Regards,
=dn
--
https://mail.python.org/mailman/listinfo/python-list

On 11/09/2021 10:09, dn via Python-list wrote:
>
>
>
> The stated requirement is: "I'd like to get the number of times I
> tried". Given such: why bother with returning any of the pairs of values?

Indeed, if that's the requirement, then you can do even better, noting
that the probability of getting a matched pair is 1/6 (6 matches out of
6*6 possibilities). So the answer to the problem is exactly the same as
rolling a single die until you get any particular number (e.g., 1).

This is somewhat easier to simulate than the two-dice problem (and the
number of throws until a match is also a known, analytic distribution
that you could sample from, but this is probably easier).


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

On 2021-09-08 13:07:47 +1200, Greg Ewing wrote:
> On 8/09/21 2:53 am, Grant Edwards wrote:
> > #define IF if (
> > #define THEN ) {
> > #define ELSE } else {
> > #define ENDIF }
>
> I gather that early versions of some of the Unix utilities were
> written by someone who liked using macros to make C resemble Algol.

Steve Bourne, the author of the eponymous shell.

hp

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

dn <PythonList@DancesWithMice.info> writes:

[...]

> Further, if you look at the OP's original solution, it only publishes
> the last pair, ie the match, without mention of the list of non-matches.
> Was it perhaps only a means of testing the solution?

It was a means of showing the student that indeed they obtained a match.
If the exercise asked for returning a single die or no die at all, they
would make mistakes and there'd be no sign of them being wrong. For
instance, one trouble a lot of them went through was to start counting
from zero and so their number of rolls was off by one. (I didn't see
that coming!) The reason they fall for this is that they also test
little --- for some it never occurred a match on the first roll, so they
never saw the zero counter coming out.
--
https://mail.python.org/mailman/listinfo/python-list