date:20190816



Abhilash Raj  added the comment:

I am slightly confused if this should be backported to bugfix branches since 
this is technically a new feature, the ability to parse Message-ID field.

I would love to see what David and Barry think about this?

--

___
Python tracker 

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

[issue21315] email._header_value_parser does not recognise in-line encoding changes



Change by Abhilash Raj :


--
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.7, Python 3.8 -Python 3.3, Python 3.4, Python 3.5

___
Python tracker 

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

[issue29412] IndexError thrown on email.message.Message.get



Change by Abhilash Raj :


--
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.8, Python 3.9 -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

[issue37790] subprocess.Popen() is extremely slow

2019-08-16 Thread Alexander Pyhalov



Alexander Pyhalov  added the comment:

Even if I use 
import subprocess
process = subprocess.Popen(cmd,
stdout=subprocess.PIPE,
stderr=subprocess.PIPE,
shell=True,
universal_newlines=True)
return process.stdout.read()
difference in times are the same.

--

___
Python tracker 

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

[issue37790] subprocess.Popen() is extremely slow

2019-08-16 Thread Alexander Pyhalov



Alexander Pyhalov  added the comment:

I couldn't reproduce entire test, as wsdiff script is rather large, but here's 
the simplified version. If Popen is used more often, difference is much more 
significant.

# Using workaround
$ python3.5 ~/tmp/1.py 1 
10.780487537384033
# Without workaround
$ python3.5 ~/tmp/1.py
13.347045660018921
# Using python2.7
$ python2.7 ~/tmp/1.py
9.83385586739

--
Added file: https://bugs.python.org/file48549/1.py

___
Python tracker 

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

[issue34155] email.utils.parseaddr mistakenly parse an email



Abhilash Raj  added the comment:

Created a backport PR for 3.5.

--
stage: patch review -> resolved

___
Python tracker 

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

[issue34155] email.utils.parseaddr mistakenly parse an email



Change by Abhilash Raj :


--
pull_requests: +15036
stage: resolved -> patch review
pull_request: https://github.com/python/cpython/pull/15317

___
Python tracker 

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

[issue34155] email.utils.parseaddr mistakenly parse an email

2019-08-16 Thread Kyle Stanley



Kyle Stanley  added the comment:

> This is already backported to 3.6. I am not sure about what gets backported 
> to 3.5 right now, I don't even see a 'Backport to 3.5' label on Github (which 
> made me think we are discouraged to backport to 3.5). I can work on a manual 
> backport if needed?

