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

[Jami Lindh]

Jami Lindh added the comment:

Also, I'm not sure what is the development status in Python 3.4 but in my case 
this bug happened using the Debian Jessie Python version 3.4.2-2

--
versions: +Python 3.4

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

In my opinion, this is still a clear case of "invalid input, raise an error", 
but I don't think AssertionError is the right one. Maybe just don't catch the 
unexpected binascii.Error and let it fly towards the user?

I might go even one step further and just let base64 library handle and raise 
all the necessary errors here, similarly to how your "encode_b" function works.

If you want more error resilience (meaning: email lib would not crash with 
invalid inputs), I would think returning an empty string is okay, since that 
base64 input is clearly not a valid base64 that is going to decode into 
anything.

--

___
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

[Martin Panter]

Martin Panter added the comment:

Here is another possible option. It is still a bit of a hack, because the 
configure script inserts comments into the makefile, but this is already done 
e.g. with @EXPORT_MACOSX_DEPLOYMENT_TARGET@. The advantage is we get to keep 
the filenames of the dependencies in the makefile, so it should be easier to 
read and maintain. And we get to eliminate the $(cross_compiling) check as well.

In native compiling mode, everything should be as normal. When cross-compiling, 
the rules for regenerating files should read like

Python/importlib.h: # $(srcdir)/Lib/importlib/_bootstrap.py 
Programs/_freeze_importlib
./Programs/_freeze_importlib \
$(srcdir)/Lib/importlib/_bootstrap.py Python/importlib.h

Since the Python/importlib.h should already exist, the rule in this form 
(dependencies commented out) won’t be run, and Make won’t need to build 
Programs/_freeze_importlib either.

--
stage:  -> patch review
versions: +Python 3.5
Added file: http://bugs.python.org/file43933/comment-out-regen.patch

___
Python tracker 

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

[issue17599] mingw: detect REPARSE_DATA_BUFFER

[Eryk Sun]

Eryk Sun added the comment:

REPARSE_DATA_BUFFER is defined in the WDK filesystem header, km\ntifs.h. It's 
not defined in the user-mode SDK.

--
nosy: +eryksun

___
Python tracker 

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

[issue17600] mingw: build-in windows modules (winreg)

[Martin Panter]

Martin Panter added the comment:

Here is a quick merge with the current code.

First concern: The patch adds special support if KEY_WOW64_64KEY is not 
defined, claiming to be for _WIN32_WINNT < 0x502, however these days I think 
Python dropped support for Windows XP etc, so we can probably drop this part.

--
components: +Windows -Cross-Build
nosy: +martin.panter, paul.moore, steve.dower, tim.golden, zach.ware
stage:  -> patch review
versions: +Python 3.6 -Python 3.4
Added file: http://bugs.python.org/file43932/MINGW-winreg.v2.patch

___
Python tracker 

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

[issue27648] Message of webbrowser.py something wrong.

[김태환]

New submission from 김태환:

I'm using Python 3.5.1+ and Ubuntu 16.04.

When I open new tab to Chrome using 'webbrowser.open()'.
Some message prints next to shell prompt like below.
```
asd 저장소가 생성되었습니다...
첫 위키 페이지를 만들기 위해 Save Page 버튼을 눌러주세요!
['asd']
(Shell prompt) $ 기존 브라우저 세션에 새 창을 생성했습니다.
```
First three line is my program's message, please don't care about them.
Problem happened at final line.
'기존 브라우저 세션에 새 창을 생성했습니다.' means Program created new window to existing browser 
session.
I think that message is for webbrowser.py and it prints with shell prompt.
So, I was reading webbrowser.py simply but I cannot find where it prints 
message.

Thanks.

--
components: Library (Lib)
messages: 271603
nosy: 김태환
priority: normal
severity: normal
status: open
title: Message of webbrowser.py something wrong.
type: behavior
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

[issue17599] mingw: detect REPARSE_DATA_BUFFER

[Martin Panter]

Martin Panter added the comment:

Leading underscore is a good idea.

I have no idea if VC14 includes the structure, but I suspect if it was added 
with this name, we would know because it would cause the same conflict that Min 
GW caused.

--
Added file: http://bugs.python.org/file43931/Py_REPARSE.v2.patch

___
Python tracker 

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

[issue17596] mingw: add wincrypt.h in Python/random.c

[Martin Panter]

Martin Panter added the comment:

For the record, the first error without this patch is

../Python/random.c:26:1: error: unknown type name 'HCRYPTPROV'

According to 
,
 the header to use is , but we use lowercase  to avoid 
a problem with case sensitivity.

--
resolution:  -> fixed
stage: commit review -> 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

[issue17596] mingw: add wincrypt.h in Python/random.c

[Roundup Robot]

Roundup Robot added the comment:

New changeset 11ed7c49f5df by Martin Panter in branch 'default':
Issue #17596: MINGW: add wincrypt.h in Python/random.c
https://hg.python.org/cpython/rev/11ed7c49f5df

--
nosy: +python-dev

___
Python tracker 

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

[issue17596] mingw: add wincrypt.h in Python/random.c

