[issue42482] TracebackException should not hold reference to the exception traceback

2020-11-27 Thread Steven D'Aprano


Steven D'Aprano  added the comment:

This would be a change of behaviour, and 3.8 and 3.9 are in feature freeze, so 
we could only add it in 3.10.

You say:

"it's supposed to capture the output without holding references to real things"

Is this requirement documented somewhere, or is it just your preference?

"it makes comparison wrong for equivalent exceptions"

If the tracebacks are different, they're not exactly equivalent.

If we did accept this patch, would that mean there would no longer be any need 
to delete the exception variable at the end of an `except` block?

--
nosy: +steven.daprano
versions:  -Python 3.8, Python 3.9

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



[issue42460] Wrong Output

2020-11-25 Thread Steven D'Aprano


Steven D'Aprano  added the comment:

Correct output.

https://docs.python.org/3/reference/expressions.html#operator-precedence

a = 10
b = 10
(a >= 10) and not (b == 10) | 7+2 == 9

returns False because of operator precedence. It evaluates like this:

(a >= 10) and not (b == 10) | 7+2 == 9
--> True and not True | 7+2 == 9
--> True and not True | 9 == 9
--> True and not 9 == 9
--> True and not True
--> True and False
--> False

--
nosy: +steven.daprano
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

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



[issue42459] Wrong Output

2020-11-25 Thread Steven D'Aprano


Steven D'Aprano  added the comment:

That is the correct output.

Kshitish, Python is a mature language (about 30 years old) used by tens or 
hundreds of thousands of people every day. Did you believe that you were the 
only person who noticed that Python cannot even run `if...else` statements 
correctly?

This is not a help desk for beginners having trouble with their code. There are 
many places you can ask for help, like Reddit's r/learnpython, or 
Stackoverflow, or the tutor mailing list:

https://mail.python.org/mailman/listinfo/tutor

There are various Python IRC channels or Discuss, if you google you will soon 
find them. There are thousands of people happy to help you learn. This bug 
tracker is not the right place.

99.999% for sure, every "bug" you find will be your misunderstanding of the 
code, not a bug in the language, just like the previous one: #42456 (also not a 
bug).

Also, please stop posting screen captures. Python code is text, and we don't 
edit in Photoshop. Copy the relevant text and paste it into your bug reports. 
Screen captures are inconvenient for us if we have to run your code, and they 
make it difficult or impossible for blind and visually impaired developers to 
take part.

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

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



[issue42441] UnicodeEncodeError

2020-11-23 Thread Steven D'Aprano


Steven D'Aprano  added the comment:

You can learn more about unicode and encodings:

https://www.joelonsoftware.com/2003/10/08/the-absolute-minimum-every-software-developer-absolutely-positively-must-know-about-unicode-and-character-sets-no-excuses/


https://pyvideo.org/pycon-us-2012/pragmatic-unicode-or-how-do-i-stop-the-pain.html


https://nedbatchelder.com/text/unipain/unipain.html#1

(For the last link, use the arrow keys to navigate.)

--
nosy: +steven.daprano

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



[issue42439] Use of ternary operator instead of if and else in month calculation function

2020-11-22 Thread Steven D'Aprano


Steven D'Aprano  added the comment:

Why do you care what the implementation of the private methods are? Does it 
make them faster or fix a bug? How is it "convenient" to change the 
implementation to ternary if?

Without some better justification, this strikes me as just code churn for no 
benefit, but the risk of breaking things. For example, you changed the result 
from a tuple to a list.

Will this break anything? I don't know, but it will take time to find out, and 
with no obvious benefit to the change, spending that time to find out if this 
is a safe change is effort for no visible benefit.

--
nosy: +steven.daprano

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



[issue36906] Compile time textwrap.dedent() equivalent for str or bytes literals

2020-11-21 Thread Steven D'Aprano


Steven D'Aprano  added the comment:

A string prefix would be a large language change that would need to go through 
Python-Ideas, a PEP and Steering Council approval. Let's not go there :-)

A new string method is a comparatively small new feature that probably won't 
need a PEP or Steering Council approval.

A compile-time optimization is an implementation feature, not a language 
feature. Whether devs want to follow up with more string optimizations like 
'spam'.upper() is entirely up to them.

Backwards compatibility implies that textwrap.dedent is not going away any time 
soon, but it should probably become a thin wrapper around str.dedent at some 
point.

--

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



[issue42421] Native open failed to create a file on windows10 when colon exists in the name

2020-11-20 Thread Steven D'Aprano


Steven D'Aprano  added the comment:

This is standard Windows behaviour, and goes back to DOS days. Reserved 
filenames and illegal characters are described here:

https://docs.microsoft.com/en-gb/windows/win32/fileio/naming-a-file?redirectedfrom=MSDN

If the Windows OS and file system does not allow a colon in the file name, 
there is nothing Python can do to change that.

--
nosy: +steven.daprano
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

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



[issue42394] Exception handling on boolean comparisons

2020-11-17 Thread Steven D'Aprano


Steven D'Aprano  added the comment:

This is not a bug, it is normal handling of `and` and `or` operators since 
Python 1.5 and possibly older.

The `and` and `or` operators are *short-cut* operators. This is intentional 
design, so we can write things like:

if mylist and mylist[0] == value:

the `mylist[0] == value` expression is only evaluated if `mylist` is a truthy 
value.

This is all documented here:

https://docs.python.org/3/reference/expressions.html#boolean-operations

--
nosy: +steven.daprano
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

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



[issue42379] Optional List Args Persist Across Objects

2020-11-16 Thread Steven D'Aprano


Steven D'Aprano  added the comment:

Hi Rose, this is a FAQ:

https://docs.python.org/3/faq/programming.html#why-are-default-values-shared-between-objects

although it's also a feature that does cause beginners some trouble, see for 
example my comment here for more information:

https://bugs.python.org/msg361451

--
nosy: +steven.daprano

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



[issue42310] for loop creates element in defaultdict

2020-11-10 Thread Steven D'Aprano


Steven D'Aprano  added the comment:

As Larry said, yes, this is expected behaviour, and has nothing to do with the 
for loop. The purpose of defaultdict is that dict lookups create the entry if 
it doesn't exist:

>>> from collections import defaultdict
>>> d = defaultdict(list)
>>> x = d['any key']
>>> d
defaultdict(, {'any key': []})


So even though your code loops zero times, you have created a key 'a' with 
value [].

--
nosy: +steven.daprano

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



[issue42302] [Turtle] Add clockwise and anticlockwise method as alias to right and left

2020-11-10 Thread Steven D'Aprano


Steven D'Aprano  added the comment:

On Tue, Nov 10, 2020 at 09:55:40AM +, Serhiy Storchaka wrote:

> If clockwise is a new 
> standard for this command in modern Turtle implementation, we can add 
> yet one alias. Otherwise I agree with Raymond.

I had a very quick look at some Logo implementations:

https://resources.terrapinlogo.com/weblogo/commands/

https://www.mit.edu/~hlb/MA562/commands.html

https://reduce-algebra.sourceforge.io/manual/manualse170.html

https://docs.racket-lang.org/logo/index.html

and even 3D Logo:

https://vrmath2.net/node/12

and I can see no sign of any other Logos allowing clockwise and 
anticlockwise as aliases. So I think it is up to Ravi Chityala to 
demonstrate that this alias is already in use in some other Logo or 
turtle graphics implementations.

--

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



[issue42302] [Turtle] Add clockwise and anticlockwise method as alias to right and left

2020-11-09 Thread Steven D'Aprano


Steven D'Aprano  added the comment:

As a new feature, it can only go into 3.10. All other versions have reached 
feature-freeze and can accept no new features.

We might argue that rotations should have always been written as 
"anticlockwise" and "clockwise", but they are long and verbose, and in English 
"left" and "right" are more common. I doubt many people will prefer 
"anticlockwise" over "left".

--
nosy: +steven.daprano
versions:  -Python 3.6, Python 3.7, Python 3.8, Python 3.9

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



[issue42290] Unicode inconsistent display after concencated

2020-11-07 Thread Steven D'Aprano

Steven D'Aprano  added the comment:

Works for me:

>>> chr(1839)+'1'
'ܯ1'

You are mixing a right-to-left code point (DHALATH) with a left-to-right code 
point (digit 1). The result depends on the quality of your console or terminal. 
Try using a different terminal.

On my system, the terminal displays the DHALATH on the left, and the digit 1 on 
the right; when pasted into my browser, it displays them in the reverse order. 
I don't know which is correct: bidirectional text is complex and I don't know 
the rules for mixing characters with different bidirection classes.

But whichever display is correct, this has nothing to do with Python. It 
depends on the quality of the bidirectional text rendering of the browser and 
the terminal.

If your terminal displays the wrong results, that's a bug in the terminal. What 
terminal are you using, in what OS? Try using a different terminal.

You can check that Python is doing the right thing:


>>> s = chr(1839)+'1'
>>> s == '\N{SYRIAC LETTER PERSIAN DHALATH}1'
True

If your system reports True, then Python has made the string you asked for, and 
the result of printing depends on the capabilities of the terminal, and the 
available glyphs in the typeface used by the terminal. There's nothing Python 
can do about that.

--
nosy: +steven.daprano

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



[issue42265] Remove binhex module following PEP-594

2020-11-04 Thread Steven D'Aprano


Steven D'Aprano  added the comment:

PEP 594 is a draft, it has not been accepted. It is premature to start 
cancelling perfectly good modules and breaking people's code.

https://conroy.org/breaking-python-packages

If you have some concrete reason for removing the binhex module, other than 
just PEP 594, then we can consider depreciating it in 3.10 or 3.11, and 
removing it in 3.12 or 3.13, or possibly later.

--
nosy: +steven.daprano
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

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



[issue42227] Unexpected sharing of list/set/dict between instances of the same class, when the list/set/dict is a default parameter value of the constructor

2020-11-01 Thread Steven D'Aprano


Steven D'Aprano  added the comment:

See also my comment here:

https://bugs.python.org/msg361451

--

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



[issue42227] Unexpected sharing of list/set/dict between instances of the same class, when the list/set/dict is a default parameter value of the constructor

2020-11-01 Thread Steven D'Aprano


Steven D'Aprano  added the comment:

Sorry, this is not a bug, but working as designed. Default values for functions 
and methods are only created once, when the function is created, not on every 
call.

This is a FAQ:

https://docs.python.org/3/faq/programming.html#why-are-default-values-shared-between-objects

--
nosy: +steven.daprano
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

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



[issue42223] List repetition operator gives unexpected results

2020-10-31 Thread Steven D'Aprano


Steven D'Aprano  added the comment:

This is not a bug. The sequence repetition operator does not *copy* items, as 
explained here:

https://docs.python.org/3/library/stdtypes.html#common-sequence-operations

--
nosy: +steven.daprano
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

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



[issue42203] Unexpected behaviour NameError: name 'open' is not defined

2020-10-30 Thread Steven D'Aprano


Steven D'Aprano  added the comment:

See:

#26789 #39513

Serhiy, is a test case still needed? Should this be closed and pushed back to 
fixing logging?

--
nosy: +steven.daprano

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



[issue42148] floating point representation issues

2020-10-25 Thread Steven D'Aprano


Steven D'Aprano  added the comment:

It looks like Python is correct and the other languages may be just truncating 
the output.


In the Lua interpreter:

> =277*0.1
27.7
> = 277*0.1 == 27.7
false


Perl:

$ perl -e "use feature qw(say); say 277*0.1"
27.7
$ perl -e "use feature qw(say); if (277*0.1 != 27.7) {say 'unequal'}"
unequal

In Ruby:

irb(main):001:0> 277*0.1
=> 27.7
irb(main):002:0> 277*0.1 == 27.7
=> false


Julia agrees with Python:

julia> 277*0.1
27.703

So does the Rhino javascript interpreter:

js> 277*0.1
27.703

I think Eric's instinct was correct.

--

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



[issue42148] floating point representation issues

2020-10-25 Thread Steven D'Aprano


Steven D'Aprano  added the comment:

Eric I would normally agree with you but the only thing which gives me pause is 
the statement that this doesn't occur with C, Lua and Perl.

That alone doesn't mean much. Different interpreters can use different 
algorithms for printing floats, Python changed its algorithm in 3.1 and 
backported it to 2.7:

https://docs.python.org/3.1/whatsnew/3.1.html#other-language-changes

and now uses Gay's algorithm which will often give different, shorter, results 
than other algorithms. Other languages do other things, for example R is 
notorious for just terminating the float output after a few decimal places, so 
you have numbers which look identical but are unequal.

Andrea, do you still think this is a bug? Can you demonstrate some code in 
another language that shows the output you expect? (Preferably an interpreter 
rather than C.)

Most importantly, can you demonstrate that the other language's output is 
correct and Python's is wrong? In particular, are you sure that the output in 
those other languages is not just rounding the result to a certain number of 
decimal places?

If you can satisfy those, please re-open the ticket, otherwise I expect that 
Eric is correct.

--
nosy: +steven.daprano

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



[issue42075] Verbose/confusing default format on warnings

2020-10-18 Thread Steven D'Aprano


Steven D'Aprano  added the comment:

3.9 and older are all in feature freeze, so no changes in behaviour will be 
considered for them.

I'm afraid I cannot replicate the behaviour you describe. When I try, the full 
warning message is correctly displayed. See the attached file.

Importing it from the interactive interpreter gives:

>>> import warntest
/home/steve/warntest.py:5: UserWarning: Danger danger danger Will 
Robinson!!!
  "Danger danger danger Will Robinson!!!"


and running it from the commandline:


$ python3 ~/warntest.py 
/home/steve/warntest.py:5: UserWarning: Danger danger danger Will Robinson!!!
  "Danger danger danger Will Robinson!!!"


Can you provide a minimal working example of the issue?

--
nosy: +steven.daprano
versions:  -Python 3.6, Python 3.7, Python 3.8, Python 3.9
Added file: https://bugs.python.org/file49526/warntest.py

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



[issue42074] setup error on windows

2020-10-18 Thread Steven D'Aprano


Steven D'Aprano  added the comment:

Hi CaptainMitsumoto,

Did you follow the instructions given by the installer to read the log file? We 
don't have access to your log file, only you do. Can you see what file cannot 
be found?

Did you try some basic googling? I'm not a Windows guru, but this:

https://answers.microsoft.com/en-us/windows/forum/windows_10-windows_install/0x80070002-the-system-cannot-find-the-file/cad10f8d-79f2-4a10-953f-b85478b3e1b7


suggests that the problem is related to permissions, or your OS installation, 
not to the installer itself. Do you have administrator privileges? Did you 
check your .Net framework? What version of Windows are you using?

If you have already received some suggestions which did not work, would you 
mind telling us what you already tried so we don't waste our time, and yours, 
telling you what you have already tried.

Did you successfully install the older version of Python? If so, there is 
nothing stopping you from coding in 3.8 and upgrading later.

--
nosy: +steven.daprano

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



[issue42074] setup error on windows

2020-10-18 Thread Steven D'Aprano


Change by Steven D'Aprano :


--
components: +Installation -Unicode
type: crash -> behavior

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



[issue42074] setup error on windows

2020-10-18 Thread Steven D'Aprano


Change by Steven D'Aprano :


--
title: f***ing setup failed is driving me insane -> setup error on windows

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



[issue41904] datetime.datetime.today makes no sense and should be removed

2020-10-13 Thread Steven D'Aprano


Steven D'Aprano  added the comment:

On Wed, Oct 14, 2020 at 12:45:55AM +, Damian Yurzola wrote:

> And you also see people doing date math on datetime.date.today which 
> will result in different answers through out the day.

Yes? Is this a problem? If I ask the question "How long is it until 
Christmas?" the answer should be different if I ask on one minute past 
midnight on December 24 or one minute to midnight.

I daresay that you are correct that many (maybe a majority) of uses of 
datetime.today are conceptually better as date.today, but not all of 
them.

> I like HassanAbouelela's idea that datetime.datetime.today should 
> return an arbitrary fixed time rather than an arbitrary variable time.

But it's not an arbitrary variable time. It is just a high-resolution 
(down to the microsecond) version of "today", instead of the 
low-resolution (down to a single day) date.today.

--

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



[issue42003] After changing to list or tuple, will the original parameter change?

2020-10-10 Thread Steven D'Aprano


Steven D'Aprano  added the comment:

This is not a bug. In Python 2, zip() returns a list, so you can use it over 
and over again. But in Python 3, zip() returns an iterator, and you can only 
use iterators once. After you have used the iterator, it is exhausted and there 
is nothing left.

So the behaviour you see is expected and intentional.

--
nosy: +steven.daprano
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

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



[issue41937] how to use cpython O

2020-10-04 Thread Steven D'Aprano


Steven D'Aprano  added the comment:

Please don't post screen shots of text when you can post a direct link to the 
page.

Are you talking about this?

https://docs.python.org/3/c-api/arg.html?highlight=py_cleanup#other-objects

This is a bug tracker, for reporting bugs in the Python interpreter and 
standard library, not a help desk for asking for help with your code. There are 
many other places where you can ask for help, such as:

- Stackoverflow

- Reddit's /r/learnpython

- https://python-forum.io/

- the Python-List mailing list 
https://mail.python.org/mailman/listinfo/python-list

- IRC https://www.python.org/community/irc/

and probably many more.

For help getting your code to work, see the above forums.

I'm going to close this as "Not A Bug", if you have an actual bug to report, 
you can re-open this with a demonstration of the bug.

--
nosy: +steven.daprano
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

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



[issue41927] Why is there no documentation in Russian?

