[issue31465] Allow _PyType_Lookup() to raise exceptions

[Stefan Behnel]

Stefan Behnel added the comment:

Any comments on this?

--

___
Python tracker 

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

[issue31584] Documentation Language mixed up

[Mariatta Wijaya]

Mariatta Wijaya added the comment:

Indeed a problem! Seems to affect Python 2.7 docs. If not mistaken, Julien 
worked on the language switcher. Maybe he has some clue ...

--
nosy: +Mariatta, mdk
priority: normal -> high
stage:  -> needs patch

___
Python tracker 

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

[issue31579] Reference leak in enumerate

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
pull_requests: +3747

___
Python tracker 

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

[issue31579] Reference leak in enumerate

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
pull_requests: +3746

___
Python tracker 

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

[issue31585] Refactor the enumerate.__next__ implementation

[Raymond Hettinger]

Raymond Hettinger added the comment:

Having separate code paths was an intentional decision.  I prefer to keep it 
that way.

--
resolution:  -> rejected
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

[issue31585] Refactor the enumerate.__next__ implementation

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
keywords: +patch
pull_requests: +3745
stage:  -> patch review

___
Python tracker 

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

[issue31585] Refactor the enumerate.__next__ implementation

[Serhiy Storchaka]

New submission from Serhiy Storchaka:

Currently the large and complex part of enum_next() and enum_next_long() in 
Objects/enumobject.c is duplicated. This increases the code size and makes 
harder maintaining the code. The proposed patch refactors the implementation 
and removes the code duplication.

--
components: Interpreter Core
messages: 303006
nosy: rhettinger, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Refactor the enumerate.__next__ implementation
type: enhancement
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

[issue31579] Reference leak in enumerate

[Serhiy Storchaka]

Serhiy Storchaka added the comment:


New changeset 0e950dd22b075b4809c84afda8aede02b76ac0fa by Serhiy Storchaka in 
branch 'master':
bpo-31579: Fixed a possible leak in enumerate() with large indices. (#3753)
https://github.com/python/cpython/commit/0e950dd22b075b4809c84afda8aede02b76ac0fa


--

___
Python tracker 

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

[issue31584] Documentation Language mixed up

[asl]

New submission from asl:

Some of the documentation language are mixed up.

eg:
Japanese on the English page https://docs.python.org/2.7/faq/design.html
French on the Japanese https://docs.python.org/ja/2.7/faq/design.html

It seem to affect multiple pages:
https://docs.python.org/2.7/bugs.html
https://docs.python.org/2.7/distributing/index.html
https://docs.python.org/2.7/extending/index.html
https://docs.python.org/2.7/extending/extending.html
The c-api pages https://docs.python.org/2.7/c-api/index.html
The faq pages https://docs.python.org/2.7/faq/index.html

And possibly others.

--
assignee: docs@python
components: Documentation
messages: 303004
nosy: asl, docs@python
priority: normal
severity: normal
status: open
title: Documentation Language mixed up
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

[issue31580] Defer compiling regular expressions

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

lru_cache() is not used for reasons. The patch makes using cached patterns 
slower by adding an overhead of 4 additional checks. It makes resolving 
attributes of a deferred patterns slower. All this slows down a straight call 
to re.search(pattern, s).

Errors in regular expression now raised only on first use of the pattern. This 
is a drawback from educational and debugging points of view.

The patch also breaks warnings emitted during compiling regular expressions. 
Now they report wrong source line and use wrong line for caching in case of 
-Wonce.

--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue31581] Reduce the number of imports for functools

[Raymond Hettinger]

Raymond Hettinger added the comment:

Go ahead.

--

___
Python tracker 

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

[issue31583] 2to3 call for file in current directory yields error

[Denis Osipov]

Changes by Denis Osipov :


--
keywords: +patch
pull_requests: +3744
stage:  -> patch review

___
Python tracker 

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

[issue31583] 2to3 call for file in current directory yields error

[Denis Osipov]

New submission from Denis Osipov:

2to3 doesn't work if called for file in current directory with --add-suffix 
option.

$ /d/repos/cpython/python.bat /d/repos/cpython/Tools/scripts/2to3 -n -W 
--add-suffix=3 test2to3.py
Running Debug|x64 interpreter...
WARNING: --write-unchanged-files/-W implies -w.
RefactoringTool: Skipping optional fixer: buffer
RefactoringTool: Skipping optional fixer: idioms
RefactoringTool: Skipping optional fixer: set_literal
RefactoringTool: Skipping optional fixer: ws_comma
RefactoringTool: Refactored test2to3.py
--- test2to3.py (original)
+++ test2to3.py (refactored)

--some changes--

Traceback (most recent call last):
  File "D:/repos/cpython/Tools/scripts/2to3", line 5, in 
sys.exit(main("lib2to3.fixes"))
  File "D:\repos\cpython\lib\lib2to3\main.py", line 259, in main
options.processes)
  File "D:\repos\cpython\lib\lib2to3\refactor.py", line 687, in refactor
items, write, doctests_only)
  File "D:\repos\cpython\lib\lib2to3\refactor.py", line 282, in refactor
self.refactor_file(dir_or_file, write, doctests_only)
  File "D:\repos\cpython\lib\lib2to3\refactor.py", line 728, in refactor_file
*args, **kwargs)
  File "D:\repos\cpython\lib\lib2to3\refactor.py", line 339, in refactor_file
write=write, encoding=encoding)
  File "D:\repos\cpython\lib\lib2to3\refactor.py", line 505, in processed_file
self.write_file(new_text, filename, old_text, encoding)
  File "D:\repos\cpython\lib\lib2to3\main.py", line 84, in write_file
os.makedirs(output_dir)
  File "D:\repos\cpython\\lib\os.py", line 221, in makedirs
mkdir(name, mode)
FileNotFoundError: [WinError 3] The system cannot find the path specified: ''


It works well if I use absolute path for target file or set -o:

$ /d/repos/cpython/python.bat /d/repos/cpython/Tools/scripts/2to3 -n -W 
--add-suffix=3 /d/MyPythonScripts/test2to3.py

$ /d/repos/cpython/python.bat /d/repos/cpython/Tools/scripts/2to3 -n -W 
--add-suffix=3 -o . test2to3.py

--
components: 2to3 (2.x to 3.x conversion tool)
messages: 303001
nosy: denis-osipov
priority: normal
severity: normal
status: open
title: 2to3 call for file in current directory yields error
type: behavior
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

[issue31582] Add _pth breadcrumb to sys.path documentation

[Traveler Hauptman]

New submission from Traveler Hauptman:

Python on windows (winpython) was not adding PYTHONPATH to sys.path as 
documented and I could not understand why.

It took a lot of time, web searches, and finally a tour through the code to 
find out about _pth; which is well documented but difficult to find out about 
if you don't know about it beforehand.

Please improve the sys.path documentation to say that it depends on either 
PYTHONPATH or the *._pth file. Better yet, link to the actual sys.path 
heuristics.

--
assignee: docs@python
components: Documentation
messages: 303000
nosy: Traveler Hauptman, docs@python
priority: normal
severity: normal
status: open
title: Add _pth breadcrumb to sys.path documentation
type: enhancement

