[issue37808] Deprecate unbound super methods

2019-08-10 Thread Zackery Spytz


Change by Zackery Spytz :


--
nosy: +ZackerySpytz

___
Python tracker 

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



[issue37808] Deprecate unbound super methods

2019-08-10 Thread Zackery Spytz


Change by Zackery Spytz :


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

___
Python tracker 

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



[issue37814] typing module: empty tuple syntax is undocumented

2019-08-10 Thread Guido van Rossum

Guido van Rossum  added the comment:

That’s correct. Mind making a PR?

--

___
Python tracker 

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



[issue37818] Behaviors of binary bitwise operators contradicting documentation

2019-08-10 Thread Steven D'Aprano


Steven D'Aprano  added the comment:

bools are integers, specifically they are a subclass of int:

py> isinstance(True, int)
True
py> issubclass(bool, int)
True

so the behaviour is correct.

--
nosy: +steven.daprano
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



[issue37814] typing module: empty tuple syntax is undocumented

2019-08-10 Thread Karthikeyan Singaravelan


Change by Karthikeyan Singaravelan :


--
nosy: +gvanrossum, levkivskyi

___
Python tracker 

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



[issue37816] f-string documentation not fully accurate

2019-08-10 Thread Karthikeyan Singaravelan


Change by Karthikeyan Singaravelan :


--
nosy: +eric.smith

___
Python tracker 

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



[issue37759] Polish whatsnew for 3.8

2019-08-10 Thread Raymond Hettinger


Change by Raymond Hettinger :


--
pull_requests: +14933
pull_request: https://github.com/python/cpython/pull/15204

___
Python tracker 

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



[issue37818] Behaviors of binary bitwise operators contradicting documentation

2019-08-10 Thread John Rogers


New submission from John Rogers :

In Python Language Reference (version 3.7), section 6.9 it states that the 
arguments of binary bitwise operators must be integers. However, the following 
expressions work without error:

True & False
False | True
True ^ True

Each produces a boolean result (not integer) (False, True, False, 
respectively). Also I find that mixing booleans and integers does work too, 
though this time it produces integers.

One can easily test it on Python home page's console window. I also tested it 
on my Linux box running version 3.5.3. So it appears that it has been 
overlooked for quite some time!

As an aside: I do assume that boolean values are *distinct* from integers. If 
they are not, then my apologies!

--
assignee: docs@python
components: Documentation
messages: 349372
nosy: The Blue Wizard, docs@python
priority: normal
severity: normal
status: open
title: Behaviors of binary bitwise operators contradicting documentation
type: behavior
versions: Python 3.5, Python 3.7

___
Python tracker 

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



[issue37817] create_pipe_connection and start_serving_pipe not documented

2019-08-10 Thread Paul Martin


New submission from Paul Martin :

I found these two methods in the windows_events code for asyncio. Is there a 
reason why they don't seem to be documented, and are not included in 
AbstractServer? They provide a good Windows alternative to create_unix_server & 
create_unix_connection for inter-process communication.

--
components: asyncio
messages: 349371
nosy: asvetlov, primal, yselivanov
priority: normal
severity: normal
status: open
title: create_pipe_connection and start_serving_pipe not documented
versions: Python 3.5, Python 3.6, Python 3.7, 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



[issue37816] f-string documentation not fully accurate

2019-08-10 Thread Glenn Linderman


New submission from Glenn Linderman :

I noticed the following description for f-strings:

> Escape sequences are decoded like in ordinary string literals (except when a 
> literal is also marked as a raw string). After decoding, the grammar for the 
> contents of the string is:

followed by lots of stuff, followed by

> Backslashes are not allowed in format expressions and will raise an error:
> f"newline: {ord('\n')}"  # raises SyntaxError

If f-strings are processed AS DESCRIBED, the \n would never seen by the format 
expression... but in fact, it does produce an error.

PEP 498 has a more accurate description, that the {} parsing actually happens 
before the escape processing. The string or raw-string escape processing is 
done only to the literal string pieces.

So the string content is first parsed for format expressions enclosed in {}, on 
the way, converting {{ and }} to { and } in the literal parts of the string, 
and then the literal parts are treated exactly like independent string literals 
(with regular or raw-string escaping performed), to be concatenated with the 
evaluation of the format expressions, and subsequent literal parts.

