[issue32852] trace changes sys.argv from list to tuple

[miss-islington]

miss-islington  added the comment:


New changeset dda938683c48197ab7e775144136f433a5d43103 by Miss Islington (bot) 
in branch '3.6':
bpo-32852: Fix trace changing sys.argv to tuple. (GH-5692)
https://github.com/python/cpython/commit/dda938683c48197ab7e775144136f433a5d43103


--

___
Python tracker 

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

[issue32852] trace changes sys.argv from list to tuple

[miss-islington]

miss-islington  added the comment:


New changeset afb5e5583694798793d44f35f901aa912ece278a by Miss Islington (bot) 
in branch '3.7':
bpo-32852: Fix trace changing sys.argv to tuple. (GH-5692)
https://github.com/python/cpython/commit/afb5e5583694798793d44f35f901aa912ece278a


--
nosy: +miss-islington

___
Python tracker 

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

[issue32852] trace changes sys.argv from list to tuple

[miss-islington]

Change by miss-islington :


--
pull_requests: +5507

___
Python tracker 

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

[issue32852] trace changes sys.argv from list to tuple

[miss-islington]

Change by miss-islington :


--
pull_requests: +5506

___
Python tracker 

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

[issue32852] trace changes sys.argv from list to tuple

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:


New changeset 9f4223261fd129ad7b9a09b2b0d625d1bb90b22b by Serhiy Storchaka 
(Kyle Altendorf) in branch 'master':
bpo-32852: Fix trace changing sys.argv to tuple. (GH-5692)
https://github.com/python/cpython/commit/9f4223261fd129ad7b9a09b2b0d625d1bb90b22b


--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue32860] Definition of iglob does not mention single star (unlike glob)

[miss-islington]

miss-islington  added the comment:


New changeset 76591bc03a26e8fde143c25cb88a98f1c96f8bc2 by Miss Islington (bot) 
in branch '3.6':
bpo-32860: Fix a missing asterisk in the documentation for glob.iglob() 
(GH-5712)
https://github.com/python/cpython/commit/76591bc03a26e8fde143c25cb88a98f1c96f8bc2


--

___
Python tracker 

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

[issue32860] Definition of iglob does not mention single star (unlike glob)

[miss-islington]

miss-islington  added the comment:


New changeset 0f764110593b337161e9321671dc13b54ca0cf95 by Miss Islington (bot) 
in branch '3.7':
bpo-32860: Fix a missing asterisk in the documentation for glob.iglob() 
(GH-5712)
https://github.com/python/cpython/commit/0f764110593b337161e9321671dc13b54ca0cf95


--
nosy: +miss-islington

___
Python tracker 

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

[issue32860] Definition of iglob does not mention single star (unlike glob)

[Mariatta Wijaya]

Mariatta Wijaya  added the comment:

Thanks!

--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +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

[issue32860] Definition of iglob does not mention single star (unlike glob)

[miss-islington]

Change by miss-islington :


--
pull_requests: +5505

___
Python tracker 

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

[issue32860] Definition of iglob does not mention single star (unlike glob)

[miss-islington]

Change by miss-islington :


--
pull_requests: +5504

___
Python tracker 

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

[issue32860] Definition of iglob does not mention single star (unlike glob)

[Mariatta Wijaya]

Mariatta Wijaya  added the comment:


New changeset 6887d86e9a04b9c5718b08e5d9e1ca3cc1f53721 by Mariatta (Zackery 
Spytz) in branch 'master':
bpo-32860: Fix a missing asterisk in the documentation for glob.iglob() 
(GH-5712)
https://github.com/python/cpython/commit/6887d86e9a04b9c5718b08e5d9e1ca3cc1f53721


--
nosy: +Mariatta

___
Python tracker 

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

[issue32862] os.dup2(fd, fd, inheritable=False) behaves inconsistently

[Alexey Izbyshev]

Change by Alexey Izbyshev :


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

___
Python tracker 

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

[issue32862] os.dup2(fd, fd, inheritable=False) behaves inconsistently

[Alexey Izbyshev]

New submission from Alexey Izbyshev :

os.dup2(fd, fd, inheritable=False) may fail or change fd inheritability in 
following ways:

1) POSIX without F_DUP2FD_CLOEXEC
1.1) dup3() is available (a common case for Linux): OSError (EINVAL, dup3() 
doesn't allow equal descriptors)
1.2) dup3() is not available: fd made non-inheritable

