[issue27641] Do not build Programs/_freeze_importlib when cross-compiling

[Thomas Perl]

New submission from Thomas Perl:

Based on http://bugs.python.org/issue27490 and 
http://bugs.python.org/msg271495, here is a patch that makes sure 
Programs/_freeze_importlib is only built when not cross-compiling.

--
components: Cross-Build
files: python-freeze-importlib-cross-compiling.patch
keywords: patch
messages: 271519
nosy: Alex.Willmer, Thomas Perl, martin.panter
priority: normal
severity: normal
status: open
title: Do not build Programs/_freeze_importlib when cross-compiling
type: behavior
versions: Python 2.7, Python 3.6
Added file: 
http://bugs.python.org/file43920/python-freeze-importlib-cross-compiling.patch

___
Python tracker 

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

[issue26851] android compilation and link flags

[Martin Panter]

Martin Panter added the comment:

All the bits that I understand look okay now. :)

I am still curious what configures the preprocessor to set __ARM_ARCH to 7 (I 
guess the clang -target argument?), and why we can’t set LDFLAGS at the same 
time or place. Is it just more convenient this way?

--

___
Python tracker 

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

[issue26852] add the '--enable-legacy-pyc-files' option to configure

[Matthias Klose]

Changes by Matthias Klose :


--
nosy: +barry

___
Python tracker 

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

[issue26852] add the '--enable-legacy-pyc-files' option to configure

[Matthias Klose]

Matthias Klose added the comment:

hmm, I really don't buy the space-saving argument.  you are saving some space 
with shorter path names, nothing more. so why do you introduce this option?

--

___
Python tracker 

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

[issue27640] add the '--disable-test-suite' option to configure

[Xavier de Gaye]

Changes by Xavier de Gaye :


--
nosy: +haypo, thomas-petazzoni

___
Python tracker 

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

[issue26852] add the '--enable-legacy-pyc-files' option to configure

[Xavier de Gaye]

Changes by Xavier de Gaye :


--
nosy: +haypo, thomas-petazzoni

___
Python tracker 

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

[issue26865] Meta-issue: support of the android platform

[Xavier de Gaye]

Xavier de Gaye added the comment:

issue #27640: add the '--disable-test-suite' option to configure

--
dependencies: +add the '--disable-test-suite' option to configure

___
Python tracker 

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

[issue26852] add the '--enable-legacy-pyc-files' option to configure

[Xavier de Gaye]

Xavier de Gaye added the comment:

Install byte-code files to their legacy locations and names to save space 
(default are the PEP 3147 locations and names) when configure is run with 
'--enable-legacy-pyc-files'.

The patch does not prevent ensurepip to use PEP 3147 locations and names when 
it is run at the end of the installation.

As many tests use the linecache module, it makes sense to skip the installation 
of the test suite aas well since the patch removes all *.py files (except those 
installed by ensurepip in site-packages). This can be done when issue 27640 is 
resolved by using '--disable-test-suite'.

The size of the standard library [1] [2]:
plain install: 111M
--disable-test-suite: 53M
--enable-legacy-pyc-files --disable-test-suite: 23M
--enable-legacy-pyc-files --disable-test-suite --with-ensurepip=no: 14M

[1] without the extension modules
[2] excluding the LIBPL directory that is installed at --prefix instead of 
--exec-prefix for some reason and that contains miscellaneous stuff needed for 
extending/embedding. This is not needed on a mobile device that does not have 
any build tool.

--
components: +Build
nosy: +doko, martin.panter
stage:  -> patch review
title: android: add a COMPILEALL_FLAGS Makefile variable -> add the 
'--enable-legacy-pyc-files' option to configure
Added file: http://bugs.python.org/file43919/legacy-pyc-files.patch

___
Python tracker 

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

[issue27640] add the '--disable-test-suite' option to configure

[Xavier de Gaye]

Changes by Xavier de Gaye :


--
components: +Cross-Build
nosy: +Alex.Willmer

___
Python tracker 

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

[issue27640] add the '--disable-test-suite' option to configure

[Xavier de Gaye]

Changes by Xavier de Gaye :


Added file: http://bugs.python.org/file43918/listdirs.py

___
Python tracker 

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

[issue27640] add the '--disable-test-suite' option to configure

[Xavier de Gaye]

New submission from Xavier de Gaye:

Do not install the Python test suite when configure is run with 
'--disable-test-suite'. This about divides by two the size of the installed 
standard library.

Related to issue 26852: add the '--enable-legacy-pyc-files' option to configure.