As far as I'm aware, backports to 3.5 have to be manually approved by those 
with repository management permissions, such the the organization owners 
(https://devguide.python.org/devcycle/#current-owners) and admins 
(https://devguide.python.org/devcycle/#current-administrators)

--
nosy: +aeros167

___
Python tracker 

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

[issue37834] readlink on Windows cannot read app exec links



Steve Dower  added the comment:

> Why group all reparse points under the banner of 'link'?

Because for the purposes of the list of changes beneath it, there wasn't any 
difference (e.g. "traverses any links supported by the OS" is more meaningful 
to most people, even though both of us would understand it to mean "traverses 
any traversable reparse points supported by the OS"). I'm not redefining them 
all to be the same thing, just establishing the terminology for what 
immediately followed.

> As I've previously suggested (and this is the last time because I'm
> becoming a broken record), lstat() should at least be restricted to
> opening only name-surrogate reparse points that are supposed to be like
> links in that they target another path in the system. Plus it also has
> to open unhandled reparse points.

Apologies for causing the repetition. Let me summarise what I believe you're 
suggesting as an alternate flow (bearing in mind that only os.stat() and 
os.lstat() are affected here):

os.lstat:
* open without following reparse points
* check the reparse tag
 - if it's a genuine symlink, return attributes of the link itself and marked 
ST_IFLNK
 - if it's a directory junction, call os.stat instead and return that (???)
 - if it's any name-surrogate reparse point, return attributes of the link 
itself but not marked ST_IFLNK
 - if it's any other reparse point, call os.stat instead and return that
* otherwise regular handling (using hFile or FindFirstFile, etc.)

os.stat:
* open following reparse points
* if the open fails with ERROR_CANT_ACCESS_FILE, try opening without following 
reparse points:
 - if it's a genuine symlink, ???
 - if it's a directory junction, ???
 - if it's any name-surrogate reparse point, ???
 - if it's any other reparse point, return attributes of the link itself
* otherwise regular handling

If you can fill in the gaps, that will help me understand exactly what you're 
proposing.

>> shutil.copytree(path): Unchanged. (requires a minor fix to
>> continue to recursively copy through junctions (using above test),
>> but not symlinks.)
>
> Everyone else who relies on islink(), readlink(), and symlink() to copy
> symlinks isn't special casing their code to look for junctions or
> anything else we lump under the banner of islink(). They could code
> defensively if readlink() fails for a 'link' that we can't read. But
> that leaves the problem of readlink() succeeding for a junction. That
> can causes problems if the target is passed to os.symlink(), which
> changes the link from a hard name grafting to a soft name grafting.

Right, but is that because they deliberately want the junction to be treated 
like a file? Or because they want it to be treated like the directory is really 
right there?

os.rmdir() already does special things to behave like a junction rather than 
the real directory, and the islink/readlink/symlink process is going to be 
problematic on Windows since most users can't create symlinks. That code simply 
isn't going to be portable. But code that is using stat() and expecting to get 
the real directory ought to work, just as code using lstat() and expecting to 
get the link if it's been linked somehow ought to work.

> Why would we need to read the target of a junction? It's not needed for
> realpath() in Windows. We should only have to resolve symlinks. For
> example:
> 
> ...
>
> IMO, S_IFLNK need not be set for anything other than Unix-like symbolic
> links. We would just need to document that on Windows, lstat opens any
> link-like reparse point that indicates it targets another path on the
> system, plus any reparse point that's not handled, but that islink() is
> only true for actual Unix symlinks that can be created via os.symlink()
> and read via os.readlink().

I think I understand your reasoning here now, sorry for it taking so long.

> This preserves how islink() and readlink() currently work, while still
> leaving the door open to fix misbehavior in particular cases. Code,
> including our own code, that needs to look for the broader Windows
> category of "name surrogate" can examine the reparse tag. For
> convenience we can provide issurrogate() that checks
> lstat(filename).st_reparse_tag & 0x2000_.

I'm not adding new API, even for internal use. This is edge case enough that 
os.lstat() is fine for it.

>> os.unlink(path): unchanged (still removes the junction, not the
>> contents)
> 
> Whatever we're calling a link should be capable of being deleted via
> os.unlink. If we apply S_IFLNK, then it won't have S_IFDIR (at least how
> POSIX code expects it), and unlink should work on it. The current state
> of affairs in which unlink/remove works on a junction, which is reported
> by stat() as a directory, is inconsistent. It's not specified to remove
> directories, so nothing that it can remove should be a directory.

I'm proposing to fix the inconsistency by fixing the flags. Your proposal is to 
fix the inconsistency by generating a new error

[issue37834] readlink on Windows cannot read app exec links

2019-08-16 Thread Eryk Sun



Eryk Sun  added the comment:

> the '/mnt/c/Document and Settings' junction... though now I try 
> it that those don't actually work...)

The security on compatibility junctions denies everyone read-data (list) 
access, but in Windows they can still be traversed (e.g. "C:/Documents and 
Settings/Public") because execute (traverse) access isn't denied, and even if 
it were denied, standard Windows users have SeChangeNotifyPrivilege to bypass 
traverse checking. 

I created a test junction named "eggs" that targets a directory named "spam" 
that has "spam/foo" subdirectory. I set the junction's security to match that 
of "Documents and Settings". In WSL, trying to traverse it to stat the "foo" 
subdirectory failed with EACCES, just as with "Documents and Settings/Public". 
After removing the entry that denies read-data access, it worked fine. There's 
no problem traversing "spam" directly if I set the same security on it that 
denies everyone read-data access; it only prevents listing the directory. 

It seems that in order to evaluate an NT junction, drvfs tries to open it with 
read-data access. I don't see why it would have to do that.

--

___
Python tracker 

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

[issue37834] readlink on Windows cannot read app exec links

2019-08-16 Thread Eryk Sun

Eryk Sun added the comment:

> Where "links" are the generic term for the set that includes
> "reparse point", "symlink", "mount point", "junction", etc.)

Why group all reparse points under the banner of 'link'? If we have a typical
HSM reparse point (the vast majority of allocated tags), then all operations,
such as delete and rename, act on the file itself, not simply the reparse
point. We should be able to delete or rename a link without affecting the
target.

In this case, there's also no chance that the reparse point is a surrogate for
another path on the system, so code that walks paths doesn't have to worry
about loops with regard to these reparse points. The only practical use case I
can think of for detecting/opening this type of reparse point is backup
software that should avoid triggering an HSM recall. For example:

https://www.ibm.com/support/knowledgecenter/en/SSEQVQ_8.1.0/client/r_opt_hsmreparsetag.html

As I've previously suggested (and this is the last time because I'm becoming a
broken record), lstat() should at least be restricted to opening only
name-surrogate reparse points that are supposed to be like links in that they
target another path in the system. Plus it also has to open unhandled reparse
points.

Personally, I'm only comfortable with opening it up to name surrogates if
islink() and readlink() are still limited to just Unix-like symlinks that we
can create via symlink(). Nothing changes there. It's just a restriction of how
lstat() currently works. The addition of the reparse tag in the stat result
enables special handling of non-symlink surrogates.

> shutil.copytree(path): Unchanged. (requires a minor fix to
> continue to recursively copy through junctions (using above test),
> but not symlinks.)

Everyone else who relies on islink(), readlink(), and symlink() to copy
symlinks isn't special casing their code to look for junctions or anything else
we lump under the banner of islink(). They could code defensively if readlink()
fails for a 'link' that we can't read. But that leaves the problem of
readlink() succeeding for a junction. That can causes problems if the target is
passed to os.symlink(), which changes the link from a hard name grafting to a
soft name grafting.

Why would we need to read the target of a junction? It's not needed for
realpath() in Windows. We should only have to resolve symlinks. For example:

C:/Mount/junction/spam/eggs

junction -> Z:/bar/baz

We don't have to resolve this as "Z:/bar/baz/spam/eggs", and doing so may even
be wrong for someone using it to manually resolve a relative symlink.
"C:/Mount/junction/spam/eggs" is a solid path. In Unix it would not be resolved
by realpath(). A solid path is needed to figure out how to create a relative
symlink, or how to manually resolve one for a given path.

For example, if "foo_link" in "C:/Mount/junction/spam/eggs" targets
"../../../foo", this refers to "C:/Mount/foo". On the other hand, if the
junction mount point were replaced by a soft symlink, then
"C:/Mount/symlink/spam/eggs" is not a solid path. "foo_link" is instead
evaluated over the target path: "Z:/bar/baz/spam/eggs/foo_link", so the link
resolves to "Z:/bar/foo".

