[issue29138] No __hash__() inheritance warning with -Werror

[Martin Panter]

Martin Panter added the comment:

Thanks, I will try to look at that some time

--
stage: needs patch -> 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

[issue29130] Exit code 120 returned from Python unit test testing SystemExit

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

> Having said all that, perhaps it would be reasonable to tolerate a missing 
> flush() method, and not treat this as an error.

In all cases the flush() method is called unconditionally. I think it can be 
considered as mandatory part of the writer protocol.

--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue29138] No __hash__() inheritance warning with -Werror

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

This is a duplicate of issue8627.

--
nosy: +serhiy.storchaka
resolution:  -> duplicate
superseder:  -> Unchecked PyErr_WarnPy3k return value in Objects/typeobject.c

___
Python tracker 

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

[issue29137] Fix fpectl-induced ABI breakage

[Nick Coghlan]

Nick Coghlan added the comment:

Ah, cool - I didn't know that Debian built with fpectl enabled by default. In 
that case, +1 for:

- low maintenance ABI and API compatibility shims that are kept around 
indefinitely (since they leaked into the limited API/stable ABI) but don't 
actually do anything
- deprecating and removing the fpectl module
- adding the ABI compatibility shims in the maintenance releases where the 
retroactive deprecation warnings are introduced

--

___
Python tracker 

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

[issue29138] No __hash__() inheritance warning with -Werror

[Martin Panter]

New submission from Martin Panter:

Normally there is a Python 3 compatibility warning emitted when a class is 
based on object, implements __eq__(), but does not define __hash__():

$ python -3 -c 'class C(object): __eq__ = lambda self, other: True'
-c:1: DeprecationWarning: Overriding __eq__ blocks inheritance of __hash__ in 
3.x

But when warnings are raised as exceptions, this warning seems to be suppressed:

$ python -3 -Werror -c 'class C(object): __eq__ = lambda self, other: True'

Perhaps there is bad exception handling at the warn() call site.

--
messages: 284539
nosy: martin.panter
priority: normal
severity: normal
stage: needs patch
status: open
title: No __hash__() inheritance warning with -Werror
type: behavior
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

[issue28518] execute("begin immediate") throwing OperationalError

[Ma Lin]

Ma Lin added the comment:

I'm trying to catch up with you.
Does it mean, if I want execute VACUUM, I have to commit manually? Like this:

if conn.in_transaction:
conn.commit()
conn.execute("vacuum")

--

___
Python tracker 

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

[issue28180] sys.getfilesystemencoding() should default to utf-8

[Nick Coghlan]

Nick Coghlan added the comment:

Updated patch adds some tests showing that this change should also help with 
cases where SSH environment forwarding results in an unknown locale being 
requested in the server environment.

--
Added file: 
http://bugs.python.org/file46121/pep538_coerce_legacy_c_locale_v2.diff

___
Python tracker 

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

[issue29130] Exit code 120 returned from Python unit test testing SystemExit

[Martin Panter]

Martin Panter added the comment:

David is right. The 120 code was added in Issue 5319, as a way of indicating a 
problem in the final stages of the interpreter exiting. The two conditions that 
trigger this are calling the flush() method on sys.stdout and sys.stderr. If 
you add a dummy flush() implementation, it no longer exits with 120:

>>> subprocess.call((sys.executable, "-c", """
... class NullWriter:
... def write(self, s): pass
... import sys; sys.stderr = NullWriter()"""))
120
>>> subprocess.call((sys.executable, "-c", """
... class NullWriter:
... def write(self, s): pass
... def flush(self): pass
... import sys; sys.stderr = NullWriter()"""))
0

It does not seem to be explicitly documented what you can set sys.stderr to, 
but I always thought it is safest to use an io.TextIOBase implementation. I 
would suggest to derive your NullWriter class from TextIOBase; that way you get 
a default flush() implementation for free.

Other options are to use StringIO() if you are not expecting too much output, 
or open(os.devnull, "w"). See also Issue 28864 about adding a predefined class 
like NullWriter to Python.

Having said all that, perhaps it would be reasonable to tolerate a missing 
flush() method, and not treat this as an error.

Stepping back a bit, I also suggest restoring sys.stderr after the test. 
Otherwise, you risk missing an error message. Try contextlib.redirect_stderr().

--

___
Python tracker 

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

[issue28864] Add devnull file-like object

[Martin Panter]

Martin Panter added the comment:

Example where an implementation like Serhiy’s was not good enough: 
. In that case, the lack of 
flush() method causes a subtle problem.

--

___
Python tracker 

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

[issue29130] Exit code 120 returned from Python unit test testing SystemExit

[Xiang Zhang]

Xiang Zhang added the comment:

Behaviour changed in #5319. Add author Martin.

--
nosy: +martin.panter, xiang.zhang

___
Python tracker 

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

[issue29131] Calling printf from the cdll does not print the full string

[Eryk Sun]

Eryk Sun added the comment:

> I am following the "Gray Hat Python - Python Programming for Hackers and 
> Reverse Engineers"

>From what I've seen in Stack Overflow questions asked by people reading that 
>book, its ctypes code is generally of poor quality. It only works in 32-bit 
>Python 2 because the author has lazy habits about strings and pointers. 
>Anyway, this issue is closed. There's no bug in Python here. If you have 
>additional questions related to porting old ctypes code to work in Python 3 
>and 64-bit Windows, please ask on ctypes-users [1] or python-list [2]. Many 
>people will be happy to help you.

[1]: https://lists.sourceforge.net/lists/listinfo/ctypes-users
[2]: https://mail.python.org/mailman/listinfo/python-list

--

___
Python tracker 

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

[issue29137] Fix fpectl-induced ABI breakage

[Nathaniel Smith]

Nathaniel Smith added the comment:

> At that point, does it actually make sense to provide the shims? Or should we 
> instead just add the deprecation warnings and say "Don't use the 
> --with-fpectl option, as it doesn't work properly, and breaks ABI 
> compatibility for extension modules built with that Python"?