The evaluation of the format expressions presently precludes the use of # and \ 
for comments and escapes, but otherwise tries to sort of by the same as a 
python expression possibly followed by a format mini-language part.  I am not 
the expert here, just the messenger.

--
assignee: docs@python
components: Documentation
messages: 349370
nosy: docs@python, v+python
priority: normal
severity: normal
status: open
title: f-string documentation not fully accurate
versions: Python 3.6, Python 3.7, 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



[issue37815] 'Make Test' error while trying to install Python 3.7.4 on Linux Mint

2019-08-10 Thread Missono Dell


Missono Dell  added the comment:

Ran 38 tests in 1.058s

FAILED (failures=1)
test test_pdb failed
1 test failed again:
test_pdb

== Tests result: FAILURE then FAILURE ==

403 tests OK.

1 test failed:
test_pdb

12 tests skipped:
test_devpoll test_kqueue test_msilib test_ossaudiodev
test_startfile test_tix test_tk test_ttk_guionly test_winconsoleio
test_winreg test_winsound test_zipfile64

1 re-run test:
test_pdb

Total duration: 6 min 5 sec
Tests result: FAILURE then FAILURE
Makefile:1076: recipe for target 'test' failed
make: *** [test] Error 2


I can't finish installing Python with sudo make install because of this error

--
title: 'Make Test' error whe trying to install Python 3.7.4 on Linux Mint -> 
'Make Test' error while trying to install Python 3.7.4 on Linux Mint

___
Python tracker 

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



[issue16837] Number ABC can be instantiated

2019-08-10 Thread Guido van Rossum


Guido van Rossum  added the comment:

Let's not do this. We've survived this long.

--

___
Python tracker 

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



[issue37815] 'Make Test' error whe trying to install Python 3.7.4 on Linux Mint

2019-08-10 Thread Missono Dell


New submission from Missono Dell :

Ran 38 tests in 1.058s

FAILED (failures=1)
test test_pdb failed
1 test failed again:
test_pdb

== Tests result: FAILURE then FAILURE ==

403 tests OK.

1 test failed:
test_pdb

12 tests skipped:
test_devpoll test_kqueue test_msilib test_ossaudiodev
test_startfile test_tix test_tk test_ttk_guionly test_winconsoleio
test_winreg test_winsound test_zipfile64

1 re-run test:
test_pdb

Total duration: 6 min 5 sec
Tests result: FAILURE then FAILURE
Makefile:1076: recipe for target 'test' failed
make: *** [test] Error 2

--
components: Installation
messages: 349367
nosy: Missono Dell
priority: normal
severity: normal
status: open
title: 'Make Test' error whe trying to install Python 3.7.4 on Linux Mint
type: compile error
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



[issue37814] typing module: empty tuple syntax is undocumented

2019-08-10 Thread Josh Holland


New submission from Josh Holland :

The empty tuple syntax in type annotations, `Tuple[()]`, is not obvious from 
the examples given in the documentation (I naively expected `Tuple[]` to work); 
it has been documented in PEP 484[1] and in mypy[2], but not in the 
documentation for the typing module.

[1]: https://www.python.org/dev/peps/pep-0484/#the-typing-module
[2]: https://github.com/python/mypy/pull/4313

--
assignee: docs@python
components: Documentation
messages: 349366
nosy: anowlcalledjosh, docs@python
priority: normal
severity: normal
status: open
title: typing module: empty tuple syntax is undocumented
type: enhancement

___
Python tracker 

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



[issue37765] IDLE: Include keywords in __main__ autocomplete list

2019-08-10 Thread Terry J. Reedy


Terry J. Reedy  added the comment:

Raymond, since there is no proposal to 'add __main__', I don't understand your 
response.  For the case in question, the completion list continues to be based 
on the keys in __main__.__builtins__.__dict__, and main__.__dict__, as it 
always has been.

--

___
Python tracker 

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



[issue37756] Error 0x80070643 when installing

2019-08-10 Thread Terry J. Reedy


Terry J. Reedy  added the comment:

I seems to me that Python Setup and Usage, Using Python on Windows should have 
a section for install failure and MS 0x8XXX install errors.  Then I and 
others on python-list could tell people to start with that.

