[issue45348] math.log(243, 3) value issue

[Tim Peters]

Tim Peters  added the comment:

CPython's log() builds on the platform C's libm facilities, and C simply 
doesn't define primitives capable of producing a worst-case < 1 ulp error 
2-argument log in reasonable time. Instead we have to build it out of two 
separate log operations, and a division. Each of those 3 operations can suffer 
its own rounding errors, which may, overall, cancel out, or build on each 
other. There's no error bound we can guarantee, although "< 2 ulp worst-case 
error" seems likely under modern libms.

Which is actually quite good. Doing better than that is out of scope for 
CPython's implementation. The easy way to get < 1 ulp is to use decimal to 
compute the intermediate results with excess precision. But that's also "too 
slow" for general use.

What Dennis did in his little test driver was fine for that, but we don't 
actually need to increase decimal's default precision at all to get < 1 ulp 
error in a converted-back-to-float-via-round-nearest result here.

Just an example (doesn't "prove" anything - but points at how to go about 
proving things):

>>> decimal.Decimal(3**8).ln() / decimal.Decimal(3).ln()
Decimal('7.999')
>>> float(_)
8.0

--
nosy: +tim.peters
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

[issue45350] configure incorrectly ignores pkg-config information for libffi and Tcl/Tk in 3.10

[Ned Deily]

New submission from Ned Deily :

./configure supports using the system or third-party-supplied pkg-config 
utility to find or override the default location of header and library files 
when building a few C extensions in the standard library, namely from OpenSSL 
for the _ssl module, libffi for ctypes, and, new in 3.10, Tcl/Tk for _tkinter 
(bpo-42603). However, currently for 3.10.0, pkg-config usage is broken for 
libffi and Tcl/Tk (but not OpenSSL). When running ./configure, there is an 
unexpected warning that is easily overlooked:

[...]
checking for --with-libs... no
./configure: line 10545: PKG_PROG_PKG_CONFIG: command not found
checking for --with-system-expat... no
[...]

PKG_PROG_PKG_CONFIG is a macro provided by GNU Autotools that is supposed to be 
in aclocal.m4. Unfortunately, it appears to have been inadvertently deleted in 
2fc857a5721a5b42bcb696c9cae1bbcc82a91b17 (PR 25860) probably due to an autoconf 
version mismatch. The net effect is that the configure variable PKG_CONFIG, the 
location of the pkg-config utility, is undefined so tests in configure for the 
location of libffi and of Tcl and Tk do not take into account any pkg-config 
info and use any default locations (i.e. /usr/include). For most builds, that 
likely still produces the desired results. But it won't if a builder is trying 
to override these locations or is building on a platform with different default 
or is using a third-party package manager and pkg-config to supply libraries.  
Note, the _ssl module builds are not affected by this problem as the 
AX_CHECK_OPENSSL macro in aclocal.m4 does not depend on PKG_PROG_PKG_CONFIG to 
find pkg-config.

It appears that the problem can be worked around by explicitly setting the 
PKG_CONFIG build variable when invoking configure, something like:

  ./configure [...] PKG_CONFIG=$(which pkg-config)

But the PR 25860 changes to aclocal.a4 should be carefully reviewed and the 
pkg-config related deletes restored; there might be other problems, too. This 
is not the first time we've been caught up by unexpected autoconf changes and, 
as is clear here, it is too easy for them to go unnoticied. Perhaps we should 
try to figure out how to reduce those risks.

--
assignee: pablogsal
components: Build
messages: 403076
nosy: ned.deily, pablogsal
priority: high
severity: normal
stage: needs patch
status: open
title: configure incorrectly ignores pkg-config information for libffi and 
Tcl/Tk in 3.10
versions: Python 3.10, Python 3.11

___
Python tracker 

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

[issue45302] 10 built-in functions need non-None .__text_signature__

[Éric Araujo]

Change by Éric Araujo :


--
nosy: +eric.araujo

___
Python tracker 

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

[issue36521] Consider removing docstrings from co_consts in code objects

[Inada Naoki]

Inada Naoki  added the comment:

> So overhead is around 2%. And this 2% is problem only for "creating function 
> with annotation, without docstring, never called, in loop" situation.

My bad, "creating function with docstring, without annotation, nevercalled in 
loop" situation.

--

___
Python tracker 

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

[issue36521] Consider removing docstrings from co_consts in code objects

[Inada Naoki]

Inada Naoki  added the comment:

And as a bonus, creating function without docstring is little faster.

```
$ cpython/release/bin/pyperf timeit --duplicate=100 "def f(): pass"
.
Mean +- std dev: 62.5 ns +- 1.2 ns

$ load-none-remove-docstring/release/bin/pyperf timeit --duplicate=100 "def 
f(): pass"
.
Mean +- std dev: 60.5 ns +- 1.3 ns
```

--

___
Python tracker 

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

[issue36521] Consider removing docstrings from co_consts in code objects

[Inada Naoki]

Inada Naoki  added the comment:

> The difference 5.1 ns is the cost of additional LOAD_CONST. It is around 8% 
> (but can be 12% or 2%). The cost of setting docstring externally will be the 
> same.


I don't have bare metal machine for now so I don't know why annotation is so 
slow. But cost of setting docstring is lighter.

```
# main branch
$ cpython/release/bin/pyperf timeit --duplicate=100 "def f():
>   'docstring'"
.
Mean +- std dev: 61.5 ns +- 1.3 ns

# https://github.com/methane/cpython/pull/37
$ load-none-remove-docstring/release/bin/pyperf timeit --duplicate=100 "def f():
>   'docstring'"
.
Mean +- std dev: 62.9 ns +- 1.5 ns

$ load-none-remove-docstring/release/bin/pyperf timeit --duplicate=100 "def 
f(x: 'int', y: 'str') -> 'float': pass"
.
Mean +- std dev: 65.1 ns +- 4.3 ns

$ load-none-remove-docstring/release/bin/pyperf timeit --duplicate=100 "def 
f(x: 'int', y: 'str') -> 'float': 'docstring'"
.
Mean +- std dev: 66.3 ns +- 2.6 ns

$ load-none-remove-docstring/release/bin/pyperf timeit --duplicate=100 "def 
f(x: 'int', y: 'str') -> 'float': 'docstring'
> f(None,None)"
.
Mean +- std dev: 131 ns +- 6 ns
```

So overhead is around 2%. And this 2% is problem only for "creating function 
with annotation, without docstring, never called, in loop" situation.
In regular situation, this overhead will be negligible.

--

___
Python tracker 

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

[issue45349] configparser.ConfigParser: 2 newlines at end of file (EOF)

[Martin Panter]

Martin Panter  added the comment:

Looks like the same as Issue 32917. I presume there are two newlines at the end 
of the file because there are two newlines following every config section.

IMO this is a minor cosmetic annoyance, just like writing a key with an empty 
value gets you a trailing space after the equals sign at the end of the line. 
Not worth changing as a bug fix, and not worth a special option, but maybe okay 
to change if the code is simple and it doesn't harm compatibility.

--
nosy: +martin.panter
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> ConfigParser writes a superfluous final blank line

___
Python tracker 

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

[issue45348] math.log(243, 3) value issue

[Dennis Sweeney]

Change by Dennis Sweeney :


--
nosy: +mark.dickinson, rhettinger

___
Python tracker 

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

[issue45349] configparser.ConfigParser: 2 newlines at end of file (EOF)

[Eric V. Smith]

Eric V. Smith  added the comment:

Please provide code that we can run that shows the problem.

--
nosy: +eric.smith

___
Python tracker 

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

[issue45348] math.log(243, 3) value issue

[Dennis Sweeney]

Dennis Sweeney  added the comment:

It turns out that the current implementation is already very good, within 1ulp 
in 99.85% of cases and perfect (as good as floats can get) in 65% of cases. So 
my thinking would be to leave the implementation as is.

#

from decimal import Decimal as D, getcontext
from math import log, nextafter
from random import uniform

getcontext().prec = 200

N = 10_000
perfect = 0
good = 0

for i in range(N):
x, base = uniform(1, 10**6), uniform(2, 100)
d_result = float(D(x).ln() / D(base).ln())
f_result = log(x, base)

if d_result == f_result:
perfect += 1
good += 1
elif nextafter(d_result, f_result) == f_result:
good += 1

print(f"{perfect/N = }")
print(f"{good/N = }")

# results:
# perfect/N = 0.6503
# good/N = 0.9985

--

___
Python tracker 

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

[issue45349] configparser.ConfigParser: 2 newlines at end of file (EOF)

[Boštjan Mejak]

New submission from Boštjan Mejak :

In every Python version that I've tested, writing a config.ini file (utilizing 
configparser.ConfigParser), the result is such that the config.ini file has 2 
newlines at the end of the file.

