[issue39298] add BLAKE3 to hashlib

[Larry Hastings]

Larry Hastings  added the comment:

Jack O'Connor:
> Was any of the experimental C extension code [...] useful to you?
> I was wondering if it could be possible to copy blake3module.c from
> there verbatim.

I concede I didn't even look at it.  The glue code to mate the library with the 
CPython runtime wasn't the hard part.  And, Python has its own way of working 
(Argument Clinic etc).  I did what seemed easiest, which
was to start with CPython's BLAKE2 support and hack it up.  Given that
I had it working in maybe half a day, this seems reasonable.

I should take a peek at your experimental build though, just to confirm
I got the interfaces right.


> The setup.py build there also has working Windows and NEON support.

The CPython build process doesn't use setup.py to build extensions on
Windows.  I haven't looked recently, but back in the day they were
built like any other DLL, using its own "project file".  This will
require someone to use the MSVS GUI to create a new project, add files,
etc etc.  I assume they can just use the .asm files for the SIMD
extensions so hopefully this will be straightforward.

As for NEON support, the technique I used theoretically should Just Work.
I look forward to hearing back from someone building on ARM.  (I have
a cross-compiler setup for building for MiSTer, which is an ARM platform
with NEON support.  But the cross-compiler is a royal PITA to use...
it's a Docker image, and requires a bunch of manual configuration,
and I haven't touched any of that in more than a year.)


You seem to have done at least a partial code review of my PR, given
your comments to follow.  I appreciate it!  I tried to add you as a
"reviewer" but GitHub wouldn't permit it--I assume this is some sort
of permissions problem.  Still, it'd be nice if you were able to do
future code reviews using the GitHub review tool; are you permitted to
use that for my PR? 

> - My derive_key_context parameter requires a string and refuses to
> accept bytes. This is consistent with our Rust and C APIs (though the C
> API does include a _raw version specifically for bindings, which we're
> using here).

I was considering going the other way with it actually, requiring bytes.
Note that Python has first-class support for hard-coded bytes strings:

b = blake3.blake3(derive_key_context=b"My Funny Valentine (1984)")

The C interface takes "char *", not a "wchar_t *", and this seemed like
the most direct and relatable way to reflect that.  But I'm not militant
about this, and I'm willing to change the interface to require an actual
string (as in Unicode).  I note that your C API already dictates that
Unicode be encoded as UTF-8, so we can do that, and if the encoding fails
the user can deal with it.


> - I've included an `AUTO` constant that provides a special value (-1)
> for the `max_threads` argument, and I explicitly don't support
> `max_threads=0`.

I can do that too; again, I prefer the 0 there, but I'm not militant about
it.  However, it would make sense to me if you had that constant somewhere
in the BLAKE3 C .h files, which AFAICT you currently don't.


> - I enforce that the `data` arguments are positional-only and that the
> other keyword arguments are keyword-only. I think this is consistent
> with the rest of hashlib.

I suspect hashlib is mostly like that, due to being chock full of
legacy code.  But I don't see why that's necessary.  I think permitting
"data" to be a named argument is fine.  So unless you have a strong
conviction about it--which I bet you don't--I'll leave it as
positional-or-keyword.

There are rare circumstances where positional-only arguments are useful;
this isn't one of them.


> - I include a `.reset()` method.

I don't mind adding that.


> - Unrelated to tests: I haven't made any attempt to zero memory in my
> `dealloc` function. But if that's what other hashlib functions do,
> then I'm certainly in favor of doing it here too.

I inherited that from the BLAKE2 code I carved up to make the BLAKE3
version.  And yeah, it made sense to me, so I kept it.


Christian Heimes:
> GH-31686 is a massive patch set. I'm feeling uncomfortable adding
> such much new code for a new hashing algorithm. Did you ask the
> Steering Council for approval?

I didn't.  Like most hashing algorithms, BLAKE3 doesn't allocate
memory and doesn't perform any I/O.  All it does is meditate on
the data you pass in, and write to various pre-allocated fixed-size
buffers.  As large codebases go this seems pretty harmless, almost inert.

The Modules/_blake3/impl directory is about 32kloc.  I note that the
Modules/_blake2/impl directory you checked in in 2016 is about 21kloc,
and you didn't require Steering Council (or BDFL) approval for that.

As (former) Steering Council member Barry Warsaw says: JFDI!


> The platform detection and compiler flag logic must be added to
> configure.ac instead of setup.py. Erlend and I are in the process
> of making setup.py optional. I plan to remove it entirely along
> with di

[issue30556] asyncio.wait very slow with FIRST_COMPLETED

[Kumar Aditya]

Change by Kumar Aditya :


--
nosy: +asvetlov

___
Python tracker 

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

[issue36098] asyncio: ssl client-server with "slow" read

[Kumar Aditya]

Kumar Aditya  added the comment:

This has been fixed with bpo-44011 on main branch.

Output on main branch:

--
/workspaces/cpython/main.py:42: DeprecationWarning: There is no current event 
loop
  loop = asyncio.get_event_loop()
received 8192, total 8192
received 8192, total 16384
received 8192, total 24576
received 8192, total 32768
received 8192, total 40960
received 8192, total 49152
received 8192, total 57344
received 8192, total 65536
received 8192, total 73728
received 8192, total 81920
received 8192, total 90112
received 8192, total 98304
received 8192, total 106496
received 8192, total 114688
received 8192, total 122880
received 8192, total 131072
received 8192, total 139264
received 8192, total 147456
received 8192, total 155648
received 8192, total 163840
received 8192, total 172032
received 8192, total 180224
received 8192, total 188416
received 8192, total 196608
received 8192, total 204800
received 8192, total 212992
received 8192, total 221184
received 8192, total 229376
received 8192, total 237568
received 8192, total 245760
received 8192, total 253952
received 8192, total 262144
received 8192, total 270336
received 8192, total 278528
received 8192, total 286720
received 8192, total 294912
received 8192, total 303104
received 8192, total 311296
received 8192, total 319488
received 8192, total 327680
received 8192, total 335872
received 8192, total 344064
received 8192, total 352256
received 8192, total 360448
received 8192, total 368640
received 8192, total 376832
received 8192, total 385024
received 8192, total 393216
received 8192, total 401408
received 8192, total 409600
received 0, total 409600



This can be closed now @asvetlov.

--
nosy: +kumaraditya303

___
Python tracker 

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

[issue43923] Can't create generic NamedTuple as of py3.9

[Guido van Rossum]

Guido van Rossum  added the comment:

So if it doesn't work in mypy why bother making it work at runtime? Is there an 
actual use case that broke? (There might be, but probably esoteric if nobody's 
run into it until now.)

--

___
Python tracker 

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

[issue46925] Replace key if not identical to old key in dict

[Raymond Hettinger]

Raymond Hettinger  added the comment:

I concur with Jelle and Methane that we can't do this without breaking code.

Also if you don't care about dict order, the work around is easy.  Just remove 
the old key:

d.pop(k); d[k] = v

--
nosy: +rhettinger
resolution:  -> rejected
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

[issue45100] Improve help() by making typing.overload() information accessible at runtime

[Jelle Zijlstra]

Jelle Zijlstra  added the comment:

We could make my proposed overload registry more reusable by putting it in a 
different module, probably functools. (Another candidate is inspect, but 
inspect.py imports functools.py, so that would make it difficult to use the 
registry for functools.singledispatch.)

We could then bill it as a "variant registry", with an API like this:

def register_variant(key: str, variant: Callable) -> None: ...
def get_variants(key: str) -> list[Callable]: ...
def get_key_for_callable(callable: Callable) -> str | None: ...

@overload could then call register_variant() to register each overload, and 
code that wants a list of overloads (pydoc, inspect.signature, runtime type 
checkers) could call get_variants().

get_key_for_callable() essentially does 
f"{callable.__qualname__}.{callable.__name__}", but returns None for objects it 
can't handle. It will also support at least classmethods and staticmethods.

I will prepare a PR implementing this idea.

--

___
Python tracker 

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

[issue46925] Replace key if not identical to old key in dict

[Jelle Zijlstra]

Jelle Zijlstra  added the comment:

As @methane also said on the PR, this is a backward compatibility break and we 
can't just change the behavior. I'd be opposed to a change here: the proposed 
behavior isn't clearly better than the existing behavior (sometimes you want 
one behavior, sometimes another), and it will be difficult to find and adjust 
code that relies on the existing behavior.