2) POSIX with F_DUP2FD_CLOEXEC (FreeBSD): inheritability is not changed

3) Windows: fd made non-inheritable

In contrast, os.dup2(fd, fd, inheritable=True) never changes fd inheritability 
(same as before PEP 446 landed). I suggest to make os.dup2(fd, fd, 
inheritable=False) behave the same.

--
components: Extension Modules, Library (Lib)
messages: 312266
nosy: benjamin.peterson, izbyshev, vstinner
priority: normal
severity: normal
status: open
title: os.dup2(fd, fd, inheritable=False) behaves inconsistently
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

[issue32846] Deletion of large sets of strings is extra slow

[INADA Naoki]

INADA Naoki  added the comment:

> Dict is (surprisingly) little smaller than set.

I'm sorry, I was wrong.
dict is smaller than set only when len(d) is small. (typical case for namespace 
dict)

In case of massive keys, dict is larger than set.

--

___
Python tracker 

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

[issue32846] Deletion of large sets of strings is extra slow

[INADA Naoki]

INADA Naoki  added the comment:

One possible advice; try dict instead of set.
Dict is (surprisingly) little smaller than set.
And dict cleans items in insertion order when the dict is deleted.

--

___
Python tracker 

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

[issue32860] Definition of iglob does not mention single star (unlike glob)

[Zackery Spytz]

Change by Zackery Spytz :


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

___
Python tracker 

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

[issue32846] Deletion of large sets of strings is extra slow

[Tim Peters]

Tim Peters  added the comment:

> Surprisingly, deleting a very large set takes much longer than creating it.