IMO, S_IFLNK need not be set for anything other than Unix-like symbolic links.
We would just need to document that on Windows, lstat opens any link-like
reparse point that indicates it targets another path on the system, plus any
reparse point that's not handled, but that islink() is only true for actual
Unix symlinks that can be created via os.symlink() and read via os.readlink().

This preserves how islink() and readlink() currently work, while still leaving
the door open to fix misbehavior in particular cases. Code, including our own
code, that needs to look for the broader Windows category of "name surrogate"
can examine the reparse tag. For convenience we can provide issurrogate() that
checks lstat(filename).st_reparse_tag & 0x2000_. This can be true for
directories. Also, a surrogate doesn't have to behave like a Unix "soft"
symlink, i.e. it applies to "hard" mount points. In Unix, issurrogate() could
just be an alias for islink() since Unix provides only one type of name
surrogate.

Currently the name surrogate category includes the following tags:

Microsoft name surrogate (bits 31 and 29)

IO_REPARSE_TAG_MOUNT_POINT 0xA003
IO_REPARSE_TAG_SYMLINK 0xA00C
IO_REPARSE_TAG_IIS_CACHE0xA010
IO_REPARSE_TAG_GLOBAL_REPARSE 0xA019
IO_REPARSE_TAG_LX_SYMLINK 0xA01D
IO_REPARSE_TAG_WCI_TOMBSTONE0xA01F
IO_REPARSE_TAG_PROJFS_TOMBSTONE 0xA022

Non-Microsoft name surrogate (bit 29)

IO_REPARSE_TAG_SOLUTIONSOFT 0x200D
IO_REPARSE_TAG_OSR_SAMPLE 0x2017
IO_REPARSE_TAG_QI_TECH_HSM

[issue37826] Document PEP 3134 in tutorials/errors.rst



Change by Abhilash Raj :


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

[issue37877] MacOS crash appJar 3.7.3



Michael Hearn  added the comment:

Hopefully apple will fix this.
https://medium.com/@michaeljosephhearn/macos-mojave-crash-6fd1e69d3d34

--

___
Python tracker 

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

[issue17305] IDNA2008 encoding is missing

2019-08-16 Thread Christian Heimes



Christian Heimes  added the comment:

There is no consensus yet. Besides https://pypi.org/project/idna/ we could also 
consider to wrap libidn2 and ship it. Both PyPI idna and libidn2 have potential 
licensing issues. I don't like the idea to reinvent the wheel and implement our 
own idna2008 codec. It's not a trivial task.

Once Python has a working idna2008 encoder, we need to address integration into 
socket, ssl, http, and asyncio module.

--

___
Python tracker 

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

[issue37877] MacOS crash appJar 3.7.3



Change by Michael Hearn :


--
resolution:  -> third party
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

[issue37877] MacOS crash appJar 3.7.3


Michael Hearn  added the comment:

Thanks for the fast response it uses appJar which is a very similar GUI
package but not the same one. AppJar is based of it but I don’t believe it
was built off it.

On Fri, Aug 16, 2019 at 3:55 PM Ronald Oussoren 
wrote:

>
> Ronald Oussoren  added the comment:
>
> Does this application use Tkinter?
>
> If so, this is a duplicate of #37833, and a bug in macOS triggered by
> (amongst others) anaconda but (AFAIK) not by the Python.org installer.
>
> The "logout" is a crash in the WindowServer proces, which is something
> that should never happen. I've filed an issue with Apple about that, but
> have no idea if or when they will look at that.
>
> --
> nosy: +ronaldoussoren
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

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

[issue37732] Possible uninitialized variable in Objects/obmalloc.c

2019-08-16 Thread Hansraj Das



Change by Hansraj Das :


--
keywords: +patch
pull_requests: +15035
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/15309

___
Python tracker 

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

[issue37824] IDLE: Handle Shell input warnings properly.

2019-08-16 Thread Tal Einat



Tal Einat  added the comment:

I see none of this on latest master (0567786d26348aa7eaf0ab1b5d038fdabe409d92) 
on Windows 10.  Can you specify on what OS and Python branch/version this 
happens?

--

___
Python tracker 

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

[issue37878] Sub-Interpreters : Document PyThreadState_DeleteCurrent()



Change by Joannah Nanjekye :


--
keywords: +patch
pull_requests: +15034
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/15315

___
Python tracker 

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

[issue37878] Sub-Interpreters : Document PyThreadState_DeleteCurrent()



Change by Joannah Nanjekye :


--
title: Sub-ineterpreters : Document PyThreadState_DeleteCurrent() ? -> 
Sub-Interpreters : Document PyThreadState_DeleteCurrent()

___
Python tracker 

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

[issue37593] ast.arguments has confusing args/posonlyargs ordering

2019-08-16 Thread Mairi Dulaney



Mairi Dulaney  added the comment:

The patch that was merged to fix this may have caused a regresion in xonsh.  Am 
working on a reproducer.

--
nosy: +mdulaney

___
Python tracker 

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

[issue37878] Sub-ineterpreters : Document PyThreadState_DeleteCurrent() ?



Change by Joannah Nanjekye :


--
title: sub-ineterpreters : Document PyThreadState_DeleteCurrent() ? -> 
Sub-ineterpreters : Document PyThreadState_DeleteCurrent() ?

___
Python tracker 

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

[issue37877] MacOS crash appJar 3.7.3

2019-08-16 Thread Ronald Oussoren



Ronald Oussoren  added the comment:

Does this application use Tkinter?  

If so, this is a duplicate of #37833, and a bug in macOS triggered by (amongst 
others) anaconda but (AFAIK) not by the Python.org installer.