--
nosy: +Jelle Zijlstra

___
Python tracker 

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

[issue43923] Can't create generic NamedTuple as of py3.9

[Jelle Zijlstra]

Jelle Zijlstra  added the comment:

It doesn't really. If you do `x = New([1], (2, 3))` you get:

main.py:11: error: List item 0 has incompatible type "int"; expected "T"
main.py:11: error: Argument 2 to "New" has incompatible type "Tuple[int, int]"; 
expected "Tuple[T, T]"

https://mypy-play.net/?mypy=latest&python=3.10&gist=a13c7a33c55a3aeee95324d46cd03ffd

--

___
Python tracker 

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

[issue43923] Can't create generic NamedTuple as of py3.9

[Guido van Rossum]

Guido van Rossum  added the comment:

Mypy seems to allow this:

from typing import NamedTuple, TypeVar, Generic, List, Tuple

T = TypeVar("T")

class New(NamedTuple, Generic[T]):
x: List[T]
y: Tuple[T, T]

It's true that pyright doesn't, but maybe that's because it doesn't work in 
3.9-3.10?

--

___
Python tracker 

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

[issue24132] Direct sub-classing of pathlib.Path

[Barney Gale]

Change by Barney Gale :


--
pull_requests: +29812
pull_request: https://github.com/python/cpython/pull/31691

___
Python tracker 

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

[issue44136] Remove pathlib flavours

[Barney Gale]

Change by Barney Gale :


--
pull_requests: +29813
pull_request: https://github.com/python/cpython/pull/31691

___
Python tracker 

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

[issue43923] Can't create generic NamedTuple as of py3.9

[Jelle Zijlstra]

Jelle Zijlstra  added the comment:

Was this ever documented to work? We have now disallowed this behavior in 3.9 
and 3.10 with few complaints, so it doesn't seem that important to restore it. 
Also, static type checkers generally disallow generic NamedTuples.

--

___
Python tracker 

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

[issue46798] xml.etree.ElementTree: get() doesn't return default value, always ATTLIST value

[Jacob Walls]

Jacob Walls  added the comment:

I agree not a bug. To ignore the document default you can set 
`specified_attributes` on the parser as documented:

https://docs.python.org/3/library/pyexpat.html#xml.parsers.expat.xmlparser.specified_attributes

Also, this was explicitly worked on recently in bpo-42151, so hard to imagine 
reversing course so soon. I suggest the issue be re-closed.

--
nosy: +jacobtylerwalls

___
Python tracker 

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

[issue46926] runpy.run_path didn't set __package__ to None as describe in doc

[Charlie Yan]

Change by Charlie Yan :


--
title: runpy.run_path didn't set __package__ as describe in doc -> 
runpy.run_path didn't set __package__ to None as describe in doc

___
Python tracker 

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

[issue46926] runpy.run_path didn't set __package__ as describe in doc

[Charlie Yan]

New submission from Charlie Yan :

As described in the doc: 
https://docs.python.org/3.8/library/runpy.html#runpy.run_path

> If the supplied path directly references a script file (whether as source or 
> as precompiled byte code), then __file__ will be set to the supplied path, 
> and __spec__, __cached__, __loader__ and __package__ will all be set to None.

But:
```
$ cat a.py
print(f'{__name__ = }')
print(f'{__package__ = }')

$ cat b.py
import runpy
runpy.run_path('a.py')

$ python3 b.py
__name__ = ''
__package__ = ''
```

`__package__` is not set to None as in the doc.

--
messages: 414555
nosy: yanhao.charles
priority: normal
severity: normal
status: open
title: runpy.run_path didn't set __package__ as describe in doc
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

[issue46925] Replace key if not identical to old key in dict

[Malthe Borch]

New submission from Malthe Borch :

When a key that is equal to an existing key (but not the same object identity) 
is used to set a new value, the key itself is not replaced.

This manifests perhaps most clearly in `weakref.WeakKeyDictionary` where keys 
can mysteriously disappear.

Consider two equal keys, k1 and k2:

d = WeakKeyDictionary()
d[k1] = 1
d[k2] = 2
del k1

We would expect the dictionary to have a single entry k2 => 2. But in fact it 
is empty now.

--
components: Library (Lib)
messages: 414554
nosy: malthe
priority: normal
pull_requests: 29811
severity: normal
status: open
title: Replace key if not identical to old key in dict
type: behavior

___
Python tracker 

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

[issue46860] `--with-suffix` not respected on case-insensitive file systems

[Brett Cannon]

Change by Brett Cannon :


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

[issue46923] Implement stack overflow protection for supported platforms

[Steven D'Aprano]

Steven D'Aprano  added the comment:

> Personally I'd prefer a new exception `StackOverflow` to `MemoryError`

+1 on a new exception (presumably a subclass of MemoryError).

How about using OverflowedStack instead?

The situation is not quite as bad as you suggest. Googling for "stack overflow" 
alone (with a space and no other qualifications):

* on Bing, scroll halfway down the first page of results to find the "People 
also ask..." 

  How do you get a stack overflow?
  How to prevent a stack overflow error?

* also on Bing at the bottom of the first page of results is a question on 
stackoverflow.com asking what causes memory stack overflows;

* on DuckDuckGo, the first page of search results fails to suggest anything 
useful;

* on Google itself, on the first page is the People Also Ask

  What causes stack overflows?

* as well as a link to Wikipedia's page on stack overflows.

I expect that going forward, "python stack overflow exception" will be 
sufficient to hit the Python docs somewhere on the first page.

Besides, presumably this OverflowedStack exception is likely to be rare, so I 
expect that few people will need to google it.

--
nosy: +steven.daprano

___
Python tracker 

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

[issue46914] On Osx Monterey(12.x), Logging.handlers.SysLogHandler does not work

[Philip Bloom]

Philip Bloom  added the comment:

> Do you mean just adding a note to the effect that SysLogHandler won't work on 
> macOS 12.2 because of changes to the syslog daemon on that platform?

Yes or removing the specific guidance about OSX handling on it, mostly just to 
reduce folks coming to ask as they transition to it.  That way it comes off 
that you need to provide a Syslog consumer to use the handler/not to expect one 
to exist on the platform.  Hope I'm phrasing that understandably.

--

___
Python tracker 

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

[issue46896] add support for watching writes to selected dictionaries

[Carl Meyer]

Carl Meyer  added the comment:

Thanks for the feedback!

> Why so coarse?

Simplicity of implementation is a strong advantage, all else equal :) And the 
coarse version is a) at least somewhat proven as useful and usable already by 
Cinder / Cinder JIT, and b) clearly doable without introducing memory or 
noticeable CPU overhead to unwatched dicts. Do you have thoughts about how 
you'd do a more granular version without overhead?

