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 out
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
> > b
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 standar
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 on
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 t
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 m
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 request!
> 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
>>k
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 be
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 o
13 matches
Mail list logo