"Providing the shims" consists of deleting two lines of code, so eh, why not? 
And in theory there could be "stable ABI" extensions that depend on the shims. 
But I agree that it doesn't make much difference either way.

> And then add a build time "#pragma message '--with-fpectl' is deprecated as 
> it breaks extension module ABI compatibility" to the WANT_SIGFPE_HANDLER 
> branch in Include/fpectl.h

This would hassle every end user who builds extension modules on Debian/Ubuntu 
(b/c their default Python build uses --with-fpectl). But end users can't do 
anything about how Debian/Ubuntu build CPython. And in fact Debian/Ubuntu can't 
do anything about how Debian/Ubuntu build CPython either until 3.7 comes out 
and breaks ABI, because switching now would break installed systems...

So long as we keep the PyFPE_* macros as no-ops (which technically we have to 
to preserve the stable ABI), then there's no need to break compatibility at the 
C API level. The place we want to break compatibility is by dropping the 
Python-level fpectl package, so I think that's where we should warn.

--

___
Python tracker 

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

[issue29133] Minor inaccuracy in shlex.shlex punctuation_chars example

[Evan]

Evan added the comment:

Sorry for not being more clear in the original report - the error is in the 
code, not in the output. The old behavior is punct=False, the new is punct=True.

--

___
Python tracker 

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

[issue29131] Calling printf from the cdll does not print the full string

[mike peremsky]

mike peremsky added the comment:

I appreciate the feedback, but as I had originally mentioned. I am following 
the "Gray Hat Python - Python Programming for Hackers and Reverse Engineers" 
book and was attempting to use Python 3 instead of Python 2 (as was used in the 
book). The cdll code is taken from the book itself. There is nothing that I 
personally plan on doing with this cdll other than to follow along in the book 
and become educated.

"Though if you do really want to use the (very) old msvcrt DLL rather than the 
proper functionality"

If there are better libraries to use I would be interested in knowing what 
those are. What is the "proper functionality"?. I like to educate myself and 
would like to attempt to follow the book using Python 3 and current libraries.

--

___
Python tracker 

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

[issue29137] Fix fpectl-induced ABI breakage

[Nick Coghlan]

Nick Coghlan added the comment:

- 3.4 is already in security-fix only mode so we can safely ignore it for this 
purpose

- 3.5.3 is likely to be the last general bugfix release of 3.5, so we can 
probably skip that as well

- that would mean the ABI compability shims would only go in 3.6.1 and the next 
2.7 release

At that point, does it actually make sense to provide the shims? Or should we 
instead just add the deprecation warnings and say "Don't use the --with-fpectl 
option, as it doesn't work properly, and breaks ABI compatibility for extension 
modules built with that Python"?

And then add a build time "#pragma message '--with-fpectl' is deprecated as it 
breaks extension module ABI compatibility" to the WANT_SIGFPE_HANDLER branch in 
Include/fpectl.h

--

___
Python tracker 

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

[issue28870] Reduce stack consumption of PyObject_CallFunctionObjArgs() and like

[STINNER Victor]

STINNER Victor added the comment:

In Python 3.5, PyObject_CallFunctionObjArgs() calls objargs_mktuple() which 
uses Py_VA_COPY(countva, va) and creates a tuple. The tuple constructor uses a 
free list to reduce the cost of heap memory allocations.

--

___
Python tracker 

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

[issue28870] Reduce stack consumption of PyObject_CallFunctionObjArgs() and like

[STINNER Victor]

STINNER Victor added the comment:

no_small_stack.patch: And now something completely different, a patch to remove 
the "small stack" alllocated on the C stack, always use the heap memory. FYI I 
created no_small_stack.patch from less_stack.patch.

As expected, the stack usage is lower:

* less_stack.patch: 384 bytes/call
* no_small_stack.patch: 368 bytes/call

I didn't check the performance of no_small_stack.patch yet.

--
Added file: http://bugs.python.org/file46120/no_small_stack.patch

___
Python tracker 

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

[issue29131] Calling printf from the cdll does not print the full string

[Eryk Sun]

Eryk Sun added the comment:

> from ctypes import *
> msvcrt = cdll.msvcrt
> message_string = "Hello World!\n"
> msvcrt.printf("Testing: %s", message_string)

Avoid using libraries as attributes of cdll and windll. They get cached, and in 
turn they cache function pointers. Thus all modules contend for cdll and windll 
function prototype definitions (i.e. argtypes, restype, errcheck), and the last 
one to modify the definition wins. Even if you're not setting prototypes (in 
which case you must really like segfaults, data corruption, and 
difficult-to-diagnose errors), your code will still be at the mercy of 
whichever module does set them. Instead use the following:

msvcrt = ctypes.CDLL('msvcrt', use_errno=True)
msvcrt.printf.argtypes = (ctypes.c_char_p,)

CDLL uses the cdecl calling convention. This convention uses caller stack 
cleanup, so we allow passing a variable number of arguments even though the 
above argtypes definition only checks the first argument.

Examples

You'll get an exception if the first argument isn't bytes:

>>> msvcrt.printf("spam and %d %s\n", 42, "eggs")
Traceback (most recent call last):
  File "", line 1, in 
ctypes.ArgumentError: argument 1: : wrong type

Since we're not checking additional arguments, you might accidentally pass a 
wide-character string. In that case of course the output will be wrong:

>>> msvcrt.printf(b"spam and %d %s\n", 42, "eggs")
spam and 42 e
14

Here we get it right:

>>> msvcrt.printf(b"spam and %d %s\n", 42, b"eggs")
spam and 42 eggs
17

Or maybe you need to print a wide-character string, i.e. "%ls" or "%S":

>>> msvcrt.printf(b"spam and %d %ls\n", 42, "eggs")
spam and 42 eggs
17

or

>>> msvcrt.printf(b"spam and %d %S\n", 42, "eggs")
spam and 42 eggs
17