___
Python tracker 

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

[issue31581] Reduce the number of imports for functools

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Initially my patch for issue30152 included the change in collections. But it 
was removed on Raymond's request.

--
nosy: +rhettinger, serhiy.storchaka

___
Python tracker 

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

[issue31581] Reduce the number of imports for functools

[INADA Naoki]

Changes by INADA Naoki :


--
keywords: +patch
pull_requests: +3743
stage:  -> patch review

___
Python tracker 

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

[issue31581] Reduce the number of imports for functools

[INADA Naoki]

New submission from INADA Naoki:

Makes `import functools` about 1.5 ms faster.

* heapq is used only when Counter.most_common(n).
* types and waakref is used only for singledispatch.

master:

import time:   - _functools 76 us (self 76 us)
import time:   - _operator 110 us (self 110 us)
import time: - operator 469 us (self 359 us)
import time: - keyword 174 us (self 174 us)
import time:   - _heapq 189 us (self 189 us)
import time: - heapq 400 us (self 211 us)
import time: - itertools 137 us (self 137 us)
import time: - reprlib 231 us (self 231 us)
import time: - _collections 142 us (self 142 us)
import time:   - collections 3006 us (self 1456 us)
import time: - collections.abc 191 us (self 191 us)
import time:   - types 518 us (self 327 us)
import time:   - weakref 577 us (self 577 us)
import time: - functools 4903 us (self 729 us)

patched:

import time:   - _functools 74 us (self 74 us)
import time:   - _operator 100 us (self 100 us)
import time: - operator 460 us (self 361 us)
import time: - keyword 174 us (self 174 us)
import time: - itertools 139 us (self 139 us)
import time: - reprlib 226 us (self 226 us)
import time: - _collections 85 us (self 85 us)
import time:   - collections 2593 us (self 1512 us)
import time: - functools 3369 us (self 703 us)

--
components: Library (Lib)
messages: 302998
nosy: inada.naoki
priority: normal
severity: normal
status: open
title: Reduce the number of imports for functools
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

[issue31580] Defer compiling regular expressions

[R. David Murray]

R. David Murray added the comment:

I agree with Raymond.  It would be strange to have the API that is obviously 
designed to pre-compile the regex not pre-compile the regex.

If the concern is that a non-precompiled regex might get bumped out of the 
cache but you want a way to only compile a "bunch of stuff" on demand, then the 
thing to do would be to make a proposal for a new API that does that, and we'll 
discuss the merits :)

It seems to me that contexts that care about startup time can use the deferred 
compile API, whether the new (it it is accepted) or existing one.  If an 
application cares about startup time and is using re.compile at startup, then 
that is an application performance bug.

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

[issue31580] Defer compiling regular expressions

[Raymond Hettinger]

Raymond Hettinger added the comment:

ISTM, the whole point is to compile in advance.  When I worked during high 
frequency trading, that was essential to news trading where you *really* didn't 
want to pay the compilation cost at the time the regex was used.  This proposal 
takes away the user's only control over when the regex is compiled. 

FWIW, if a user doesn't explicitly invoke re.compile() and instead uses a 
straight call to re.search(pattern, s), then the pattern is compiled on 
first-use and cached for future use.  In other words, we already have a simple 
and clear way to auto-compile on first use.  I recommend against taking away 
the only option to specify otherwise.

--
nosy: +rhettinger

___
Python tracker 

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

[issue31580] Defer compiling regular expressions

[Barry A. Warsaw]

Changes by Barry A. Warsaw :


--
keywords: +patch
pull_requests: +3742
stage:  -> patch review

___
Python tracker 

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

[issue31580] Defer compiling regular expressions

[Barry A. Warsaw]

New submission from Barry A. Warsaw:

It's a very common pattern to see the following at module scope:

cre_a = re.compile('some pattern')
cre_b = re.compile('other pattern')

and so on.  This can cost you at start up time because all those regular 
expressions are compiled at import time, even if they're never used in practice 
(e.g. because say whatever condition tickles the compiled regex never gets 
exercised).

It occurred to me that if re.compile() deferred compilation of the regexp until 
first use, you could speed up start up time.  But by how much?  And at what 
cost?

So I ran a small experiment (pull request to be submitted) using the `perf` 
module on `pip --help`.  I was able to cut down the number of compiles from 28 
to 9, and a mean startup time from 245ms to 213ms.

% python -m perf compare_to ../base.json ../defer.json 
Mean +- std dev: [base] 245 ms +- 19 ms -> [defer] 213 ms +- 21 ms: 1.15x 
faster (-13%)

`pip install tox` reduces the compiles from 231 to 75:

(cpython 3.7) 231 0.06945133209228516
(3.7 w/defer)  75 0.03140091896057129

So what's the cost?  Backward compatibility.  `re.compile()` doesn't return a 
compiled regular expression object now, but instead a "deferred" proxy.  When 
the proxy is used, then it does the actual compilation.  This can break 
compatibility by deferring any exceptions that compile() might raise.  This 
happens a fair bit in the test suite, but I'm not sure it's all that common in 
practice.  In any case, I've also added a re.IMMEDIATE (re.N -- for "now") flag 
to force immediate compilation.

I also modified the compilation to use an actual functools.lru_cache.  This 
way, if maxcache gets triggered, the entire cache won't get blown away.

So, whether this is a good idea or not, I open this and push the branch for 
further discussion.

--
assignee: barry
components: Library (Lib)
messages: 302995
nosy: barry
priority: normal
severity: normal
status: open
title: Defer compiling regular expressions
type: performance
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

[issue18257] Two copies of python-config

[R. David Murray]

R. David Murray added the comment:

Since it hasn't been an issue for a few releases, I say we close it.  If there 
is some problem remaining, it probably deserves its own tracker issue anyway.

--
nosy: +r.david.murray
resolution:  -> fixed
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

[issue14799] Tkinter ttk tests hang on linux

[Terry J. Reedy]

Terry J. Reedy added the comment:

A year or so ago, I asked people on python-list who could to run the gui tests 
on their linux boxes and report.  About 6 did and with one possible exception, 
and not that reported here, everyone reported success.  So, unless someone can 
report otherwise, I think this should be closed.

I think we should regularly ask the community to help with gui tests.

--

___
Python tracker 

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

[issue31415] Add -X option to show import time

[INADA Naoki]

INADA Naoki added the comment:

how can I make it more machine readable?

On 2017年9月25日(月) 19:39 Christian Heimes  wrote:

>
> Christian Heimes added the comment:
>
> +1 for an option to profile import time.
>
> I have a minor complain: The output format is not machine-friendly, which
> makes it harder to perform automatic analysis. I created #31574 / PR3749 to
> add dtrace probes.
>
> --
> nosy: +christian.heimes
>
> ___
> Python tracker 
> 
> ___
>
-- 
Inada Naoki 

--

___
Python tracker 

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

[issue31571] Redundand information on Doc/reference/lexical_analysis.rst

[Mariatta Wijaya]

Mariatta Wijaya added the comment:

The proposed change seems fine. Merged and backported.
Thanks everyone!

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