2020-10-04 Thread Steven D'Aprano


Steven D'Aprano  added the comment:

Oh no, you have discovered our dirty secret! Python is racist against Russia! 
/sarcasm

Python is created by volunteers, including the documentation. If you want a 
Russian translation, feel free to start working on one.

You could start here: https://wiki.python.org/moin/Languages

--
nosy: +steven.daprano

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



[issue41920] Weird add operation of "0.2222 + 0.1111"

2020-10-03 Thread Steven D'Aprano


Steven D'Aprano  added the comment:

Hi Leonard,

Any number which has only fixed precision will experience similar 
issues. It might affect different calculations.

In Python, float, complex and Decimal have fixed precision, so they can 
experience this issue.

But for simple calculations, Decimal may be better for you, as it uses 
base-10 floats, not base-2, so many numbers which are rounded off in 
binary floats are not rounded in Decimal:

py> from decimal import Decimal
py> 0. + 0.  # binary floats
0.4
py> Decimal('0.') + Decimal('0.')  # decimal floats
Decimal('0.')

But with Decimal, you have other numbers which are rounded off and so 
are not exact:

py> one_third = 1/Decimal(3)
py> 3*one_third  # should be exactly 1
Decimal('0.')

py> (1/Decimal(6)) * 3
Decimal('0.5001')

ints are always exact, but you can only do whole numbers with ints. 
Fractions are also exact:

py> from fractions import Fraction
py> Fraction(, 1) + Fraction(, 1)
Fraction(, 1)

Using Fraction is a good way to see what number a binary float really 
is:

py> Fraction(0.)
Fraction(4002799348806897, 36028797018963968)

--

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



[issue41920] Weird add operation of "0.2222 + 0.1111"

2020-10-03 Thread Steven D'Aprano


Steven D'Aprano  added the comment:

Some further resources:

https://stackoverflow.com/questions/8215437/floating-point-accuracy-in-python

https://stackoverflow.com/questions/21895756/why-are-floating-point-numbers-inaccurate

https://stackoverflow.com/questions/1089018/why-cant-decimal-numbers-be-represented-exactly-in-binary?noredirect=1=1

https://randomascii.wordpress.com/category/floating-point/page/1/


If you google a bit you will find many other places that discuss this.

--

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



[issue41920] Weird add operation of "0.2222 + 0.1111"

2020-10-03 Thread Steven D'Aprano


Steven D'Aprano  added the comment:

Please forgive me if my answer is a little bit brusque, but we get essentially 
this same bug report regularly, only the numbers are different.

This is not a bug in Python, it is an unavoidable consequence of how floating 
point arithmetic works in every single programming language that does floating 
point arithmetic.

There's a FAQ about it:

https://docs.python.org/3/faq/design.html#why-am-i-getting-strange-results-with-simple-arithmetic-operations

it's discussed in the tutorial:

https://docs.python.org/3/tutorial/floatingpoint.html#tut-fp-issues

there's probably a million websites, blog posts, Stackoverflow questions etc 
about it, and computer scientists write papers about it:

https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html

--
nosy: +steven.daprano
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

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



[issue41904] datetime.datetime.today makes no sense and should be removed

2020-10-01 Thread Steven D'Aprano


Steven D'Aprano  added the comment:

On Thu, Oct 01, 2020 at 04:37:28PM +, Damian Yurzola wrote:
> I was inspired to file this bug after reading through a multiplicity 
> of bugs introduced by folks confused by the library's behavior.

Are these public bug reports or private anecdotes?

I'm not saying that the method cannot be deprecated or removed, but it 
needs to be justified. We don't break people's code gratuitiously, at 
least not intentionally. If you make a good enough case for deprecating 
the method, we can do so.

> What do you say about the unnecessarily redefined properties?
> 
> Lines Lib/datetime.py#L1606 to datetime.py#L1620

I don't know. Do all the tests still pass if you take them out?

--

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



[issue41904] datetime.datetime.today makes no sense and should be removed

2020-10-01 Thread Steven D'Aprano


Steven D'Aprano  added the comment:

Even if I agreed that this method "makes no sense", and I don't, removing it 
would be gratuitous breakage.

Why should we break potentially thousands of people's code who are happily 
using this method, merely because you say that people who use it have "the 
wrong semantic mental model"?

Considered as a datetime, having `today` return the date and time *now* makes 
good sense to me. Obviously the date components must be today's date, not 
yesterday or tomorrow; and the time component could be any arbitrary time, with 
the current time an obvious choice.

And since datetime inherits from date, it would be very odd if it didn't 
inherit the `today` method. It would also violate the Liskov Substitution 
Principle.

But even if you disagree with my opinions, you still have to justify breaking 
backwards compatibility.

--
nosy: +steven.daprano

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



[issue41788] enhancement: add assertDuration context manager to unittest module

2020-09-15 Thread Steven D'Aprano


Steven D'Aprano  added the comment:

Matt, you can add this to your own unit tests by just subclassing 
unittest.TestCase and adding a new assertDuration method. Copy the existing 
method's implementations (its open source and you should have the source code 
already, but if not you can find it here:

https://github.com/python/cpython/blob/3.8/Lib/unittest/__init__.py

If you are looking for some timing code to use (in case you don't already have 
your own) you can try this:

https://github.com/ActiveState/code/tree/master/recipes/Python/577896_Benchmark_code

--
nosy: +steven.daprano

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



[issue41774] While removing element from list using for and remove(), which has same items output is not right

2020-09-12 Thread Steven D'Aprano


Steven D'Aprano  added the comment:

I think Eric left the issue open because he was hoping to update the FAQs 
and/or docs with information about this issue.

I will leave it to someone else to decide whether or not to reopen it.

--

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



[issue41774] While removing element from list using for and remove(), which has same items output is not right

2020-09-12 Thread Steven D'Aprano


Steven D'Aprano  added the comment:

You say:

"output should be empty list"

but that's not actually correct. You intend the output to be the empty list, 
but if you think carefully about what happens during iteration, you should see 
that the behaviour is correct.

To make it easier to see what is happening, let's use different values:

L = [20, 21, 22]


On the first iteration, the interpreter looks at position 0, which is 20. You 
remove 20 from the list, which shrinks the list down to:

L = [21, 22]

Now it is 21 in position 0. But that iteration of the loop is finished, so the 
interpreter looks at position 1, which is 22. You remove 22 from the list, 
giving:

L = [21]

and the interpreter looks at position 2, which does not exist, so the loop 
finishes.


>>> L = [20, 21, 22]
>>> for i in L:
... L.remove(i)
... print('i', i, 'L is now:', L)
... 
i 20 L is now: [21, 22]
i 22 L is now: [21]
>>> L
[21]


So the interpreter did exactly what you told it to do. The problem is that what 
you told it to do is not what you wanted it to do.

--
nosy: +steven.daprano

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



[issue41770] Import module doesn't updated

2020-09-11 Thread Steven D'Aprano


Steven D'Aprano  added the comment:

This is not a bug, it is working as designed. Importing takes the module from 
the cache. You can either delete the module from the cache:

del sys.modules['modulename']
import modulename  # reloads from the module file


or possibly simpler, use reload:

importlib.reload(modulename)

--
components: +Interpreter Core -Windows
nosy: +steven.daprano
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
type: resource usage -> behavior

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



[issue41743] Remove Unnecessarily Gendered Language from the Documentation

2020-09-08 Thread Steven D'Aprano


Steven D'Aprano  added the comment:

On Tue, Sep 08, 2020 at 06:23:58PM +, David Williams wrote:
> Steven, it sounds like we agree to the change proposal, which is to 
> remove gendered language from the documentation.

What?

Did you even read what I wrote?

--

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



[issue41743] Remove Unnecessarily Gendered Language from the Documentation

2020-09-08 Thread Steven D'Aprano


Steven D'Aprano  added the comment:

Hello David,

I really don't think you speak for the entire LGBTQ community. You don't speak 
for me or my wife.

You mention two issues here:

"First is that break and continue don't allow the programmer to do anything, 
they cause the program control flow to change."

And by changing program control flow, they allow the programmer to do many 
things. That's why we use them: because we want to do something, and the break 
and continue statements allow us to do so more conveniently that the 
alternatives.

You say:

"Second, there is no reason to appeal to gendered pronouns which are 
antiquated."

If gendered pronouns are antiquated, why do people care about choosing their 
pronouns?

David, I would like to assume good faith, but coming in here and declaring that 
pronouns are antiquated seems a bit... trollish. I am sure that there are many 
people who do not agree that pronouns are antiquated or irrelevant. I am pretty 
sure that there are some people in the mailing list who would be very upset if 
you misgendered them by insisting that they need no gendered pronouns.

Many people consider their personal choice of pronoun important enough to list 
it in their mail signature or profile, at possible risk to their own safety.