The "%s" and "%S" convention in MSVC predates standard C. In Microsoft's 
printf, "%s" expects a char pointer and "%S" expects a wchar_t pointer, but in 
their wprintf it's the other way around. In standard C "%s" and "%ls" are 
always a char string and a wchar_t string, respectively. MSVC also supports the 
standard "%ls" for wide-character strings, but its non-standard use of "%s" 
requires the introduction of a non-standard "%hs" for char strings.

--

___
Python tracker 

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

[issue29131] Calling printf from the cdll does not print the full string

[Eryk Sun]

Changes by Eryk Sun :


--
Removed message: http://bugs.python.org/msg284525

___
Python tracker 

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

[issue29131] Calling printf from the cdll does not print the full string

[Eryk Sun]

Eryk Sun added the comment:

> from ctypes import *
> msvcrt = cdll.msvcrt
> message_string = "Hello World!\n"
> msvcrt.printf("Testing: %s", message_string)

Avoid using libraries as attributes of cdll and windll. They get cached, and in 
turn they cache function pointers. Thus all modules contend for cdll and windll 
function prototype definitions (i.e. argtypes, restype, errcheck), and the last 
one to modify the definition wins. Even if you're not setting prototypes (in 
which case you must really like segfaults, data corruption, and 
difficult-to-diagnose errors), your code will still be at the mercy of 
whichever module does set them. Instead use the following:

msvcrt = ctypes.CDLL('msvcrt', use_errno=True)
msvcrt.printf.argtypes = (ctypes.c_char_p,)

CDLL uses the cdecl calling convention. This convention uses callee stack 
cleanup, so we allow passing a variable number of arguments even though the 
above argtypes definition only checks the first argument.

Examples

You'll get an exception if the first argument isn't bytes:

>>> msvcrt.printf("spam and %d %s\n", 42, "eggs")
Traceback (most recent call last):
  File "", line 1, in 
ctypes.ArgumentError: argument 1: : wrong type

Since we're not checking additional arguments, you might accidentally pass a 
wide-character string. In that case of course the output will be wrong:

>>> msvcrt.printf(b"spam and %d %s\n", 42, "eggs")
spam and 42 e
14

Here we get it right:

>>> msvcrt.printf(b"spam and %d %s\n", 42, b"eggs")
spam and 42 eggs
17

Or maybe you need to print a wide-character string, i.e. "%ls" or "%S":

>>> msvcrt.printf(b"spam and %d %ls\n", 42, "eggs")
spam and 42 eggs
17

or

>>> msvcrt.printf(b"spam and %d %S\n", 42, "eggs")
spam and 42 eggs
17

The "%s" and "%S" convention in MSVC predates standard C. In Microsoft's 
printf, "%s" expects a char pointer and "%S" expects a wchar_t pointer, but in 
their wprintf it's the other way around. In standard C "%s" and "%ls" are 
always a char string and a wchar_t string, respectively. MSVC also supports the 
standard "%ls" for wide-character strings, but its non-standard use of "%s" 
requires the introduction of a non-standard "%hs" for char strings.

--
nosy: +eryksun

___
Python tracker 

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

[issue28870] Reduce stack consumption of PyObject_CallFunctionObjArgs() and like

[STINNER Victor]

STINNER Victor added the comment:

testcapi_stacksize.patch: add 
_testcapi.pyobjectl_callfunctionobjargs_stacksize(), function used to measure 
the stack consumption.

--
Added file: http://bugs.python.org/file46119/testcapi_stacksize.patch

___
Python tracker 

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

[issue29137] Fix fpectl-induced ABI breakage

[Nick Coghlan]

Changes by Nick Coghlan :


--
nosy: +ncoghlan

___
Python tracker 

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

[issue28839] _PyFunction_FastCallDict(): replace PyTuple_New() with PyMem_Malloc()

[STINNER Victor]

STINNER Victor added the comment:

fastcalldict-4.patch: Rebased patch.

kw1: Median +- std dev: [ref] 290 ns +- 3 ns -> [patch] 253 ns +- 21 ns: 1.14x 
faster (-13%)
kw5: Median +- std dev: [ref] 438 ns +- 33 ns -> [patch] 394 ns +- 27 ns: 1.11x 
faster (-10%)
kw10: Median +- std dev: [ref] 663 ns +- 14 ns -> [patch] 617 ns +- 16 ns: 
1.07x faster (-7%)

This patch still always allocated 10 pointers (80 bytes) on the C stack: see 
issue #28870 which discuss options to use less memory.

--
Added file: http://bugs.python.org/file46118/fastcalldict-4.patch

___
Python tracker 

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

[issue28839] _PyFunction_FastCallDict(): replace PyTuple_New() with PyMem_Malloc()

[STINNER Victor]

STINNER Victor added the comment:

I pushed the two obvious and safe optimization of fastcalldict-3.patch.

--

___
Python tracker 

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

[issue28839] _PyFunction_FastCallDict(): replace PyTuple_New() with PyMem_Malloc()

[Roundup Robot]

Roundup Robot added the comment:

New changeset 5f7cd3b6c9b1 by Victor Stinner in branch 'default':
Issue #28839: Optimize function_call()
https://hg.python.org/cpython/rev/5f7cd3b6c9b1

New changeset f9dd607dc04c by Victor Stinner in branch 'default':
Optimize _PyFunction_FastCallDict() when kwargs is {}
https://hg.python.org/cpython/rev/f9dd607dc04c

--
nosy: +python-dev

___
Python tracker 

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

[issue27200] make doctest in CPython has failures

[Berker Peksag]

Berker Peksag added the comment:

I agree with Ezio.

--

___
Python tracker 

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

[issue29135] run_proces logs the command without escaping parmaeters such that the coammns logged are not valid

[R. David Murray]

Changes by R. David Murray :


--
resolution: not a bug -> third party
stage:  -> resolved

___
Python tracker 

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

[issue29013] zipfile: inconsistent doc for ZIP64 file size

[Berker Peksag]

Berker Peksag added the comment:

Right, that's my fault. Apparently I missed the "[...] zipfile will create 
[...]" part :) What do you think about Monte's suggested changes Serhiy? Should 
we just revert 4685cd33087b (1) or do both (1) and (2)?

