Extract lines from file, add to new files

[avi.e.gross at gmail.com]

Whoa, Олег Сивоконь!

I do not understand any arguments about whether comments are, or are not an
object.

>From one perspective, python comments have even less meaning than whitespace
and simply do not exist. I mean once a naked "#" is seen, the rest of that
line is effectively discarded by the interpreter. The supposed multi-line
comments though, meaning something like a triple set of quotes up to another
set are probably objects in the sense that they create a text literal in a
context where there is no usual pointer to them and are thus largely ignored
and perhaps garbage collected. Some programs look for them in code as part
of documentation and it is possible they are stored in some object that
"holds" aspects of a function.

But I think that talking about some inconsistency in python because comments
are not an object is a bit silly. Why should they be? If I choose to leave
lots of blank lines between my function definitions or statements, do they
need to be made into an object, or ignored as superfluous but legal
whitespace?

I have seen many debates about some form of purity and generally, they get
boring. Nobody in their right mind can defend any computer language as being
100% right for every purpose. Python has some reasonable tradeoffs and is
highly popular and there are other languages with other tradeoffs you can
use instead. At this point, making changes without disrupting things gets
ever harder.

-----Original Message-----
From: Python-list <python-list-bounces+avi.e.gross=gmail.com at python.org> On
Behalf Of Left Right via Python-list
Sent: Sunday, January 14, 2024 7:28 AM
To: Chris Angelico <rosuav at gmail.com>
Cc: python-list at python.org
Subject: Re: Extract lines from file, add to new files

> 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.

> 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.

> 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?

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...

Furthermore, I'm absolutely convinced that what governs the
restrictions on the left-hand side isn't not whether it's understood
to be an object, but the grammar rules, that are unaware of the
concept of objects.  For example, you may say "functions in Python are
objects", but you cannot put a function definition in the head of the
for loop clause.
-- 
https://mail.python.org/mailman/listinfo/python-list