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

[Mark Dickinson]

Mark Dickinson added the comment:

> The ambiguous signed conversion cases should be an error, the unambiguous 
> unsigned conversion case should be supported

+1. A signed representation *requires* 1 bit for the sign (regardless of 
whether the number being represented is negative or nonnegative), so it should 
be an error to encode into zero bytes. But there's nothing wrong with trying to 
encode 0 in zero bytes when using an unsigned representation.

--
nosy: +mark.dickinson

___
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]

Changes by Martin Panter :


Added file: http://bugs.python.org/file43915/issue26462.v5_regen.diff

___
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

[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

[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

[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

[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

[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

[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")

Hoping

[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

[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

[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]

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

[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

[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

[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

[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

[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

[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

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

[Xavier de Gaye]

Xavier de Gaye 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?

No, compileall is run with '-b', so there are no  PEP 3147 __pycache__ 
directories, and with an installation of 53M where the test suite is excluded, 
that saves 30M (see my previous msg).

IMHO this option is very useful on mobile devices and embedded systems where 
space is sparse.

--

___
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:

One last change I think needs making to the same demo, the “code-block” needs 
indenting under the bullet point:

* The interpreter can now be started with a quiet option, ``-q``, to prevent
  the copyright and version information from being displayed in the interactive
  mode.  The option can be introspected using the :attr:`sys.flags` attribute:
  
  .. code-block:: shell-session  <== Indented
 
$ python -q

Otherwise, it seems to include extra text in the code block.

--

___
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

[Roman Evstifeev]

Roman Evstifeev added the comment:

While not only android issue, there is a problem with dumbdbm module: it 
internally tries to do os.chmod() on a FAT-formatted sdcard and fails, because 
FAT does not support chmod.

--

___
Python tracker 

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

[issue23085] update internal libffi copy to 3.2.1

[Ned Deily]

Ned Deily added the comment:

We should be able to make things work for OS X installer builds one way or 
another so don't let that be a factor.

--

___
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

[Thomas Petazzoni]

Thomas Petazzoni added the comment:

I can also say that in the Buildroot project, we have patches to get rid of the 
PEP3147 stuff. Indeed, the PEP3147 forces one to have both the .py *and* the 
.pyc file for a given module. If you have only the .pyc file, Python does not 
recognize it and it cannot be imported.

By removing the PEP3147 functionality, we are able to keep only the .pyc files 
on the target, therefore dividing roughly by two the size of the Python 
installation.

--

___
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

[Thomas Petazzoni]

Thomas Petazzoni added the comment:

See 
https://git.buildroot.org/buildroot/tree/package/python3/0016-Add-importlib-fix-for-PEP-3147-issue.patch

--

___
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

[koobs]

Changes by koobs :


--
nosy: +koobs

___
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

[Thomas Petazzoni]

Thomas Petazzoni added the comment:

We have a similar patch in Buildroot (see 
https://git.buildroot.org/buildroot/tree/package/python3/0017-Add-an-option-to-disable-installation-of-test-module.patch)
 so we would be very happy to see this patch merged.

Note that we also have many more patches to disable various parts of the Python 
standard installation 
(https://git.buildroot.org/buildroot/tree/package/python3/). So either we have 
one option for each feature (like we have implemented), or a more general 
config option --disable-feature=test,this,that.

See also bug http://bugs.python.org/issue20210 which is related, and was also 
proposing a patch to disable the test suite.

--

___
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

[Ned Deily]

Ned Deily added the comment:

I think a proposal to add an option like this requires more discussion, 
probably a PEP.

--
nosy: +ned.deily

___
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:

but these are rebuilt when you start the interpreter, aren't they?

--

___
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

[Thomas Petazzoni]

Thomas Petazzoni added the comment:

No, if you remove PEP3147 (like the Buildroot patch does), and install only the 
.pyc files, you have a smaller Python installation, and nothing gets 
"re-generated", since what you already have are the .pyc files. The .py files 
are not even installed on the target system.

--

___
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

[Xavier de Gaye]

Xavier de Gaye added the comment:

> I am still curious what configures the preprocessor to set __ARM_ARCH to 7 (I 
> guess the clang -target argument?)
Yes, the -target clang argument or the -march gcc argument.

> and why we can’t set LDFLAGS at the same time or place. Is it just more 
> convenient this way?
I don't understand the question. LDFLAGS is set at the time we know that 
__ARM_ARCH is 7, just after the preprocessing is done. Would you set it 
elsewhere ?
LDFLAGS is set in configure.ac with always this same idiom: LDFLAGS="$LDFLAGS 
new_options..." and this setting is done in what seems to be random places in 
configure.ac.
CCSHARED is set in one case statement.

--

___
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:

> but these are rebuilt when you start the interpreter, aren't they?

No.

Quoting PEP 3147:
Case 4: legacy pyc files and source-less imports

Python will ignore all legacy pyc files when a source file exists next to 
it. In other words, if a foo.pyc file exists next to the foo.py file, the pyc 
file will be ignored in all cases

In order to continue to support source-less distributions though, if the 
source file is missing, Python will import a lone pyc file if it lives where 
the source file would have been.

--

___
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

[R. David Murray]

R. David Murray added the comment:

LGTM, but this is change we should probably only make in a feature release, 
with a note in the What's New porting section.

--
nosy: +r.david.murray
stage:  -> needs patch
versions: +Python 3.6 -Python 3.5

___
Python tracker 

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

[issue27642] import and __import__() fails silently without a ImportError and does not add the module to the file's namespace.

[Decorater]

New submission from Decorater:

So, I have some code. I tried to make a 'plugin' for my bot I made in python. 
However it seems to not be able to import it which it should be able to.

The code I used is here: https://bpaste.net/show/e4445c47490d

I dont even know why it is not addign it to the file's namespace or even adding 
it to sys.modules either.

--
messages: 271533
nosy: Decorater
priority: normal
severity: normal
status: open
title: import and __import__() fails silently without a ImportError and does 
not add the module to the file's namespace.
versions: Python 3.5

___
Python tracker 

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

[issue27642] import and __import__() fails silently without a ImportError and does not add the module to the file's namespace.

[Emanuel Barry]

Emanuel Barry added the comment:

`import` merely adds the imported module to the current namespace which, in 
your code, is some local (non-global) namespace. It is successfully imported 
but never used, and quickly falls out of scope.

You also check for `testplugin in sys.modules`, but you want `'testplugin' in 
sys.modules`. Closing this as not a bug, please reopen if there's indeed a bug 
I didn't spot.

--
nosy: +ebarry
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

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

[R. David Murray]

R. David Murray added the comment:

Our official position (so far, mobile is a new use case since the last time it 
was discussed) is that we don't go out of our way to support sourceless 
distribution, and in general we discourage it.  That is, it is left to the 
packager of a sourceless program to deal with removing the source and putting 
the .pyc files in the right place for python to find them.  So, yes, this 
requires at *least* a discussion on python-ideas, and possibly a PEP.

If this is adopted '--enable-legacy-pyc' would be the wrong name for the 
option, since it is in fact forcing legacy pyc...and if the only reason is to 
reduce space by omitting the source, then it should also not install the source 
so the name is wrong :)

But, this conversation should continue on python-ideas.  I'm -1 myself, for the 
record.

--
nosy: +r.david.murray

___
Python tracker 

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

[issue27642] import and __import__() fails silently without a ImportError and does not add the module to the file's namespace.

[Decorater]

Decorater added the comment:

yeah I just noticed it is in sys.modules but does not get defined globally. Bug 
maybe there is a hack to make it global?

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

___
Python tracker 

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

[issue27642] import and __import__() fails silently without a ImportError and does not add the module to the file's namespace.

[Decorater]

Decorater added the comment:

But*

--

___
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

[R. David Murray]

R. David Murray added the comment:

About doko's note and your response: unless this patch does not install the 
source (I haven't looked), the __pycache__ files *will* be rebuilt at 
interpreter start, according to the text you quoted.

--

___
Python tracker 

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

[issue27642] import and __import__() fails silently without a ImportError and does not add the module to the file's namespace.

[Emanuel Barry]

Emanuel Barry added the comment:

Yeah, just add 'global testplugin' at the top of your function, before your 
import it (you'll also need a global statement if you want to delete/re-import 
it). You might want to take a look at importlib if you wish to dynamically load 
modules (especially reloading them, which is a pain).

--

___
Python tracker 

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

[issue27642] import and __import__() fails silently without a ImportError and does not add the module to the file's namespace.

[R. David Murray]

R. David Murray added the comment:

Questions like this are more appropriate for the python-list mailing list, or 
even python-tutor.

--
nosy: +r.david.murray
resolution:  -> not a bug
status: open -> closed

___
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

[Mark Dickinson]

Mark Dickinson added the comment:

-1 from me; it feels like a needless expansion of the API.

--

___
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

[Mark Dickinson]

Mark Dickinson added the comment:

[Martin]

> I don’t like special values.

Agreed. If we wanted to add this, the obvious API would be to simply make the 
size optional (which would force passing the endianness by name or explicitly 
passing a default value of `None`, but that doesn't seem like a big deal to me).

I'm -0 on the feature itself. On the plus side, the fact that it's not 
completely trivial to compute the size with errors is an argument for including 
that calculation within the Python code. I'd suggest formulas of:

   (x.bit_length() + 7) // 8

for the unsigned case, and

   (~x if x < 0 else x).bit_length() // 8 + 1

for the signed case, these giving the minimal number of bytes necessary for 
encoding x in each case.

--
nosy: +mark.dickinson

___
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:

Where is the code that sets the clang -target argument, or gcc -march? Is it 
hidden away somewhere in the autoconf code? Do you manually set it with 
‘./configure CFLAGS="-target . . ." ’?

--

___
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

[Ned Deily]

Ned Deily added the comment:

Also, has anyone tried bundling the std lib into a zlib?  I know that option 
has been around for a long time but I don't know if it still works or is even 
being used.  Presumably, that would be another way to save space and file 
system entries.

--

___
Python tracker 

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

[issue27397] email.message.Message.get_payload(decode=True) raises AssertionError that "should never happen"

[Jami Lindh]

Jami Lindh added the comment:

I also attached a minimal script containing only the decode call and the 
garbage payload.

--
Added file: http://bugs.python.org/file43922/issue27397_poc_minimal.py

___
Python tracker 

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

[issue27397] email.message.Message.get_payload(decode=True) raises AssertionError that "should never happen"

[Jami Lindh]

Jami Lindh added the comment:

I stumbled upon this bug as well while fuzzing with AFL. The curious thing is 
that email.message_from_string still accepts that garbled message as a valid 
email.

--
nosy: +CryptidVulpes
versions: +Python 3.4
Added file: http://bugs.python.org/file43921/issue27397_poc.py

___
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

[Julien]

Julien added the comment:

Hi,

Indentation in whatsnew/3.2 fixed.

Colors in this block are clearly not perfect, but I think that's another 
subject.

--
Added file: http://bugs.python.org/file43923/issue26462.v7.diff

___
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

[Chi Hsuan Yen]

Chi Hsuan Yen added the comment:

Some dependent issues, like issue26852, issue26859 and issue27640, are for 
reducing the size of an installation. How about moving them to another 
meta-issue? First they are not critical for normal usages on Android. Second 
they are not limited to Android - other platforms may benefit as well.

--

___
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

[Julien]

Julien added the comment:

Hi,

Would you like me to also provide patches for different versions?
I only provided patches for the default branch, but I'll gladly see this 
applied on other branches, as I often build them all.

Also is a documented policy about maintaining the documentation?
I have some questions like:

- Should we maintain bugfix/security/end-of-life branches?
- Are we even allowed to push a documentation change to them?
- I'm seeing that the 3.x documentation are converging by using the "New in 
version 3.xx." marks, but they still different, is this effort documented? 
- Is this a goal to merge them on the long term?
- Is there a team on this?

--

___
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

[Decorater]

Decorater added the comment:

tbh it would be nice if the entire documentation was recolored to look more 
'interesting' to read. And to also have it in a way that people who lean 
visually can learn the info easier instead of them trying to read a giant wall 
of text that they may or may not understand. (got to hate reading giant walls) 
But yeah all versions on it should be good.

--
nosy: +Decorater

___
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

[Decorater]

Decorater added the comment:

Also I was thinking maybe I could figure out how to Add in asyncio to 2.7 
anyway (well latest one that is) because why not. With as many things using 
asyncio now days it would be cake for those python 2 users.

--

___
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

[Xavier de Gaye]

Xavier de Gaye added the comment:

Yes, the packager must use appropriately either CFLAGS CPPFLAGS [1] and 
LDFLAGS, or CC. I am using:
CC="clang --sysroot=$(SYSROOT) -target $(TARGET) -gcc-toolchain 
$(GCC_TOOLCHAIN)".

[1] See issue 27453, for the remaining problem upon using CPPFLAGS.

--

___
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:

Usually my technique is to apply the 3.6 patch to 3.5, fix up any conflicts, 
and leave the 3.6-only bits out (which get rejected by the patch process 
anyway). But dedicated patch(es) may be useful. Especially for 2.7, where there 
are probably independent changes to be made (e.g. modules that were removed in 
Python 3).

I think the policy on documentation in each branch should be in the devguide. 
My understanding: In general, bug fix branches (3.5, 2.7) have the 
documentation maintained, but generally not the older security-only branches.

My view is if a feature is added to (say) 3.6, then it gets a new-in-3.6 notice 
in the 3.6 documentation, but nothing gets added to 3.5. The Python 3 
documentation rarely mentions features of Python 2, so every feature is treated 
as being new in 3.0 by default. For Python 2, it won’t document new features of 
Python 3, but is updated with changes relevant to porting to 3. So in theory 
the latest Python 3.6+ documentation should also be usable with 3.5, but not 
with Python 2. That’s about all I know :)

--

___
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

[R. David Murray]

R. David Murray added the comment:

Martin: your summary is correct.  A new feature should also have a What's New 
entry, of course; I think that's the only essential you left out.

Decorator: general comments (eg: color of docs, etc) aren't really useful 
comments on a specific bug report, and the asyncio comment is totally 
irrelevant.

--
nosy: +r.david.murray

___
Python tracker 

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

[issue27643] test_ctypes fails on AIX with xlc

[Michael Felt]

New submission from Michael Felt:

I am preparing a system with gcc to see if it is compiler related, i.e., goes 
away with gcc. On the one hand, fingers crossed - but on the other, having 
bitfields working regardless of the compiler should be preferred.


This issue is similar to a Solaris (C compiler) 
http://bugs.python.org/issue16275

During the build using clc _ get these messages - which make me hope it is an 
unexpected compiler issue.

"/data/prj/aixtools/python/python-2.7.12.1/Modules/_ctypes/_ctypes_test.c", 
line 382.5: 1506-159 (E) Bit field type specified for M is not valid. Type 
unsigned assumed.
"/data/prj/aixtools/python/python-2.7.12.1/Modules/_ctypes/_ctypes_test.c", 
line 382.5: 1506-159 (E) Bit field type specified for N is not valid. Type 
unsigned assumed.
"/data/prj/aixtools/python/python-2.7.12.1/Modules/_ctypes/_ctypes_test.c", 
line 382.5: 1506-159 (E) Bit field type specified for O is not valid. Type 
unsigned assumed.
"/data/prj/aixtools/python/python-2.7.12.1/Modules/_ctypes/_ctypes_test.c", 
line 382.5: 1506-159 (E) Bit field type specified for P is not valid. Type 
unsigned assumed.
"/data/prj/aixtools/python/python-2.7.12.1/Modules/_ctypes/_ctypes_test.c", 
line 382.5: 1506-159 (E) Bit field type specified for Q is not valid. Type 
unsigned assumed.
"/data/prj/aixtools/python/python-2.7.12.1/Modules/_ctypes/_ctypes_test.c", 
line 382.5: 1506-159 (E) Bit field type specified for R is not valid. Type 
unsigned assumed.
"/data/prj/aixtools/python/python-2.7.12.1/Modules/_ctypes/_ctypes_test.c", 
line 382.5: 1506-159 (E) Bit field type specified for S is not valid. Type 
unsigned assumed.

Note: I modified test_bitfields to do an additional print. Maybe this gives an 
idea about what the issue is (when considering the compiler messages)

root@x064:[/data/prj/aixtools/python/python-2.7.12.1/Lib/ctypes/test]../../../python
 ./runtests.py
A 0x1001f 0
B 0x2001d 0
C 0x3001a 0
D 0x40016 0
E 0x50011 0
F 0x6000b 0
G 0x70004 0
H 0x80018 4
I 0x9000f 4
M 0x1000e 6
N 0x2000c 6
O 0x30009 6
P 0x40005 6
Q 0x5 6
R 0x6000a 8
S 0x70003 8
.s...s...s.s..s...ss.FF...s...s.s.sss...ss..sss...s..s.s..s...ss.ss.s.s.
==
FAIL: test_ints (ctypes.test.test_bitfields.C_Test)
--
Traceback (most recent call last):
  File 
"/data/prj/aixtools/python/python-2.7.12.1/Lib/ctypes/test/test_bitfields.py", 
line 41, in test_ints
self.assertEqual((name, i, getattr(b, name)), (name, i, func(byref(b), 
name)))
AssertionError: Tuples differ: ('A', 1, -1) != ('A', 1, 1)

First differing element 2:
-1
1

- ('A', 1, -1)
?  -

+ ('A', 1, 1)

==
FAIL: test_shorts (ctypes.test.test_bitfields.C_Test)
--
Traceback (most recent call last):
  File 
"/data/prj/aixtools/python/python-2.7.12.1/Lib/ctypes/test/test_bitfields.py", 
line 48, in test_shorts
self.assertEqual((name, i, getattr(b, name)), (name, i, func(byref(b), 
name)))
AssertionError: Tuples differ: ('M', 1, -1) != ('M', 1, 1)

First differing element 2:
-1
1

- ('M', 1, -1)
?  -

+ ('M', 1, 1)

--
Ran 440 tests in 0.883s (0 modules skipped)
Unavailable resources: printing, refcount

FAILED (failures=2)
root@x064:[/data/prj/aixtools/python/python-2.7.12.1/Lib/ctypes/test]

--
messages: 271555
nosy: Michael.Felt
priority: normal
severity: normal
status: open
title: test_ctypes fails on AIX with xlc
versions: Python 2.7

___
Python tracker 

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

[issue27643] test_ctypes fails on AIX with xlc

[Michael Felt]

Michael Felt added the comment:

FYI: similar (exact) results when 64-bit mode:
root@x064:[/data/prj/aixtools/python/python-2.7.12.1/Lib/ctypes/test]../../../python
 ./runtests.py
A 0x1001f 0
B 0x2001d 0
C 0x3001a 0
D 0x40016 0
E 0x50011 0
F 0x6000b 0
G 0x70004 0
H 0x80018 4
I 0x9000f 4
M 0x1000e 6
N 0x2000c 6
O 0x30009 6
P 0x40005 6
Q 0x5 6
R 0x6000a 8
S 0x70003 8
.s...s...s.s..s...ss.FF...s...s.s.sss...ss..sss...s..s.s..s...ss.ss.s.s.
==
FAIL: test_ints (ctypes.test.test_bitfields.C_Test)
--
Traceback (most recent call last):
  File 
"/data/prj/aixtools/python/python-2.7.12.1/Lib/ctypes/test/test_bitfields.py", 
line 41, in test_ints
self.assertEqual((name, i, getattr(b, name)), (name, i, func(byref(b), 
name)))
AssertionError: Tuples differ: ('A', 1, -1) != ('A', 1, 1)

First differing element 2:
-1
1

- ('A', 1, -1)
?  -

+ ('A', 1, 1)

==
FAIL: test_shorts (ctypes.test.test_bitfields.C_Test)
--
Traceback (most recent call last):
  File 
"/data/prj/aixtools/python/python-2.7.12.1/Lib/ctypes/test/test_bitfields.py", 
line 48, in test_shorts
self.assertEqual((name, i, getattr(b, name)), (name, i, func(byref(b), 
name)))
AssertionError: Tuples differ: ('M', 1, -1) != ('M', 1, 1)

First differing element 2:
-1
1

- ('M', 1, -1)
?  -

+ ('M', 1, 1)

--
Ran 440 tests in 0.870s (0 modules skipped)
Unavailable resources: printing, refcount

FAILED (failures=2)

--

___
Python tracker 

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

[issue27131] Unit test random shuffle

[Jonathan Kross]

Jonathan Kross added the comment:

Just giving this one a bump to see if it can be applied soon.

--

___
Python tracker 

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

[issue27404] Misc/NEWS: add [Security] prefix to Python 3.5.2 changelog

[Roundup Robot]

Roundup Robot added the comment:

New changeset a576a34f5386 by Victor Stinner in branch '3.5':
NEWS: tag security related changes with [Security] prefix
https://hg.python.org/cpython/rev/a576a34f5386

New changeset 6a2de662eeb7 by Victor Stinner in branch 'default':
Merge 3.5 (issue #27404)
https://hg.python.org/cpython/rev/6a2de662eeb7

--
nosy: +python-dev

___
Python tracker 

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

[issue24773] Implement PEP 495 (Local Time Disambiguation)

[Alexander Belopolsky]

Alexander Belopolsky added the comment:

It looks like the tzdata folks have agreed [1] that there is a problem with the 
Morocco rules in the Africa file and will likely fix it in the next release.

This is an interesting situation where a bug in tzcode masks a bug in tzdata 
while glibc implements the documented behavior faithfully but as a result 
suffers from the data bug.

I will wait for the conclusion of the discussion on the TZ list because there 
is a chance that we should fix the ZoneInfo logic to match glibc. 

[1]: http://mm.icann.org/pipermail/tz/2016-July/023896.html

--

___
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

[Julien]

Julien added the comment:

Martin: OK, let's apply this to 3.6 / 3.5 with this one, and I'll provide 
independent patch for 2.7 if needed (long time without building 2.7 doc).

--

___
Python tracker 

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

[issue27643] test_ctypes fails on AIX with xlc

[Michael Felt]

Michael Felt added the comment:

So, it seems to be a compiler issue - when built using gcc (v4.7.4) the tests 
take a bit longer, but no failures.

root@x065:[/data/prj/aixtools/python/python-2.7.12.1/Lib/ctypes/test]../../../python
 runtests.py
A 0x1001f 0
B 0x2001d 0
C 0x3001a 0
D 0x40016 0
E 0x50011 0
F 0x6000b 0
G 0x70004 0
H 0x80018 4
I 0x9000f 4
M 0x1000e 6
N 0x2000c 6
O 0x30009 6
P 0x40005 6
Q 0x5 6
R 0x6000a 8
S 0x70003 8
.s...s...s.s..s...ss..s...s.s.sss...ss..sss...s..s.s..s...ss.ss.s.s.
--
Ran 440 tests in 1.028s (0 modules skipped)
Unavailable resources: printing, refcount

OK

--

___
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-sourceless-distribution' option to configure

[Xavier de Gaye]

Xavier de Gaye added the comment:

> and if the only reason is to reduce space by omitting the source, then it 
> should also not install the source so the name is wrong :)

I miss your point, msg271515  said earlier "the patch removes all *.py files".
The patch does a sourceless distribution: no source and no __pycache__ files 
(with the exception mentionned in msg271515).
Changing the issue title with '--enable-sourceless-distribution' which is a 
better name and would have maybe avoided this confusion :)

--
title: add the '--enable-legacy-pyc-files' option to configure -> add the 
'--enable-sourceless-distribution' option to configure

___
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 :


--
keywords: +patch
Added file: http://bugs.python.org/file43924/581663cb2d4d.diff

___
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 :


Removed file: http://bugs.python.org/file43924/581663cb2d4d.diff

___
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

[Anders Lorentsen]

Anders Lorentsen added the comment:

So, am I to understand that the only corner case we should fix is that
>>> (-1).to_bytes(0, 'big', signed=True)
should raise an overflow error (currently it returns  b'') ?

--
Added file: 
http://bugs.python.org/file43925/int_to_bytes_overflow_cornercase.patch

___
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-sourceless-distribution' option to configure

[Xavier de Gaye]

Xavier de Gaye added the comment:

> About doko's note and your response: unless this patch does not install the 
> source (I haven't looked), the __pycache__ files *will* be rebuilt at 
> interpreter start, according to the text you quoted.

Right, and since the source files are removed, the __pycache__ files are *not* 
built. Hence my negative answer to Matthias.

--

___
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

[Mark Dickinson]

Mark Dickinson added the comment:

I guess that would be the minimal change necessary to remove ambiguity. But I 
tend to think that

>>> (0).to_bytes(0, 'big', signed=True)

should also be an error. (And of course both these should still be errors with 
'big' replaced with 'little'.)

--

___
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

[Julien]

Julien added the comment:

Decorater: Colors used by the documentation are defined here: 
https://github.com/sphinx-doc/sphinx/blob/master/sphinx/pygments_styles.py#L22 
you can easily modify it and rebuild the doc ``(cd Doc; make html)``. Take a 
look at existing themes (https://help.farbox.com/pygments.html), sphinx uses a 
vaiarion of "friendly". But, in general, please open a new issue to speak on 
different subjects, typically about asyncio which is not related to this issue. 
Have a nice day.

--

___
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:

Roman, can you please enter a new issue for that problem.

--

___
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:

> Some dependent issues, like issue26852, issue26859 and issue27640, are for 
> reducing the size of an installation. How about moving them to another 
> meta-issue? First they are not critical for normal usages on Android. Second 
> they are not limited to Android - other platforms may benefit as well.

Many issues that deal with failed tests are also not critical for normal usages 
on Android, but they must be fixed to run a buildbot and to support Android.
Issue #22724 (byte-compile fails for cross-builds) is also not specific to 
Android.
IMHO this meta-issue collects (1) the issues that must be fixed for the support 
of Android and (2) the issues that should possibly be fixed. The issues you are 
naming and issue 22724 are in the second category.

--

___
Python tracker 

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

[issue27404] Misc/NEWS: add [Security] prefix to Python 3.5.2 changelog

[STINNER Victor]

Changes by STINNER Victor :


--
resolution:  -> fixed
status: open -> closed

___
Python tracker 

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

[issue27250] Add os.urandom_block()

[STINNER Victor]

STINNER Victor added the comment:

I don't support this idea anymore, so I close the issue.

I wrote the PEP 524 to propose to make os.urandom() blocking on Linux. The 
discussion moved to the security-sig mailing list.

--
resolution:  -> rejected
status: open -> closed

___
Python tracker 

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

[issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom()

[STINNER Victor]

STINNER Victor added the comment:

I don't like this idea anymore ("add block=False parameter to os.urandom()"), 
so I close this issue.

I wrote the PEP 524 to propose to make os.urandom() blocking on Linux. The 
discussion moved to the security-sig mailing list.

--
resolution:  -> rejected
status: open -> closed

___
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

[Chi Hsuan Yen]

Chi Hsuan Yen added the comment:

Maybe the term "normal usages" is not accurate. I was trying to refer all 
possible Python usages on Android, and the test suite is a subset of them, so 
they should be fixed, too. I propose the aforementioned change (creating 
another meta-issue) because there are already many issues in this meta-issue, 
and I'm afraid new issues in the second category lead to complexity in tracking 
CPython's Android support. Currently things are still under control, so you can 
ignore my request until the number of issues goes crazy.

--

___
Python tracker 

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

[issue27644] Expand documentation about type aliases and NewType in the typing module

[Michael Lee]

New submission from Michael Lee:

This is a patch to update the documentation on the typing module. It expands 
the section on type aliases and adds a section on [NewType][0].

Since support for NewType was [recently added][1] to mypy, it seemed like a 
prudent time to update the docs to describe this new feature.

The section on type aliases was mainly expanded because the distinction between 
type aliases and NewType could be potentially confusing, so adding extra 
clarification seemed like a good idea.

  [0]: https://www.python.org/dev/peps/pep-0484/#newtype-helper-function
  [1]: https://github.com/python/mypy/pull/1939

--
assignee: docs@python
components: Documentation
files: document_newtype.patch
keywords: patch
messages: 271572
nosy: docs@python, michael0x2a
priority: normal
severity: normal
status: open
title: Expand documentation about type aliases and NewType in the typing module
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file43926/document_newtype.patch

___
Python tracker 

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

[issue27629] Cannot create ssl.SSLSocket without existing socket

[nemunaire]

nemunaire added the comment:

Here is a new patch with tests on constructor.

The patch on the feature is quite different: instead of testing for None 
socket, I choose to delay the != SOCK_STREAM check in the later condition, when 
we know we treat a socket.

Tests include different constructor forms: with a given socket, with a fileno 
(didn't work either, before this patch) and without socket nor file descriptor 
(as in my original test).

I don't have sufficient background to judge if tests will work on all platform 
(eg. fileno and windows, ...).

Here is the interesting diff of the tests on SSL (before/after applying the 
patch on the feature):

32c32
< test_constructor (__main__.BasicSocketTests) ... ERROR
---
> test_constructor (__main__.BasicSocketTests) ... ok
519,528d518
< ERROR: test_constructor (__main__.BasicSocketTests)
< --
< Traceback (most recent call last):
<   File "test_ssl.py", line 149, in test_constructor
< ss = ssl.SSLSocket()
<   File "/usr/lib/python3.4/ssl.py", line 545, in __init__
< if sock.getsockopt(SOL_SOCKET, SO_TYPE) != SOCK_STREAM:
< AttributeError: 'NoneType' object has no attribute 'getsockopt'
< 
< ==

--
Added file: 
http://bugs.python.org/file43927/fix_sslsocket_init_without_socket_3_3-3_6.patch

___
Python tracker 

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

[issue27629] Cannot create ssl.SSLSocket without existing socket

[nemunaire]

Changes by nemunaire :


Removed file: 
http://bugs.python.org/file43900/fix_sslsocket_init_without_socket_3.3-3_6.patch

___
Python tracker 

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

[issue27645] Supporting native backup facility of SQLite

[Lele Gaifax]

New submission from Lele Gaifax:

It would be nice if the sqlite3 stdlib module could expose the SQLite Online 
Backup API.

I'm willing to implement it, as encouraged by Paul Moore.

See also: https://mail.python.org/pipermail/python-dev/2016-July/145570.html

--
components: Extension Modules
messages: 271574
nosy: lelit
priority: normal
severity: normal
status: open
title: Supporting native backup facility of SQLite
type: enhancement
versions: Python 3.6

___
Python tracker 

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

[issue27645] Supporting native backup facility of SQLite

[Lele Gaifax]

Lele Gaifax added the comment:

Here is a preliminary implementation: 
https://github.com/lelit/cpython/commit/b7456eb6a55568639a41efb5d88ab4d9b3c20337

--

___
Python tracker 

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

[issue27645] Supporting native backup facility of SQLite

[Emanuel Barry]

Emanuel Barry added the comment:

That's really nice, thank you for doing this! To get your code reviewed, 
though, you should upload a patch here. With git, you can do 'git diff > 
my_patch_file_name.patch' in your local repo, then you can upload the resulting 
file here. If you haven't done so yet, you'll need to sign a contributor 
agreement as well: https://www.python.org/psf/contrib/contrib-form/ :)

(Also, you might want to remove the 'index ...' lines in the patch file that 
git generates for each modified file; since there are three files, there should 
be three lines to remove. I'm not sure if you really have to, but I always do 
it just to be sure :)

--
nosy: +ebarry

___
Python tracker 

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

[issue27645] Supporting native backup facility of SQLite

[Lele Gaifax]

Changes by Lele Gaifax :


--
keywords: +patch
Added file: http://bugs.python.org/file43928/issue27645.patch

___
Python tracker 

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

[issue27646] yield from expression can be any iterable

[Terry J. Reedy]

New submission from Terry J. Reedy:

https://docs.python.org/3/reference/expressions.html#yield-expressions says
  "When yield from  is used, it treats the supplied expression
  as a subiterator. All values produced by that subiterator ...".
To me "treats..expression as a subiterator" means that the expression must *be* 
an iterator, such as returned by iter or calling a generator function.  Hence I 
was surprised upon reading "yield from " in stdlib code.

I confirmed that this usage is correct by trying

>>> def g():
yield from (1,2)

>>> i = g()
>>> next(i), next(i)
(1, 2)

and then reading the PEP380 Formal Semantics, which begins with "_i = 
iter(EXPR)".  Hence I suggest the following replacement for the quote above:
  "When yield from  is used, the expression must be an iterable.
  A subiterator is obtained with iter().  All values produced
  by that subiterator ...".

Note that 'subiterator' is spelled in the following sentences 'underlying 
iterable' (which I am not sure I like) and 'sub-iterator' (and 
'sub-generator').  I think we should  be consistent for at least the two short 
'yield from' paragraphs.

--
assignee: docs@python
components: Documentation
messages: 271577
nosy: docs@python, terry.reedy
priority: normal
severity: normal
stage: patch review
status: open
title: yield from expression can be any iterable
type: behavior
versions: Python 3.5, Python 3.6

___
Python tracker 

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

[issue10910] pyport.h FreeBSD/Mac OS X "fix" causes errors in C++ compilation

[Mihai Capotă]

Changes by Mihai Capotă :


--
nosy: +mihaic

___
Python tracker 

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

[issue27645] Supporting native backup facility of SQLite

[Berker Peksag]

Berker Peksag added the comment:

Thanks for the patch! I haven't had a chance to review the patch yet, but we 
also need documentation updates to Doc/library/sqlite3.rst.

--
nosy: +berker.peksag
stage:  -> patch review

___
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

[Vinay Sajip]

Vinay Sajip added the comment:

I have updated the patch to apply against 3.6, and changed it to be more 
conservative: it only uses ld and LD_LIBRARY_PATH when trying to find a library 
if the existing gcc-based method fails.

Seeing that this issue has been around for so long, I would really like to get 
this patch committed in the short window we have before 3.6 goes into beta. 
Please review!

--
assignee: theller -> vinay.sajip
title: ctypes find_library should search LD_LIBRARY_PATH on linux -> ctypes 
find_library should search LD_LIBRARY_PATH on Linux
versions: +Python 3.6 -Python 3.5
Added file: http://bugs.python.org/file43929/refresh-2016.diff

___
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

[Vinay Sajip]

Changes by Vinay Sajip :


--
hgrepos:  -130

___
Python tracker 

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

[issue27645] Supporting native backup facility of SQLite

[Lele Gaifax]

Lele Gaifax added the comment:

For the documentation see 
https://github.com/lelit/cpython/commit/bd82f8de9800ae40b33ddf1e4b7d72f10bc9c10e
 or the attached patch.

--
Added file: http://bugs.python.org/file43930/issue27645-doc.patch

___
Python tracker 

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

[issue27647] Update Windows build to Tcl/Tk 8.6.6

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
nosy: +terry.reedy

___
Python tracker 

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

[issue27647] Update Windows build to Tcl/Tk 8.6.6

[Serhiy Storchaka]

New submission from Serhiy Storchaka:

Current Tcl/Tk version in Windows build is 8.6.4.2. Tcl/Tk 8.6.6 was released 
yesterday.

https://sourceforge.net/p/tcl/mailman/message/35246302/

--
components: Tkinter, Windows
messages: 271581
nosy: paul.moore, serhiy.storchaka, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: Update Windows build to Tcl/Tk 8.6.6
versions: Python 3.5, Python 3.6

___
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:

imho - it is not correct to only make a modification of this nature for a 
single platform.

To be realistic, if the "design" goal is to 'find' what dlopen() will find when 
given a argument without a pathname component - then gcc should not be used, 
and perhaps only your 'ld' based solution (which I have not read).

>From linux man pages: both the justification to consider *PATH* for all 
>platforms (i.e., LD_LIBRARY_PATH is a GNU/Linux construct, not the default for 
>all platforms.)

"""
dlopen()

The function dlopen() loads the dynamic library file named by the 
null-terminated string filename and returns an opaque "handle" for the dynamic 
library. If filename is NULL, then the returned handle is for the main program. 
If filename contains a slash ("/"), then it is interpreted as a (relative or 
absolute) pathname. Otherwise, the dynamic linker searches for the library as 
follows (see ld.so(8) for further details):
o

(ELF only) If the executable file for the calling program contains a DT_RPATH 
tag, and does not contain a DT_RUNPATH tag, then the directories listed in the 
DT_RPATH tag are searched.

o

If, at the time that the program was started, the environment variable 
LD_LIBRARY_PATH was defined to contain a colon-separated list of directories, 
then these are searched. (As a security measure this variable is ignored for 
set-user-ID and set-group-ID programs.) 
""" end of excerpt

In short, this is more than just LD_LIBRARY_PATH. And my preference is that 
*PATH*, if predefined, should be taken into consideration by find_library. In 
other words, the purpose of find_library is to resolve platform naming 
conventions of shared libraries given a 'generic' argument, e.g., 
find_library("c") on Linux returns libc.so.6 while for AIX it (should return) 
libc.a(shr4.o).

As such, I would oppose a patch that only addresses the specifics of one 
platform. What is needed is a "design" clarification of the purpose of 
find_library. If we can agree on that "implementation" can follow. IMHO - 
trying to get a patch in for the convenience of one platform is not an 
architectural enhancement.

Again, I would like to see the documented behavior to be that find_library 
returns what dlopen() would open - when given an argument is the correct 
platform syntax. A patch for Linux does not - formally - guarantee that 
documented change.

--

___
Python tracker 

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

[issue27645] Supporting native backup facility of SQLite

[Lele Gaifax]

Lele Gaifax added the comment:

WRT to the agreement form, I guess I'll have to compile it even if I already 
contributed to Python decades ago (ObjC, readline, NeXT support...), right?

Will try to do whatever is needed in the next days...

--

___
Python tracker 

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

[issue27645] Supporting native backup facility of SQLite

[R. David Murray]

R. David Murray added the comment:

If you have a copy of your original agreement you could fax it to the PSF, but 
it is probably easier to just to sign the electronic one.

--
nosy: +r.david.murray

___
Python tracker 

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

[issue27647] Update Windows build to Tcl/Tk 8.6.6

[Zachary Ware]

Zachary Ware added the comment:

I've done a test build (32-bit Release) and everything went fine.  It looks 
like we get to drop our patches, which is enough for me to want to do this for 
3.6.

We historically haven't kept our Tcl/Tk sources extremely up to date on 
Windows, though; is there anything compelling in 8.6.[56] to warrant updating 
for 3.5?

--

___
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

[Vinay Sajip]

Vinay Sajip added the comment:

In my view, the best should not be the enemy of the good, and pragmatism beats 
purity. I don't have the resources to test this functionality on all platforms 
- just Windows and Linux - and am not familiar with other platforms like AIX, 
Solaris or the BSDs. The documentation makes clear that the behaviour of 
find_library is system-dependent and makes no promises of a particular level of 
consistency, either with dlopen() or across platforms. Nor can we guarantee in 
the documentation that find_library() will exactly emulate dlopen(), since that 
may not hold on all platforms - and in fact, since Windows is in the mix, there 
is little point in trying to tie find_library() behaviour to that of dlopen() 
directly.

My documentation update makes clear that for Linux only, LD_LIBRARY_PATH will 
be searched if the existing mechanisms give no joy.

This request has been around since 2010, and in my view implementing this 
long-overdue patch will improve matters for Linux users and IIUC meet the goals 
of the issue creator and other commenters who concurred with his sentiment. 
This does not preclude improving the functionality on other platforms later, 
but I think we should implement this patch unless someone can point out that it 
makes things worse in some way. If anyone can improve it, that is also to be 
welcomed, of course.

> As such, I would oppose a patch that only addresses the specifics of one 
> platform.

Why would improving behaviour on one platform, without any API changes or 
needing additional work by users, be worthy of opposition?

> What is needed is a "design" clarification of the purpose of find_library.
> If we can agree on that "implementation" can follow.

The purpose of find_library as currently documented seems adequately described, 
and the documentation update in my latest patch clarifies things further. IMO 
this is an area where the underlying platform features which find_library() 
relies on, as well as the run-time dynamic linking facilities available, are 
quite different across platforms. 

I'm not sure the agreement you seek will come any time soon, as it has not come 
in the last five years; it doesn't seem possible to aim for e.g. exact 
behaviour of dlopen(), because (a) it's not the same on Windows and (b) 
potentially varies too widely across POSIX platforms. Can you propose some 
change to the find_library() contract which you can assure will be 
implementable across all platforms? Certainly, fidelity with dlopen() isn't it.
 

> IMHO - trying to get a patch in for the convenience of one platform is not an 
> architectural enhancement.

We're not trying for an architectural enhancement here, AFAIK.

I would welcome some input from others!

--

___
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

[Vinay Sajip]

Vinay Sajip added the comment:

Added belopolsky and meador.inge to nosy as they are listed as ctypes experts 
in the experts index (Amaury was already there).

--
nosy: +meador.inge

___
Python tracker 

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

[issue27598] Add SizedIterable to collections.abc and typing

[Ivan Levkivskyi]

Changes by Ivan Levkivskyi :


--
nosy: +levkivskyi

___
Python tracker 

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

[issue27644] Expand documentation about type aliases and NewType in the typing module

[Ivan Levkivskyi]

Changes by Ivan Levkivskyi :


--
nosy: +levkivskyi

___
Python tracker 

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