date:20180926

[issue34815] Change Py_Ellipse str behavior.

2018-09-26 Thread tom.r



tom.r  added the comment:

Frankly, because it bothered me that ``...`` evaluates to ``Ellipsis`` but that 
``Ellipsis`` could never print as ``...``.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34512] Document platform-specific strftime() behavior for non-ASCII format strings

2018-09-26 Thread Karthikeyan Singaravelan



Change by Karthikeyan Singaravelan :


--
nosy: +xtreak

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34512] Document platform-specific strftime() behavior for non-ASCII format strings

2018-09-26 Thread Tal Einat



Change by Tal Einat :


--
versions: +Python 2.7, Python 3.5

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34815] Change Py_Ellipse str behavior.

2018-09-26 Thread Karthikeyan Singaravelan



Karthikeyan Singaravelan  added the comment:

Thanks for the PR but this seems to be backwards incompatible though I don't 
know if anyone depends on this and I am curious about the reason to change. 
Since this was added in e449af7da94 (1996) and I am not sure if this needs to 
be changed though it's up to Guido to take a call. There seems to be no tests 
for this in test suite that catches this change too.

$ python2.7
Python 2.7.14 (default, Mar 12 2018, 13:54:56)
[GCC 4.2.1 Compatible Apple LLVM 7.0.2 (clang-700.1.81)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> str(Ellipsis)
'Ellipsis'
>>> repr(Ellipsis)
'Ellipsis'

Thanks

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34815] Change Py_Ellipse str behavior.

2018-09-26 Thread Serhiy Storchaka



Serhiy Storchaka  added the comment:

What is the rationale of this change?

--
nosy: +serhiy.storchaka

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34815] Change Py_Ellipse str behavior.

2018-09-26 Thread Serhiy Storchaka



Change by Serhiy Storchaka :


--
nosy: +gvanrossum

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34815] Change Py_Ellipse str behavior.

2018-09-26 Thread Karthikeyan Singaravelan



Change by Karthikeyan Singaravelan :


--
nosy: +xtreak

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32956] python 3 round bug

2018-09-26 Thread Nathaniel Smith



Nathaniel Smith  added the comment:

FWIW, I hadn't noticed this change in py3, but it would never have occurred to 
me that it's controversial... I thought everyone who'd studied the issue agreed 
that round-half-to-even was the best default :-). Numpy has always done 
round-to-even, and it's the default rounding mode mandated by IEEE754. (This 
doesn't mean that they mandate that round() itself follow this rule, but the 
implicit rounding that all floating point operations do has to follow this 
rule.) See also: https://en.wikipedia.org/wiki/Rounding#Round_half_to_even

--
nosy: +njs

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34815] Change Py_Ellipse str behavior.

2018-09-26 Thread tom.r



Change by tom.r :


--
keywords: +patch
pull_requests: +8994
stage:  -> patch review

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34815] Change Py_Ellipse str behavior.

2018-09-26 Thread tom.r



New submission from tom.r :

Added ellipsis_str function to Objects/sliceobject.c such that 
str(Ellipsis)=='...'.

--
components: Interpreter Core
files: sliceobject.c
messages: 326522
nosy: photofone
priority: normal
severity: normal
status: open
title: Change Py_Ellipse __str__ behavior.
type: enhancement
versions: Python 3.8
Added file: https://bugs.python.org/file47833/sliceobject.c

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34806] distutils tests fail with recent 3.7 branch

2018-09-26 Thread Karthikeyan Singaravelan



Karthikeyan Singaravelan  added the comment:

@doko As an update 3.7.1rc1 is available . The fixes should be there. I think 
they are worth checking out to see if the cases still fail or if you can add 
the links for the branches 20180925 and 20180911 snapshot. I can do a clean 
rebuild of these branches to test them.

3.7.rc1 announcement : 
https://mail.python.org/pipermail/python-dev/2018-September/155329.html

Thanks

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34803] argparse int type does not accept scientific notation

2018-09-26 Thread paul j3



paul j3  added the comment:

The `type` parameter is normally a function (or more generally a callable).  
When given a string it should convert it as needed, or raise an error.  In your 
example that function is the stock, 'int()'.

Test `int('123')`, `int('1e3')` etc for yourself to see what it can handle.

If you want to convert '1e3' to an integer, write your own function that handle 
it.  Don't expect argparse or the stock int() to do it for you.