What you describe as "more include[sic] and parsimonious form (less chatter)" 
reads to me as a more passive, excessively terse, less inclusive form that is 
also incorrect, since "Python syntax is limited..." is not a *motivation*. 
Motivation must refer to human desire, and your version not only has no human 
desire, it has no reference to humans at all. It reads to me as a  cold, 
abstract statement divorced from any motivation or human need.

--
nosy: +steven.daprano

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



[issue41740] Improve error message for string concatenation via `sum`

2020-09-07 Thread Steven D'Aprano


Steven D'Aprano  added the comment:

Marco, sum should be as fast as possible, so we don't want to type check every 
single element. But if it is easy enough, it might be worth checking the first 
element, and if it fails, report:

cannot add 'type' to start value

where 'type' is the type of the first element. If that is str, then concatenate

(use ''.join(iterable) instead)

to the error message.

--

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



[issue41740] Improve error message for string concatenation via `sum`

2020-09-07 Thread Steven D'Aprano


Steven D'Aprano  added the comment:

As Marco says, the exception message is because the default value for start is 
0, and you can't concatenate strings to the integer 0.

You get the same error if you try to concatenate lists:

py> sum([[], []])
TypeError: unsupported operand type(s) for +: 'int' and 'list'


However, even if you provide a default of the empty string, "", sum will still 
reject string arguments. This is intentional, as repeatedly concatenating 
strings may be extremely inefficient and slow, depending on the specific 
circumstances.


The default of 0 is documented, as is the intention that sum be used only for 
numeric addition. See `help(sum)` or the docs on the website.

--
nosy: +steven.daprano
title: string concatenation via `sum` -> Improve error message for string 
concatenation via `sum`

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



[issue41719] Why does not range() support decimals?

2020-09-04 Thread Steven D'Aprano


Steven D'Aprano  added the comment:

Generating a range of equally-spaced floats is tricky and the range builtin is 
not the right solution for this.

For numerical work, we often need to specify the number of steps, not the step 
size. For instance, in numeric integration, we often like to double the number 
of steps and avoid re-calculation.

We often need to skip either the start or end point, or both, or neither.

If you specify the step size, as range does, you can have off-by-one errors due 
to float rounding.

See here for a discussion and possible solution:

https://code.activestate.com/recipes/577878

--
nosy: +steven.daprano

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



[issue41716] SyntaxError: EOL while scanning string literal

2020-09-04 Thread Steven D'Aprano


Steven D'Aprano  added the comment:

See the FAQ:

https://docs.python.org/3/faq/design.html#why-can-t-raw-strings-r-strings-end-with-a-backslash

Also documented here:

https://docs.python.org/dev/reference/lexical_analysis.html#string-and-bytes-literals

Previous issues: #1271 and #31136

--

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



[issue41716] SyntaxError: EOL while scanning string literal

2020-09-04 Thread Steven D'Aprano


Steven D'Aprano  added the comment:

You can't end a string with a bare backslash, not even an raw string.

--
nosy: +steven.daprano
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

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



[issue41666] fix

2020-08-30 Thread Steven D'Aprano


Steven D'Aprano  added the comment:

I agree with xtreak. I guess you probably misspelled the initial word:

>>> 'Python'[2:5]  # same as the tutorial
'tho'

>>> 'Pyhton'[2:5]  # misspelling
'hto'

--
nosy: +steven.daprano

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



[issue41656] Sets are storing elements in sorted order.

2020-08-28 Thread Steven D'Aprano


Steven D'Aprano  added the comment:

Here's another example:

py> set([1, 2**63, 4, -5, 6, 5])
{1, 9223372036854775808, 4, 6, 5, -5}



By the way, in the future, please don't post screen shots of text, copy the 
code and output and paste it as text into your bug report. Screenshots make it 
hard for us to reproduce the bug, we have to re-type your code. And it makes it 
difficult for blind and visually impaired developers, who may be reading this 
with a screen-reader.

--

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



[issue41656] Sets are storing elements in sorted order.

2020-08-28 Thread Steven D'Aprano


Steven D'Aprano  added the comment:

"Unordered" means that the language doesn't promise any specific order, it 
doesn't mean that there is no order at all.

Try strings:

py> set("abcdef")
{'b', 'f', 'c', 'e', 'd', 'a'}


or different ints:

py> set([1, 0, -2])
{0, 1, -2}

--
nosy: +steven.daprano
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

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



[issue41645] Typo First Page of Documentation

2020-08-26 Thread Steven D'Aprano


Steven D'Aprano  added the comment:

I don't think that Python, a computer language, IS an approach to OOP. A 
programming language HAS an approach to OOP.

We would say "Python's approach to OOP is ..." so the approach is something 
that belongs to Python, it isn't Python itself.

(My dog's approach to cats is to bark loudly and chase them. It would be wrong 
to say that my dog is to bark loudly and chase cats.)

So the sentence is grammatically correct, inserting an "is" would make it 
incorrect. But perhaps it could be re-written to be more clear? It seems a 
little clumsy to me.

--
nosy: +steven.daprano

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



[issue41598] Adding support for rounding modes to builtin round

2020-08-24 Thread Steven D'Aprano


Steven D'Aprano  added the comment:

Okay Marco, I'm changing the title to reflect the new API (support for rounding 
modes rather than new round functions) and pushed the version to 3.10, since 
3.9 is in feature freeze (no new features).

This will probably need to be discussed on Python-Ideas, and maybe a PEP 
written, but provided it is not too controversial it may not be a big 
complicated PEP and I'm happy to help.

There is certainly a history of people requesting something like this:

https://kingant.net/2019/01/rounding-numbers-in-python-2-and-python-3/

https://mail.python.org/archives/list/python-...@python.org/thread/34QNDXZBMP6RR4P6NZFFIJK6YODEWSVK/


It will help very much if Mark, Raymond and Tim either support this idea or at 
least don't object. (Adding Tim to the nosy list.)

See also relevant discussion here:

https://bugs.python.org/issue32956


In my innocence, I don't think that this will be a very difficult feature to 
implement. Out of the five IEEE-754 rounding modes:

- Round to nearest, ties away to even already exists, so no extra work needs to 
be done.

- Round to nearest, ties away from zero was already implemented in Python 2, so 
we can just(?) resurrect that.

- Round toward 0 (truncation or chop) is equivalent to rounding down for 
positive numbers and rounding up for negatives, so if we can implement those, 
we get round towards 0.

- And I think that rounding up and rounding down are symmetrical, so if you can 
do one, you can do the other.

As Vedran correctly points out, the tricky part is adjusting for the difference 
between decimal digits and bits.

Dotnet provides rounding modes for Math.Round:

https://docs.microsoft.com/en-us/dotnet/api/system.midpointrounding?view=netcore-3.1


So does Julia:

http://www.jlhub.com/julia/manual/en/function/round

http://www.jlhub.com/julia/manual/en/function/get_rounding


so I think that there is precedence for this in other languages.

--
nosy: +tim.peters
title: rnd() + rndup() in math -> Adding support for rounding modes to builtin 
round
versions: +Python 3.10 -Python 3.9

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



[issue41616] Global variable in whole project and Relative imports problem

2020-08-22 Thread Steven D'Aprano


Steven D'Aprano  added the comment:

One issue per ticket please.

Versions 3.9 and older are all in feature freeze, they will not get new 
features.

Combining a global declaration with an assignment has been requested before, 
and rejected. If you want to discuss that feature again, you should raise it on 
the Python-Ideas mailing list first, but unless you have a stronger reason than 
just saving a line of code, it probably won't be accepted.

Project-wide globals has not, as far as I can remember, been requested before, 
but again it needs to be discussed on Python-Ideas first.

Your comments about relative imports don't seem to be either a feature request 
or a bug report, but just a vague complaint that it often causes problems. 
Please be more precise.

Problems with global variables are nearly always problems with global 
variables, not bugs with Python. Global variables are very easy to misuse and 
often cause problems.

https://weblogs.asp.net/wallen/6750

http://wiki.c2.com/?GlobalVariablesAreBad

--
nosy: +steven.daprano
versions:  -Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

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



[issue41598] rnd() + rndup() in math

2020-08-21 Thread Steven D'Aprano


Steven D'Aprano  added the comment:

Marco, it is better to give a description of the functionality required rather 
than a simplistic and incorrect implementation :-)

(Not that I am likely to provide a better implementation without a lot of 
study.)

Regardless of whether you or I agree with the decision to move to Banker's 
Rounding, that was done about a decade ago, and it matches decisions made by 
other languages such as Julia. Changing the default will break people's code 
and we do not do that lightly, or at all, without a very good reason.

As Tim Peters describes here:

https://mail.python.org/pipermail/python-dev/2008-January/075873.html

many older languages implemented rounding by "add half and chop", more because 
it was cheap than for its mathematical properties.

Are you satisfied that adding a rounding mode to the built-in `round` function 
is a better solution than a series of functions in the math module? If so, I 
will change the title to reflect that.