--
stage:  -> needs patch

___
Python tracker 

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

[issue28839] _PyFunction_FastCallDict(): replace PyTuple_New() with PyMem_Malloc()

[STINNER Victor]

STINNER Victor added the comment:

Quick update on the fastcall work.

> I pushed th echange b9c9691c72c5 to replace PyObject_CallFunctionObjArgs() 
> with _PyObject_CallNoArg() or _PyObject_CallArg1(). These functions are 
> simpler and don't allocate memory on the C stack.

Using _PyObject_CallArg1() increased the usage of the C stack: see issue 
#28858. The fix was to remove the _PyObject_CallArg1() macro, replaced with 
PyObject_CallFunctionObjArgs(func, arg, NULL).

There is still an open issue #28870 to reduce the usage of the C stack memory 
even more, but it's more a general optimization.

--

___
Python tracker 

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

[issue15812] inspect.getframeinfo() cannot show first line

[Berker Peksag]

Berker Peksag added the comment:

You're right. Thanks for the review, Serhiy!

--

___
Python tracker 

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

[issue15812] inspect.getframeinfo() cannot show first line

[Roundup Robot]

Roundup Robot added the comment:

New changeset 2b6bdd6cd3f8 by Berker Peksag in branch '3.5':
Issue #15812: Delete redundant max(start, 0)
https://hg.python.org/cpython/rev/2b6bdd6cd3f8

New changeset 7cbcee0c53e3 by Berker Peksag in branch '3.6':
Issue #15812: Merge from 3.5
https://hg.python.org/cpython/rev/7cbcee0c53e3

New changeset 5b0dee884b0b by Berker Peksag in branch 'default':
Issue #15812: Merge from 3.6
https://hg.python.org/cpython/rev/5b0dee884b0b

--

___
Python tracker 

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

[issue29035] regrtest: simplify regex to match test names for the --fromfile option

[STINNER Victor]

STINNER Victor added the comment:

> I don't understand the use case of it ;)

When I modify a codec or something related to text codecs, I would like to run 
all codec tests, not the fully Python test suite. So I use "ls 
Lib/test/test_*codec*py", the list is quite list, it's annoying to have to 
copy/paste test names manually.

> You can call just .group() instead of .group(0).

Done.

Thanks for your review. I added a new unit test for filenames.

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

[issue29035] regrtest: simplify regex to match test names for the --fromfile option

[Roundup Robot]

Roundup Robot added the comment:

New changeset a9fe5bee892b by Victor Stinner in branch 'default':
Issue #29035: Simplify a regex in libregrtest
https://hg.python.org/cpython/rev/a9fe5bee892b

--
nosy: +python-dev

___
Python tracker 

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

[issue29012] __bases__ is a tuple (possibly empty or a singleton)

[Berker Peksag]

Berker Peksag added the comment:

Good point, Serhiy. Thanks for the patch, Jim. I've now removed the "possible a 
singleton" part.

--

___
Python tracker 

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

[issue29012] __bases__ is a tuple (possibly empty or a singleton)

[Roundup Robot]

Roundup Robot added the comment:

New changeset 1aba7cbbcc27 by Berker Peksag in branch '3.5':
Issue #29012: Remove another outdated information
https://hg.python.org/cpython/rev/1aba7cbbcc27

New changeset 7ef5b02b228a by Berker Peksag in branch '3.6':
Issue #29012: Merge from 3.5
https://hg.python.org/cpython/rev/7ef5b02b228a

New changeset f05165a9cae6 by Berker Peksag in branch 'default':
Issue #29012: Merge from 3.6
https://hg.python.org/cpython/rev/f05165a9cae6

--

___
Python tracker 

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

[issue29137] Fix fpectl-induced ABI breakage

[Nathaniel Smith]

New submission from Nathaniel Smith:

It turns out that CPython built with --with-fpectl has a different ABI than 
CPython built without --with-fpectl (which is the default). Specifically, if 
you have an extension module built against a --with-fpectl CPython, and it uses 
the PyFPE_{START,END}_PROTECT macros (as e.g. Cython modules do), then it ends 
up referring to some symbols that aren't provided by no-fpectl CPython builds.

These macros are part of the stable ABI, so it's possible (though unlikely?) 
that there are existing modules using the stable ABI that refer to these 
symbols.

Mailing list discussion:
   December: 
https://mail.python.org/pipermail/python-dev/2016-December/147065.html
   January: 
https://mail.python.org/pipermail/python-dev/2017-January/147092.html
   Guido's "let's get rid of it": 
https://mail.python.org/pipermail/python-dev/2017-January/147094.html

There are 3 parts to the fpectl machinery:
- macros PyFPE_{START,END}_PROTECT in Include/pyfpe.h, which are part of the 
public C API. Depending on --with-fpectl, these are either no-ops, or else 
refer to:
- global symbols PyFPE_{jbuf,counter,dummy}, defined in Python/pyfpe.c iff 
--with-fpectl is enabled.
- the stdlib module 'fpectl' (Modules/fpectlmodule.c) which provides some 
Python APIs that make use of the information that the macros put into the 
global symbols. (If the user doesn't use fpectl, then the macros do nothing 
except update the global variables.)

>From the python-dev discussion, I think the resolution is:

- for all supported CPython releases, we should modify Python/pyfpe.c so that 
the PyFPE_jbuf and PyFPE_counter are defined unconditionally. (I.e., remove the 
#ifdef WANT_SIGFPE_HANDLER that currently protects their definitions). After 
this change, all CPython builds will be able to import all CPython extension 
modules (though the actual fpectl functionality may or may not be available).

- in the next 3.5 and maybe 3.4 releases, we should add a deprecation warning 
to the fpectl module.

- in the next 2.7 release, we should add a Py3k warning to the fpectl module.

- in trunk / 3.7, we should remove --with-fpectl and the fpectl stdlib module 
entirely. For stable API compatibility we might want to leave the PyFPE_* 
macros (defined as no-ops) and/or the PyFPE_{jbuf,counter,dummy} symbols, but 
nothing will actually use them.

--
components: Extension Modules
messages: 284511
nosy: njs
priority: normal
severity: normal
status: open
title: Fix fpectl-induced ABI breakage
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7

___
Python tracker 

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

[issue29012] __bases__ is a tuple (possibly empty or a singleton)

[Jim Fasarakis-Hilliard]

Jim Fasarakis-Hilliard added the comment:

Yes, I agree with that it seems redundant after the change. I'm attaching 
another small patch based on the committed one to trim that off.

--
Added file: http://bugs.python.org/file46117/fixbasesdoc2.patch

___
Python tracker 

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

[issue29136] Add OP_NO_TLSv1_3

[Benjamin Peterson]

Benjamin Peterson added the comment:

I think that's fine for 2.7.

On Mon, Jan 2, 2017, at 13:07, Christian Heimes wrote:
> 
> New submission from Christian Heimes:
> 
> OpenSSL 1.1.1 is going to provide TLS 1.3. The preferred protocols
> PROTOCOL_TLS (old name PROTOCOL_SSLv23), PROTOCOL_TLS_CLIENT and
> PROTOCOL_TLS_SERVER are going to have TLS 1.3 enabled by default. In
> order to disable TLS 1.3, let's add OP_NO_TLSv1_3 to _ssl.c and guard it
> with #ifdef SSL_OP_NO_TLSv1_3
> 
> https://github.com/openssl/openssl/blob/d2e491f225d465b11f18a466bf399d4a899cb50e/include/openssl/ssl.h#L346
> 
> Benjamin, Larry, Ned, are you ok with a new flag? OpenSSL 1.1.1 won't be
> available any time soon. I like to add the flag *after* the upcoming
> round of releases.
> 
> --
> assignee: christian.heimes
> components: SSL
> messages: 284504
> nosy: benjamin.peterson, christian.heimes, larry, ned.deily
> priority: normal
> severity: normal
> stage: needs patch
> status: open
> title: Add OP_NO_TLSv1_3
> type: enhancement
> versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7
> 
> ___
> Python tracker 
> 
> ___

--

___
Python tracker 

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

[issue29135] run_proces logs the command without escaping parmaeters such that the coammns logged are not valid

[William Gianopoulos]

William Gianopoulos added the comment:

It seems it is part of the Mozilla build system.  I closed this issue.

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

[issue29135] run_proces logs the command without escaping parmaeters such that the coammns logged are not valid

[William Gianopoulos]

William Gianopoulos added the comment:

I would like to keep this open until I figure this out so I can provide a 
pointer to where the real issue is being tracked. I should have time to do that 
tomorrow. SOunds like this is part of some third-party add-on python library 
that is normally provided with  linux builds.

--

___
Python tracker 

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

[issue29135] run_proces logs the command without escaping parmaeters such that the coammns logged are not valid

[William Gianopoulos]

William Gianopoulos added the comment:

OK i t appears it might be a third party python utility library.  I will
try to trak this down and report it there and close this issue once i sort
it out.

On Mon, Jan 2, 2017 at 4:07 PM, William Gianopoulos 
wrote:

>
> William Gianopoulos added the comment:
>
> well i could be screwed up perhaps it is something provided in the mozilla
> python environment i was going by the fact that google searches on python
> run-process returned things, including other reported issues, that made me
> think it was not.
>
> On Mon, Jan 2, 2017 at 4:02 PM, R. David Murray 
> wrote:
>
> >
> > R. David Murray added the comment:
> >
> > What is run_process?  I'm not getting any hits from grep on the standard
> > library.
> >
> > --
> > nosy: +r.david.murray
> >
> > ___
> > Python tracker 
> > 
> > ___
> >
>
> --
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

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

[issue29136] Add OP_NO_TLSv1_3

[Christian Heimes]

New submission from Christian Heimes:

OpenSSL 1.1.1 is going to provide TLS 1.3. The preferred protocols PROTOCOL_TLS 
(old name PROTOCOL_SSLv23), PROTOCOL_TLS_CLIENT and PROTOCOL_TLS_SERVER are 
going to have TLS 1.3 enabled by default. In order to disable TLS 1.3, let's 
add OP_NO_TLSv1_3 to _ssl.c and guard it with #ifdef SSL_OP_NO_TLSv1_3

https://github.com/openssl/openssl/blob/d2e491f225d465b11f18a466bf399d4a899cb50e/include/openssl/ssl.h#L346

Benjamin, Larry, Ned, are you ok with a new flag? OpenSSL 1.1.1 won't be 
available any time soon. I like to add the flag *after* the upcoming round of 
releases.

--
assignee: christian.heimes
components: SSL
messages: 284504
nosy: benjamin.peterson, christian.heimes, larry, ned.deily
priority: normal
severity: normal
stage: needs patch
status: open
title: Add OP_NO_TLSv1_3
type: enhancement
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7

___
Python tracker 

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

[issue29135] run_proces logs the command without escaping parmaeters such that the coammns logged are not valid

[William Gianopoulos]

William Gianopoulos added the comment:

well i could be screwed up perhaps it is something provided in the mozilla
python environment i was going by the fact that google searches on python
run-process returned things, including other reported issues, that made me
think it was not.

On Mon, Jan 2, 2017 at 4:02 PM, R. David Murray 
wrote:

>
> R. David Murray added the comment:
>
> What is run_process?  I'm not getting any hits from grep on the standard
> library.
>
> --
> nosy: +r.david.murray
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

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

[issue29135] run_proces logs the command without escaping parmaeters such that the coammns logged are not valid

[R. David Murray]

R. David Murray added the comment:

What is run_process?  I'm not getting any hits from grep on the standard 
library.

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

[issue28945] get_boundary (and get_filename) invokes unquote twice

[bpoaugust]

bpoaugust added the comment:

The patch is incomplete.

There is another unquote call:

336 return unquote(text)

--

___
Python tracker 

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

[issue29020] collapse_rfc2231_value has inconsistent unquoting

[bpoaugust]

bpoaugust added the comment:

If there are concerns about 3rd party code relying on the current behaviour of 
the function, then just create a new function without the unquoting, and 
deprecate the original function.

The existing function does not always unquote, so any code which relies on it 
is liable to break.

--

___
Python tracker 

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

[issue27200] make doctest in CPython has failures

[Ezio Melotti]

Ezio Melotti added the comment:

I left a few comments on rietveld,
In general, if making the doctest pass entails adding superfluous code (e.g. 
sorted(), , #doctest: +SKIP (if visible), setups/teardowns, or even 
whole files) or removing details that might be useful (ids or filenames in 
reprs), I'd rather skip the snippet altogether.

Keep in mind that most of those snippets are there to document, not for 
testing, so imho the priority should be keeping them clear and to the point.
The behavior of those snippets should already be covered by unittest, so the 
only downside of skipping is that, if the behavior changes, the examples will 
be wrong until someone notices.

If others agree, this should make the patch simpler and easier to review; if 
not, breaking it down in 3-4 patches that address separate issue might also 
help reviewers.

--
nosy: +ezio.melotti

___
Python tracker 

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

[issue29053] Implement >From_ decoding on input from mbox

[bpoaugust]

bpoaugust added the comment:

The patch can be simplified by just looking for b'\n' in the last 6 chars, and 
caching from b'\n' if found.

This would mean more file seeking in exchange for less buffer matching.

--

___
Python tracker 

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

[issue29135] run_proces logs the command without escaping parmaeters such that the coammns logged are not valid

[William Gianopoulos]

New submission from William Gianopoulos:

So, the arguments to run_process are not escaped when logged such that the 
logged command is un-parsable.
The following call:

self.run_process(['notify-send', '--app-name', 'Mozilla Build System', 'Mozilla 
Build System', msg])  where msg='Build complete'

ends up logging the following:

/usr/bin/notify-send --app-name Mozilla Build System Mozilla Build System Build 
complete

Where to be a valid command it needs to be:

/usr/bin/notify-send --app-name 'Mozilla Build System' 'Mozilla Build System' 
'Build complete'


So, I think this needs to either not log the command at all or for each 
parameter replace any occurrence of the character "'" with "\'" and then 
enclose the entire parameter with "'" to make sure the logged command can 
actually be properly parsed.

--
components: Library (Lib)
messages: 284498
nosy: wgianopoulos
priority: normal
severity: normal
status: open
title: run_proces logs the command without escaping parmaeters such that the 
coammns logged are not valid
versions: Python 3.7

___
Python tracker 

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

[issue29134] contextlib doc bug

[YoSTEALTH]

YoSTEALTH added the comment:

typo:
def ContextBase:
to
class ContextBase:

--

___
Python tracker 

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

[issue29134] contextlib doc bug

[YoSTEALTH]

YoSTEALTH added the comment:

@SilentGhost
You are right, I see it now!

If this is the case maybe "ContextBaseClass" should be changed to 
"UserDefinedContextClass" (or something...) having "Base" in the class name was 
confusing, since module "io" has IOBase class that refer to its "base class" 
figured it was the same concept for contextlib as well.

Also it would be nice if example was improved a bit.


Another Idea:
 - why not have an empty context manager base class? like:

def ContextBase:

def __enter__(self):
return self

def __exit__(self, *errors):
pass

This is something anyone can use to extend their class to support context 
manager? I actually have a class like this i have used many times in my 
projects! Its simple yet useful.

--

___
Python tracker 

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

[issue29134] contextlib doc bug

[Marco Buttu]

Marco Buttu added the comment:

Going a bit OT, in the contextlib doc there are two examples that have both 
normal code and shell code in the same code block. In this way we loose the 
prompt syntax highlight, and the code block can also confuse the reader.  In 
the patch attached the two examples are executed entirely in the shell, and 
both are under doctest.

--
keywords: +patch
nosy: +marco.buttu
Added file: http://bugs.python.org/file46116/contextlib.patch

___
Python tracker 

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

[issue29054] pty.py: pty.spawn hangs after client disconnect over nc (netcat)

[Cornelius Diekmann]

Cornelius Diekmann added the comment:

Status change: I proposed a generic test suite for pty.spawn() in issue29070. 
Once we have agreed on the current behavior of pty.spawn() and the test suite 
is merged, I would like to come back to this issue which requests for a change 
in behavior of pty.spawn(). Currently, I would like to document that this issue 
is waiting for issue29070 and this issue doesn't need any attention.

--

___
Python tracker 

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

[issue26228] pty.spawn hangs on FreeBSD 9.3, 10.x

[Cornelius Diekmann]

Cornelius Diekmann added the comment:

I just tested pty.spawn() on OS X 10.6.8 and FreeBSD 11 and it also hangs. It 
works on Linux.

Your patch solves the problem. I proposed a test suite for pty.spawn() in 
issue29070. The test suite currently only exposes the problem, as suggested by 
Martin.

--
nosy: +Cornelius Diekmann

___
Python tracker 

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

[issue29070] Integration tests for pty.spawn on Linux and all other platforms

[Cornelius Diekmann]

Cornelius Diekmann added the comment:

I did a larger update to my proposed patch. I read the pty man pages and posix 
standard and designed a test suite which documents the expected behavior of the 
pty module. The test suite is biased towards my Linux system, but I respect the 
posix standard. Tested on Linux, OS X, and FreeBSD.

The patch introduces no behavioral changes to the actual pty.py module! It 
should be easy to merge.

Changes to pty.py: I made _select and _execlp local definitions of the pty 
module to ease mocking them in the test suite. A comment finally explains why 
pty.py defines STDIN_FILENO, STDOUT_FILENO, ... itself.

All tests pass on Linux.
Tests fail on macOS 10.6.8 and FreeBSD 11. The tests just hang. The patch 
suggested in issue26228 solves these issues. With this patch (or even without 
patch on Linux), the test suite needs about 1 to 2 seconds). I did not include 
the patch of issue26228 into the patch proposed here since I promised no change 
in behavior to the pty module. We now have a lot of test cases for the pty 
module and we are now finally aware that something is broken in the module. 
It's better to have failing tests than to have no tests at all :-)

I included the change to the documentation I proposed in issue29054.

The test suite does several things:

* SmallPtyTests mainly tests the _copy loop and documents current behavior. As 
issue issue26228 has shown, this behavior is not what one would expect. When 
adding the patch for the mentioned issue, one also needs to adapt 
test__copy_eof_on_all and test__copy_eof_on_master. These tests will make it 
easier to resolve issue26228 since they provide a clear documentation of the 
current behavior and contribute the missing test cases.

* PtyTest is left unchanged.

* One has probably noticed that the current test_pty.py suite randomly fails. I 
introduced _os_read_exactly and _os_read_only to make all new tests 
deterministic and easy to debug.

* PtyPosixIntegrationTest does a very simple integration test by spawning the 
programs `true' and `false'. Currently, these tests hang on the platforms where 
pty.spawn() is broken and testing cannot continue. As stated above, with the 
patch, everything is fine also on FreeBSD and OS X.

* PtyMockingExecTestBase is a base class where I prepare to replace the actual 
exec-call made by pty.spawn() to only run local python code. This makes it 
possible to test pty.spawn() in a portable, platform-independent manner (where 
platform-independent means posix-compatible).

* PtyWhiteBoxIntegrationPingPong1000Test exchanges a thousand Ping Pong 
Messages between master and the pty.spawn()ed slave.

* PtyWhiteBoxIntegrationReadSlaveTest tests that we read all data from the 
slave. This test is inspired by msg283912 and it shows that my naive patch in 
the beginning of issue29054 would lose data.

* PtyWhiteBoxIntegrationTermiosTest tests "advanced" features of terminals. The 
pty.spawn() function is the ultimate integration test setup for this.


Waiting for a review :-)

--
Added file: http://bugs.python.org/file46115/pty_tests.patch

___
Python tracker 

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

[issue29134] contextlib doc bug

[SilentGhost]

SilentGhost added the comment:

ContextBaseClass is meant to represent a user-defined class that is a parent of 
mycontext.

--
nosy: +SilentGhost

___
Python tracker 

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

[issue29133] Minor inaccuracy in shlex.shlex punctuation_chars example

[Marco Buttu]

Marco Buttu added the comment:

Thank you. The patch fixes it and makes the example under doctest.

--
keywords: +patch
nosy: +marco.buttu
Added file: http://bugs.python.org/file46114/issue29133.patch

___
Python tracker 

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

[issue29134] contextlib doc bug

[Chris Warrick]

Changes by Chris Warrick :


--
nosy: +Kwpolska

___
Python tracker 

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

[issue29134] contextlib doc bug

[YoSTEALTH]

New submission from YoSTEALTH:

Link: 
https://docs.python.org/3/library/contextlib.html#contextlib.ContextDecorator

"from contextlib import ContextDecorator

class mycontext(ContextBaseClass, ContextDecorator):"

"ContextBaseClass" is referenced but its no where to be found in source.

--
messages: 284489
nosy: YoSTEALTH
priority: normal
severity: normal
status: open
title: contextlib doc bug

___
Python tracker 

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

[issue29128] No way to instsall win32com on python 3.6

[Zachary Ware]

Changes by Zachary Ware :


--
resolution:  -> third party
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

[issue29125] Shell injection via TIX_LIBRARY when using tkinter.tix

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Here is a fix.

--
keywords: +patch
Added file: http://bugs.python.org/file46113/tix_library_shell_injection.patch

___
Python tracker 

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

[issue29125] Shell injection via TIX_LIBRARY when using tkinter.tix

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
stage:  -> patch review

___
Python tracker 

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

[issue29125] Shell injection via TIX_LIBRARY when using tkinter.tix

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

I agreed that this security issue has low severity. Only applications that use 
Tix are vulnerable, and this is very small number of applications.

--

___
Python tracker 

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

[issue29125] Shell injection via TIX_LIBRARY when using tkinter.tix

[Christian Heimes]

Christian Heimes added the comment:

yeah, sounds totally fine to me. It's a low risk change and the issue has a 
small attack surface. I set the priority to release blocker to draw your 
attention.

--

___
Python tracker 

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

[issue29125] Shell injection via TIX_LIBRARY when using tkinter.tix

[Larry Hastings]

Larry Hastings added the comment:

This code hasn't changed in years.  So while I believe it's a security bug and 
should be fixed, I don't know if I agree it's a bad enough security bug to stop 
Python 3.5.3rc1, which is literally in the middle of the release process.

I'm guessing this is easily fixed (if not os.path.isfile(tixlib): return), so 
how about we release 3.5.3rc1 with this bug and I'll cherry-pick this fix for 
3.5.3 final.

--

___
Python tracker 

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

[issue29132] shlex.shlex with punctuation_chars and posix doesn't handle punctuation next to quotes

[Evan]

Evan added the comment:

I've attached a simplistic patch which fixes the problem. I suspect a better 
fix might be to shuffle the elif branches around so the extra condition isn't 
necessary. Vinay, what are your thoughts?

--
keywords: +patch
Added file: http://bugs.python.org/file46112/shlex-posix-quote.diff

___
Python tracker 

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

[issue29124] Freeze fails to compile on windows

[Steve Dower]

Steve Dower added the comment:

Ah, I was thinking of platform.machine().

--

___
Python tracker 

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

[issue29131] Calling printf from the cdll does not print the full string

[R. David Murray]

Changes by R. David Murray :


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

[issue29125] Shell injection via TIX_LIBRARY when using tkinter.tix

[Christian Heimes]

Changes by Christian Heimes :


--
nosy: +benjamin.peterson, christian.heimes, larry, ned.deily
priority: normal -> release blocker

___
Python tracker 

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

[issue28595] shlex.shlex should not augment wordchars

[Evan]

Evan added the comment:

I've attached a more complete patch. This takes the conservative approach of 
retaining all functionality of 3.6 and treating this as a new feature for 3.7. 
I don't think this is suitable for 3.6.1 given this new behavior contradicts 
what is currently written in the documentation (though this can be discussed 
further).

I've also run into a couple of other bugs that I've made separate issues for:

* The example in the documentation mixes up 'Old' and 'New' (issue29133)
* The updated example contains a bug (the '>abc' token should actually be two 
tokens) (issue29132)

These should both be fixed in 3.6.1 regardless of where this goes.

--
versions: +Python 3.7
Added file: http://bugs.python.org/file46111/shlex.diff

___
Python tracker 

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

[issue29133] Minor inaccuracy in shlex.shlex punctuation_chars example

[Evan]

New submission from Evan:

https://docs.python.org/3/library/shlex.html#improved-compatibility-with-shells

The code sample here does not match the output - the first line is labelled 
'New' and the second line 'Old'.

--
assignee: docs@python
components: Documentation
messages: 284481
nosy: docs@python, evan_
priority: normal
severity: normal
status: open
title: Minor inaccuracy in shlex.shlex punctuation_chars example
versions: Python 3.6, Python 3.7

___
Python tracker 

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

[issue29132] shlex.shlex with punctuation_chars and posix doesn't handle punctuation next to quotes

[Evan]

New submission from Evan:

When both punctuation_chars and posix are used, any punctuation directly next 
to quoted characters is interpreted as a single token.

>>> from shlex import shlex
>>> list(shlex('>"a"', posix=True))
['>', 'a']
>>> list(shlex('>"a"', punctuation_chars=True))
['>', '"a"']
>>> list(shlex('>"a"', posix=True, punctuation_chars=True))
['>a']  # should be ['>', 'a']

--
components: Library (Lib)
messages: 284480
nosy: evan_, r.david.murray, vinay.sajip
priority: normal
severity: normal
status: open
title: shlex.shlex with punctuation_chars and posix doesn't handle punctuation 
next to quotes
versions: Python 3.6, Python 3.7

___
Python tracker 

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

[issue29071] IDLE doesn't highlight f-strings properly

[Terry J. Reedy]

Terry J. Reedy added the comment:

The doc appears to be carefully accurate, but the second sentence especially is 
a bit awkward.  I will open a new issue.

--

___
Python tracker 

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

[issue29006] 2.7.13 _sqlite more prone to "database table is locked"

[Marc-Andre Lemburg]

Marc-Andre Lemburg added the comment:

As general comment, I think you'd have to check which operation modes SQLite 
supports for the case of a transaction commit/rollback in the light of open 
cursors.

ODBC defines the following cases and each data source can specify a different 
behavior (https://msdn.microsoft.com/en-us/library/ms711769%28v=vs.85%29.aspx):

 * All cursors are closed, and access plans for prepared statements on that 
connection are deleted.

 * All cursors are closed, and access plans for prepared statements on that 
connection remain intact.

 * All cursors remain open, and access plans for prepared statements on that 
connection remain intact.

The Python DB-API does not specify any particular behavior (since this depends 
on the database backend), so I guess pysqlite3 should implement whatever SQLite 
supports per default in such cases (or make this configurable).

BTW: It is quite common for databases to support the second mode of operation:

 * All cursors are closed, and access plans for prepared statements on that 
connection remain intact.

since this allows pooling cursors to cache often used access plans.

--
nosy: +lemburg

___
Python tracker 

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

[issue29128] No way to instsall win32com on python 3.6

[Chi Hsuan Yen]

Chi Hsuan Yen added the comment:

https://github.com/pywin32/pypiwin32/pull/2

Anyway this is not a Python issue but pywin32's.

--
nosy: +Chi Hsuan Yen

___
Python tracker 

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

[issue29128] No way to instsall win32com on python 3.6

[Evan]

Evan added the comment:

This package doesn't yet have a wheel for Python 3.6, so it falls back on the 
source distribution, and the setup.py file doesn't run under Python 3.

You can either wait for the maintainer to upload the new wheel to PyPI, or take 
one of the recently built installers from 
https://sourceforge.net/projects/pywin32/files/pywin32/Build%20220/

--
nosy: +evan_

___
Python tracker 

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

[issue29013] zipfile: inconsistent doc for ZIP64 file size

[Monte Davidoff]

Monte Davidoff added the comment:

Serhiy, thank you for the correction and the additional information. I tried 
reading a zip file larger than 4 GiB with allowZip64=False, and it worked, so 
it looks like allowZip64 only applies to writing. I suggest we fix the 
inconsistency in the documentation as follows:

(1) In the description of the zipfile.ZipFile class, revert the change back to:

"If allowZip64 is True (the default) zipfile will create ZIP files that use the 
ZIP64 extensions when the zipfile is larger than 2 GiB."

(2) Change the second paragraph in the zipfile module documentation from:

"It can handle ZIP files that use the ZIP64 extensions (that is ZIP files that 
are more than 4 GiB in size)."

to:

"It can handle ZIP files that use the ZIP64 extensions (that is ZIP files that 
are more than 2 GiB in size)."

--

___
Python tracker 

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

[issue24725] test_socket testFDPassEmpty fails on OS X 10.11+ with "Cannot allocate memory"

[Ned Deily]

Ned Deily added the comment:

This issue slipped off the radar (so to speak) after being closed.  For one, 
the tests also fail on 3.5.x (and probably earlier systems) and fail on macOS 
10.12, not just 10.11.  And, two, I'm not sure if anyone opened an issue with 
Apple about it.  I'm re-opening it and assigning it to me to address those 
things.

--
assignee:  -> ned.deily
resolution: fixed -> 
stage: resolved -> needs patch
status: closed -> open
title: test_socket testFDPassEmpty fails on OS X 10.11 DP with "Cannot allocate 
memory" -> test_socket testFDPassEmpty fails on OS X 10.11+ with "Cannot 
allocate memory"
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