> Getting a notification for every change of a global in module, is likely to 
> make use the use of global variables extremely expensive.

It's possible. We haven't ever observed this as an issue in practice, but we 
may have just not observed enough workloads with heavy writes to globals. I'd 
like to verify this problem with a real representative benchmark before making 
design decisions based on it, though. Calling a callback that is uninterested 
in a particular key doesn't need to be super-expensive if the callback is 
reasonably written, and this expense would occur only on the write path, for 
cases where the `global` keyword is used to rebind a global. I don't think it's 
common for idiomatic Python code to write to globals in perf-sensitive paths. 
Let's see how this shows up in pyperformance, if we try running it with all 
module globals dicts watched.

> For example, we could just tag the low bit of any pointer in a dictionary’s 
> values that we want to be notified of changes to

Would you want to tag the value, or the key? If value, does that mean if the 
value is changed it would revert to unwatched unless you explicitly watched the 
new value?

I'm a bit concerned about the performance overhead this would create for use of 
dicts outside the write path, e.g. the need to mask off the watch bit of 
returned value pointers on lookup.

> What happens if a watched dictionary is modified in a callback?

It may be best to document that this isn't supported; it shouldn't be necessary 
or advisable for the intended uses of dict watching. That said, I think it 
should work fine if the callback can handle re-entrancy and doesn't create 
infinite recursion. Otherwise, I think it's a case of "you broke it, you get to 
keep all the pieces."

> How do you plan to implement this? Steal a bit from `ma_version_tag`

We currently steal the low bit from the version tag in Cinder; my plan was to 
keep that approach.

> You'd probably need a PEP to replace PEP 509, but I think this may need a PEP 
> anyway.

I'd prefer to avoid coupling this to removal of the version tag. Then we get 
into issues of backward compatibility that this proposal otherwise avoids.

I don't think the current proposal is of a scope or level of user impact that 
should require a PEP, but I'm happy to write one if needed.

--

___
Python tracker 

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

[issue38738] Fix formatting of True and False

[miss-islington]

miss-islington  added the comment:


New changeset fa69ec89393549a18944b3b92943709dac56a36a by Miss Islington (bot) 
in branch '3.10':
bpo-38738: Fix formatting of True and False in the threading documentation 
(GH-31678)
https://github.com/python/cpython/commit/fa69ec89393549a18944b3b92943709dac56a36a


--

___
Python tracker 

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

[issue38738] Fix formatting of True and False

[Gregory P. Smith]

Gregory P. Smith  added the comment:


New changeset 46a116c1c9f6b60a3d35ab9a419f8eee5de2542e by Géry Ogam in branch 
'main':
bpo-38738: Fix formatting of True and False in the threading documentation 
(GH-31678)
https://github.com/python/cpython/commit/46a116c1c9f6b60a3d35ab9a419f8eee5de2542e


--
nosy: +gregory.p.smith

___
Python tracker 

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

[issue38738] Fix formatting of True and False

[miss-islington]

Change by miss-islington :


--
nosy: +miss-islington
nosy_count: 5.0 -> 6.0
pull_requests: +29810
pull_request: https://github.com/python/cpython/pull/31690

___
Python tracker 

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

[issue38738] Fix formatting of True and False

[Géry]

Change by Géry :


--
nosy: +maggyero
nosy_count: 4.0 -> 5.0
pull_requests: +29809
pull_request: https://github.com/python/cpython/pull/31678

___
Python tracker 

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

[issue45828] [sqlite3] use unraisable exceptions in callbacks

[Erlend E. Aasland]

Change by Erlend E. Aasland :


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

[issue46924] make install hangs when installing zoneinfo/_zoneinfo.py

[AmericanEnglish]

New submission from AmericanEnglish :

I am currently trying to compile Python 3.10.2 from source. Everything seems to 
compile fine when doing a configure then a make. When I do make install though 
the install process hangs when compiling zoneinfo/_zoneinfo.py . Currently 
there are 6 python processes running when I view top. I have left this for 
several hours and the status is unchanged.

Here is the configure command I used:

export CXX=icpx
export CC=icx
# icx uses LLVM, so this is required for ctypes...?
export CFLAGS="-no-integrated-as"
# icx uses a clang frontend so these should be used as suggested by:
# https://devguide.python.org/setup/
export CFLAGS="$CFLAGS -Wno-unused-value -Wno-empty-body -Qunused-arguments"

cd $BUILD
../../302/configure \
--prefix $PREFIX \
--enable-profiling \
--enable-optimizations \
--with-ensurepip=install > configureOutput.txt


everything runs fine. When I CTRL+C to kill the make install it drops an error:
KeyboardInterrupt
  File "/installation/lib/python3.10/multiprocessing/synchronize.py", line 95, 
in __enter__
return self._semlock.__enter__()
  File "/installation/lib/python3.10/multiprocessing/process.py", line 315, in 
_bootstrap
self.run()
  File "/installation/lib/python3.10/multiprocessing/process.py", line 315, in 
_bootstrap
self.run()
  File "/installation/lib/python3.10/multiprocessing/queues.py", line 102, in 
get
with self._rlock:
  File "/installation/lib/python3.10/multiprocessing/process.py", line 108, in 
run
self._target(*self._args, **self._kwargs)
  File "/installation/lib/python3.10/multiprocessing/process.py", line 315, in 
_bootstrap
[interrupted]
make: [libinstall] Error 1 (ignored)


Any advice would be greatly appreciated. I have tried Googling the problem and 
searching StackOverflow and found no solutions that work.

I will say that this happens with AND without optimizations enabled.

--
components: Installation
messages: 414548
nosy: AmericanEnglish
priority: normal
severity: normal
status: open
title: make install hangs when installing zoneinfo/_zoneinfo.py
type: crash
versions: Python 3.10

___
Python tracker 

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

[issue46841] Inline bytecode caches

[Brandt Bucher]

Brandt Bucher  added the comment:


New changeset c4d2d57eefb1224a12e2e95e4508658dfbf6a7c9 by Brandt Bucher in 
branch 'main':
bpo-46841: Fix BINARY_OP's handling of inline caches (GH-31671)
https://github.com/python/cpython/commit/c4d2d57eefb1224a12e2e95e4508658dfbf6a7c9


--

___
Python tracker 

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

[issue25415] [io doc] Reword "there is no public constructor"

[Terry J. Reedy]

Change by Terry J. Reedy :


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

[issue25415] [io doc] Reword "there is no public constructor"

[miss-islington]

miss-islington  added the comment:


New changeset bdce1880365990403efdbeb60c4928c996370b0c by Miss Islington (bot) 
in branch '3.10':
bpo-25415: Remove confusing sentence from IOBase docstrings (PR-31631)
https://github.com/python/cpython/commit/bdce1880365990403efdbeb60c4928c996370b0c


--

___
Python tracker 

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

[issue25415] [io doc] Reword "there is no public constructor"

[miss-islington]

miss-islington  added the comment:


New changeset 01df048831eb631dfee41175f08d09b9ad1a9538 by Miss Islington (bot) 
in branch '3.9':
bpo-25415: Remove confusing sentence from IOBase docstrings (PR-31631)
https://github.com/python/cpython/commit/01df048831eb631dfee41175f08d09b9ad1a9538


--

___
Python tracker 

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

[issue39298] add BLAKE3 to hashlib

[Christian Heimes]