The "logout" is a crash in the WindowServer proces, which is something that 
should never happen. I've filed an issue with Apple about that, but have no 
idea if or when they will look at that.

--
nosy: +ronaldoussoren

___
Python tracker 

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

[issue37878] sub-ineterpreters : Document PyThreadState_DeleteCurrent() ?



New submission from Joannah Nanjekye :

I just noticed that PyThreadState_DeleteCurrent()in Python/pystate.c is not 
documented.

Relevant documentation should go in Doc/c-api/init.rst If no one objects to 
this.

--
assignee: docs@python
components: Documentation
keywords: easy
messages: 349881
nosy: docs@python, eric.snow, nanjekyejoannah, ncoghlan, vstinner
priority: normal
severity: normal
stage: needs patch
status: open
title: sub-ineterpreters : Document PyThreadState_DeleteCurrent() ?
versions: Python 3.8, Python 3.9

___
Python tracker 

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

[issue37877] MacOS crash appJar 3.7.3



New submission from Michael Hearn :

macOS 10.14.6 -anaconda install Python 3.7.3  pip install appJar (0.94.0) 

On start of app with app.go() a crash will occur causing mac to logout.

Python 3.7.2 does not show this behavior

Will document on medium.

https://raw.githubusercontent.com/borosilicate/RCSB-Protein-Data-Bank-CSV-Maker/master/pygui.py

--
nosy:  -ned.deily, ronaldoussoren
type:  -> crash

___
Python tracker 

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

[issue37835] typing.get_type_hints wrong namespace for forward-declaration of inner class

2019-08-16 Thread Ivan Levkivskyi



Change by Ivan Levkivskyi :


--
nosy: +levkivskyi

___
Python tracker 

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

[issue9949] os.path.realpath on Windows does not follow symbolic links



Steve Dower  added the comment:

Another minor change worth calling out - I added a note to the docs that when a 
symlink cycle is detected, realpath() could return any member of the cycle, but 
does not guarantee which one.

For our test cases it's generally stable enough, but if you change the starting 
point (e.g. from absolute to relative path) then it can change the result. It 
seemed easier all round just to not guarantee anything about which member of 
the cycle will be returned, rather than determining the exact rules, 
reproducing them across all platforms, and documenting them.

--

___
Python tracker 

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

[issue37872] Move _Py_IDENTIFIER statics in Python/import.c to top of the file

2019-08-16 Thread Greg Price



Change by Greg Price :


--
components: +Interpreter Core

___
Python tracker 

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

[issue37872] Move _Py_IDENTIFIER statics in Python/import.c to top of the file

2019-08-16 Thread Greg Price



Change by Greg Price :


--
title: Move statics in Python/import.c to top of the file -> Move 
_Py_IDENTIFIER statics in Python/import.c to top of the file

___
Python tracker 

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

[issue37872] Move statics in Python/import.c to top of the file

2019-08-16 Thread Greg Price



Change by Greg Price :


--
nosy: +Greg Price

___
Python tracker 

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

[issue37877] MacOS crash appJar 3.7.3



Change by Michael Hearn :


--
components: macOS
nosy: Michael Hearn, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: MacOS crash appJar 3.7.3
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

[issue25299] TypeError: init() takes at least 4 arguments (4 given)



Joannah Nanjekye  added the comment:

> this argument defaults to "None"

Am leaning to the fact that this works as required. The documentation does not 
just say defaults to none. It says:

With the 'store_const' and 'append_const' actions, the const keyword argument 
must be given. For other actions, it defaults to None.

In the scenario, you have given, you are using 'store_const' so the const 
keyword argument must be given.

This should be closed If you agree with what I have just stated.

--

___
Python tracker 

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

[issue24754] argparse add_argument with action="store_true", type=bool should not crash



Joannah Nanjekye  added the comment:

See issue25299 also.

--
nosy: +nanjekyejoannah

___
Python tracker 

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

[issue37834] readlink on Windows cannot read app exec links



Steve Dower  added the comment:

That was a long set of replies, so here's my summary proposed behaviour:

(Where "links" are the generic term for the set that includes "reparse point", 
"symlink", "mount point", "junction", etc.)

os.lstat(path): returns attributes for path without traversing any kind of links

os.stat(path): traverses any links supported by the OS and returns attributes 
for the final file
- on Windows, if the OS reports that a link is not followable (e.g. 
appexeclink), then the original link is reported. So if S_IFLNK is set in the 
result, the caller should, use os.path.realpath() to traverse as many links as 
possible to reach the unfollowable link

os.exists(path): now returns True for links that exist but the OS reports are 
not followable - previously returned False (links that are followable but the 
target does not exist continue to return False)

os.path.is_dir(path): now returns False for directory links where the target 
does not exist

os.unlink(path): unchanged (still removes the junction, not the contents)

os.scandir(path): DirEntry.is_symlink() and DirEntry.is_dir() will now both be 
True for junctions (this was always the case for symlinks to directories). 
DirEntry.stat(follow_symlinks=False).st_reparse_tag == 
stat.IO_REPARSE_TAG_MOUNT_POINT is how to specifically detect a junction.

shutil.copytree(path): Unchanged. (requires a minor fix to continue to 
recursively copy through junctions (using above test), but not symlinks.)

shutil.rmtree(path): Will now remove a junction rather than recursively 
deleting its contents (net improvement, IMHO)


And as I said at the end of the long post, my main goals are:
* the result of _using_ the returned information should be consistent across OS
* there are ways of getting more specific information when needed