More commonly people use 'type=bool', expecting it convert 'True' or 'False' 
strings to boolean values.  But that's not what the bool() function does.

To reiterate, 'type' is a function, not a desired class.

Since this is not a bug, I think this should be closed.

--
nosy: +paul.j3

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34744] New %(flag)s format specifier for argparse.add_argument help string

2018-09-26 Thread paul j3



paul j3  added the comment:

The preferred way of adding new features to the Formatter is to subclass it, 
and modify one or more methods.  That's what the existing alternative 
formatters do.

A user can easily create such a subclass, and use it with their own parser, 
without having to modify the stock `argparse.py` file.

Given that flexibility, adding new features (as opposed to bug fixes) to the 
help formatter should have a low priority.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31551] test_distutils fails if current directory contains spaces

2018-09-26 Thread Karthikeyan Singaravelan



Karthikeyan Singaravelan  added the comment:

There is a similar issue with whitespace in filenames causing failure in 
bdist_rpm tracked at issue809163. It has test cases but unfortunately the issue 
didn't move forward and has only patches. I tried the patches but none of them 
seem to fix the issue here. The issue seems to be in spec file generation with 
space in path of python executable. Did some debugging and my analysis as 
follows. Renamed my source directory 'cpython' as 'cpy thon' and made a clean 
build. It seems that sys.executable returns '/home/karthi/cpy thon/python' 
which is used as the python binary for the commands and hence with normal 
string concatenation the spec file generated [0] . I tried very basic fix of 
sys.executable.replace(' ', '\ ') to be used as a path. It generates the 
correct spec file [1] which passes and ./python -m test -vuall test_distutils 
also passes.

I am not sure if Python has a function to escape spaces for shell commands 
which would be more reliable. I tried shlex.quote but it handles only ' and ". 
I think having space in the directory might cause issues in places where we use 
string concatenation with sys.executable without taking spaces into account 
like the other issue with windows. I will try running the test suite sometime 
with space.

[0] With spaces. The commands that fail are /home/karthi/cpy thon/python 
setup.py build and /home/karthi/cpy thon/python setup.py install -O1 
--root=$RPM_BUILD_ROOT --record=INSTALLED_FILES

%define name foo
%define version 0.1
%define unmangled_version 0.1
%define release 1

Summary: UNKNOWN
Name: %{name}
Version: %{version}
Release: %{release}
Source0: %{name}-%{unmangled_version}.tar.gz
License: UNKNOWN
Group: Development/Libraries
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-buildroot
Prefix: %{_prefix}
BuildArch: noarch
Vendor: xxx 
Url: xxx

%description
UNKNOWN

%prep
%setup -n %{name}-%{unmangled_version}

%build
/home/karthi/cpy thon/python setup.py build

%install
/home/karthi/cpy thon/python setup.py install -O1 --root=$RPM_BUILD_ROOT 
--record=INSTALLED_FILES

%clean
rm -rf $RPM_BUILD_ROOT

%files -f INSTALLED_FILES
%defattr(-,root,root)


[1] sys.executable.replace(' ', '\ ') and the tests pass


%define name foo
%define version 0.1
%define unmangled_version 0.1
%define release 1

Summary: UNKNOWN
Name: %{name}
Version: %{version}
Release: %{release}
Source0: %{name}-%{unmangled_version}.tar.gz
License: UNKNOWN
Group: Development/Libraries
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-buildroot
Prefix: %{_prefix}
BuildArch: noarch
Vendor: xxx 
Url: xxx

%description
UNKNOWN

%prep
%setup -n %{name}-%{unmangled_version}

%build
/home/karthi/cpy\ thon/python setup.py build

%install
/home/karthi/cpy\ thon/python setup.py install -O1 --root=$RPM_BUILD_ROOT 
--record=INSTALLED_FILES

%clean
rm -rf $RPM_BUILD_ROOT

%files -f INSTALLED_FILES
%defattr(-,root,root)


I am adding 3.8 also as a target as part of triaging this issue.

Thanks

--
versions: +Python 3.8

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34370] Tkinter scroll issues on macOS

2018-09-26 Thread Ned Deily



Ned Deily  added the comment:

FYI, for the python.org binary macOS installers for the 3.7.1rc1 and 3.6.7rc1 
releases, I cherry-picked a post-8.6.8 development snapshot of Tk 8.6 that 
should include Kevin's fix.  I would appreciate any feedback one way or the 
other whether this version of Tk 8.6 improves things over the vanilla 8.6.8 
version used for the 3.7.0 and 3.6.6 releases.  Thanks!