--

___
Python tracker 

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



[issue37765] IDLE: Include keywords in __main__ autocomplete list

2019-08-10 Thread Raymond Hettinger


Raymond Hettinger  added the comment:

Since the word "main" is short and since the dunder prefix is common, I don't 
expect to get much value out of adding '__main__'.ISTM, this just increases 
the risk of a false positive for a given dunder method.

> To be clear, I'm currently -1 on this suggestion.

I concur.

--

___
Python tracker 

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



[issue37765] IDLE: Include keywords in __main__ autocomplete list

2019-08-10 Thread Terry J. Reedy


Terry J. Reedy  added the comment:

After more research, I am more inclined to add the keywords to the global 
identifiers list. The IDLE doc says that they should be present.

"Show Completions
 Open a scrollable list allowing selection of keywords and attributes."

If this issue were rejected, the line above would have to be changed.  (Other 
needed updates are another issue.)  It was added to idlelib/help.txt (since 
replaced by help.html) by KBK in

Revision: 209de1f6ca1beaaa6b5eeb413f02e9c8c334ee50
Author: Kurt B. Kaiser 
Date: 2/8/2007 5:58:18 PM
Message: ... Added AutoComplete instructions to IDLE Help.

(I checked 2.6 fetch_completions and keywords were not actually included in the 
global ('') list.)

The completion menu entry was copied to idle.rst in patches for #5066 by 
Jessica McKeller and Todd Rovito.  Both docs were updated.  Another 5 people, 
at least, reviewed, including 3 core developers.  It was committed by a 4th, 
Andrew Svetlov.  So 9 people besides me did not notice the discrepancy and may 
have thought 'keywords, fine', like I have been.

One can invoke Show Completions not following anything to get a list of names 
that one should not use.  For that use, keywords should be included.  This list 
currently has 230+ identifiers, 150+ all lowercase.  keyword.kwlist would add 
32 (35 - 3 builtins).  It is not a huge increase.

--
nosy: +cheryl.sabella
stage: patch review -> test needed

___
Python tracker 

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



[issue37813] PEP 7 line-breaking with binary operations contradicts Knuth's rule

2019-08-10 Thread Géry

New submission from Géry :

I have just read PEP 7 and noticed that its line-breaking recommandation in 
presence of binary operations seems to contradict its analogue in PEP 8 which 
follows Knuth's rule.

