[issue6766] Cannot modify dictionaries inside dictionaries using Managers from multiprocessing

[Johannes]

Johannes  added the comment:

Hi all, I'm trying to use multiprocessing with a 3d list. From the 
documentation I expected it to work. As I found this report a bid later, I 
opened a bug report here: https://bugs.python.org/issue32538. Am I doing sth. 
wrong or is it still not working in 3.6.3?

--
nosy: +John_81

___
Python tracker 

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

[issue8243] curses writing to window's bottom right position raises: `_curses.error: addstr() returned ERR'

[Jay Crotts]

Change by Jay Crotts :


--
keywords: +patch
pull_requests: +5031
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

[issue32516] Add a shared library mechanism for win32

[xoviat]

xoviat  added the comment:

My current plan is to patch the __init__ package files to add the '.libs' 
folder to the search path. However, I think it would be better for Python to do 
this so that there is a consistent mechanism for loading shared libraries.

--

___
Python tracker 

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

[issue32516] Add a shared library mechanism for win32

[xoviat]

xoviat  added the comment:

So the idea here is actually to write a replacement for auditwheel that works 
on windows. In order to do that, I need to recursively analyze DLL 
dependencies, randomize the DLL filenames, rewrite the pe header table, and 
then copy them into the .libs folder.

At that point, I need some mechanism to either preload all of the DLLs or add 
them to the DLL search path so that extensions can find them (example: the 
extension will need to load umfpack-gghsa-cp36.dll). If assemblies can 
accomplish such a task, then I can use them. However the restriction on the 
number of parent directories is a real problem.

I've benchmarked preloading the DLLs and it's not really ideal.

--

___
Python tracker 

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

[issue32546] Unusual TypeError with dataclass decorator

[Eric V. Smith]

Eric V. Smith  added the comment:

No matter what happens with #32513, I think the right thing to do in this case 
is to not error if trying to set __hash__ to None, if it already is None in 
__dict__.

--

___
Python tracker 

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

[issue21592] Make statistics.median run in linear time

[Raymond Hettinger]

Raymond Hettinger  added the comment:

Everyone here should heed Tim's comments.  The statistics module already has a 
history of suboptimal decisions made in the service of theoretical perfection 
(i.e. mean(seq) is over a 100x slower than fsum(seq)/len(seq)).

While variants of quick-select have a nice O(n) theoretical time, the 
variability is very-high and has really bad worst cases. The existing sort() is 
unbelievably fast, has a reasonable worst case, exploits existing order to 
great advantage, has nice cache performance, and has become faster still with 
the recently added type-specialized comparisons.  This sets a very high bar for 
any proposed patches.

--
nosy: +rhettinger

___
Python tracker 

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

[issue32516] Add a shared library mechanism for win32

[Eryk Sun]

Eryk Sun  added the comment:

> on Windows, the rpath mechanism doesn't exist

It seems we can locate a dependent assembly up to two directories up from a DLL 
using a relative path. According to MSDN [1], this is supported in Windows 7+. 
3.7 no longer supports Vista, so this can potentially be used for extension 
modules in 3.7. I tested that it works in Windows 10, at least.

[1]: https://msdn.microsoft.com/en-us/library/aa374182

Create a ".2.config" file for the module (e.g. 
"myextension.pyd.2.config"), and include a "probing" path in this file. This 
can specify up to 9 relative directories that can be up to two levels above the 
module. For example, the following adds "..\.libs" to the DLL's private 
assembly search path:



  

  

  


Add dependent assemblies to the module's #2 embedded manifest. For example, 
here's a dependency on 64-bit "myassembly" version 1.0.000.1234:

  

  

  

I this case the assembly is a directory with the given assembly name that 
contains an ".manifest" file (e.g. "myassembly.manifest"). This 
manifest lists the assembly DLLs that are in the directory. For example:








The loader will look for the assembly in WinSxS, the module's directory, a 
subdirectory named for the assembly, and then the private probing paths that 
were added by the module's config file.

--
nosy: +eryksun

___
Python tracker 

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

[issue32548] IDLE: Add links for email and docs to help_about

[Cheryl Sabella]

Change by Cheryl Sabella :


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

___
Python tracker 

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

[issue32548] IDLE: Add links for email and docs to help_about

[Cheryl Sabella]

New submission from Cheryl Sabella :

In the help_about dialog, change the email address and IDLE documentation into 
hyperlinks as a first step toward rewriting the dialog to use hyperlinks 
instead of buttons, as proposed in msg296648 and msg294298.