--
nosy: +rhettinger
resolution:  -> third party
stage:  -> commit review
status: open -> pending

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34370] Tkinter scroll issues on macOS

2018-09-26 Thread Ned Deily



Ned Deily  added the comment:


New changeset d9cfe5ed2c2c61eeae915b76f5e10aadbbb28da6 by Ned Deily in branch 
'3.7':
bpo-34370: Update Tk 8.6 used with macOS installers
https://github.com/python/cpython/commit/d9cfe5ed2c2c61eeae915b76f5e10aadbbb28da6


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34370] Tkinter scroll issues on macOS

2018-09-26 Thread Ned Deily



Ned Deily  added the comment:


New changeset adf493227f1efd5d6b34f46b854142bf3b5a411c by Ned Deily in branch 
'3.6':
bpo-34370: Update Tk 8.6 used with macOS installers
https://github.com/python/cpython/commit/adf493227f1efd5d6b34f46b854142bf3b5a411c


--
nosy: +ned.deily

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31405] shutil.which doesn't find files without PATHEXT extension on Windows

2018-09-26 Thread Eryk Sun

Eryk Sun added the comment:

In a patch review [1] for issue 24505, I had a discussion with Toby Tobkin
about extending the behavior of shutil.which() on Windows. This was to match
the behavior of the CMD shell, including securing the search path via
NeedCurrentDirectoryForExePath, searching for the exact filename, and
implementing a real execute-access check.

CMD won't directly execute a file that lacks execute access -- even a script or
data file. We can implement this with a real implementation of os.access() that
checks file security, for which there's an existing issue. (My previous
suggestion to use CreateProcess and AssocQueryString to check for execute
access was over the top. At the time I was thinking about building out support
for a high-level shutil.execute, but it's out of scope here.)

Note that CMD will only try to execute an extensionless file if "." is in
PATHEXT. (In the Windows file namespace, "name" and "name." are equivalent.)
This obviously works for PE binaries, but we can also define an association for
"." in the registy, which is useful for extensionless script files. Just
associate "." files with a launcher that tries CreateProcess and falls back on
a shebang line.

[1]:
https://web.archive.org/web/20170619131224/http://bugs.python.org:80/review/24505/diff/16179/Lib/shutil.py

--
nosy: +eryksun

___
Python tracker

___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34691] _contextvars missing in xmaster branch Windows build?

2018-09-26 Thread Helena Centanin



Helena Centanin  added the comment:

Good night I installed the python program at the start it appears this message
Python 3.7.0 (v3.7.0:1bf9cc5093, Jun 27 2018, 04:06:47) [MSC v.1914 32 bit 
(Intel)] on win32
Type "copyright", "credits" or "license()" for more information.
>>>

--
components: +Installation -Build, Library (Lib), Windows
nosy: +helena.marina
title: _contextvars missing in x64 master branch Windows build? -> _contextvars 
missing in xmaster branch Windows build?
versions: +Python 3.7 -Python 3.8
Added file: https://bugs.python.org/file47832/Captura de Tela (12).png

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34751] Hash collisions for tuples

2018-09-26 Thread Tim Peters



Tim Peters  added the comment:

>> The two-liner above with the xor in the second line is
>> exactly Bernstein 33A, followed by a permutation
>> of 33A's _output_ space.

> Not output space, but internal state

?  33A's output _is_ its internal state at the end.  This is a distinction that 
makes no difference.  I do distinguish here between 33A and the output of 
Python's `tuplehash()`, but the output space of both on a 64-bit box is a 
64-bit int, so that's another pointless distinction to me.

> (I assume that you do that operation inside the loop).

Yes, as I said at the start, "this is the only code remaining in the loop apart 
from setting y to the next tuple component's hash".

> It's replacing DJBX33A by a different algorithm which is not
> DJBX33A.

Replacing DJBX33A's multiplier of 33 is also a different algorithm.  So is 
working with inputs other than unsigned bytes.  So is mucking with the inputs 
before adding them in.

> It may or may not work, that's not my point. It's just that
> I would avoid changing the structure of the algorithm if
> there is no reason to.