Vedran: I don't think the availability of different rounding modes will have 
any effect at all on whether or not people believe floats are real decimal 
numbers rather than binary floats. People already believe that. I think we are 
better off acknowledging that there are reasonable use-cases for different 
rounding modes even when using floats.

According to this:

https://www.gnu.org/software/libc/manual/html_node/Rounding.html

IEEE-754 only requires four rounding modes, defaulting to the same Banker's 
Rounding that Python uses. Wikipedia says there are five:

https://en.wikipedia.org/wiki/IEEE_754#Rounding_rules


Regardless of whether there are four or five, I see no technical reason why we 
couldn't offer the full set of eight used by the decimal module.

--

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



[issue41598] rnd() + rndup() in math

2020-08-21 Thread Steven D'Aprano


Steven D'Aprano  added the comment:

Vedran: you are quoting von Neumann out of context, he was talking about 
generating random numbers, not rounding, and in the seven decades since he made 
his famous witticism, we of course know that there is absolutely nothing wrong 
with generating random numbers via arithmetical methods so long as you do it 
correctly :-)

I have read your comments in the linked Stackoverflow answer, and I don't agree 
that we shouldn't be rounding binary floats. I do, however, agree with your 
comment here that we ought to add a rounding mode to the built-in round 
function, that would be a much better idea than adding a multitude of 
individual rounding functions.

I proposed this idea some time ago:

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

--
nosy: +steven.daprano

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



[issue41590] "zip()" very slowly for this

2020-08-19 Thread Steven D'Aprano


Steven D'Aprano  added the comment:

If you know about timeit, why aren't you using it?

In any case, I have just ran your nested_lists.py file, and on my 
computer, the last version with zip is the fastest version:

0 transpose1_0(lT) Time =  1.0627508163452149e-05
7 zip(*lT) Time =  1.5511512756347657e-06

1.55e-6 is smaller than 1.06e-5:

py> 1.55e-6 < 1.06e-5
True

Smaller times are faster, and the first version transpose1_0 takes 
nearly seven times longer to run than the last version with zip.

As for the other comments, the purpose of the tutorial is to teach the 
language in the simplest way possible. It is aimed at beginners, not 
intermediate or expert programmers. The purpose of this section is to 
demonstrate the basic features of list comprehensions, not to overwhelm 
the beginner with complicated details.

Making the example more complicated so that it is a tiny bit faster 
would not a good tradeoff for the tutorial, but in fact all the more 
complicated versions are slower, not faster.

You are also confused about the structure of comprehensions. The 
comprehension consists of 

expression-part for-part (optional for- and if-parts)

There is no else-part in the comprehension, and the for-part always 
comes before any if-part. Your code:

row[j] if j < len(row) else 0

is not an "if statement" as you call it, neither is it part of the 
comprehension syntax. It is the expression-part of the comprehension, 
containing a ternary if-expression. It is not part of the structure of 
the comprehension.

See the full language specification, in particular the grammar:

https://docs.python.org/3.9/reference/grammar.html

We could re-write the if-expression like this:

(j < len(row)) and row[j] or 0

That doesn't mean that comprehensions consist of an "and" part followed 
by an "or" part followed by a for-part. The "and" and "or" are just part 
of the expression part of the comprehension.

Adding this level of technical detail and complexity to an introductory 
tutorial aimed at beginners would not be a good idea.

--

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



[issue41590] "zip()" very slowly for this

2020-08-19 Thread Steven D'Aprano


Steven D'Aprano  added the comment:

What are you actually reporting? What part of the documentation do you think 
should be changed, why should it be changed, and what should it be changed to?

It is normal for different algorithms to perform with different speed. I'm not 
sure what the purpose of the "nested_lists" file is. You have discovered that 
different programs perform differently. Okay. What do you want us to do?

One last comment: using time() as you did is unreliable, especially for small 
code snippets that are very fast. The best way to time small snippets of Python 
code is to use the timeit module.

--
nosy: +steven.daprano

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



[issue41563] .python_history file causes considerable slowdown

2020-08-17 Thread Steven D'Aprano


Steven D'Aprano  added the comment:

> My history file is only 500 lines.

*slaps forehead*

Of course it is, I'm running a customer history hook that has a limit of 500 
lines in the history file.

It looks to me that by default the history feature is set to unlimited lines, 
so I guess that implies that this isn't a bug and it is your responsibility to 
set a maximum history length.

You can put these two lines in your Python startup file:

import readline
readline.set_history_length(1000)  # or any number you like



Personally, I don't think that having a default setting that allows the history 
file to grow to 130MB is a good idea.

--

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



[issue41563] .python_history file causes considerable slowdown

2020-08-17 Thread Steven D'Aprano


Steven D'Aprano  added the comment:

How very odd. I use the Python interactive interpreter extensively, and have 
done so for years. My history file is only 500 lines.

Did you happen to inspect the file before deleting it to see if it contained 
something odd?

What does this print for you?

import readline
readline.get_history_length()

--
nosy: +steven.daprano

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



[issue41558] Backspace not clearing the text

2020-08-15 Thread Steven D'Aprano


Steven D'Aprano  added the comment:

Works correctly for me in the Python interpreter.

Please check if it works for you in the Python interpreter, if it does, then it 
is a bug in Jupyter and should be reported to them, we cannot do anything to 
fix it.

--
nosy: +steven.daprano

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



[issue41542] module `__all__` cannot detect function name with `φ`

2020-08-14 Thread Steven D'Aprano

Steven D'Aprano  added the comment:

On Fri, Aug 14, 2020 at 02:03:37PM +, Seth Woodworth wrote:

> I'm exploring what unicode code points can be used as valid starting 
> characters for identifiers.

I presume you have seen the documention here:

https://docs.python.org/3/reference/lexical_analysis.html#identifiers

> I'm looping over the code point ranges 
> with the XID_START property and attempting to add them to globals() to 
> see if they maintain the same representation.

You can add any hashable key to globals, it's just a dict:

py> globals()[2] = 'test'
py> globals()[2]
'test'

Including strings that differ in their normalization:

py> import unicodedata
py> phi = 'ϕ'
py> nphi = unicodedata.normalize('NFKC', phi)
py> g = globals()
py> g[phi] == g[nphi]
False

The strings are only normalised when used as variables:

py> eval(f'{phi} == {nphi}')
True

--

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



[issue41545] gc API requiring matching number of gc.disable - gc.enable calls

2020-08-13 Thread Steven D'Aprano


Steven D'Aprano  added the comment:

> I wrap a function's logic with `gc.disable()` to prevent GC from triggering 
> some race condition.

If this race condition is a bug in gc, then we should fix that.

If it is a bug in your code, surely you should fix that rather than disable gc.

Either way, I don't think we should complicate the gc iterface by adding a 
second way to enable and disable the cyclic gc.

--
nosy: +steven.daprano

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



[issue41542] module `__all__` cannot detect function name with `φ`

2020-08-13 Thread Steven D'Aprano


Steven D'Aprano  added the comment:

Hi Seth,

Surely you aren't relying on the behaviour that names in `__all__` *aren't* 
normalised but others are?

Rather than a warning, I think the right solution here is to normalise the 
names in `__all__`.

--
nosy: +steven.daprano

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



[issue41518] incorrect printing behavior with parenthesis symbols

2020-08-11 Thread Steven D'Aprano


Steven D'Aprano  added the comment:

On Tue, Aug 11, 2020 at 07:16:20AM +, Ramesh Sahoo wrote:

> for i in stack:
> print("inside if Popped =",stack.pop(stack.index(i)))

You are mutating the list while you iterate over it. This is prone to 
cause trouble. Here's is a much smaller and simpler demonstration:

items = [1, 2, 3, 4, 5]
for index, value in enumerate(items):
print(f"index: {index}, value: {value}, items: {items}")
if value == 2:
x = items.pop(index)
print(f"after popping 2: {items}")

which has output:

index: 0, value: 1, items: [1, 2, 3, 4, 5]
index: 1, value: 2, items: [1, 2, 3, 4, 5]
after popping 2: [1, 3, 4, 5]
index: 2, value: 4, items: [1, 3, 4, 5]
index: 3, value: 5, items: [1, 3, 4, 5]

If you trace the code execution in your head, you will see that this is 
correct behaviour: Python is walking the list from position to position, 
but you removed one of the values so everything shifts and you end up 
skipping a value, because it moves before the loop can reach it.

The lesson here is:

Don't mutate a list that you are iterating over if you can avoid it. It 
you cannot avoid it, you can avoid problems by iterating in reverse, and 
only mutating the part of the list you have already processed.

But better to avoid mutation altogether.

So not a bug. Python is doing exactly what you told it to do.

--

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



[issue41517] Able to subclass enum with members by using multiple inheritance

2020-08-10 Thread Steven D'Aprano


Steven D'Aprano  added the comment:

The documentation says:

"Allowing subclassing of enums that define members would lead to a violation of 
some important invariants of types and instances."