--
assignee: terry.reedy
components: IDLE
messages: 309906
nosy: csabella, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE: Add links for email and docs to help_about
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

[issue32547] csv.DictWriter emits strange errors if fieldnames is an iterator

[Raymond Hettinger]

Raymond Hettinger  added the comment:

This isn't a bug.  The docs specify that *fieldnames* is a sequence, "The 
fieldnames parameter is a sequence of keys that identify the order in which 
values in the dictionary passed to the writerow() method are written to the 
csvfile."

We could make this a feature request. but as far as I can tell there isn't a 
real use case, nor has one ever arisen in the decade long history of the 
module.  Adding the list(fieldnames) behavior could be done without a backwards 
compatibility issue, but it does incur an overhead that would be paid by all 
existing working code.

--
nosy: +rhettinger
type:  -> enhancement
versions:  -Python 3.4, Python 3.5, Python 3.6, Python 3.8

___
Python tracker 

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

[issue29708] support reproducible Python builds

[Eli Schwartz]

Eli Schwartz  added the comment:

So, a couple of things.

It seems to me, that properly supporting SOURCE_DATE_EPOCH means using exactly 
that and nothing else. To that end, I'm not entirely sure why things like 
--clamp-mtime even exist, as the original timestamp of a source file doesn't 
seem to have a lot of utility and it is better to be entirely predictable. But 
I'm not going to argue that, except insomuch as it seems IMHO to fit better for 
python to just keep things simple and override the timestamp with the value of 
SOURCE_DATE_EPOCH

That being said, I see two problems with python implementing something 
analogous to --clamp-mtime rather than just --mtime.


1) Source files are extracted by some build process, and remain untouched. 
Python generates bytecode pinned to the original time, rather than 
SOURCE_DATE_EPOCH. Later, the build process packages those files and implements 
--mtime, not --clamp-mtime. Because Python and the packaging software disagree 
about which one to use, the bytecode fails.

2) Source files are extracted, and the build process even tosses all timestamps 
to the side of the road, by explicitly `touch`ing all of them to the date of 
SOURCE_DATE_EPOCH just in case. Then for whatever reason (distro patches, 2to3, 
the use of `cp`) the timestamps get updated to $currentime. But 
SOURCE_DATE_EPOCH is in the future, so the timestamps get downdated. Python 
bytecode is generated by emulating --clamp-mtime. The build process then uses 
--mtime to package the files. Again, because Python and the packaging software 
disagree about which one to use, the bytecode fails.

Of course, in both those cases, blindly respecting SOURCE_DATE_EPOCH will 
seemingly break everything for people who use --clamp-mtime instead. I'm not 
happy with reproducible-builds.org for allowing either one.

I don't think python should rely on --mtime users manually overriding the 
filesystem metadata of the source files outside of py_compile, as that is a 
hack that I think we'd like to remove if possible... that being said, Arch 
Linux will, on second thought, not be adversely affected even if py_compile 
tries to be clever and emulate --clamp-mtime to decide on its own whether to 
respect SOURCE_DATE_EPOCH.

Likewise, I don't really expect people to try to reproduce builds using a 
future date for SOURCE_DATE_EPOCH. On the other hand, the reproducible builds 
spec doesn't forbid it AFAICT.

But... neither of those mitigations seem "clean" to me, for the reasons stated 
above.

There is something that would solve all these issues, though. From reading the 
importlib code (I haven't actually tried smoketesting actual imports), it 
appears that Python 2 accepts any bytecode that is dated at or later than the 
timestamp of its source .py, while Python 3 requires the timestamps to 
perfectly match. This seems bizarre to behave differently, especially as until 
@bmwiedemann mentioned it on the GitHub PR I blindly assumed that Python would 
not care if your bytecode is somehow dated later than your sources. If the user 
is playing monkey games with mismatched source and byte code, while backdating 
the source code to *trick* the interpreter into loading it... let them? They 
can break their stuff if they want to!

On looking through the commit logs, it seems that Python 3 used to do the same, 
until 
https://github.com/python/cpython/commit/61b14251d3a653548f70350acb250cf23b696372
 refactored the general vicinity and modified this behavior without warning. In 
a commit that seems to be designed to do something else entirely. This really 
should have been two separate commits, and modifying the import code to more 
strictly check the timestamp should have come with an explanatory 
justification. Because I cannot think of a good reason for this behavior, and 
the commit isn't giving me an opportunity to understand either. As it is, I am 
completely confused, and have no idea whether this was even supposed to be 
deliberate.
In hindsight it is certainly preventing nice solutions to supporting 
SOURCE_DATE_EPOCH.

--
nosy: +eschwartz

___
Python tracker 

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

[issue32547] csv.DictWriter emits strange errors if fieldnames is an iterator

[Ben Cummings]

New submission from Ben Cummings :

If I pass an iterator to csv.DictWriter as the fieldname field, then DictWriter 
consumes that iterator pretty quickly, emitting strange errors such as the 
following when trying to write the headers.

>>> import csv
>>> fields = iter(["a", "b", "c", "d"])
>>> f = open('test.csv', 'w')
>>> writer = csv.DictWriter(f, fieldnames=fields)
>>> writer.writeheader()
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3.4/csv.py", line 142, in writeheader
self.writerow(header)
  File "/usr/lib/python3.4/csv.py", line 153, in writerow
return self.writer.writerow(self._dict_to_list(rowdict))
  File "/usr/lib/python3.4/csv.py", line 149, in _dict_to_list
+ ", ".join([repr(x) for x in wrong_fields]))
ValueError: dict contains fields not in fieldnames: 'c', 'a'

