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....@python.org> On Behalf Of Left Right via Python-list Sent: Sunday, January 14, 2024 7:28 AM To: Chris Angelico <ros...@gmail.com> Cc: python-list@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 -- https://mail.python.org/mailman/listinfo/python-list
