At least on Linux, this wouldn't be that ideal. These LWN articles go over
the general fsync mess and the lack of viable alternatives:
https://lwn.net/Articles/351422/
> [...] most file systems take the brute force approach, with the result
that fsync() commonly takes time proportional to all
On 25Dec2020 09:29, Steven D'Aprano wrote:
>On Thu, Dec 24, 2020 at 12:15:08PM -0500, Michael A. Smith wrote:
>
>> With all the buffering that modern disks and filesystems do, a
>> specific question has come up a few times with respect to whether or
>> not data was actually written after flush. I
On Fri, Dec 25, 2020 at 9:30 AM Steven D'Aprano wrote:
> Perhaps a "sync on close" keyword argument to open? At least then it is
> always available and easily discoverable.
+1 (though this is really just bikeshedding)
> > 3. There are many ways to do this, and I think several of them could
> >
On Thu, Dec 24, 2020 at 12:15:08PM -0500, Michael A. Smith wrote:
> With all the buffering that modern disks and filesystems do, a
> specific question has come up a few times with respect to whether or
> not data was actually written after flush. I think it would be pretty
> useful for the
On Thu, Dec 24, 2020 at 1:34 AM Barry Scott wrote:
> if sys.playform == 'win32':
> os.system('cls')
> else:
> sys.stdout.write('\x1b[2J' '\x1b[H')
>
> No concern about CLS being a trojan becuse as a builtin to CMD and
> PowerShell
> and it takes priority over cls.bat etc.
With all the buffering that modern disks and filesystems do, a
specific question has come up a few times with respect to whether or
not data was actually written after flush. I think it would be pretty
useful for the standard library to have a variant in the io module
that would explicitly fsync
Sorry for the long response.
After investigation, I have found that there is a third-party library called
`decorator` which do smth similar to what I propose (I didn't know about that
library when I created this thread).
As I said, the idea of `decorator_factory` is to create a unified way of
Actually, I am talking about both. It is not stated anywhere in PEPs or Python
documentation that it is OK to put docstrings in .pyi files.
So we have 2 problems:
* Developers (of general purpose software) don't know should they put
docstrings in .pyi files
* Some other developers of docstring
Some examples would be:
* Pydoc does not generate documentation from stub files
* Jupyter Notebooks don't show documentation from stub files (when using its
shift+tab)
There is a better way to grasp this problem. Consider you are developing some
big library with stub files. .pyi files contain
The event loop does not exist at class setup and teardown stages.
On Thu, Dec 24, 2020 at 8:36 AM Andres Torres
wrote:
> Title says it all. This might have been an oversight while making this
> class. If not please let me know why it was not included!
>
> Thank you for considering my
> On 22 Dec 2020, at 12:39, Eryk Sun wrote:
>
> On 12/22/20, Barry Scott wrote:
>>
>> import sys
>>
>> def clear_terminal():
>>if sys.platform == 'win32':
>>import ctypes
>>kernel32 = ctypes.windll.kernel32
>># turn on the console ANSI colour handling
>>
I am +0.5 on allowing this, unless I misunderstand the implications, this would
still raise errors in the cases where an empty tuple was not an intended
key/index/argument.
I can see that `obj[]` is less explicit than `obj[()]` but is no less clear (if
it is allowed). However, I am only +0.5
On Tue, Dec 22, 2020 at 4:46 PM Christopher Barker
wrote:
> Though, yeah shelling out to an arbitrary command on the system is a bit
> scary -- does the Python stdlib currently do that anywhere?
>
Here's what I found by grepping the sources for uses of os.system and
subprocess:
* pydoc shells
13 matches
Mail list logo