Luis, that's not surprising ;-)  When you create it, it's mostly the case that 
there's a vast chunk of raw memory from which many pieces are passed out in 
address order (to hold all the newly created Python objects).  Memory access is 
thus mostly sequential.  But when you delete it, that vast chunk of once-raw 
memory is visited in essentially random order (string hashes impose a 
pseudo-random order on where (pointers to) string objects are stored within a 
set's vector), defeating all the hardware features that greatly benefit from 
sequential access.

More precisely, the set's internal vector is visited sequentially during 
deletion, but the string objects the pointers point _at_ are all over the 
place.  Even if nothing is swapped to disk, it's likely that visiting a string 
object during deletion will miss on all cache levels, falling back to (much 
slower) RAM.  Note that all the string objects must be visited during set 
deletion, in order to decrement their reference counts.

--

___
Python tracker 

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

[issue32604] Expose the subinterpreters C-API in Python for testing use.

[Eric Snow]

Eric Snow  added the comment:


New changeset 3db05a3a9c109f49d54b4965852e41c657e9b117 by Eric Snow (Miss 
Islington (bot)) in branch '3.7':
bpo-32604: Clean up created subinterpreters before runtime finalization. 
(gh-5710)
https://github.com/python/cpython/commit/3db05a3a9c109f49d54b4965852e41c657e9b117


--

___
Python tracker 

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

[issue32861] urllib.robotparser: incomplete __str__ methods

[Michael Lazar]

Change by Michael Lazar :


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

___
Python tracker 

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

[issue32604] Expose the subinterpreters C-API in Python for testing use.

[miss-islington]

Change by miss-islington :


--
pull_requests: +5499

___
Python tracker 

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

[issue32604] Expose the subinterpreters C-API in Python for testing use.

[Eric Snow]

Eric Snow  added the comment:


New changeset 4c6955e2b0ccf88c705f8d1fac685a8e65f9699e by Eric Snow in branch 
'master':
bpo-32604: Clean up created subinterpreters before runtime finalization. 
(gh-5709)
https://github.com/python/cpython/commit/4c6955e2b0ccf88c705f8d1fac685a8e65f9699e


--

___
Python tracker 

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

[issue32861] urllib.robotparser: incomplete __str__ methods

[Michael Lazar]

New submission from Michael Lazar :

Hello,

I have stumbled upon a couple of inconsistencies in urllib.robotparser's 
__str__ methods.

These appear to be unintentional omissions; basically the code was modified but 
the string methods were never updated.

1. The RobotFileParser.__str__ method doesn't include the default (*) 
User-agent entry.

>>> from urllib.robotparser import RobotFileParser
>>> parser = RobotFileParser()
>>> text = """
... User-agent: *
... Allow: /some/path
... Disallow: /another/path
...
... User-agent: Googlebot
... Allow: /folder1/myfile.html
... """
>>> parser.parse(text.splitlines())
>>> print(parser)
User-agent: Googlebot
Allow: /folder1/myfile.html


>>>

This is *especially* awkward when parsing a valid robots.txt that only contains 
a wildcard User-agent.

>>> from urllib.robotparser import RobotFileParser
>>> parser = RobotFileParser()
>>> text = """
... User-agent: *
... Allow: /some/path
... Disallow: /another/path
... """
>>> parser.parse(text.splitlines())
>>> print(parser)


>>>


2. Support was recently added for `Crawl-delay` and `Request-Rate` lines, but 
__str__ does not include these.

>>> from urllib.robotparser import RobotFileParser
>>> parser = RobotFileParser()
>>> text = """
... User-agent: figtree
... Crawl-delay: 3
... Request-rate: 9/30
... Disallow: /tmp
... """
>>> parser.parse(text.splitlines())
>>> print(parser)
User-agent: figtree
Disallow: /tmp


>>>

3. Two unnecessary trailing newlines are being appended to the string output 
(one for the last RuleLine and one for the last Entry)

(see above examples)


Taken on their own these are all minor issues, but they do make things quite 
confusing when using robotparser from the REPL!

--
components: Library (Lib)
messages: 312259
nosy: michael-lazar
priority: normal
severity: normal
status: open
title: urllib.robotparser: incomplete __str__ methods
type: behavior
versions: Python 3.8

___
Python tracker 

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

[issue32860] Definition of iglob does not mention single star (unlike glob)

[Roger Erens]

New submission from Roger Erens :

Although both glob and iglob have the same arity in Lib/glob.py:

def glob(pathname, *, recursive=False)

def iglob(pathname, *, recursive=False):

the documentation only mentions for glob the single star
https://docs.python.org/3/library/glob.html#glob.iglob:

glob.glob(pathname, *, recursive=False)

glob.iglob(pathname, recursive=False)

--
assignee: docs@python
components: Documentation
messages: 312258
nosy: Roger Erens, docs@python
priority: normal
severity: normal
status: open
title: Definition of iglob does not mention single star (unlike glob)

___
Python tracker 

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

[issue22167] iglob() has misleading documentation (does indeed store names internally)

[Roger Erens]

Roger Erens  added the comment:

http://bugs.python.org/issue25596 has been closed...

--
nosy: +Roger Erens

___
Python tracker 

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

[issue32604] Expose the subinterpreters C-API in Python for testing use.

[Eric Snow]

Change by Eric Snow :


--
pull_requests: +5498

___
Python tracker 

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

[issue32859] os.dup2() tests dup3() availability on each call

[Alexey Izbyshev]

Change by Alexey Izbyshev :


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

___
Python tracker 

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

[issue32859] os.dup2() tests dup3() availability on each call

[Alexey Izbyshev]

New submission from Alexey Izbyshev :

os.dup2() tests for dup3() system call availability at runtime, but doesn't 
remember the result across calls, repeating the test on each call with 
inheritable=False even if the test fails.

Judging by the code, 'dup3_works' was intended to be static (the first time its 
value is checked it's always an initial one).

--
components: Extension Modules, Library (Lib)
messages: 312256
nosy: benjamin.peterson, izbyshev, vstinner
priority: normal
severity: normal
status: open
title: os.dup2() tests dup3() availability on each call
type: performance
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

[issue17050] argparse.REMAINDER doesn't work as first argument

[paul j3]

paul j3  added the comment:

A REMAINDER that would work with a flag-like string would be too powerful, too 
greedy.

In [64]: p = argparse.ArgumentParser();
In [65]: p.add_argument('--foo');
In [66]: p.add_argument('rest', nargs='...');

If the flag is first, its Action works:

In [67]: p.parse_args('--foo x a b c'.split())
Out[67]: Namespace(foo='x', rest=['a', 'b', 'c'])

If there's a non-flag string, REMAINDER grabs everything:

In [68]: p.parse_args('d --foo x a b c'.split())
Out[68]: Namespace(foo=None, rest=['d', '--foo', 'x', 'a', 'b', 'c'])

Imagine a REMAINDER could act with '--foo' as the first string.  In[67] would 
then parse as Out[68] but without the 'd'.  

In documented use 'cmd' acts as a gatekeeper, allowing the REMAINDER to grab 
the rest.  So does the '--rest' flag in:

 p.add_argument('--rest', nargs='...')

Double dash is another gatekeeper:

In [69]: p.parse_args('-- --foo x a b c'.split())
Out[69]: Namespace(foo=None, rest=['--', '--foo', 'x', 'a', 'b', 'c'])

If you don't want such a gatekeeper, why used argparse at all?  Why not use 
sys.argv[1:] directly?

So some sort of warning about the limitations of REMAINDER would be good.  But 
the trick is to come up with something that is clear but succinct. The argparse 
documentation is already daunting to beginners.  

A closed request to document the argparse.PARSER option:
https://bugs.python.org/issue16988

A closed request to document '...'
https://bugs.python.org/issue24647

There was also an issue asking to treat unrecognized flags as plain arguments.  
I don't recall the status of that issue.  With that, REMAINDER could grab 
'--bar a b c', but 'fail' with '--foo a b c'.  It would interesting to test 
such a variation, but that would be even harder to document.

--

___
Python tracker 

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

[issue32858] Improve OpenSSL ECDH support

[sruester]

Change by sruester :


--
pull_requests: +5495

___
Python tracker 

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

[issue32829] Lib/ be more pythonic

[Terry J. Reedy]

Terry J. Reedy  added the comment:

Dilyan, please explain what you believe the problems to be and how the patch 
solves it.  These seem to be 3 separate issues.

Do not change idlelib.config.  config_main.def contain 'default = True' or 
'default = False' and that is what the docstring references.

--
nosy: +terry.reedy

___
Python tracker 

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

[issue32852] trace changes sys.argv from list to tuple

[Kyle Altendorf]

Change by Kyle Altendorf :


--
pull_requests: +5494

___
Python tracker 

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

[issue32852] trace changes sys.argv from list to tuple

[Kyle Altendorf]

Change by Kyle Altendorf :


--
pull_requests: +5493

___
Python tracker 

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

[issue32825] warn user of creation of multiple Tk instances

[Terry J. Reedy]

Change by Terry J. Reedy :


--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue32854] Add ** Map Unpacking Support for namedtuple

[Jay Crotts]

Jay Crotts  added the comment:

Would it be worth adding an example of unpacking such as, t(**a._asdict()), or 
something similar to the documentation ?

--
nosy: +jcrotts

___
Python tracker 

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

[issue32852] trace changes sys.argv from list to tuple

[Kyle Altendorf]

Change by Kyle Altendorf :


--
pull_requests: +5492

___
Python tracker 

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

[issue32852] trace changes sys.argv from list to tuple

[Kyle Altendorf]

Change by Kyle Altendorf :


--
pull_requests: +5491

___
Python tracker 

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

[issue32495] Adding Timer to multiprocessing

[Jay Crotts]

Jay Crotts  added the comment:

Closing this issue, for the reasons Antoine outlined.

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

[issue32852] trace changes sys.argv from list to tuple

[Kyle Altendorf]

Change by Kyle Altendorf :


--
versions: +Python 3.8

___
Python tracker 

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

[issue32846] Deletion of large sets of strings is extra slow

[Terry J. Reedy]

Terry J. Reedy  added the comment:

Luís, what you really need for the problem you outline is an immutable set with 
one operation, 'in', aside from create and delete.  If specialized to strings 
only, it could internally stores only character sequences, rather than Python 
objects.  I suspect someone has written such a class (in C), but did not find 
anything on pypi.python.org.

Lacking that, the following experiment suggests that you might be able to 
restore near O(n) time by partitioning the set of keys into a collection of 
sets.  My 16M set took 6.48 and 1.80 seconds.  Times 4 is 25.9 and 7.2.  My 64M 
set took 28 and 19 seconds, but 4 16M sets take 26.3 and 7.5 seconds, only 
about 5% more than the x4 target.

print(timeit.Timer(
's = [{str(n) for n in range(i*100, (i+16)*100)}'
' for i in (0, 16, 32, 48)]')
  .timeit(number=1))
print(timeit.Timer(
'del s',
's = [{str(n) for n in range(i*100, (i+16)*100)}'
' for i in (0, 16, 32, 48)]')
  .timeit(number=1))

--

___
Python tracker 

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

[issue32857] tkinter after_cancel does not behave correctly when called with id=None

[Cheryl Sabella]

Change by Cheryl Sabella :


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

[issue32846] Deletion of large sets of strings is extra slow

[Raymond Hettinger]

Raymond Hettinger  added the comment:

Thanks for the info.  Here is what I surmise from the data.  

* The shape of the curve matches the expected memory latency curve for random 
memory accesses for a given working set size.  The graph of your measurements 
looks similar in shape to this one:  
https://www.extremetech.com/wp-content/uploads/2014/08/latency.png

*  The last line of the measurements has N=1,500,000,000.   That would give an 
approx 70GB setobject that refers to another 100Gb (or more) of strings.  
Unless you are working with an extraordinary machine, most of that data will 
have been swapped to disk.

* Dividing the 1,500,000,000 elements by the time of 25,068 seconds gives about 
60,000 deletions per second.  This number coincides nicely with the random 
access performance of a typical SSD rated at  50,000 IOPs.

If this reasoning is sound, all it proves is that random accesses to virtual 
memory are limited by the speed of the hardware for that virtual memory.

--

___
Python tracker 

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

[issue32858] Improve OpenSSL ECDH support

[sruester]

sruester  added the comment:

I'd really love to see kxinfo() or a similar method in the standard. I chose to 
implement it similar to cipher() which seemed to be a good idea then. If there 
are any objections, please let's discuss how that information can be made 
available otherwise.
If that's ok, I will open another pull request which only contains kxinfo or 
similar. It is, however, not sufficient without set_ecdh_curve's support for 
X25519 in some cases (my case ^^).

Changing the implementation of set_ecdh_curve seems necessary anyway, as it 
does not support X25519 at all, and it does not allow defining multiple curves.

Maybe we can do both, update PEP 543 to address the needs and implement it (in 
an OpenSSL centric way) for the current version.

--

___
Python tracker 

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

[issue32856] Optimize the `for y in [x]` idiom in comprehensions

[Yury Selivanov]

Yury Selivanov  added the comment:

I'm still not sure whether we should enable this optimization or not.

I haven't ever seen this pattern used in any Python code I worked with, so I 
suspect it's quite a rare hack.  Giving it a fast-path would give this pattern 
extra visibility and might encourage people to use it.

And the pattern itself... Well, it's quite ugly and barely readable.  IMO it's 
way better to simply rewrite such comprehension to an equivalent 'for' 
statement.

So I guess I'm -0 on this change.  I suggest to ask Guido on the mailing list 
if he agrees that this language patten is worth optimizing/promoting.

--

___
Python tracker 

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

[issue32856] Optimize the `for y in [x]` idiom in comprehensions

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Here are some microbenchmarks. But since this code always is a part of complex 
expression it may be not make sense to talk about its pure speed.

$ ./python -m timeit -s 'a = list(range(1000))' -- '[y for x in a for y in [x]]'
Unpatched:  5000 loops, best of 5: 81.4 usec per loop
Patched:   1 loops, best of 5: 19.8 usec per loop

For comparison the variant without temporary variable:

$ ./python -m timeit -s 'a = list(range(1000))' -- '[x for x in a]'
2 loops, best of 5: 15.6 usec per loop

The overhead of using temporary variable is decreased from 66 usec to 4.2 usec 
(by 16 times).

In more realistic examples the subexpression assigned to temporary variable is 
slow. Otherwise it would be not worth to use a temporary variable. Therefore 
the relative speed up of the whole comprehension expression caused by this 
optimization is much smaller.

--

___
Python tracker 

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

[issue32858] Improve OpenSSL ECDH support

[Christian Heimes]

Christian Heimes  added the comment:

Thanks!

I rejected your initial PR. In the past we added some cruft or badly designed 
features to the SSL module. I'm in the process of cleaning the module up. Any 
new feature or revised method should be designed carefully and added to PEP 
543. The PEP defines a general TLS API that is less OpenSSL centric.

The ssl module is and will stay a thin wrapper around OpenSSL. But we are 
trying to implement new features in a general, abstract way that work with 
other TLS implementations like SecureTransport, SChannel, or NSS.

--

___
Python tracker 

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

[issue32858] Improve OpenSSL ECDH support

[sruester]

sruester  added the comment:

Attached script shows usage

--
Added file: https://bugs.python.org/file47449/ssl-host-check.py

___
Python tracker 

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

[issue32858] Improve OpenSSL ECDH support

[sruester]

sruester  added the comment:

With OpenSSL 1.1.0g, the Code

 int nid = OBJ_sn2nid("X25519");
 EC_KEY *key = EC_KEY_new_by_curve_name(nid);
 printf("id:%i  key:%p\n", nid, key);

gives

 id:1034  key:(nil)

EC_KEY_new_by_curve_name is IMHO not the best option to define client side 
curves. It can only select a single curve to be offered to the server, and it 
does not (for whatever reason) support X25519 yet.
SSL_CTX_set1_curves_list() provides both, selection of multiple curves for the 
client's preference list and it supports X25519 out of the box.

Aside from this I am missing a method in SSLSocket to give me information about 
the key exchange (DH, ECDH, which curve was chosen, which bit size DH keys had, 
...).

I prepared a pull request which addresses both. Please review and be gentle, it 
is my first pull request here :-)