The problem is that source code editors like Sublime Text, or IDEs like 
PyCharm, already insert a newline at the end of a file, but then 
configparser.ConfigParser 
(or maybe the Python's write() function?)  insert its own as well.

Is it possible to fix this behavior?

--
components: Library (Lib)
messages: 403069
nosy: PythonEnthusiast
priority: normal
severity: normal
status: open
title: configparser.ConfigParser: 2 newlines at end of file (EOF)
type: behavior
versions: Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python 
3.9

___
Python tracker 

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

[issue43329] Multiprocessing Manager Client Not Reconnecting

[Michael L. Boom]

Michael L. Boom  added the comment:

Is there anything that I can do, or the company I work for can do, to get a 
developer assigned to fix this bug?  It is hard to use multiprocessing remote 
method calls without this bug being fixed.  The software wouldn't be robust 
enough for production.

--

___
Python tracker 

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

[issue45348] math.log(243, 3) value issue

[Dennis Sweeney]

Dennis Sweeney  added the comment:

According to https://docs.python.org/3/library/math.html#math.log :

"""With two arguments, return the logarithm of x to the given base, calculated 
as log(x)/log(base)."""

Indeed, this is consistent with that:

>>> from math import log
>>> log(243)
5.493061443340548
>>> log(3)
1.0986122886681098
>>> 5.493061443340548/1.0986122886681098
4.999

math.log is a floating-point operation, not an integer operation, and this is 
the nature of floating point operations: there can be rounding errors whenever 
there are intermediate steps of the computation. Strictly speaking, I would say 
this is not a bug, and results of floating point operations should generally be 
compared with math.isclose(), not with ==. Just like you can't expect (1/49)*49 
== 1.0.

On the other hand, it may be theoretically possible to do some clever floating 
point tricks to get more accurate results out of math.log(a, b), like maybe 
some kind of correction factor involving the platform libm pow() function. I 
don't know if those are typically any more reliable than the status quo 
quotient-of-logs.

--
nosy: +Dennis Sweeney

___
Python tracker 

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

[issue45348] math.log(243, 3) value issue

[Eddie Caraballo]

Eddie Caraballo  added the comment:

Issue seems to be with all power of 3 divisible by 5 (3**5, 3**10, etc).

Powers of 7 also seem to have the issue, where math.log(7**5, 7) = 5.01

--

___
Python tracker 

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

[issue45348] math.log(243, 3) value issue

[Eddie Caraballo]

New submission from Eddie Caraballo :

math.log(243, 3) should result in 5.0, but instead results in 4....

Can be worked around via base conversion (math.log10(243) / math.log10(3))

--
components: Library (Lib)
messages: 403065
nosy: eddiemichaelc
priority: normal
severity: normal
status: open
title: math.log(243, 3) value issue
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

[issue45335] Default TIMESTAMP converter in sqlite3 ignores time zone

[Ian Fisher]

Ian Fisher  added the comment:

Substitute "UTC offset" for "time zone" in my comment above.

I have attached a minimal Python program demonstrating data loss from this bug.

--
Added file: https://bugs.python.org/file50324/timestamp.py

___
Python tracker 

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

[issue44831] Inconsistency between datetime.now() and datetime.fromtimestamp(time.time(), None)

[Raymond Hettinger]

Raymond Hettinger  added the comment:

Related:  https://bugs.python.org/issue45347

--

___
Python tracker 

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

[issue45347] datetime subject to rounding?

[Raymond Hettinger]

Raymond Hettinger  added the comment:

Related:  https://bugs.python.org/issue44831

--
nosy: +rhettinger

___
Python tracker 

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

[issue45346] Some "truthy" crept in

[Raymond Hettinger]

Change by Raymond Hettinger :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

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

[issue45346] Some "truthy" crept in

[Raymond Hettinger]

Raymond Hettinger  added the comment:


New changeset 72089f33c0aed391f047b1cbaf19d8da1e51c167 by Miss Islington (bot) 
in branch '3.10':
bpo-45346: Keep docs consistent regarding true and false values (GH-28697) 
(GH-28698)
https://github.com/python/cpython/commit/72089f33c0aed391f047b1cbaf19d8da1e51c167


--

___
Python tracker 

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

[issue45346] Some "truthy" crept in

[Raymond Hettinger]

Raymond Hettinger  added the comment:


New changeset db91b058d5d4fbff4185982095d90fe6a2741aed by Raymond Hettinger in 
branch 'main':
bpo-45346: Keep docs consistent regarding true and false values (GH-28697)
https://github.com/python/cpython/commit/db91b058d5d4fbff4185982095d90fe6a2741aed


--

___
Python tracker 

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

[issue45346] Some "truthy" crept in

[miss-islington]

Change by miss-islington :


--
nosy: +miss-islington
nosy_count: 3.0 -> 4.0
pull_requests: +27057
pull_request: https://github.com/python/cpython/pull/28698

___
Python tracker 

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

[issue45346] Some "truthy" crept in

[Raymond Hettinger]

Change by Raymond Hettinger :


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

___
Python tracker 

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

[issue45346] Some "truthy" crept in

[Raymond Hettinger]

Change by Raymond Hettinger :


--
assignee: docs@python -> rhettinger
nosy: +rhettinger
type: enhancement -> 

___
Python tracker 

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

[issue45346] Some "truthy" crept in

[Stefan Pochmann]

Change by Stefan Pochmann :


--
type:  -> enhancement

___
Python tracker 

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

[issue45347] datetime subject to rounding?

[Daniele Varrazzo]

New submission from Daniele Varrazzo :

I found two datetimes at difference timezone whose difference is 0 but which 
don't compare equal.

Python 3.9.5 (default, May 12 2021, 15:26:36) 
[GCC 8.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import datetime as dt
>>> from zoneinfo import ZoneInfo
>>> for i in range(3):
... ref = dt.datetime(5327 + i, 10, 31, tzinfo=dt.timezone.utc)
... print(ref.astimezone(ZoneInfo(key='Europe/Rome')) == 
ref.astimezone(dt.timezone(dt.timedelta(seconds=3600
... 
True
False
True
>>> for i in range(3):
... ref = dt.datetime(5327 + i, 10, 31, tzinfo=dt.timezone.utc)
... print(ref.astimezone(ZoneInfo(key='Europe/Rome')) - 
ref.astimezone(dt.timezone(dt.timedelta(seconds=3600
... 
0:00:00
0:00:00
0:00:00

Is this a float rounding problem? If so I think it should be documented that 
datetimes bewhave like floats instead of like Decimal, although they have 
finite precision.

--
components: Library (Lib)
messages: 403059
nosy: piro
priority: normal
severity: normal
status: open
title: datetime subject to rounding?
versions: Python 3.8, Python 3.9

___
Python tracker 

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

[issue18712] Pure Python operator.index doesn't match the C version.

[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

[issue36521] Consider removing docstrings from co_consts in code objects

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

> I'm confused by your phrase "take data" -- do you mean remove these? Or wht 
> do you propose we do with them?

I thought that function's name and qualname are set in the code that creates a 
function instead of copying from the code object. Similarly as what Inada-san 
propose for docstring. Perhaps it was in the past. Also, the documentation 
tells that annotations is a tuple of strings, so it should be known at the 
compile time. I propose to make it an attribute of the code object and copy to 
the function object when create a function. It saves a LOAD_CONST.

> Smaller, maybe. Measurably faster? Can you demonstrate that with a patch?

$ ./python -m pyperf timeit --duplicate=100  "def f(x: 'int', y: 'str') -> 
'float': pass"
Mean +- std dev: 64.6 ns +- 4.2 ns
$ ./python -m pyperf timeit --duplicate=100  "def f(x, y): pass"
Mean +- std dev: 59.5 ns +- 2.4 ns

The difference 5.1 ns is the cost of additional LOAD_CONST. It is around 8% 
(but can be 12% or 2%). The cost of setting docstring externally will be the 
same.

> Oh, what do you mean exactly by "local functions" -- is that any function, or 
> only a function nested inside another function?

Global functions and methods of global classes created at import time and only 
once. But functions nested inside another function are created every time when 
the external function is created, and they can even be created in a loop. It is 
a tiny cost, by why make it larger?

--

___
Python tracker 

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

[issue45321] Module xml.parsers.expat.errors misses error code constants of libexpat >=2.0

[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

[issue36521] Consider removing docstrings from co_consts in code objects

[Guido van Rossum]

Guido van Rossum  added the comment:

Serhiy:
> I propose an opposite change -- take data known at compile time (name, 
> qualname and annotations).

I'm confused by your phrase "take data" -- do you mean remove these? Or wht do 
you propose we do with them?

> It will make the code for creating new function smaller and faster.

Smaller, maybe. Measurably faster? Can you demonstrate that with a patch?

> It is what we want to achieve -- reducing import time, but additionally it 
> will reduce time of creating local functions.

I don't think the creation time of local functions is burdensome. (Creating a 
class is much more so.)

Oh, what do you mean exactly by "local functions" -- is that any function, or 
only a function nested inside another function?

--

___
Python tracker 

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

[issue45340] Lazily create dictionaries for plain Python objects

[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

[issue45346] Some "truthy" crept in

[Stefan Pochmann]

New submission from Stefan Pochmann :

Python consistently says true/false, not truthy/falsy. But a few "truthy" have 
crept in now:

https://github.com/python/cpython/search?q=truthy
- Two in Doc/reference/compound_stmts.rst
- One in Doc/library/ast.rst
- One in Lib/test/test_builtin.py

Evidence for consistent true/false usage, if needed:
https://docs.python.org/3/library/stdtypes.html#truth-value-testing
https://docs.python.org/3/library/stdtypes.html#boolean-operations-and-or-not
https://docs.python.org/3/reference/compound_stmts.html#the-if-statement
https://docs.python.org/3/reference/compound_stmts.html#the-while-statement
https://docs.python.org/3/reference/expressions.html#boolean-operations

--
assignee: docs@python
components: Documentation
messages: 403056
nosy: Stefan Pochmann, docs@python
priority: normal
severity: normal
status: open
title: Some "truthy" crept in
versions: Python 3.10, Python 3.11

___
Python tracker 

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

[issue45341] Update "Python Package Index" in Docs

[Terry J. Reedy]

Change by Terry J. Reedy :


--
resolution:  -> fixed

___
Python tracker 

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

[issue45341] Update "Python Package Index" in Docs

[Terry J. Reedy]

Terry J. Reedy  added the comment:


New changeset d211e87307bb2a0b80e0a489501e892e61d879fc by Miss Islington (bot) 
in branch '3.9':
bpo-45341: Replace 'Packaging' with 'Package' in "Python P... Index" (GH-28687) 
(GH-28689)
https://github.com/python/cpython/commit/d211e87307bb2a0b80e0a489501e892e61d879fc


--

___
Python tracker 

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

[issue45339] concurrent.future.ThreadPoolExecutor should parameterize class used for threads

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
components:  -asyncio
nosy: +bquinlan, pitrou

___
Python tracker 

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

[issue45339] concurrent.future.ThreadPoolExecutor should parameterize class used for threads

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Can you apply some custom logic by specifying the initializer?

--
components: +asyncio
nosy: +asvetlov, serhiy.storchaka, yselivanov
type:  -> enhancement

___
Python tracker 

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

[issue45345] Equalized lists depend to each other after equalizing

[Eric V. Smith]

Eric V. Smith  added the comment:

This isn't a bug. In python, the assignment doesn't make a copy, it makes ts 
and s refer to the same object. So there's really only one list to change, and 
you can refer to it by either name, ts or s.

--
nosy: +eric.smith
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

[issue45345] Equalized lists depend to each other after equalizing

[Code7737]

Change by Code7737 :


Added file: https://bugs.python.org/file50323/Test.py

___
Python tracker 

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

[issue45345] Equalized lists depend to each other after equalizing

[Code7737]

Change by Code7737 :


Added file: https://bugs.python.org/file50322/Test.py

___
Python tracker 

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

[issue45345] Equalized lists depend to each other after equalizing

[Code7737]

New submission from Code7737 :

When you make two lists same by using "=" and then change one of them, other 
changes too

--
files: Test.py
messages: 403052
nosy: Code7737
priority: normal
severity: normal
status: open
title: Equalized lists depend to each other after equalizing
type: behavior
versions: Python 3.8
Added file: https://bugs.python.org/file50321/Test.py

___
Python tracker 

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

[issue45329] pyexpat: segmentation fault when `--with-system-expat` is specified

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

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

[issue45329] pyexpat: segmentation fault when `--with-system-expat` is specified

[miss-islington]

miss-islington  added the comment:


New changeset 22cf6a2f2347b7d4f11e45e557beace55acc79b5 by Miss Islington (bot) 
in branch '3.10':
bpo-45329: Fix freed memory access in pyexpat.c (GH-28649)
https://github.com/python/cpython/commit/22cf6a2f2347b7d4f11e45e557beace55acc79b5


--

___
Python tracker 

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

[issue45329] pyexpat: segmentation fault when `--with-system-expat` is specified

[miss-islington]

Change by miss-islington :


--
pull_requests: +27055
pull_request: https://github.com/python/cpython/pull/28693

___
Python tracker 

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

[issue45329] pyexpat: segmentation fault when `--with-system-expat` is specified

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:


New changeset 0742abdc48886b74ed3b66985a54bb1c32802670 by TAGAMI Yukihiro in 
branch 'main':
bpo-45329: Fix freed memory access in pyexpat.c (GH-28649)
https://github.com/python/cpython/commit/0742abdc48886b74ed3b66985a54bb1c32802670


--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue45329] pyexpat: segmentation fault when `--with-system-expat` is specified

[miss-islington]

Change by miss-islington :


--
nosy: +miss-islington
nosy_count: 3.0 -> 4.0
pull_requests: +27054
pull_request: https://github.com/python/cpython/pull/28692

___
Python tracker 

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

[issue36521] Consider removing docstrings from co_consts in code objects

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

I propose an opposite change -- take data known at compile time (name, qualname 
and annotations). It will make the code for creating new function smaller and 
faster. It is what we want to achieve -- reducing import time, but additionally 
it will reduce time of creating local functions.

Arguments for saving few bytes do not look convincing to me. It is why we use 
caches -- memory is cheaper than the CPU time. And in most cases there is no 
any saving.

--

___
Python tracker 

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

[issue45341] Update "Python Package Index" in Docs

[Steven Hsu]

Steven Hsu  added the comment:

Thanks for the efficient help!

--
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

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

[issue36521] Consider removing docstrings from co_consts in code objects

[Irit Katriel]

Irit Katriel  added the comment:

> This not saves only memory usage, but also import time too.

Do you see a measurable impact on import time?

With LOAD_NONE I saw speedup of 8% on micro benchmarks but it didn’t make any 
difference overall.

--

___
Python tracker 

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

[issue36521] Consider removing docstrings from co_consts in code objects

[Inada Naoki]

Inada Naoki  added the comment:

> For the sqlalchemy example: the saving in co_consts is about 1.6k (200 
> pointers), but an increase in bytecode size of 2.4k.

Please see number of co_constatns tuples. (d) saved 1307 tuples compared to (b).
`sys.getsizeof(())` is 40 on 64bit machine. So 1307 tuples is 50k bytes. This 
not saves only memory usage, but also import time too.

Although bytecode size is increased, they are released soon right after 
importing module because `LOAD_CONST` is in module or class code.

So there is a significant gain overall.

> It’s not clear that LOAD_NONE/LOAD_COMMON_CONST are worth doing. Any way the 
> docstring question is not necessarily related to that.

I combined with LOAD_NONE because this issue and LOAD_NONE/LOAD_COMMON_CONST 
has synergy.

But I don't combine it in next time.

--

___
Python tracker 

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

[issue45341] Update "Python Package Index" in Docs

[miss-islington]

miss-islington  added the comment:


New changeset e040adc806aba32c53f4c3d35899d0e5691cab95 by Miss Islington (bot) 
in branch '3.10':
bpo-45341: Replace 'Packaging' with 'Package' in "Python P... Index" (GH-28687)
https://github.com/python/cpython/commit/e040adc806aba32c53f4c3d35899d0e5691cab95


--

___
Python tracker 

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

[issue45341] Update "Python Package Index" in Docs

[miss-islington]

Change by miss-islington :


--
nosy: +miss-islington
nosy_count: 3.0 -> 4.0
pull_requests: +27052
pull_request: https://github.com/python/cpython/pull/28688

___
Python tracker 

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

[issue45341] Update "Python Package Index" in Docs

[miss-islington]

Change by miss-islington :


--
pull_requests: +27053
pull_request: https://github.com/python/cpython/pull/28689

___
Python tracker 

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

[issue45341] Update "Python Package Index" in Docs

[Terry J. Reedy]

Terry J. Reedy  added the comment:


New changeset 0be338199fd663f020d833a4db185d0c5a0e0078 by Terry Jan Reedy in 
branch 'main':
bpo-45341: Replace 'Packaging' with 'Package' in "Python P... Index" (#28687)
https://github.com/python/cpython/commit/0be338199fd663f020d833a4db185d0c5a0e0078


--

___
Python tracker 

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