but it isn't clear what those invariants are, or why it is more of a problem 
for enums than any other subclassing situation. Could the docs be updated to 
explain why it is prohibited?

--
nosy: +steven.daprano
title: Enum multiple inheritance loophole -> Able to subclass enum with members 
by using multiple inheritance

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



[issue41518] incorrect printing behavior with parenthesis symbols

2020-08-10 Thread Steven D'Aprano


Steven D'Aprano  added the comment:

Python 3.6 has reached security-fix only stage:

https://www.python.org/dev/peps/pep-0494/#schedule-last-bugfix-release

so even if this is a bug, it won't be fixed in 3.6.

I cannot reproduce this in 3.7, and Eric cannot reproduce in 3.6.9, so I'm 
closing the issue. Please re-open if you can reproduce in 3.8 or better. (3.7 
is also only accepting security fixes only.)

(Eric do you concur? If you disagree please feel free to re-open.)

--
nosy: +steven.daprano
resolution:  -> works for me
stage:  -> resolved
status: open -> closed

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



[issue41495] SPAM

2020-08-06 Thread Steven D'Aprano


Change by Steven D'Aprano :


--
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
title: Technical advise -> SPAM

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



[issue41495] Technical advise

2020-08-06 Thread Steven D'Aprano


Change by Steven D'Aprano :


--
Removed message: https://bugs.python.org/msg374932

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



[issue41481] pip install will install version 0.0.0 if existing in stead of newer ones

2020-08-04 Thread Steven D'Aprano


Steven D'Aprano  added the comment:

This is a bug tracker for issues with the Python language, interpreter and 
standard library. For third party applications like pip, please report bugs to 
their maintainers.

https://github.com/pypa/pip/issues

--
nosy: +steven.daprano
resolution:  -> third party
stage:  -> resolved
status: open -> closed

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



[issue41479] pip install== will install 0.0.0 version in stead of showing alll

2020-08-04 Thread Steven D'Aprano


Steven D'Aprano  added the comment:

This is a bug tracker for issues with the Python language, interpreter and 
standard library. For third party applications like pip, please report bugs to 
their maintainers.

https://github.com/pypa/pip/issues

--
nosy: +steven.daprano
resolution:  -> third party
stage:  -> resolved
status: open -> closed

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



[issue41407] Tricky behavior of builtin-function map

2020-07-27 Thread Steven D'Aprano


Steven D'Aprano  added the comment:

Converting *all* exceptions into RuntimeError is certainly not a good idea, 
especially since you include KeyboardInterrupt and other non-errors.

I'm probably going to be on the losing side of this one (I lost the argument 
back when a similar issue was raised about comprehensions), but I argue that 
this is not a bug it is a useful feature.

Having the map function raise StopIteration is a good way for the map to halt 
the loop early, when it detects a special sentinel or condition. A few years 
ago the change to comprehensions broke my code so I changed to map, and now you 
want to break it again :-(

--
nosy: +steven.daprano

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



[issue41301] Assignment operation of list is not working as expected

2020-07-15 Thread Steven D'Aprano


New submission from Steven D'Aprano :

Sorry Yashwanthbarad, this isn't a bug, you expect the wrong result.

Augmented assignment for lists is documented to be the same as calling the 
extend method, which means your AppenedFuncShortHandOperator function modifies 
the argument list in-place.

The AppenedFuncRegularAssignment simply replaces the *local variable* inside 
the function with a new list. Since it doesn't return the new list, the new 
list gets thrown away when the function returns, leaving the original list 
untouched.

This is not a bug, it is the normal behaviour. If you need help understanding 
why it works the way it does, and the difference between mutating an object and 
binding a new object to a local variable, there are many places you can ask for 
help, such as Stackoverflow, the /learnpython sub-reddit on Reddit, the tutor 
mailing list and others.

https://mail.python.org/mailman/listinfo/tutor

Good luck!

--
nosy: +steven.daprano
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

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



[issue41297] Remove doctest import from heapq

2020-07-14 Thread Steven D'Aprano


Steven D'Aprano  added the comment:

The idiom of a module running doctests on itself when executed as a script is a 
common idiom.

If modulegraph and pyinstaller can't cope a module importing another module 
from inside an if statement, that's a bug in them, not in the heapq module (and 
many others).

This requested change is a regression, taking away functionality. 3.8 and older 
are in feature freeze, so this could only apply to 3.9 and 3.10, and even then, 
I do not believe it should apply at all.

--
nosy: +steven.daprano
versions:  -Python 3.5, Python 3.6, Python 3.7, Python 3.8

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



[issue41276] Min / Max returns different values depending on parameter order

2020-07-10 Thread Steven D'Aprano


Steven D'Aprano  added the comment:

In your first example, `min([(-5, 2), (0, 2)])` the min() function compares the 
two tuples and finds that the first one is lexicographically smaller:

py> (-5, 2) < (0, 2)
True

so (-5, 2) is considered the minimum. In the second example, using the key 
function compares 2 with 2, but since they are equal, the *first* tuple wins 
and is considered the minimum, and so using the key function doesn't change the 
result.

In your third example, after reversing the list, you have `min([(0, 2), (-5, 
2)])` and the min() function compares the two tuples and finds the *second* 
tuple is the smaller:

py> (0, 2) < (-5, 2)
False

But in the fourth example, using the key function, yet again the comparison 
compares 2 with 2 and finds them equal, and so the *first* tuple wins and (0, 
2) is declared the minimum.

When using the key function, only the second item of the tuple is looked at; 
the first item is ignored. So the difference between 0 and -5 is irrelevant, 
and the tie is decided by which element was seen first.

--

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



[issue41276] Min / Max returns different values depending on parameter order

2020-07-10 Thread Steven D'Aprano


Steven D'Aprano  added the comment:

This is correct behaviour. What makes you think otherwise?

For future bug reports, please don't post screen shots of text, copy and paste 
the text into the body of your bug report.

Posting screenshots makes it difficult for us to copy and run your code, and 
discriminates against the blind and visually impaired who may be reading this 
with a screen-reader, which doesn't not work with images.

--
nosy: +steven.daprano
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

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



[issue41274] Better way to random.seed()?

2020-07-10 Thread Steven D'Aprano


Steven D'Aprano  added the comment:

This is definitely cool though. It might make a really sweet example in the 
demos that come with Python, or in the tutorial, showcasing both the 
awesomeness of HelioViewer and how to use Python to connect to web APIs.

https://github.com/python/cpython/tree/master/Tools/demo

--
nosy: +steven.daprano

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



[issue41243] SPAM

2020-07-08 Thread Steven D'Aprano


Change by Steven D'Aprano :


--
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
title: Android Game -> SPAM
type: security -> 

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



[issue41240] Use the same kind of quotation mark in f-string

2020-07-08 Thread Steven D'Aprano


Steven D'Aprano  added the comment:

Just change the f string quotes.

Python strings, whether f-strings or not, can be delimited by '' or "" or 
triple quotes. So this works:


>>> f"But, {'this quote is right.'}"
'But, this quote is right.'

Remember that the part of the f-string is evaluated as code, converted to a 
string, and interpolated into the rest of the f-string body. This is why the 
quotes disappear.

If you need both kinds of quotes, use triple-quotes as the delimiter:

>>> f"""Both {'single and "double" quotes'.title()}"""
'Both Single And "Double" Quotes'

I assume you want to pass the '' string to a function or something, and this 
example is just a simplified version. Because if there is no function call 
needed, you should just use a regular string, there's no need for an f-string:

"But, 'this quote is right.'"

--
nosy: +steven.daprano

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



[issue41198] Round built-in function not shows zeros acording significant figures and calculates different numbers of odd and even

2020-07-02 Thread Steven D'Aprano


Steven D'Aprano  added the comment:

If you change the starting point of the rounding away from zero, the bias flips 
back and forth, which is exactly what I would expect from Banker's Rounding:


def check_bias(start):
d = 0.001
ne = no = 0
for i in range(1000):
digit = int(round(start + i * d, 1) * 10)
if digit & 1:
no += 1
else:
ne += 1
return ne, no


# Python 3.7
>>> check_bias(0.0)
(501, 499)
>>> check_bias(0.1)
(500, 500)
>>> check_bias(0.2)
(499, 501)
>>> check_bias(0.3)
(499, 501)
>>> check_bias(0.4)
(500, 500)
>>> check_bias(0.5)
(499, 501)
>>> check_bias(0.6)
(501, 499)


I ran the same check_bias in Python 2.7, which doesn't use bankers rounding, 
and the bias is consistently in one direction:

# Python 2.7
>>> check_bias(0.0)
(500, 500)
>>> check_bias(0.1)
(499, 501)
>>> check_bias(0.2)
(498, 502)
>>> check_bias(0.3)
(498, 502)
>>> check_bias(0.4)
(499, 501)
>>> check_bias(0.5)
(498, 502)
>>> check_bias(0.6)
(500, 500)

