[issue41884] tempfile.py TemporaryDirectory/mkdtemp defaults to mode 0o700, propose to add mode argument

[Raymond Sit]

Change by Raymond Sit :


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

___
Python tracker 

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

[issue40631] PEG Parser: Cannot used starred expression in parenthesised expr

[Pablo Galindo Salgado]

Change by Pablo Galindo Salgado :


--
pull_requests: +22859
pull_request: https://github.com/python/cpython/pull/24019

___
Python tracker 

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

[issue29708] support reproducible Python builds

[Inada Naoki]

Inada Naoki  added the comment:

See bpo-34093 too.

--

___
Python tracker 

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

[issue40631] PEG Parser: Cannot used starred expression in parenthesised expr

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

> I'll work on finding out when this got messed up and fix it.

Apparently is 

commit bca701403253379409dece03053dbd739c0bd059 (HEAD)
Author: Lysandros Nikolaou 
Date:   Tue Oct 27 00:42:04 2020 +0200

bpo-42123: Run the parser two times and only enable invalid rules on the 
second run (GH-22111)


~/github/python/master v3.10.0a2~61 9s
❯ ./python -c "(*x), y = 1,2"

~/github/python/master v3.10.0a2~61
❯ git checkout HEAD^
Previous HEAD position was bca7014032 bpo-42123: Run the parser two times and 
only enable invalid rules on the second run (GH-22111)
HEAD is now at c8c4200b65 bpo-42157: Convert unicodedata.UCD to heap type 
(GH-22991)

~/github/python/master remotes/welikeparsers/master
❯ make -j -s
 CC='gcc -pthread' LDSHARED='gcc -pthread -shared' OPT='-g -Og -Wall'   
_TCLTK_INCLUDES='' _TCLTK_LIBS=''   ./python -E ./setup.py -q build

The following modules found by detect_modules() in setup.py, have been
built by the Makefile instead, as configured by the Setup files:
_abc  atexitpwd
time


~/github/python/master remotes/welikeparsers/master
❯ ./python -c "(*x), y = 1,2"
  File "", line 1
(*x), y = 1,2
 ^
SyntaxError: can't use starred expression here

--

___
Python tracker 

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

[issue42772] randrange() mishandles step when stop is None

[Raymond Hettinger]

Change by Raymond Hettinger :


--
assignee:  -> rhettinger

___
Python tracker 

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

[issue42772] randrange() mishandles step when stop is None

[Raymond Hettinger]

Raymond Hettinger  added the comment:

Upon further reflection, I think these cases should raise a TypeError because 
the meaning is ambiguous:

randrange(1000, step=10) # Could only mean start=0 stop=1000 step=10

but that conflicts with:

randrange(1000, None, 100)  # Has no reasonable interpretation

For comparison, this currently raises a TypeError because None isn't a sensible 
argument for stop:

range(1000, None, 100)

--

___
Python tracker 

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

[issue42772] randrange() mishandles step when stop is None

[Raymond Hettinger]

Change by Raymond Hettinger :


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

___
Python tracker 

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

[issue40631] PEG Parser: Cannot used starred expression in parenthesised expr

[Lysandros Nikolaou]

Lysandros Nikolaou  added the comment:

Yup, this all sounds much more reasonable. Thanks for the explanation, Guido.

> Also the current behavior allows `(*x), y = 1` assignment. If `(*x)` is to be 
> totally disallowed, `(*x), y = 1` should also be rejected.

This is allowed in 3.9.1 and 3.10.0a2, but not allowed in 3.9.0 and 3.10.0a1. 
I'll work on finding out when this got messed up and fix it.

--

___
Python tracker 

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

[issue42686] include built-in Math functions in SQLite to 3.35.0 of march 2021

[Erlend Egeberg Aasland]

Erlend Egeberg Aasland  added the comment:

Using SQLite 3.35.0 nightly build, building Python using PCbuild/build.bat and 
PCBuild\pcbuild.sln with VS 2017 (does this reflect how the Windows team build 
the installers?), I can confirm that math functions are _not_ included by 
default. I added SQLITE_ENABLE_MATH_FUNCTIONS to PCbuild/sqlite3.vcxproj, but 
then VS 2017 fails building sqlite:

1>-- Rebuild All started: Project: sqlite3, Configuration: Debug Win32 
--
1>sqlite3.c
1>c:\src\cpython.git\externals\sqlite-3.33.0.0\sqlite3.c(119997): error C2099: 
initializer is not a constant
1>c:\src\cpython.git\externals\sqlite-3.33.0.0\sqlite3.c(119997): warning 
C4047: 'initializing': 'FuncDef *' differs in levels of indirection from 'void 
(__cdecl *)(sqlite3_context *,int,sqlite3_value **)'
1>c:\src\cpython.git\externals\sqlite-3.33.0.0\sqlite3.c(119997): warning 
C4047: 'initializing': 'void (__cdecl *)(sqlite3_context *,int,sqlite3_value 
**)' differs in levels of indirection from 'char [5]'
1>c:\src\cpython.git\externals\sqlite-3.33.0.0\sqlite3.c(119998): error C2099: 
initializer is not a constant
1>c:\src\cpython.git\externals\sqlite-3.33.0.0\sqlite3.c(119998): warning 
C4047: 'initializing': 'FuncDef *' differs in levels of indirection from 'void 
(__cdecl *)(sqlite3_context *,int,sqlite3_value **)'
1>c:\src\cpython.git\externals\sqlite-3.33.0.0\sqlite3.c(119998): warning 
C4047: 'initializing': 'void (__cdecl *)(sqlite3_context *,int,sqlite3_value 
**)' differs in levels of indirection from 'char [8]'
1>c:\src\cpython.git\externals\sqlite-3.33.0.0\sqlite3.c(11): error C2099: 
initializer is not a constant
1>c:\src\cpython.git\externals\sqlite-3.33.0.0\sqlite3.c(11): warning 
C4047: 'initializing': 'FuncDef *' differs in levels of indirection from 'void 
(__cdecl *)(sqlite3_context *,int,sqlite3_value **)'
1>c:\src\cpython.git\externals\sqlite-3.33.0.0\sqlite3.c(11): warning 
C4047: 'initializing': 'void (__cdecl *)(sqlite3_context *,int,sqlite3_value 
**)' differs in levels of indirection from 'char [6]'
1>Done building project "sqlite3.vcxproj" -- FAILED.
== Rebuild All: 0 succeeded, 1 failed, 0 skipped ==

(Note, I've overwritten the files in the externals\sqlite-3.33.0.0 directory 
with the nightly build.)

--

___
Python tracker 

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

[issue40631] PEG Parser: Cannot used starred expression in parenthesised expr

[Guido van Rossum]

Guido van Rossum  added the comment:

> It makes sense to me to be able to do `(*a), b` if I can do `*a, b`, but I 
> don't really have a strong opinion on it.

I disagree. *a is not an expression, so the normal rules for parenthesizing 
those don't apply. I've always thought of *a as a feature of the "comma" 
syntax. Note too that (**a) is not valid and never was. Also note that 2.7 
doesn't support f((*a)). In fact 3.4 doesn't either -- but 3.5 does.

I don't know how this slipped into earlier Python 3 versions -- apparently 
there aren't tests for this, and it's not used in popular 3rd code either, or 
we would have found out when we first implemented PEP 617.

Most likely it's due to the general problem where the parser would just accept 
parenthesized stuff in various places where it shouldn't (e.g. also f(a=1) 
could be spelled as f((a)=1) -- this was fixed in 3.8).

> Also the current behavior allows `(*x), y = 1` assignment. If `(*x)` is to be 
> totally disallowed, `(*x), y = 1` should also be rejected.

I agree.

--

___
Python tracker 

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

[issue40631] PEG Parser: Cannot used starred expression in parenthesised expr

[Saiyang Gou]

Saiyang Gou  added the comment:

Also the current behavior allows `(*x), y = 1` assignment. If `(*x)` is to be 
totally disallowed, `(*x), y = 1` should also be rejected.

--

___
Python tracker 

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

[issue40631] PEG Parser: Cannot used starred expression in parenthesised expr

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Parenthesis can be added around expression. But `*a` is not an expression (as 
well as `+`, `or`, `1:5`, you cannot surround them with parenthesis).

--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue40631] PEG Parser: Cannot used starred expression in parenthesised expr

[Lysandros Nikolaou]

Lysandros Nikolaou  added the comment:

It makes sense to me to be able to do `(*a), b` if I can do `*a, b`, but I 
don't really have a strong opinion on it.

--

___
Python tracker 

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

[issue41224] Document is_annotate() in symtable and update doc strings

[Andrés Delfino]

Change by Andrés Delfino :


--
pull_requests: +22857
pull_request: https://github.com/python/cpython/pull/24017

___
Python tracker 

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

[issue41224] Document is_annotate() in symtable and update doc strings

[Andrés Delfino]

Change by Andrés Delfino :


--
pull_requests: +22856
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/24016

___
Python tracker 

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

[issue42792] [MacOS] Can't open file in a separate (threading.Thread) thread

[Mark Dickinson]

Mark Dickinson  added the comment:

Your test file has the line:

f = open("lol.txt", "r", "utf-8")

But the third positional argument to the 'open' built-in function is 
"buffering", which expects an integer. Pass the "utf-8" argument by name 
instead:

f = open("lol.txt", "r", encoding="utf-8")

As a side note, you probably also want to join your thread before exiting the 
script.

Closing here, since it looks as though there's no Python bug.

--
nosy: +mark.dickinson
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