This is because writeheader and _dict_to_list repeatedly iterate over 
self.fieldnames. It seems like this could be solved by making a list of 
fieldnames in the constructor.

--
components: Library (Lib)
messages: 309904
nosy: bendotc
priority: normal
severity: normal
status: open
title: csv.DictWriter emits strange errors if fieldnames is an iterator
versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8

___
Python tracker 

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

[issue21592] Make statistics.median run in linear time

[Roundup Robot]

Change by Roundup Robot :


--
keywords: +patch
pull_requests: +5029
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

[issue28879] smtplib send_message should add Date header if it is missing, per RFC5322

[Eric Lafontaine]

Change by Eric Lafontaine :


--
pull_requests: +5028

___
Python tracker 

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

[issue32546] Unusual TypeError with dataclass decorator

[Eric V. Smith]

Eric V. Smith  added the comment:

Thanks.

I'm going to be changing the errors as part of #32513, but I'll make sure to 
cover this case better.

--

___
Python tracker 

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

[issue32546] Unusual TypeError with dataclass decorator

[Raymond Hettinger]

Raymond Hettinger  added the comment:

I think the error message here can be improved to explain why is being raised.  
Otherwise the cause isn't self-evident.

--

___
Python tracker 

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

[issue32546] Unusual TypeError with dataclass decorator

[Raymond Hettinger]

New submission from Raymond Hettinger :

The following code (simplified from a real example) triggers an unexpected 
TypeError:

@dataclass
class PrioritizedItem:
priority: 'int'
def __eq__(self, other):
return self.priority == other.priority

This code gives the following trackback:

Traceback (most recent call last):
  File "/Users/raymond/Documents/tmp16.py", line 16, in 
@dataclass
  File 
"/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/dataclasses.py",
 line 598, in dataclass
return wrap(_cls)
  File 
"/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/dataclasses.py",
 line 590, in wrap
return _process_class(cls, repr, eq, order, hash, init, frozen)
  File 
"/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/dataclasses.py",
 line 539, in _process_class
_set_attribute(cls, '__hash__', None)
  File 
"/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/dataclasses.py",
 line 444, in _set_attribute
