Alex Groce added the comment:
Looks to be OS X rename, not Python
--
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http://bugs.pyt
Alex Groce added the comment:
#include
#include
#include
#include
int main () {
system("rm -rf testingdir");
mkdir("testingdir",S_IRWXU);
mkdir("testingdir/a",S_IRWXU);
mkdir("testingdir/a/a",S_IRWXU);
mkdir("testingdir/a/a/a"
Alex Groce added the comment:
Tested on latest Mac OS; mv at command line does the right thing, have not
checked a C rename yet.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Alex Groce added the comment:
Checked, and this is a problem on Python 3 as well as 2.7.
--
title: Non-atomic and unusual (wrong) rename behavior under OS X, Python 2.7.13
-> Non-atomic and unusual (wrong) rename behavior under OS X
versions: -Python
New submission from Alex Groce:
Attached file causes a failed rename, which is fine. However, after the failed
rename, the directory structure has changed (and the error reported is not very
helpful). Behavior does not match Linux or Windows behavior.
Discovered using random testing
Alex Groce added the comment:
I mean a Python long. GMP mpz (via gmpy2) is supposed to be "drop-in"
replacement, but it's choice to handle 0 << N even if N is too large to
allocate (since you get back a 1-bit number, 0) seems reasonable, if not
required for
Alex Groce added the comment:
Allocates, then fails to perform the operation (with MemoryError). Neither a
crash nor resource allocation, precisely, just fails to carry out operation GMP
integers can do under the same circumstances.
--
___
Python
Alex Groce added the comment:
AND, right shift >> does not allocate memory, so there is a lack of symmetry
that indicates the optimization might be desired.
see
https://github.com/agroce/tstl/tree/master/examples/gmpy2/leftshiftalloc.py
vs.
https://github.com/agroce/tstl/tree/master/ex
Alex Groce added the comment:
(to clarify:
0 << N
allocates memory (which can fail, raising MemoryError) based on N. GMP simply
returns 0 for any N.
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
New submission from Alex Groce:
Using a random testing system to compare Python long behavior to GMP (via
gmpy2), I notice that in a low-memory situation (created by allocating many
large integers in both Python and GMP), a left-shift of 0 by large number of
bytes:
- returns 0 via gmpy2
10 matches
Mail list logo
