date:20190918



Change by miss-islington :


--
pull_requests: +15863
pull_request: https://github.com/python/cpython/pull/16274

___
Python tracker 

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

[issue38218] SyntaxError in Tutorial 8.6 Defining Clean-up Actions



Change by miss-islington :


--
pull_requests: +15864
pull_request: https://github.com/python/cpython/pull/16275

___
Python tracker 

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

[issue38220] Wrong values for %b and %B in ca_ES and ca_AD locales

2019-09-18 Thread Eryk Sun


Eryk Sun  added the comment:

The result from strftime is platform dependent. In Windows, the result has a 
trailing "." for the abbreviated names that are less than four characters, but 
no "de" in either form:

>>> months = [(2019, m) + (0,)*7 for m in range(1,13)]
>>> locale.setlocale(locale.LC_ALL, 'ca_ES.utf8')
'ca_ES.utf8'
>>> print(*(time.strftime('%b|%B', m) for m in months), sep='\n')
gen.|gener
febr.|febrer
març|març
abr.|abril
maig|maig
juny|juny
jul.|juliol
ag.|agost
set.|setembre
oct.|octubre
nov.|novembre
des.|desembre

In Linux, the result uses the same base abbreviations as in Windows, including 
the trailing ".", but it also includes "de" or "d'" in both forms:

>>> months = [(2019, m) + (0,)*7 for m in range(1,13)]
>>> locale.setlocale(locale.LC_ALL, 'ca_ES.utf8')
'ca_ES.utf8'
>>> print(*(time.strftime('%b|%B', m) for m in months), sep='\n')
de gen.|de gener
de febr.|de febrer
de març|de març
d’abr.|d’abril
de maig|de maig
de juny|de juny
de jul.|de juliol
d’ag.|d’agost
de set.|de setembre
d’oct.|d’octubre
de nov.|de novembre
de des.|de desembre

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

[issue38218] SyntaxError in Tutorial 8.6 Defining Clean-up Actions



Change by miss-islington :


--
pull_requests: +15862
pull_request: https://github.com/python/cpython/pull/16273

___
Python tracker 

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

[issue38218] SyntaxError in Tutorial 8.6 Defining Clean-up Actions



Change by miss-islington :


--
pull_requests: +15861
pull_request: https://github.com/python/cpython/pull/16272

___
Python tracker 

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

[issue38116] Make select module PEP-384 compatible

2019-09-18 Thread Paulo Henrique Silva



Change by Paulo Henrique Silva :


--
nosy: +phsilva

___
Python tracker 

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

[issue38221] Enhancement to pydoc for Python 3.6 to allow full backgrounding as a server

2019-09-18 Thread Lindsay Haisley



New submission from Lindsay Haisley :

This patch extends the functionality of pydoc3 to allow it to run purely as a 
server, as is the case with pydoc for python 2.7. If the -d option is 
specified, pydoc as a server (-p  option) may be backgrounded to a 
subshell with "&".

--
assignee: docs@python
components: Documentation
files: pydoc3.diff
keywords: patch
messages: 352766
nosy: docs@python, fmouse
priority: normal
severity: normal
status: open
title: Enhancement to pydoc for Python 3.6 to allow full backgrounding as a 
server
type: enhancement
versions: Python 3.6
Added file: https://bugs.python.org/file48613/pydoc3.diff

___
Python tracker 

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

[issue38205] Python no longer compiles without small integer singletons

2019-09-18 Thread Ammar Askar



Ammar Askar  added the comment:

