[issue28009] core logic of uuid.getnode() is broken for AIX - all versions

2018-01-14 Thread Michael Felt

Michael Felt  added the comment:

On 14/01/2018 22:01, Antoine Pitrou wrote:
> Antoine Pitrou  added the comment:
>
> Is nohup required in the example you just posted or is that a red herring?
>
> --
>
> ___
> Python tracker 
> 
> ___
>
nohup is required (i.e., my lazy way!) to stream both stdout and stderr 
through the pipe. Perhaps, for this output nohup could have been 
omitted. But it became a habit while I was testing. Maybe a birthday 
herring :p

Working on the Windows issue (my mistake). Will be groping in the dark 
as I have no windows system to test on.

--

___
Python tracker 

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



[issue15221] os.path.is*() may return False if path can't be accessed

2018-01-14 Thread Mariatta Wijaya

Mariatta Wijaya  added the comment:

Thanks!

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



[issue15221] os.path.is*() may return False if path can't be accessed

2018-01-14 Thread Mariatta Wijaya

Mariatta Wijaya  added the comment:


New changeset bb80645d06c16461b0b58d8983cd7fa6962ba3c6 by Mariatta (Miss 
Islington (bot)) in branch '3.6':
bpo-15221: Update os.path.is*() documentation (GH-5185) (GH-5186)
https://github.com/python/cpython/commit/bb80645d06c16461b0b58d8983cd7fa6962ba3c6


--

___
Python tracker 

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



[issue32553] venv says to use python3 which does not exist in 3.6.4

2018-01-14 Thread Mariatta Wijaya

Mariatta Wijaya  added the comment:

People who has more than one Python versions installed will have python3.

--
nosy: +Mariatta

___
Python tracker 

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



[issue32551] 3.5.4 has a regression that was fixed in 3.6.1rc1

2018-01-14 Thread Larry Hastings

Larry Hastings  added the comment:

As a reminder: I'm currently scheduled to tag Python 3.5.5rc1 on January 21st, 
2018, aka about six days from now.

--

___
Python tracker 

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



[issue26330] shutil.disk_usage() on Windows can't properly handle unicode

2018-01-14 Thread Roundup Robot

Change by Roundup Robot :


--
pull_requests: +5042

___
Python tracker 

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



[issue26330] shutil.disk_usage() on Windows can't properly handle unicode

2018-01-14 Thread Mariatta Wijaya

Mariatta Wijaya  added the comment:


New changeset ee3b83547c6b0cac1da2cb44aaaea533a1d1bbc8 by Mariatta (Cheryl 
Sabella) in branch 'master':
bpo-26330: Update shutil.disk_usage() documentation (GH-5184)
https://github.com/python/cpython/commit/ee3b83547c6b0cac1da2cb44aaaea533a1d1bbc8


--
nosy: +Mariatta

___
Python tracker 

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



[issue26163] FAIL: test_hash_effectiveness (test.test_set.TestFrozenSet)

2018-01-14 Thread Raymond Hettinger

Change by Raymond Hettinger :


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

___
Python tracker 

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



[issue15221] os.path.is*() may return False if path can't be accessed

2018-01-14 Thread Roundup Robot

Change by Roundup Robot :


--
pull_requests: +5040

___
Python tracker 

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



[issue15221] os.path.is*() may return False if path can't be accessed

2018-01-14 Thread Mariatta Wijaya

Mariatta Wijaya  added the comment:


New changeset b3dd18d4035803b50c65a434955966d1b3b1f363 by Mariatta (Cheryl 
Sabella) in branch 'master':
bpo-15221: Update os.path.is*() documentation (GH-5185)
https://github.com/python/cpython/commit/b3dd18d4035803b50c65a434955966d1b3b1f363


--
nosy: +Mariatta

___
Python tracker 

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



[issue26163] FAIL: test_hash_effectiveness (test.test_set.TestFrozenSet)

2018-01-14 Thread Raymond Hettinger

Raymond Hettinger  added the comment:

Bringing this tracker item back to life.  I've had more time to look at the 
this and the underlying problem was the high bits were not being shuffled back 
to impact lower bits.  By fixing this, all of the tests produce a greater 
number of distinct values than before.

--
resolution: wont fix -> 
status: closed -> open

___
Python tracker 

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



[issue32551] 3.5.4 has a regression that was fixed in 3.6.1rc1

2018-01-14 Thread Nick Coghlan

Nick Coghlan  added the comment:

Unfortunately, it looks like bpo-29319 was backported to the 3.5 branch, but 
not the follow-up fix from bpo-29723: 
https://github.com/python/cpython/commits/3.5/Modules/main.c

(The metadata on bpo-29319 indicated that the original change was targeted at 
3.6+ only, and I didn't notice the message that mentioned the 3.5 branch, so I 
never even looked at 3.5 when working on bpo-29723 - I just assumed it wasn't 
affected)

Adding unexpected directories to sys.path can definitely be a security problem, 
so I think the fix should be backported for 3.5.5, but I'm also wondering 
whether it might be a significant enough regression to warrant an extra "Oops, 
sorry, we broke it" binary release. (We don't have any good usage numbers on 
how often folks use directory execution vs other forms of execution, so we 
don't know how widespread any impact is likely to be)

--
nosy: +steve.dower

___
Python tracker 

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



[issue32553] venv says to use python3 which does not exist in 3.6.4

2018-01-14 Thread Paul Watson

New submission from Paul Watson :

The 3.6.4 documentation on venv specifies using 'python3', but no python3 
executable is in the 3.6.4 kit.

https://docs.python.org/3/library/venv.html?highlight=venv#module-venv

--
assignee: docs@python
components: Documentation
messages: 309943
nosy: Paul Watson, docs@python
priority: normal
severity: normal
status: open
title: venv says to use python3 which does not exist in 3.6.4
type: enhancement
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



[issue32542] memory not freed, aka memory leak continues...

2018-01-14 Thread Michael Felt

Michael Felt  added the comment:

Thanks for the clarification. 

Being curious, is there a way to see what the size of the cache is? I want to 
believe, but i do not have the impression memory is being reallocated to later 
users. My gut feeling is that the code change permits repeated calls to a 
function in a way that it reuses memory it received before (rather than a 
memory leak of repeatedly allocating a brand new buffer). What I expected, more 
accurately hoped for, is that cache was either freed and/or made available for 
reuse. 

Since I am on my phone atm I am less successful at finding documentation. I 
would be very grateful for a link to the relevant information and I’ll look 
further, time permitting. Thx again,

Michael 

Sent from my iPhone

> On 12 Jan 2018, at 23:48, Serhiy Storchaka  wrote:
> 
> 
> Serhiy Storchaka  added the comment:
> 
> Issue25582 fixed a memory leak. If run the tests repeatedly every iteration 
> leaked 100 MB of memory. If you get a MemoryError with a single iteration, 
> this means that your machine just doesn't have enough memory for tests. Tests 
> require around 500-600MB of memory on 32-bit platform.
> 
> --
> nosy: +serhiy.storchaka
> 
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

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



[issue26330] shutil.disk_usage() on Windows can't properly handle unicode

2018-01-14 Thread Eryk Sun

Eryk Sun  added the comment:

This is the high-level shutil module, so why not try to use the resolved parent 
directory? For example:

def disk_usage(path):
try:
total, free = nt._getdiskusage(path)
except NotADirectoryError:
path = os.path.dirname(nt._getfinalpathname(path))
total, free = nt._getdiskusage(path)
used = total - free
return _ntuple_diskusage(total, used, free)

Also, as noted in msg260022, nt._getdiskusage was overlooked when implementing 
PEP 529. The same applies to nt._getfinalpathname and nt._getvolumepathname. 
nt._getfullpathname works with bytes because it takes an argument-clinic 
`path_t` instead of `unicode` or `Py_UNICODE`. I think the other 3 should be 
rewritten to use path_t, but it's out of scope for this issue.

--
nosy: +eryksun