[issue31571] Redundand information on Doc/reference/lexical_analysis.rst

[Mariatta Wijaya]

Mariatta Wijaya added the comment:


New changeset 26b940f762f0b306ff894601003f51a8d036e285 by Mariatta (Miss 
Islington (bot)) in branch '3.6':
bpo-31571: Remove duplicated info in Lexical Analysis documentation (GH-3691) 
(GH-3754)
https://github.com/python/cpython/commit/26b940f762f0b306ff894601003f51a8d036e285


--

___
Python tracker 

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

[issue31571] Redundand information on Doc/reference/lexical_analysis.rst

[Roundup Robot]

Changes by Roundup Robot :


--
keywords: +patch
pull_requests: +3741

___
Python tracker 

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

[issue31571] Redundand information on Doc/reference/lexical_analysis.rst

[Mariatta Wijaya]

Mariatta Wijaya added the comment:


New changeset 4a2d00cb4525fcb3209f04531472ba6a359ed418 by Mariatta (Guilherme 
Caminha) in branch 'master':
bpo-31571: Remove duplicated info in Lexical Analysis documentation (GH-3691)
https://github.com/python/cpython/commit/4a2d00cb4525fcb3209f04531472ba6a359ed418


--

___
Python tracker 

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

[issue14799] Tkinter ttk tests hang on linux

[Łukasz Langa]

Łukasz Langa added the comment:

Unsetting priority.

--
nosy: +lukasz.langa
priority: critical -> 

___
Python tracker 

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

[issue27163] IDLE entry for What's New in Python 3.6

[Łukasz Langa]

Łukasz Langa added the comment:

Unsetting priority since it's not Critical and RMs look at open Critical bugs 
when releasing 3.6.3 and so on.

--
nosy: +lukasz.langa
priority: critical -> 

___
Python tracker 

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

[issue29406] asyncio SSL contexts leak sockets after calling close with certain Apache servers

[Łukasz Langa]

Changes by Łukasz Langa :


--
assignee:  -> yselivanov

___
Python tracker 

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

[issue29624] Python 3.5.3 x86 web installer cannot install launcher

[Łukasz Langa]

Łukasz Langa added the comment:

This is marked as "critical". Looks like it's fixed. Can we close it?

--
nosy: +lukasz.langa

___
Python tracker 

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

[issue29406] asyncio SSL contexts leak sockets after calling close with certain Apache servers

[Łukasz Langa]

Łukasz Langa added the comment:

This is marked as Critical so either we should change the priority or fix it 
soon :)

--
nosy: +lukasz.langa

___
Python tracker 

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

[issue14499] Extension module builds fail with Xcode 4.3 on OS X 10.7 due to SDK move

[Łukasz Langa]

Łukasz Langa added the comment:

Not critical anymore. Probably safe to close?

--
nosy: +lukasz.langa
priority: critical -> 

___
Python tracker 

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

[issue18257] Two copies of python-config

[Łukasz Langa]

Łukasz Langa added the comment:

Downgrading the priority, it's not a deferred blocker for sure. I think we 
could probably just close it?

--
nosy: +lukasz.langa
priority: deferred blocker -> 

___
Python tracker 

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

[issue30755] locale.normalize() and getdefaultlocale() convert C.UTF-8 to en_US.UTF-8

[Matthew Woodcraft]

Matthew Woodcraft added the comment:

(For PEP 537 please read PEP 538, sorry)

--

___
Python tracker 

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

[issue30755] locale.normalize() and getdefaultlocale() convert C.UTF-8 to en_US.UTF-8

[Matthew Woodcraft]

Matthew Woodcraft added the comment:

I've investigated a bit more.

First, I've tried with Python 3.7.0a1 . As you'd expect, PEP 537 means
this behaviour now also occurs when no locale environment variables at
all are set.


Second, I've looked through locale.py a bit. I believe what it calls the
"aliasing engine" is applied for:

 - getlocale()
 - getdefaultlocale()
 - setlocale() when passed a tuple, but not when passed a string


This leads to some rather odd results.

With 3.7.0a1 and no locale environment variables:

  >>> import locale
  >>> locale.getlocale()
  ('en_US', 'UTF-8')

  # getlocale() is lying: the effective locale is really C.UTF-8
  >>> sorted("abcABC", key=locale.strxfrm)
  ['A', 'B', 'C', 'a', 'b', 'c']


