Re: Bug 3.11.x behavioral, open file buffers not flushed til file closed.

[Frank B]

Am 05.03.23 um 15:35 schrieb aapost:
I have run in to this a few times and finally reproduced it. Whether it 
is as expected I am not sure since it is slightly on the user, but I can 
think of scenarios where this would be undesirable behavior.. This 
occurs on 3.11.1 and 3.11.2 using debian 12 testing, in case the 
reasoning lingers somewhere else.


If a file is still open, even if all the operations on the file have 
ceased for a time, the tail of the written operation data does not get 
flushed to the file until close is issued and the file closes cleanly.


2 methods to recreate - 1st run from interpreter directly:

f = open("abc", "w")
for i in range(5):
   f.write(str(i) + "\n")


use

with open("abc", "w") as f:
for i in range(5):
f.write(str(i) + "\n")

and all is well

Frank
--
https://mail.python.org/mailman/listinfo/python-list

[issue37655] Set subset operator docs

[Frank B]

New submission from Frank B :

The docs say "Test whether the set is a proper subset of other" for both set < 
other and set > other built-in functions.

Is that a misprint? How could it be both?

For the <= and >= operators it properly reverses the order so one says:

Test whether every element in the set is in other.

and the other:

Test whether every element in other is in the set.

--
assignee: docs@python
components: Documentation
files: 2019-07-22 1728 Screenshot.png
messages: 348307
nosy: Frank B2, docs@python
priority: normal
severity: normal
status: open
title: Set subset operator docs
versions: Python 2.7, Python 3.7
Added file: https://bugs.python.org/file48498/2019-07-22 1728 Screenshot.png

___
Python tracker 
<https://bugs.python.org/issue37655>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

try/except/finally

[Frank B]

Ok; this is a bit esoteric.

So finally is executed regardless of whether an exception occurs, so states the 
docs.

But, I thought, if I return from my function first, that should take 
precedence.

au contraire

Turns out that if you do this:

try:
  failingthing()
except FailException:
  return 0
finally:
  return 1

Then finally really is executed regardless... even though you told it to return.

That seems odd to me.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: try/except/finally

[Frank B]

Ok; thanks for the underscore and clarification.  Just need to adjust my 
thinking a bit.
-- 
https://mail.python.org/mailman/listinfo/python-list