On 29/07/2018 02:04, Jeremy Kloth wrote:
On Sat, Jul 28, 2018 at 6:43 PM Brett Cannon
wrote:
If Windows doesn't clean up its temp directory on a regular basis
then that doesn't suggest to me not to use tempfile, but instead
that the use of tempfile still needs to clean up after itself. And
if t
On 28/07/2018 22:17, Jeremy Kloth wrote:
On Sat, Jul 28, 2018 at 11:20 AM Tim Golden wrote:
Although things have moved on since that discussion and
test.support.unlink has grown some extra legs, all it's done really is
to push the bump along the carpet for a bit. I've got a newly-installed
Win1
Currently C API is not completely covered by tests. Tests for particular
parts of C API are scattered through different files. There are files
completely purposed for testing C API (like test_capi.py,
test_getargs2.py), there are classes (usually having "CAPI" in the name)
in different files fo
On 29Jul2018 0958, Tim Golden wrote:
In the interests of trying to keep a focus to the changes I'm making, I
propose to start again by, as you suggest, making use of
test.support.unlink where it's not currently used. From the evidence I
don't believe that will solve every problem I'm seeing but
On 29Jul2018 1253, Serhiy Storchaka wrote:
The benefit is that it will be easier to run all C API tests at once,
and only them, and it will be clearer what C API is covered by tests.
The disadvantage is that you will need to run several files for testing
marshal for example.
Can we make the r
29.07.18 15:39, Steve Dower пише:
On 29Jul2018 1253, Serhiy Storchaka wrote:
The benefit is that it will be easier to run all C API tests at once,
and only them, and it will be clearer what C API is covered by tests.
The disadvantage is that you will need to run several files for
testing marsh
On Sun, Jul 29, 2018 at 9:13 AM, Tim Golden wrote:
>
> For an example:
>
> http://tjg.org.uk/test.log
>
> Thinkpad T420, 4Gb, i5, SSD
>
> Recently rebuilt and reinstalled: Win10, VS2017, TortoiseGit, standard
> Windows Antimalware, usual developer tools. That particular run was done
> with the lap
On Sun, Jul 29, 2018 at 3:13 AM Tim Golden wrote:
> For an example:
>
> http://tjg.org.uk/test.log
Thank you! After inspecting all the errors, it does seem that they
are ALL caused by "bare" os.unlink/rmdir calls. So it seems that a
massive undertaking of ferreting out these locations and repla
On Sun, Jul 29, 2018 at 12:35 PM, Steve Dower wrote:
>
> One additional thing that may help (if support.unlink doesn't already do it)
> is to rename the file before deleting it. Renames are always possible even
> with open handles, and then you can create a new file at the original name.
Renaming
On Sun, Jul 29, 2018 at 2:21 PM, Jeremy Kloth wrote:
>
> try:
> os.rename(new_file.name, self._path)
> except FileExistsError:
> -os.remove(self._path)
> +temp_name = _create_temporary_name(self._path)
> +os.rename(self._path, temp
On 29/07/2018 15:21, Jeremy Kloth wrote:
On Sun, Jul 29, 2018 at 3:13 AM Tim Golden wrote:
For an example:
http://tjg.org.uk/test.log
Thank you! After inspecting all the errors, it does seem that they
are ALL caused by "bare" os.unlink/rmdir calls. So it seems that a
massive undertaking of
Hello Python list,
I intend to cross-compile Python v3.6.6 to Threos ( https://threos.io )
operating system. Threos is supports a quite large set from POSIX and
C89/C99. Unfortunately, Threos lacks fork(2), but provides
posix_spawn(3) instead. I already made some local changes in
posixmodule.
On Sun, Jul 29, 2018 at 9:34 AM Tim Golden wrote:
> For test_mailbox I've experimentally implemented a hybrid tempfile /
> local directory solution. ie I've created a new file on each run, but
> only within the python_ folder which already exists. As long as the
> directory cleans up there should
On Sun, Jul 29, 2018 at 5:44 PM, Barath Aron wrote:
> My question is that the _posixsubprocess.c can be prepared to use
> posix_spawn(3) instead of fork(2)? Maybe the UNIX/Linux version can also
> benefit from it, see:
> https://salsa.debian.org/ruby-team/ruby-posix-spawn
There is an open issue t
If the problem is AV scanners, then they should be opening them properly for
this (and since the delete is not failing but is being deferred, I assume it's
allowing deletes). If the problem is elsewhere in our code base then we have a
different bug.
Top-posted from my Windows 10 phone
From: er
On Sun, Jul 29, 2018, 06:44 Serhiy Storchaka, wrote:
> 29.07.18 15:39, Steve Dower пише:
> > On 29Jul2018 1253, Serhiy Storchaka wrote:
> >> The benefit is that it will be easier to run all C API tests at once,
> >> and only them, and it will be clearer what C API is covered by tests.
> >> The di
Hi,
I just sent an email to the capi-sig mailing list. Since this mailing
list was idle for months, I copy my email here to get a wider
audience. But if possible, I would prefer that you join me on capi-sig
to reply ;-)
--
Hi,
Last year, I gave a talk at the Language Summit (during Pycon) to
ex
On 07/29/2018 06:02 PM, Berker Peksağ wrote:
There is an open issue to add os.posix_spawn() at
https://bugs.python.org/issue20104
Seems promising, but 3.7 does not support it. And I don't see whether
Python will work without fork().
- bpo-20104: Expose posix_spawn as a low level API in the os m
My first impression is that making things faster and hiding
implementation details in the ABI are contrary goals. I agree with
hiding implementation details in the API but not in the ABI.
For example, you mention that you want to make Py_INCREF() a function
call instead of a macro. But since P
2018-07-29 23:41 GMT+02:00 Jeroen Demeyer :
> For example, you mention that you want to make Py_INCREF() a function call
> instead of a macro. But since Py_INCREF is very common, I would guess that
> this would make performance worse (not by much maybe but surely measurable).
For the very specific
On Mon, Jul 30, 2018 at 10:46 AM, Victor Stinner wrote:
> 2018-07-29 23:41 GMT+02:00 Jeroen Demeyer :
>> For example, you mention that you want to make Py_INCREF() a function call
>> instead of a macro. But since Py_INCREF is very common, I would guess that
>> this would make performance worse (no
> On Jul 29, 2018, at 4:53 AM, Serhiy Storchaka wrote:
>
> The benefit is that it will be easier to run all C API tests at once, and
> only them, and it will be clearer what C API is covered by tests. The
> disadvantage is that you will need to run several files for testing marshal
> for ex
22 matches
Mail list logo