Third, I've checked on a system which does have en_US.UTF-8 installed,
and (as you'd expect) instead of crashing it gives wrong results:

  >>> import locale
  >>> locale.setlocale(locale.LC_ALL, ('C', 'UTF-8'))
  'en_US.UTF-8'
  >>> locale.getlocale()
  ('en_US', 'UTF-8')

  # now getlocale() is telling the truth, and the user isn't getting the
  # collation they requested
  >>> sorted("abcABC", key=locale.strxfrm)
  ['a', 'A', 'b', 'B', 'c', 'C']

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

[issue30152] Reduce the number of imports for argparse

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Thanks all!

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

[issue30152] Reduce the number of imports for argparse

[Serhiy Storchaka]

Serhiy Storchaka added the comment:


New changeset 81108375d9b2ccd0add1572da745311d4dfac505 by Serhiy Storchaka in 
branch 'master':
bpo-30152: Reduce the number of imports for argparse. (#1269)
https://github.com/python/cpython/commit/81108375d9b2ccd0add1572da745311d4dfac505


--

___
Python tracker 

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

[issue31579] Reference leak in enumerate

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
keywords: +patch
pull_requests: +3740

___
Python tracker 

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

[issue31579] Reference leak in enumerate

[Serhiy Storchaka]

New submission from Serhiy Storchaka:

There is a possible leak of the value emitted by an underlying iterator in 
enumerate.__next__.

Proposed PR fixes it.

--
assignee: rhettinger
components: Interpreter Core
messages: 302978
nosy: rhettinger, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Reference leak in enumerate
type: resource usage
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

[issue31571] Redundand information on Doc/reference/lexical_analysis.rst

[Mariatta Wijaya]

Changes by Mariatta Wijaya :


--
stage:  -> patch review
versions: +Python 3.6

___
Python tracker 

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

[issue31530] Python 2.7 readahead feature of file objects is not thread safe

[STINNER Victor]

STINNER Victor added the comment:

> Iteration on Python 2 files is fragile, now is not the time to fix 
> fundamental bugs in Python 2.

Right. I don't have a strong preference for Serhiy's PR 3672.

--

___
Python tracker 

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

[issue31577] crash in os.utime() in case of a bad ns argument

[Oren Milman]

Changes by Oren Milman :


--
keywords: +patch
pull_requests: +3739
stage:  -> patch review

___
Python tracker 

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

[issue31577] crash in os.utime() in case of a bad ns argument

[Oren Milman]

Oren Milman added the comment:

I opened a PR.
I think another fix might be to use
PyLong_Type.tp_as_number->long_divmod() instead of PyNumber_Divmod().

--

___
Python tracker 

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

[issue31170] Update to expat 2.2.4 (expat: utf8_toUtf8 cannot properly handle exhausting buffer)

[STINNER Victor]

STINNER Victor added the comment:

Oh, it seems like Steve Dower found an issue on Windows: PR 3751.

I reopen the issue.

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

___
Python tracker 

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

[issue31571] Redundand information on Doc/reference/lexical_analysis.rst

[Guilherme Praciano Karst Caminha]

Guilherme Praciano Karst Caminha added the comment:

In that case, I believe the PR I've opened should be fine?

--

___
Python tracker 

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

[issue31530] Python 2.7 readahead feature of file objects is not thread safe

[Guido van Rossum]

Guido van Rossum added the comment:

It should be like 'if key in dct: del dct[key]'. It may fail when two
threads do this but the *internal* state of dct should not be compromised.

On Sep 25, 2017 2:45 AM, "Antoine Pitrou"  wrote:

>
> Antoine Pitrou added the comment:
>
> Le 25/09/2017 à 11:39, STINNER Victor a écrit :
> >
> > Antoine: "I'm wary of raising an exception.  Assuming Benjamin's patch
> is correct, I vote for it."
> >
> > Can you please elaborate? You are fine with the fact that iter(file) in
> two thread can return the same line?
>
> AFAIU it already could.  Iteration on Python 2 files is fragile, now is
> not the time to fix fundamental bugs in Python 2.
>
> --
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

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

[issue31558] gc.freeze() - an API to mark objects as uncollectable

[Antoine Pitrou]

Antoine Pitrou added the comment:

Le 25/09/2017 à 20:55, Neil Schemenauer a écrit :
> 
> I think the basic idea makes a lot of sense, i.e. have a generation that is 
> never collected.  An alternative way to implement it would be to have an 
> extra generation, e.g. rather than just 0, 1, 2 also have generation 3.  The 
> collection would by default never collect generation 3.  Generation 4 would 
> be equivalent to the frozen generation.  You could still force collection by 
> calling gc.collect(3).

API-wise it would sound better to have a separate gc.collect_frozen()...

Though I think a gc.unfreeze() that moves the frozen generation into the
oldest non-frozen generation would be useful too, at least for testing
and experimentation.

> I think issue 3110 (https://bugs.python.org/issue31105) is also related.  The 
> current GC thresholds are not very good.  I've look at what Go does and the 
> GC collection is based on a relative increase in memory usage.  Python could 
> do perhaps something similar.  The accounting of actual bytes allocated and 
> deallocated is tricky because the *_Del/Free functions don't actually know 
> how much memory is being freed, at least not in a simple way.

Yeah... It's worse than that.  Take for example a bytearray object.  The
basic object (the PyByteArrayObject structure) is quite small.  But it
also has a separately-allocated payload that is deleted whenever
tp_dealloc is called.  The GC isn't aware of that payload.  Worse, the
payload can (and will) change size during the object's lifetime, without
the GC's knowledge about it ever being updated. (*)

IMHO, the only reliable way to use memory footprint to drive the GC
heuristic would be to force all allocations into our own allocator, and
reconcile the GC with that allocator (instead of having the GC be its
own separate thing as is the case nowadays).

(*) And let's not talk about hairier cases, such as having multiple
memoryviews over the same very large object...

PS: every heuristic has its flaws.  As I noted on python-(dev|ideas),
full GC runtimes such as most Java implementations are well-known for
requiring careful tuning of GC parameters for "non-usual" workloads.  At
least reference counting makes CPython more robust in many cases.

--

___
Python tracker 

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

[issue20827] IDLE : Display function argument list in ClassBrowser

[Terry J. Reedy]

Terry J. Reedy added the comment:

Having fixed the nested functions and classes issue, and thought some more, I 
have two other concerns with adding signatures in the browser, and a different 
solution.

1. Time: When requested, the browser window comes up immediately with the 
module node.  There is a noticeable delay before the top level items are 
displayed, and it is longer than before.  Since pyclbr was already patched to 
deliver the information on nested items, this puzzles me, and I want to 
investigate the cause before possible slowing display even longer.

2. Space: For browser tree items, base 'Tree' is expanded to 
'idlelib.tree.Tree'.  With one base, this will usually not an issue.  With 
multiple bases, it could be, in the sense of making the single line too long.  
Signatures, like calls, can well be too long for a single line.

Alternatives:

1. Module Browser opens the file.  Single clicking a line in the browser moves 
the selection highlight in the browser.  Double clicking a line expands or 
contract the node if it is expandedable, and it highlights the corresponding 
line in the editor. So the new feature is not *necessary* for a user to get the 
information.

But we can make it easier.  First, move the editor highlight when moving the 
browser hightlight.  Second, move both highlights with the Up and Down keys 
(instead of just scrolling.  Expand/contract with Right and Left keys.  Third, 
with a bit more work, the entire header could be highlighted.  Fourth, position 
browser box and editor side-by-side with tops aligned, instead of overlapping.  
(Note: the positioning would be automatic if IDLE had side-by-side tabbed 
panes.)

2. Signatures might be displayed in a pop-up box.  But I like 1. above better.

So I am inclined to reject adding to the Python-code browser in favor of 
improving the coordination between browser and editor.

If we ever add the ability to browse imported modules by introspection, then 
making signatures, *and* docstrings, would be needed -- and easy.  (This would 
be be aimed at, but not limited to, non-Python coded modules.)

--

___
Python tracker 

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

[issue31571] Redundand information on Doc/reference/lexical_analysis.rst

[Guido van Rossum]

Guido van Rossum added the comment:

That's *really* old. Please clean up as you see fit!

On Sep 24, 2017 10:33 PM, "Serhiy Storchaka"  wrote:

Serhiy Storchaka added the comment:

Guido, in 60f2f0cf8e10c94693dfea8937b7feabeffe5744 you added the phrase
"Note that numeric literals do not include a sign; ..." in the "Numeric
literals" section. Did you mean moving it from the "Floating point
literals" section or creating a duplicate?

--

___
Python tracker 

___

--

___
Python tracker 

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

[issue31558] gc.freeze() - an API to mark objects as uncollectable

[Barry A. Warsaw]

Barry A. Warsaw added the comment:

I like the idea of a gen 4 that never gets collected.  This would have been 
useful for the original problem that inspired me to add the `generation` 
argument to `gc.collect()`.  The nice thing about this, is just as you suggest: 
you could force a collection of gen 4 by `gc.collect(3)`.

It's unfortunate that you'd have to add a bit to handle this, but maybe you're 
right that we only really need three generations.

--

___
Python tracker 

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

[issue31578] Unexpected Floating Point Division Result

[R. David Murray]

R. David Murray added the comment:

In the absence of the appropriate __future__ import, the python2 division 
operator uses integer division.

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

[issue31558] gc.freeze() - an API to mark objects as uncollectable

[Neil Schemenauer]

Neil Schemenauer added the comment:

I think the basic idea makes a lot of sense, i.e. have a generation that is 
never collected.  An alternative way to implement it would be to have an extra 
generation, e.g. rather than just 0, 1, 2 also have generation 3.  The 
collection would by default never collect generation 3.  Generation 4 would be 
equivalent to the frozen generation.  You could still force collection by 
calling gc.collect(3).  Whether that generation should be collected on shutdown 
would still be a question.

If this gets implemented, it will impact the memory bitmap based GC idea I have 
been prototyping.  Currently I am thinking of using two bits for each small GC 
object.  The bits would mean: 00 - untracked, 01 - gen 0, 10 - gen 1, 11 - gen 
2.  With the introduction of a frozen generation, I would have to use another 
bit I think.

Another thought is maybe we don't actually need 3 generations as they are 
currently used.  We could have gen 0 which is collected frequently and gen 1 
that is collected rarely.  The frozen objects could go into gen 2 which are not 
automatically collected or have a user adjustable collection frequency.  
Collection of gen 1 would not automatically move objects into gen 2.

I think issue 3110 (https://bugs.python.org/issue31105) is also related.  The 
current GC thresholds are not very good.  I've look at what Go does and the GC 
collection is based on a relative increase in memory usage.  Python could do 
perhaps something similar.  The accounting of actual bytes allocated and 
deallocated is tricky because the *_Del/Free functions don't actually know how 
much memory is being freed, at least not in a simple way.

--

___
Python tracker 

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

[issue31578] Unexpected Floating Point Division Result

[hw]

New submission from hw:

To reproduce:
>>> 480/1000/13.0
Actual result: 0.0

Expected result: 0.03692307692307692
Adding the zero decimal to any other combinations of the numbers produces the 
expected floating point result.

Working as expected in Python 3

--
components: Interpreter Core
messages: 302966
nosy: Hw
priority: normal
severity: normal
status: open
title: Unexpected Floating Point Division Result
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

[issue31569] inconsistent case of PCbuild/ directory

[Steve Dower]

Changes by Steve Dower :


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

[issue31574] Add dtrace hook for importlib

[Barry A. Warsaw]

Changes by Barry A. Warsaw :


--
nosy: +barry

___
Python tracker 

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

[issue22140] "python-config --includes" returns a wrong path (double prefix)

[Michał Górny]

Changes by Michał Górny :


--
nosy: +mgorny

___
Python tracker 

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

[issue31423] Error while building PDF documentation

[Mariatta Wijaya]

Mariatta Wijaya added the comment:

Sorry!! Yesterday morning I received 50+ emails all about document download 
page is 404. Reading those again, turns out these are older emails from a week 
before, somehow just showing up in my mailbox.
I think everything is good here. :)

Thanks!

--

___
Python tracker 

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

[issue31574] Add dtrace hook for importlib

[Ned Deily]

Changes by Ned Deily :


--
nosy: +lukasz.langa

___
Python tracker 

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

[issue31475] Bug in argparse - not supporting utf8

[Josh Rosenberg]

Josh Rosenberg added the comment:

Based on the OP's patch, it looks like they have a problem where they have 
non-ASCII text in their output strings (either due to using non-ASCII switches, 
or using non-ASCII help documentation), but sys.stdout/sys.stderr are 
configured for some encoding that doesn't support said characters, so they're 
getting exceptions when the help message is sent to the screen automatically 
(e.g. by running with --help).

It's only sort of a bug in Python: Fundamentally, the problem is a script that 
assumes arbitrary Unicode support being run under a locale that doesn't provide 
it. The solution provided is bad though: It shouldn't be trying to force UTF8 
output regardless of locale.

A simple repro, at least on Linux-like systems, would be to run Python with 
LANG=C (and no other LC variables set), then do:

import argparse
parser = argparse.ArgumentParser()
parser.add_argument('-f', help=chr(233)) # help is 'é'
parser.print_help()

While the patch as given is wrong (with the exception of Windows weirdness, 
blithely ignoring/second-guessing the locale is a terrible idea), it's not a 
terrible idea to fix this in some way; if nothing else, it might make sense to 
have some fallback approach when the exception is raised (e.g. encoding the 
output with errors='ignore' or the like) so running scriptname.py --help at 
least provides *some* output even with incompatible locales, rather than dying 
with an error in the help message handling code itself.

--
nosy: +josh.r
status: pending -> open

___
Python tracker 

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

[issue31569] inconsistent case of PCbuild/ directory

[Paul Moore]

Paul Moore added the comment:


New changeset f1502d097c29b266a5748312ee2451a2d6ac0af6 by Paul Moore (Stefan 
Grönke) in branch 'master':
bpo-31569: correct PCBuild/ case to PCbuild/ in build scripts and docs (GH-3711)
https://github.com/python/cpython/commit/f1502d097c29b266a5748312ee2451a2d6ac0af6


--

___
Python tracker 

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

[issue31577] crash in os.utime() in case of a bad ns argument

[Oren Milman]

New submission from Oren Milman:

The following code causes the interpreter to crash:
class BadInt:
def __divmod__(*args):
return 42

import os
os.utime('foo.txt', ns=(BadInt(), 1))


This is because split_py_long_to_s_and_ns() (in Modules/posixmodule.c) assumes
that PyNumber_Divmod() returns a 2-tuple, and passes it to PyTuple_GET_ITEM(),
which assumes it is a tuple. Thus, PyTuple_GET_ITEM() might return a non-NULL
value which is not an address of a Python object.

--
components: Extension Modules
messages: 302962
nosy: Oren Milman
priority: normal
severity: normal
status: open
title: crash in os.utime() in case of a bad ns argument
type: crash
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

[issue31569] inconsistent case of PCbuild/ directory

[Paul Moore]

Paul Moore added the comment:

OK, having re-read the PR, I'm fine with applying it as is, too.

--

___
Python tracker 

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

[issue31170] Update to expat 2.2.4 (expat: utf8_toUtf8 cannot properly handle exhausting buffer)

[Steve Dower]

Changes by Steve Dower :


--
pull_requests: +3738

___
Python tracker 

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

[issue31569] inconsistent case of PCbuild/ directory

[Zachary Ware]

Zachary Ware added the comment:

Personally, *I'd* prefer PC -> Windows and PCbuild -> Windows\build :)

I'm also good with the PR as is.

--

___
Python tracker 

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

[issue31569] inconsistent case of PCbuild/ directory

[Steve Dower]

Steve Dower added the comment:

I'm okay with the PR as it stands, especially the parts that affect GitHub and 
appveyor, as those are almost certainly using case sensitive comparisons.

It's definitely not easier to update the case of a file that is in git, and 
doing so will very likely break users (we had to do a case-folding pass over 
the Mercurial repository because while it could handle case changes, git could 
not import the ones we had in history).

Personally I'd prefer it to have always been PCBuild rather than PCbuild, and 
it's very likely that I've introduced most of the 'incorrect' ones. But what's 
done is done and we should avoid the potential distraction of mismatched case 
throughout the rest of our codebase.

--

___
Python tracker 

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

[issue16322] time.tzname on Python 3.3.0 for Windows is decoded by wrong encoding

[Mark Lawrence]

Changes by Mark Lawrence :


--
nosy:  -BreamoreBoy

___
Python tracker 

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

[issue31145] PriorityQueue.put() fails with TypeError if priority_number in tuples of (priority_number, data) are the same.

[R. David Murray]

Changes by R. David Murray :


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

[issue31573] PyStructSequence_New() doesn't validate its input type (crashes in os.wait3() and os.wait4() in case of a bad resource.struct_rusage)

[STINNER Victor]

Changes by STINNER Victor :


--
title: PyStructSequence_New() doesn't validate its input type (crashes in 
os.wait3() and os.wait4() in case of a bad resource.struct_rusage -> 
PyStructSequence_New() doesn't validate its input type (crashes in os.wait3() 
and os.wait4() in case of a bad resource.struct_rusage)

___
Python tracker 

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

[issue31573] PyStructSequence_New() doesn't validate its input type (crashes in os.wait3() and os.wait4() in case of a bad resource.struct_rusage

[STINNER Victor]

Changes by STINNER Victor :


--
title: crashes in os.wait3() and os.wait4() in case of a bad 
resource.struct_rusage -> PyStructSequence_New() doesn't validate its input 
type (crashes in os.wait3() and os.wait4() in case of a bad 
resource.struct_rusage

___
Python tracker 

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

[issue31573] crashes in os.wait3() and os.wait4() in case of a bad resource.struct_rusage

[STINNER Victor]

Changes by STINNER Victor :


--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue31573] crashes in os.wait3() and os.wait4() in case of a bad resource.struct_rusage

[STINNER Victor]

STINNER Victor added the comment:

Attached PR 3750 tries to validate the input type. The problem is that 
structseq is not exactly a type. It's hard to really validate everything. See 
the comment test in my PR.

--
nosy: +haypo

___
Python tracker 

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

[issue31573] crashes in os.wait3() and os.wait4() in case of a bad resource.struct_rusage

[STINNER Victor]

Changes by STINNER Victor :


--
keywords: +patch
pull_requests: +3737
stage:  -> patch review

___
Python tracker 

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

[issue31558] gc.freeze() - an API to mark objects as uncollectable

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
nosy: +pitrou

___
Python tracker 

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

[issue31576] problem in math

[ANEESH JOSE]

ANEESH JOSE added the comment:

Thankyou for the information .

--

___
Python tracker 

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

[issue31576] problem in math

[STINNER Victor]

STINNER Victor added the comment:

It seems like you are confused between radians and degrees. math.sin() expects 
radians.
https://docs.python.org/dev/library/math.html#math.sin

Sorry but the Python bug tracker is not the right to ask questions. I close 
your bug report.

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

[issue31576] problem in math

[ANEESH JOSE]

New submission from ANEESH JOSE:

We know that the answer of sin 90 is 1.
But In Python's library math,the value of it is around 0.83...
My program is as follows:
import math
a=math.sin(90)
print(a)
#Output obtained is 0.83.
Hope you guys solve this on the next update or nearby
I hope it is a small issue.But the credibility of program depends upon every 
minute particles

--
messages: 302955
nosy: aneesh317
priority: normal
severity: normal
status: open
title: problem in math
type: performance
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

[issue31574] Add dtrace hook for importlib

[Christian Heimes]

Christian Heimes added the comment:

Improved script and output for "import asyncio":

$ sudo stap import.stp -c "./python -c 'import asyncio'"
[1506343527655342994] * Importing '_frozen_importlib_external' ...
[1506343527655797118] + Imported  '_frozen_importlib_external' in 454us
[1506343527656351387] * Importing 'zipimport' ...
[1506343527656420328] + Imported  'zipimport' in 68us
[1506343527656577490] * Importing 'encodings' ...
[1506343527656969001]   * Importing 'codecs' ...
[1506343527657242647] * Importing '_codecs' ...
[1506343527657302163] + Imported  '_codecs' in 59us
[1506343527657461354]   + Imported  'codecs' in 492us
[1506343527657475610]   * Importing 'encodings.aliases' ...
[1506343527657778342]   + Imported  'encodings.aliases' in 302us
[1506343527657815834] + Imported  'encodings' in 1238us
[1506343527657829245] * Importing 'encodings.utf_8' ...
[1506343527658013466] + Imported  'encodings.utf_8' in 184us
[1506343527658037373] * Importing '_signal' ...
[1506343527658133293] + Imported  '_signal' in 95us
[1506343527658144146] * Importing 'encodings.latin_1' ...
[1506343527658350574] + Imported  'encodings.latin_1' in 206us
[1506343527658357616] * Importing 'io' ...
[1506343527658456592]   * Importing 'abc' ...
[1506343527658570293] * Importing '_weakrefset' ...
[1506343527658790316] + Imported  '_weakrefset' in 219us
[1506343527658881770]   + Imported  'abc' in 425us
[1506343527659074176] + Imported  'io' in 716us
[1506343527659130999] * Importing 'site' ...
[1506343527659303251]   * Importing 'os' ...
[1506343527659525410] * Importing 'errno' ...
[1506343527659597020] + Imported  'errno' in 71us
[1506343527659599466] * Importing 'stat' ...
[1506343527659766912]   * Importing '_stat' ...
[1506343527659826033]   + Imported  '_stat' in 59us
[1506343527659850009] + Imported  'stat' in 250us
[1506343527659890059] * Importing 'posixpath' ...
[1506343527660042891]   * Importing 'genericpath' ...
[1506343527660162920]   + Imported  'genericpath' in 119us
[1506343527660178776] + Imported  'posixpath' in 288us
[1506343527660291984] * Importing '_collections_abc' ...
[1506343527661557288] + Imported  '_collections_abc' in 1265us
[1506343527661673583]   + Imported  'os' in 2370us
[1506343527661677360]   * Importing '_sitebuiltins' ...
[1506343527661838265]   + Imported  '_sitebuiltins' in 160us
[1506343527662126078]   * Importing 'sitecustomize' ...
[1506343527662277259]   - Failed'sitecustomize' in 151us
[1506343527662281831]   * Importing 'usercustomize' ...
[1506343527662342158]   - Failed'usercustomize' in 60us
[1506343527662352810] + Imported  'site' in 3221us
[1506343527662533328] * Importing 'asyncio' ...
[1506343527662726586]   * Importing 'asyncio.selectors' ...
[1506343527662819261]   - Failed'asyncio.selectors' in 92us
[1506343527662828182]   * Importing 'selectors' ...
[1506343527662998225] * Importing 'collections' ...
[1506343527663394147]   * Importing 'operator' ...
[1506343527663966898] * Importing '_operator' ...
[1506343527664053199] + Imported  '_operator' in 86us
[1506343527664080513]   + Imported  'operator' in 686us
[1506343527664084065]   * Importing 'keyword' ...
[1506343527664212162]   + Imported  'keyword' in 128us
[1506343527664217270]   * Importing 'heapq' ...
[1506343527664344952] * Importing '_heapq' ...
[1506343527664482616] + Imported  '_heapq' in 137us
[1506343527664500526]   + Imported  'heapq' in 283us
[1506343527664504388]   * Importing 'itertools' ...
[1506343527664598920]   + Imported  'itertools' in 94us
[1506343527664603801]   * Importing 'reprlib' ...
[1506343527664775143]   + Imported  'reprlib' in 171us
[1506343527664779385]   * Importing '_collections' ...
[1506343527664845585]   + Imported  '_collections' in 66us
[1506343527665283918] + Imported  'collections' in 2285us
[1506343527665287954] * Importing 'collections.abc' ...
[1506343527665431913] + Imported  'collections.abc' in 143us
[1506343527665435709] * Importing 'math' ...
[1506343527665598221] + Imported  'math' in 162us
[1506343527665600676] * Importing 'select' ...
[1506343527665748069] + Imported  'select' in 147us
[1506343527666097689]   + Imported  'selectors' in 3269us
[1506343527666102503]   * Importing 'asyncio.base_events' ...
[1506343527666436554] * Importing 'concurrent.futures' ...
[1506343527666449899]   * Importing 'concurrent' ...
[1506343527666575660]   + Imported  'concurrent' in 125us
[150634352796868]   * Importing 'concurrent.futures._base' ...
[1506343527666880942] * Importing 'logging' ...
[1506343527667272107]   * Importing 'time' ...
[1506343527667364105]   + Imported  'time' in 91us
[1506343527667366876]   * Importing 'traceback' ...
[1506343527667538062] * Importing 'linecache' ...
[1506343527667655837]   * 

[issue31553] Extend json.tool to handle jsonlines (with a flag)

[Eric Moyer]

Eric Moyer added the comment:

I planned to write the PR myself, on the principle of "it's my itch, I
should scratch it." But if you think it is better for someone else to write
it, you know the codebase better than I, and you know how long a PR takes
to review/fix. My intention is to help. I'll do whatever is easier for you.

On Sep 24, 2017 10:01 PM, "Raymond Hettinger" 
wrote:

>
> Raymond Hettinger added the comment:
>
> Eric, did you want to write the PR yourself or would you like for Lisa to
> bring it to fruition?   If you're going to do it yourself, Lisa will serve
> as the primary reviewer (with either Ezio or me doing the final sign-off).
>
> --
> assignee:  -> lisroach
> nosy: +lisroach
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

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

[issue31520] ResourceWarning: unclosed warning

[STINNER Victor]

STINNER Victor added the comment:

> I’m curious how you manage to trigger the warning in the “closed” state.

It comes from Refleak buildbots. Example:

0:13:47 load avg: 3.24 [ 52/407] test_urllib2net passed (239 sec)
beginning 6 repetitions
123456
Resource 'http://www.imdb.com' is not available
/buildbot/buildarea/3.x.ware-gentoo-x86.refleak/build/Lib/test/libregrtest/refleak.py:253:
 ResourceWarning: unclosed 
  gc.collect()
..

I failed to reproduce this exact warning. I don't know if it's related to the 
"Resource 'http://www.imdb.com' is not available" message.

--

___
Python tracker 

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

[issue31574] Add dtrace hook for importlib

[Christian Heimes]

Christian Heimes added the comment:

Example output:

$ sudo stap import.stp -c "./python -c pass"
[1506342342142233574] * Importing '_frozen_importlib_external' ...
[1506342342142719538] + Imported  '_frozen_importlib_external'
[1506342342143260191] * Importing 'zipimport' ...
[1506342342143329476] + Imported  'zipimport'
[1506342342143474571] * Importing 'encodings' ...
[1506342342143858228]   * Importing 'codecs' ...
[1506342342144149624] * Importing '_codecs' ...
[1506342342144205933] + Imported  '_codecs'
[1506342342144363609]   + Imported  'codecs'
[1506342342144377843]   * Importing 'encodings.aliases' ...
[1506342342144676180]   + Imported  'encodings.aliases'
[1506342342144712610] + Imported  'encodings'
[1506342342144725110] * Importing 'encodings.utf_8' ...
[1506342342144906782] + Imported  'encodings.utf_8'
[1506342342144925714] * Importing '_signal' ...
[1506342342145015138] + Imported  '_signal'
[1506342342145025346] * Importing 'encodings.latin_1' ...
[1506342342145229859] + Imported  'encodings.latin_1'
[1506342342145236273] * Importing 'io' ...
[1506342342145333476]   * Importing 'abc' ...
[1506342342145443604] * Importing '_weakrefset' ...
[1506342342145658942] + Imported  '_weakrefset'
[1506342342145746442]   + Imported  'abc'
[1506342342145929972] + Imported  'io'
[1506342342145985754] * Importing 'site' ...
[1506342342146168933]   * Importing 'os' ...
[1506342342146387697] * Importing 'errno' ...
[1506342342146455581] + Imported  'errno'
[1506342342146457808] * Importing 'stat' ...
[1506342342146620691]   * Importing '_stat' ...
[1506342342146676954]   + Imported  '_stat'
[1506342342146700059] + Imported  'stat'
[1506342342146738715] * Importing 'posixpath' ...
[1506342342146882603]   * Importing 'genericpath' ...
[1506342342146999370]   + Imported  'genericpath'
[1506342342147014839] + Imported  'posixpath'
[1506342342147133401] * Importing '_collections_abc' ...
[1506342342148404142] + Imported  '_collections_abc'
[1506342342148517849]   + Imported  'os'
[1506342342148521360]   * Importing '_sitebuiltins' ...
[1506342342148680131]   + Imported  '_sitebuiltins'
[1506342342148952120]   * Importing 'sitecustomize' ...
[1506342342149107151]   - Failed'sitecustomize'
[1506342342149111461]   * Importing 'usercustomize' ...
[1506342342149171745]   - Failed'usercustomize'
[1506342342149182576] + Imported  'site'

--
Added file: https://bugs.python.org/file47168/import.stp

___
Python tracker 

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

[issue31575] Functional Programming HOWTO sub-optimal example for reduce

[Anran Yang]

New submission from Anran Yang:

At the end of the Functional Programming HOWTO document 
(https://docs.python.org/3.7/howto/functional.html) the usage of 
reduce/lambda/for loops are compared and discussed. However, the example for 
reduce seems sub-optimal and thus the discussion is not that efficient. The 
example:

total = functools.reduce(lambda a, b: (0, a[1] + b[1]), items)[1]

could be changed to:

total = functools.reduce(lambda total, item: total + item[1], items, 0)

which is much more readable and is actually not much inferior to the loop one 
(though the sum approach is still more concise).

--
assignee: docs@python
components: Documentation
messages: 302950
nosy: Anran Yang, docs@python
priority: normal
severity: normal
status: open
title: Functional Programming HOWTO sub-optimal example for reduce
versions: 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

[issue31520] ResourceWarning: unclosed warning

[Martin Panter]

Martin Panter added the comment:

I’m curious how you manage to trigger the warning in the “closed” state. The 
Python I have handy is half a year out of date, but all my attempts to trigger 
the warning either produce the less confusing version,

ResourceWarning: unclosed 

or there is no warning at all due IOBase.__del__ (see Issue 19829).

If your SocketIO was wrapped in a BufferedReader/Writer/RWPair, then that could 
easily close the SocketIO object before SocketIO.__del__ is called. You would 
also have to override the wrapper’s __del__ method, rather than (or as well as) 
SocketIO.__del__.

--

___
Python tracker 

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

[issue30347] itertools.groupby() can fail a C assert()

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Hmm, the sole issue30346 is not enough for fixing this crash. I don't know if 
there is a simpler fix based on issue30346, but since PR 1557 removes the code 
duplication I'm going to merge it in any case.

--

___
Python tracker 

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

[issue30347] itertools.groupby() can fail a C assert()

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
versions:  -Python 3.5

___
Python tracker 

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

[issue25732] functools.total_ordering does not correctly implement not equal behaviour

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


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

[issue25732] functools.total_ordering does not correctly implement not equal behaviour

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

I committed the patch from Raymond's name, but GitHub set me as the author of 
the commit. :(

--

___
Python tracker 

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

[issue25732] functools.total_ordering does not correctly implement not equal behaviour

[Serhiy Storchaka]

Serhiy Storchaka added the comment:


New changeset d94a65a0694a188713f91ba7c9fffded090247dc by Serhiy Storchaka in 
branch '2.7':
bpo-25732: Make functools.total_ordering implementing __ne__. (#3748)
https://github.com/python/cpython/commit/d94a65a0694a188713f91ba7c9fffded090247dc


--

___
Python tracker 

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

[issue31573] crashes in os.wait3() and os.wait4() in case of a bad resource.struct_rusage

[Oren Milman]

New submission from Oren Milman:

The following code causes the interpreter to crash:
import os
import time
import resource
new_pid = os.fork()
if new_pid == 0:
time.sleep(0.5)
else:
resource.struct_rusage = None
os.wait3(0)

We would get a crash also if we replaced 'os.wait3(0)' with 'os.wait4(new_pid, 
0)'.

This is because wait_helper() (in in Modules/posixmodule.c) assumes that
resource.struct_rusage is a type object, and passes it to 
PyStructSequence_New(),
which tries to access the n_fields attribute, and crashes.


In addition, the following code causes a SystemError:
class BadStructRusage:
n_fields = None

import os
import time
import resource
new_pid = os.fork()
if new_pid == 0:
time.sleep(0.5)
else:
resource.struct_rusage = BadStructRusage
os.wait3(0)

This is because PyStructSequence_New() (in Objects/structseq.c) assumes that it
received a type with a valid n_fields attribute.


Similarly, the following code causes the interpreter to crash:
class BadStructRusage:
n_fields = 16
n_sequence_fields = None

import os
import time
import resource
new_pid = os.fork()
if new_pid == 0:
time.sleep(0.5)
else:
resource.struct_rusage = BadStructRusage
os.wait3(0)


ISTM that we can fix these problems by adding checks to wait_helper() and to
PyStructSequence_New().
However, maybe a more simple solution would be to either:
- Make wait_helper() always use StructRUsageType (defined in 
Modules/resource.c).
- Disable assigning to resource.struct_rusage.

Moreover, I don't understand the comment before calling PyStructSequence_New():
/* XXX(nnorwitz): Copied (w/mods) from resource.c, there should be only one. */
Is it relevant to this issue?


Lastly, I am not sure about tests (as I found almost no tests of wait3() and
wait4()).
Should I add to Lib/test/test_wait3.py and Lib/test/test_wait4.py each a class
to test this issue? Or is it too much of a corner case, and a test is not 
needed?

--
components: +Extension Modules
title: struct_rusage -> crashes in os.wait3() and os.wait4() in case of a bad 
resource.struct_rusage
type:  -> crash
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

[issue30152] Reduce the number of imports for argparse

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

functools.wraps() is used in more complex programs. The purpose of this PR is 
speeding up small scripts that just start, parse arguments, do its fast work 
(so fast as outputting a help or a version) and exit. Even collections is not 
used in a half of my scripts.

types needs functools only for coroutine(). Unlikely it is used in old style 
namespace packages.

--

___
Python tracker 

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

[issue31415] Add -X option to show import time

[Christian Heimes]

Christian Heimes added the comment:

+1 for an option to profile import time.

I have a minor complain: The output format is not machine-friendly, which makes 
it harder to perform automatic analysis. I created #31574 / PR3749 to add 
dtrace probes.

--
nosy: +christian.heimes

___
Python tracker 

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

[issue31574] Add dtrace hook for importlib

[Christian Heimes]

Changes by Christian Heimes :


--
keywords: +patch
pull_requests: +3736
stage: needs patch -> patch review

___
Python tracker 

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

[issue31574] Add dtrace hook for importlib

[Christian Heimes]

New submission from Christian Heimes:

#31415 proposed an option to show import timings. The output is primarily 
designed for humans. I propose to instrument importlib with two dtrace hooks:

  probe import__find__load__start(const char *)
  probe import__find__load__done(const char *, int);

arg0 is the absolute module name as UTF-8 string. arg1 of import_find_load_done 
probe indicates if the module was found (1) or import failed (0).

--
components: Interpreter Core
messages: 302942
nosy: brett.cannon, christian.heimes, eric.snow, ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Add dtrace hook for importlib
type: performance
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

[issue31573] struct_rusage

[Oren Milman]

Changes by Oren Milman :


--
nosy: Oren Milman
priority: normal
severity: normal
status: open
title: struct_rusage

___
Python tracker 

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

[issue30152] Reduce the number of imports for argparse

[INADA Naoki]

INADA Naoki added the comment:

Oh, the pull request is far larger than I thought!

I doubt that avoiding functools and collections is worth enough, because it is 
very common.

For example:

* functools is very commonly imported, especially for wraps().

* collections is imported by functools, so it's more commonly imported than 
functools.

* Old style namespace package (.pth file) imports types module, and types 
module and types imports functools, collections.  So even `python -c 42` 
imports them if at least one old-style namespace package is installed.  (e.g. 
Sphinx)


Instead of avoiding them, I want to make them faster.

* C implementation of ABC will makes collection, weakref and some other modules 
much faster.
* Recent PEP will allows split functools module into submodules without 
breaking backward compatibility.

--
nosy: +inada.naoki

___
Python tracker 

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

[issue25732] functools.total_ordering does not correctly implement not equal behaviour

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
pull_requests: +3735
stage: commit review -> patch review

___
Python tracker 

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

[issue31530] Python 2.7 readahead feature of file objects is not thread safe

[Antoine Pitrou]

Antoine Pitrou added the comment:

Le 25/09/2017 à 11:39, STINNER Victor a écrit :
> 
> Antoine: "I'm wary of raising an exception.  Assuming Benjamin's patch is 
> correct, I vote for it."
> 
> Can you please elaborate? You are fine with the fact that iter(file) in two 
> thread can return the same line?

AFAIU it already could.  Iteration on Python 2 files is fragile, now is
not the time to fix fundamental bugs in Python 2.

--

___
Python tracker 

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

[issue31530] Python 2.7 readahead feature of file objects is not thread safe

[STINNER Victor]

STINNER Victor added the comment:

Antoine: "I'm wary of raising an exception.  Assuming Benjamin's patch is 
correct, I vote for it."

Can you please elaborate? You are fine with the fact that iter(file) in two 
thread can return the same line?

--

___
Python tracker 

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

[issue31530] Python 2.7 readahead feature of file objects is not thread safe

[Antoine Pitrou]

Antoine Pitrou added the comment:

I'm wary of raising an exception.  Assuming Benjamin's patch is correct, I vote 
for it.

--

___
Python tracker 

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