Three reasons to improve issue 35095: Implement pathlib.Path.append_bytes and pathlib.Path.append_text

1. If I want to append text to log at each startup(before calling basicConfig), there is no simple way to do this.

2. Adding append keyword is better then adding new APIs.

3. From stackoverflow: How does this make the classes clean? They already contain the write_* methods which are just not flexible enough. If the methods (or classes) are not dirty how would e.g. adding an optional parameter append=False to them make them dirty? https://stackoverflow.com/questions/57296168/pathlib-path-write-text-in-append-mode

So, this patch is just an implementation of discussions in above stackoverflow link.

From https://stackoverflow.com/a/68969892

> I think a major reason why pathlib.Path objects don't (and, indeed,
> shouldn't) have a append_text method is because it creates a hole for
> inexperienced users to fall into, which is a huge sin in API design.

> Specifically, the hole I'm referring to is using append_text on the
> same file repeatedly in a loop. Because you're continually opening
> and closing the file, it is slow. Plus, doing so many unnecessary
> writes is probably not great for the health of your hard drive.

> Worse, because the program will actually behave correctly (e.g. the
> file will have the contents they intended), they may not even notice
> anything is wrong, because they don't necessarily have a mental gauge
> on how long writing to a file "should" take.

Most of the time you don't need an 'append' mode. And when you do, most
of the time you'll need to append multiple times, in which case
`path.open('a')` is a much better bet.

@barneygale,
This is for simplifying code and improve readability, since `Readability counts` in The Zen of Python.

Users needn't two lines code to append a file. And there is a minimal modifying to reach it.

If inexperienced users are falling into the hole, just let them in and then learned sth. Because they will go out of the hole sooner or later. 

And finally, two lines cann't prevent them from falling into the hole.

I think it should be closed for the same reasons as #35095. It is not common enough case to complicate Path.write_text(), and you always can use open()+write().

This shouldn't be limited logging.
In unstable application scene, file should be append and then close immediately to avoid breaking filesystem (e.g. inode is not updated timely). Such as main.py file in MicroPython development board, user may disconnect USB or press reset at anytime without ejecting disk. Or in IVI system, some embedded devices, record should be appended immediately.

And if path.write(append=) is not common enough, then what's about built-in function open()? What's the purpose of adding read/write functions to pathlib.Path?

In file operations, write/modify/append, which one is generic/common? They're all.

Modifying need more then one line code, but write/oppend needn't.

Two lines are bad to readability and readability counts.

How do you determine it's not common enough? There're many kind of users and application scene, and this feature is even not existed.

Should we create a poll both to Python developers and it's users?

Without append kwarg, users need two lines to append. It's bad to both readability and writability.

Library developers should focus on bath language and library's design targets, but how frequently used. And as all discussed here, at least one applications scene(logging) benefited from append kwarg. Right?

New users who want to add lines to a file will see this method and do:

    for line in blah:
        path.write_text(line, append=True)

Which repeatedly opens/closes the file. This is a foot-shotgun; it 
shouldn't be added to pathlib IMO.

There is nothing wrong with writing two lines of code. And two lines of code may be more readable than one line of code. New method or parameter has a cost -- core developers need to maintain it, update documentation and tests if they conflict with new features, user will need to learn about it, remember differences between Python versions and implementations of different Path-like objects, it can be only used after dropping support of older Python versions, and it may be a source of common mistakes.

If you think that it is so important to use a single call for appending to a file, you can create a module which provides functions append_text() and append_bytes(). They could be used even in Python versions older than 3.11.

I concur with Serhiy.

OK. Since most are opposed to append kwarg, I close this issue.
Thanks ALL!