The attached listdirs.py script may be used to check that the set of 
sub-directories in the std library is not changed by the patch.

--
assignee: xdegaye
components: Build
files: disable-test-suite.patch
keywords: patch
messages: 271514
nosy: doko, martin.panter, xdegaye
priority: normal
severity: normal
stage: patch review
status: open
title: add the '--disable-test-suite' option to configure
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file43917/disable-test-suite.patch

___
Python tracker 

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

[issue27435] ctypes and AIX - also for 2.7.X (and later)

[Michael Felt]

Michael Felt added the comment:

Adding "type behavior" as I have now read that that is actually the python 
friendly way of talking about a 'bug'.

Testing my proposed patch for 2.7 with python2.7.12 - will update with patch 
when finished.

--
nosy: +Michael.Felt
type:  -> behavior

___
Python tracker 

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

[issue9998] ctypes find_library should search LD_LIBRARY_PATH on linux

[Michael Felt]

Michael Felt added the comment:

Getting back to this summary:
Windows: {name} and {name}.dll, via %PATH%
OS X: lib{name}.dylib, {name}.dylib and {name}.framework/{name}, via dyld_find()
BSD: lib{name}.* via ldconfig (choose highest ABI version) and cc
Solaris: lib{name}.so via crle, and lib{name}.* via cc
Gnu: lib{name}.* via ldconfig and cc

The "Gnu" selection is what is used for "None of the above", so also for AIX - 
which generally has neither ldconfig nor cc installed.

Having worked on a patch for AIX so that something that is (aka should) always 
there (dump) for examining archives for dlopen() openable objects.

In another issue I have had the benefit of lots of feedback from Martin Panter 
- most of which I agree with.

As this issue is about enhancement my feedback re: AIX behavior of dlopen() is 
that dlopen() takes LD_LIBRARY_PATH (when LIBPATH is not defined) into account.

In general find_library() is used as: CDLL(find_library("xxx")) - as in I do 
not care if the result is None or libxxx.so.y.z - just do it. However, if 
find_library() and CDLL() are written so that they "find" the same library 
object then it does become possible for a programmer to verify that a supported 
version is what will be loaded.

The return value from find_library() should be related to it's argument - just 
as dlopen() would 'react' (better, search *PATH*). If no path element ("./*" | 
"../*", or "/*") then no path element should be in the return value. The case 
for using path elements is because find_library() could be used to verity it's 
existence before calling CDLL() - what I did not know initially, but consider 
vital for proper behavior is that CDLL(NULL) just returns 'python' itself.

To underline that there are many issues that have been left unaddressed for 
years (this discussion here is nearly 6 years old) I mention:
"The case of python calling find_library("uuid") - on AIX this is probably 
NULL, as libuuid.so(.X) is not native to AIX - and even if it is present will 
not be found via a non-existent ldconfig or cc (only thing the "Gnu" option 
even considers).

IMHO: find_library should reflect dlopen() - with find_library being, as 
documented.

>From the Python2.6 documentation (when introduced?)
"""The purpose of the find_library() function is to locate a library in a way 
similar to what the compiler does (on platforms with several versions of a 
shared library the most recent should be loaded), while the ctypes library 
loaders act like when a program is run, and call the runtime loader directly.

The ctypes.util module provides a function which can help to determine the 
library to load.

ctypes.util.find_library(name)
Try to find a library and return a pathname. name is the library name 
without any prefix like lib, suffix like .so, .dylib or version number (this is 
the form used for the posix linker option -l). If no library can be found, 
returns None.

The exact functionality is system dependent."""

This pre-dates my experience with python, so if I inaccurate in assumptions - 
correct me, but please be patient with me.

What I miss is a PEP on this topic. From the limited reads of other PEPs I have 
read I think (rather hope) that inconsistencies in documentation could have 
been caught.

While (as Martin mentioned earlier in this discussion) find_library() behaves 
as "build" aka cc/gcc and CDLL follows "run-time" loader. imho, this is 
inconsistent - and the inconsistency is also in that short bit of documentation:

a) """The purpose of the find_library() function is to locate a library in a 
way similar to what the compiler does (on platforms with several versions of a 
shared library the most recent should be loaded) (i.e., always find the latest 
version)"""

and
b)"""The ctypes.util module provides a function which can help to determine the 
library to load.""" IMHO: how it is expected to be used because I (i.e., the 
python programmer) cannot provide additional specification to locate a specific 
version - find_library() is meant to find the latest always

As the Python3.5.2 documentation is nearly verbatim - this is still the 
documented condition.