Christian Heimes  added the comment:

GH-31686 is a massive patch set. I'm feeling uncomfortable adding such much new 
code for a new hashing algorithm. Did you ask the Steering Council for approval?

The platform detection and compiler flag logic must be added to configure.ac 
instead of setup.py. Erlend and I are in the process of making setup.py 
optional. I plan to remove it entirely along with distutils in 3.12.

--
assignee: christian.heimes -> 

___
Python tracker 

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

[issue29971] threading.Lock.acquire() not interruptible on Windows

[Géry]

Change by Géry :


--
nosy: +maggyero

___
Python tracker 

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

[issue45274] Race condition in Thread._wait_for_tstate_lock()

[Géry]

Change by Géry :


--
nosy: +maggyero

___
Python tracker 

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

[issue39298] add BLAKE3 to hashlib

[Jack O'Connor]

Jack O'Connor  added the comment:

Thanks Larry! Was any of the experimental C extension code under 
https://github.com/oconnor663/blake3-py/tree/master/c_impl useful to you? I was 
wondering if it could be possible to copy blake3module.c from there verbatim. 
The setup.py build there also has working Windows and NEON support.

I've patched the blake3-py test suite (which both the production Rust-based 
extension and that experimental C-based extension currently pass) to invoke the 
new hashlib implementation from your branch. You can find the full test output, 
and the procedure I used to run the tests, in this Gist 
https://gist.github.com/oconnor663/533048580b1c0f4a01d1d55f57f92792. Here are 
some differences:

- My derive_key_context parameter requires a string and refuses to accept 
bytes. This is consistent with our Rust and C APIs (though the C API does 
include a _raw version specifically for bindings, which we're using here). For 
a long discussion of why we prefer to do things this way, see 
https://github.com/BLAKE3-team/BLAKE3/issues/13. The short version is that any 
use case that requires arbitrary bytes for the context string is almost 
certainly violating the documented security requirement that the context string 
must be hardcoded.

- I've included an `AUTO` constant that provides a special value (-1) for the 
`max_threads` argument, and I explicitly don't support `max_threads=0`.

- I enforce that the `data` arguments are positional-only and that the other 
keyword arguments are keyword-only. I think this is consistent with the rest of 
hashlib.

- I include a `.reset()` method. This isn't particularly useful in the default 
case, where you might as well create a new hasher. But when `max_threads` is 
greater than 1 in the Rust implementation, the hasher owns a thread pool, and 
`.reset()` is currently the only way to reuse that pool. (A BLAKE3 hasher is 
also ~2 KB, somewhat larger than other hashers, so callers who are pinching 
pennies with their allocator traffic might prefer to reuse the object.)

- Unrelated to tests: I haven't made any attempt to zero memory in my `dealloc` 
function. But if that's what other hashlib functions do, then I'm certainly in 
favor of doing it here too.

--

___
Python tracker 

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

[issue46922] tarfile.TarFile.next() crashes on empty tar files

[Ethan Furman]

Change by Ethan Furman :


--
nosy: +ethan.furman

___
Python tracker 

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

[issue17505] [doc] email.header.Header.__unicode__ does not decode header

[Vidhya]

Vidhya  added the comment:

@hniksic: Thanks for your suggestions. I will look into BytesFeedParser 
documents.
@david.murray: I can help you for the switch over to the default in the default 
policy and update the deprecation as well. It will be good if someone can guide 
me on this. Being a beginner, I am not sure if we are allowed to change the 
python code.

--

___
Python tracker 

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

[issue43923] Can't create generic NamedTuple as of py3.9

[Guido van Rossum]

Guido van Rossum  added the comment:

Couldn't there be a subtler solution than rolling back GH-19371?

--

___
Python tracker 

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

[issue46896] add support for watching writes to selected dictionaries

[Brandt Bucher]

Brandt Bucher  added the comment:

> Why so coarse?

> Getting a notification for every change of a global in module, is likely to 
> make use the use of global variables extremely expensive.

Perhaps a compromise is possible here: one global group/chain of callbacks 
registered for all dictionaries in an interpreter seems reasonable (to keep 
overhead low), but we could reduce the number of times it’s actually called by, 
say, tagging specific values of specific dictionaries to be watched.

For example, we could just tag the low bit of any pointer in a dictionary’s 
values that we want to be notified of changes to. Something like that seems 
like it could really keep the cost of watching down without sacrificing power.

--

___
Python tracker 

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

[issue25415] [io doc] Reword "there is no public constructor"

[miss-islington]

Change by miss-islington :


--
pull_requests: +29808
pull_request: https://github.com/python/cpython/pull/31689

___
Python tracker 

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

[issue25415] [io doc] Reword "there is no public constructor"

[miss-islington]

Change by miss-islington :


--
nosy: +miss-islington
nosy_count: 6.0 -> 7.0
pull_requests: +29807
pull_request: https://github.com/python/cpython/pull/31688

___
Python tracker 

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

[issue25415] [io doc] Reword "there is no public constructor"

[Terry J. Reedy]

Terry J. Reedy  added the comment:


New changeset cedd2473a9bebe07f3ced4f341cf58a2fef07b03 by slateny in branch 
'main':
bpo-25415: Remove confusing sentence from IOBase docstrings (PR-31631)
https://github.com/python/cpython/commit/cedd2473a9bebe07f3ced4f341cf58a2fef07b03


--

___
Python tracker 

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

[issue46923] Implement stack overflow protection for supported platforms

[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

[issue46923] Implement stack overflow protection for supported platforms

[Brandt Bucher]

Change by Brandt Bucher :


--
nosy: +brandtbucher

___
Python tracker 

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

[issue46389] 3.11: unused generator comprehensions cause f_lineno==None

[Mark Shannon]

Change by Mark Shannon :


--
stage: resolved -> 

___
Python tracker 

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

[issue46923] Implement stack overflow protection for supported platforms

[Mark Shannon]

New submission from Mark Shannon :

https://github.com/python/steering-council/issues/102 (definitely not PEP 651 
;))

We should implement efficient stack checks on those platforms that allow us to 
introspect stack extents.
Windows and posix systems allow us to do this.

C allows addresses of stack variables to be taken. This means that C stacks 
cannot be moved.
In theory they might be discontinuous, although I suspect that they are always 
contiguous.

My plan is to maintain a per-thread "safe region" of 32or 64k. We can check if 
the current stack pointer (or near enough) is in that region cheaply.
If we are not in that region, we can ask the O/S for a stack limit to determine 
a new "safe region". If we cannot find a safe region, then we raise a 
MemoryError.

Personally I'd prefer a new exception `StackOverflow` to `MemoryError` but, 
thanks to stackoverflow.com, it is now impossible for new programmers to do a 
web search to determine what a "stack overflow" is.
So, I guess MemoryError will have to do.

--
assignee: Mark.Shannon
messages: 414538
nosy: Mark.Shannon, gregory.p.smith
priority: normal
severity: normal
status: open
title: Implement stack overflow protection for supported platforms

___
Python tracker 

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

[issue44549] Update Windows installer to use bzip2 1.0.8

[Ned Deily]

Change by Ned Deily :


--
title: Update Windows installer to use BZip 1.0.8 -> Update Windows installer 
to use bzip2 1.0.8

___
Python tracker 

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

[issue44549] Update Windows installer to use BZip 1.0.8

[Ned Deily]

Change by Ned Deily :


--
assignee:  -> steve.dower
priority: normal -> critical
title: BZip 1.0.6 Critical Vulnerability -> Update Windows installer to use 
BZip 1.0.8
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

