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
--
https://mail.python.org/mailman/listinfo/python-list