___
Python tracker 

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



[issue32552] Improve text for file arguments in argparse.ArgumentDefaultsHelpFormatter class

2018-01-14 Thread elypter

New submission from elypter :

If you use formatter_class=argparse.ArgumentDefaultsHelpFormatter in the 
constructor then the defaults that you include in arguments get automatically 
added to the help text. this looks great for int and Strings but not for files.

example:
  -suffixes [SUFFIXES]
suffixes file which contains keywords that are often
the last part of a class or style name of a sticky bar
(default: )

it should rather look like

  -suffixes [SUFFIXES]
suffixes file which contains keywords that are often
the last part of a class or style name of a sticky bar
(default:'sources/suffixes.txt')


the same holds probably true for more exotic datatypes. so an alternative or an 
addition could be to add an option to arguments to not add the default to the 
help text

--
components: Library (Lib)
messages: 309940
nosy: elypter
priority: normal
severity: normal
status: open
title: Improve text for file arguments in 
argparse.ArgumentDefaultsHelpFormatter class
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



[issue15221] os.path.is*() may return False if path can't be accessed

2018-01-14 Thread Cheryl Sabella

Cheryl Sabella  added the comment:

I created a PR for this by making the word 'existing' a link to 
'os.path.exists' since Nick mentioned that that word already implied the 
definition.

--
nosy: +csabella
versions: +Python 3.7 -Python 2.7, Python 3.2, Python 3.3

___
Python tracker 

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



[issue15221] os.path.is*() may return False if path can't be accessed

2018-01-14 Thread Cheryl Sabella

Change by Cheryl Sabella :


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

2018-01-14 Thread Steve Dower

Steve Dower  added the comment:

The more details you reveal, the less I want it to be an officially supported 
pattern :)

Perhaps you actually want an import hook? Brett can confirm, but I believe you 
can overwrite __loader__ in a package and change how submodules are loaded.

--
nosy: +brett.cannon

___
Python tracker 

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



[issue15115] Duplicated Content-Transfer-Encoding header when applying email.encoders

2018-01-14 Thread Cheryl Sabella

Cheryl Sabella  added the comment:

Barry/David,

Is this still a change you wanted to include in the documentation?


Thanks!

--
nosy: +csabella

___
Python tracker 

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



[issue26330] shutil.disk_usage() on Windows can't properly handle unicode

2018-01-14 Thread Cheryl Sabella

Change by Cheryl Sabella :


--
versions: +Python 3.7 -Python 3.3, Python 3.4, 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



[issue26330] shutil.disk_usage() on Windows can't properly handle unicode

2018-01-14 Thread Cheryl Sabella

Cheryl Sabella  added the comment:

I've submitted a PR for the documentation change.

--
nosy: +csabella

___
Python tracker 

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



[issue26330] shutil.disk_usage() on Windows can't properly handle unicode

2018-01-14 Thread Cheryl Sabella

Change by Cheryl Sabella :


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

___
Python tracker 

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



[issue28009] core logic of uuid.getnode() is broken for AIX - all versions

2018-01-14 Thread Antoine Pitrou

Antoine Pitrou  added the comment:

Is nohup required in the example you just posted or is that a red herring?

--

___
Python tracker 

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



[issue28009] core logic of uuid.getnode() is broken for AIX - all versions

2018-01-14 Thread Michael Felt

Michael Felt  added the comment:

FYI: - On AIX, no uuid_create support:

./python -m unittest -v test.test_uuid
...
Ran 48 tests in 0.261s

OK (skipped=37)

On AIX 6.1 (with ctypes, without _uuid)

./python -m unittest -v test.test_uuid
...
Ran 48 tests in 0.274s

OK (skipped=32)

On AIX 6.1 (with ctypes, with _uuid)

./python -m unittest -v test.test_uuid
...
Ran 48 tests in 0.379s

OK (skipped=16)

+++