[issue46794] Please update bundled libexpat to 2.4.6 with security fixes (5 CVEs)

[sping]

sping  added the comment:

Hi mattip,

at the core the problem is not the use of non-URI character "}" for a namespace 
separator but the use of non-URI character "}" in a namespace URI.  
test_issue3151 is mistaken (meaning that non-URI characters in URIs are 
malformed XML) and the test has been removed in CPython pull request 
https://github.com/python/cpython/pull/31453/files .  Expat pull request 
https://github.com/libexpat/libexpat/pull/577 is related but it's about URI 
characters not about non-URI ones, so it does not change anything about 
test_issue3151 in PyPy.  Does that make sense?

Best, Sebastian

--

___
Python tracker 

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

[issue46922] tarfile.TarFile.next() crashes on empty tar files

[progval]

New submission from progval :

Hi,

I found two related bugs when calling tarfile.TarFile.next() on an empty tar 
file, both when trying to seek when it should not:

import io
import tarfile

# Create a tarball with no member:
fd = io.BytesIO()
with tarfile.open(fileobj=fd, mode="w") as tf:
pass

# read in stream mode:
fd.seek(0)
with tarfile.open(fileobj=fd, mode="r|") as tf:
print(tf.next())   # tarfile.StreamError: seeking backwards is not allowed

# read in normal mode:
fd.seek(0)
with tarfile.open(fileobj=fd, mode="r") as tf:
print(tf.next())  # ValueError: negative seek value -1

--
components: Library (Lib)
messages: 414536
nosy: progval
priority: normal
severity: normal
status: open
title: tarfile.TarFile.next() crashes on empty tar files
versions: Python 3.10, Python 3.9

___
Python tracker 

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

[issue46921] Vectorcall support for super()

[Ken Jin]

Change by Ken Jin :


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

___
Python tracker 

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

[issue46921] Vectorcall support for super()

[Ken Jin]

New submission from Ken Jin :

This is related to bpo-46564. The changes are less ambitious but should produce 
a nice speedup.

--
messages: 414535
nosy: kj
priority: normal
severity: normal
status: open
title: Vectorcall support for super()
versions: Python 3.11

___
Python tracker 

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

[issue46541] Replace _Py_IDENTIFIER() with statically initialized objects.

[Dong-hee Na]

Dong-hee Na  added the comment:


New changeset d168c728f7114959e8fc147538ea1d24f2f5af79 by Dong-hee Na in branch 
'main':
bpo-46541: Remove usage of _Py_IDENTIFIER from lzma module (GH-31683)
https://github.com/python/cpython/commit/d168c728f7114959e8fc147538ea1d24f2f5af79


--

___
Python tracker 

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

[issue46919] After Python 3.9.2 is installed, the CVE-2019-12900 and CVE-2016-3189 vulnerabilities exist in Python39/DLLs/_bz2.pyd.

[Ned Deily]

Change by Ned Deily :


--
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> BZip 1.0.6 Critical Vulnerability

___
Python tracker 

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

[issue39298] add BLAKE3 to hashlib

[Larry Hastings]

Larry Hastings  added the comment:

Also, for what it's worth: I just ran my checksum benchmarker using a freshly 
built python a la my PR.  Here are my results when hashing 462183782 bytes 
(dicey-dungeons-linux64.zip):

  hash
 algorithm  timebytes/sec size hash 
 -  -- --  -
blake3  0.18976406 2435570699   64 0c72d0a07ba767b75b0c99fed38fda...
  sha1  0.21692419 2130623562   40 9fb83614394cd3b39e42b1d9f84a3c...
sha256  0.26399648 1750719480   64 2320129f2545ff8606d3db1d706d86...
sha224  0.28097475 1644929957   56 133b5da8d8b387f2bcfd69b0c73ed8...
   md4  0.34185237 1351998195   32 dea7585ea9fa4520687bab1dc671858e
   blake2b  0.53724666  860282275  128 e3653f33858a83b386c2fe865280a1...
   md5  0.58128106  795112407   32 299440e1968cf8f8abc288bac8c0a4fa
sha512_224  0.64589952  715566066   56 413d48b782f114870ef80815540678...
sha384  0.64645893  714946859   96 b1c1cd96cef79c15f2171b8aa81304...
sha512  0.65424513  706438241  128 e7d0cec3fe8b73d1534a7bdb484176...
sha512_256  0.68371638  675987586   64 3f58faba70cea4d6ea8a8371e71bbb...
  md5-sha1  0.80361958  575127576   72 299440e1968cf8f8abc288bac8c0a4...
 shake_128  0.84424524  547452041   64 c62a813897b81f67822fc07115deae...
   blake2s  0.85661793  539544839   64 cb8bd19c6ca446bbf7a8abbec61dc5...
  sha3_224  0.95759645  482649850   56 6f96d117c7fcbcd802b222854db644...
 shake_256  1.0152032   455262322   64 2d9f9dafe0ddf792c6407910946845...
  sha3_256  1.015744455019929   64 cc5d55fe0ac31f6e335da1bc6abaf3...
  sha3_384  1.3235858   349190644   96 13206910ff231fe51a38fe637ded30...
   sm3  1.4478934   319211203   64 021cd913540d95b13a03342b54f80d...
 ripemd160  1.4737549   313609670   40 1a956000b88267ec8fc23327d22548...
  sha3_512  1.9131832   241578418  128 e84b9f499b013956f6f36c93234ca3...

"time" is wall time in seconds.  So, yes, BLAKE3 was the fastest hash algorithm 
available on my machine--2.4GB/sec!

(I'm a little surprised by that result actually.  My CPU is pretty modern, so I 
assume it has the SHA1 extensions.  And I further assume we're using OpenSSL, 
and OpenSSL will use those extensions when available.  If BLAKE3 is *still* 
faster that OpenSSL, well! hats off to the BLAKE3 team.  And that just goes to 
show you how useful SIMD extensions are!)

--

___
Python tracker 

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

[issue39298] add BLAKE3 to hashlib

[Larry Hastings]

Larry Hastings  added the comment:

Okay, so.  Here's a PR that adds BLAKE3 support to hashlib.

The code was straightforward; I just took the BLAKE2 module and modified it to 
only have one algorithm.  I also copied over the whole C directory tree from 
BLAKE3, which is totally okay fine by their license.  I didn't have to modify 
it a bit.

The tricky part was building it.  Building extension modules is done inside 
setup.py using distutils (or the modern replacement), and in order to get those 
sexy SIMD implementations I had to compile assembly-language files, or C files 
with extra flags.  What I did works great on my Linux box, and I have my 
fingers crossed that it'll work on other POSIX platforms.  I wrote a lng 
comment in setup.py explaining what I did and why.

Steve: I didn't do anything for Windows support.  Do you have time to take a 
pass at it?  Or if you know another core dev who does Windows build stuff, 
please nosy them.  Whoever does the work. I suggest you read 
https://github.com/BLAKE3-team/BLAKE3/blob/master/c/README.md for a little 
guidance on how to build BLAKE3 on Windows with SIMD support.  Also, I see you 
now build Python for Windows on ARM!  Does this mean Python can use BLAKE3's 
NEON support?  Maybe it's time to find out!  Get hyped!

Jack and I corresponded last year (or maybe 2020?) about what the API should 
look like.  The idea is, Jack also maintains a BLAKE3 Python extension on pypi, 
written in Rust.  Our goal was to make the two types behave identically, so 
that it could be like the old stringio / cstringio situation.  You can use the 
built-in one for convenience, but also you can install the Rust version from 
PyPI for even more performance.  Jack, it wouldn't hurt my feelings overly much 
if you checked my PR to make sure I got the interface right.