--

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



[issue41198] Round built-in function not shows zeros acording significant figures and calculates different numbers of odd and even

2020-07-02 Thread Steven D'Aprano


Steven D'Aprano  added the comment:

Thank you for your long and detailed bug report, but please post one issue per 
bug report.

Tim, we agree that the notion of significant figures is irrelevant; is Carlos' 
even/odd test sufficiently flawed that we should close this bug report, or keep 
it open to investigate the rounding bias issue? My feeling is that it is 
sufficiently flawed that we can just close this, but it's too early in the 
morning for me to articulate why :-)

--
nosy: +steven.daprano

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



[issue41166] CLASS ATTRIBUTES

2020-06-30 Thread Steven D'Aprano


Steven D'Aprano  added the comment:

By the way, for future reports, it is much better to give the URL of the page 
and copy and paste the exact quote than to give a screen shot. Using a screen 
shot is inconvenient for us (we have to try to guess what URL you are referring 
to, there are *lots* of pages in the documentation) and discriminates against 
the visually impaired and blind, who may be using screen readers. (They 
typically do not work with images.)

Thank you.

--

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



[issue41166] CLASS ATTRIBUTES

2020-06-30 Thread Steven D'Aprano


Steven D'Aprano  added the comment:

"Class attribute" and "instance attribute" are the usual terms used in the 
Python documentation and community. I have heard other terms used in other 
language communities, in particular "members" and "variables", but I've never 
come across one that uses "value". Do you mind if you tell us where you have 
seen this used?

We have 30 years of talking about class and instance attributes, we're not 
going to change now. 

Java has ClassValue:

https://docs.oracle.com/javase/7/docs/api/java/lang/ClassValue.html

and Scala talks about "value classes", but neither seem to be what you are 
talking about.

See also:

https://stackoverflow.com/questions/11350423/terminology-of-class-attribute-vs-member-vs-variable-vs-field

--
nosy: +steven.daprano
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

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



[issue41071] from an int to a float , why

2020-06-22 Thread Steven D'Aprano


Steven D'Aprano  added the comment:

Mike, the bug tracker is not a help-desk for questions. There are many other 
forums where you can ask for help:

- the python-list and tutor mailing lists 
  https://www.python.org/community/lists/

- Stackoverflow

- The Python IRC channel https://www.python.org/community/irc/

- Reddit's r/learnpython

- https://python-forum.io/

--
nosy: +steven.daprano

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



[issue41057] Division error

2020-06-20 Thread Steven D'Aprano


Steven D'Aprano  added the comment:

Further to what Mark said, I'm afraid you are mistaken when you thought that 
"the result was correct" on R. R cheats by not printing the full precision of 
the number, they just stop printing digits, giving a false impression of 
accuracy. You can prove this for yourself:

> 0.4 + 8/100
[1] 0.48
> (0.4 + 8/100) == 0.48
[1] FALSE

So even though the printed result *looks* like 0.48, it actually isn't. If you 
investigate carefully, you will probably find that the number R calculates is 
the same as Python.

And the same as Javascript:

js> 0.4 + 8/100
0.48004

and pretty much every programming language that uses 64-bit floats.


BTW, this is a FAQ:

https://docs.python.org/3/faq/design.html#why-are-floating-point-calculations-so-inaccurate

There are a ton of other resources on the web explaining this, since it occurs 
virtually everywhere, in every language with fixed-precision floating point 
numbers. For example:

https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html

https://randomascii.wordpress.com/2012/05/20/thats-not-normalthe-performance-of-odd-floats/

https://randomascii.wordpress.com/2012/04/05/floating-point-complexities/

--
nosy: +steven.daprano

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



[issue40981] increment is wrong in 3.7 but not in 2.7

2020-06-15 Thread Steven D'Aprano


Steven D'Aprano  added the comment:

On Mon, Jun 15, 2020 at 07:37:16PM +, mike stern wrote:
> sorry but I don't see the option to delete

Your keyboard has a Delete key and a Backspace key. Select the quoted 
text in your email client and press one or the other.

If you can't see the quoted text in Hotmail, them I'm afraid you will 
have to do some homework of your own and find out how to do it in 
Hotmail.

Possibly there is an option to reply *without* quoting the message you 
are replying to?

--

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



[issue40981] increment is wrong in 3.7 but not in 2.7

2020-06-15 Thread Steven D'Aprano


Steven D'Aprano  added the comment:

> I wouldn't trust a language behaving crazy like this

I guess then you won't trust C, Java, C++, Swift, Javascript, Ruby, Cobol, 
Fortran, and pretty much every programming language in existence. The only ones 
that escape this are ones that don't have floating point numbers at all.


> you haven't tried it on 2.7 did you ?

We know how Python 2.7 works. Some of us have been using Python for 25 years, 
since version 1.5 or older. Do you think you are the first person to have 
noticed this? There are hundreds of thousands of Python programmers, believe me 
you're not the first, or even the ten-thousandth person to have noticed.

Python 2.7 rounds off the default display of floats to make them look "pretty" 
instead of displaying their actual value. Try this in 2.7 and see what happens:

i=0
while i < 1.2:
i += 0.1
print "default:", i, "actual: %.24f" % i

The calculations are *precisely* the same, only the display is different.

Honestly Mike, this is not a Python issue, it is universal to all languages 
with fixed-size floating point numbers. This is not a bug, it is how numeric 
computing works *everywhere*. People write peer reviewed scientific papers 
about this:

http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.22.6768

https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html


If you want to educate yourself on the issue, rather than just rant about not 
trusting the language and abuse people who have been using the language for 
decades, you could do a lot worse than to start here:

https://randomascii.wordpress.com/2012/05/20/thats-not-normalthe-performance-of-odd-floats/

https://randomascii.wordpress.com/2012/04/05/floating-point-complexities/

and take careful note that the author talks about C, probably the most common, 
fundamental and trusted programming language in the world. (Also remember that 
when Bruce Dawson talks about floats in C, they are half the precision of 
Python floats, which are C doubles.)

The bottom line is that floats are not the infinitely precise exact 
mathematical numbers we learn about in school, they are more like the numbers 
you get on a calculator.

--
nosy: +steven.daprano

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



[issue40911] Unexpected behaviour for += assignment to list inside tuple

2020-06-08 Thread Steven D'Aprano


Steven D'Aprano  added the comment:

Alas, this gotcha is the consequence of the way `+=` is defined in Python. 
Although the behaviour is surprising, there's nothing to fix because everything 
is working as expected:

* addition to a list will extend the list, as expected;
* trying to assign into a tuple will fail, as expected.

It's just the combination that is surprising.

There's even a FAQ for it:

https://docs.python.org/3/faq/programming.html#why-does-a-tuple-i-item-raise-an-exception-when-the-addition-works

--
nosy: +steven.daprano
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

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



[issue40909] unittest assertCountEqual doesn't filter on values in dict

2020-06-08 Thread Steven D'Aprano


Steven D'Aprano  added the comment:

This is working as designed. assertCountEqual is documented here:

https://docs.python.org/3/library/unittest.html#unittest.TestCase.assertCountEqual

It says: "Test that sequence *first* contains the same elements as *second*..." 
notice that it talks about *sequences*, not mappings. The (approximate) 
equivalent code is also given:

assertEqual(Counter(list(first)), Counter(list(second)))

If the arguments are dicts, only the keys are compared. The example you give 
correctly passes, because it is equivalent to calling 
`assertCountEqual(first.keys(), second.keys())` and the keys are equal.

If you want to compare the items, you can call `assertCountEqual(first.items(), 
second.items())`.

The example comparing lists correctly fails because the list elements are 
different.

--
nosy: +steven.daprano
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

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



[issue40879] Strange regex cycle

2020-06-05 Thread Steven D'Aprano


Steven D'Aprano  added the comment:

Wait, I'm sorry, do you mean this?

py> repr(r)[13:-16]

'?i)b((?:[a-z][w-]+:(?:/{1,3}|[a-z0-9%])|wwwd{0,3}[.]|[a-z0-9.-]+[.][a-z]{2,4}/)(?:[^s()<>]+|(([^s()<>]+|(([^s()<>]+)))*))+(?:(([^s()<>]+|(([^s()<>]+)))*)|[^s`!()\\'

Referring to the pattern being truncated in the repr? I would assume that's 
intentional.

--

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



[issue40879] Strange regex cycle

2020-06-05 Thread Steven D'Aprano

Steven D'Aprano  added the comment:

> notice the stripped characters in the `repr`

Er, no. Your regex looks like line noise, and it hurts my brain to look at it 
:-)

If you have spotted a difference, can you tell us what characters are stripped? 
When I try running it, I don't get any characters stripped at all:

py> import re
py> STR_RE_URL = 
r"""(?i)\b((?:[a-z][\w-]+:(?:/{1,3}|[a-z0-9%])|www\d{0,3}[.]|[a-z0-9.\-]+[.][a-z]{2,4}/)(?:[^\s()<>]+|\(([^\s()<>]+|(\([^\s()<>]+\)))*\))+(?:\(([^\s()<>]+|(\([^\s()<>]+\)))*\)|[^\s`!()\[\]{};:'".,<>?«»“”‘’]))"""
py> r = re.compile(STR_RE_URL)
py> r.pattern == STR_RE_URL
True

--
nosy: +steven.daprano

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



[issue40863] bytes.decode changes/destroys line endings on windows

2020-06-04 Thread Steven D'Aprano


Steven D'Aprano  added the comment:

You don't need `b = bytes([0x41, 0x0D, 0x0A])`, this will work just as well:

b = b'\x41\x0D\x0A'

and this is even better:

b = b'A\r\n'


> It seems like bytes.decode always replaces "\n" with "\r\n".

What makes you say that? You are passing the output through print, which does 
things with newlines and carriage returns. Try this, for example:

py> print('ABCD\rZ\n', end='')
ZBCD


The best way to see what your string actually contains is the print the repr:

print(repr(b.decode('utf-8')))

which I'm pretty sure will print A\r\n as you expect. But I don't have a 
Windows box to test it on.

--
nosy: +steven.daprano

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



[issue40855] statistics.stdev ignore xbar argument

2020-06-03 Thread Steven D'Aprano


Steven D'Aprano  added the comment:

Thanks Raymond, that is the intended effect, and your analysis seems 
plausible.

--

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



[issue40809] list.Count() isn't working as expected for the series of same numbers in a list

2020-05-28 Thread Steven D'Aprano


Steven D'Aprano  added the comment:

Typo:

"on each step, you delete one item from the from and step forward"

Should be, you delete one item from the FRONT and step forward.

--

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



[issue40809] list.Count() isn't working as expected for the series of same numbers in a list

2020-05-28 Thread Steven D'Aprano

Steven D'Aprano  added the comment:

Rémi is correct, this is not a bug.

The problem isn't with list.count. If you print list.count each time through 
the loop, you will see that it is working perfectly. 

The problem is that you are modifying the list as you are iterating over it. 
That means that you skip every second item. It isn't easy to see when all the 
items are the same, but we can alternate int and float values (which are equal) 
to see how every second value is skipped.


py> a = [1, 1.0, 1, 1.0, 1, 1.0, 1, 1.0]
py> for i in a:
... print(a, i, a.count(i))
... if a.count(i) > 1:
... a.remove(i)
...
[1, 1.0, 1, 1.0, 1, 1.0, 1, 1.0] 1 8
[1.0, 1, 1.0, 1, 1.0, 1, 1.0] 1 7
[1, 1.0, 1, 1.0, 1, 1.0] 1 6
[1.0, 1, 1.0, 1, 1.0] 1 5
py> a
[1, 1.0, 1, 1.0]


Notice that every one of the float 1.0 values gets skipped. That's because when 
you resize the list as you walk over it, the value which *would have been* the 
next value gets pushed back into the current position, and then you advance to 
the next position, and skip it.

So there's no bug in list.count, it is working perfectly each time. There's no 
bug in iteration either, it is walking the list correctly too. But there is a 
bug in your code: you are shrinking the list while walking over it, so on each 
step, you delete one item from the from and step forward, so you skip items.

The lesson here is not to delete items from a list while you are iterating over 
it.

Technically, it's okay to delete items so long as they are *ahead* of the 
current item, but not if they are *behind* it. But it is easiest to just use 
the rule, never delete items while iterating over the same list.

If you must delete items from a list, iterate over a copy.

--
nosy: +steven.daprano
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

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



[issue40762] Writing bytes using CSV module results in b prefixed strings

2020-05-26 Thread Steven D'Aprano

Steven D'Aprano  added the comment:

On further thought, no, I don't think it would be a reasonable feature.

User opens the CSV file, probably using the default encoding (UTF-8?) 
but potentially in anything.

They collect some data as bytes. Those bytes could be from any unknown 
encoding. When they try writing those bytes to the CSV file, at best 
they get an explicit but confusing exception that the decoding failed, 
at worst they get data loss (mojibake).

# Latin-1 to UTF-8 fails
py> b = 'ßæ'.encode('latin-1')
py> b.decode('utf-8')
# raises UnicodeDecodeError: 'utf-8' codec can't decode 
# byte 0xdf in position 0: invalid continuation byte

# UTF-8 to Latin-1 loses data
py> b = 'ßæ'.encode('UTF-8')
py> b.decode('latin-1')
# returns mojibake 'Ã\x9fæ'

Short of outright banning the use of bytes (raise a TypeError), I think 
the current behaviour is least-worst.

--

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



[issue40762] Writing bytes using CSV module results in b prefixed strings

2020-05-26 Thread Steven D'Aprano


Steven D'Aprano  added the comment:

The csv file object knows the encoding it was opened with, I think?

If so, we could add an enhancement that bytes objects are first decoded to str 
using the same encoding the file was opened with. That seems like a reasonable 
new feature to me.

Everything else would continue to be passed through str().

--
nosy: +steven.daprano
type: behavior -> enhancement

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



[issue40761] unittest.TestCase.asserTrue return True even if the expr is False

2020-05-24 Thread Steven D'Aprano


Steven D'Aprano  added the comment:

Works for me in 3.7. See attached file. Can you provide a minimal piece of code 
that demonstrates the bug?

Since Python 3.5 is now only accepting security fixes, and numpy is a 
third-party library, unless you can demonstrate this in a more recent version I 
think we should close this as "Works For Me".

--

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



[issue40761] unittest.TestCase.asserTrue return True even if the expr is False

2020-05-24 Thread Steven D'Aprano


Change by Steven D'Aprano :


Added file: https://bugs.python.org/file49192/test_asserttrue.py

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



[issue40761] unittest.TestCase.asserTrue return True even if the expr is False

2020-05-24 Thread Steven D'Aprano


Change by Steven D'Aprano :


Removed file: https://bugs.python.org/file49191/test_asserttrue.py

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



[issue40761] unittest.TestCase.asserTrue return True even if the expr is False

2020-05-24 Thread Steven D'Aprano


Change by Steven D'Aprano :


--
Removed message: https://bugs.python.org/msg369846

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



[issue40761] unittest.TestCase.asserTrue return True even if the expr is False

2020-05-24 Thread Steven D'Aprano


Steven D'Aprano  added the comment:

Works for me in Python 3.7. See attached file.

Given that Python 3.5 is only longer accepting security fixes, and that numpy 
is a third-party library, unless you can reproduce this in a more recent 
version I think we should close this.

--
nosy: +steven.daprano
Added file: https://bugs.python.org/file49191/test_asserttrue.py

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



[issue40028] Math module method to find prime factors for non-negative int n

2020-05-22 Thread Steven D'Aprano

Steven D'Aprano  added the comment:

On Fri, May 22, 2020 at 10:23:06AM +, Rémi Lapeyre wrote:
> As you said the PEP would have to explain why not just use sympy and 
> honestly I don't have a very good argument there for now.

Because sympy is a beast. It's an excellent beast, but its an absolute 
monster. I stopped counting at 400 modules, not including tests. Having 
to install a mega-library like sympy to get two or three functions is 
overkill, like using a nuclear-powered bulldozer to crack a peanut.

The sympy docs say:

"SymPy does require mpmath Python library to be installed first. The 
recommended method of installation is through Anaconda, which includes 
mpmath, as well as several other useful libraries. Alternatively, some 
Linux distributions have SymPy packages available."

which is great if you are using Anaconda, a little less great if you're 
using Linux, and not very good if you're not using either.

And it's especially not very good if you are a student using a school 
laptop where Python is installed but you are not permitted to install 
other software. (Likewise for corporate users with locked down desktops, 
although they are less likely to care about prime numbers.)

sympy also comes with it's own odd ways of doing things, such as having 
to care about the difference between Python numbers and sympy numbers. 
(Not for prime testing, admittedly. I'm just making a general 
observation.)

--

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



[issue40682] random.Random.seed() with version=1 does not consistently match Python 2 behavior

2020-05-19 Thread Steven D'Aprano


Steven D'Aprano  added the comment:

3.5 and 3.6 are now only accepting security fixes.

Only the stability of random.random is guaranteed across versions, but you are 
calling randrange:

https://docs.python.org/3/library/random.html#notes-on-reproducibility

So I am pretty sure that this will not be considered a bug (unless it is a 
design bug).

Personally I think that the lack of reproducibility of the full range of random 
methods is a rather large annoyance: if you care about reproducibility, 
including doctests, you cannot use anything in the module except random.random, 
but have to write your own implementation (possibly by copying and pasting).

I don't have a good solution for this though.

--
nosy: +steven.daprano
versions:  -Python 3.5, Python 3.6

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



  1   2   3   4   5   6   7   8   9   10   >