The most impactful change would seem to be the one to DirEntry, in that users 
may now treat junction points more like symlinks than real directories 
depending on how they've set up their checks. But for the other benefits - 
particularly the more reliable exists() checks - I think this is worth it 
overall.

--

___
Python tracker 

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

[issue37834] readlink on Windows cannot read app exec links



Steve Dower  added the comment:

>> I don't want to add any parameters - I want to have predictable and
>> reasonable default behaviour. os.readlink() already exists for 
>> "open reparse point" behaviour.
>
> I'd appreciate a parameter to always open reparse points, even if a
> filter-driver or the I/O manager handles them. 

But that's only required if lstat() traverses junctions, which I'm not 
proposing to do.

> I'm no longer a big fan of mapping "follow_symlinks" to name surrogates
> ... But it's not up to me. If follow_symlinks means name surrogates, at
> least then lstat can open any reparse point that claims to link to
> another path and thus *should* have link-like behavior (hard link or
> soft link).

Yeah, ultimately it looks like it'll be up to me, which is why I want as much 
of your input as I can get before having to make a call :)

I'm leaning towards "if the OS follows it by default, stat() will follow it", 
and (given some of your later comments), "when ERROR_CANT_ACCESS_FILE occurs on 
a reparse point (is that the only scenario?) behave like lstat()".