[Martin Panter]

Martin Panter added the comment:

I think this one should be fairly safe; any breakage should be pretty obvious 
by watching the buildbots.

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

[issue27647] Update Windows build to Tcl/Tk 8.6.6

[Terry J. Reedy]

Terry J. Reedy added the comment:

I think 3.4 and 3.5 were pretty current as of .0 release, or certainly as of 
.0b1.  Have we updated to new unicode (9.0), like tcl?  Martin used to do that.

--

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

Okay, leaving this open for a 2.7 patch. BTW thanks for your work; I tried to 
tackle these warnings a while ago, but I didn’t know enough about 
Sphix/RST/etc. The 2.7 change should be fairly easy; I can give it a crack if 
you’re not that interested in 2.7.

--
stage: commit review -> needs patch

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


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

[issue26462] Patch to enhance literal block language declaration

[Roundup Robot]

Roundup Robot added the comment:

New changeset 8bac90be by Martin Panter in branch '3.5':
Issue #26462: Doc: reduce literal_block warnings, fix syntax highlighting.
https://hg.python.org/cpython/rev/8bac90be

New changeset 6fbb7c9d77c6 by Martin Panter in branch 'default':
Issue #26462: Merge code block fixes from 3.5
https://hg.python.org/cpython/rev/6fbb7c9d77c6

--
nosy: +python-dev

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

[R. David Murray]

R. David Murray added the comment:

It might be better to add a character: that will produce garbage as the last 
byte, but that could serve as an alert that something is wrong...and we don't 
know if the extra character is at the end or at the beginning of the base64 
encoded string, or if, as in this case, it is multiple extra characters which 
will produce trailing garbage anyway.  The example in hand is, I would guess, 
by far the most likely scenario.

--

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

[R. David Murray]

R. David Murray added the comment:

Thanks for narrowing this down.  There are two problems: the first is that the 
base64 module is raising "Incorrect padding" when the issue is actually that 
the input string cannot be decoded using the base64 algorithm no matter what 
padding might be supplied.  The second is that the else clause in 
_encoded_words *can* happen, in this circumstance.

The circumstance is that the input string contains n*4+1 characters.  No 
encoding of source text will ever produce that number of output characters.  (I 
also seem to have used an index one greater than needed for the loop; the 
maximum number of padding characters is 2.)

The interesting question is what we want to do for error recovery in the n*4+1 
case.  Do we declare the part invalid and return an empty string?  Do we try 
chopping off the last character and see if we can decode it?  The latter is 
complicated by the possible presence of invalid alphabet characters, but it is 
what I lean toward.

I'm open to alternate suggestions.  And to a patch if someone wants to write 
one :)

--
stage:  -> needs patch
type: crash -> behavior
versions:  -Python 3.4

___
Python tracker 

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

[issue22645] Unable to install Python 3.4.2 amd64 on Windows 8.1 Update 1

[Berker Peksag]

Berker Peksag added the comment:

This was marked as 'fixed' almost two years ago. I tried to install 3.4.3, 
uninstall 3.4.3 and install 3.4.4 again in Win 10 and it worked fine for me. I 
guess this was left open accidentally.

--
nosy: +berker.peksag
status: open -> closed

___
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

[Martin Panter]

Martin Panter added the comment:

The test seems to be comparing ctypes and native C bit-field structures, c_int 
and c_short versus native int and short. In general in C, if a bit-field has 
type “int” without a signed or unsigned qualifier, it is up to the 
implementation which mode is chosen. This is different from normal, where int 
always means signed int.

Since ctypes documents c_int as both meaning “int” and “signed int”, I would 
say that a ctypes bit-field using c_int should always behave as “signed int”. 
So perhaps we should just change the test structure to use “signed int” and 
“signed short”. That should also help avoid the warnings, and may help the 
Solaris situation (if that is still relevant).

I presume this also affects Python 3.

--
components: +ctypes
nosy: +martin.panter
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

[issue27355] Strip out the last lingering vestiges of Windows CE support

[Zachary Ware]

Zachary Ware added the comment:

See #23085 for more about our libffi situation.


For this issue, with silence from Tim and Mark I say commit at will (and kill 
Modules/_ctypes/libffi_arm_wince/ as well).

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

[issue27647] Update Windows build to Tcl/Tk 8.6.6

[Zachary Ware]

Zachary Ware added the comment:

There have also been a few updates to 8.5 since we last updated the version we 
ship with 2.7; has there been anything in 8.5.15-19 that we should pick up?

--
versions: +Python 2.7 -Python 3.6

___
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

[Roundup Robot]

Roundup Robot added the comment:

New changeset abfda075eb37 by Zachary Ware in branch 'default':
Issue #27647: Update Windows build to Tcl/Tk 8.6.6
https://hg.python.org/cpython/rev/abfda075eb37

--
nosy: +python-dev

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

Ivan Levkivskyi added the comment:

Added two small comments to the review.

--

___
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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

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

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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

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

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

[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

[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

[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

[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

[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

[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

[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

[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

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

[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

[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

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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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