--

___
Python tracker 

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

[issue32436] Implement PEP 567

[miss-islington]

miss-islington  added the comment:


New changeset af6eaae306dce5095a350348432cc8595efc0211 by Miss Islington (bot) 
in branch '3.7':
bpo-32436: Add docs for contextvars (GH-5685)
https://github.com/python/cpython/commit/af6eaae306dce5095a350348432cc8595efc0211


--
nosy: +miss-islington

___
Python tracker 

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

[issue32858] Improve OpenSSL ECDH support

[sruester]

Change by sruester :


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

[issue32858] Improve OpenSSL ECDH support

[Christian Heimes]

Christian Heimes  added the comment:

When I replace the current implementation of SSLContext.set_ecdh_curve() with 
an implementation based on SSL_CTX_set1_curves_list(), then I'm able to 
configure X25519 curve for ECDH.

--

___
Python tracker 

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

[issue32436] Implement PEP 567

[Yury Selivanov]

Yury Selivanov  added the comment:

With the basic documentation committed, I'm now closing this issue.

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

[issue32436] Implement PEP 567

[Yury Selivanov]

Yury Selivanov  added the comment:


New changeset bd093355a6aaf2f4ca3ed153e195da57870a55eb by Yury Selivanov in 
branch 'master':
bpo-32436: Add docs for contextvars (#5685)
https://github.com/python/cpython/commit/bd093355a6aaf2f4ca3ed153e195da57870a55eb


--

___
Python tracker 

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

[issue32436] Implement PEP 567

[miss-islington]

Change by miss-islington :


--
pull_requests: +5488

___
Python tracker 

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

[issue32858] Improve OpenSSL ECDH support

[Christian Heimes]

Christian Heimes  added the comment:

Please elaborate, how did you test that the curve is not support? Python calls 
SSL_CTX_set_ecdh_auto(self->ctx, 1) to auto configure curves.


>>> import ssl
>>> ssl = ssl.SSLContext()
>>> ssl.set_ecdh_curve('X25519')
Traceback (most recent call last):
  File "", line 1, in 
ssl.SSLError: unknown group (_ssl.c:3954)

The error message means that EC_KEY_new_by_curve_name() does not support 
X25519's group.

Some notes:
* OpenSSL 1.0.2+ supports SSL_CTX_set1_curves_list() besides 
SSL_CTX_set_tmp_ecdh()
* OpenSSL has no API to get configured curves from a context.
* I'm not sure how useful SSL_get1_curves() and SSL_get_shared_curve() would be 
for a general audience. To reduce our maintenance burden, we only wrap 
functions that are useful or required.

--
assignee:  -> christian.heimes
components: +SSL -Library (Lib)
nosy: +alex, christian.heimes, dstufft, janssen
stage:  -> needs patch

___
Python tracker 

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

[issue32858] Improve OpenSSL ECDH support

[Stefan Rüster]

New submission from Stefan Rüster :

Tested with OpenSSL v1.1.0g, Python does not support selection of curve 
Curve25519 with _ssl.ctx.set_ecdh_curve("X25519").

Additionally the DH key exchange parameters (which curve has been chosen, what 
DH bit size was used) are not available through any SSL or Context method.

--
components: Library (Lib)
messages: 312237
nosy: Stefan Rüster
priority: normal
severity: normal
status: open
title: Improve OpenSSL ECDH support
type: enhancement
versions: Python 3.8

___
Python tracker 

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

[issue32846] Deletion of large sets of strings is extra slow

[Luís Pedro Coelho]

Luís Pedro Coelho  added the comment:

Original poster here.

The benchmark is artificial, but the problem setting is not. I did have a 
problem that is roughly:

interesting = set(line.strip() for line in open(...))
for line in open(...):
key,rest = line.split('\t', 1)
if key in interesting:
 process(rest)

Deleting the set (when it goes out of scope) was a significant chunk of the 
time. Surprisingly, deleting a very large set takes much longer than creating 
it.

Here are my controlled measurements (created with the attached script, which 
itself uses Jug http://jug.rtfd.io and assumes a file `input.txt` is present).


Ncreate (s) delete (s)
   1 0.00 0.00
  10 0.00 0.00
 100 0.00 0.00
1000 0.00 0.00
   1 0.01 0.00
  10 0.15 0.01
 100 1.14 0.12
100011.44 2.24
   1   126.4170.34
   2   198.04   258.44
   3   341.27   646.81
   4   522.70  1044.97
   5   564.07  1744.54
   6  1380.04  3364.06
   7  1797.82  3300.20
   8  1294.20  4410.22
   9  3045.38  7646.59
  10  3467.31 11042.97
  11  5162.35 13750.22
  12  6581.90 12544.67
  13  1612.60 17204.67
  14  1788.13 23772.84
  15  6922.16 25068.49

--
nosy: +l...@luispedro.org
Added file: https://bugs.python.org/file47448/time-set.py

___
Python tracker 

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

[issue29612] TarFile.extract() suffers from hard links inside tarball

[Larry Cook]

Larry Cook  added the comment:

I recently hit this with Python 2.7.5 and 2.7.13.  It has a very simple repro.  
Just specify the same file twice on the command line to tar (GNU 1.26):

% tar cvf test.tar test.txt test.txt
test.txt
test.txt

% tar tvf test.tar
-rw-r--r-- root/root24 2018-02-16 09:35 test.txt
hrw-r--r-- root/root 0 2018-02-16 09:35 test.txt link to test.txt

% python2.7
Python 2.7.5 (default, Aug  4 2017, 00:39:18) 
[GCC 4.8.5 20150623 (Red Hat 4.8.5-16)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import tarfile
>>> tarball = tarfile.open("test.tar")
>>> tarball.extractall()
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib64/python2.7/tarfile.py", line 2047, in extractall
self.extract(tarinfo, path)
  File "/usr/lib64/python2.7/tarfile.py", line 2084, in extract
self._extract_member(tarinfo, os.path.join(path, tarinfo.name))
  File "/usr/lib64/python2.7/tarfile.py", line 2168, in _extract_member
self.makelink(tarinfo, targetpath)
  File "/usr/lib64/python2.7/tarfile.py", line 2252, in makelink
os.link(tarinfo._link_target, targetpath)
OSError: [Errno 2] No such file or directory
>>>

--
nosy: +Larry Cook

___
Python tracker 

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

[issue32857] tkinter after_cancel does not behave correctly when called with id=None

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
stage:  -> needs patch
versions: +Python 2.7, 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

[issue32857] tkinter after_cancel does not behave correctly when called with id=None

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

I prefer the option 1. Even if calling after_cancel(None) would make sense, 
currently it silently does wrong things, and it is more errorproof to make it 
raising an exception.

--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue32857] tkinter after_cancel does not behave correctly when called with id=None

[Cheryl Sabella]

Cheryl Sabella  added the comment:

I can open a PR for this, but thought it might be best to discuss it first as 
far as what should happen with None.

1. Raise an error that it's an incorrect call.
2. Ignore it and just return.
3. Loop through all the events and after_cancel each one. 

Tcl allows the after_cancel call to be an id or script(s), but they don't have 
functionality that would cancel everything (unless all the `script` values were 
sent).

FWIW, if no parameters are sent, this is the Tcl code:
if (objc < 3) {
Tcl_WrongNumArgs(interp, 2, objv, "id|command");
return TCL_ERROR;
}

--

___
Python tracker 

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

[issue32839] Add after_info as a function to tkinter

[Cheryl Sabella]

Cheryl Sabella  added the comment:

I created issue32857 for the after_cancel issue.  Thanks!

--

___
Python tracker 

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

[issue32857] tkinter after_cancel does not behave correctly when called with id=None

[Cheryl Sabella]

New submission from Cheryl Sabella :

This was discovered while working on issue32839.  An old comment added for 
issue763637 resulted in further research and it was determined that the comment:

! data = self.tk.call('after', 'info', id)
! # In Tk 8.3, splitlist returns: (script, type)
! # In Tk 8.4, splitlist returns: (script,)

wasn't correct.  The underlying difference is that the call to 'after info' 
returns different results depending on the way it's called.  If it's called 
with an 'id', it will return a tuple of (script, type) if the id is valid or a 
TclError if the id isn't valid.  However, if id is None, then 'after info' 
returns a tuple of all the event ids for the widget.  In the case of the 
original bug in issue763637, the reported message shows the return value of 
`('after#53',)`, which is definitely an after event id and not a (script,) 
tuple.

Serhiy mentions on issue32839 that the current code also deletes the script for 
the first event if after_cancel is called with None.
https://bugs.python.org/issue32839#msg312199

--
components: Tkinter
messages: 312231
nosy: csabella
priority: normal
severity: normal
status: open
title: tkinter after_cancel does not behave correctly when called with id=None
type: behavior
versions: Python 3.8

___
Python tracker 

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

[issue26534] subprocess.check_output with shell=True ignores the timeout

[Fangyi Zhou]

Change by Fangyi Zhou :


--
nosy: +fangyizhou

___
Python tracker 

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

[issue5115] Extend subprocess.kill to be able to kill process groups

[Fangyi Zhou]

Change by Fangyi Zhou :


--
nosy: +fangyizhou

___
Python tracker 

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

[issue32856] Optimize the `for y in [x]` idiom in comprehensions

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

It is.

--

___
Python tracker 

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

[issue32856] Optimize the `for y in [x]` idiom in comprehensions

[Steven D'Aprano]

Steven D'Aprano  added the comment:

+1

Please also support using a one-element tuple:

`for y in (f(x),)`

--
nosy: +steven.daprano

___
Python tracker 

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

[issue32856] Optimize the `for y in [x]` idiom in comprehensions

[Serhiy Storchaka]

Change by Serhiy Storchaka :


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

___
Python tracker 

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

[issue32856] Optimize the `for y in [x]` idiom in comprehensions

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
keywords: +patch, patch
pull_requests: +5486, 5487
stage:  -> patch review

___
Python tracker 

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

[issue32856] Optimize the `for y in [x]` idiom in comprehensions

[Serhiy Storchaka]

New submission from Serhiy Storchaka :

There were a number of discussions about adding new syntax for temporary 
variables in comprehensions. The last was started yesterday on Python-Ideas 
(https://mail.python.org/pipermail/python-ideas/2018-February/048971.html). The 
problem is that all syntaxes proposed before are ugly. There are common 
solutions of this problem (calculating common subexpression only once): using 
internal comprehension or generator, or refactoring the inner expression as a 
local function where local variables can be used. For example [f(x) + g(f(x)) 
for x in range(10)] can be rewritten as

f_samples = (f(x) for x in range(10))
[y+g(y) for y in f_samples]

or

def func(x):
y = f(x)
return y + g(y)
[func(x) for x in range(10)]

Stephan Houben suggested other idea 
(https://mail.python.org/pipermail/python-ideas/2018-February/048971.html): 
perform an assignment by iterating a one-element list.

[y + g(y) for x in range(10) for y in [f(x)]]

I never seen this idiom before, but seems it is well known for some other 
developers, and it looks less clumsy than other solutions with current syntax. 
Its advantage over hypothetical syntax ideas is that it is an existing syntax. 
Its disadvantage over hypothetical syntax ideas is that iterating a one-element 
list is slightly slower that a simple assignment.

The proposed PR makes `for y in [f(x)]` in comprehensions as fast as just an 
assignment `y = f(x)`. This will make this idiom more preferable for 
performance reasons. Other existing solutions, iterating an inner generator and 
calling a local function in a loop, have an overhead.

--
components: Interpreter Core
messages: 312228
nosy: benjamin.peterson, brett.cannon, ncoghlan, serhiy.storchaka, yselivanov
priority: normal
severity: normal
status: open
title: Optimize the `for y in [x]` idiom in comprehensions
type: performance
versions: Python 3.8

___
Python tracker 

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