Which is also fine by me, except I see no actual reason to care.  All 
variations of "chain permutations" I've tried appear to work fine, except for 
those (which I haven't mentioned at all) that tried replacing multiplication 
with "weaker" permutations.

A minor exception is that, as already mentioned, applying the "leftshift-xor" 
permutation to the inputs with a shift count of 1 didn't pass the original 
tuple hash test in several cases.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31425] Expose AF_QIPCRTR in socket module

2018-09-26 Thread Tal Einat



Tal Einat  added the comment:


New changeset f55c64c632af438d0daa043acdd95a5e74f31441 by Tal Einat in branch 
'master':
bpo-31425: fix versionadded in docs and add attribution in NEWS (GH-9595)
https://github.com/python/cpython/commit/f55c64c632af438d0daa043acdd95a5e74f31441


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31425] Expose AF_QIPCRTR in socket module

2018-09-26 Thread Tal Einat



Change by Tal Einat :


--
pull_requests: +8993

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34521] test_socket.RecvmsgIntoSCMRightsStreamTest fails on AMD64 FreeBSD CURRENT Debug 3.x

2018-09-26 Thread Pablo Galindo Salgado



Change by Pablo Galindo Salgado :


--
keywords: +patch
pull_requests: +8992
stage:  -> patch review

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34751] Hash collisions for tuples

2018-09-26 Thread Jeroen Demeyer



Jeroen Demeyer  added the comment:

> The two-liner above with the xor in the second line is exactly Bernstein 33A, 
> followed by a permutation of 33A's _output_ space.

Not output space, but internal state (I assume that you do that operation 
inside the loop). It's replacing DJBX33A by a different algorithm which is not 
DJBX33A. It may or may not work, that's not my point. It's just that I would 
avoid changing the structure of the algorithm if there is no reason to.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34814] makesetup: must link C extensions to libpython when compiled in shared mode

2018-09-26 Thread Xavier de Gaye



Xavier de Gaye  added the comment:

> Downstream (RHEL) issue:
> https://bugzilla.redhat.com/show_bug.cgi?id=1585201

Not sure that this is a bug. As Petr Viktorin points out in Comment #4, the 
reproducer is not expected to work because of the semantics of RTLD_LOCAL.

So the current bpo issue would be related only to a slight inconsistency 
between the build of extension modules by distutils and those built by the 
Makefile.

However, it seems that the loader of Android requires that those libraries be 
explicitly linked against libpython:

* The last paragraph on https://github.com/termux/termux-packages and the 
related termux issue "Shared library symbols not visible on dlopen()?" (at 
https://github.com/android-ndk/ndk/issues/201) explain this point.

* The issue I have submitted to pyephem "android cross-build needs the 
extension module to be linked against the math library" at 
https://github.com/brandon-rhodes/pyephem/issues/114 confirms this point on 
Android API level 21.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34751] Hash collisions for tuples

2018-09-26 Thread Jeroen Demeyer



Jeroen Demeyer  added the comment:

> please restore the original tuple hash test.

Sure. I wasn't sure what to do and was I afraid that having 2 tests for tuple 
hashes would be too much. If that's OK for you, then surely I will restore the 
test.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34751] Hash collisions for tuples

2018-09-26 Thread Jeroen Demeyer



Jeroen Demeyer  added the comment:

> Do you believe any other multiplier would work better toward that end?

Absolutely. Ideally, the multiplier should just be a random 64-bit number.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31405] shutil.which doesn't find files without PATHEXT extension on Windows

2018-09-26 Thread Steve Dower



Steve Dower  added the comment:

It certainly doesn't match "which" semantics, but given the F_OK and X_OK flags 
I can see cases where it ought not to. I'm not sure it does what it implies for 
those either though.

I can see uses for "find files according to 'which'" and "find executable files 
according to 'which'".

Either way, I don't see an easy way to change the semantics any earlier than 
3.8, so changing the target.

--
versions: +Python 3.8 -Python 3.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34751] Hash collisions for tuples

2018-09-26 Thread Tim Peters



Tim Peters  added the comment:

High-order bit:  please restore the original tuple hash test.  You have the 
worst case of "but I didn't write it" I've ever encountered ;-)  Your new test 
is valuable, but I've seen several cases now where it fails to detect any 
problems where the original test fails catastrophically.  Tests are written to 
ensure known problems don't recur, so there's _never_ "a reason" to throw one 
away unless the test itself is in error.  The test suite only grows over time, 
and that's how it should be.