___
Python tracker 

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

[issue40631] PEG Parser: Cannot used starred expression in parenthesised expr

[Guido van Rossum]

Guido van Rossum  added the comment:

Honestly this seems like a bug in 3.8 to me (if it indeed behaves like this):

>>> (*x), y
(1, 2, 3)

Every time I mistakenly tried (*x) I really meant (*x,), so it's surprising 
that (*x), y would be interpreted as (*x, y) rather than flagging (*x) as an 
error.

Please don't "fix" this even if it is a regression.

--

___
Python tracker 

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

[issue42792] [MacOS] Can't open file in a separate (threading.Thread) thread

[Jah-On]

Change by Jah-On :


Added file: https://bugs.python.org/file49710/lol.txt

___
Python tracker 

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

[issue42792] [MacOS] Can't open file in a separate (threading.Thread) thread

[Jah-On]

New submission from Jah-On :

Tested on MacOS Big Sur... Most recent version as of posting.

--
components: macOS
files: test.py
messages: 384088
nosy: Jah-On, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: [MacOS] Can't open file in a separate (threading.Thread) thread
versions: Python 3.8
Added file: https://bugs.python.org/file49709/test.py

___
Python tracker 

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

[issue40631] PEG Parser: Cannot used starred expression in parenthesised expr

[Pablo Galindo Salgado]

Change by Pablo Galindo Salgado :


--
pull_requests: +22855
pull_request: https://github.com/python/cpython/pull/24015

___
Python tracker 

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

[issue40631] PEG Parser: Cannot used starred expression in parenthesised expr

[Pablo Galindo Salgado]

Change by Pablo Galindo Salgado :


--
keywords: +patch
pull_requests: +22854
stage: resolved -> patch review
pull_request: https://github.com/python/cpython/pull/24014

___
Python tracker 

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

[issue40631] PEG Parser: Cannot used starred expression in parenthesised expr

[Pablo Galindo Salgado]

Change by Pablo Galindo Salgado :


--
resolution: not a bug -> 
status: closed -> open

___
Python tracker 

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

[issue42093] Add opcode cache for LOAD_ATTR

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

>Wow, this is amazing. I just found that this is now faster than slots. 

Not only that: is even faster than the highly-tuned namedtuple access 
descriptors that used to be the faster access to an attribute:

3.9 results
---
  17.6 ns   read_classvar_from_class
  16.3 ns   read_classvar_from_instance
  23.2 ns   read_instancevar
  19.7 ns   read_instancevar_slots
  17.9 ns   read_namedtuple
  39.2 ns   read_boundmethod

Now this is the faster way to get an attribute:

3.10 results

  17.9 ns   read_classvar_from_class
  16.9 ns   read_classvar_from_instance
  14.1 ns   read_instancevar
  20.0 ns   read_instancevar_slots
  18.0 ns   read_namedtuple
  40.7 ns   read_boundmethod

> Should we mention that in What's New?

Good idea!. I will prepare a PR complementing the current paragraph.

--

___
Python tracker 

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

[issue40631] PEG Parser: Cannot used starred expression in parenthesised expr

[Saiyang Gou]

Saiyang Gou  added the comment:

Well, there is actually a bug:

root@f1b4a742d8fc:/# python3.9
Python 3.9.1 (default, Dec  8 2020, 03:24:52)
[GCC 7.5.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> x = [1, 2]
>>> y = 3
>>> *x, y
(1, 2, 3)
>>> (*x), y
  File "", line 1
(*x), y
 ^
SyntaxError: can't use starred expression here

root@f1b4a742d8fc:/# python3.8
Python 3.8.6 (default, Oct  6 2020, 03:22:36)
[GCC 7.5.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> x = [1, 2]
>>> y = 3
>>> *x, y
(1, 2, 3)
>>> (*x), y
(1, 2, 3)

This is different from the previous message where the starred expression is 
"alone" (and thus invalid). Since this bug happens in 3.9 but not in 3.8, it 
might be due to the PEG parser.

Also,
root@f1b4a742d8fc:/# python3.9
Python 3.9.1 (default, Dec  8 2020, 03:24:52)
[GCC 7.5.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> del *x
  File "", line 1
del *x
^
SyntaxError: cannot delete starred
>>> del (*x)
  File "", line 1
del (*x)
 ^
SyntaxError: can't use starred expression here

The latter case should also report "SyntaxError: cannot delete starred".

--
nosy: +gousaiyang

___
Python tracker 

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

[issue42791] There is no way to json encode object to str.

[Artyom Kaltovich]

New submission from Artyom Kaltovich :

Hello.

At first I want to say thank you for all your efforts in python development. I 
really appreciate it. :)

I am trying to convert custom object to json. 

But, I've found a problem. JSONEncoder has ``default`` method for converting 
custom objects to some primitives and ``encode`` for converting structures.

But what if I want to return completed json string? I can't do it in 
``default``, because JSONEncoder will think it is string and encode it 
accordingly later in ``iterencode`` method.

Then I tried redefine encode, but it is called with the 
dict(array_name=default(o)) so I should convert the dict as a whole and 
basically reimplement all conversions (for int, float, and lists of course).

Did I missed something or there is no way to do it?

I suggest to introduce another method, e.g. encode_obj and call it there:

https://github.com/python/cpython/blob/master/Lib/json/encoder.py#L438
```
   o = _default(o)
   yield from _iterencode(o, _current_indent_level)
```
->
```
   o = _encode_obj(_default(o))
   yield from _iterencode(o, _current_indent_level)
```

If you are agree I would be happy to implement it.

Best Regards,
Artsiom.

--
components: Library (Lib)
messages: 384085
nosy: kaltovichartyom
priority: normal
severity: normal
status: open
title: There is no way to json encode object to str.

___
Python tracker 

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

[issue42790] test.regrtest outputs to stdout instead of stderr

[Serhiy Storchaka]

New submission from Serhiy Storchaka :

unittest outputs progress and summary to stderr, but test.regrtest outputs it 
to stdout. Except that it outputs progress to stderr if option -W is used.

It caused some problems with test_curses, because curses uses stdout, and when 
re-attach it to other terminal or file we can lose the regrtest output. It 
makes the code more complicated.

--
components: Tests
messages: 384084
nosy: serhiy.storchaka, vstinner
priority: normal
severity: normal
status: open
title: test.regrtest outputs to stdout instead of stderr
type: behavior

___
Python tracker 

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

[issue42773] build.yml workflow not testing on pushes

[miss-islington]

Change by miss-islington :


--
pull_requests: +22852
pull_request: https://github.com/python/cpython/pull/24010

___
Python tracker 

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

[issue42773] build.yml workflow not testing on pushes

[miss-islington]

Change by miss-islington :


--
pull_requests: +22853
pull_request: https://github.com/python/cpython/pull/24011

___
Python tracker 

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

[issue42789] Do not skip test_curses on non-tty

[Serhiy Storchaka]

Change by Serhiy Storchaka :


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

___
Python tracker 

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

[issue42789] Do not skip test_curses on non-tty

[Serhiy Storchaka]

New submission from Serhiy Storchaka :

Currently many tests in test_curses are skipped if sys.__stdout__ is not 
attached to terminal. All tests are ran only when run them manually, and 
without using pager. This leads to passing bugs, like in issue42694.

The proposed PR makes tests always ran. If __stdout__ is not attached to 
terminal, it tries to attach it to terminal, using __stderr__ if it is attached 
to terminal, or opening /dev/tty. If neither __stdout__ nor __stderr__ are 
attached to terminal, it tries to use temporary file, but some functions do not 
work in this case and will be untested.

It could be better to use os.openpty(), but too many curses outputs can 
overflow the buffer (2 KiB) and cause the test and all subsequent tests to 
fail. Currently all tests are passed if use os.openpty(), but I afraid that 
adding more tests will overflow the buffer and it will confuse future 
developers. My attempts to solve this issue was unsuccessful for that time, so 
I left more complicated and less flexible, but more reliable solution.

--
components: Tests
messages: 384083
nosy: serhiy.storchaka, twouters
priority: normal
severity: normal
status: open
title: Do not skip test_curses on non-tty
type: enhancement
versions: Python 3.10, Python 3.8, Python 3.9

___
Python tracker 

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

[issue42786] Different repr for collections.abc.Callable and typing.Callable

[Svyatoslav]

Svyatoslav  added the comment:

Thanks a lot! I am closing this issue.

--
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed

___
Python tracker 

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

[issue27820] Possible bug in smtplib when initial_response_ok=False

[Pandu E POLUAN]

Pandu E POLUAN  added the comment:

I tried creating a PR, but for the life of me I couldn't wrap my head around 
how testAUTH_LOGIN is being performed (it's in Lib/test/test_smtplib.py)

All I know is, the test doesn't AT ALL test for situations where 
initial_response_ok=False. ALL tests are done with initial_response_ok=True.

There needs to be a whole set of additions to test_smtplib.py

--

___
Python tracker 

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

[issue42786] Different repr for collections.abc.Callable and typing.Callable

[Ken Jin]

Ken Jin  added the comment:

You're welcome, and yes you're right! You can read the news item for it here 
https://docs.python.org/3/whatsnew/3.9.html#notable-changes-in-python-3-9-2. 

The expected release date for Python 3.9.2 is Monday, 2021-02-15 according to 
PEP 596 https://www.python.org/dev/peps/pep-0596/.

--

___
Python tracker 

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

[issue42788] Issue with Python’s Floor Division

[Eric V. Smith]

Eric V. Smith  added the comment:

Oops, my message collided with rhettinger.

--
nosy: +rhettinger

___
Python tracker 

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

[issue42788] Issue with Python’s Floor Division

[Eric V. Smith]

Eric V. Smith  added the comment:

Regular division (/) yields a float, so 1 / 1 is 1.0.

https://docs.python.org/3/reference/expressions.html#binary-arithmetic-operations
 says that for floor division, the arguments are first converted to a common 
type, which here would be float.

So, your examples are basically:

>>> 1 / 1
1.0
>>> 1.0 // 1
1.0

>>> 0 / 1
0.0
>>> 0.0 // 1
0.0

This is working as expected, and is not a bug.

--
nosy: +eric.smith -rhettinger

___
Python tracker 

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

[issue42773] build.yml workflow not testing on pushes

[Ammar Askar]

Ammar Askar  added the comment:

Thank you Filipe and Mariatta, the fix looks good to me. I think it needs a 
backport to the 3.9 branch though.

--

___
Python tracker 

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

[issue42788] Issue with Python’s Floor Division

[Raymond Hettinger]

Raymond Hettinger  added the comment:

The current behavior was specified in PEP 238:

   int / int -> float
   float // int -> float 

See:  https://www.python.org/dev/peps/pep-0238/#semantics-of-floor-division

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

___
Python tracker 

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

[issue42786] Different repr for collections.abc.Callable and typing.Callable

[Svyatoslav]

Svyatoslav  added the comment:

Ok, thanks for the answer. Did I understand correctly that the issue will be 
fixed in 3.9.2 as well?

--

___
Python tracker 

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

[issue42773] build.yml workflow not testing on pushes

[Filipe Laíns]

Filipe Laíns  added the comment:

Ammar, could you confirm the issue is now solved?

--

___
Python tracker 

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

[issue42788] Issue with Python’s Floor Division

[yao_way]

New submission from yao_way :

There might be an issue with Python’s floor division:
Experienced Behavior: >>> (1 / 1) // 1 --> 1.0; >>> (0 / 1) // 1 --> 0.0
Expected Behavior: >>> (1 / 1) // 1 --> 1; >>> (0 / 1) // 1 --> 0

--
components: Interpreter Core
messages: 384073
nosy: yao_way
priority: normal
severity: normal
status: open
title: Issue with Python’s Floor Division
type: behavior
versions: Python 3.8

___
Python tracker 

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

[issue41914] test_pdb fails

[Ross Rhodes]

Ross Rhodes  added the comment:

Hi Sumagna,

test_pdb appears to be working as expected on my machine. I realise this was 
posted a few months ago so would you mind trying again and seeing if the issue 
persists? If so, which OS are you running your tests on?

--
nosy: +trrhodes

___
Python tracker 

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

[issue40522] [subinterpreters] Get the current Python interpreter state from Thread Local Storage (autoTSSkey)

[hai shi]

Change by hai shi :


--
nosy: +shihai1991

___
Python tracker 

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

[issue42787] email.utils.getaddresses improper parsing of unicode realnames

[Ross Rhodes]

Ross Rhodes  added the comment:

Hi Konstantin,

Thanks for raising this issue. It appears the field provided in your example 
does not conform to RFC 2822 followed by this email library. Square brackets 
are treated as special characters in [section 
3.2.1](https://tools.ietf.org/html/rfc2822#section-3.2.1), which is handled in 
the 
[_parseaddr](https://github.com/python/cpython/blob/master/Lib/email/_parseaddr.py#L219)
 file.

The above combined with the fact that any [failed parsing returns an two-tuple 
of ('', 
'')](https://github.com/python/cpython/blob/master/Lib/email/utils.py#L212) I 
believe explains the behavior observed.

--
nosy: +trrhodes

___
Python tracker 

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

[issue40522] [subinterpreters] Get the current Python interpreter state from Thread Local Storage (autoTSSkey)

[Dong-hee Na]

Change by Dong-hee Na :


--
nosy: +corona10

___
Python tracker 

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

[issue42786] Different repr for collections.abc.Callable and typing.Callable

[Ken Jin]

Ken Jin  added the comment:

This was addressed in issue42195 and issue40494 as you pointed out :). It has 
been fixed in Python 3.10. Unfortunately the backport didn't make it in time 
for Python 3.9.1, and will come in Python 3.9.2 instead. Sadly there's not much 
to do about that.

On 3.10:

>>> import collections
>>> repr(collections.abc.Callable[[int], str])
'collections.abc.Callable[[int], str]'

--
nosy: +kj

___
Python tracker 

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

[issue42787] email.utils.getaddresses improper parsing of unicode realnames

[Konstantin Ryabitsev]

New submission from Konstantin Ryabitsev :

What it currently does:

>>> import email.utils
>>> email.utils.getaddresses(['Shuming [范書銘] '])
[('', 'Shuming'), ('', ''), ('', '范書銘'), ('', ''), ('', 'shumi...@realtek.com')]

What it should do:

>>> import email.utils
>>> email.utils.getaddresses(['Shuming [范書銘] '])
[('Shuming [范書銘]'), 'shumi...@realtek.com')]

--
components: email
messages: 384069
nosy: barry, konstantin2, r.david.murray
priority: normal
severity: normal
status: open
title: email.utils.getaddresses improper parsing of unicode realnames
type: enhancement
versions: Python 3.9

___
Python tracker 

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

[issue42786] Different repr for collections.abc.Callable and typing.Callable

[Svyatoslav]

New submission from Svyatoslav :

Was making some typing conversions to string and noticed a different behavior 
of collections.abc.Callable and typing.Callable here in 3.9.1. Issues 
issue42195 and issue40494 can be related.

>>> import collections, typing
>>> repr(collections.abc.Callable[[int], str])
"collections.abc.Callable[[], str]"
>>> repr(typing.Callable[[int], str])
'typing.Callable[[int], str]'

The variant from collections is wrong, it is not consistent with other 
GenericAlias reprs like
>>> repr(tuple[list[float], int, str])
'tuple[list[float], int, str]'

The problem is actually in the list usage to denote callable arguments:
>>> repr(tuple[[float], int, str])
"tuple[[], int, str]"

Here is the same error. This error disallows to use typing in eval/exec 
statements:
>>> c = collections.abc.Callable[[int], str]
>>> d = eval(repr(c))
Traceback (most recent call last):
  File "", line 1, in 
  File "", line 1
collections.abc.Callable[[], str]
  ^
SyntaxError: invalid syntax

Ofc there is no such problem with typing.Callable:
>>> c = typing.Callable[[int], str]
>>> d = eval(repr(c))
>>> 

Interesting, if pass a list into typing.Tuple, an exception is raised:
>>> repr(typing.Tuple[[float], int, str])
Traceback (most recent call last):
  File "", line 1, in 
  File "f:\software\python3.9\lib\typing.py", line 262, in inner
return func(*args, **kwds)
  File "f:\software\python3.9\lib\typing.py", line 896, in __getitem__
params = tuple(_type_check(p, msg) for p in params)
  File "f:\software\python3.9\lib\typing.py", line 896, in 
params = tuple(_type_check(p, msg) for p in params)
  File "f:\software\python3.9\lib\typing.py", line 151, in _type_check
raise TypeError(f"{msg} Got {arg!r:.100}.")
TypeError: Tuple[t0, t1, ...]: each t must be a type. Got [].

I think it is not correct that tuple accepts lists as generics, i. e. for 
tuple[[float], int, str] an exception as above should be raised. Bu this is the 
topic for other issue (maybe even already reported).

--
messages: 384068
nosy: Prometheus3375
priority: normal
severity: normal
status: open
title: Different repr for collections.abc.Callable and typing.Callable
type: behavior
versions: Python 3.9

___
Python tracker 

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

[issue42773] build.yml workflow not testing on pushes

[miss-islington]

miss-islington  added the comment:


New changeset 4ac923f2756f835f512339ee181348cc535ab07f by Filipe Laíns in 
branch 'master':
bpo-42773: fix tests not being run on pushes (GH-24004)
https://github.com/python/cpython/commit/4ac923f2756f835f512339ee181348cc535ab07f


--
nosy: +miss-islington

___
Python tracker 

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

[issue24464] "sqlite3_enable_shared_cache" deprecation warning when compiling with macOS system SQLite3

[Erlend Egeberg Aasland]

Change by Erlend Egeberg Aasland :


--
pull_requests: +22850
pull_request: https://github.com/python/cpython/pull/24008

___
Python tracker 

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

[issue29708] support reproducible Python builds

[STINNER Victor]

STINNER Victor  added the comment:

> tiny bytecode differences

bpo-37596 "Reproducible pyc: frozenset is not serialized in a deterministic 
order" is not fixed yet.

--

___
Python tracker 

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

[issue29708] support reproducible Python builds

[Frederik Rietdijk]

Frederik Rietdijk  added the comment:

Building Python packages reproducibly has now basically been resolved with the 
reproducible bytecode as well as changes in tools such as pip.

Unfortunately, the interpreters do not yet seem to be reproducible. After 
certain changes, a Nixpkgs build of 3.9 shows several tiny bytecode 
differences. What could have caused these differences? Please see the attached 
diffoscope report. 

As part of installation all bytecode is force regenerated using compileall. 
This is using the default checked-hash.

--
nosy: +Frederik Rietdijk
versions: +Python 3.9 -Python 3.7
Added file: https://bugs.python.org/file49708/python39_2.html

___
Python tracker 

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

[issue27640] add the '--disable-test-suite' option to configure

[STINNER Victor]

STINNER Victor  added the comment:

Thanks all, it's now fixed in the master branch, the future Python 3.10.

Thanks Xavier de Gaye for the initial patch and reported the issue.

Thanks Peixing Xin for the final change which is now even better! 

Thanks also Thomas Petazzoni who maintained the downstream patch in buildroot.

See also discussion on PR 23886 about the technical change and the different 
tests that we run to ensure that the change doesn't break anything, and that it 
works as expected.

I'm really not comfortable at all to change the Python build system. It's very 
complex and fragile, I don't know it very well, so I'm not confident in what I 
am doing. For these reasons, I'm strongly against backporting the change to 
stable branches (3.8 and 3.9) and so I close the issue

--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.10 -Python 3.6

___
Python tracker 

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

[issue27640] Add --disable-test-modules configure option to not build nor install tests

[STINNER Victor]

Change by STINNER Victor :


--
title: add the '--disable-test-suite' option to configure -> Add 
--disable-test-modules configure option to not build nor install tests

___
Python tracker 

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

[issue27640] add the '--disable-test-suite' option to configure

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 277ce3060becc120f1c877346562bd6880f4be71 by pxinwr in branch 
'master':
bpo-27640: Add --disable-test-modules configure option (GH-23886)
https://github.com/python/cpython/commit/277ce3060becc120f1c877346562bd6880f4be71


--

___
Python tracker 

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

[issue42760] inspect.iscoroutine returns False for asynchronous generator methods

[Paolo Lammens]

Change by Paolo Lammens :


--
title: inspect.iscoroutine returns False for asynchronous generator functions 
-> inspect.iscoroutine returns False for asynchronous generator methods

___
Python tracker 

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

[issue42760] inspect.iscoroutine returns False for asynchronous generator functions

[Paolo Lammens]

Change by Paolo Lammens :


--
versions: +Python 3.9

___
Python tracker 

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

[issue42785] Support operator module callables in inspect.signature

[Paolo Lammens]

Paolo Lammens  added the comment:

Correction:

```
ValueError: callable operator.attrgetter('spam') is not supported by signature
```

--

___
Python tracker 

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

[issue42785] Support operator module callables in inspect.signature

[Paolo Lammens]

New submission from Paolo Lammens :

Currently, `inspect.signature` doesn't support all callables from the 
`operator` module, e.g. `operator.attrgetter`:

```python
>>> import inspect
>>> import operator
>>> inspect.signature(operator.attrgetter("spam"))
ValueError: callable operator.attrgetter('is_host') is not supported by 
signature
```

Support for this could be added either directly to `inspect.signature` or by 
adding `__signature__` attributes to `operator`'s classes.

--
components: Library (Lib)
messages: 384061
nosy: plammens
priority: normal
severity: normal
status: open
title: Support operator module callables in inspect.signature
type: enhancement
versions: Python 3.9

___
Python tracker 

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

[issue40633] json.dumps() should encode float number NaN to null

[Mark Dickinson]

Mark Dickinson  added the comment:

> RFC 8259 (current RFC for JSON): https://tools.ietf.org/html/rfc7159

Argh; copy-and-paste fail. That link should have been 
https://tools.ietf.org/html/rfc8259, of course.

--

___
Python tracker 

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

[issue40633] json.dumps() should encode float number NaN to null

[Mark Dickinson]

Mark Dickinson  added the comment:

For the record, some helpful resources:

ECMA-404 (the ECMA standardization of JSON): 
http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf

RFC 8259 (current RFC for JSON): https://tools.ietf.org/html/rfc7159. (I 
mistakenly referred to RFC 7159 in a previous comment, but that's obsoleted by 
RFC 8259; however, none of the language around infinities and nans has changed, 
and none of the current errata to RFC 8259 have any impact on infinity or nan 
encoding.)

This Stack Overflow question and its answers contain some interesting 
discussion and links: 
https://stackoverflow.com/questions/1423081/json-left-out-infinity-and-nan-json-status-in-ecmascript
 

Essentially, there's no good answer here: standard JSON simply can't encode 
infinities and NaNs. Absent a fix for the standard itself, both Python and 
ECMAScript end up papering over that fact. Unfortunately from an 
interoperability point of view, they do so in different ways - Python 
effectively extends the JSON spec in such a way that it produces invalid JSON 
by default; ECMAScript converts all of Infinity, -Infinity, NaN and null to the 
exact same JSON string, producing valid JSON but losing the ability to restore 
the original values from their JSON representations.

FWIW, Python's solution to this problem is (whether by accident or design I'm 
not sure) forward-looking in the sense that it's compatible with JSON 5: 
https://spec.json5.org

--

___
Python tracker 

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

[issue30459] PyList_SET_ITEM could be safer

[Christian Tismer]

Christian Tismer  added the comment:

Congrats to that change!

--
nosy: +Christian.Tismer

___
Python tracker 

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

[issue40522] [subinterpreters] Get the current Python interpreter state from Thread Local Storage (autoTSSkey)

[STINNER Victor]

STINNER Victor  added the comment:

One GIL per interpreter requires to store the tstate per thread. I don't see 
any other option. We need to replace the global _PyRuntime atomic variable with 
a TLS variable. I'm trying to reduce the overhead, but it's heard to beat the 
performance of an atomic variable.

That's also we I modified many functions to pass explicitly tstate to 
subfunctions in internal C functions, to avoid any possible overhead of getting 
tstate.

https://vstinner.github.io/cpython-pass-tstate.html


Pablo:
> In MacOS is quite challenging to activate LTO, so normally optimized builds 
> are only done with PGO.

Oh right, I forgot macOS. I should check how TLS is compiled on macOS. IMO wwo 
MOV instead of MOV is not a major performance bottleneck.

The best would be to be able to avoid pthread_getspecific() function which is 
less efficient than a TLS variable. The glibc implementation uses an array for 
a few variables (first 32 variables?) and then a slower hash table.


Pablo:
> Also in Windows I am not sure is possible to use LTO. Same for many other 
> platforms.

I will check how it's implemented on Windows.

We cannot use TLS on all platforms, since it requires C11 features which are 
not available on all platforms. Also, the implementation depends on the 
architecture.

--

___
Python tracker 

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

[issue40137] TODO list when PEP 573 "Module State Access from C Extension Methods" will be implemented

[STINNER Victor]

STINNER Victor  added the comment:

> _abc: abc_invalidation_counter is shared by all module instances.

For the record, this one has been fixed by:

commit 77c614624b6bf2145bef69830d0f499d8b55ec0c
Author: Dong-hee Na 
Date:   Sat May 9 17:31:40 2020 +0900

bpo-40566: Apply PEP 573 to abc module (GH-20005)

--

___
Python tracker 

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

[issue40633] json.dumps() should encode float number NaN to null

[Mark Dickinson]

Mark Dickinson  added the comment:

@Luca: you might want to open a new feature request issue; it's not clear to me 
what exact behaviour change you're proposing for Python.

What was rejected in this issue was the proposal to *automatically* convert 
NaNs and infinities to nulls by default, but that still leaves open the 
possibility of adding an option to do such conversion, provided that a 
sufficiently strong case could be made for adding such an option, and that we 
can figure out what we want the behaviour should be (should _all_ things that 
JSON doesn't know how to encode be converted to null, or just infinities and 
nans?)

If you want standards compliance, then that's already there: you can use the 
existing flag allow_nan=False when generating JSON. I agree that it would have 
been better if that were the default, but changing it now is probably a no-go - 
it would break too much existing code.

I'm still confused by Arjan Staring's comments: they seem to be saying that the 
JSON specification states that a NaN should be converted to the string "null", 
but there's nothing in RFC 7159 to support that - as you point out, it 
explicitly says that NaNs and infinities are disallowed.

--

___
Python tracker 

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

[issue40956] Use Argument Clinic in sqlite3

[Erlend Egeberg Aasland]

Change by Erlend Egeberg Aasland :


--
pull_requests: +22849
pull_request: https://github.com/python/cpython/pull/24007

___
Python tracker 

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

[issue27794] setattr a read-only property; the AttributeError should show the attribute that failed

[Raymond Hettinger]

Raymond Hettinger  added the comment:

Thanks for the PR :-)

--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.10 -Python 3.7

___
Python tracker 

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

[issue27794] setattr a read-only property; the AttributeError should show the attribute that failed

[Raymond Hettinger]

Raymond Hettinger  added the comment:


New changeset c56387f80c5aabf8100ceaffe365cc004ce0d7e0 by Yurii Karabas in 
branch 'master':
bpo-27794: Add `name` attribute to `property` class (GH-23967)
https://github.com/python/cpython/commit/c56387f80c5aabf8100ceaffe365cc004ce0d7e0


--

___
Python tracker 

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

[issue42764] HTMLParser close() issue

[Anthony Hodson]

Anthony Hodson  added the comment:

Resolved by correct initiation of subclass

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

___
Python tracker 

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

[issue42747] Remove Py_TPFLAGS_HAVE_VERSION_TAG flag?

[Petr Viktorin]

Petr Viktorin  added the comment:

> I'm only aware of PyQt which uses the stable ABI. Is there other projects 
> using it? Do these projects check for Py_TPFLAGS_HAVE_VERSION_TAG or 
> Py_TPFLAGS_HAVE_FINALIZE flag?

I think there are. Who knows how many; they're not required to register 
anywhere.


If the flags do end up being removed, it would be nice to reserve the bits (in 
a comment), so they aren't reused too soon.

Also, ISTM that PEP 387 applies, and requires warning for two releases. How can 
that be done for flags?

--

___
Python tracker 

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