Re: Extract lines from file, add to new files
On 15/01/24 1:28 am, Left Right wrote: Python isn't a context-free language, so the grammar that is used to describe it doesn't actually describe the language Very few languages have a formal grammar that *fully* describes the set of strings that constitute valid programs, including all the rules about things having to be declared, types matching up, etc. The only one I know of which attempted that is Algol 68, and it seems to be regarded as a technical success but a practical failure. ... so, it's a "pretend grammar" that ignores indentation. Indentation isn't ignored, it appears in the grammar by means of INDENT and DEDENT lexical tokens. It's true that the meaning of these tokens is described informally elsewhere, but that's true of all the lexical features. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: Extract lines from file, add to new files
On 13/01/24 11:34 pm, Left Right wrote: To make this shorter, Python allows: for in ... : ... Um, no, it doesn't. An assignment target is not, on its own, a statement. It's hard to make sense of what you're saying. You seem to be surprised by the fact that Python doesn't require variables to be declared separately from their use. But this is a very common feature of dynamic languages generally. As language oddities go, it hardly rates a mention. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: Extract lines from file, add to new files
On 15/01/24 14:45, Chris Angelico wrote: On Mon, 15 Jan 2024 at 12:42, dn via Python-list wrote: On 15/01/24 14:33, Chris Angelico via Python-list wrote: On Mon, 15 Jan 2024 at 12:12, dn via Python-list wrote: Here's another witticism I'll often toss at trainees (in many languages, and especially in UX): just because we can do it, doesn't make it a good idea! Programming. We were so busy with whether we COULD that we didn't stop to think if we SHOULD. I think that's basically my whole life. Don't be too hard on yourself. My life-advice has always been "don't do anything I wouldn't do" - which pretty-much gives you carte blanche. I would NEVER give that advice to anyone. They would leave the dishes unwashed, and a number of other problems :) I'd soon have you sorted-out - except for one small problem: all the dishes have been done! If you can get here before the rain, the lawn needs mowing... -- Regards, =dn -- https://mail.python.org/mailman/listinfo/python-list
Re: Extract lines from file, add to new files
On Mon, 15 Jan 2024 at 12:42, dn via Python-list wrote: > > On 15/01/24 14:33, Chris Angelico via Python-list wrote: > > On Mon, 15 Jan 2024 at 12:12, dn via Python-list > > wrote: > >> Here's another witticism I'll often toss at trainees (in many languages, > >> and especially in UX): just because we can do it, doesn't make it a good > >> idea! > >> > > > > Programming. We were so busy with whether we COULD that we didn't stop > > to think if we SHOULD. > > > > I think that's basically my whole life. > > Don't be too hard on yourself. > > My life-advice has always been "don't do anything I wouldn't do" > - which pretty-much gives you carte blanche. > I would NEVER give that advice to anyone. They would leave the dishes unwashed, and a number of other problems :) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Extract lines from file, add to new files
On 15/01/24 14:33, Chris Angelico via Python-list wrote: On Mon, 15 Jan 2024 at 12:12, dn via Python-list wrote: Here's another witticism I'll often toss at trainees (in many languages, and especially in UX): just because we can do it, doesn't make it a good idea! Programming. We were so busy with whether we COULD that we didn't stop to think if we SHOULD. I think that's basically my whole life. Don't be too hard on yourself. My life-advice has always been "don't do anything I wouldn't do" - which pretty-much gives you carte blanche. -- Regards, =dn -- https://mail.python.org/mailman/listinfo/python-list
Re: Extract lines from file, add to new files
On Mon, 15 Jan 2024 at 12:12, dn via Python-list wrote: > Here's another witticism I'll often toss at trainees (in many languages, > and especially in UX): just because we can do it, doesn't make it a good > idea! > Programming. We were so busy with whether we COULD that we didn't stop to think if we SHOULD. I think that's basically my whole life. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Extract lines from file, add to new files
On 15/01/24 11:47, Chris Angelico via Python-list wrote: On Mon, 15 Jan 2024 at 09:40, dn via Python-list wrote: The basic challenge came from my earlier (and blasé) repetition of the Python refrain "everything in Python is an object". Which led to: ... So, no, there's an "everything" which (might be) an object but which cannot be used in that scenario. More accurately, every VALUE in Python is an object. This does not mean that syntax is an object. Very few languages would say that every single grammatical element is a value. +1 Thank you. This old-dog will try to re-learn that term... Yes, it's sloppy to say "everything" is an object, but it's also rather nonintuitive to claim that, therefore, syntax elements are all objects. It's like claiming that everything that this dealership sells is a car (or "everything in this dealership is a car"), and therefore the dealership's name must itself be a car. To say nothing of 'extended warranties'! (and their dubious rationale) That said, does anyone think that something like: for a_function( etc ) in iterable/iterator: is acceptable? - see both Python definition and (full-)quotation. I've not come-across a language which does allow such - YMMV/mea culpa; and am struggling to see how it could possibly be useful. You could do something close to that: for a_function(etc)[0] in iterable: ... because an assignment target can contain an arbitrary expression followed by the subscript. Here's another witticism I'll often toss at trainees (in many languages, and especially in UX): just because we can do it, doesn't make it a good idea! * Looking at the correspondent's email-address (cf 'handle') - and as an unfair stereotype, raises the question of issues related to (English) language-skills - which, arrogantly implies/assumes that native English-speakers are all highly-capable. (?) A negative-interpretation is to note his apparent intelligence, but wonder if failing to represent others' comments fairly is deliberate, or carelessness. Is there an irony in behaving/failing in such, whilst attempting to hold Python's structure to some golden-ideal? Seems likely. -- Regards, =dn -- https://mail.python.org/mailman/listinfo/python-list
Re: Extract lines from file, add to new files
On 15/01/24 08:06, AVI GROSS via Python-list wrote: ...> You provided a way to create an anonymous function and that was not enough. I wonder if you could throw in the new := walrus operator to similarly make a named lambda function in a similar way. Why would @Chris have anything to do with the 'walrus-operator'? PS our interlocutor doesn't like colloquialisms such as these - despite them being near-and-dear to our hearts! -- Regards, =dn -- https://mail.python.org/mailman/listinfo/python-list
Re: Extract lines from file, add to new files
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
Re: Python 3.12.1, Windows 11: shebang line #!/usr/bin/env python3 doesn't work any more
In Windows the provided methods for running complex command lines are either a batch file or a shortcut.Someone very kindly pointed out to me in this thread that there is a PEP for py.exe. I don't use py.exe originally because I didn't trust it believing it was a new-fangled Microsoft trick. I did read that PEP but it has no relevance for my mixed Windows/Linux environments. On reflection I now believe I won't use py.exe because it introduces an unnecessary layer of indirection.The bottom line is that you still need to know which Python a particular set of circumstances demands and if you use py.exe you then need to also understand how it chooses and how it interprets shebang lines written for your Linux environment. And if that isn't your situation I have jumped to the wrong conclusion.I have found no problem in Windows when I use shebang lines in scripts intended for execution in both Linux and Windows. They are ignored unless you use py.exe.My advice is to give up py.exe unless your use case mandates shebang lines in Windows.M--(Unsigned mail from my phone) Original message From: Sibylle Koczian via Python-list Date: 14/1/24 23:59 (GMT+10:00) To: python-list@python.org Subject: Re: Python 3.12.1, Windows 11: shebang line #!/usr/bin/env python3 doesn't work any more Am 09.01.2024 um 12:36 schrieb Barry Scott via Python-list:> > >> On 7 Jan 2024, at 15:09, Sibylle Koczian via Python-list wrote: Oh, and the two Windows and Python versions are on two different computers. Will remove the "/env" from my shebang lines, even if I don't understand what's happening.> > Thanks for the details.> > Only thing I can think of is that "python" may be defaulting to mean python 2.> If you use "#!/usr/bin/env python3" it may work on both.No, it doesn't. That's the form I started with. When it didn't work I thought "python3" might be too old, because Python 2 is dead for so long.> > Did you creates a py.ini file to configure py.exe?> > See if you have %userappdata%\py.ini on either windows 10 or windows 11.> If so what is its contents?No to both.> > I've tried with and without a py.ini and cannot duplicate what you see.> It really seems strange. Only thing I can think of - and I don't really believe in that idea: as far as I know in Windows 11 the handling of PATH has changed. My Python isn't on the path, perhaps that is it. A shebang line without "/env" doesn't check the path, right?Thank you for helping,Sibylle-- https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
RE: Extract lines from file, add to new files
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 On Behalf Of Left Right via Python-list Sent: Sunday, January 14, 2024 7:28 AM To: Chris Angelico 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
Re: Extract lines from file, add to new files
On Mon, 15 Jan 2024 at 09:40, dn via Python-list wrote: > The basic challenge came from my earlier (and blasé) repetition of the > Python refrain "everything in Python is an object". Which led to: > > <<< > 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. > >>> > > Which is logical - to some degree, and in-isolation. > > for def a_function( etc )... in iterable/iterator: > > does not make sense. The 'head' (a more generic name, where Python says > "target_list", that refines down to 'something which can identify the > generated-value'. > > So, no, there's an "everything" which (might be) an object but which > cannot be used in that scenario. More accurately, every VALUE in Python is an object. This does not mean that syntax is an object. Very few languages would say that every single grammatical element is a value. Yes, it's sloppy to say "everything" is an object, but it's also rather nonintuitive to claim that, therefore, syntax elements are all objects. It's like claiming that everything that this dealership sells is a car (or "everything in this dealership is a car"), and therefore the dealership's name must itself be a car. > That said, does anyone think that something like: > > for a_function( etc ) in iterable/iterator: > > is acceptable? > - see both Python definition and (full-)quotation. > > I've not come-across a language which does allow such - YMMV/mea culpa; > and am struggling to see how it could possibly be useful. You could do something close to that: for a_function(etc)[0] in iterable: ... because an assignment target can contain an arbitrary expression followed by the subscript. > * Looking at the correspondent's email-address (cf 'handle') - and as an > unfair stereotype, raises the question of issues related to (English) > language-skills - which, arrogantly implies/assumes that native > English-speakers are all highly-capable. (?) A negative-interpretation > is to note his apparent intelligence, but wonder if failing to represent > others' comments fairly is deliberate, or carelessness. Is there an > irony in behaving/failing in such, whilst attempting to hold Python's > structure to some golden-ideal? Seems likely. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
RE: Extract lines from file, add to new files
Straight Ahead, on average,
I am not sure what your beef is as apparently it is always something else than
some others assumed.
If your point is that you want consistency, sure that would be nice. But maybe
part of the inconsistency I am not sure you mean is an artifact of the language.
There are programming languages where a keyword like "def" is used to create a
function and similarly some where variables are declared some special way like
"let" or "var" and "const" or "class" to provide the right hints. Some
languages skip that and just let you pop up a variable as in "x=5" both
declares and instantiates a variable. Strictly speaking, in a language like
python, everything is an object and some of the way of creating them remains
bound to other ideas like declaring a class uses key words as does declaring a
function.
But consider a language like R which declares a function similar to anything
else:
X <- 5
Times2 <- function(x) { x*2 }
The keyword has been moved as compared to the python:
Def Times2(x):
return(x*2)
It is not a question of being better or worse, but simply speaking, there is no
special keyword to start the process before the name, but rather a keyword
later that is really similar to a lambda method. Secondarily, not relying on
indentation, may make it easier in some cases to insert the function
declaration anywhere a statement might fit as there is no special keyword.
Other languages have their own chosen ways and many will fail various tests you
can come up with.
Could python have chosen some other way that would have fit some grammar needs?
Probably. But it did not.
If you want to play a common grammar game, you can define a higher-level
construct I will simply call A that is decomposed into two or more subcontexts
one of which is B and then populate the tree on each side with more and more
specific stuff. Then when talking about what is allowed in context alpha, where
all expressions are allowed, say it supports A or anything in the tree below
it. In another context, say it only supports B and anything below that.
Think of it a bit like subclassing.
Perhaps you can then build a complex description that can be instantiated by
code to define all valid programs from invalid ones. But it would remain a pain
to implement all the tools you want to help you, including in an editor or
programming environment, where figuring out the context may become very
difficult.
Still, making things very loose and general so that your design looks simple
has many negative tradeoffs too, including allowing rather nonsensical things.
People who create programming languages have various goals in mind that guide
what they choose. Python was not made to be a mathematically perfect object
that guided being able to have programs proven to work and so on. It is
acknowledged various aspects do not please some people or others and I am not
defending it.
I am wondering if what is being discussed is in any way a serious issue.
The original question in this thread really was a minor one and how it became
whatever this is, well, I give up! LOL!
-Original Message-
From: Left Right
Sent: Sunday, January 14, 2024 4:15 PM
To: avi.e.gr...@gmail.com
Cc: Chris Angelico ; python-list@python.org
Subject: Re: Extract lines from file, add to new files
> You said function. I made a function. You said "head of a for loop
> clause". I put it there. Problem was underspecified.
I also wrote a lot of letters, if you combine them very liberally,
without any regard to the order in which they were written or the
context in which they were used, you may come up with very surprising
findings.
> But if you're trying to tell me that a def statement should be a valid
> assignment target,
Why not just read what I wrote and work from there? No, I didn't
write anything even remotely similar to this... I don't want function
definition to be an assignment target. I was giving an example of how
Python grammar works, how the rules govern what can or cannot be used
in a particular place...
In other words, if you aren't sure you understand the question, why
are you trying to reply to it? Is your goal to learn the meaning of
the question by giving arbitrary replies and hoping that the author of
the question restates it so that you understand it? If so, I believe,
the better strategy would be to simply ask to restate the question.
Will save you the round-trip.
> You provided a way to create an anonymous function and that was not enough.
> I wonder if you could throw in the new := walrus operator to similarly make
> a named lambda function in a similar way.
The person you are replying to didn't understand the question and has
written something irrelevant. It's not about being "enough". I
honestly don't know why they are spending so much energy replying to
my messages :|
> Python grew and there was regular pressure to add keywords which might break
> existing programs. So, yes,
Re: Extract lines from file, add to new files
On 15/01/24 10:23, Chris Angelico via Python-list wrote: On Mon, 15 Jan 2024 at 08:15, Left Right wrote: Python grammar rules prevent function definition from appearing in left-hand side of the head of the for loop. However, a variable declaration, which is also a statement, is allowed there. What is a "variable declaration" in Python? Please elaborate. We may be in danger of disappearing down an unintended 'rabbit hole' with this side-discussion (he says, with graceful under-statement). The basic challenge came from my earlier (and blasé) repetition of the Python refrain "everything in Python is an object". Which led to: <<< 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. >>> Which is logical - to some degree, and in-isolation. for def a_function( etc )... in iterable/iterator: does not make sense. The 'head' (a more generic name, where Python says "target_list", that refines down to 'something which can identify the generated-value'. So, no, there's an "everything" which (might be) an object but which cannot be used in that scenario. Two "howevers": However, instead of looking at the narrow clause, (third comment about wording not being taken as an whole!!!)* the full quotation was: <<< 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. >>> Context! However, from the docs: "A function definition defines a user-defined function object (see section The standard type hierarchy)". Accordingly, is a function-definition an object? No! It defines an object. That said, does anyone think that something like: for a_function( etc ) in iterable/iterator: is acceptable? - see both Python definition and (full-)quotation. I've not come-across a language which does allow such - YMMV/mea culpa; and am struggling to see how it could possibly be useful. In-turn, how this discussion could become profitable... * Looking at the correspondent's email-address (cf 'handle') - and as an unfair stereotype, raises the question of issues related to (English) language-skills - which, arrogantly implies/assumes that native English-speakers are all highly-capable. (?) A negative-interpretation is to note his apparent intelligence, but wonder if failing to represent others' comments fairly is deliberate, or carelessness. Is there an irony in behaving/failing in such, whilst attempting to hold Python's structure to some golden-ideal? Web.Refs: https://docs.python.org/3/reference/compound_stmts.html#the-for-statement https://docs.python.org/3/reference/simple_stmts.html#grammar-token-python-grammar-target_list https://docs.python.org/3/reference/compound_stmts.html#function-definitions -- Regards, =dn -- https://mail.python.org/mailman/listinfo/python-list
Re: Extract lines from file, add to new files
> You said function. I made a function. You said "head of a for loop > clause". I put it there. Problem was underspecified. I also wrote a lot of letters, if you combine them very liberally, without any regard to the order in which they were written or the context in which they were used, you may come up with very surprising findings. > But if you're trying to tell me that a def statement should be a valid > assignment target, Why not just read what I wrote and work from there? No, I didn't write anything even remotely similar to this... I don't want function definition to be an assignment target. I was giving an example of how Python grammar works, how the rules govern what can or cannot be used in a particular place... In other words, if you aren't sure you understand the question, why are you trying to reply to it? Is your goal to learn the meaning of the question by giving arbitrary replies and hoping that the author of the question restates it so that you understand it? If so, I believe, the better strategy would be to simply ask to restate the question. Will save you the round-trip. > You provided a way to create an anonymous function and that was not enough. > I wonder if you could throw in the new := walrus operator to similarly make > a named lambda function in a similar way. The person you are replying to didn't understand the question and has written something irrelevant. It's not about being "enough". I honestly don't know why they are spending so much energy replying to my messages :| > Python grew and there was regular pressure to add keywords which might break > existing programs. So, yes, sometimes, a keyword was re-used in a different > context. Why are keywords relevant to this? > How often do you really think anyone out there NEEDS to define a function in > the context mentioned? This isn't about programmers writing programs that aren't about the language. It's about programmers who write language-related tools, like linters, formatters etc. I.e. the programmers who need to consider any possible grammar product. And the reason I mentioned function definition is, this, again: function definition is a statement. Python grammar rules prevent function definition from appearing in left-hand side of the head of the for loop. However, a variable declaration, which is also a statement, is allowed there. Programmers like grammar rules to be consistent, and it's surprising if a particular larger context allows both statements and expressions. I also explained why and how language authors would make a decision to break this consistency: it saves some keystrokes for the programmers. I.e. allows for shorter programs, while doesn't add any new abilities to the language. -- https://mail.python.org/mailman/listinfo/python-list
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. --
Re: Extract lines from file, add to new files
On 14/01/24 16:48, Chris Angelico wrote: On Sun, 14 Jan 2024 at 14:43, dn via Python-list wrote: Similarly, whilst we could write: a, b, c = 1, 2, 3 I would only do this when it aligns particularly well with the algorithm being implemented. For example, you could start a Fibonacci evaluator with "a, b = 0, 1". Otherwise, there's not all that much reason to unpack three constants in this way. (Though I am much more likely to use multiple initialization to set a bunch of things to the SAME value, lilke "a = b = c = 0".) Neatly stated! -- Regards, =dn -- https://mail.python.org/mailman/listinfo/python-list
Re: Extract lines from file, add to new files
> What do you mean? > > for x in lambda: ...: > ... > > Perfectly grammatical. 1. You put the lambda definition in the wrong place (it should be in the left-hand side, or as Python calls it "star_targets", but you put it into "star_expressions", which would be where the right-hand side is drawn from). 2. You used what Python calls "lambdadef" in place of what Python calls "function_def". I.e. lambda definition and function definition are two different things, at least as far as grammar is considered. So, you solved a different problem. -- https://mail.python.org/mailman/listinfo/python-list
Re: Extract lines from file, add to new files
> What do you mean by this? Most languages I've worked with allow > variables to be initialized with arbitrary expressions, and a lot of > languages allow narrowly-scoped variables. I'm talking about the *left* hand side of the assignment, not the right hand side. Initialization with arbitrary expression -- arbitrary expression is on the right. So, that's beside the point. Here are examples of languages that don't have a feature analogous to "augmented assignment target": * Java * C * Shell Examples of languages with limited use of destructuring: * Haskell * JavaScript * Ruby * Common Lisp Examples of languages with a superset of destructuring: * Prolog family of languages (in Prolog it's called "unification") What is the problem with Python's "augmented assignment target"? -- It is used in places where syntactically it is more common to introduce variables (and in languages with the limited use of destructuring, it's only possible to introduce variables in this context). For example, when destructuring an Array in JavaScript, the left-hand side is restricted syntactically to a very small subset of the language that, for example, excludes function application. Typically, it's not possible to use already defined variables in the left-hand side of the variable definition, even if destructuring assignment is possible. Prolog is the example of the opposite, where already defined variables are allowed on both sides of unification, but Prolog doesn't have function application in the same sense Python has, so it's still OK. In general, in languages that aren't like Prolog, conceptually, it's possible to either *define* variables (with optional initialization) or to *reuse* them (in the context of assignment that usually looks similar to initialization), but not both. The fact that in Python you can do both in the same place is surprising, eg. in the context of loops. Any language that distinguishes between expressions and statements would have conceptual difficulties with allowing a mix in the same context. Typically, variable introduction is a statement in such languages (as is the case in Python), so using an expression in the same place as a variable introduction is strange. To make this shorter, Python allows: for in ... : ... and for in ... : ... which is unexpected, especially since the first form is a lot more popular. Because the limited subset of expressions is desirable in this context, many languages try to "cram" it into this box. C, after some standard iterations caved in and allowed statements in the initialization component of the for loop (but only variable declaration statements), for example. Other languages like JavaScript developed a special subset of language for the purpose of describing the relationship between multiple components of the object being assigned as variables. In every case, from the language development perspective, this looks clumsy and unnecessary, as it is usually easy to write programs that are exactly equivalent but don't require such workarounds. But, in practice, programmers want to save a few keystrokes, and this pushes the language authors to add such "features". Python is furthermore unique in how the workaround creates a lot of opportunities for abuse. > The Python term, at least colloquially, is "tuple unpacking." Well, why use colloquialism if there's a language specification? Also, there weren't any tuples used in my example, at least not explicitly (i could've been a tuple, but that wasn't specified). -- https://mail.python.org/mailman/listinfo/python-list
Re: Extract lines from file, add to new files
On Mon, 15 Jan 2024 at 08:15, Left Right wrote: > Python grammar rules prevent function definition from > appearing in left-hand side of the head of the for loop. However, a > variable declaration, which is also a statement, is allowed there. What is a "variable declaration" in Python? Please elaborate. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
RE: Extract lines from file, add to new files
Chris, It gets frustrating when people demand too much when strictly speaking, it is not really needed or may cause new problems. How often do you really think anyone out there NEEDS to define a function in the context mentioned? You provided a way to create an anonymous function and that was not enough. I wonder if you could throw in the new := walrus operator to similarly make a named lambda function in a similar way. And, in any case, you can make a function factory that returns a function and call that function with appropriate arguments that might then create a wide variety of functions by doing the def within. Languages are tools and need not be the end-all for all people. You do not want the language to get so complex that programmers do not have any idea what valid code does. Consider the mess in multiple inheritance and trying to figure out which of many classes will be the one where a method is finally called using some diamond algorithm. It is both extremely powerful but also silly to overuse such features. Avi -Original Message- From: Python-list On Behalf Of Chris Angelico via Python-list Sent: Sunday, January 14, 2024 8:34 AM To: python-list@python.org Subject: Re: Extract lines from file, add to new files On Mon, 15 Jan 2024 at 00:27, Left Right wrote: > > > What do you mean? > > > > for x in lambda: ...: > > ... > > > > Perfectly grammatical. > > 1. You put the lambda definition in the wrong place (it should be in > the left-hand side, or as Python calls it "star_targets", but you put > it into "star_expressions", which would be where the right-hand side > is drawn from). > 2. You used what Python calls "lambdadef" in place of what Python > calls "function_def". I.e. lambda definition and function definition > are two different things, at least as far as grammar is considered. > > So, you solved a different problem. You said function. I made a function. You said "head of a for loop clause". I put it there. Problem was underspecified. But if you're trying to tell me that a def statement should be a valid assignment target, I don't know what you're smoking, but I want you to keep it a long way away from me. Can you name ANY language in which that would make the slightest bit of sense? ChrisA -- https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3.12.1, Windows 11: shebang line #!/usr/bin/env python3 doesn't work any more
On 1/14/2024 8:54 AM, Thomas Passin via Python-list wrote: On 1/14/2024 7:48 AM, Sibylle Koczian via Python-list wrote: Am 09.01.2024 um 12:36 schrieb Barry Scott via Python-list: On 7 Jan 2024, at 15:09, Sibylle Koczian via Python-list wrote: Oh, and the two Windows and Python versions are on two different computers. Will remove the "/env" from my shebang lines, even if I don't understand what's happening. Thanks for the details. Only thing I can think of is that "python" may be defaulting to mean python 2. If you use "#!/usr/bin/env python3" it may work on both. No, it doesn't. That's the form I started with. When it didn't work I thought "python3" might be too old, because Python 2 is dead for so long. Did you creates a py.ini file to configure py.exe? See if you have %userappdata%\py.ini on either windows 10 or windows 11. If so what is its contents? No to both. I've tried with and without a py.ini and cannot duplicate what you see. It really seems strange. Only thing I can think of - and I don't really believe in that idea: as far as I know in Windows 11 the handling of PATH has changed. My Python isn't on the path, perhaps that is it. A shebang line without "/env" doesn't check the path, right? From what I've read recently, if you have a Python program that starts with a shebang line with any of four standard unix-like paths, then Python (not Windows) will look for a version of Python in standard locations - *NOT* in the shebang line locations: I meant to write "the Python launcher", that is, the "py" program. Normal Python installs on Windows install the launcher and Windows will run it on ".py" files if no other program has been specified on the command line. "To allow shebang lines in Python scripts to be portable between Unix and Windows, this launcher supports a number of ‘virtual’ commands to specify which interpreter to use. The supported virtual commands are: /usr/bin/env /usr/bin/python /usr/local/bin/python python " Also - "The /usr/bin/env form of shebang line has one further special property. Before looking for installed Python interpreters, this form will search the executable PATH for a Python executable matching the name provided as the first argument. This corresponds to the behaviour of the Unix env program, which performs a PATH search. If an executable matching the first argument after the env command cannot be found, but the argument starts with python, it will be handled as described for the other virtual commands. " There are some other complications, too, depending on whether you specify bare "python" or some specific version. The form with "/usr/bin/env" is the closest to the unix behavior, in that it searches the PATH. And you write that your intended version of Python is not on the path. IOW, these shebang lines don't work the way you seem to think that they do. See https://docs.python.org/3/using/windows.html for a more complete rundown. -- https://mail.python.org/mailman/listinfo/python-list
RE: Extract lines from file, add to new files
It can be worth considering why a language is designed or altered in certain ways to see if there was a tradeoff that made it seem worthwhile or easier than some other choice. Python grew and there was regular pressure to add keywords which might break existing programs. So, yes, sometimes, a keyword was re-used in a different context. And, yes, it was not originally conceived in a purely object oriented context. If you wanted to start over and built a new language very similar to python, you might indeed make other choices now that seem more seamlessly to fit together. You could set aside and reserve hundreds of keywords or some way to extend keywords by insisting anything staring with "key_" cannot be used in a variable name. You might design all the main objects supported to all support a function that provides a length as well as every other method needed so it looks purely object oriented. But perhaps that would make it a tad harder to program it using other ways. As an example, I can ask some sort program to order the results by the length of items by passing it the function that does lengths as an argument. If instead all we had was a method, that might be a bit different and perhaps someone would simply make a tiny function that when called, invoked the method. So, we have a hybrid of sorts and have to live with it, warts and all, and some of the warts may be seen by some as beauty marks. -Original Message- From: Python-list On Behalf Of Chris Angelico via Python-list Sent: Sunday, January 14, 2024 7:32 AM To: python-list@python.org Subject: Re: Extract lines from file, add to new files On Sun, 14 Jan 2024 at 23:28, Left Right wrote: > Having worked with a bunch of different grammar languages, the one > used for Python isn't a recognizable BNF derivative. That might possibly be because it isn't? It's not BNF. It's PEG. Or are you a long way behind the times? > 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. What do you mean? for x in lambda: ...: ... Perfectly grammatical. ChrisA -- https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3.12.1, Windows 11: shebang line #!/usr/bin/env python3 doesn't work any more
On 1/14/2024 7:48 AM, Sibylle Koczian via Python-list wrote: Am 09.01.2024 um 12:36 schrieb Barry Scott via Python-list: On 7 Jan 2024, at 15:09, Sibylle Koczian via Python-list wrote: Oh, and the two Windows and Python versions are on two different computers. Will remove the "/env" from my shebang lines, even if I don't understand what's happening. Thanks for the details. Only thing I can think of is that "python" may be defaulting to mean python 2. If you use "#!/usr/bin/env python3" it may work on both. No, it doesn't. That's the form I started with. When it didn't work I thought "python3" might be too old, because Python 2 is dead for so long. Did you creates a py.ini file to configure py.exe? See if you have %userappdata%\py.ini on either windows 10 or windows 11. If so what is its contents? No to both. I've tried with and without a py.ini and cannot duplicate what you see. It really seems strange. Only thing I can think of - and I don't really believe in that idea: as far as I know in Windows 11 the handling of PATH has changed. My Python isn't on the path, perhaps that is it. A shebang line without "/env" doesn't check the path, right? From what I've read recently, if you have a Python program that starts with a shebang line with any of four standard unix-like paths, then Python (not Windows) will look for a version of Python in standard locations - *NOT* in the shebang line locations: "To allow shebang lines in Python scripts to be portable between Unix and Windows, this launcher supports a number of ‘virtual’ commands to specify which interpreter to use. The supported virtual commands are: /usr/bin/env /usr/bin/python /usr/local/bin/python python " Also - "The /usr/bin/env form of shebang line has one further special property. Before looking for installed Python interpreters, this form will search the executable PATH for a Python executable matching the name provided as the first argument. This corresponds to the behaviour of the Unix env program, which performs a PATH search. If an executable matching the first argument after the env command cannot be found, but the argument starts with python, it will be handled as described for the other virtual commands. " There are some other complications, too, depending on whether you specify bare "python" or some specific version. The form with "/usr/bin/env" is the closest to the unix behavior, in that it searches the PATH. And you write that your intended version of Python is not on the path. IOW, these shebang lines don't work the way you seem to think that they do. See https://docs.python.org/3/using/windows.html for a more complete rundown. -- https://mail.python.org/mailman/listinfo/python-list
Re: Extract lines from file, add to new files
On Mon, 15 Jan 2024 at 00:27, Left Right wrote: > > > What do you mean? > > > > for x in lambda: ...: > > ... > > > > Perfectly grammatical. > > 1. You put the lambda definition in the wrong place (it should be in > the left-hand side, or as Python calls it "star_targets", but you put > it into "star_expressions", which would be where the right-hand side > is drawn from). > 2. You used what Python calls "lambdadef" in place of what Python > calls "function_def". I.e. lambda definition and function definition > are two different things, at least as far as grammar is considered. > > So, you solved a different problem. You said function. I made a function. You said "head of a for loop clause". I put it there. Problem was underspecified. But if you're trying to tell me that a def statement should be a valid assignment target, I don't know what you're smoking, but I want you to keep it a long way away from me. Can you name ANY language in which that would make the slightest bit of sense? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3.12.1, Windows 11: shebang line #!/usr/bin/env python3 doesn't work any more
Am 09.01.2024 um 12:36 schrieb Barry Scott via Python-list: On 7 Jan 2024, at 15:09, Sibylle Koczian via Python-list wrote: Oh, and the two Windows and Python versions are on two different computers. Will remove the "/env" from my shebang lines, even if I don't understand what's happening. Thanks for the details. Only thing I can think of is that "python" may be defaulting to mean python 2. If you use "#!/usr/bin/env python3" it may work on both. No, it doesn't. That's the form I started with. When it didn't work I thought "python3" might be too old, because Python 2 is dead for so long. Did you creates a py.ini file to configure py.exe? See if you have %userappdata%\py.ini on either windows 10 or windows 11. If so what is its contents? No to both. I've tried with and without a py.ini and cannot duplicate what you see. It really seems strange. Only thing I can think of - and I don't really believe in that idea: as far as I know in Windows 11 the handling of PATH has changed. My Python isn't on the path, perhaps that is it. A shebang line without "/env" doesn't check the path, right? Thank you for helping, Sibylle -- https://mail.python.org/mailman/listinfo/python-list
Re: Extract lines from file, add to new files
On Sun, 14 Jan 2024 at 23:28, Left Right wrote: > Having worked with a bunch of different grammar languages, the one > used for Python isn't a recognizable BNF derivative. That might possibly be because it isn't? It's not BNF. It's PEG. Or are you a long way behind the times? > 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. What do you mean? for x in lambda: ...: ... Perfectly grammatical. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