(And I carefully phrased that to not imply that Python is going to partially 
follow a link chain for you if the eventual end result is not valid. e.g. 
stat() on a symlink to an appexeclink will return the symlink, because 
ERROR_CANT_ACCESS_FILE was the result. Then the suggestion will be "if stat() 
returns a link, use os.path.realpath() if you want to resolve it as far as 
possible".)

> The questions for me are whether os.readlink() should also read
> junctions and exactly what follow_symlinks means in Windows. We have a
> complicated story to tell if follow_symlinks=False (lstat) opens any
> reparse point or opens just name-surrogate reparse points, and islink()
> is made consistent with this, but then readlink() doesn't work.

I don't think it's that complicated:
* os.lstat() will not traverse any links or reparse points
* os.stat() will traverse any links and reparse points supported by the OS, or 
else return the same as os.lstat()
* os.readlink() can read the target of a symlink or (on Windows) junction point

> If junctions are handled as symlinks, then islink(), readlink(),
> symlink() would be used to copy a junction 'link' while copying a tree
> (e.g. shutil.copytree with symlinks=True). This would transform
> junctions into directory symlinks. In this case, we potentially have a
> problem that relative symlinks in the tree no longer target the same
> files when accessed via a directory symlink instead of a junction. No
> one thinks about this problem on the POSIX side because it would be
> weird to copy a mountpoint as a symlink. In POSIX, a mountpoint is
> always seen as just a directory and always traversed.

This isn't difficult to handle specifically if we want to, though, since the 
stat result now includes the reparse tag. And you're right, we probably have to 
handle it.

>> I'm still not convinced that this is what we want to do. I don't
>> have a true Linux machine handy to try it out (Python 3.6 and 3.7 on
>> WSL behave exactly like the semantics I'm proposing, but that may
>> just be because it's the Windows kernel below it).

> ... This is a decision in WSL's drvfs file-system driver, and I have to
> assume it's intentional.

I assumed it was intentional as well, though it'll almost certainly be based on 
pragmatically getting things to work (e.g. the '/mnt/c/Document and Settings' 
junction... though now I try it that those don't actually work...)

>> ismount() is currently not true for junctions. And I can't find any
>> reference that says that POSIX symlinks can't point to directories,
>
> Our current implementation for junctions is based on GetVolumePathNameW,
> which will be true for junctions that use the "Volume{...}" name to
> mount the file-system root directory. That's a volume mount point.
> 
> I don't know why someone decided that's the sum total of "mount point"
> in Windows. DOS drives and UNC drives can refer to arbitrary file system
> directories. They don't have to refer to file-system root directory. We
> can have "W:" -> "\\??\\C:\\Windows", etc.
> 
> Per the docs, a mount point for ismount() is a "point in a file system
> where a different file system has been mounted". The mounted directory
> doesn't have to be the root directory of the file system. I'd relax this
> definition to include all "hard" name grafting links to other
> directories, even within the same file system. What matter to me is the
> semantics of how this differs from the soft name grafting of a symlink.

I think the intent is that it's mounted the root of another file system. There 
was discussion of just using the reparse tag in issue9035, but it looks like 
from msg138197 that returning True for regular directory links was not the 
intent (despite the tests in that message being insufficient).

> If follow_symlinks=False applies to name surrogates, then a junction
> would be detectable via

[issue37876] Tests for Rot13 codec

2019-08-16 Thread Zeth



New submission from Zeth :

Julius Caesar might have written the Rot13 codec, but he forgot to write unit 
tests, dragging down test coverage.

--
components: Tests
messages: 349874
nosy: zeth
priority: normal
pull_requests: 15033
severity: normal
status: open
title: Tests for Rot13 codec
type: enhancement
versions: Python 3.9

___
Python tracker 

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

[issue37874] json traceback on a float

2019-08-16 Thread af



af  added the comment:

I understand, thanks.

--

___
Python tracker 

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

[issue37871] 40 * 473 grid of "é" has a single wrong character on Windows



Steve Dower  added the comment:

I'd rather keep encoding incrementally, and reduce the length of each attempt 
until the last UTF-8 character does not have its top bit set (i.e. is the final 
character in a multi-byte sequence).

Otherwise the people who like to print >2GB worth of data to the console will 
complain about the memory error :)

--

___
Python tracker 

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

[issue37874] json traceback on a float

2019-08-16 Thread Eric V. Smith



Eric V. Smith  added the comment:

I think Serhiy means 1.e-8 is not valid.

The spec says that at least one digit is required in the "frac" part, after the 
decimal.

--
nosy: +eric.smith

___
Python tracker 

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

[issue37875] gzip module any difference for compressing png file in version 2.X and 3.X

2019-08-16 Thread Zachary Ware



Zachary Ware  added the comment:

Sorry, but your report is unclear.  Are you asking if there is any difference, 
or are you reporting a difference?  If the former, this is not the correct 
forum for such questions, please try python-l...@python.org or StackOverflow 
instead.  If the latter, you'll need to include sample code and data that shows 
the issue.

--
components:  -2to3 (2.x to 3.x conversion tool)
nosy: +zach.ware
type: performance -> 

___
Python tracker 

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

[issue37824] IDLE: Handle Shell input warnings properly.

2019-08-16 Thread Terry J. Reedy



Terry J. Reedy  added the comment:

The triple (or double, see below) printing seems like a pure bug to be fixed.  
A fix could be a separate PR to be merged 'immediately'.

But there is a complication with insertion location.  My bug claim was based on 
a one line statement, where 'before' looks wrong and 'after', as in REPL, right.

>>> 
Warning (from warnings module):  # Printed 3 times, 2 deleted.
  File "", line 1
0 is 0
SyntaxWarning: "is" with a literal. Did you mean "=="?
0 is 0
True

>>> 0 is 0  # REPL
:1: SyntaxWarning: "is" with a literal. Did you mean "=="?
True

But now consider a more realistic compound statement.

>>> if 0 is 0:  # REPL
...   print('true')
...
:1: SyntaxWarning: "is" with a literal. Did you mean "=="?
true

With IDLE, a warning is printed *before* the user enters a blank line to signal 
end of statement.

>>> 
Warning (from warnings module):  # Only printed TWICE!.
  File "", line 1
if 0 is 0:
SyntaxWarning: "is" with a literal. Did you mean "=="?
if 0 is 0:
print('true')
|< cursor location

A user could edit the condition, add more to the suite, or hit return. In the 
latter 2 cases, the warnings are repeated.  In this case, the insertion seems 
like the best that can be done.

Perhaps the msg349845 comment about run.show_warnings collecting warnings for 
possible delayed display applies to pyshell.show_warnings.  Or the warning 
could be put in a popup, though I do not especially like the idea of that.  Or 
it could be logged to a separate Warnings window, and a red "Warning logged' 
flashed on the status bar.

I suspect that this case is why a fake prompt was previously tacked on to the 
end of the warning, though I also suspect these complications are why shell 
input warnings were relegated to a possibly non-existent console (where the 
fake prompt is nonsense).

Behavior is the same with '\e' and DeprecationWarning.

This example further convinces me that multiline shell input should be isolated 
from both prompts and intermixed outputs.  I plan to open that issue later 
today.

--

___
Python tracker 

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

[issue37875] gzip module any difference for compressing png file in version 2.X and 3.X

2019-08-16 Thread Sivaprabu Ganesan



New submission from Sivaprabu Ganesan :

gzip module any difference for compressing png file in version 2.X and 3.X

--
components: 2to3 (2.x to 3.x conversion tool)
messages: 349868
nosy: Sivaprabu Ganesan, sjoerd
priority: normal
severity: normal
status: open
title: gzip module any difference for compressing png file in version 2.X and 
3.X
type: performance
versions: Python 2.7

___
Python tracker 

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

[issue37874] json traceback on a float

2019-08-16 Thread Serhiy Storchaka



Serhiy Storchaka  added the comment:

1.0e-8 is not a format for numbers in JSON. See RFC 7159 
(https://tools.ietf.org/html/rfc7159.html#section-6):

  number = [ minus ] int [ frac ] [ exp ]

  decimal-point = %x2E   ; .

  digit1-9 = %x31-39 ; 1-9

  e = %x65 / %x45; e E

  exp = e [ minus / plus ] 1*DIGIT

  frac = decimal-point 1*DIGIT

  int = zero / ( digit1-9 *DIGIT )

  minus = %x2D   ; -

  plus = %x2B; +

  zero = %x30; 0

--
nosy: +serhiy.storchaka
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

___
Python tracker 

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

[issue37874] json traceback on a float

2019-08-16 Thread af



Change by af :


--
type: crash -> behavior

___
Python tracker 

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

[issue37874] json traceback on a float

2019-08-16 Thread af



New submission from af :

json.loads traceback with:

[In [16]: json.loads("[1.e-8]")
---
JSONDecodeError   Traceback (most recent call last)
 in ()
> 1 json.loads("[1.e-8]")

/scr/fonari/2019-4/internal/lib/python3.6/json/__init__.py in loads(s, 
encoding, cls, object_hook, parse_float, parse_int, parse_constant, 
object_pairs_hook, **kw)
352 parse_int is None and parse_float is None and
353 parse_constant is None and object_pairs_hook is None and 
not kw):
--> 354 return _default_decoder.decode(s)
355 if cls is None:
356 cls = JSONDecoder

/scr/fonari/2019-4/internal/lib/python3.6/json/decoder.py in decode(self, s, _w)
337 
338 """
--> 339 obj, end = self.raw_decode(s, idx=_w(s, 0).end())
340 end = _w(s, end).end()
341 if end != len(s):

/scr/fonari/2019-4/internal/lib/python3.6/json/decoder.py in raw_decode(self, 
s, idx)
353 """
354 try:
--> 355 obj, end = self.scan_once(s, idx)
356 except StopIteration as err:
357 raise JSONDecodeError("Expecting value", s, err.value) from 
None

JSONDecodeError: Expecting ',' delimiter: line 1 column 3 (char 2)

Works with json.loads("[1.0e-8]") and json.loads("[1e-8]")

--
components: Library (Lib)
messages: 349866
nosy: af
priority: normal
severity: normal
status: open
title: json traceback on a float
type: crash
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

[issue29535] datetime hash is deterministic in some cases

2019-08-16 Thread Tim Peters



Tim Peters  added the comment:

I'm with Mark:  leave numeric hashes alone.  There's no reason to change them, 
and in addition to what Mark wrote it's a positively Good Thing that `hash(i) 
== i` for all sufficiently small ints.  Not only is that efficient to compute, 
it guarantees there are no collisions _at all_ in the common case of a dict 
indexed by a contiguous range of integers.

The _purpose_ of `hash()` in Python isn't to create an illusion of randomness, 
it's to support efficient dicts and sets.  Mucking with string hashes was a 
pragmatic hack to alleviate concerns about DOS attacks specific to 
string-indexed dicts.  A better technical solution to that would have been to 
introduce a different flavor of dict with guaranteed good worst-case behaviors, 
but, pragmatically, a great many users would never realize that's what they 
really wanted, and it wouldn't have helped pre-existing code at all.

But there's no reason to spread that hack beyond the use cases that needed it, 
and much reason not to.

--
nosy: +tim.peters

___
Python tracker 

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

[issue37873] unittest: execute tests in parallel

2019-08-16 Thread D. A. Pellegrino



New submission from D. A. Pellegrino :

The unittest documentation makes reference to a potential parallelization 
feature:

"Note that shared fixtures do not play well with [potential] features like test 
parallelization and they break test isolation. They should be used with care." 
(https://docs.python.org/3/library/unittest.html)

However, it seems that executing tests in parallel is not yet a feature of 
unittest. This enhancement request is to add parallel execution of tests to 
unittest.

A command line option may be a good interface. Ideally, it would be compatible 
with test discovery. Outside of the Python ecosystem, a common practice is to 
define test cases in a Makefile and then execute GNU Make with the '-j' flag 
(https://www.gnu.org/software/make/manual/html_node/Parallel.html#Parallel). 
Adding such an option to unittest would be a convenience and may save the 
effort of bringing in additional libraries or tools for parallel unit test 
execution.

--
components: Library (Lib)
messages: 349864
nosy: user93448
priority: normal
severity: normal
status: open
title: unittest: execute tests in parallel
type: enhancement
versions: Python 3.9

___
Python tracker 

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

[issue37703] Inconsistent gather with child exception



Vinay Sharma  added the comment:

Hi Andrew,
Thanks for replying!

I understand that the behavior change is not backward compatible. But the 
current behavior is a bit ambiguous ad mentioned by Dimitri, therefore I have 
updated the documentation and opened a Pull request.

I would be very glad if you could review it.
Thanks!

Also, would adding an optional argument like force_cancel=False to 
``gather.cancel``, which won't return even if gather is done be backward 
compatible. Should I open a PR with this change also, so that you can better 
review it and see if it looks good.

--

___
Python tracker 

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

[issue37872] Move statics in Python/import.c to top of the file

2019-08-16 Thread Josh Rosenberg



Change by Josh Rosenberg :


--
title: Move statitics in Python/import.c  to top of the file -> Move statics in 
Python/import.c to top of the file

___
Python tracker 

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

[issue37703] Inconsistent gather with child exception



Change by Vinay Sharma :


--
pull_requests: +15031
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/15312

___
Python tracker 

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

[issue37872] Move statitics in Python/import.c to top of the file



Joannah Nanjekye  added the comment:

Keeping this until the PR https://github.com/python/cpython/pull/15057 is 
merged.

--

___
Python tracker 

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

[issue37872] Move statitics in Python/import.c to top of the file



Joannah Nanjekye  added the comment:

Relevant comment from @gnprice.



I think it would be better to make that as a separate change. This style where 
they're block-local is the way the existing code works, which keeps the diff 
simple.

It's also the way that every use of _Py_IDENTIFIER in this file works. So I 
think the cleanest way to change the style would be to sweep through this whole 
file (or more) in one PR, separate from any substantive changes.

--

___
Python tracker 

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

[issue37872] Move statitics in Python/import.c to top of the file



New submission from Joannah Nanjekye :

Following a PR review here: https://github.com/python/cpython/pull/15057 by 
@ericsnowcurrently i.e :

Please move both these statics to the top of the file (next to CACHEDIR) as 
globals.

To keep the diff in the above PR simple, I am tracking this refactor in this 
issue.

--
assignee: nanjekyejoannah
components: Library (Lib)
messages: 349859
nosy: eric.snow, nanjekyejoannah, serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: Move statitics in Python/import.c  to top of the file
type: enhancement
versions: Python 3.9

___
Python tracker 

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

[issue37824] IDLE: Handle Shell input warnings properly.

2019-08-16 Thread Tal Einat



Tal Einat  added the comment:

Il take a look at this. I've very recently gone through the relevant parts of 
the code and I should be able to figure it it efficiently.

--

___
Python tracker 

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

[issue37790] subprocess.Popen() is extremely slow

2019-08-16 Thread Antoine Pitrou



Antoine Pitrou  added the comment:

Can you post a simple script showcasing the performance degradation?

--
nosy: +pitrou

___
Python tracker 

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

[issue37540] vectorcall: keyword names must be strings

2019-08-16 Thread Jeroen Demeyer



Change by Jeroen Demeyer :


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

[issue37703] Inconsistent gather with child exception

2019-08-16 Thread Andrew Svetlov



Andrew Svetlov  added the comment:

The behavior change is not backward compatible, we cannot apply it.

Also, please use github pull requests for proposing a patch: 
https://devguide.python.org/pullrequest/

--

___
Python tracker 

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

[issue17305] IDNA2008 encoding is missing

2019-08-16 Thread Andrew Svetlov



Andrew Svetlov  added the comment:

There is no consensus yet, IMHO.
There is a lack of resources for the issue.

--

___
Python tracker 

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

[issue37540] vectorcall: keyword names must be strings

2019-08-16 Thread miss-islington



miss-islington  added the comment:


New changeset 0567786d26348aa7eaf0ab1b5d038fdabe409d92 by Miss Islington (bot) 
(Jeroen Demeyer) in branch 'master':
bpo-37540: vectorcall: keyword names must be strings (GH-14682)
https://github.com/python/cpython/commit/0567786d26348aa7eaf0ab1b5d038fdabe409d92


--
nosy: +miss-islington

___
Python tracker 

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

[issue29535] datetime hash is deterministic in some cases

2019-08-16 Thread Mark Dickinson



Mark Dickinson  added the comment:

> Why so?

Python's hash needs to obey the invariant that `hash(x) == hash(y)` for any two 
hashable objects with `x == y`. That makes life particularly hard for numeric 
types, because there are a number of *different* numeric types where equality 
can hold across those types. This includes not just built-in types, but third 
party types as well (think of NumPy, gmpy2, SymPy, and other libraries 
providing numbers that need to compare equal to Python numbers with the same 
value).

So for example, `hash(1.5)`,  `hash(Decimal("1.5"))`, `hash(Fraction(3, 2))`, 
`hash(1.5 + 0j)`, `hash(numpy.float32(1.5))`, `hash(bigfloat.BigFloat(1.5, 
precision=200))` must _all_ be equal to one another within a single running 
Python process.

Moreover, hash computation needs to be efficient for common types like floats 
and integers, while also not being impossibly slow for other types. (Early 
versions of Decimal's hash did a check to see whether the Decimal instance was 
an exact integer, and if so, converted that Decimal instance to an integer 
before taking its hash. But doing that with `Decimal(1e99)` doesn't go 
well.)

It would definitely be *possible* to:

- compute a hash in a cross-type-compatible way
- do some sort of uniform post-processing of that hash, incorporating 
information from a per-process random salt

The operations described by Melissa O'Neill in her PCG paper give ideas for 
some ways to do such post-processing: regard the hash and the salt as together 
forming a 128-bit integer, and then collapse that 128-integer down to a 64-bit 
integer using one of the PCG post-processing methods. Note that as far as I 
know there's been no validation of those methods from a cryptographic (rather 
than a statistical) perspective.

However, it would be significant work, be disruptive not just to CPython, but 
to 3rd party packages and to other Python implementations, would slow down 
common hashing operations, and would increase the amount and the complexity of 
code that has to be maintained into the future.

So there's no shortage of reasons *not* to change the numeric hash. What I 
think we're lacking is a single reason *to* change it. Can you give a plausible 
example of a situation where the predictability of the numeric hash can lead to 
possible security issues?

See also the recent issue #37807.

> but *not* if my keys, say, are tuples of strings

Bad example. :-) The hash of a tuple is based on the hash of its contents. So 
if those contents are strings, the tuple benefits from the string hash 
randomization.

mirzakhani:~ mdickinson$ python -c "print(hash(('abc', 'def')))"
-824966383135019564
mirzakhani:~ mdickinson$ python -c "print(hash(('abc', 'def')))"
-5971473524922642515
mirzakhani:~ mdickinson$ python -c "print(hash(('abc', 'def')))"
5384650403450490974

--

___
Python tracker 

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

[issue37703] Inconsistent gather with child exception



Change by Vinay Sharma :


Added file: https://bugs.python.org/file48548/gather_cancel_code.patch

___
Python tracker 

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

[issue37703] Inconsistent gather with child exception



Vinay Sharma  added the comment:

Hi Dimitri,
You are right, gather.cancel() doesn't work once it has propagated an 
exception. This happens because after propagating the exception to the caller, 
gather is marked as done. And cancel doesn't work after a Future object has 
been marked done.
You can test the same by printing the return value of gather.cancel(). It will 
be False

I also believe that the documentation of gather should explicitly mention this. 
But, depending on the fact, whether this is an expected behaviour, current code 
base might also need changes.

Therefore I have created two patches, one updating the current documentation 
according to the current functionality, and other changing the codebase which 
supports cancelling even after raising exceptions.

I will try to contact one of the core developers on deciding which one is the 
way to go.

--
keywords: +patch
nosy: +vinay0410
Added file: https://bugs.python.org/file48547/gather_cancel_doc.patch

___
Python tracker 

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

[issue37256] urllib.request.Request documentation erroneously refers to the "final two"

2019-08-16 Thread miss-islington



miss-islington  added the comment:


New changeset f9919121460bffc04f935dbdb85f0af3ffbd3ddf by Miss Islington (bot) 
in branch '3.8':
bpo-37256: Wording in Request class docs (GH-14792)
https://github.com/python/cpython/commit/f9919121460bffc04f935dbdb85f0af3ffbd3ddf


--

___
Python tracker 

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

[issue37256] urllib.request.Request documentation erroneously refers to the "final two"

2019-08-16 Thread Senthil Kumaran



Senthil Kumaran  added the comment:

Thank you for the patch, CuriousLearner.

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

[issue37764] email.Message.as_string infinite loop