raise TypeError(f'Cannot overwrite attribute {name} '
TypeError: Cannot overwrite attribute __hash__ in PrioritizedItem

--
assignee: eric.smith
components: Library (Lib)
files: data_class_type_error.py
messages: 309901
nosy: eric.smith, rhettinger
priority: normal
severity: normal
status: open
title: Unusual TypeError with dataclass decorator
type: behavior
versions: Python 3.7
Added file: https://bugs.python.org/file47384/data_class_type_error.py

___
Python tracker 

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

[issue29476] Simplify set_add_entry()

[Raymond Hettinger]

Change by Raymond Hettinger :


Added file: https://bugs.python.org/file47383/inner_loop_analysis.s

___
Python tracker 

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

[issue32516] Add a shared library mechanism for win32

[Steve Dower]

Steve Dower  added the comment:

How is this an improvement over loading the DLL explicitly? Even if subpackages 
require the file, your top level __init__.py will run before they are loaded 
and it can import a pyd that's known to be next to the file or it can 
LoadLibrary the contents of .libs itself.

Modifying the search path is not entirely robust, as you know, but once a DLL 
is loaded it doesn't need to be on the path to be found.

--

___
Python tracker 

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

[issue32545] Unable to install Python 3.7.0a4 on Windows 10 - Error 0x80070643: Failed to install MSI package.

[Matt Ripley]

New submission from Matt Ripley :

When I try to use any of the installers downloaded from the website I get the 
errors 2203 and 0x80070643:

[2468:1D2C][2018-01-13T20:15:51]e000: Error 0x80070643: Failed to install MSI 
package.
[2468:1D2C][2018-01-13T20:15:51]e000: Error 0x80070643: Failed to configure 
per-user MSI package.
[2468:1D2C][2018-01-13T20:15:51]i319: Applied execute package: core_JustForMe, 
result: 0x80070643, restart: None
[2468:1D2C][2018-01-13T20:15:51]e000: Error 0x80070643: Failed to execute MSI 
package.

Been looking all over the reported issues but nothing has helped me with this 
one. Other installers work without issue?

--
components: Installation
files: Python 3.7.0a4 (64-bit)_20180113201542_000_core_JustForMe.log
messages: 309899
nosy: mwr256
priority: normal
severity: normal
status: open
title: Unable to install Python 3.7.0a4 on Windows 10 - Error 0x80070643: 
Failed to install MSI package.
type: behavior
versions: Python 3.7
Added file: https://bugs.python.org/file47382/Python 3.7.0a4 
(64-bit)_20180113201542_000_core_JustForMe.log

___
Python tracker 

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

[issue32545] Unable to install Python 3.7.0a4 on Windows 10 - Error 0x80070643: Failed to install MSI package.

[Ned Deily]

Change by Ned Deily :


--
components: +Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware

___
Python tracker 

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

[issue31368] RWF_NONBLOCK

[YoSTEALTH]

YoSTEALTH  added the comment:

preadv2(2) syscall with RWF_NONBLOCK feature is now released starting linux4.14
https://kernelnewbies.org/Linux_4.14#Asynchronous_buffered_I.2FO_support

--

___
Python tracker 

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

[issue29476] Simplify set_add_entry()

[Raymond Hettinger]

Raymond Hettinger  added the comment:

What I've decided for now is to keep the freeslot reuse logic but in a simpler 
form. Currently there are two optimizations for rare cases.  The first is 
reusing a dummy entry -- we'll keep that.  And the second is detecting multiple 
dummies in a lookup chain and prefering the first in the chain -- I'm going to 
get rid of this I haven't found any plausible case where it demonstrates value 
in excess of its cost.

For it to trigger, the set has to have had a growth phase, then a number of 
subsequent deletions, and then later additions that have multiple collisions 
with dummy entries, all without any intervening resizes.  Modern sets have a 
lower fill factor, making this situation even less likely.  Also, modern sets 
use a series of linear probes making collisions much cheaper.  The benefit is 
so small and so rare, it possible that the cost of the inner-loop test now 
exceeds its potential benefit.  Given that the optimization is of questionable 
worth, I choose to remove it, preferring the simpler inner-loop code.

--

___
Python tracker 

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

[issue29476] Simplify set_add_entry()

[Raymond Hettinger]

Change by Raymond Hettinger :


--
pull_requests: +5027
stage:  -> patch review

___
Python tracker 

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

[issue32516] Add a shared library mechanism for win32

[Antoine Pitrou]

Change by Antoine Pitrou :


--
nosy: +paul.moore, steve.dower, tim.golden, zach.ware

___
Python tracker 

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

[issue32516] Add a shared library mechanism for win32

[Antoine Pitrou]

Change by Antoine Pitrou :


--
nosy: +Ray Donnelly

___
Python tracker 

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

[issue32544] Speed up hasattr(o, name) and getattr(o, name, default)

[INADA Naoki]

Change by INADA Naoki :


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

___
Python tracker 

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

[issue32544] Speed up hasattr(o, name) and getattr(o, name, default)

[INADA Naoki]

New submission from INADA Naoki :

ABCMeta.__new__ calls `getattr(value, "__isabstractmethod__", False)` many 
times.
https://github.com/python/cpython/blob/0f31c74fcfdec8f9e6157de2c366f2273de81677/Lib/abc.py#L135-L142

Since metaclass is used by subclasses, it checks all members of all subclasses 
(including concrete class).

But getattr() and hasattr() is inefficient when attribution is not found,
because it raises AttributeError and clear it internally.

I tried to bypass AttributeError when tp_getattro == PyObject_GenericGetAttr.
Here is quick micro benchmark:

$ ./python-patched -m perf timeit --compare-to=`pwd`/python-master -s 'def 
foo(): pass' 'hasattr(foo, "__isabstractmethod__")'python-master: 
. 385 ns +- 2 ns
python-patched: . 87.6 ns +- 1.6 ns

Mean +- std dev: [python-master] 385 ns +- 2 ns -> [python-patched] 87.6 ns +- 
1.6 ns: 4.40x faster (-77%)

(I added Ivan to nosy list because he may implement C version of ABC.)

--
messages: 309896
nosy: inada.naoki, levkivskyi
priority: normal
severity: normal
status: open
title: Speed up hasattr(o, name) and getattr(o, name, default)

___
Python tracker 

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

[issue32516] Add a shared library mechanism for win32

[Barry A. Warsaw]

Change 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

[issue31310] semaphore tracker isn't protected against crashes

[Thomas Moreau]

Thomas Moreau  added the comment:

> Is it an optimization problem, or does it risk leaking semaphores?

I do not think it risks leaking semaphores as the clean-up is performed by the 
process which created the Semaphore. So I would say it is more an optimization 
issue.

It is true that I do not see many use case where the Semaphore might be created 
by the child process but it was optimized in previous version. If you don't 
think it is useful, we could avoid sharing the semaphore_tracker pipe to the 
child process to reduce complexity in the spawning process. Do you think it is 
worth fixing or it should be simplified?

--

___
Python tracker 

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

[issue32528] Change base class for futures.CancelledError

[Joongi Kim]

Joongi Kim  added the comment:

I strongly agree to have discretion of CancelledError and other general 
exceptions, though I don't have concrete ideas on good unobtrusive ways to 
achieve this.

If I write my codes carefully I could control most of cancellation explicitly, 
but it is still hard to control it in 3rd-party libraries that I depend on. 
Often they just raise random errors, or CancelledError is swallowed.

Also it would be nice to have some documentation and examples on how to write 
"cancellation-friendly" coroutine codes.

--

___
Python tracker 

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

[issue31310] semaphore tracker isn't protected against crashes

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> Thus, as the _pid argument is None in the new process, it launches a new 
> tracker if it needs to create a new Semaphore

I see.  Is it an optimization problem, or does it risk leaking semaphores?  The 
problem is if a semaphore shared with the child isn't garbage collected 
correctly.

--

___
Python tracker 

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

[issue32346] Speed up slot lookup for class creation

[Antoine Pitrou]

Antoine Pitrou  added the comment:

I think that Inada is right: there's too much impact on memory consumption and 
garbage collection to call this an optimization.

Serhiy suggested removing the cache.  But, once you remove the cache, you're 
going to iterate on all values of all parent classes' dicts to find which 
values are __dunder__ methods.  This risks being much more expensive for 
classes with tens or hundreds of namespace entries, making the optimization 
even less interesting.

So in the end I think I'm going to reject this issue.

--
resolution:  -> rejected
stage: patch review -> resolved
status: open -> pending

___
Python tracker 

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

[issue29209] Remove old-deprecated ElementTree features

[Stefan Behnel]

Stefan Behnel  added the comment:

Patch looks right to me.

I'd personally be ok with applying it to 3.7, but I'll leave the decision to 
you. Most of the removed "features" are non-controversial, except:

- "getchildren()" is probably still in use, also because it's more efficient 
than "list(elem)" in lxml (and has never been deprecated there), so code that 
supports both libraries might have preferred it

- cElementTree is probably still imported by quite a bit of code

So, this will have an impact on user code, despite any previous deprecation 
warnings. But it's easy to resolve in a backwards compatible way.

--

___
Python tracker 

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

[issue31310] semaphore tracker isn't protected against crashes

[Thomas Moreau]

Thomas Moreau  added the comment:

For new processes created with spawn or forkserver, only the 
semaphore_tracker._fd is send and shared to the child. Thus, as the _pid 
argument is None in the new process, it launches a new tracker if it needs to 
create a new Semaphore, regardless of crashes in the previous semaphore tracker.

--

___
Python tracker 

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

[issue31310] semaphore tracker isn't protected against crashes

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> With this fix, the semaphore_tracker is not shared with the children anymore 
> and each process launches its own tracker.

That's only if the semaphore tracker process crashes, right?

--

___
Python tracker 

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

[issue31310] semaphore tracker isn't protected against crashes

[Thomas Moreau]

Thomas Moreau  added the comment:

With this fix, the semaphore_tracker is not shared with the children anymore 
and each process launches its own tracker.

I opened a PR to try to fix it. Let me know if I should open a new ticket.

--
nosy: +tomMoral

___
Python tracker 

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

[issue31310] semaphore tracker isn't protected against crashes

[Thomas Moreau]

Change by Thomas Moreau :


--
pull_requests: +5025

___
Python tracker 

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