For the control path warning, that can be fixed by just hinting to the compiler 
that the function doesn't return like so:

  # ifdef __GNUC__
  __attribute__ ((noreturn))
  # elif defined(_MSC_VER)
  __declspec(noreturn)
  # endif
  static inline void
  _Py_UNREACHABLE()
  {


(https://godbolt.org/z/AG9tx_)

--
nosy: +ammar2

___
Python tracker 

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

[issue38205] Python no longer compiles without small integer singletons

2019-09-18 Thread Ma Lin



Ma Lin  added the comment:

PR 16270 use Py_UNREACHABLE() in a single line.
It solves this particular issue.

--

___
Python tracker 

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

[issue38205] Python no longer compiles without small integer singletons

2019-09-18 Thread Ma Lin



Change by Ma Lin :


--
keywords: +patch
pull_requests: +15860
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/16270

___
Python tracker 

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

[issue38205] Python no longer compiles without small integer singletons

2019-09-18 Thread Ma Lin



Ma Lin  added the comment:

If use static inline function, and Py_UNREACHABLE() inside an if-else branch 
that should return a value, compiler may emit warning:
https://godbolt.org/z/YtcNSf

MSVC v19.14:
warning C4715: 'test': not all control paths return a value

clang 8.0.0:
warning: control may reach end of non-void function [-Wreturn-type]

Other compilers (gcc, icc) don't emit this warning.

This situation in real code:
https://github.com/python/cpython/blob/v3.8.0b4/Include/object.h#L600
https://github.com/python/cpython/blob/v3.8.0b4/Objects/longobject.c#L3088

--

___
Python tracker 

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

[issue17822] Save on Close windows (IDLE)

2019-09-18 Thread Terry J. Reedy



Terry J. Reedy  added the comment:

AttributeErrors on closing were a separate issue.  They are now caught on 
closing.  #35379.

Save on Close is now modal on Windows also, in that one cannot do anything with 
the Window being closed.

One can try to close a second dirty window.  Saying 'no' in either dialog no 
longer crashes.  The only oddity is that if one switched from the 2nd dialog to 
the 1st and say 'no' on the first first, it does not immediately close until 
one answers on the second.  It seems normal to me that the 2nd call that raises 
the 2nd dialog blocks the 1st from receiving and responding to the 1st click 
until the 2nd call returns.  

Thus the bugs reported here have been otherwise fixed.

--
resolution:  -> out of date
stage: test needed -> 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

[issue29258] init.py required for pkgutil.walk_packages in python3

2019-09-18 Thread Eric Wieser



Change by Eric Wieser :


--
nosy: +Eric Wieser

___
Python tracker 

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

[issue35379] IDLE's close fails io is set to None on Mac

2019-09-18 Thread Terry J. Reedy



Terry J. Reedy  added the comment:

#17822 is not what I was thinking of, nor are #17614 or #22614, so I considered 
this issue done for now.

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

[issue38216] Fix for issue30458 prevents crafting invalid requests

2019-09-18 Thread Tim Burke



Change by Tim Burke :


--
nosy: +tburke

___
Python tracker 

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

[issue30458] [security][CVE-2019-9740][CVE-2019-9947] HTTP Header Injection (follow-up of CVE-2016-5699)

2019-09-18 Thread Ned Deily



Ned Deily  added the comment:

With the breaking out of the portential and/or actual regression (e.g. invalid 
requests can no longer be crafted) into Issue38216, itself a potential release 
blocker, we are still left here with the as-yet unresolved issue identified 
above in msg34728 (e.g. not checking for control characters in the "host" part 
of the URL, only the "path" part).  Since this also affects so many 
branches/releases and has external components (CVE's, third-party impacts), it 
probably would have made sense to break it out into a separate issue (and maybe 
it still does).  But since this problem has been present for many releases 
(apparently), I would rather not further hold the 3.7.5 release for a 
resolution (though that would be a good thing) so I'm going to change the 
priority for the moment to "deferred blocker".

But we need someone (preferably a core dev already involved) to take charge of 
this and push it to a resolution.  Thanks for everyone's help so far!

--
priority: release blocker -> deferred blocker

___
Python tracker 

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

[issue38216] Fix for issue30458 prevents crafting invalid requests

2019-09-18 Thread Ned Deily



Ned Deily  added the comment:

Thanks for identifying this issue and breaking it out into a separate bpo, 
Jason.  If I understand correctly, the problematic fix for Issue30458 has 
already been released in maintenance release 3.7.4 and security release 3.6.9, 
is in the current security release candidate 3.5.8rc1, as well as 3.8.0b4, and, 
without further action, will be in 2.7.17rc1 and continue to be in 3.7.5rc1.  
In other words, this issue potentially affects all currently maintained Python 
branches and/or releases.  (In addition, there appear to be still unresolved 
questions about the original Issue30458 and the CVE's associated with it.  But 
let's ignore those here. My brain hurts enough already.)

The immediate question for me is what to do about 3.7.5.  We could:
1. hold 3.7.5rc1 for a mitigation fix
2. release 3.7.5rc1 and accept a fix for 3.7.5final or for an unplanned 3.7.5rc2
3. fix in 3.7.6
4. do nothing other than possibly a doc change

Since 3.5.8rc1 is already released for testing, a similar decision needs to be 
made for it.

And 3.8.0rc1 and 2.7.17rc1 are schedulded for tagging om the coming weeks.

Since the problem. as best I understand, is most likely to impact tests rather 
than legitimate user cases (is that correct?) and, since at least some projects 
and users of 3.7.4 impacted by the change have developed workarounds, and since 
3.7.5rc1 is being delayed pending a resolution of this, I think the best 
options for 3.7.5 at this point are either 2 or 3 above.  So, unless someone 
expresses a major objection in the next few hours, I am going to proceed with 
3.7.5rc1 as is with the hope that we will have final resolution prior to 3.7.5 
final.

Decisions will still have to be made by the other RMs for their branches.

--
nosy: +benjamin.peterson, larry, lukasz.langa, ned.deily
priority: normal -> release blocker
versions: +Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 
3.9

___
Python tracker 

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

[issue38205] Python no longer compiles without small integer singletons

2019-09-18 Thread Zachary Ware



Zachary Ware  added the comment:

I have poked at this a bit and have an implementation that defines a `static 
inline void _Py_Unreachable()` in pymacro.h, see 
https://github.com/zware/cpython/commit/d07b4255dc1170155e18db0fea99ec1cb29c2f0a

This works on at least macOS and Windows, and we also have prior art for 
defining static inline functions in headers in GH-10079.  If we agree that 
that's an acceptable solution, I'll open a PR for that change.

--

___
Python tracker 

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

[issue38205] Python no longer compiles without small integer singletons

2019-09-18 Thread Gregory P. Smith



Gregory P. Smith  added the comment:

While I don't like how that get_small_int macro is defined...
and I don't like that Py_UNREACHABLE() was usable as an expression in the 
past...

it is probably best to just revert 3ab61473ba7f3dca32d779ec2766a4faa0657923.

The choice to use a macro for this when it was created and the way the macro 
was defined means it is an expression forever unless we want to bother forcing 
code cleanups for uses of it.

--

___
Python tracker 

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

[issue34820] binascii.c:1578:1: error: the control flow of function ‘binascii_crc32’ does not match its profile data (counter ‘arcs’)

2019-09-18 Thread Ned Deily



Change by Ned Deily :


--
stage: resolved -> needs patch
status: closed -> open

___
Python tracker 

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

[issue38220] Wrong values for %b and %B in ca_ES and ca_AD locales

2019-09-18 Thread Joan



Joan  added the comment:

Issue can be reproduced with this snippet:
---
import locale
from datetime import datetime
locale.setlocale(locale.LC_ALL, 'ca_AD.utf8')
locale.setlocale(locale.LC_ALL, 'ca_ES.utf8')
#locale.setlocale(locale.LC_ALL, 'es_ES.utf8')
now = datetime.now() # current date and time
date_time = now.strftime("|%b|%B|")
print("date and time:",date_time)   
---

--

___
Python tracker 

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

[issue38220] Wrong values for %b and %B in ca_ES and ca_AD locales

2019-09-18 Thread Joan


New submission from Joan :

There's an incorrect behaviour in the output for the strftime values when in 
catalan.
On the documentation at 
https://docs.python.org/3.7/library/datetime.html#strftime-strptime-behavior:

- %b Month as locale’s abbreviated name. Jan, Feb, …, Dec (en_US)
- %B Month as locale’s full name. January, February, …, December (en_US);

It works also in es_ES an others, while in catalan there's an extra article on 
the month name (and a point in the abbreviated version) that shouldn't be there 
de "set." and "de setembre".

Where should I go to fix this and get the documented behaviour? I haven't been 
able to find a translation section on python site.

--
components: Library (Lib)
messages: 352755
nosy: aseques
priority: normal
severity: normal
status: open
title: Wrong values for %b and %B in ca_ES and ca_AD locales
type: behavior
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

[issue34820] binascii.c:1578:1: error: the control flow of function ‘binascii_crc32’ does not match its profile data (counter ‘arcs’)

2019-09-18 Thread David Cuthbert



Change by David Cuthbert :


--
versions: +Python 3.8

___
Python tracker 

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

[issue34820] binascii.c:1578:1: error: the control flow of function ‘binascii_crc32’ does not match its profile data (counter ‘arcs’)

2019-09-18 Thread David Cuthbert



David Cuthbert  added the comment:

I'm seeing this on a rebuild now of Python 3.7.4 on Ubuntu 18.04 (in my case 
against _ssl.c).

What's happening is there's coverage/profiling data being generated in the 
build chain (somewhere), which spits out files named *.gcda. Interestingly, 
make clean does *not* clean these files up.

gcc is attempting to use this data in its optimization, but discovers that it's 
now bogus -- likely due to system library headers (like OpenSSL) being updated 
in the meantime, with some inline code causing the coverage data to become 
invalid.

The fix should be to have 'make clean' clean up these *.gcda files. In the 
meantime, the workaround is to run "find . -name \*.gcda -exec rm '{}' \;"

--
nosy: +dacut
versions: +Python 3.7 -Python 3.8

___
Python tracker 

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

[issue38219] Optimize dict.init and dict.update for dict argument



Change by Serhiy Storchaka :


--
keywords: +patch
pull_requests: +15859
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/16268

___
Python tracker 

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

[issue38219] Optimize dict.init and dict.update for dict argument



New submission from Serhiy Storchaka :

dict.__init__() and dict.update() with a positional argument look up the "keys" 
attribute of the argument to distinguish a mapping from a sequence of 
item-value pairs. It has a non-trivial cost. Merging dicts is optimized for 
exact dicts in PyDict_Merge(), so it would be worth to optimize also this check.

$ ./python -m pyperf timeit -s "d = {}; D = dict" -- "D(d)"
Unpatched:  Mean +- std dev: 154 ns +- 4 ns
Patched:Mean +- std dev: 110 ns +- 4 ns

$ ./python -m pyperf timeit -s "d = {}" -- "d.update(d)"
Unpatched:  Mean +- std dev: 112 ns +- 3 ns
Patched:Mean +- std dev: 70.4 ns +- 1.5 ns

The cost of the check is about 40 ns, and it is a significant part of the total 
time of creating/updating a small dict.

--
components: Interpreter Core
messages: 352753
nosy: rhettinger, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Optimize dict.__init__ and dict.update for dict argument
type: performance
versions: Python 3.9

___
Python tracker 

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

[issue38200] Adding itertools.pairwise to the standard library?

2019-09-18 Thread Tim Peters



Tim Peters  added the comment:

There's an eternal culture clash here:  functional languages have a long 
history of building in just about everything of plausible use, regardless of 
how trivial to build on other stuff.  This started when LISP was barely 
released before (cadr x) was introduced as a shorthand for (car (cdr x)), and 
(caddr x) for (car (cdr (cdr x))), and so on.  Which more modern functional 
languages also supply (second x) and (third x) spellings for (_and_ nth(2, x) 
and nth(3, x) spellings).

This one is harder to get right than those, but not hard at all.  But it's not 
coincidence that itertoolz[1] (note the trailing 'z') also supplies it, spelled 
`sliding_window(width, iterable)` there.  Working with finite difference 
algorithms is probably "the most obvious" use case for a width of 2.

More esoterically, one of my favorite "technical indicators" for stock analysis 
is a dead simple 20-period simple moving average, which can be built very 
conveniently (although not very efficiently - but I don't usually care) by 
mapping a mean function over a sliding window of width 20.

BTW, if you want padding on each end, you can apply pairwise to `chain([first], 
iterable, [last])`.

A related function is breaking an iterable into _non_-overlapping chunks of a 
given width.  itertoolz spells that "partition".  For me that comes up more 
often than overlapping windows.

I like having these things around, but it's not a big deal.  Perhaps it would 
be an easier decision in Python if we gave up on believing that everything in 
itertools _must_ be coded in C.  In functional idioms sometimes speed isn't the 
point at all, but rather using conventional names for simple but compound 
functionality.  Like that "sliding window" is a concept in its own right.  If 
I'm _picturing_ an algorithm in terms of a sliding window, then - of course - 
the shortest distance to working code is to use a facility that already 
implements that concept.

Which is a long way of saying +0.

[1] https://toolz.readthedocs.io/en/latest/api.html

--

___
Python tracker 

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

[issue30458] [security][CVE-2019-9740][CVE-2019-9947] HTTP Header Injection (follow-up of CVE-2016-5699)



Jason R. Coombs  added the comment:

I've created issue38216 to address the (perceived) regression.

--

___
Python tracker 

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

[issue38216] Fix for issue30458 prevents crafting invalid requests



Change by Jason R. Coombs :


--
keywords: +3.6regression, 3.7regression

___
Python tracker 

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

[issue36274] http.client cannot send non-ASCII request lines



Jason R. Coombs  added the comment:

That's right - no longer a 3.7 regression here.

--
keywords:  -3.7regression

___
Python tracker 

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

[issue38200] Adding itertools.pairwise to the standard library?

2019-09-18 Thread Vedran Čačić


Vedran Čačić  added the comment:

I also use it all the time. Most recently in some numerical calculation for 
successive differences. My main problem is that I'm too often tempted to just 
zip l with l[1:], thereby restricting the code to sequences, when it would work 
perfectly well for any iterable. (Just as I sometimes write range(lots of 
nines) instead of itertools.count() *shame*;)

--
nosy: +veky

___
Python tracker 

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

[issue38215] Do not import modules in star-import when all is not defined.

2019-09-18 Thread Ethan Furman



Ethan Furman  added the comment:

It's the casual users' code that will break.

--

___
Python tracker 

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

[issue38215] Do not import modules in star-import when all is not defined.



Serhiy Storchaka  added the comment:

I believe that significant part or even most of code is writing without using 
linters and type checkers. Python is too convenient for non-professional 
programmers. You do not need to declare all variables with their types to use 
Python and do not need to run a compiler/linker/checker after editing sources.

There was such mistake (using a module implicitly imported by star-import) even 
in the Python stdlib (fixed now).

This change would increase the quality of code if you do not use __all__ and do 
not have habits to write "import sys as _sys". It will not affect professional 
code. It is just a small step in the direction of been casual user friendly.

--

___
Python tracker 

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

[issue38218] SyntaxError in Tutorial 8.6 Defining Clean-up Actions

2019-09-18 Thread Roundup Robot



Change by Roundup Robot :


--
keywords: +patch
pull_requests: +15858
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/16265

___
Python tracker 

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

[issue38215] Do not import modules in star-import when all is not defined.



Change by Karthikeyan Singaravelan :


--
nosy: +xtreak

___
Python tracker 

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

[issue38218] SyntaxError in Tutorial 8.6 Defining Clean-up Actions

2019-09-18 Thread Jason Plurad



New submission from Jason Plurad :

The second code example in Tutorial section 8.6 defines the function:

def bool_return(): -> bool:

which throws a SyntaxError: invalid syntax

If the function wants to use a return annotation, there should not be a colon 
after the function name. I have a pull request ready for this.

--
assignee: docs@python
components: Documentation
messages: 352746
nosy: Jason Plurad, docs@python
priority: normal
severity: normal
status: open
title: SyntaxError in Tutorial 8.6 Defining Clean-up Actions

___
Python tracker 

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

[issue38215] Do not import modules in star-import when all is not defined.

2019-09-18 Thread Brett Cannon



Change by Brett Cannon :


--
nosy: +brett.cannon

___
Python tracker 

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

[issue38215] Do not import modules in star-import when all is not defined.

2019-09-18 Thread Ethan Furman



Ethan Furman  added the comment:

I don't think this is worth the code breakage.

The advice already given is not to use `import *` unless:

- the module was designed for that usage; or
- you know what you are doing.

--
nosy: +ethan.furman

___
Python tracker 

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

[issue38217] argparse should support multiple types when nargs > 1

2019-09-18 Thread paul j3



paul j3  added the comment:

Which is more valuable to you, the string conversion, or the checking?

What's wrong with doing the 'type check' in post parsing code?  (MarSoft's 
answer in the SO link).

To make a better case for this, I'd suggest writing your own fix.  It doesn't 
need to be a polished push, but enough code to show that the change is 
relatively simple (preferably occurring in only one or two functions).

--

___
Python tracker 

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

[issue38217] argparse should support multiple types when nargs > 1



Change by Karthikeyan Singaravelan :


--
nosy: +paul.j3, rhettinger
versions:  -Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8

___
Python tracker 

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

[issue36274] http.client cannot send non-ASCII request lines



Karthikeyan Singaravelan  added the comment:

> @xtreak the encoded null-byte test would be an extra test case to consider. 
> It is reasonable to test as many known invalid sequences as possible. 
> Changing that byte to encoded notation would just replace one test with 
> another effectively changing the semantics of it.

Agreed that it's slightly different but I also admit I was also relying on the 
fact that encoded request will also be decoded by the server as done in most 
web frameworks to act upon the decoded payload. There could be systems where 
raw null byte might need to be transferred where the receiving system might not 
decode the payload but it seemed to be a workaround to ensure the required 
exception of serving null byte included static file was handled properly by 
CherryPy and also seemed to be adopted by others like urllib3.

> To me, it's quite weird that it's considered a CVE at all: it's happening on 
> the client side and it doesn't prevent the user from just feeding the proper 
> bytes right into the socket so why overcomplicate things?

The impacted function in http is used by functions like urllib.urlopen which is 
often feeded with input from the user that is not validated properly with some 
expectation that the function itself might handle the URL parsing and is safe 
enough. In this case it could lead to things like SSRF where malicious input 
could end up executing arbitrary code in some of the systems like Redis as 
demonstrated in the report. As for the CVE in question it was originally 
reported to golang and the same attack was also found out to be vulnerable. The 
fix adopted also seemed to have address few other security reports of similar 
nature.

Thanks Jason, as issue38216 is now a separate issue we can discuss around 
there. I guess this issue then is not a 3.7 only regression anymore since the 
original issue reported predates 3.7.

--

___
Python tracker 

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

[issue38204] Cannot compile on RPi with optimizations

2019-09-18 Thread Thomas Knox



Thomas Knox  added the comment:

I updated binutils:

pi@pi4b:~/Downloads/Python-3.8.0b4 $ ld --version
GNU ld (GNU Binutils) 2.32

Same problem.

--

___
Python tracker 

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

[issue38215] Do not import modules in star-import when all is not defined.

2019-09-18 Thread Guido van Rossum



Guido van Rossum  added the comment:

I feel that this is a relatively minor issue, and not worth breaking "working" 
code over. Some more pedantic tool like a linter or type checker would be a 
better place to start diagnosing this.

--

___
Python tracker 

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

[issue38217] argparse should support multiple types when nargs > 1

2019-09-18 Thread Ryan Govostes

New submission from Ryan Govostes :

argparse supports consuming multiple command-line arguments with nargs=2, etc.
It converts them to the type given in the argument's type parameter.

argparse does not provide a good solution when the input arguments should be
different data types. For an example, you cannot have an argument that expects
a str followed by an int, '--set-age Bob 34'.

Ordinarily, the suggestion would be to split it into two arguments, like
'--set-person Bob --set-age 34'.

However, this becomes awkward with an action such as 'append', where the
command line arguments become tedious, like '--set-person Bob --set-age 34
--set-person Alice --set-age 29', or confusing, as in '--set-person Bob
--set-person Alice --set-age 34 --set-age 29'.

My proposal is to allow the 'type' parameter to accept a tuple of types:

p.add_argument('--set-age', nargs=2, type=(str, int))

Since 'nargs' is redundant, this could even be simplified to just:

p.add_argument('--set-age', type=(str, int))

The resulting parsed argument would then be a tuple of (str, int), as opposed
to a list. If action='append', the result would be a list of such tuples.

This creates no backwards compatibility issue because tuple instances are not
callable, so this was never valid code that did something else.

A further enhancement could be that when nargs='+' or '*', and a tuple of types
is provided, the types are used round robin: '--set-ages Bob 34 Alice 29'. An
exception would be raised if it would create an incomplete tuple.

See here for other discussion and workarounds:
https://stackoverflow.com/questions/16959101/python-argparse-how-to-have-nargs-2-with-type-str-and-type-int

--
components: Library (Lib)
messages: 352741
nosy: rgov
priority: normal
severity: normal
status: open
title: argparse should support multiple types when nargs > 1
type: enhancement
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

___
Python tracker

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

[issue38216] Fix for issue30458 prevents crafting invalid requests

2019-09-18 Thread Sviatoslav Sydorenko



Change by Sviatoslav Sydorenko :


--
nosy: +webknjaz

___
Python tracker 

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

[issue38216] Fix for issue30458 prevents crafting invalid requests



Change by Karthikeyan Singaravelan :


--
nosy: +xtreak

___
Python tracker 

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

[issue17258] multiprocessing.connection challenge implicitly uses MD5

2019-09-18 Thread Charalampos Stratakis



Change by Charalampos Stratakis :


--
pull_requests: +15857
pull_request: https://github.com/python/cpython/pull/16264

___
Python tracker 

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

[issue36274] http.client cannot send non-ASCII request lines



Jason R. Coombs  added the comment:

I've created issue38216 to address the issue of sending invalid bytes in the 
request line, separate from the original intention and title issue about 
sending non-ASCII.

--

___
Python tracker 

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

[issue38216] Fix for issue30458 prevents crafting invalid requests



New submission from Jason R. Coombs :

The fix for issue30458 prevents any request line from transmitting non-ascii 
characters. In some cases, it's useful to transmit these illegal bytes in order 
to simulate a maliciously-crafted request (such as to ensure a web server 
responds correctly to such a request). This limitation is a regression from 
previous behavior that allowed transmission of such invalid requests.

For example, consider [this 
comment](https://github.com/cherrypy/cherrypy/issues/1781#issuecomment-507836873),
 where tests in CherryPy were disabled due to emergent failures against nightly 
builds.

Originally, I reported this issue in issue36274, but I believe this issue is 
distinct and has a different timeline from that issue.

In [this comment](https://bugs.python.org/issue36274#msg352711), xtreak 
suggests that the proper solution might be not to transmit raw invalid 
characters but to actually rely on URL quoting to "transmit" those bytes. While 
that does seem to exercise CherryPy's error detection properly, I believe it 
still fails to exercise the receipt and handling of raw invalid bytes, but it 
does provide a possible satisfactory mitigation to this issue.

--
messages: 352738
nosy: jaraco
priority: normal
severity: normal
status: open
title: Fix for issue30458 prevents crafting invalid requests

___
Python tracker 

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

[issue38204] Cannot compile on RPi with optimizations

2019-09-18 Thread Ammar Askar



Ammar Askar  added the comment:

Hmm, I think this might be the following gcc/binutils bug: 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84847
https://sourceware.org/bugzilla/show_bug.cgi?id=20882

This might be a bit of a pain but could you try updating binutils and see if 
the problem persists.

--

___
Python tracker 

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

[issue38215] Do not import modules in star-import when all is not defined.



Change by Serhiy Storchaka :


--
keywords: +patch
pull_requests: +15856
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/16263

___
Python tracker 

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

[issue38215] Do not import modules in star-import when all is not defined.



New submission from Serhiy Storchaka :

If __all__ is not defined in a module "from module import *" will import all 
keys from module.__dict__ which does not start with underscore. It can add 
undesired names to the current namespace. The common case is related to 
importing modules.

1. Importing modules which are imported in the original module for internal 
use. Every module usually imports several other modules, and since public 
module names are not underscored, they pollute the namespace of the module. To 
prevent leaking they names you need to import them under underscored name, like 
"import sys as _sys" (if you don't want to use __all__). This is cumbersome and 
makes the module code less readable.

2. Importing submodules. The problem is that the result depends on the history 
of imports. If you imported "module.submodule" before or if it was imported 
implicitly by other module, "from module import *" will import the "submodule" 
name. But if it was not imported before, "from module import *" will import the 
"submodule" name.

The proposed PR excludes modules from importing by star-import if __all__ is 
not defined.

Discussion on Python-ideas: 
https://mail.python.org/archives/list/python-id...@python.org/thread/AKWL7CRCCFACSITAH2NNFBL5BGRKLKJD/

--
components: Interpreter Core
messages: 352736
nosy: gvanrossum, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Do not import modules in star-import when __all__ is not defined.
type: enhancement
versions: Python 3.9

___
Python tracker 

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

[issue38205] Python no longer compiles without small integer singletons

2019-09-18 Thread Zachary Ware



Zachary Ware  added the comment:

Whoops :(.  Fixing this is beyond my C skill.  I'd rather not lose the easter 
egg, but if it can't be fixed properly then 
3ab61473ba7f3dca32d779ec2766a4faa0657923 should just be reverted.

--
nosy: +gregory.p.smith

___
Python tracker 

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

[issue38204] Cannot compile on RPi with optimizations

2019-09-18 Thread Thomas Knox



Thomas Knox  added the comment:

I'll be more than happy to buy you an RPi to do testing on.

--

___
Python tracker 

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

[issue38204] Cannot compile on RPi with optimizations

2019-09-18 Thread Thomas Knox



Thomas Knox  added the comment:

pi@pi4b:~ $ gcc --version
gcc (Raspbian 8.3.0-6+rpi1) 8.3.0

pi@pi4b:~ $ ld --version
GNU ld (GNU Binutils for Raspbian) 2.31.1

--

___
Python tracker 

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

[issue35696] remove unnecessary operation in long_compare()

2019-09-18 Thread Inada Naoki



Change by Inada Naoki :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.9 -Python 3.8

___
Python tracker 

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

[issue35696] remove unnecessary operation in long_compare()

2019-09-18 Thread Inada Naoki



Inada Naoki  added the comment:


New changeset 42acb7b8d29d078bc97b0cfd7c4911b2266b26b9 by Inada Naoki 
(HongWeipeng) in branch 'master':
bpo-35696: Simplify long_compare() (GH-16146)
https://github.com/python/cpython/commit/42acb7b8d29d078bc97b0cfd7c4911b2266b26b9


--
nosy: +inada.naoki

___
Python tracker 

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

[issue30458] [security][CVE-2019-9740][CVE-2019-9947] HTTP Header Injection (follow-up of CVE-2016-5699)



Jason R. Coombs  added the comment:

> Should we open a separate issue to track (fixing) the regression?

Yes, I think so. The ticket I referenced mainly addresses an incompatibility 
that was introduced with Python 3.0, so is much less urgent than the one 
introduced more recently, so I believe it deserves a proper, independent 
description and discussion. I'll gladly file that ticket, tonight most likely.

--

___
Python tracker 

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

[issue37531] Fix regrtest timeout for subprocesses: regrtest -jN --timeout=SECONDS



STINNER Victor  added the comment:

It seems like the new regrtest design doesn't work as I expected.

Calling popen.kill() + popen.stdout.close() + popen.stderr.close() from a 
thread B does not always interrupt popen.communicate() in thread A.

See https://bugs.python.org/issue38207#msg352729 for an example on Linux where 
communicate() still blocks until all child processes complete.

I see different options:

* Revert changes to restore regrtest old design which didn't have these new 
issues

* Find a way to fix bpo-38207 on all platforms: be able to interrupt 
communicate() as soon as the process is killed and/or when all pipes are closed.

* Call communicate() with shorter timeout to workaround the blocking 
communicate() issue (bpo-38207).

* Maybe experiment asyncio which supports asynchronous subprocess.

asyncio subprocess uses overlapped operations which can be cancelled. So maybe 
it isn't affected by bpo-38207.

--

___
Python tracker 

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

[issue38207] subprocess: On Windows, Popen.kill() + Popen.communicate() is blocking until all processes using the pipe close the pipe



STINNER Victor  added the comment:

Hum, I see a similar behavior on Linux. Try attached communicate_close.py (I 
added newlines for readability):
---
vstinner@apu$ python3 communicate_close.py
process 1: pid 13089
process 1: process 2 spawned (pid 13090)
process 1: stdout pipe os.stat_result(st_mode=4480, st_ino=3107861, st_dev=12, 
st_nlink=1, st_uid=1000, st_gid=1000, st_size=0, st_atime=1568816000, 
st_mtime=1568816000, st_ctime=1568816000)
process 1: communicate with process 2 (pid 13090) ...

process 2: pid 13090
process 2: stdout os.stat_result(st_mode=4480, st_ino=3107861, st_dev=12, 
st_nlink=1, st_uid=1000, st_gid=1000, st_size=0, st_atime=1568816000, 
st_mtime=1568816000, st_ctime=1568816000)

process 3: pid 13092
process 3: stdout os.stat_result(st_mode=4480, st_ino=3107861, st_dev=12, 
st_nlink=1, st_uid=1000, st_gid=1000, st_size=0, st_atime=1568816000, 
st_mtime=1568816000, st_ctime=1568816000)

process 1 (thread): kill process 2 (pid 13090)
process 1 (thread): close process 2 stdout pipe (fd 3)

process 3: exit
process 1: communicate with process 2 (pid 13090) ... done in 5.1 sec
---

In process 1, communicate() does not complete immediately when the 
process 1 thread kills process 2 and closes process 2 stdout pipe.

communicate() only completes once process 3 completes.

The stdout file of process 2 and process 3 are the same file.

--
Added file: https://bugs.python.org/file48612/communicate_close.py

___
Python tracker 

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

[issue38214] reduce API specs for objects with slots

2019-09-18 Thread Guido Imperiale


New submission from Guido Imperiale :

The documentation for the pickle module states, about the 3rd element of the 
tuple returned by __reduce__:



Optionally, the object’s state, which will be passed to the object’s 
__setstate__() method as previously described. If the object has no such method 
then, the value must be a dictionary and it will be added to the object’s 
__dict__ attribute.



This doesn't seem correct to me. It should instead read:



Optionally, the object’s state, which will be passed to the object’s 
__setstate__() method as previously described. If the object has no such 
method, then the value must be:

- for objects with only __dict__, a dictionary which will be used to update the 
object’s __dict__ attribute.
- for objects with only __slots__, a tuple of (None, {<__slots__ key>: , 
...})
- for objects with both __dict__ and __slots__, a tuple of ({<__dict__ key>: 
, ...}, {<__slots__ key>: , ...})



--
assignee: docs@python
components: Documentation
messages: 352728
nosy: crusaderky, docs@python
priority: normal
severity: normal
status: open
title: __reduce__ API specs for objects with __slots__
type: behavior
versions: Python 3.7, Python 3.8, Python 3.9

___
Python tracker 

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

[issue30458] [security][CVE-2019-9740][CVE-2019-9947] HTTP Header Injection (follow-up of CVE-2016-5699)

2019-09-18 Thread Larry Hastings



Larry Hastings  added the comment:

Should we open a separate issue to track fixing the regression?

--

___
Python tracker 

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

[issue37531] Fix regrtest timeout for subprocesses: regrtest -jN --timeout=SECONDS



STINNER Victor  added the comment:

Oh wait, test_regrtest.test_multiprocessing_timeout() now also hangs on 
FreeBSD? :-(

AMD64 FreeBSD CURRENT Shared 3.8:
https://buildbot.python.org/all/#/builders/212/builds/226

running: test_regrtest (24 min 52 sec)
0:32:54 load avg: 0.26 [423/423/1] test_regrtest crashed (Exit code 1)
Timeout (0:25:00)!
Thread 0x000800ac (most recent call first):
  File 
"/usr/home/buildbot/python/3.8.koobs-freebsd-current/build/Lib/selectors.py", 
line 415 in select
  File 
"/usr/home/buildbot/python/3.8.koobs-freebsd-current/build/Lib/subprocess.py", 
line 1866 in _communicate
  File 
"/usr/home/buildbot/python/3.8.koobs-freebsd-current/build/Lib/subprocess.py", 
line 1024 in communicate
  File 
"/usr/home/buildbot/python/3.8.koobs-freebsd-current/build/Lib/subprocess.py", 
line 491 in run
  File 
"/usr/home/buildbot/python/3.8.koobs-freebsd-current/build/Lib/test/test_regrtest.py",
 line 504 in run_command
  File 
"/usr/home/buildbot/python/3.8.koobs-freebsd-current/build/Lib/test/test_regrtest.py",
 line 529 in run_python
  File 
"/usr/home/buildbot/python/3.8.koobs-freebsd-current/build/Lib/test/test_regrtest.py",
 line 676 in run_tests
  File 
"/usr/home/buildbot/python/3.8.koobs-freebsd-current/build/Lib/test/test_regrtest.py",
 line 1174 in test_multiprocessing_timeout
  File 
"/usr/home/buildbot/python/3.8.koobs-freebsd-current/build/Lib/unittest/case.py",
 line 633 in _callTestMethod

--

___
Python tracker 

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

[issue36274] http.client cannot send non-ASCII request lines

2019-09-18 Thread Sviatoslav Sydorenko



Sviatoslav Sydorenko  added the comment:

@xtreak the encoded null-byte test would be an extra test case to consider. It 
is reasonable to test as many known invalid sequences as possible. Changing 
that byte to encoded notation would just replace one test with another 
effectively changing the semantics of it.

To me, it's quite weird that it's considered a CVE at all: it's happening on 
the client side and it doesn't prevent the user from just feeding the proper 
bytes right into the socket so why overcomplicate things?

--

___
Python tracker 

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

[issue38203] regrtest fails to stop test_multiprocessing_spawn worker process



miss-islington  added the comment:


New changeset 1a3a48ddaf41dff3c0fcedcfe7ec0940158c568d by Miss Islington (bot) 
in branch '3.7':
bpo-38203: faulthandler.dump_traceback_later() is always available (GH-16260)
https://github.com/python/cpython/commit/1a3a48ddaf41dff3c0fcedcfe7ec0940158c568d


--
nosy: +miss-islington

___
Python tracker 

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

[issue38203] regrtest fails to stop test_multiprocessing_spawn worker process



STINNER Victor  added the comment:


New changeset 064e1e384120635330493abf300b1113eadd904c by Victor Stinner in 
branch '3.8':
bpo-38203: faulthandler.dump_traceback_later() is always available (GH-16260)
https://github.com/python/cpython/commit/064e1e384120635330493abf300b1113eadd904c


--

___
Python tracker 

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

[issue38203] regrtest fails to stop test_multiprocessing_spawn worker process



Change by miss-islington :


--
pull_requests: +15855
pull_request: https://github.com/python/cpython/pull/16261

___
Python tracker 

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

[issue38203] regrtest fails to stop test_multiprocessing_spawn worker process



Change by STINNER Victor :


--
pull_requests: +15854
pull_request: https://github.com/python/cpython/pull/16260

___
Python tracker 

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

[issue38203] regrtest fails to stop test_multiprocessing_spawn worker process



STINNER Victor  added the comment:


New changeset 0a963fbc9c4cf4569f1eadaa2aa1229bb0081256 by Victor Stinner in 
branch 'master':
bpo-38203: faulthandler.dump_traceback_later() is always available (GH-16249)
https://github.com/python/cpython/commit/0a963fbc9c4cf4569f1eadaa2aa1229bb0081256


--

___
Python tracker 

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

[issue38070] visit_decref(): add an assertion to check that the object is not freed



STINNER Victor  added the comment:

Ok, I pushed the most important changes that I wanted to push. I close the 
issue.

--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.8

___
Python tracker 

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

[issue38070] visit_decref(): add an assertion to check that the object is not freed



STINNER Victor  added the comment:


New changeset 47bbab9f76735acc1991e541d12fd18be6b13b16 by Victor Stinner in 
branch '3.8':
[3.8] bpo-38070: Py_FatalError() logs runtime state (GH-16258)
https://github.com/python/cpython/commit/47bbab9f76735acc1991e541d12fd18be6b13b16


--

___
Python tracker 

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

[issue38213] sys.maxsize returns incorrect docstring.

2019-09-18 Thread Steven D'Aprano



Steven D'Aprano  added the comment:

This is not a bug. ``sys.maxsize`` is just an int instance, and it has no 
docstring itself. When you look up ``sys.maxsize.__doc__``, or call 
``help(sys.maxsize)``, the ordinary inheritance rules apply and you get the 
class docstring.

There is nothing magical about ``sys.maxsize``. You will get the same result 
for ``help(2147483647)`` or ``help(1234)`` or any other int. So you are getting 
the correct docstring, the one which belongs to the class.

I'm going to close this as "not a bug", but if you believe that you have a good 
reason to treat this as a bug, please reply. If your argument is convincing, we 
can re-open the ticket.

--
nosy: +steven.daprano
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

[issue38213] sys.maxsize returns incorrect docstring.

2019-09-18 Thread Akash Shende



Akash Shende  added the comment:

Yes. I checked that. Same for sys.maxunicode

--

___
Python tracker 

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

[issue38213] sys.maxsize returns incorrect docstring.



Karthikeyan Singaravelan  added the comment:

sys.maxsize returns an integer so essentially sys.maxsize.__doc__ is giving 
docs for int.__doc__. help(sys) to get to maxsize would help.

maxsize -- the largest supported length of containers.


python3
Python 3.8.0b4 (v3.8.0b4:d93605de72, Aug 29 2019, 21:47:47)
[Clang 6.0 (clang-600.0.57)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> print(sys.maxsize)
9223372036854775807
>>> print(sys.maxsize.__doc__)
int([x]) -> integer
int(x, base=10) -> integer

Convert a number or string to an integer, or return 0 if no arguments
are given.  If x is a number, return x.__int__().  For floating point
numbers, this truncates towards zero.

If x is not a number or if base is given, then x must be a string,
bytes, or bytearray instance representing an integer literal in the
given base.  The literal can be preceded by '+' or '-' and be surrounded
by whitespace.  The base defaults to 10.  Valid bases are 0 and 2-36.
Base 0 means to interpret the base from the string as an integer literal.
>>> int('0b100', base=0)
4


>>> print(int.__doc__)
int([x]) -> integer
int(x, base=10) -> integer

Convert a number or string to an integer, or return 0 if no arguments
are given.  If x is a number, return x.__int__().  For floating point
numbers, this truncates towards zero.

If x is not a number or if base is given, then x must be a string,
bytes, or bytearray instance representing an integer literal in the
given base.  The literal can be preceded by '+' or '-' and be surrounded
by whitespace.  The base defaults to 10.  Valid bases are 0 and 2-36.
Base 0 means to interpret the base from the string as an integer literal.
>>> int('0b100', base=0)
4

--
nosy: +xtreak

___
Python tracker 

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

[issue38213] sys.maxsize returns incorrect docstring.

2019-09-18 Thread Akash Shende



New submission from Akash Shende :

>>> import sys
>>> print(sys.maxsize.__doc__)
int([x]) -> integer
int(x, base=10) -> integer

Convert a number or string to an integer, or return 0 if no arguments
are given.  If x is a number, return x.__int__().  For floating point
numbers, this truncates towards zero.

If x is not a number or if base is given, then x must be a string,
bytes, or bytearray instance representing an integer literal in the
given base.  The literal can be preceded by '+' or '-' and be surrounded
by whitespace.  The base defaults to 10.  Valid bases are 0 and 2-36.
Base 0 means to interpret the base from the string as an integer literal.
>>> int('0b100', base=0)
4

--
components: Library (Lib)
messages: 352716
nosy: akash0x53
priority: normal
severity: normal
status: open
title: sys.maxsize returns incorrect docstring.

___
Python tracker 

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

[issue37904] Suggested edit to Python Tutorial - Section 4



Change by Eric V. Smith :


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

[issue37904] Suggested edit to Python Tutorial - Section 4



Eric V. Smith  added the comment:


New changeset c47c8ba2969c9faf1c036b3dc4b0a5cf0d3aa0cc by Eric V. Smith (Miss 
Islington (bot)) in branch '2.7':
bpo-37904: Edition on python tutorial - section 4 (GH-16169) (GH-16236)
https://github.com/python/cpython/commit/c47c8ba2969c9faf1c036b3dc4b0a5cf0d3aa0cc


--

___
Python tracker 

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

[issue37904] Suggested edit to Python Tutorial - Section 4



Eric V. Smith  added the comment:


New changeset 8b907a8875d1b22d8f060dee9430cc82d471e86b by Eric V. Smith (Miss 
Islington (bot)) in branch '3.7':
bpo-37904: Edition on python tutorial - section 4 (GH-16169) (GH-16235)
https://github.com/python/cpython/commit/8b907a8875d1b22d8f060dee9430cc82d471e86b


--

___
Python tracker 

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

[issue37904] Suggested edit to Python Tutorial - Section 4



Eric V. Smith  added the comment:


New changeset 7a2f68776a77c782c0abf40dc9e3fb687787e730 by Eric V. Smith (Miss 
Islington (bot)) in branch '3.8':
bpo-37904: Edition on python tutorial - section 4 (GH-16169) (GH-16234)
https://github.com/python/cpython/commit/7a2f68776a77c782c0abf40dc9e3fb687787e730


--

___
Python tracker 

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

[issue38070] visit_decref(): add an assertion to check that the object is not freed



Change by STINNER Victor :


--
pull_requests: +15853
pull_request: https://github.com/python/cpython/pull/16258

___
Python tracker 

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

[issue38212] test_multiprocessing_spawn: test_queue_feeder_donot_stop_onexc() failed on x86 Windows7 3.x



New submission from STINNER Victor :

x86 Windows7 3.x:
https://buildbot.python.org/all/#/builders/58/builds/3015

If I recall correctly, this buildbot is known to be slow.

It sounds like a race condition.

ERROR: test_queue_feeder_donot_stop_onexc 
(test.test_multiprocessing_spawn.WithProcessesTestQueue)
--
Traceback (most recent call last):
  File 
"D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\_test_multiprocessing.py",
 line 1132, in test_queue_feeder_donot_stop_onexc
self.assertTrue(q.get(timeout=1.0))
  File 
"D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\multiprocessing\queues.py",
 line 108, in get
raise Empty
_queue.Empty


Extract of the test:

def test_queue_feeder_donot_stop_onexc(self):
# bpo-30414: verify feeder handles exceptions correctly
if self.TYPE != 'processes':
self.skipTest('test not appropriate for {}'.format(self.TYPE))

class NotSerializable(object):
def __reduce__(self):
raise AttributeError
with test.support.captured_stderr():
q = self.Queue()
q.put(NotSerializable())
q.put(True)
# bpo-30595: use a timeout of 1 second for slow buildbots
self.assertTrue(q.get(timeout=1.0))   # <= FAIL HERE =
close_queue(q)

...


Hum, "bpo-30595: use a timeout of 1 second for slow buildbots" sounds like this 
test depends on time which is bad for reliable tests. Would it be possible to 
use a more reliable synchronization primitive?

If no solution is found, the workaround is to use a timeout of 60 seconds 
instead of just 1 second...

--
components: Tests
messages: 352712
nosy: pablogsal, vstinner
priority: normal
severity: normal
status: open
title: test_multiprocessing_spawn: test_queue_feeder_donot_stop_onexc() failed 
on x86 Windows7 3.x
versions: Python 3.9

___
Python tracker 

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

[issue36274] http.client cannot send non-ASCII request lines



Karthikeyan Singaravelan  added the comment:

Is there a reason why cherrypy doesn't URL encode the null byte in this test as 
per comment : 
https://github.com/cherrypy/cherrypy/issues/1781#issuecomment-504476658 ?

The original fix was adopted from golang 
(https://github.com/golang/go/commit/829c5df58694b3345cb5ea41206783c8ccf5c3ca) 
and as per the cherrypy test the golang client also should be forbidding 
invalid control character : https://play.golang.org/p/FTNtRmvlWrn

Also as per the discussion one of our own stdlib tests were depending on this 
behavior in the http client and had to be changed : 
https://github.com/python/cpython/pull/12755#issuecomment-481617878

The change made in Issue30458 also affects urllib3 test in 3.7.4 causing CI 
failure and the related discussion to encode URLs : 
https://github.com/urllib3/urllib3/pull/1671#discussion_r318804155 . urllib3 
issue : https://github.com/urllib3/urllib3/issues/1664 . 

IIRC urllib3 was also patched for this vulnerability in similar manner as part 
of larger refactor : https://github.com/urllib3/urllib3/issues/1553 . I didn't 
verify yet, it's unreleased and how urllib3 client behaves before and after 
patch for the CRLF characters and similar tests that use urllib3 as client.

Applying the URL encoding patch to cherrypy I can verify that the behavior is 
also tested

diff --git a/cherrypy/test/test_static.py b/cherrypy/test/test_static.py
index cdd821ae..85a51cf3 100644
--- a/cherrypy/test/test_static.py
+++ b/cherrypy/test/test_static.py
@@ -398,7 +398,8 @@ class StaticTest(helper.CPWebCase):
 self.assertInBody("I couldn't find that thing")

 def test_null_bytes(self):
-self.getPage('/static/\x00')
+from urllib.parse import quote
+self.getPage(quote('/static/\x00'))
 self.assertStatus('404 Not Found')

 @classmethod


After patch the test passes and ValueError is also raised properly as the null 
byte is decoded in the server and using it in os.stat to resolve null byte path.

Breakages were expected in the discussion as adopting the fix from golang. 
Giving an option like a parameter to bypass the validation was also discussed 
in the linked but giving an option would also mean it could be abused or missed.

--

___
Python tracker 

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

[issue38211] clean up type_init()

2019-09-18 Thread Sergey Fedoseev



Change by Sergey Fedoseev :


--
keywords: +patch
pull_requests: +15852
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/16257

___
Python tracker 

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

[issue38211] clean up type_init()

2019-09-18 Thread Sergey Fedoseev



New submission from Sergey Fedoseev :

I wrote patch that cleans up type_init():

1. Removes conditions already checked by assert()
2. Removes object_init() call that effectively creates an empty tuple and 
checks that this tuple is empty

--
messages: 352710
nosy: sir-sigurd
priority: normal
severity: normal
status: open
title: clean up type_init()

___
Python tracker 

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

[issue37812] Make implicit returns explicit in longobject.c (in CHECK_SMALL_INT)



STINNER Victor  added the comment:

Raymond:
> We're wasted a lot of dev time on something that never promised much value in 
> the first place.

I'm one of the first to advocate to replace ugly macros with clean static 
inline functions. Macros are evil and can be too easily misused.

On PR 15216, Benjamin and Raymond advised to replace the macro with a function.

I'm also a believer that one day, we could replace duplicated C functions 
accepting variant of C "integers" types with a single larger type:

* signed: replace (char, short, int, long, long long, ssize_t) with intmax_t
* unsigned: replace (unsigned char, unsigned short, unsigned int, unsigned 
long, unsigned long long, size_t) with uintmax_t

Sadly, it seems like such change has a small performance loss, and so cannot be 
done in "performance critical" code. I consider that longobject.c is such 
performance critical code.

--

I converted some macros of the Python C API to static inline functions, like 
Py_INCREF() or _PyObject_GC_TRACK():
https://vstinner.github.io/split-include-directory-python38.html

Compared to macros, static inline functions have multiple advantages:

* Parameter types and return type are well defined;
* They don't have issues specific to macros: see GCC Macro Pitfals 
https://gcc.gnu.org/onlinedocs/cpp/Macro-Pitfalls.html ;
* Variables have a well defined local scope ;
* GDB is able to retrieve then name when read the current C stack ("backtrace").

--

Again, I advice to add a small comment in longobject.c macros to explain that 
converting them to functions would loose performances.

--

___
Python tracker 

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

[issue38205] Python no longer compiles without small integer singletons



STINNER Victor  added the comment:

> Before the mentioned commit Py_UNREACHABLE() was an expression, now it's a 
> block. 

Right, it was changed by:

commit 3ab61473ba7f3dca32d779ec2766a4faa0657923
Author: Zachary Ware 
Date:   Thu Sep 12 13:35:48 2019 +0100

Enhance Py_UNREACHABLE macro (GH-16032)


I add Zachary Ware in the nosy list.

--
nosy: +zach.ware

___
Python tracker 

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

[issue35866] concurrent.futures deadlock

2019-09-18 Thread bentoi



bentoi  added the comment:

FYI, I'm getting a similar deadlock in a child Python process which is stuck on 
locking a mutex from the dl library. See attached stack. 

I'm not using concurrent.futures however, the parent Python process is a test 
driver that uses threading.Thread and subprocess.Popen to spawn new 
processes... I'm not using os.fork().

This occurred on ArchLinux with Python 3.7.4.

--
nosy: +bentoi
Added file: https://bugs.python.org/file48611/stack-python.txt

___
Python tracker 

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

[issue27575] dict viewkeys intersection slow for large dicts



Serhiy Storchaka  added the comment:

This changed behavior. See issue38210.

See also issue38202 for other regression.

--
status: closed -> open

___
Python tracker 

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

[issue27575] dict viewkeys intersection slow for large dicts



Change by Serhiy Storchaka :


--
status: open -> closed

___
Python tracker 

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

[issue27575] dict viewkeys intersection slow for large dicts



Change by Serhiy Storchaka :


--
versions: +Python 3.9 -Python 3.6

___
Python tracker 

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

[issue38210] Intersection of dict view with iterator returns empty set



New submission from Serhiy Storchaka :

In 3.8:

>>> {1: 2, 3: 4}.keys() & {1, 2}
{1}

In master:

>>> {1: 2, 3: 4}.keys() & iter([1, 2])
set()

The behavior was changed in issue27575.

--
components: Interpreter Core
messages: 352705
nosy: rhettinger, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Intersection of dict view with iterator returns empty set
type: behavior
versions: Python 3.9

___
Python tracker 

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

[issue27575] dict viewkeys intersection slow for large dicts



Serhiy Storchaka  added the comment:

I am puzzled why we still call set.intersection_update with empty set?

--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue38205] Python no longer compiles without small integer singletons

2019-09-18 Thread Sergey Fedoseev



Sergey Fedoseev  added the comment:

Also quote from Py_UNREACHABLE() doc:

>  Use this in places where you might be tempted to put an assert(0) or abort() 
> call.

https://github.com/python/cpython/commit/6b519985d23bd0f0bd072b5d5d5f2c60a81a19f2
 does exactly that, it replaces assert(0) with Py_UNREACHABLE().

--

___
Python tracker 

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

[issue38208] Simplify string.Template by using __init_subclass__()



Change by Serhiy Storchaka :


--
keywords: +patch
pull_requests: +15851
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/16256

___
Python tracker 

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

[issue38209] Simplify dataclasses.InitVar by using __class_getitem__()



Change by Serhiy Storchaka :


--
keywords: +patch
pull_requests: +15850
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/16255

___
Python tracker 

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

[issue38209] Simplify dataclasses.InitVar by using __class_getitem__()



New submission from Serhiy Storchaka :

Currently dataclasses.InitVar uses a metaclass. It is possible to get rid of it 
and use __class_getitem__() instead.

--
components: Library (Lib)
messages: 352702
nosy: eric.smith, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Simplify dataclasses.InitVar by using __class_getitem__()
versions: Python 3.9

___
Python tracker 

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

[issue38203] regrtest fails to stop test_multiprocessing_spawn worker process