[issue30466] Tutorial doesn't explain the use of classes

[Raymond Hettinger]

Raymond Hettinger added the comment:

Apparently this was committed without my review.

--
assignee: rhettinger -> 

___
Python tracker 

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

[issue30935] document the new behavior of get_event_loop() in Python 3.6

[Mandeep Singh]

Changes by Mandeep Singh :


--
pull_requests: +2791

___
Python tracker 

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

[issue23844] test_ssl: fails on recent libressl version with BAD_DH_P_LENGTH

[Ned Deily]

Ned Deily added the comment:


New changeset b52c0075511f8330f57c81520ee0287241d3653f by Ned Deily in branch 
'3.3':
bpo-23844: Fix test_dh_params failure
https://github.com/python/cpython/commit/b52c0075511f8330f57c81520ee0287241d3653f


--
nosy: +ned.deily

___
Python tracker 

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

[issue30919] Shared Array Memory Allocation Regression

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

The size of file system mounted on "/run/user/${uid}" is limited (only 200 MiB 
on my computer). get_temp_dir() will be successful, but this may be not enough 
for allocating large shared array. And it is harder to control by user, because 
the location is not specified by an environment variable.

--

___
Python tracker 

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

[issue30919] Shared Array Memory Allocation Regression

[Antoine Pitrou]

Antoine Pitrou added the comment:

> The size of file system mounted on "/run/user/${uid}" is limited (only 200 
> MiB on my computer)

Hmm, you're right.  Is /dev/shm ok on your computer?

--

___
Python tracker 

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

[issue30694] Update embedded copy of expat to 2.2.1

[Ned Deily]

Ned Deily added the comment:


New changeset ab90986600ba7dea2aa41e5c1773791070725453 by Ned Deily (Victor 
Stinner) in branch '3.3':
[3.3] bpo-29591, bpo-30694: Upgrade Modules/expat to libexpat 2.2.1 (#2164) 
(#2204)
https://github.com/python/cpython/commit/ab90986600ba7dea2aa41e5c1773791070725453


--

___
Python tracker 

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

[issue30726] [Windows] Warnings in elementtree due to new expat

[Ned Deily]

Ned Deily added the comment:


New changeset ab90986600ba7dea2aa41e5c1773791070725453 by Ned Deily (Victor 
Stinner) in branch '3.3':
[3.3] bpo-29591, bpo-30694: Upgrade Modules/expat to libexpat 2.2.1 (#2164) 
(#2204)
https://github.com/python/cpython/commit/ab90986600ba7dea2aa41e5c1773791070725453


--

___
Python tracker 

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

[issue29591] expat 2.2.0: Various security vulnerabilities in bundled expat (CVE-2016-0718 and CVE-2016-4472)

[Ned Deily]

Ned Deily added the comment:


New changeset ab90986600ba7dea2aa41e5c1773791070725453 by Ned Deily (Victor 
Stinner) in branch '3.3':
[3.3] bpo-29591, bpo-30694: Upgrade Modules/expat to libexpat 2.2.1 (#2164) 
(#2204)
https://github.com/python/cpython/commit/ab90986600ba7dea2aa41e5c1773791070725453


--

___
Python tracker 

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

[issue30797] ./pyconfig.h:1438:0: warning: "_GNU_SOURCE" redefined [enabled by default]

[Ned Deily]

Changes by Ned Deily :


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

[issue30694] Update embedded copy of expat to 2.2.1

[Ned Deily]

Changes by Ned Deily :


--
priority: deferred blocker -> 
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

[issue30919] Shared Array Memory Allocation Regression

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Yes, /dev/shm is ok on my computer.

But there is yet one drawback of this patch. Currently the size of shared array 
is limited by the free space on the file system for temporary files. If it 
isn't enough you can easy set TMPDIR to other path. In 2.7 and with hardcoded 
/dev/shm it is limited by the size of physical memory (maybe plus swap). It is 
not easy to increase it, especially for unprivileged user.

The effect of hardcoding /dev/shm can be achieved by setting TMPDIR to 
/dev/shm. Using os.ftruncate() adds yet about 20% of speed up. This looks 
mainly as a documentation issue to me. The regression and the workaround should 
be documented.

--

___
Python tracker 

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

[issue30919] Shared Array Memory Allocation Regression

[Antoine Pitrou]

Antoine Pitrou added the comment:

The main issue here is to restore performance of 2.7 version.  Setting TMPDIR 
sounds too general and might have impact on other libraries.  I think it's ok 
if shared array size is limited by virtual memory size on the computer, since 
the whole point is to expose a fast communication channel between processes.

--

___
Python tracker 

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

[issue30919] Shared Array Memory Allocation Regression

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

This can break Python 3 applications that work with shared arrays larger than 
the size of physical memory. If do this change, it should be optional.

Setting TMPDIR=/dev/shm restores performance of 2.7 version even on versions 
that we will decide to not patch.

--

___
Python tracker 

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

[issue30919] Shared Array Memory Allocation Regression

[Antoine Pitrou]

Antoine Pitrou added the comment:

Again, setting TMPDIR is a poor workaround as it will impact any library 
creating temporary files.

I haven't found anyone complaining about limited shared array size on 2.7, so 
likely it's not a common concern.  Right now, anyone creating a huge shared 
array on 3.x will be facing huge performance issues, as the array is backed by 
disk, so it doesn't sound realistic at all to assume people are doing that.

--

___
Python tracker 

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

[issue30938] pdb lacks debugger command to list and show all user-defined variables

[Roundup Robot]

Changes by Roundup Robot :


--
pull_requests: +2792

___
Python tracker 

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

[issue23916] module importing performance regression

[David Roundy]

David Roundy added the comment:

Here is a little script to demonstrate the regression (which yes, is still 
bothering me).

--
type:  -> performance
versions: +Python 3.5
Added file: http://bugs.python.org/file47016/test.py

___
Python tracker 

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

[issue23916] module importing performance regression

[Antoine Pitrou]

Antoine Pitrou added the comment:

Thanks for the reproducer.  I haven't changed my mind on the resolution, as it 
is an extremely unlikely usecase (a directory with 1e8 files is painful to 
manage with standard command-line tools).  I suggest you change your approach, 
for example you could use a directory hashing scheme to spread the files into 
smaller subdirectories.

--

___
Python tracker 

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

[issue25571] Improve the lltrace feature with the Py_Debug mode

[George King]

George King added the comment:

@matrixise, I'm the author of the alternative in issue29400, and I'm finally 
finding the time to get back into it. I'm going to make a push this week to 
clean it up; your feedback would be much appreciated!

--
nosy: +gwk

___
Python tracker 

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

[issue30934] Document how to run coverage for repository idlelib files.

[Louie Lu]

Changes by Louie Lu :


--
pull_requests: +2794

___
Python tracker 

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

[issue30934] Document how to run coverage for repository idlelib files.

[Louie Lu]

Louie Lu added the comment:

Upload the Linux/MacOS version of coverage usage.

--

___
Python tracker 

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

[issue30694] Update embedded copy of expat to 2.2.1

[STINNER Victor]

STINNER Victor added the comment:

Yeah! It's nice to see this issue now fixed in all branches!

--

___
Python tracker 

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

[issue25571] Improve the lltrace feature with the Py_Debug mode

[STINNER Victor]

STINNER Victor added the comment:

I still strongly prefer bpo-29400 over "lltrace", since it would be usable in 
release mode.

--

___
Python tracker 

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

[issue30936] json module ref leaks detected by test_json

[STINNER Victor]

STINNER Victor added the comment:

Thanks for the fixes. I checked manually 2.7, 3.5, 3.6 and master branches with 
"./python -m test -R 3:3 test_json": no more leak!

--

___
Python tracker 

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

[issue9262] IDLE: Revise or replace tabbedpages for multi-editor window.

[Vedran Čačić]

Vedran Čačić added the comment:

> The way IDLE looks on Mac is what we want on all systems.  I added a note to 
> #24826.

I'm not sure I understand you. This is what I have on Windows today. Of course, 
the menu is replicated on each window, but that's an irrelevant detail - it 
doesn't take that much space, and I use keyboard to access it anyway.

What I emphasized is something else: separate windows that can be independently 
opened, closed, moved and resized. When Raymond needs a few characters more in 
a line, he just temporarily resizes the window - everything else stays at the 
same place, ready for return to the previous state.

I think it's essential, and I must say I have never seen it in a tabbed 
interface application.

> Do you regularly work on Mac?  It would be help if someone were to test PRs 
> on OSX, especially patches intended to change what users see.  Even a weekly 
> test of a fresh download from the repository would be helpful.

No, sorry. I use Windows at home and Linux at work, I have never worked on a 
Mac. As I said above, my point was not the position of the main menu, but the 
ability to position windows where I want them on the screen.

--

___
Python tracker 

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

[issue29400] Add instruction level tracing via sys.settrace

[George King]

George King added the comment:

After reviewing the thread, I'm reminded that the main design problem concerns 
preserving behavior of this idiom:
"old=sys.gettrace(); ...; sys.settrace(old)"

If we add more state, i.e. the `trace_instructions` bool, then the above idiom 
no longer correctly stores/reloads the full state.

Here are the options that I see:

1. New APIs:
* `gettrace() -> Callable # no change.`
* `settrace(tracefunc: Callable) -> None # no change.`
* `gettraceinst() -> Callable # new.`
* `settraceinst(tracefunc: Callable) -> None # new.`
Behavior:
* `settrace()` raises if `gettraceinst()` is not None.
* `settraceinst()` raises if `gettrace()` is not None.


2. Add keyword arg to `settrace`.
* `gettrace() -> Callable # no change.`
* `settrace(tracefunc: Callable, trace_instructions:Optional[bool]=False) -> 
None # added keyword.`
* `gettracestate() -> Dict[str, Any] # new.`
Behavior:
* `gettracestate()` returns the complete trace-related state: currently, 
`tracefunc` and `trace_instructions` fields.
* `gettrace()` raises an exception if any of the trace state does not match the 
old behavior, i.e. if `trace_instructions` is set.


3. New API, but with extensible keyword args:
* `settracestate(tracefunc: Callable, trace_instructions:Optional[bool]=False) 
-> None # new.`
* `gettracestate() -> Dict[str, Any] # new.`
Behavior:
* `settrace()` raises if `gettracestate()` is not None.
* `settracestate()` raises if `gettrace()` is not None.


As I see it:
* approach #1 is more conservative because it does not modify the old API.
* approach #2 is more extensible because all future features can be represented 
by the state dictionary.
* approach #3 has both of these strengths, but is also the most work.

Examples of possible future features via keywords:
* branch-level tracing, as briefly disscussed above.
* instruction filtering set, which could be a more general version of the 
branch tracing.

I intend to prototype one or both of these, but I'm also feeling a bit of time 
pressure to get the basic feature on track for 3.7.

--

___
Python tracker 

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

[issue25684] ttk.OptionMenu radiobuttons aren't unique between two instances of OptionMenu

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


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

[issue30940] Documentation for round() is incorrect.

[George K]

New submission from George K:

The documentation for round states "The return value is an integer if called 
with one argument, otherwise of the same type as number." This is not the case 
if the second argument is None.

--
assignee: docs@python
components: Documentation
messages: 298442
nosy: George K, docs@python
priority: normal
severity: normal
status: open
title: Documentation for round() is incorrect.
versions: Python 3.5, Python 3.6

___
Python tracker 

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

[issue30940] Documentation for round() is incorrect.

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

In 3.4 round() doesn't accept None as ndigits argument. The behavior was 
changed by issue19933 and issue27936. Wasn't this change a mistake? Seems Mark 
opposed to it.

--
nosy: +mark.dickinson, rhettinger, serhiy.storchaka, steve.dower
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

[issue28638] Optimize namedtuple creation

[INADA Naoki]

INADA Naoki added the comment:

I like your idea.  Would you make pull request?

--
resolution: rejected -> 
status: closed -> open
title: Creating namedtuple is too slow to be used in common stdlib (e.g. 
functools) -> Optimize namedtuple creation

___
Python tracker 

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

[issue30941] Missing line in example program

[Luc Bougé]

New submission from Luc Bougé:

On page , the 
following program is listed.

It raises a syntactic error.

An empty line is missing after "... n += val" to close the loop body. 

   >>> # iteration
   >>> n = 0
   >>> for val in values:
   ... n += val
   >>> print(n)
   504

--
assignee: docs@python
components: Documentation
messages: 298445
nosy: docs@python, lucbouge
priority: normal
severity: normal
status: open
title: Missing line in example program
type: resource usage
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

[issue30934] Document how to run coverage for repository idlelib files.

[Terry J. Reedy]

Terry J. Reedy added the comment:

Cheryl, please try Louie's linux instructions and see if they work on Ubuntu.

--

___
Python tracker 

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

[issue30941] Missing line in example program

[R. David Murray]

R. David Murray added the comment:

This is the standard way that we write examples.  Sprinkling in extra blank 
lines everywhere would make the examples less readable.  One you've learned how 
the command interpreter works, the examples are clear, so you each beginner 
only has to learn this once (and I believe it is explained in the tutorial, 
though I haven't checked).

--
nosy: +r.david.murray
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
type: resource usage -> behavior

___
Python tracker 

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

[issue22253] ConfigParser does not handle files without sections

[Roundup Robot]

Changes by Roundup Robot :


--
pull_requests: +2795

___
Python tracker 

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

[issue22253] ConfigParser does not handle files without sections

[Pedro Lacerda]

Pedro Lacerda added the comment:

Thank you 林自均! I just made a pull-request with the relevant bits.

--

___
Python tracker 

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

[issue9262] IDLE: Revise or replace tabbedpages for multi-editor window.

[Terry J. Reedy]

Terry J. Reedy added the comment:

Vedran, reread "continue ... with multiple windows".  What you describe as 'I 
have never seen' seems standard for tabbed windows applications.  I just 
verified that FireFox and Edge allow "separate windows that can be 
independently opened, closed, moved and resized."  (To repeat, I will NOT copy 
Notepad++ in restricting to one windows, which I regard as exceptional.)

Firefox also has both features Tal requested in msg110906 "And if you can have 
several windows, each with several tabs, drag-n-drop moving of tabs between 
windows is really nice to have, not to mention drag-n-drop reordering of tabs." 
 (Edge does not allow dropping on an existing window).  I would like both for 
IDLE if tk drag-and-drop allows.

--

___
Python tracker 

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

[issue23916] module importing performance regression

[Brett Cannon]

Brett Cannon added the comment:

I agree with Antoine that this shouldn't change. Having said that, it
wouldn't be hard to write your own finder using importlib that doesn't get
the directory contents and instead checks for the file directly (and you
could even set it just for your troublesome directory to get the
performance benefit from the default finder).

On Sun, Jul 16, 2017, 05:25 Antoine Pitrou,  wrote:

>
> Antoine Pitrou added the comment:
>
> Thanks for the reproducer.  I haven't changed my mind on the resolution,
> as it is an extremely unlikely usecase (a directory with 1e8 files is
> painful to manage with standard command-line tools).  I suggest you change
> your approach, for example you could use a directory hashing scheme to
> spread the files into smaller subdirectories.
>
> --
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

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

[issue30939] Sphinx 1.6.3 deprecation warning for sphinx.util.compat.Directive in docs builds

[Brett Cannon]

Brett Cannon added the comment:

I wonder if we should pin sphinx directly instead of the approximate pin we
have now to prevent this sort of thing in the future? I had figured they
wouldn't introduce a new warning in a bugfix release but I was wrong in
that assumption.

On Sat, Jul 15, 2017, 12:19 Ned Deily,  wrote:

>
> New submission from Ned Deily:
>
> [..]/sphinx/util/compat.py:40: RemovedInSphinx17Warning:
> sphinx.util.compat.Directive is deprecated and will be removed in Sphinx
> 1.7, please use docutils' instead.
>   RemovedInSphinx17Warning)
>
> The solution is to import Directive directly from docutils.  PR to follow
> for master, needs to be cherrypicked to all maintenance branches and,
> ideally, all current security-only branches.
>
> --
> assignee: docs@python
> components: Documentation
> messages: 298401
> nosy: brett.cannon, docs@python, larry, ned.deily
> priority: normal
> severity: normal
> stage: patch review
> status: open
> title: Sphinx 1.6.3 deprecation warning for sphinx.util.compat.Directive
> in docs builds
> versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6,
> Python 3.7
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

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

[issue28638] Optimize namedtuple creation

[Jelle Zijlstra]

Changes by Jelle Zijlstra :


--
pull_requests: +2796

___
Python tracker 

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

[issue30874] unittest execute tests twice in some conditions

[ale5000]

ale5000 added the comment:

@louielu: I have the problem under Windows, and on Travis CI under Linux.

--

___
Python tracker 

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

[issue28638] Optimize namedtuple creation

[Raymond Hettinger]

Raymond Hettinger added the comment:

> creates only one necessary backwards compatibility break 
> (we no longer have _source).

IMO, this is an essential feature.  It allows people to easily build their own 
variants, to divorce the generated code from the generator, and to fully 
understand what named tuples do (that is in part why we get so few questions 
about how they work).

You all seem to be in rush to redesign code that has been stable and well 
served the needs of users for a very long time.  This all seems to be driven by 
a relentless desire for micro-optimizations regardless of actual need.

BTW, none of the new contributors seem to be aware of named tuple's history.  
It was an amalgamation of many separate implementations that had sprung up in 
the wild (it was being reinvented many times).  It was posted as ASPN recipe 
and went through a long period of maturation that incorporated the suggestions 
of over a dozen engineers based on use in the field.  It went through further 
refinement when examined and discussed on the pythoh-dev incorporating reviews 
from Guido, Alex, and Tim.  Since that time, the tools has been broadly 
deployed and met the needs of enormous numbers of users. Its use is considered 
a best practice.  The code and API have maintained and improved an 
intentionally slow and careful pace.

I really, really do not want to significantly revised the stable code and 
undermine the premise of its implementation so that you can save a few 
micro-seconds in the load of some module.  That is contrary to our optimization 
philosophy for CPython.  

As is, the code is very understandable, easy to maintain, easy to understand, 
easy to create variants, easy to verify that it is bug free. It works great for 
CPython, IronPython, PyPy, and Jython without modification.

--

___
Python tracker 

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

[issue9216] FIPS support for hashlib

[Andrew DiPrinzio]

Andrew DiPrinzio added the comment:

I have been able to use this flag on RHEL and Centos. Is it possible that this 
has been completed?

--
nosy: +Andrew DiPrinzio

___
Python tracker 

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

[issue26617] Assertion failed in gc with __del__ and weakref

[Ned Deily]

Ned Deily added the comment:

If it's also reproducible with 3.3, I'd take a 3.3 PR for it.

--

___
Python tracker 

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

[issue26617] Assertion failed in gc with __del__ and weakref

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

I wait merging PR 2695 for cherry-picking it to 3.3.

--

___
Python tracker 

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

[issue28638] Optimize namedtuple creation

[Nick Coghlan]

Nick Coghlan added the comment:

I agree with Raymond here - the standard library's startup benchmarks are *NOT* 
normal code execution paths, since normal code execution is dominated by the 
actual operation being performed, and hence startup micro-optimizations vanish 
into the noise.

Accordingly, we should *not* be redesigning existing standard interfaces simply 
for the sake of allowing them to be used during startup without significantly 
slowing down the interpreter startup benchmark.

By contrast, it *is* entirely OK to introduce specialised types specifically 
for internal use (including during startup), and only making them available at 
the Python level through the types module (e.g. types.MappingProxyType, 
types.SimpleNamespace).

At the moment, the internal PyStructSequence type used to define sys.flags, 
sys.version_info, etc *isn't* exposed that way, so efforts to allow the use of 
namedtuple-style interfaces in modules that don't want to use namedtuple itself 
would likely be better directed towards making that established type available 
and usable through the types module, rather than towards altering namedtuple.

That approach would have the potential to solve both the interpreter startup 
optimisation problem (as the "types" module mainly just exposes thing defined 
by the interpreter implementation, not new Python level classes), *and* provide 
an alternate option for folks that have pre-emptively decided that namedtuple 
is going to be "too slow" for their purposes without actually measuring the 
relative performance in the context of their application.

--

___
Python tracker 

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

[issue30942] Implement lwalk(levelwalk) function on os.py

[André Rossi Korol]

New submission from André Rossi Korol:

I forked cpython and implemented an lwalk function on os.py. The lwalk funtion 
behaves exactly like walk(), except that it recurses only to a certain level of 
depth that can be selected by the user. More information on the lwalk function 
can be found on "os.py" in my cpython fork. It worked fine when I tested the 
funtion in a local virtual environment, but when I installed Python 3.7 with my 
lwalk function implemented in os.py I get an error when I try to test it in my 
recent Python installation: "TypeError: 'NoneType' object is not iterable".
I'd like to know where else I need to add info about my lwalk function so it 
can be correctly used in a fresh Python installation and so than I can send a 
Pull Request.

--
components: Library (Lib)
files: os.py
hgrepos: 369
messages: 298458
nosy: andrekorol
priority: normal
severity: normal
status: open
title: Implement lwalk(levelwalk) function on os.py
type: enhancement
versions: Python 3.7
Added file: http://bugs.python.org/file47017/os.py

___
Python tracker 

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

[issue30942] Implement lwalk(levelwalk) function on os.py

[André Rossi Korol]

André Rossi Korol added the comment:

I forked cpython and implemented an lwalk function on os.py. The lwalk funtion 
behaves exactly like walk(), except that it recurses only to a certain level of 
depth that can be selected by the user. More information on the lwalk function 
can be found on "os.py" in my cpython fork.
I'd like to know what else I need to do in order to send a Pull Request.

--
hgrepos: +370
Added file: http://bugs.python.org/file47018/os.py

___
Python tracker 

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

[issue30942] Implement lwalk(levelwalk) function on os.py

[André Rossi Korol]

Changes by André Rossi Korol :


--
hgrepos:  -369

___
Python tracker 

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

[issue30942] Implement lwalk(levelwalk) function on os.py

[André Rossi Korol]

André Rossi Korol added the comment:

UPDATE: I already fixed the cause of the TypeError I mentioned earlier.

--

___
Python tracker 

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

[issue30939] Sphinx 1.6.3 deprecation warning for sphinx.util.compat.Directive in docs builds

[Ned Deily]

Ned Deily added the comment:

> I wonder if we should pin sphinx directly instead of the approximate pin we
> have now to prevent this sort of thing in the future?

Perhaps. OTOH, we will find out about Sphinx incompatibilities pretty quickly 
that way, rather than having doc builds potentially silently fail or only 
finding out about the problem at release time.

--

___
Python tracker 

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

[issue28638] Optimize namedtuple creation

[Raymond Hettinger]

Changes by Raymond Hettinger :


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