nohup ./python -m unittest -v test.test_uuid | grep skipped
test_arp_getnode (test.test_uuid.TestInternalsWithExtModule) ... skipped 'AIX 
arp does not provide MAC addr'
test_ifconfig_getnode (test.test_uuid.TestInternalsWithExtModule) ... skipped 
'AIX ifconfig does not provide MAC addr'
test_ip_getnode (test.test_uuid.TestInternalsWithExtModule) ... skipped 
'requires ip'
test_ipconfig_getnode (test.test_uuid.TestInternalsWithExtModule) ... skipped 
'requires Windows'
test_lanscan_getnode (test.test_uuid.TestInternalsWithExtModule) ... skipped 
'requires lanscan'
test_netbios_getnode (test.test_uuid.TestInternalsWithExtModule) ... skipped 
'requires win32wnet'
test_windll_getnode (test.test_uuid.TestInternalsWithExtModule) ... skipped 
'requires Windows'
test_arp_getnode (test.test_uuid.TestInternalsWithoutExtModule) ... skipped 
'AIX arp does not provide MAC addr'
test_ifconfig_getnode (test.test_uuid.TestInternalsWithoutExtModule) ... 
skipped 'AIX ifconfig does not provide MAC addr'
test_ip_getnode (test.test_uuid.TestInternalsWithoutExtModule) ... skipped 
'requires ip'
test_ipconfig_getnode (test.test_uuid.TestInternalsWithoutExtModule) ... 
skipped 'requires Windows'
test_lanscan_getnode (test.test_uuid.TestInternalsWithoutExtModule) ... skipped 
'requires lanscan'
test_netbios_getnode (test.test_uuid.TestInternalsWithoutExtModule) ... skipped 
'requires win32wnet'
test_windll_getnode (test.test_uuid.TestInternalsWithoutExtModule) ... skipped 
'requires Windows'
test_uuid1_safe (test.test_uuid.TestUUIDWithExtModule) ... skipped 'requires 
uuid_generate_time_safe(3)'
test_uuid1_safe (test.test_uuid.TestUUIDWithoutExtModule) ... skipped 'requires 
uuid_generate_time_safe(3)'

--

___
Python tracker 

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



[issue28009] core logic of uuid.getnode() is broken for AIX - all versions

2018-01-14 Thread Michael Felt

Michael Felt  added the comment:

PR added, please review.

--

___
Python tracker 

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



[issue28009] core logic of uuid.getnode() is broken for AIX - all versions

2018-01-14 Thread Michael Felt

Change by Michael Felt :


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

___
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()

2018-01-14 Thread Raymond Hettinger

Change by Raymond Hettinger :


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



[issue29476] Simplify set_add_entry()

2018-01-14 Thread Raymond Hettinger

Raymond Hettinger  added the comment:


New changeset 3329992e31bd0494a7d7312853f7ffd054737e27 by Raymond Hettinger in 
branch 'master':
bpo-29476: Simplify set_add_entry() (#5175)
https://github.com/python/cpython/commit/3329992e31bd0494a7d7312853f7ffd054737e27


--

___
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

2018-01-14 Thread Brett Cannon

Brett Cannon  added the comment:

As Eli's comments are coming off as negative to/at me, I feel like I have
to defend myself here. If you look at the commit there was actually two
places where the timestamp was checked; one did an equality comparison and
one did a >= comparison. It's quite possible the semantics accidentally
changed as part of the refactoring due to the check being done in different
places and a different one was copied, although no one has even noticed
until now.

If there is a desire to change the semantics of how timestamps are checked
then that should be done in a separate issue as at this point we have lived
with the current semantics for several releases -- all releases of Python 3
still receiving security updates -- so it's passed being a bug and is now
the semantics in Python 3.

On Sat, Jan 13, 2018, 16:57 Eli Schwartz,  wrote:

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

[issue32550] STORE_ANNOTATION bytecode is unnecessary and can be removed.

2018-01-14 Thread Raymond Hettinger

Raymond Hettinger  added the comment:

I would like to see this patch go forward.  Making __annotations__ special and 
subtly different just adds to language complexity.

--
nosy: +rhettinger

___
Python tracker 

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



[issue32534] Speed-up list.insert

2018-01-14 Thread Raymond Hettinger

Raymond Hettinger  added the comment:

The result likely varies quite a bit from compiler-to-compiler and 
processor-to-processor and os-to-os.   It is may also be affected by data size 
and caching.

--
nosy: +rhettinger

___
Python tracker 

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



[issue32526] Closing async generator while it is running does not raise an exception

2018-01-14 Thread Joongi Kim

Change by Joongi Kim :


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

___
Python tracker 

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



[issue32226] Implement PEP 560: Core support for typing module and generic types

2018-01-14 Thread Serhiy Storchaka

Serhiy Storchaka  added the comment:

Sorry, I know very small about this module to writing the documentation.

--

___
Python tracker 

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



[issue32551] 3.5.4 has a regression that was fixed in 3.6.1rc1

2018-01-14 Thread Ned Deily

Change by Ned Deily :


--
dependencies: +3.6.1rc1 adds the current directory to sys.path when running a 
subdirectory's __main__.py; previous versions did not
nosy: +larry, ncoghlan

___
Python tracker 

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



[issue32551] 3.5.4 has a regression that was fixed in 3.6.1rc1

2018-01-14 Thread Ned Batchelder

Ned Batchelder  added the comment:

(For clarity)

The problem is that 3.5.4 adds the current directory to sys.path when running a 
subdirectory's __main__.py.  No other version of Python does this.

--

___
Python tracker 

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



[issue32551] 3.5.4 has a regression that was fixed in 3.6.1rc1

2018-01-14 Thread Ned Batchelder

New submission from Ned Batchelder :

The issue that I reported in https://bugs.python.org/issue29723 is now 
affecting 3.5.4:


```
$ pwd
/Users/ned/foo
$ tree syspathmain
syspathmain
└── __main__.py

0 directories, 1 file
$ cat syspathmain/__main__.py
import sys
print("-" * 20)
print(sys.version)
print("\n".join(sys.path))
$ for pyth in /usr/local/pythonz/pythons/CPython-*/bin/python; do $pyth 
syspathmain; done
/usr/local/pythonz/pythons/CPython-2.4.6/bin/python: 'syspathmain' is a 
directory, cannot continue

2.6.9 (unknown, Jun 18 2016, 17:45:44)
[GCC 4.2.1 Compatible Apple LLVM 7.0.2 (clang-700.1.81)]
syspathmain
/usr/local/pythonz/pythons/CPython-2.6.9/lib/python26.zip
/usr/local/pythonz/pythons/CPython-2.6.9/lib/python2.6
/usr/local/pythonz/pythons/CPython-2.6.9/lib/python2.6/plat-darwin
/usr/local/pythonz/pythons/CPython-2.6.9/lib/python2.6/plat-mac
/usr/local/pythonz/pythons/CPython-2.6.9/lib/python2.6/plat-mac/lib-scriptpackages
/usr/local/pythonz/pythons/CPython-2.6.9/lib/python2.6/lib-tk
/usr/local/pythonz/pythons/CPython-2.6.9/lib/python2.6/lib-old
/usr/local/pythonz/pythons/CPython-2.6.9/lib/python2.6/lib-dynload
/usr/local/pythonz/pythons/CPython-2.6.9/lib/python2.6/site-packages

2.7.10 (default, Jun 18 2016, 18:30:12)
[GCC 4.2.1 Compatible Apple LLVM 7.0.2 (clang-700.1.81)]
syspathmain
/usr/local/pythonz/pythons/CPython-2.7.10/lib/python27.zip
/usr/local/pythonz/pythons/CPython-2.7.10/lib/python2.7
/usr/local/pythonz/pythons/CPython-2.7.10/lib/python2.7/plat-darwin
/usr/local/pythonz/pythons/CPython-2.7.10/lib/python2.7/plat-mac
/usr/local/pythonz/pythons/CPython-2.7.10/lib/python2.7/plat-mac/lib-scriptpackages
/usr/local/pythonz/pythons/CPython-2.7.10/lib/python2.7/lib-tk
/usr/local/pythonz/pythons/CPython-2.7.10/lib/python2.7/lib-old
/usr/local/pythonz/pythons/CPython-2.7.10/lib/python2.7/lib-dynload
/usr/local/pythonz/pythons/CPython-2.7.10/lib/python2.7/site-packages

2.7.11 (default, Jun 18 2016, 17:51:44)
[GCC 4.2.1 Compatible Apple LLVM 7.0.2 (clang-700.1.81)]
syspathmain
/usr/local/pythonz/pythons/CPython-2.7.11/lib/python27.zip
/usr/local/pythonz/pythons/CPython-2.7.11/lib/python2.7
/usr/local/pythonz/pythons/CPython-2.7.11/lib/python2.7/plat-darwin
/usr/local/pythonz/pythons/CPython-2.7.11/lib/python2.7/plat-mac
/usr/local/pythonz/pythons/CPython-2.7.11/lib/python2.7/plat-mac/lib-scriptpackages
/usr/local/pythonz/pythons/CPython-2.7.11/lib/python2.7/lib-tk
/usr/local/pythonz/pythons/CPython-2.7.11/lib/python2.7/lib-old
/usr/local/pythonz/pythons/CPython-2.7.11/lib/python2.7/lib-dynload
/usr/local/pythonz/pythons/CPython-2.7.11/lib/python2.7/site-packages

2.7.12 (default, Nov 20 2016, 16:53:49)
[GCC 4.2.1 Compatible Apple LLVM 7.0.2 (clang-700.1.81)]
syspathmain
/usr/local/pythonz/pythons/CPython-2.7.12/lib/python27.zip
/usr/local/pythonz/pythons/CPython-2.7.12/lib/python2.7
/usr/local/pythonz/pythons/CPython-2.7.12/lib/python2.7/plat-darwin
/usr/local/pythonz/pythons/CPython-2.7.12/lib/python2.7/plat-mac
/usr/local/pythonz/pythons/CPython-2.7.12/lib/python2.7/plat-mac/lib-scriptpackages
/usr/local/pythonz/pythons/CPython-2.7.12/lib/python2.7/lib-tk
/usr/local/pythonz/pythons/CPython-2.7.12/lib/python2.7/lib-old
/usr/local/pythonz/pythons/CPython-2.7.12/lib/python2.7/lib-dynload
/usr/local/pythonz/pythons/CPython-2.7.12/lib/python2.7/site-packages

2.7.13 (default, Dec 17 2016, 16:51:07)
[GCC 4.2.1 Compatible Apple LLVM 7.0.2 (clang-700.1.81)]
syspathmain
/usr/local/pythonz/pythons/CPython-2.7.13/lib/python27.zip
/usr/local/pythonz/pythons/CPython-2.7.13/lib/python2.7
/usr/local/pythonz/pythons/CPython-2.7.13/lib/python2.7/plat-darwin
/usr/local/pythonz/pythons/CPython-2.7.13/lib/python2.7/plat-mac
/usr/local/pythonz/pythons/CPython-2.7.13/lib/python2.7/plat-mac/lib-scriptpackages
/usr/local/pythonz/pythons/CPython-2.7.13/lib/python2.7/lib-tk
/usr/local/pythonz/pythons/CPython-2.7.13/lib/python2.7/lib-old
/usr/local/pythonz/pythons/CPython-2.7.13/lib/python2.7/lib-dynload
/usr/local/pythonz/pythons/CPython-2.7.13/lib/python2.7/site-packages

2.7.13rc1 (default, Dec  4 2016, 15:34:21)
[GCC 4.2.1 Compatible Apple LLVM 7.0.2 (clang-700.1.81)]
syspathmain
/usr/local/pythonz/pythons/CPython-2.7.13rc1/lib/python27.zip
/usr/local/pythonz/pythons/CPython-2.7.13rc1/lib/python2.7
/usr/local/pythonz/pythons/CPython-2.7.13rc1/lib/python2.7/plat-darwin
/usr/local/pythonz/pythons/CPython-2.7.13rc1/lib/python2.7/plat-mac
/usr/local/pythonz/pythons/CPython-2.7.13rc1/lib/python2.7/plat-mac/lib-scriptpackages
/usr/local/pythonz/pythons/CPython-2.7.13rc1/lib/python2.7/lib-tk
/usr/local/pythonz/pythons/CPython-2.7.13rc1/lib/python2.7/lib-old
/usr/local/pythonz/pythons/CPython-2.7.13rc1/lib/python2.7/lib-dynload
/usr/local/pythonz/pythons/CPython-2.7.13rc1/lib/python2.7/site-packages

2.7.14 (default, Oct  4 2017, 09:45:53)
[GCC 4.2.1 

[issue32550] STORE_ANNOTATION bytecode is unnecessary and can be removed.

2018-01-14 Thread Mark Shannon

Mark Shannon  added the comment:

Works as expected:

>>> class C:
... exec('x: int')
... 
>>> C.__annotations__
{'x': }
>>> __annotations__
{}

--

___
Python tracker 

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



[issue32550] STORE_ANNOTATION bytecode is unnecessary and can be removed.

2018-01-14 Thread Ivan Levkivskyi

Ivan Levkivskyi  added the comment:

There is also another corner case to consider:

class C:
exec('x: int')

assert C.__annotations__ == {'x': int}
assert __annotations__ == {}

I am not sure this one will be covered correctly.
But the main argument here is speed I think.

Let us see what others think about this.

--

___
Python tracker 

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



[issue32550] STORE_ANNOTATION bytecode is unnecessary and can be removed.

2018-01-14 Thread Mark Shannon

Mark Shannon  added the comment:

> 3. It doesn't add a name constant. Instead it uses a name from the names list 
> (which already has to contain this name).

This PR moves the constant for the name from `co_names` to `co_consts`. There 
is no duplication.
>>> def f():
...class C:
...   a : 1
(It does add __annotations__ to `co_names`, but that seems reasonable to me)

Current:
>>> f.__code__.co_consts[1].co_names
('__name__', '__module__', '__qualname__', 'a')
>>> f.__code__.co_consts[1].co_consts
('f..C', 1, None)
With PR 5181:
>>> f.__code__.co_consts[1].co_names
('__name__', '__module__', '__qualname__', '__annotations__')
>>> f.__code__.co_consts[1].co_consts
('f..C', 1, 'a', None)

--

___
Python tracker 

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



[issue32550] STORE_ANNOTATION bytecode is unnecessary and can be removed.

2018-01-14 Thread Mark Shannon

Mark Shannon  added the comment:

PEP 526 explicitly states
"as with all dunder attributes, any undocummented use of __annotations__ is 
subject to breakage without warning"

I consider deleting __annotations__ to be undocumented use.

Do you really think that an obscure difference in the behaviour of 

>>> class C:
... del __annotations__
... x: int

justifies an extra bytecode, but the implicit return at the end of all 
functions (LOAD_CONST None; RETURN_VALUE) does not?

--

___
Python tracker 

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



[issue32550] STORE_ANNOTATION bytecode is unnecessary and can be removed.

2018-01-14 Thread Ivan Levkivskyi

Ivan Levkivskyi  added the comment:

There are several corner cases. For example consider this code:

>>> class C:
... del __annotations__
... x: int

Currently this correctly raises NameError, with your replacement it will 
instead stick {'x': int} in the module `__annotations__`. I think there may be 
other special cases but I don't remember them now.

--

___
Python tracker 

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



[issue32550] STORE_ANNOTATION bytecode is unnecessary and can be removed.

2018-01-14 Thread Serhiy Storchaka

Serhiy Storchaka  added the comment:

There some subtle differences.

1. Unlike to LOAD_NAME, STORE_ANNOTATION doesn't fall back to globals if 
'__annotations__' is not found in locals. The behavior difference is shown by 
the following example:

x: int
class A:


del __annotations__ 

   
y: int

2. The single STORE_ANNOTATION is faster than 3 other opcodes.

3. It doesn't add a name constant. Instead it uses a name from the names list 
(which already has to contain this name).

--
nosy: +serhiy.storchaka

___
Python tracker 

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



[issue32550] STORE_ANNOTATION bytecode is unnecessary and can be removed.

2018-01-14 Thread Mark Shannon

Change by Mark Shannon :


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



[issue32550] STORE_ANNOTATION bytecode is unnecessary and can be removed.

2018-01-14 Thread Serhiy Storchaka

Change by Serhiy Storchaka :


--
nosy: +gvanrossum, levkivskyi, yselivanov

___
Python tracker 

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



[issue32550] STORE_ANNOTATION bytecode is unnecessary and can be removed.

2018-01-14 Thread Mark Shannon

New submission from Mark Shannon :

The STORE_ANNOTATION bytecode is used to implement annotations.
The code 
 name : ann
is equivalent to 
__annotations__['name'] = ann

Consequently,
STORE_ANNOTATION name

can be trivially replaced with 
LOAD_NAME  __annotations__
LOAD_CONST 'name'
STORE_SUBSCR

--
components: Interpreter Core
messages: 309918
nosy: Mark.Shannon
priority: normal
severity: normal
stage: needs patch
status: open
title: STORE_ANNOTATION bytecode is unnecessary and can be removed.
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



[issue32534] Speed-up list.insert

2018-01-14 Thread Jeethu Rao

Jeethu Rao  added the comment:

I managed to tune an i7700k desktop running Ubuntu 17.10 per this doc[1], and 
ran the pyperformance benchmarks[2].
I also tried various threshold with this benchmark and 16 still seems to be the 
sweet spot.
The geometric mean of the relative changes across all benchmarks indicates a 
12.85% improvement.

[1]: http://pyperformance.readthedocs.io/usage.html#how-to-get-stable-benchmarks
[2]: https://gist.github.com/jeethu/4d9a8bd3eecbd067c00f085f7d2e7595

--

___
Python tracker 

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



[issue32549] Travis: Test with OpenSSL 1.1.0

2018-01-14 Thread Christian Heimes

Change by Christian Heimes :


--
keywords: +patch
pull_requests: +5033

___
Python tracker 

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



[issue32549] Travis: Test with OpenSSL 1.1.0

2018-01-14 Thread Christian Heimes

New submission from Christian Heimes :

For several planned features and security improvements, at least OpenSSL 1.0.2 
is required. OpenSSL 1.1.0 is preferred to test all new features. See 
discussion 
https://mail.python.org/pipermail/python-dev/2018-January/151718.html . However 
Travis CI uses Ubuntu 14.04 LTS, which comes with OpenSSL 1.0.1.

To address the problem, CPython has either to compile and install a local copy 
of OpenSSL, move to container-based testing or use a different CI provider with 
more recent infrastructure.

I have created a PR that uses an improved version of my multissl test helper to 
compile and install the latest copy of OpenSSL 1.1.0. The build is cached by 
Travis. I *think* it is necessary to build OpenSSL in master so PRs can use the 
cache. A daily Travis cron job on master should do the trick.

--
messages: 309916
nosy: christian.heimes
priority: normal
severity: normal
stage: patch review
status: open
title: Travis: Test with OpenSSL 1.1.0
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



[issue17972] inspect module docs omits many functions

2018-01-14 Thread Paul Rudin

Paul Rudin  added the comment:

Although formatannotation is undocumented, its actually documented as a default 
value for one of the parameters of formatargspec, so it does form part of the 
module's public interface. However formatargspec is deprecated, so it's still 
OK to deprecate formatannotation.

formatannotation is also used as a helper within Parameter, which isn't 
deprecated, but the public interface or docs of Parameter don't mention 
formatannotation, so using _formatannotation instead is fine.

Since I've looked through this and, as far as I can tell, nobody is working on 
it, I'll make the changes and make a PR.

--

___
Python tracker 

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