Extract lines from file, add to new files

[dn]

On 15/01/24 01:28, Left Right wrote:
>> Second time to ameliorate wording-dispute in this thread! The original
>> phrase was: "[modified] BNF". Some of us have worked with various forms
>> and evolutions of BNF since back in the days of COBOL-60 proposals, and
>> know it when we see it!
> 
> OK, here are the conceptual differences between what Python grammar
> language does and what you'd expect from anything that's based on BNF,
> modified or not:
> 
> Python isn't a context-free language, so the grammar that is used to
> describe it doesn't actually describe the language... so, it's a
> "pretend grammar" that ignores indentation.  BNF is supposed to be
> used to describe the language, it's not a "pretend" or "pseudo"
> grammar, in a way we have at least two established grammar for
> pseudo-code.
> 
> BNF and derivatives don't have an inherent mechanism for tiebreaks.
> The mechanism is necessary because BNF rules can be tried in any
> order.  Some grammar languages derived from BNF declare ambiguous
> grammars invalid, some allow ambiguity, but say that the longest
> prefix wins, and if there's still ambiguity after that, then such
> grammar is invalid, some have special constructs to define "priority"
> etc. My reading of Python grammar is that it works like PEG, where
> rules are tried in the order they are defined.  This makes it less
> expressive, but easier to work with.  This is, probably, the most
> fundamental difference between the BNF family and the PEG family.
> 
> BNF and family languages rarely incorporate elements of Perl-like
> regular expression parsing in the language (i.e. things like
> lookaheads, lookbehinds etc.) This is more typical of the PEG family.
> 
> On top of this, the Python grammar language has a bunch of
> "inventions" that are unique to it (I've never seen any other grammar
> language use '.' in the same way Python uses it).  So, there's that
> too.
> 
> Having worked with a bunch of different grammar languages, the one
> used for Python isn't a recognizable BNF derivative.  I think the
> authors used this as a description in the same way as today a lot of
> programmers would use the word "IDE" to describe any text editor or
> "REST" to describe any kind of server-client protocol over HTTP and so
> on.  Or, how we'd use "Xerox" to name a copier machine, even if that
> company didn't manufacture it, and even if the tech used for copying
> is completely different.  And that's why I wrote that the grammar is
> actually more like PEG, adding that it's neither, but seems to fall
> more into that later category.

We are in broad-agreement. I'd enjoy the discussion, except that I can't 
see where it is leading or how it will benefit you...

Where we seem to differ is the length of time we've been part of the 
Python-world.

An important point is that languages are often described as 'living', 
because they evolve over time. I'm relieved to note that the youngsters 
in the family have stopped describing 'everything' as "awesome". That 
word, has taken-on aspects of the original meanings of "awful". The 
former being positive-factors, and the negative ascribed to the latter. 
However, we don't have to step far back into history to find that 
"awful" meant 'full of awe' or awe-inspiring - with no connotation of 
'good' or 'bad'. There was no need for a word with opposite-meaning, 
apart from "mundane".

Similarly, spoken-language often lacks precision. My CO, to this day, 
uses phrases like "all done" [with time for me to take a breath, 
followed by "except ...", eg "are we ready to leave for ...?". This 
drives me nuts. (the word "nuts" requires consideration too!) Thus, have 
learned to elicit the pertinent information with phrasing such as "what 
is left to be done?" rather than arguing the illogic between "all" and 
"except".

Python is not different. We're currently looking at version 3.12, which 
implies three major iterations of the language. Accordingly, when it was 
a 'green fields project', what may have been a pure and elegant 
expression of a language, has become "acquisitive". Sometimes these 
additions-and-alterations have required compromise, eg lack of elegance. 
Sometimes, it has been realised that there is a flaw, and things need to 
be improved, even removed.

You've made comments about BNF. Like Python, it is a 'language' (a bit 
of stretch, but...) which has also been pulled, poked, and perhaps 
contorted over time. It had a body of folk who understood its 
expression, and therefore it made sense to stick with some variation of 
it (even warts-and-all) rather than going with something 'new'.


All of which creates the sorts of issues described.

The PEG-parser is a comparatively-recent improvement - other aspects 
previously-mentioned.

I'm not going to touch "Perl".

Is there really some sort of standard-understanding/format for 
"pseudo-code"? (ISO?)

Yes, there's some 'pretense' (not sure I'd choose that exact term). 
However, it is working for the vast-majority. Perhaps after using Python 
for so long, I'm comfortable accepting such 'pretense', in the same way 
that when 'the kids' use phrases like "yeah, nah" which are totally 
devoid of logical-meaning, I can deduce the attitude behind their utterance.

So, again, yes I think you're right about what appears in the docs - why 
change it if we can accept that what was there before can still be 
applied today? Again, a comfort for those who've been-around, but 
perhaps failing to take into account others. (?)

