Extract lines from file, add to new files

[dn]

On 13/01/24 00:11, Left Right via Python-list wrote:
> To people discussing BNF:
> 
> The grammar language Python uses is *very* far from BNF. It's more
> similar to PEG, but even then it's still quite far.  Python's grammar
> is just its own thing, which makes it harder to read, if you are
> already familiar with other more popular formats.

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!

 From the 'book of words': <<<The descriptions of lexical analysis and 
syntax use a modified Backus–Naur form (BNF) grammar notation.>>>
https://docs.python.org/3/reference/introduction.html#notation

Yes it is hard to read - and even harder to learn-from; which is why 
@Chris gave advice about preferring tutorials/text.

Just because there are other (more popular?) formats, doesn't make the 
one used here 'wrong'. In the same way that Python code differs from 
'the same' in other languages.

Putting it another way: if what Python is doing is wrong in your 
opinion, you are in the wrong place (for you).

That is not to say that Python has everything 'right'. One of my own 
bug-bears is very similar - that the string formatting 'mini-language' 
(https://docs.python.org/3/library/string.html#formatspec) does not 
follow the same rules about white-space as everything covered by the PEG 
Parser.

BTW the PEG Parser is relatively new to Python. IIRC there was comment 
at the time of its first application, that some 'other' areas of Python 
might take a while to be converted-over.


> I've also found bugs in Python parser before, so had this turned out

Sorry, didn't recognise your email-handle - not that I'm a Python 
Core-Dev, and pretty much ignore the "Ideas" list these days. Must have 
missed your previous contributions...


> to be a real issue, this wouldn't have been the first time.  There are
> plenty of weird corners in Python grammar that allow unexpected
> programs to parse (and sometimes even run!), and these are very often
> connected to assignments, because, in general, assignments in Python
> are very elaborate and hard to describe / conceptualize about.  The
> most popular example I've even seen used in coding interviews (which I
> think is a silly gimmick, but that's kind of the whole point of a lot
> of these interviews...) is:
> 
>      x = [...]
>      for x[i] in x: print(i)
> 
> Which is not an assignment by itself, but the "weirdness" results from
> the loop syntax sharing definitions with the "destructuring bind"
> style of assignment (i.e. where the left-hand side can be an arbitrary
> complex expression).

You're right. (also about stupid 'interviewing' ideas) If someone asked 
me this, I'd respond by asking if that was the standard of code they 
work towards - and depending upon that answer would either walk-out or 
refer the matter to a more senior manager!


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.

Also, an identifier (whether x, i, or x[ i ]) should not only be 
considered to be its own object, but is best regarded as a pointer to 
some value. This is how we can have an 'immutable' tuple 'containing' a 
mutable list (for example) - such that elements of that list may be 
changed, despite being 'part of' an immutable construct!

Programs are read by people. If something is a "weirdness", then 
chances-are it won't survive a CodeReview/a professional team's 
expected-standard. Not limited to Python-code!


> I was surprised, for example, to learn that "as" in "with_stmt" isn't
> shared with "as" in "except_block" (so, from the grammar perspective,
> these are two different keywords), and that asterisk in "except_block"
> isn't shared with "star_target" (also weird, since you'd think these
> should be the same thing).  In general, and by and large, if you look
> at Python's grammar there are many "weird" choices that it makes to
> describe the language which seem counterintuitive to the programmer
> who tries to learn the language from examples (i.e. context-depending
> meaning of parenthesis, of asterisk, of period etc.)  Having been
> exposed to this, you'd start to expect that some of this weirdness
> will eventually result in bugs, or at least in unexpected behavior.

You're right. It is potentially confusing when the same word/symbol is 
used in different contexts.

I've heard similar questions from learners, but not had anyone trying to 
mis-use something extrapolating from how the 'same' is used elsewhere. YMMV!

It's the context part that's important to remember. If someone calls you 
"mate", that has different connotations depending upon whether you're 
friends, you're on a Navy ship, or in a more intimate situation - indeed 
there are some cultures in which the word "mate" is not used to mean 
'friend' at all. Which is (more) right? Which wrong?

Perhaps you're aiming for, or even used to, a more perfect and 
predictable language?


> ----
> 
> Anyways. To the OP: I'm sorry to hijack your question. Below is the
> complete program:
> 
> with (
>      open('example.txt', 'r') as e,
>      open('emails.txt', 'w') as m,
>      open('salutations.txt', 'w') as s,
> ):
>      for line in e:
>          if line.strip():
>              (m if '@' in line else s).write(line)

Please see responses elsewhere which say why this sort of thing, whilst 
possible and 'easy', is not recommendable.


> it turned out to be not quite the golfing material I was hoping for.
> But, perhaps a somewhat interesting aspect of this program you don't
> see used a lot in the wild is the parenthesis in the "with" head.  So,
> it's not a total write-off from the learning perspective.  I.e. w/o
> looking at the grammar, and had I have this code in a coding interview
> question, I wouldn't be quite sure whether this code would work or
> not: one way to interpret what's going on here is to think that the
> expression inside parentheses is a tuple, and since tuples aren't
> context managers, it wouldn't have worked (or maybe not even parsed as
> "as" wouldn't be allowed inside tuple definition since there's no
> "universal as-expression" in Python it's hard to tell what the rules
> are).  But, it turns out there's a form of "with" that has parentheses
> for decoration purposes, and that's why it parses and works to the
> desired effect.

Again, context! All that is important 'here' is how to 'link' the 
file-descriptor with an identifier. Similarly, whilst we could write:

a, b, c = 1, 2, 3

(and BTW that is legal Python - for anyone seeing such for the first time)
and whilst it is shorter (and I've been known to write such), the need 
to read carefully in order to pair-up the relative positions make it 
less readable than

a = 1; b = 2; c = 3

(and some would argue, quite reasonably, that it would be better were 
they on separate lines)

Similarly, many dev.teams have a 'standard' which suggests that once a 
function/method has three or more arguments, relative-positioning should 
go out-the-window, in favor of named-arguments. This speeds 
comprehension and reduces errors.

In the original mental-model, the difficulty was which file-descriptor 
would be paired with which file (previously described). The multiple 
as-s make it more readable and more comprehensible.


> Since it looks like you are doing this for educational reasons, I
> think there's a tiny bit of value to my effort.

That's what we're (all) here for!
(and not forgetting that the OP described a skill-level well below that 
of most of this post and your question, which enabled (and deserved, 
IMHO) appropriate respect).

-- 
Regards,
=dn