Example:  when I replace the computational guts of the tuple hash with the 
single line (64-bit build, and this is the only code remaining in the loop 
apart from setting y to the next tuple component's hash):

x = (x * mult) + y;

both tests fail spectacularly.

But if I add one more line:

x = (x * mult) + y;
x += x >> 16;

your new test falls to 0 collisions, while the original test still suffers 
83447 collisions (an improvement - down from 120050 - but still a spectacular 
failure).

We're flying blind enough here without deliberately plucking out one of our 
eyes ;-)  Indeed, the original tuple test is the only one in my collection that 
showed even a single collision after the two-line replacement just above.  "My 
collection" means your test, the original tuple hash test, and every example 
given in all the messages in this bug report.

Another "surprise":  replace addition with xor in the second line above:

x = (x * mult) + y;
x ^= x >> 16;

and then the original tuple test drops from 83447 to 0(!) collisions, while 
your new one jumps from 0 to a measly 12.


> The collision hash((3,3)) == hash((-3,-3)) is due a specific
> structure in the input to the FNV algorithm.

This is all so hypothetical it's impossible to know.  Perhaps the tuple hash 
function simply subtracts the hash of the first component from the hash of the 
second.  Then it's impossible to make any deterministic change to the component 
hashes that can stop either of the tuples from hashing to 0.  The weakness is 
entirely in the hash combining function then.

> The operation t ^= t << 7 that you suggested (and which I approve, except
> for the shift amount) is meant precisely to destroy that structure.

Except I have no reason to believe that destroying the input structure is of 
unique value.  As shown above, it's easy to change the tuple hash in a simple 
way that passes all known tests without touching `y` (aka `t`) at all.

>> It's x you care about directly, not t.

> That would not be a good solution, because that destroys the structure
> of the hash algorithm.   For Bernstein for example, each loop iteration
> should do something like
>
>x = (x * m) + t
>
> for *some* value t depending on the input. If you mess with x, then it
> really becomes a different hash algorithm.

The two-liner above with the xor in the second line is exactly Bernstein 33A, 
followed by a permutation of 33A's _output_ space.  It works fine in tests.  
Why should I care about merely that it's "different"?  33A on its own fails 
spectacularly - it damned well _better_ be "different" ;-)

There is no "Bernstein theory" to appeal to here - just raw assertions.  I'm 
not attached to any of these approaches.  The strongest I can say from trying 
many things is that "chaining permutations works best, but no detail appears to 
matter much, except that multiplication is the most valuable of all the 
permutations I've tried".

x*M is a permutation of the word-size space for any odd M, and any "big enough" 
odd M I tried appears to work about as well as any other.  Adding t is another. 
 The shift-xor in the second line above is a third (but the "+=" version 
instead was not a permutation, and it failed).

> That is far more dangerous than simply applying a permutation on t.

Why?

> Which "desirable properties" of t does the operation t ^= (t << 1) damage?

On second thought, none!  Across any contiguous range of integers, that 
preserves that the last k bits (for all k >= 1) remain as evenly distributed as 
in the inputs.  That wasn't obvious to me at first.  It's not true if the left 
shift is replaced by a right shift, though.

However, with a shift count of 1 I've generally found that the _original_ tuple 
hash test fails (not spectacularly, but fails all the same).  "Generally" means 
across a substantial number of varying the permutations used in other places.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34771] test_ctypes failing on Linux SPARC64

2018-09-26 Thread Frank Schaefer



Frank Schaefer  added the comment:

Further details:

I cloned libffi from a few days ago to see if I had any different behavior.  So 
far the test fails the same way with the updated libffi.

I'll also see about contacting libffi upstream and see what they can suggest 
here.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2771] Test issue

2018-09-26 Thread Ned Batchelder



Ned Batchelder  added the comment:

Also a test.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31405] shutil.which doesn't find files without PATHEXT extension on Windows

2018-09-26 Thread Ryan McCampbell



Ryan McCampbell  added the comment:

This is how windows looks up commands, as well as the built in "where" command. 
(Note that windows doesn't actually distinguish between "executable" files and 
just plain old files, so this could be confusing for UNIX users... a text file 
for instance will simply open in the default text editor when "executed" by the 
shell.)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31405] shutil.which doesn't find files without PATHEXT extension on Windows

2018-09-26 Thread Paul Moore



Paul Moore  added the comment:

On further reflection, I'm less sure that the proposed behaviour is the best 
option, but I do think this warrants further consideration.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34022] 6 tests fail using SOURCE_DATE_EPOCH env var