So - I am very happy about Martin's (partial) comment:
maybe changing towards run-time would not be such a problem as I first thought.

CDLL() does a search, by definition. Maybe I do not care what it finds - but 
the argument to it is expected to platform dependent.
The "remaining" limitation of find_library(), even with searching *PATH* 
included is that it MUST also return the latest version (as a request for a 
specific version may not be made, or any other "extension"). An additional 
weakness is that what it "finds" must always be prefixed by "lib", while 
dlopen() has not such requirement. (FYI: I ran into these 'unusual' shared 
libraries while packaging sudo. While it is unlikely that python would ever 
load these sudo libraries it does show that there can be shared libraries that 
can accessed by not "found")

[issue26462] Patch to enhance literal block language declaration

[Julien]

Julien added the comment:

Hi,

You're right, nice catch!

Removing `python -q` from the code block demonstrating it was a bad idea. I 
fixed it in the v6.

Thanks!

--
Added file: http://bugs.python.org/file43916/issue26462.v6.diff

___
Python tracker 

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

[issue27638] int.to_bytes() and int.from_bytes() should support 'net' and 'host' byte orders

[Марк Коренберг]

Марк Коренберг added the comment:

1. Yes 'host' is the same as sys.buteorder
2. Yes, 'net' is the same as 'big'
3. See `struct` module: it have '!' for those who forgot which order is 
`network`. In most cases (i.e. some protocols or formats) 'network' order is 
used.
4. Support of new values will actually slightly complicate code. I will say 
just change, not complicte.
5. This patch will add two extra string comparings. This should not slowdown 
current implementation significantly. I can benchmark it.

--

___
Python tracker 

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

[issue26462] Patch to enhance literal block language declaration

[Martin Panter]

Martin Panter added the comment:

V5 looks pretty good to me. With your blessing of restoring the python -q 
example from v4 (see review), I think it is ready to commit.

--
stage: patch review -> commit review

___
Python tracker 

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

[issue20947] -Wstrict-overflow findings

[Mark Lawrence]

Changes by Mark Lawrence :


--
nosy:  -BreamoreBoy

___
Python tracker 

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

[issue20947] -Wstrict-overflow findings

[Martin Panter]

Martin Panter added the comment:

Regarding the warning in Modules/_posixsubprocess.c, I don’t see any problem. 
I’m not sure exactly what it is warning about. Maybe if the cur pointer ever 
gets _before_ the start of hex_errno, that could be a problem, but the loop 
should stop when it reaches the start.

The warnings in Modules/sha512module.c refer to the first line of the 
sha512_transform() function. I cannot see any pointer comparisons in that 
function. The closest is pointer and array indexing, but it all seems to be in 
order.

I propose to ignore these warnings.

--
nosy: +martin.panter
resolution:  -> wont fix
type:  -> compile error

___
Python tracker 

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

[issue27637] int.to_bytes(-1, ...) should automatically choose required count of bytes

[Марк Коренберг]

Марк Коренберг added the comment:

https://github.com/pyca/cryptography/issues/3064

--

___
Python tracker 

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

[issue27639] UserList.__getitem__ doesn't account for slices

[Anton Backer]

Changes by Anton Backer :


--
hgrepos: +351

___
Python tracker 

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

[issue27623] int.to_bytes() and int.from_bytes(): raise ValueError when bytes count is zero

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

I agree with Martin. The ambiguous signed conversion cases should be an error, 
the unambiguous unsigned conversion case should be supported (especially if 
there are tests for this).

--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue27637] int.to_bytes(-1, ...) should automatically choose required count of bytes

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

This is rarely needed, mainly in general serializers like pickle. The code for 
determining the minimal number of bytes is not trivial, but it depends on the 
serializer. If you always serialize unsigned values and saves the sign 
separately, or use one's complement represenatation, or if the serializer 
supports only fixed set of integer sizes, the code is absolutely different.

I don't think that we need this feature in the stdlib.

--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue27638] int.to_bytes() and int.from_bytes() should support 'net' and 'host' byte orders

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

I agreed with Martin. The "host" byte order is sys.byteorder, and the "net" 
byteorder is just "big". There is one obvious way to specify this, and there is 
not need to add yet one way.

Adding support of new values for byteorder would complicate and slow down the 
code. int.to_bytes() and int.from_bytes() already are slower then struct.pack() 
and struct.unpack(), and parsing the byteorder argument is the main culprit 
here (see also issue27574).

I'm for rejecting this idea.

--

___
Python tracker 

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