PEP 7 (https://www.python.org/dev/peps/pep-0007/#code-lay-out):

> When you break a long expression at a binary operator, the operator
> goes at the end of the previous line, and braces should be formatted
> as shown. E.g.:
> 
> if (type->tp_dictoffset != 0 && base->tp_dictoffset == 0 &&
> type->tp_dictoffset == b_size &&
> (size_t)t_size == b_size + sizeof(PyObject *))
> {
> return 0; /* "Forgive" adding a __dict__ only */
> }

PEP 8 
(https://www.python.org/dev/peps/pep-0008/#should-a-line-break-before-or-after-a-binary-operator):

> To solve this readability problem, mathematicians and their
> publishers follow the opposite convention. Donald Knuth explains the
> traditional rule in his Computers and Typesetting series: "Although
> formulas within a paragraph always break after binary operations and
> relations, displayed formulas always break before binary operations"
> [3].
> 
> Following the tradition from mathematics usually results in more
> readable code:
> 
> # Yes: easy to match operators with operands
> income = (gross_wages
>   + taxable_interest
>   + (dividends - qualified_dividends)
>   - ira_deduction
>   - student_loan_interest)
> In Python code, it is permissible to break before or after a binary
> operator, as long as the convention is consistent locally. For new
> code Knuth's style is suggested.

--
assignee: docs@python
components: Documentation
messages: 349361
nosy: docs@python, maggyero
priority: normal
severity: normal
status: open
title: PEP 7 line-breaking with binary operations contradicts Knuth's rule
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



[issue37802] micro-optimization of PyLong_FromSize_t()

2019-08-10 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



[issue37812] Make implicit returns explicit in longobject.c (in CHECK_SMALL_INT)

2019-08-10 Thread Greg Price


Greg Price  added the comment:

I've just sent GH-15203 which is the first of two patches for this. It's quite 
small.

The second patch, which completes the change, is also small:
https://github.com/gnprice/cpython/commit/c6b905104

It depends on the first one, so I think the easiest is for me to send it as a 
PR after the first is merged? Happy to do another workflow if that'd make 
review easier. (I don't see guidance in the devguide on handling a sequence of 
patches, so I'm making this up.)

--
nosy: +aeros167, mark.dickinson, sir-sigurd

___
Python tracker 

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



[issue37812] Make implicit returns explicit in longobject.c (in CHECK_SMALL_INT)

2019-08-10 Thread Greg Price


Change by Greg Price :


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

___
Python tracker 

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



[issue37812] Make implicit returns explicit in longobject.c (in CHECK_SMALL_INT)

2019-08-10 Thread Greg Price


New submission from Greg Price :

In longobject.c we have the following usage a few times:

PyObject *
PyLong_FromLong(long ival)
{
PyLongObject *v;
// ... more locals ...

CHECK_SMALL_INT(ival);

if (ival < 0) {
/* negate: can't write this as abs_ival = -ival since that
   invokes undefined behaviour when ival is LONG_MIN */
abs_ival = 0U-(unsigned long)ival;
sign = -1;
}
else {
// ... etc. etc.

The CHECK_SMALL_INT macro contains a `return`, so the function can actually 
return before it reaches any of the other code.

#define CHECK_SMALL_INT(ival) \
do if (-NSMALLNEGINTS <= ival && ival < NSMALLPOSINTS) { \
return get_small_int((sdigit)ival); \
} while(0)

That's not even an error condition -- in fact it's the fast, hopefully 
reasonably-common, path.

An implicit return like this is pretty surprising for the reader. And it only 
takes one more line (plus a close-brace) to make it explicit:

if (IS_SMALL_INT(ival)) {
return get_small_int((sdigit)ival);
}

so that seems like a much better trade.

Patch written, will post shortly.

--
components: Interpreter Core
messages: 349359
nosy: Greg Price
priority: normal
severity: normal
status: open
title: Make implicit returns explicit in longobject.c (in CHECK_SMALL_INT)
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



[issue37764] email.Message.as_string infinite loop

2019-08-10 Thread Abhilash Raj


Abhilash Raj  added the comment:

Adding security label since this can cause DOS.

--
type:  -> security

___
Python tracker 

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



[issue37811] [FreeBSD, OSX] Socket module: incorrect usage of poll(2)

2019-08-10 Thread Artem Khramov


Change by Artem Khramov :


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

___
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-10 Thread Abhilash Raj


Abhilash Raj  added the comment:

Closing this since teh PRs are merged.

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



[issue37811] [FreeBSD, OSX] Socket module: incorrect usage of poll(2)

2019-08-10 Thread Artem Khramov


New submission from Artem Khramov :

FreeBSD implementation of poll(2) restricts timeout argument to be either zero, 
or positive, or equal to INFTIM (-1).

Unless otherwise overridden, socket timeout defaults to -1. This value is then 
converted to milliseconds (-1000) and used as argument to the poll syscall.

poll returns EINVAL (22), and the connection fails.

I have discovered this bug during the EINTR handling testing, and have 
naturally found a repro code in https://bugs.python.org/issue23618 (see 
connect_eintr.py, attached). On GNU/Linux, the example runs as expected.

--
files: connect_eintr.py
messages: 349356
nosy: akhramov
priority: normal
severity: normal
status: open
title: [FreeBSD, OSX] Socket module: incorrect usage of poll(2)
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9
Added file: https://bugs.python.org/file48537/connect_eintr.py

___
Python tracker 

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



[issue37756] Error 0x80070643 when installing

2019-08-10 Thread Steve Dower


Steve Dower  added the comment:

I can't see anything specific in that log file, but if you can provide the 
"Python 3.7.4 (32-bit)_20190804181255_000_core_JustForMe.log" file, that should 
be able to help.

(For others who may have to triage these in the future, the main thing you'll 
find in this log file is when the installer is attempting to upgrade from an 
AllUsers install to a JustForMe install, which almost always fails. But since 
this is upgrading from a previous JustForMe, it's not that.)

--

___
Python tracker 

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



[issue37810] ndiff reports incorrect location when diff strings contain tabs

2019-08-10 Thread Raymond Hettinger


Raymond Hettinger  added the comment:

This seems like a reasonable suggestion to me.  Am not sure whether it should 
be backported.

Tim, what do you think?

--
assignee:  -> tim.peters
components: +Library (Lib)
nosy: +rhettinger, tim.peters

___
Python tracker 

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



[issue37810] ndiff reports incorrect location when diff strings contain tabs

2019-08-10 Thread Anthony Sottile


Change by Anthony Sottile :


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

___
Python tracker 

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



[issue19692] Rename Py_SAFE_DOWNCAST

2019-08-10 Thread Sanyam Khurana


Change by Sanyam Khurana :


--
nosy: +CuriousLearner
versions: +Python 3.7, Python 3.8, Python 3.9 -Python 3.4

___
Python tracker 

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



[issue37810] ndiff reports incorrect location when diff strings contain tabs

2019-08-10 Thread Anthony Sottile


New submission from Anthony Sottile :

Here's an example

from difflib import ndiff


def main():
x = '\tx\t=\ty\n\t \t \t^'
y = '\tx\t=\ty\n\t \t \t^\n'
print('\n'.join(
line.rstrip('\n') for line in
ndiff(x.splitlines(True), y.splitlines(True)))
)


if __name__ == '__main__':
exit(main())


Current output:

$ python3.8 t.py
x   =   y
-   ^
+   ^
?+


Expected output:

$ ./python t.py
x   =   y
-   ^
+   ^
?+


Found this while implementing a similar thing for flake8 here: 
https://gitlab.com/pycqa/flake8/merge_requests/339 and while debugging with 
pytest

--
messages: 349353
nosy: Anthony Sottile
priority: normal
severity: normal
status: open
title: ndiff reports incorrect location when diff strings contain tabs
versions: Python 3.7, 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



[issue37792] xml.etree.ElementTree.Element.__eq__ does compare only objects identity

2019-08-10 Thread Stefan Behnel


Stefan Behnel  added the comment:

Right. If you want to compare XML trees for equality, either write your own 
deep-tree comparison function, or use something like doctestcompare, or use a 
C14N serialisation (which is now part of Py3.8). Whichever suits your needs.

https://github.com/lxml/lxml/blob/master/src/lxml/doctestcompare.py

https://docs.python.org/3.8/library/xml.etree.elementtree.html#xml.etree.ElementTree.canonicalize

--

___
Python tracker 

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



[issue37792] xml.etree.ElementTree.Element.__eq__ does compare only objects identity

2019-08-10 Thread Serhiy Storchaka


Serhiy Storchaka  added the comment:

In some applications the order of attributes matters, and in others it does 
not. So the equality check is application dependent.

--
nosy: +serhiy.storchaka

___
Python tracker 

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



[issue37807] Make hash() return a non-negative number

2019-08-10 Thread Tim Peters


Tim Peters  added the comment:

Well, I have no code that would benefit from this change.  What's the point?  
Sure, I use _parts_ of hash codes at times, but, e.g.,

index = the_hash_code & SOME_LOW_BIT_MASK

in Python couldn't care less about the sign of `the_hash_code` - it returns a 
non-negative int regardless.  The same applies if, e.g., SOME_LOW_BIT_MASK is 
`(1 << sys.hash_info.hash_bits) - 1`, giving a full-width non-negative hash 
without losing a bit of "entropy".  But I've never felt a need for the latter.  
Likewise for doing, e.g.,

index = the_hash_code % SOME_POSITIVE_PRIME

in Python.  % takes the sign (positive here) of the modulus in Python.

So this _looks_ like pointlessly disruptive code churn to me.  What killer use 
case am I missing?

--

___
Python tracker 

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



[issue37807] Make hash() return a non-negative number

2019-08-10 Thread Serhiy Storchaka


Serhiy Storchaka  added the comment:

Currently the hash for integers and several other types uses 62 bits of 64 (on 
64-bit platform). The domain of values is continuous:

-sys.hash_info.modulus < h < sys.hash_info.modulus

If interpret Py_hash_t as Py_uhash_t, it will no longer be continuous:

0 <= h < sys.hash_info.modulus or 
2**sys.hash_info.width-sys.hash_info.modulus < h < 2**sys.hash_info.width

The hash for tuples is written in term of signed hashes of elements. If write 
it in Python it will look more complicated for unsigned hashes.

What are problems with using negative hash values? In hash tables you squeeze 
it to valid range by evaluating `h % size` of `h & mask`. Both expressions give 
non-negative result.

--

___
Python tracker 

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



[issue37792] xml.etree.ElementTree.Element.__eq__ does compare only objects identity

2019-08-10 Thread Stefan Behnel

Stefan Behnel  added the comment:

FWIW, deep traversing an XML tree on an operation as simple as "==" seems 
excessive. To me, object identity comparison seems the most sensible behaviour 
of "==" on Element objects.

(It's not "complicated to implement", but rather can be very expensive to 
execute.)

Regarding your other questions (and note that this is a bug tracker, so 
discussing unrelated questions in a ticket is inappropriate – use the Python 
mailing list instead if you want):

"SubElement" suggests a constructor, yes. It kind-of makes sense, given what it 
does, and resembles "Element", which is the constructor for a (non-sub) 
Element. It might seem funny, sure, but on the other hand, why should users be 
bothered with the implementation detail that it is a function? :-)

"fromstringlist()" matches "tostringlist()", API-wise. Both are probably not 
very widely used, but I don't see much value in removing them. It always breaks 
someone's code out there.

--

___
Python tracker 

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



[issue37807] Make hash() return a non-negative number

2019-08-10 Thread Mark Dickinson


Mark Dickinson  added the comment:

This is a change of documented behaviour that will affect 3rd party libraries 
that provide numeric types, like NumPy and gmpy; it should not be done lightly. 
I think such a change deserves at least a deprecation warning, and should also 
be discussed more widely than just this issue.

--
nosy: +njs

___
Python tracker 

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



[issue14465] xml.etree.ElementTree: add feature to prettify XML output

2019-08-10 Thread Stefan Behnel


Change by Stefan Behnel :


--
pull_requests: +14929
pull_request: https://github.com/python/cpython/pull/15200

___
Python tracker 

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



[issue14465] xml.etree.ElementTree: add feature to prettify XML output

2019-08-10 Thread Stefan Behnel


Stefan Behnel  added the comment:

The spec section that Raymond quoted makes it clear that pretty printing is not 
for everyone. But there are many use cases where it is 1) helpful, 2) leads to 
correct results, and 3) does not grow the file size excessively. Whoever wants 
to make use of it is probably in such a situation. I think adding some kind of 
support in the standard library would be nice, but it should not hurt "normal" 
uses, especially when a lot of data is involved.

I'll send a PR that adds an indent() function to pre-process trees. Comments 
welcome.

--
assignee: serhiy.storchaka -> scoder
versions: +Python 3.9 -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



[issue37809] Alias typing.NamedTuple to collections

2019-08-10 Thread Raymond Hettinger


Raymond Hettinger  added the comment:

Further notes for posterity:

* Anything written using collections.NamedTuple would instantly lose its 
backwards compatibility.  

* The casing of NamedTuple is more in line with the typing module:  List, 
Deque, NamedTuple and doesn't fit well with the deque, namedtuple, and ChainMap 
in the collections module. 

* Nothing in the collections module currently requires typing, but NamedTuple 
can only be used with typing.  

* We really don't want to increase import times for collections. This proposal 
would defeat the entire purpose of having moved _collections_abc to a separate 
module outside of the collections package.

--

___
Python tracker 

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



[issue37806] Infinite recursion with typing.get_type_hints

2019-08-10 Thread Ivan Levkivskyi


Change by Ivan Levkivskyi :


--
assignee:  -> levkivskyi

___
Python tracker 

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



[issue37809] Alias typing.NamedTuple to collections

2019-08-10 Thread Ivan Levkivskyi


Ivan Levkivskyi  added the comment:

> FWIW, I had updated the docs for namedtuple() to link to typing.NamedTuple.  
> I think that should suffice.

Thank you!  I looked at the docs everything looks good.  I think this can be 
closed now.

--
assignee:  -> docs@python
components: +Documentation
nosy: +docs@python
resolution:  -> fixed
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



[issue37809] Alias typing.NamedTuple to collections

2019-08-10 Thread Raymond Hettinger


Raymond Hettinger  added the comment:

> we should do a better job of advertising typing.NamedTuple

FWIW, I had updated the docs for namedtuple() to link to typing.NamedTuple.  I 
think that should suffice.

--
nosy: +rhettinger

___
Python tracker 

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



[issue37807] Make hash() return a non-negative number

2019-08-10 Thread Raymond Hettinger


Raymond Hettinger  added the comment:

We think can clarify that those docs describe int.__hash__, float.__hash__, and 
complex.__hash__.   

The builtin hash() function can and does make transformations on the result 
from the __dunder__ method:

>>> class A:
def __hash__(self):
return 123423412341234123412341234

>>> hash(A())
1656462513496965462

--

___
Python tracker 

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



[issue37807] Make hash() return a non-negative number

2019-08-10 Thread Serhiy Storchaka


Serhiy Storchaka  added the comment:

The only problem is that the current algorithm for numeric types is documented 
to return negative numbers.
https://docs.python.org/3/library/stdtypes.html#hashing-of-numeric-types

--
nosy: +mark.dickinson, serhiy.storchaka

___
Python tracker 

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



[issue37807] Make hash() return a non-negative number

2019-08-10 Thread Serhiy Storchaka


Change by Serhiy Storchaka :


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

___
Python tracker 

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



[issue37756] Error 0x80070643 when installing

2019-08-10 Thread Eryk Sun


Eryk Sun  added the comment:

If we see 0x8XXX_, it's either an NTSTATUS [1] warning, which is unlikely, 
or and HRESULT [2] error, which is very likely. One of the more common facility 
codes for HRESULT is the Windows API, 0x007. If we see 0x8007, then  is 
a Windows system error code [3]. In this case, 0x643 is ERROR_INSTALL_FAILURE 
(1603), which is not a very information error code by itself. 

We need to read the log file (or request additional logs) to figure out what 
failed. Steve Dower is the person to address this, since he has far more 
experience with the design and behavior of the installer. From what I can see 
on the surface, with my shallow knowledge, it failed to install core_JustForMe 
for some reason (probably there's more info in another log), and then failed to 
delete the cached package when rolling back, with the error 0x80070003 
(ERROR_PATH_NOT_FOUND), which looks suspicious.

I'm reopening for now. Feel free to close it again if you disagree. I won't 
press the matter.

[1] 
https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-erref/87fba13e-bf06-450e-83b1-9241dc81e781
[2] 
https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-erref/0642cb2f-2075-4469-918c-4441e69c548a
[3] https://docs.microsoft.com/en-us/windows/win32/debug/system-error-codes

--
nosy: +eryksun
resolution: not a bug -> 
stage: resolved -> 
status: closed -> open

___
Python tracker 

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



[issue37809] Alias typing.NamedTuple to collections

2019-08-10 Thread Steven D'Aprano


New submission from Steven D'Aprano :

As discussed in the thread starting here with Guido's message:

https://mail.python.org/archives/list/python-id...@python.org/message/WTBXYJJ7CSGDLLJHHPHSH5ZCCA4C7QEP/

and these two follow-ups:

https://mail.python.org/archives/list/python-id...@python.org/message/SXF3RKYQ6DXFKX2RFMUDUKAWQEGXGHP3/

https://mail.python.org/archives/list/python-id...@python.org/message/VRCH56CHE4P7IAWO7QRA6TDBISLONGQT/


we should do a better job of advertising typing.NamedTuple by aliasing it in 
the collections module.

(I'm not sure if this can still go into 3.8, since it's not really a new 
feature, or if its too late.)

--
messages: 349339
nosy: gvanrossum, levkivskyi, steven.daprano
priority: normal
severity: normal
status: open
title: Alias typing.NamedTuple to collections
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



[issue37808] Deprecate unbound super methods

2019-08-10 Thread Steven D'Aprano


New submission from Steven D'Aprano :

As per the discussion here, let's deprecate unbound super methods.

https://discuss.python.org/t/is-it-time-to-deprecate-unbound-super-methods/1833

--
messages: 349338
nosy: steven.daprano
priority: normal
severity: normal
status: open
title: Deprecate unbound super methods
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



[issue37801] Compilation on MINGW64 fails (CODESET,wcstok,...)

2019-08-10 Thread Christoph Reiter


Christoph Reiter  added the comment:

> I wasn't aware that CPython builds for MSYS2 out of the box, since it's a 
> POSIX-on-Windows platform like Cygwin. Apparently there are patches that 
> enable it to build, since MSYS2 has Python available.

MSYS2 consists of a cygwin like environment and a mingw one. OP is trying to 
build with mingw.

MSYS2 contains a somewhat heavily patched Python in both environments so it's 
expected that building plain CPython doesn't work. There are plans to upstream 
smaller non-MSYS2 specific patches but nothing has come of it so far.

--
nosy: +lazka

___
Python tracker 

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



[issue37756] Error 0x80070643 when installing

2019-08-10 Thread Terry J. Reedy


Terry J. Reedy  added the comment:

The error comes from Windows and it indicates a problem with your computer.  
Questions about Windows errors should be initially directed to python-list or 
elsewhere.

Searching for 0x80070643 returns multiple hits, including this 'official' one.
https://answers.microsoft.com/en-us/insider/forum/all/windows-update-error-0x80070643/3bad0495-dabb-4e3f-91a7-aaf992ef537a
You could also search stackoverflow.com.

--
nosy: +terry.reedy
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
type: crash -> behavior

___
Python tracker 

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



[issue37806] Infinite recursion with typing.get_type_hints

2019-08-10 Thread Karthikeyan Singaravelan


Change by Karthikeyan Singaravelan :


--
nosy: +gvanrossum, levkivskyi

___
Python tracker 

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



[issue32912] Raise non-silent warning for invalid escape sequences

2019-08-10 Thread miss-islington


miss-islington  added the comment:


New changeset b4be87a04a2a8ccfd2480e19dc527589fce53555 by Miss Islington (bot) 
(Gregory P. Smith) in branch 'master':
bpo-32912: Revert SyntaxWarning on invalid escape sequences. (GH-15195)
https://github.com/python/cpython/commit/b4be87a04a2a8ccfd2480e19dc527589fce53555


--
nosy: +miss-islington

___
Python tracker 

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



[issue23666] Add shell session logging option to IDLE

2019-08-10 Thread Terry J. Reedy


Terry J. Reedy  added the comment:

A dirty editor must be saved before running, or discarded before closing.  
Neither is true for Shell,  Making these at least an option in Shell should be 
the first change.  If the user has specified a savefile name, that should be 
used, and the user is responsible for the file.  If a file is automatically 
put, say, in .idlerc/shell.bak.py, there is an issue of when to delete or 
overwrite.

We should continue working to make automatic, versus explicit, shell logging 
less necessary.

If IDLE running in normal mode (user code running in a separate process) either 
closes by itself or locks up so that it *must* be closed, that should indicates 
a bug in python or IDLE that should be fixed.  There might be a couple such 
bugs left, I am not sure.

If the user process closes, the shell should restart one automatically. As far 
as I know, it dies.

If the user process hangs, control-C (Shell => Interrupt Execution) usually 
works,
  >>> while 1: 2+2
  KeyboardInterrupt
  >>> 
But a) beginning computer user may not know about ^C, or it may not work due to 
limitations in Python.  (There is an issue about the latter.)  In the latter 
case, one can restart with Shell => Restart Shell, but this is IDLE specific 
and users may not know about it.

When the shell catches ^C, it could create an after callback with a delay of, 
say, .5 seconds (but to be determined).  If ^C works, cancel the callback.  If 
not, display a message (only once per session) about using Restart.  Maybe next 
time, do an auto restart.

We might also think about detecting a hang (5 seconds, no output?) and printing 
a message about using ^C.

--
assignee:  -> terry.reedy
stage:  -> test needed
versions: +Python 3.7, Python 3.8, Python 3.9 -Python 3.5

___
Python tracker 

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



[issue37807] Make hash() return a non-negative number

2019-08-10 Thread Raymond Hettinger


New submission from Raymond Hettinger :

The existing API for the builtin hash() function is inconvenient.  When 
implementing structure that use a hash value, you never want a negative number. 
 Running abs(hash(x)) works but is awkward, slower, and loses one bit of 
entropy.

--
components: Interpreter Core
messages: 349333
nosy: rhettinger, tim.peters
priority: normal
severity: normal
status: open
title: Make hash() return a non-negative number
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