2018-09-26 Thread Eli Schwartz



Change by Eli Schwartz :


--
nosy: +eschwartz

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31405] shutil.which doesn't find files without PATHEXT extension on Windows

2018-09-26 Thread Paul Moore



Paul Moore  added the comment:

I don't think this is expected behaviour. It's not documented what should 
happen in this case but the behaviour suggested by the OP (to search for the 
path as given, followed by [path+e for e in 
os.environ['PATHEXT'].split(os.pathsep)] seems reasonable to me.

The details and corner cases need thrashing out, which I don't have time to do 
right now, but the principle seems sound.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34781] infinite waiting in multiprocessing.Pool

2018-09-26 Thread Tomáš Bouda


Tomáš Bouda  added the comment:

By now I have spent several days trying to reproduce the behaviour in 
production environment with debugger attached. Unfortunately, no success. On 
the other hand yesterday the application froze, again, and colleague today 
experienced the problem in his script, too. (talking about RHEL)

Dealing with this kind of problem is always very frustrating.

By now, I agree with @pitrou that OSX/RHEL could be two different problems. In 
advance, I tried the approach by @calimeroteknik and this would actually make 
sense.

If the child process receives a signal (SIGTERM or SIGSEGV), parent waits 
forever. We do call 3rd party libraries and segfault is indeed possible. I've 
tried to send signal to a child and script really froze. By now, it seems to be 
the most probable explanation.

OSX debugger may also be buggy, yesterday I completely broke my system just by 
trying my original script, leading to a regular segfaults and system restart 
(never happened before).

Since I can't reproduce the problem under controlled conditions, I am ok with 
closing this bug. The script by @calimeroteknik seems to be pointing in the 
same direction and I think this may solve our problem, too.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31405] shutil.which doesn't find files without PATHEXT extension on Windows

2018-09-26 Thread Serhiy Storchaka



Serhiy Storchaka  added the comment:

Isn't this an expected behavior?

--
nosy: +serhiy.storchaka

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34694] Dismiss To Avoid Slave/Master wording cause it easier for non English spoken programmers

2018-09-26 Thread Matthew Barnett



Change by Matthew Barnett :


--
nosy:  -mrabarnett

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31405] shutil.which doesn't find files without PATHEXT extension on Windows

2018-09-26 Thread Karthikeyan Singaravelan



Karthikeyan Singaravelan  added the comment:

I am adding windows as a component during triaging since PATHEXT seems to be 
windows specific. Unfortunately, I couldn't verify this since I don't have 
windows system to check this against master so leaving it to 3.6.

Thanks

--
components: +Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31551] test_distutils fails if current directory contains spaces

2018-09-26 Thread Karthikeyan Singaravelan



Change by Karthikeyan Singaravelan :


--
nosy: +xtreak

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31405] shutil.which doesn't find files without PATHEXT extension on Windows

2018-09-26 Thread Karthikeyan Singaravelan



Change by Karthikeyan Singaravelan :


--
nosy: +xtreak

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34813] child process disappears when removing a print statement after its creation

2018-09-26 Thread Antoine Pitrou



Antoine Pitrou  added the comment:

Indeed!

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34814] makesetup: must link C extensions to libpython when compiled in shared mode

2018-09-26 Thread Antoine Pitrou



Antoine Pitrou  added the comment:

Of course, one workaround to satisfy everyone would be to build a (empty) 
libpython.so even on static Python builds.  But I'm not sure Debian/Ubuntu 
would package it.

--
nosy: +doko

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34814] makesetup: must link C extensions to libpython when compiled in shared mode

2018-09-26 Thread Antoine Pitrou



Antoine Pitrou  added the comment:

Why do you call this a bug?
For me it's the reverse: it's linking to libpython.so which is a bug.  It means 
a C extension compiled with a shared-library Python cannot be imported on a 
monolithic Python (which doesn't have libpython.so).  It's a real problem when 
you want to redistribute compiled C extensions: if you compile it on 
RedHat/CentOS, it won't work on Ubuntu/Debian (the reverse works).

I even opened an issue about that: issue21536
("extension built with a shared python cannot be loaded with a static python")

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34813] child process disappears when removing a print statement after its creation

2018-09-26 Thread calimeroteknik



calimeroteknik  added the comment:

So this is invalid library usage, we need to run .wait() on the Popen object.

--
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

1 2 >

1 - 100 of 144 matches

Mail list logo