--

___
Python tracker 

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

[issue39298] add BLAKE3 to hashlib

[Larry Hastings]

Change by Larry Hastings :


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

___
Python tracker 

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

[issue46430] intern strings in deepfrozen modules

[Dong-hee Na]

Change by Dong-hee Na :


--
pull_requests:  -29803

___
Python tracker 

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

[issue46541] Replace _Py_IDENTIFIER() with statically initialized objects.

[Dong-hee Na]

Change by Dong-hee Na :


--
pull_requests: +29804
pull_request: https://github.com/python/cpython/pull/31683

___
Python tracker 

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

[issue46430] intern strings in deepfrozen modules

[Dong-hee Na]

Change by Dong-hee Na :


--
pull_requests: +29803
pull_request: https://github.com/python/cpython/pull/31683

___
Python tracker 

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

[issue46896] add support for watching writes to selected dictionaries

[Mark Shannon]

Mark Shannon  added the comment:

Why so coarse?

Getting a notification for every change of a global in module, is likely to 
make use the use of global variables extremely expensive.

```
var = 0

CONST = 1
def foo(...):
...
```

I may well want to be notified if `foo` or `CONST` gets modified, but 
performance could suffer badly if we make a callback every time `var` is 
changed.

--

What happens if a watched dictionary is modified in a callback?

--

How do you plan to implement this? Steal a bit from `ma_version_tag` or replace 
`ma_version_tag`?
If you replace `ma_version_tag` this could actually speed things up a tad.

You'd probably need a PEP to replace PEP 509, but I think this may need a PEP 
anyway.

--

___
Python tracker 

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

[issue46311] Clean up PyLong_FromLong and PyLong_FromLongLong

[Mark Shannon]

Change by Mark Shannon :


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

[issue17505] [doc] email.header.Header.__unicode__ does not decode header

[R. David Murray]

R. David Murray  added the comment:

The policy is named 'default' because it was intended to become the default two 
feature releases after the new email code became non-provisional (first: 
deprecate not specifying an explicit policy, next release make default the 
default policy and make the deprecation only cover compat32).  However, for 
various reasons that switchover did not happen (one big factor being my reduced 
time spent doing python development).  It can happen any time someone steps 
forward to guide it through the release process.

--

___
Python tracker 

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

[issue31613] Localize tkinter.simpledialog.Default buttons as with file dialogs.

[Sampo Hippeläinen]

Sampo Hippeläinen  added the comment:

>Tk does not provide localized [Ok] and [Cancel] buttons.

This is not true. You can call ::msgcat::mc to localize core strings such as 
"OK" and "Cancel".

The full tk.call becomes

tk.call("namespace", "eval", "::tk", "::msgcat::mc", s)

to translate a string s, such as "OK".

I have made a custom modified version of simpledialog.py that makes use of this 
and indeed localizes the OK/Cancel buttons as they would be localized for tk 
messageboxes (which use Tcl/Tk Core localization). I submitted this now as a 
GitHub PR.

--
nosy: +sampo.hippelainen

___
Python tracker 

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

[issue31613] Localize tkinter.simpledialog.Default buttons as with file dialogs.

[Roundup Robot]

Change by Roundup Robot :


--
keywords: +patch
nosy: +python-dev
nosy_count: 3.0 -> 4.0
pull_requests: +29801
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31682

___
Python tracker 

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

[issue46918] The vulnerability is included in /lib/python3.9/ensurepip after python 3.9.2 is installed.

[Ned Deily]

Ned Deily  added the comment:

To emphasize, Python 3.9.2 is obsolete and no longer supported; at the moment, 
the current release of Python 3.9 is 3.9.10. The most current bugfix release 
(3.9.x) obsoletes all previous releases of that Python version (3.9); during a 
version's support lifecycle, we only provide fixes for the most recent bugfix 
release (3.9.10). (Downstream third-party distributors of Python may have 
different support policies.)

https://www.python.org/downloads/

--
nosy: +ned.deily

___
Python tracker 

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

[issue5043] get_msvcr() returns None rather than []

[Alex Zunegin]

Alex Zunegin  added the comment:

This messes up building Cython extensions on MSYS2 and MINGW. Still here as of 
setuptools 60. 

There is no line 
```
return [] -
```
at the end. Adding it helps.

--
nosy: +gesserat

___
Python tracker 

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

[issue46794] Please update bundled libexpat to 2.4.6 with security fixes (5 CVEs)

[mattip]

mattip  added the comment:

On PyPy, the test `test_issue3151` in `test_xml_etree.py` is failing with 
libexpat 2.4.6. I think the problem is connected to instantiation of the 
`XMLParser()` with `parser = expat.ParserCreate(encoding, "}")` where `"}"` is 
not a valid URI character. In any case, due to libexpat issue 577, 
https://github.com/libexpat/libexpat/pull/577 they will be releasing a new 
version 2.4.7 soon.

--
nosy: +mattip

___
Python tracker 

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

[issue46916] There is a problem with escape characters in the path passed in by pathlib.Path.mkdir()

[Vincent FUNG]

Vincent FUNG  added the comment:

Thank you very much for your patient answer, I am still a developer who has 
just started, and it seems that I need to learn more about it.

I used repr().replace to replace with forward slashes, and also restricted 
paths ending in a slash to Improve reliability.

Thanks anagin. ;)

--

___
Python tracker 

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

[issue46841] Inline bytecode caches

[Mark Shannon]

Mark Shannon  added the comment:


New changeset 586b24d3be1aec5d2568b070a249b4d75e608782 by Brandt Bucher in 
branch 'main':
bpo-46841: Fix error message hacks in `GET_AWAITABLE` (GH-31664)
https://github.com/python/cpython/commit/586b24d3be1aec5d2568b070a249b4d75e608782


--

___
Python tracker 

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

[issue46781] Tracing: c_return doesn't report the result

[Mark Shannon]

Mark Shannon  added the comment:

This is an API change.

I agree that the API is not what it should be, but we can't change it without 
breaking an unknown amount of 3rd party code that uses it.

--
nosy: +Mark.Shannon

___
Python tracker 

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

[issue46910] Expect IndentationError, get SyntaxError: 'break' outside loop

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

Unfortunately that's not how the parser works. I insist, for the compiler to 
raise the propper error the parser needs to succeed first. That would require 
us to modify the input string in arbitrary ways (many times we don't know 
exactly what went wrong) and recompile an arbitrary number of times.

I'm very sorry, but I will leave this issue closed as "won't fix" as the 
complexity of this solution is too much for the given benefit.

--

___
Python tracker 

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

[issue46920] Remove code made dead long ago with #if 0

[Oleg Iarygin]

Oleg Iarygin  added the comment:

Also forgot to add that git grep "#if 1" gives the following:

- added on 20 Nov 2014 by d600951: cpython/Python/pylifecycle.c:2427. "/* 
Disable this if you have trouble debugging bootstrap stuff */" - after seven 
years, no trouble was found so this always-true guard has no use.

--

___
Python tracker 

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

[issue46920] Remove code made dead long ago with #if 0

[Oleg Iarygin]

Change by Oleg Iarygin :


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

___
Python tracker 

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

[issue46920] Remove code made dead long ago with #if 0

[Oleg Iarygin]

New submission from Oleg Iarygin :