Recently we 'lost' Niklaus Wirth. I recall the days when he was part of 
teams looking at languages. Back then we contemplated improvements to 
COBOL, FORTRAN, even PL/1 (an attempt said to take the 'best' of the 
previous two - but the scuttlebutt suggested its result was the 
opposite), ALGOL68, and the idea of a new language for the world's 
largest user of computers: Ada. We devoured new drafts of future 
standards; but they were thick tomes. Soon after, Wirth simplified 
rather than expanded, and developed Pascal. When I first saw this I was 
stunned, then attracted to its simplicity, but then steered-away once 
realised that it needed 'more' to cope with 'the outside world'. 
Even-so, lessons were learned from Pascal, and its development path, and 
thus Oberon is 'same but different'. Things change. We learn (and 
improve - hopefully). etc, etc...


As mentioned, the value of this discussion would be better realised on 
the Python-Ideas Discussion List or amongst the Core-Devs - and there is 
a Python Docs Team, if you'd prefer to contribute at that level.


Back to the point that has been made, repeatedly: relying upon a single 
source is not likely to be helpful. We've been talking about 'rules', 
let's expand that out to "laws". I am unaware of a jurisdiction which 
relies totally upon written legislation. Every legal system brings those 
into the real-world with interpretation and "case law" or "the law of 
precedent". Often, the latter ends-up contorting or stretching the 
former in ways the original authors did not (even, could not) imagine.

Life, the universe, and everything!


>> Yes it is hard to read - and even harder to learn-from;
> 
> This wasn't my point.  My point is that it's hard to learn languages
> that are "one off" in the group languages that all share a similar set
> of rules. The difficulty comes from the surprise caused by the unique
> use, not because there's something inherently difficult about reading
> grammar languages.  In fact, however you look at Python's grammar
> language, in a sense, it's a lot easier to read than Python itself
> because it has significantly fewer rules.  Of course, the number of
> rules doesn't entirely capture the difficulty, but it's a useful
> metric.

Rules? What rules?

Each (programming) language was originally developed with specific 
objectives in-mind. Usually the history would include determinations to 
avoid certain aspects of other/existing languages.

As long as that objective includes 'pushing the envelope' or 'making 
things better'; any 'rules' must bend or break in-concert.


>> In Python, everything is an object. As long as the LHS is a legal-object
>> which  makes sense for the situation, it can be used.
> 
> This is a very interesting statement... I don't think you are fully
> aware of what it might mean :)  Here are just a few questions for you
> to ponder:
> 
> * What is Python? Is it only Python 3.12?  Is Python 3.11 not Python?
> How far back do you go to draw the line?
> * What makes something an "object"? Is it the ability to dispatch on?
> Is it the inheritance from "object" type?
> * What elements of the language do you consider part of the language
> that can be included in your "all" set.  Do types belong in that set?
> Do expressions belong in that set?  What about comments?

Topic addressed elsewhere.

Yet, here we are discussing a Python 'eco-system', which consists of 
numbers of parts. That those parts do, or do not, integrate as tidily or 
elegantly as we might like, is a fact of life (also previously discussed).

What language might fulfill these exacting criteria?
- and if that exists, what are you doing here?


> Depending on how you answer these questions, you'd have some further
> problems to deal with.  For example, historically, Python had plenty
> of things that didn't inherit from "object" but acted similar to one.
> I believe "module" objects were among the last to transition into
> object inheritance lane, which might have happened some time around
> Python 3.5.  Of course, there are plenty of things that are "in
> Python", at least due to its grammar, that are hard to describe as
> objects (eg. comments).  So, you'd have to make a special subset of
> Python language that (eg. excludes comments) to claim that everything
> is an object.
> 
> Most importantly, however, regardless of what you understand to be an
> object, or how you decide to answer any of those questions: what value
> does such a claim possibly have? Especially, given the context...

Intriguing. I laughed when I first saw Python's docstrings (one type of 
"comment") because it was obvious (to me) that they were being treated 
as strings. The fact that they were not identified ("assigned" or 
"bound", if you prefer) is neither here-nor-there.
(just as, on the RHS, all Python-functions return a value, even if it is 
None - which is not obvious to many, at-first)

Admittedly, a #-comment does not qualify as an object; but then the hash 
is an exclusion signal, which the lexer understands as ending the 
logical line.

Thus, a comment has meaning at 'compile time', but not at 'execution 
time'. Such would be true, strictly-speaking. However, most of us would 
say that a comment 'has no meaning' in terms of the parser, and what it 
delivers.

Shall we change the phrase to "everything in Python, at run-time, is an 
object"? As a phrase it is obiter-dictum, not ratio decidendi! (to use a 
language which has only extended in dubious modes for the last 
couple-of-thousand years - but which still has illogical structure)

Suspect that clumsy exclusion also lacks precision to the standard being 
demanded. Thus return to the suggestion that you seem in the wrong 
place, because Python doesn't meet the required standard. Sorry!


-- 
Regards,
=dn