`git grep "#if 0"` gives the following occurences of dead code (analyzed with 
`git blame`, removed by a linked pull request):

- added on 27 Apr 2020 by 2b74c83: Parser/pegen.h:9, Parser/pegen.h:15. Since 
these constants aren't mentioned anywhere else, I think it's some initial 
experiment now abandoned.

- added on 23 Apr 2020 by c5fc156: Parser/pegen.c:40. `token_name` is mentioned 
nowhere in the CPython codebase too.

- added on 20 Nov 2014 by d600951: Python/pylifecycle.c:1843 with the following 
note:

  > XXX This is disabled because it caused too many problems.  If a __del__ or 
weakref callback triggers here, Python code has a hard time running, because 
even the sys module has been cleared out (sys.stdout is gone, sys.excepthook is 
gone, etc).  One symptom is a sequence of information-free messages coming from 
threads (if a __del__ or callback is invoked, other threads can execute too, 
and any exception they encounter triggers a comedy of errors as subsystem after 
subsystem fails to find what it *expects* to find in sys to help report the 
exception and consequent unexpected failures).  I've also seen segfaults then, 
after adding print statements to the Python code getting called.

  So the call is faulty for seven years with no progress.

- added on 26 Oct 2013 by 8444ebb: Modules/sre_lib.h336. The Secret Labs' 
Regular Expression Engine was vendored nine years ago so `not used in this 
release` is permanent and can be removed.

- added on 25 Aug 2012 by 2543756: 
Modules/_ctypes/libffi_osx/x86/x86-ffi64.c:155

- added on 21 Mar 2012 by 1919b7e: Modules/_decimal/libmpdec/sixstep.c:120, 
Modules/_decimal/libmpdec/sixstep.c:157, 
Modules/_decimal/libmpdec/fourstep.c:189, 
Modules/_decimal/libmpdec/fourstep.c:220

- added on 28 Sep 2011 by d63a3b8: Python/formatter_unicode.c:140. 
`DEBUG_PRINT_FORMAT_SPEC` is used nowhere, plus putting a debugger breakpoint 
onto an interesting `InternalFormatSpec` is more convenient.

- added on 5 Mar 2008 by 7864476: 
Modules/_ctypes/libffi_osx/powerpc/ppc-ffi_darwin.c:40

- added on 27 Aug 2007 by e226b55: Objects/unicodeobject.c:13660, 
Objects/unicodeobject.c:14253. `_decimal2ascii` is mentioned nowhere else in 
the CPython codebase.

- added on 11 Aug 2006 by 0e3f591: Python/compile.c:7873. Neither `dump_instr` 
nor `dump_basicblock` are used.

- added on 7 Dec 2005 by 8c8836b: Modules/_elementtree.c:39. In addition, 
`ALLOC()` and `RELEASE()` are removed as unconditional no-ops.

- added on 4 Aug 2002 by 00f1e3f: Parser/tokenizer.c:285. "/* Disable support 
for UTF-16 BOMs until a decision is made whether this needs to be supported */" 
- I have every reason to believe that the decision was Never Ever.

- added on 23 Mar 2002 by c24ea08: Python/ceval.c:7065-L7070. The "/* future 
keyword */" is quite overdue already.

- added on 23 Jun 2001 by 01dfdb3: Modules/getaddrinfo.c:41, 
Modules/getnameinfo.c:37

- added on 14 Jul 1998 by 43ff868: Modules/_tkinter.c:3443

--
components: Extension Modules, Interpreter Core, Unicode, macOS
messages: 414519
nosy: arhadthedev, ezio.melotti, ned.deily, ronaldoussoren, vstinner
priority: normal
severity: normal
status: open
title: Remove code made dead long ago with #if 0
type: enhancement
versions: Python 3.11

___
Python tracker 

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

[issue19217] Calling assertEquals for moderately long list takes too long

[Alex Waygood]

Change by Alex Waygood :


--
keywords:  -easy

___
Python tracker 

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

[issue46910] Expect IndentationError, get SyntaxError: 'break' outside loop

[Jonathan Fine]

Jonathan Fine  added the comment:

Many thanks Pablo for the clear explanation. I'd prefer that the issue remain 
open, as there's an important user experience issue here. I suspect there are 
other similar examples of how the compiler error messages could be improved.

Here's a change that doesn't seem to be too hard, that could fix the problem at 
hand.

The IndentationError occurred at a known location in the input string. So as 
part of error reporting truncate the input string and try to compile that. In 
other words, make a good faith attempt to find an earlier error.

I've attached a funny_break_error_fix.py which is a first draft implementation 
of this idea. 

Here's the output:
===
$ python3 funny_break_error_fix.py funny_break_error.py
unexpected indent (funny_break_error.py, line 6)
Traceback (most recent call last):
  File "funny_break_error_fix.py", line 3, in compile_fix
compile(source, filename, 'exec')
  File "funny_break_error.py", line 6
else:
^
IndentationError: unexpected indent

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "funny_break_error_fix.py", line 18, in 
compile_fix(src.read(), filename, 'exec')
  File "funny_break_error_fix.py", line 9, in compile_fix
compile(new_source, filename, 'exec')
  File "funny_break_error.py", line 5
break
^
SyntaxError: 'break' outside loop
===

And in this case we've got hold of the first error (at the cost of compiling 
part of the source file twice). Many thanks again for the clear explanation, 
which I found most helpful when formulating the above fix.

--
Added file: https://bugs.python.org/file50656/funny_break_error_fix.py

___
Python tracker 

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

[issue46916] There is a problem with escape characters in the path passed in by pathlib.Path.mkdir()

[Eryk Sun]

Eryk Sun  added the comment:

> I thought pathlib would solve this problem completely now, 
> without having to replace the slashes.

pathlib has nothing to do with how the Python language compiles string 
literals. A string *literal* is Python source code that gets compiled and 
instantiated as a string object. 

There is no technical problem with using r'F:\ceven\test2'. Using a raw string 
literal disables backslash escapes. But many developers find it inconvenient to 
have to use raw strings or to have to escape backslashes by doubling them. Plus 
raw string literals can't represent a path that ends with a backslash, such as 
C:\. 

The Windows API supports forward slash as a path separator in many cases, but 
not always, and also not always for paths passed on the command line. So it's 
preferable to always normalize paths. pathlib takes care of this for you. You 
can initialize conveniently with forward slashes, but get a Windows path string 
that uses backslashes.

--

___
Python tracker 

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

[issue46911] Early tracing has lineno=None for modules

[Mark Shannon]

Mark Shannon  added the comment:

This is a bit of a tricky one.

The problem is that the line number for an instruction is used for two purposes.
1. To calculate the line number in frame.f_lineno for tracebacks and events
2. By dis to determine which lines are present and where they start.

If we set the lineno for the initial RESUME instruction in a module, we break 
dis and coverage for modules that do not have code on line 1.

If we add an explicit line-start table, we would be able to fix this, as the 
RESUME would have a line number for case 1, but wouldn't start a line, thus not 
breaking dis.

An explicit line-start table has other advantages, so we probably will 
implement it, but maybe not until 3.12.

Ned,
Would it make sense in coverage.py to ignore "call" events when doing coverage, 
and only use "line" events?
All the traces in your example are from "call" events.

--

___
Python tracker 

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

[issue46903] Crash when setting attribute with string subclass as the name (--with-pydebug)

[Mark Shannon]

Mark Shannon  added the comment:


New changeset 03c2a36b2bd2d4469160d1607619ee144175d753 by Mark Shannon in 
branch 'main':
bpo-46903: Handle str-subclasses in virtual instance dictionaries. (GH-31658)
https://github.com/python/cpython/commit/03c2a36b2bd2d4469160d1607619ee144175d753


--

___
Python tracker 

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

[issue46916] There is a problem with escape characters in the path passed in by pathlib.Path.mkdir()

[Vincent FUNG]

Vincent FUNG  added the comment:

Oh. Got it. 

I thought pathlib would solve this problem completely now, without having to 
replace the slashes. Thank you for your patient answer.

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

[issue31370] Remove support for threads-less builds

[pmp-p]

Change by pmp-p :


--
nosy: +pmpp

___
Python tracker 

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

[issue43923] Can't create generic NamedTuple as of py3.9

[Alex Waygood]

Change by Alex Waygood :


--
nosy: +Jelle Zijlstra, gvanrossum, kj, sobolevn

___
Python tracker 

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

[issue46918] The vulnerability is included in /lib/python3.9/ensurepip after python 3.9.2 is installed.

[Karthikeyan Singaravelan]

Karthikeyan Singaravelan  added the comment:

https://nvd.nist.gov/vuln/detail/CVE-2020-14422

Lib/ipaddress.py in Python through 3.8.3 improperly computes hash values in the 
IPv4Interface and IPv6Interface classes, which might allow a remote attacker to 
cause a denial of service if an application is affected by the performance of a 
dictionary containing IPv4Interface or IPv6Interface objects, and this attacker 
can cause many dictionary entries to be created. This is fixed in: v3.5.10, 
v3.5.10rc1; v3.6.12; v3.7.9; v3.8.4, v3.8.4rc1, v3.8.5, v3.8.6, v3.8.6rc1; 
v3.9.0, v3.9.0b4, v3.9.0b5, v3.9.0rc1, v3.9.0rc2.

This CVE is listed as fixed in 3.9.0RC2 though you have added 3.9.2 and also 
mentioned ensurepip which doesn't seem to be relevant. Can you please add more 
detail over how we can reproduce the vulnerability in latest master or latest 
stable 3.9 release and how this is related to ensurepip.

--
nosy: +xtreak

___
Python tracker 

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

[issue46907] Update Windows and MacOS installer to SQLite 3.38.0.

[Karthikeyan Singaravelan]

Change by Karthikeyan Singaravelan :


--
nosy: +xtreak

___
Python tracker 

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

[issue29406] asyncio SSL contexts leak sockets after calling close with certain Apache servers

[STINNER Victor]

Change by STINNER Victor :


--
nosy:  -vstinner

___
Python tracker 

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

[issue46913] UBSAN: test_ctypes, test_faulthandler and test_hashlib are failing

[STINNER Victor]

STINNER Victor  added the comment:

> I don't agree with GH-31673. Did you try defining NO_MISALIGNED_ACCESSES 
> instead?

Did you read the commit message? The change is not about skipping the test, but 
fixing the CI. Previously, test_hashlib was not run at all on the UBSan 
buildbot, now most test_hashlib tests are run. The intent is to make sure that 
we don't add *new* undefined behavior.

As I wrote in the commit, the UD must be fixed in _sha3.

No, I didn't try NO_MISALIGNED_ACCESSES, I don't know this macro. If you have 
an idea on how _sha3 can be fixed on the UBSan buildbot, please go head!

--

___
Python tracker 

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

[issue40185] Refactor typing.NamedTuple

[Roundup Robot]

Change by Roundup Robot :


--
nosy: +python-dev
nosy_count: 4.0 -> 5.0
pull_requests: +29799
pull_request: https://github.com/python/cpython/pull/31679

___
Python tracker 

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

[issue43923] Can't create generic NamedTuple as of py3.9

[Roundup Robot]

Change by Roundup Robot :


--
keywords: +patch
nosy: +python-dev
nosy_count: 7.0 -> 8.0
pull_requests: +29798
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31679

___
Python tracker 

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

[issue46919] After Python 3.9.2 is installed, the CVE-2019-12900 and CVE-2016-3189 vulnerabilities exist in Python39/DLLs/_bz2.pyd.

[zjmxq]

Change by zjmxq :


--
components: Library (Lib)
nosy: zjmxq
priority: normal
severity: normal
status: open
title: After Python 3.9.2 is installed, the CVE-2019-12900 and CVE-2016-3189 
vulnerabilities exist in Python39/DLLs/_bz2.pyd.
type: security
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

[issue46918] The vulnerability is included in /lib/python3.9/ensurepip after python 3.9.2 is installed.

[zjmxq]

New submission from zjmxq :

Vulnerability CVE-2021-29921,CVE-2020-14422, CVE-2021-3572, CVE-2021-33503 
Vulnerability Found in python 3.9.2 /lib/python3.9/ensurepip

--
components: Library (Lib)
messages: 414511
nosy: zjmxq
priority: normal
severity: normal
status: open
title: The vulnerability is included in /lib/python3.9/ensurepip after python 
3.9.2 is installed.
type: security
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

[issue45413] Add install scheme for virtual environments

[Petr Viktorin]

Petr Viktorin  added the comment:

Steve, could you take a look at the PR discussion and chime in about how this 
should be done?

--

___
Python tracker 

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

[issue29406] asyncio SSL contexts leak sockets after calling close with certain Apache servers

[Kumar Aditya]

Kumar Aditya  added the comment:

Since bpo-issue44011 is fixed, this can be closed now @asvetlov.

--
nosy: +kumaraditya303

___
Python tracker 

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

[issue17505] [doc] email.header.Header.__unicode__ does not decode header

[Hrvoje Nikšić]

Hrvoje Nikšić  added the comment:

> Any suggestions on what needs to be done for current revisions?

Hi! I'm the person who submitted this issue back in 2013. Let's take a look at 
how things are in Python 3.10:

Python 3.10.2 (main, Jan 13 2022, 19:06:22) [GCC 10.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import email
>>> msg = email.message_from_string('Subject: 
>>> =?gb2312?b?1eLKx9bQzsSy4srUo6E=?=\n\nfoo\n')
>>> msg['Subject']
'=?gb2312?b?1eLKx9bQzsSy4srUo6E=?='

So the headers are still not decoded by default. The `unicode()` invocation in 
the original description was just an attempt to get a Unicode string out of a 
byte string (assuming it was correctly decoded from MIME, which it wasn't). 
Since Python 3 strings are Unicode already, I'd expect to just get the decoded 
subject - but that still doesn't happen.

The correct way to make it happen is to specify `policy=email.policy.default`:

>>> msg = email.message_from_string('Subject: 
>>> =?gb2312?b?1eLKx9bQzsSy4srUo6E=?=\n\nfoo\n', policy=email.policy.default)
>>> msg['Subject']
'这是中文测试！'

The docs should point out that you really _want_ to specify the "default" 
policy (strangely named, since it's not in fact the default). The current docs 
only say that `message_from_string()` is "equivalent to Parser().parsestr(s)." 
and that `policy` is interpreted "as with the Parser class constructor". The 
docs of the Parser constructor don't document `policy` at all, except for the 
version when it was added.

So, if you want to work for this, my suggestion would be to improve the docs in 
the following ways:

* in message_from_string() docs, explain that `policy=email.policy.default` is 
what you want to send to get the headers decoded.

* in Parser docs, explain what _class and policy arguments do in the 
constructor, which policies are possible, etc. (These things seem to be 
explained in the BytesFeedParser, so you might want to just link to that, or 
include a shortened version.)

--

___
Python tracker 

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