[issue46747] bisect.bisect/insort don't document key parameter

[Stefan Pochmann]

New submission from Stefan Pochmann :

The signatures for the versions without "_right" suffix are missing the key 
parameter:

bisect.bisect_right(a, x, lo=0, hi=len(a), *, key=None)
bisect.bisect(a, x, lo=0, hi=len(a))¶

bisect.insort_right(a, x, lo=0, hi=len(a), *, key=None)
bisect.insort(a, x, lo=0, hi=len(a))¶

https://docs.python.org/3/library/bisect.html#bisect.bisect_right
https://docs.python.org/3/library/bisect.html#bisect.insort_right

--
assignee: docs@python
components: Documentation
messages: 413213
nosy: Stefan Pochmann, docs@python
priority: normal
severity: normal
status: open
title: bisect.bisect/insort don't document key parameter
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

[issue46743] Enable usage of object.__orig_class__ in __init__

[Mehdi2277]

Mehdi2277  added the comment:

Hmm, I actually have code that does something very similar to that. But it does 
not set it in `__init__` and instead uses it in a property where it is 
available. Tweaking your code,

```py
class DefaultBox(Generic[T]):
def __init__(self, value: T | None = None):
self._default_value = value
self._value_set = False
   
 @property
 def value(self) -> T:
   if not self._value_set:
 self._value = self._default_value if self._default_value is not None 
else self.__orig_class__.__args__[0]()  

   return self._value
```

I think should work fine. Any reason initializing value afterwards is an issue? 
Or is the main goal that the original code is simpler then this lazy 
initialization workaround.

--
nosy: +med2277

___
Python tracker 

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

[issue46735] gettext.translations crashes when locale is unset

[Eric V. Smith]

Change by Eric V. Smith :


--
components: +Library (Lib) -Parser
type: crash -> behavior

___
Python tracker 

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

[issue45447] Make IDLE recognize .pyi stub files as source for open, save, and edit

[Terry J. Reedy]

Terry J. Reedy  added the comment:

Issue 46746 is the followup for browsers (currently restricted to .py files) 
and anything else.

--
title: Make IDLE recognize .pyi stub files (and .pyw) as python source -> Make 
IDLE recognize .pyi stub files as source for open, save, and edit

___
Python tracker 

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

[issue46746] IDLE: Consistently handle non .py source files

[Terry J. Reedy]

New submission from Terry J. Reedy :

Python will attempt to execute any file it can decode to unicode text as a 
startup script.  It will only import .py files as a module.  #45447 turned on 
syntax coloring for .pyi stub files.  (.pyw files and files starting with 
"!#.*python" were already recognized as source (scripts).) It also added '.pyi' 
as a possible python extension in open and save dialogs.

For this issue, fix some other modules, as appropriate, for non-.py files.

Pathbrowser: Except for the files in sys.path, pathbrowser only shows .py files 
and directories including such.  It should be easy to also list .pyw and .pyi 
files and directories.  Perhaps a button could be added to list all files.

Open Module: Opens a module when given a valid import name.  So it cannot be 
used to open non-modules, which is to say, non .py files.  .pyi files are 
condensed modules, not startup files, but opening them would require 
considerable change since the import machinery is currently used.  We could add 
a message to the box saying, "To open a non-module (non .py) file, use File => 
Open."

Modulebrowser: This was originally called Classbrowser as it only browsed 
top-level classes and their methods.  It now browses all classes and def-ined 
functions and I renamed it to indicate the expanded scope. Since it only 
browses .py files, I did not know that I was theoretically narrowing the scope 
to exclude non-.py files.

Currently, when editing a non-.py file and trying to open a module browser, a 
window is opened and nothing happens.  This is the same as with a file with no 
classes or functions.  Either browse or display an error message.  The latter 
would include files with nothing to browse.

Anything else?

--
assignee: terry.reedy
components: IDLE
messages: 413210
nosy: terry.reedy
priority: normal
severity: normal
stage: test needed
status: open
title: IDLE: Consistently handle non .py source files
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

[issue46745] Typo in new PositionsIterator

[Robert-André Mauchin]

New submission from Robert-André Mauchin :

In Objects/codeobject.c, poisitions_iterator should read positions_iterator

--
components: C API
messages: 413209
nosy: eclipseo
priority: normal
pull_requests: 29479
severity: normal
status: open
title: Typo in new PositionsIterator
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

[issue46726] Thread spuriously marked dead after interrupting a join call

[Eryk Sun]

Eryk Sun  added the comment:

> I didn't have that in mind at all.

I understood what you had in mind, and I don't disagree. I was just 
highlighting that the only somewhat important work done in _stop() is to clean 
up the _shutdown_locks set, to keep it from growing too large. But that task is 
already handled when creating a new thread, and it's arguably more important to 
handle it there.

--

___
Python tracker 

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

[issue46743] Enable usage of object.__orig_class__ in __init__

[Guido van Rossum]

Guido van Rossum  added the comment:

Thanks for the small example, I understand what you are trying to do now.

I don't think it's possible in general, since you are blindly instantiating the 
type (self.__orig_class__.__args__[0]) without arguments. That doesn't work for 
all types.

But that aside, the problem with implementing what you wish is that we would 
have to refactor class instantiation to break it in two parts, one part that 
calls __new__() and produces the instance, and one part that (if certain 
conditions are satisifed) calls __init__().

I now also understand the two code fragments you gave, and breaking the 
construction in those two parts is exactly what you are doing there.

However. The "if certain conditions are satisfied" part is complex. For 
example, self.__origin__.__new__() could return an instance of a different type 
-- if that's not a subclass of self.__origin__, the call to __init__() will be 
skipped.

There may also be other that happen between __new__() and __init__(), and other 
things may happen before __new__() or after __init__() that we would skip by 
simply calling __new__() followed by __init__() ourselves -- someone else 
should research this.

And we may have the same issue in the C code in ga_call() in 
genericaliasobject.c. (I'm not sure if that's relevant.)

I'm also not sure what static type checkers would make of this. But I presume 
you don't care about that.

--

___
Python tracker 

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

[issue46743] Enable usage of object.__orig_class__ in __init__

[Alex Waygood]

Change by Alex Waygood :


--
nosy: +AlexWaygood

___
Python tracker 

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

[issue46740] Improve Telnetlib's throughput

[Jelle Zijlstra]

Jelle Zijlstra  added the comment:

Note that telnetlib is being proposed for deprecation in PEP 594. You may be 
better off using a third-party telnet implementation; the PEP lists 
https://pypi.org/project/telnetlib3/ and https://pypi.org/project/Exscript/.

--
nosy: +Jelle Zijlstra

___
Python tracker 

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

[issue46743] Enable usage of object.__orig_class__ in __init__

[Jelle Zijlstra]

Change by Jelle Zijlstra :


--
nosy: +Jelle Zijlstra

___
Python tracker 

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

[issue46743] Enable usage of object.__orig_class__ in __init__

[Gobot1234]

Gobot1234  added the comment:

```py
class DefaultBox(Generic[T]):
def __init__(self, value: T | None = None):
self.value = (
value if value is not None else  # the arg
self.__orig_class__.__args__[0]()  # or the default for the type 
argument 
)

int_box = DefaultBox[int]()
print(int_box.value)  # should print 0
str_box = DefaultBox[str](value="this")
print(str_box.value)  # should print this
```
Currently this doesn't work, but I really think it should.

--

___
Python tracker 

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

[issue46743] Enable usage of object.__orig_class__ in __init__

[Guido van Rossum]

Guido van Rossum  added the comment:

I'm sorry, that's not a small example that I can follow, and I have no idea why 
you are doing all those things.

I fear that if you cannot be more articulate this will remain unfixed.

--

___
Python tracker 

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

[issue46726] Thread spuriously marked dead after interrupting a join call

[Tim Peters]

Tim Peters  added the comment:

> It's nice that _maintain_shutdown_locks() gets
> called in _stop(), but the more important call site is in
> _set_tstate_lock().

I didn't have that in mind at all. What at the Python level cares whether the 
thread is alive? Well. is_alive() does, and it calls _wait_for_tstate_lock() 
__repr__() does, and it calls is_alive() (which I added years ago, else repr 
could keep claiming a thread was alive weeks ;-) after it actually ended). 
join() does, and it calls _wait_for_tstate_lock().

Anything else? Not off the top of my head. The point is that if 
_wait_for_tstate_lock() fails to call _stop() for some reason when it "should 
have" called it, it's not fatal. Anything that _cares_ will call it again. 
Indeed, it was all designed so that it could be called any number of times, 
redundantly or not, and without any explicit synchronization.

For the rest, I value clarity above all else here. This code has a long history 
of being the subject of bug reports. The cost of an "extra" call to .locked() 
is just trivial, especially given that calls to _wait_for_tstate_lock() are 
typically rare.

--

___
Python tracker 

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

[issue46726] Thread spuriously marked dead after interrupting a join call

[Eryk Sun]

Eryk Sun  added the comment:

> Anything at the Python level that cares whether the thread is 
> still alive will call _wait_for_tstate_lock() again

It's nice that _maintain_shutdown_locks() gets called in _stop(), but the more 
important call site is in _set_tstate_lock().

I typed up the example initially with try/finally. Then I changed it to avoid 
the extra lock.locked() call when there's no exception, but I forgot to add a 
`raise` statement:

try:
if lock.acquire_and_release(block, timeout):
self._stop
except:
if not lock.locked():
self._stop()
raise

--

___
Python tracker 

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

[issue46743] Enable usage of object.__orig_class__ in __init__

[Gobot1234]

Gobot1234  added the comment:

Currently I have code that uses the generic argument to a class as the 
constructor for its `items` 
https://github.com/Gobot1234/steam.py/blob/f99cb77d58b552f1d493663e7b3455f94977347e/steam/trade.py#L380.
 As this is called from `BaseInventory.__init__` it currently fails if I just 
subclass `GenericAlias`, so I had to implement `__call__` myself 
https://github.com/Gobot1234/steam.py/blob/f99cb77d58b552f1d493663e7b3455f94977347e/steam/trade.py#L299-L307.

--

___
Python tracker 

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

[issue46743] Enable usage of object.__orig_class__ in __init__

[Guido van Rossum]

Guido van Rossum  added the comment:

In the early days the design and implementation were changed so many times, 
your question (why was it changed) is unanswerable.

I do not actually understand your description of your problem -- you mention so 
many dunders that it obscures your use case.

Can you provide a small example use case that demonstrates code that currently 
doesn't work but that you think ought to work, and walk us through it?

--

___
Python tracker 

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

[issue46744] installers on ARM64 suggest wrong folders

[conio]

New submission from conio :

Thank you for your work on bringing Python to Windows on ARM64.

I recently installed it an noticed some strange behaviours.

On ARM64 Windows 11 the recent prerelease (3.11.0a5, post #33125) acts in a way 
I believe is wrong: Checking the _install for all users_ checkbox causes the 
installer to suggest the `C:\Program Files (Arm)\Python311-Arm64` folder, but 
the `C:\Program Files (Arm)` is intended for ARM32 programs, similarly to how 
the `C:\Program Files (x86)` is intended for x86 programs.

The folder for programs that are native for the platform is simply `C:\Program 
Files` - which is x86 on x86 Windows, x64 on x64 Windows and ARM64 on ARM64 
Windows.

So on ARM64 Windows the ARM64 Python should go into the native Program Files 
folder which is `C:\Program Files`.

--

A closely related issue is that the installer for x64 Python wants to install 
into `C:\Program Files\Python311`, but I already installed the ARM64 version 
there.

The x86 acts as as should be expected and wants to install into `C:\Program 
Files (x86)\Python311-32`.

But there's no "Program Files (x64)", so where should the x64 version on ARM64 
machines go?

I argue that the x64 version should go into `C:\Program Files\Python311-amd64" 
while the ARM64 version should go into `C:\Program Files\Python311`, because 
the ARM64 is the native on on this platform, while the x64 is foreign, and 
should get an elaborate name, like the x86, which is also foreign, gets.

(The dotnet team also had this problem, and they decided similarly.)

Internally `sys.winver` and the PEP 514 Registry structure can say whatever you 
like, but on the filesystem it's much more appropriate for the unqualified 
folder to be the system native one.

--
components: Installation, Windows
messages: 413199
nosy: conio, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: installers on ARM64 suggest wrong folders
type: behavior
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

[issue46743] Enable usage of object.__orig_class__ in __init__

[Gobot1234]

New submission from Gobot1234 :

When using `__call__` on a `typing/types.GenericAlias` `__orig_class__` is set 
to the `GenericAlias` instance, however currently the mechanism for this does 
not allow the `__origin__` to access the `GenericAlias` from 
`__origin__.__init__` as it performs something akin to:
```py
def __call__(self, *args, **kwargs):
object = self.__origin__(*args, **kwargs)
object.__orig_class__ = self
return object
```
I'd like to propose changing this to something like:
```py
def __call__(self, *args, **kwargs):
object = self.__origin__.__new__(*args, **kwargs)
object.__orig_class__ = self
object.__init__(*args, **kwargs)
return object
```
(Ideally `__orig_class__` should also be available in `__new__` but I'm not 
entirely sure if that's possible)

AFAICT this was possible in the typing version back in 3.6 
(https://github.com/python/typing/issues/658 and maybe 
https://github.com/python/typing/issues/519). Was there a reason this was 
removed?

--
components: Library (Lib)
messages: 413198
nosy: Gobot1234, gvanrossum, kj
priority: normal
severity: normal
status: open
title: Enable usage of object.__orig_class__ in __init__
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

[issue46742] Add '-d $fd' option to trace module, akin to bash -x feature

[Charles Howes]

Change by Charles Howes :


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

___
Python tracker 

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

[issue46742] Add '-d $fd' option to trace module, akin to bash -x feature

[Charles Howes]

New submission from Charles Howes :

The 'trace' module logs trace output to stdout, intermingled with regular 
program output.  This is a problem when you want to read either the trace 
output or the normal output of the program separately.

To separate the trace output, it could be written to a file or to another file 
descriptor.

A pull request has been created that fixes this by mimicking bash's behaviour: 
bash can be told to write trace output to a different file descriptor using the 
BASH_XTRACEFD shell variable: `exec 42> xtrace.out; BASH_XTRACEFD=42; ...`

Usage of this new feature:

  python -m trace -t -d 111 your_program.py 111> /tmp/your_trace.txt

or:

  t = Trace(count=1, trace=1, trace_fd=1, countfuncs=0, countcallers=0, 
ignoremods=(), ignoredirs=(), infile=None, outfile=None, timing=False)

Notes:
* `bash -x` sends trace logs to stderr by default; `python -m trace -t` sends 
them to stdout.  I wanted to change Python to match, but was worried that this 
might break existing code.  

* Also considered writing trace logs to the file specified with the `-f FILE` 
option, but worried that it would mess up the count file if `-t` and `-c` were 
used together.

--
components: Library (Lib)
messages: 413197
nosy: PenelopeFudd
priority: normal
severity: normal
status: open
title: Add '-d $fd' option to trace module, akin to bash -x feature
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

[issue46741] Docstring for asyncio.protocols.BufferedProtocol appears out of date

[Alex Waygood]

New submission from Alex Waygood :

The docstring for asyncio.protocols.BufferedProtocol includes this paragraph:

"""
Important: this has been added to asyncio in Python 3.7
*on a provisional basis*!  Consider it as an experimental API that
might be changed or removed in Python 3.8.
"""

The main branch is now 3.11, and the class has not yet been removed, so I'm 
guessing it's now safe to say that it's here to stay?

--
assignee: docs@python
components: Documentation, asyncio
messages: 413196
nosy: AlexWaygood, asvetlov, docs@python, yselivanov
priority: normal
severity: normal
status: open
title: Docstring for asyncio.protocols.BufferedProtocol appears out of date
type: behavior
versions: Python 3.10, Python 3.11, Python 3.9

___
Python tracker 

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

[issue46740] Improve Telnetlib's throughput

[Martin Kirchgessner]

New submission from Martin Kirchgessner :

While using `telnetlib` I sometimes received unusually "large" messages (around 
1Mb) from another process on the same machine, and was surprised `read_until` 
took more than a second. After instrumenting I discovered such messages were 
received at roughly 500kbyte/s.

I think this low throughput comes from two implementation details:

 - `Telnet.fill_rawq` is calling `self.sock.recv(50)`, whereas 4096 is now 
recommended
 - the `Telnet.process_rawq` method is transferring from raw queue to cooked 
queue by appending byte per byte.

For the latter, transferring by slices looks much faster (I'm measuring at 
least 5x). I'm preparing a PR.

--
components: Library (Lib)
messages: 413195
nosy: martin_kirch
priority: normal
severity: normal
status: open
title: Improve Telnetlib's throughput
type: resource usage
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

[issue46705] Memory optimization for set.issubset

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

It will be even more efficient after applying a set.intersection() optimization 
in issue43464.

--

___
Python tracker 

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

[issue43464] set intersections should short-circuit

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

See also issue46721. set.issuperset() can get similar optimization.

And set.issubset() will benefit from this optimization if use 
set.intersection() in issue46705.

--
keywords:  -patch
stage: patch review -> 

___
Python tracker 

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

[issue43464] set intersections should short-circuit

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
keywords: +patch
nosy: +serhiy.storchaka
nosy_count: 2.0 -> 3.0
pull_requests: +29477
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31316

___
Python tracker 

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

[issue46739] dataclasses __eq__ isn't logical

[Eric V. Smith]

Change by Eric V. Smith :


--
assignee:  -> eric.smith

___
Python tracker 

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

[issue46739] dataclasses __eq__ isn't logical

[Eric V. Smith]

Eric V. Smith  added the comment:

I agree with Mark. It's identical to:

>>> () == ()
True

As for the non-dataclass version, that's a normal object identity comparison if 
no __eq__ is defined: 
https://docs.python.org/3/reference/datamodel.html#object.__eq__ , third 
paragraph.

--

___
Python tracker 

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

[issue46726] Thread spuriously marked dead after interrupting a join call

[Tim Peters]

Tim Peters  added the comment:

>> is there a bulletproof way to guarantee that `self._stop()` gets 
>> called if the acquire_and_release() succeeds? 

> I don't think it's critical.

Agreed! Anything at the Python level that cares whether the thread is still 
alive will call _wait_for_tstate_lock() again, and get another chance each time 
to notice that the tstate lock has been freed.

Instead of:

try:
if lock.acquire_and_release(block, timeout):
self._stop
except:
if not lock.locked():
self._stop()

I'd prefer:

try:
lock.acquire_and_release(block, timeout)
finally:
if not lock.locked():
self._stop()

Because, at the Python level, whether acquire_and_release() succeeded at its 
task depends entirely on whether the lock is free afterward. That's what we're 
_really_ looking for, and is so on all possible platforms.

--

___
Python tracker 

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

[issue46733] pathlib.Path methods can raise NotImplementedError

[Éric Araujo]

Change by Éric Araujo :


--
nosy: +eric.araujo, pitrou, serhiy.storchaka

___
Python tracker 

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

[issue46739] dataclasses __eq__ isn't logical

[Mark Dickinson]

Mark Dickinson  added the comment:

Can you explain why you think the result of `a == b` should be `False` rather 
than `True`? By default, equality for dataclasses is structural equality, and 
`True` is the result that I'd expect here.

>From the 
>[docs](https://docs.python.org/3/library/dataclasses.html#dataclasses.dataclass)
> for `eq`: 

> If true (the default), an __eq__() method will be generated. This method 
> compares the class as if it were a tuple of its fields, in order

--
nosy: +mark.dickinson

___
Python tracker 

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

[issue46739] dataclasses __eq__ isn't logical

[Alex Waygood]

Change by Alex Waygood :


--
nosy: +eric.smith

___
Python tracker 

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

[issue46716] regrtest didn't respect the timeout when running test_subprocess on AMD64 Windows11 3.x

[Jeremy Kloth]

Jeremy Kloth  added the comment:

> > the fix should be as simple as coercing the timeout values to >= 0.
>
> Popen._remaining_time() should return max(endtime - _time(), 0).

That was my first initial instinct as well, however, that change would
also affect more of the Popen behavior and need a much more thorough
investigation of the POSIX side of Popen.

> Popen._wait() should raise OverflowError if the timeout is too large for the 
> implementation. In Windows, the upper limit in milliseconds is 
> `_winapi.INFINITE - 1` (about 49.7 days). It's important to only allow the 
> timeout in milliseconds to be _winapi.INFINITE when `timeout is None`.

I agree.

> The DWORD converter in _winapi needs to subclass unsigned_long_converter. The 
> current implementation based on the legacy format unit "k" is too lenient. 
> Negative values and values that are too large should fail.

Whilst I agree this is a correct solution, I fear the potential
3rd-party breakage alone should bump this to its own issue.

I believe that this then leads to the following action items for this issue:
1) modify Windows Popen._wait() to raise on out of bounds values [< 0
or >= INFINITE]
2) cap Popen._remaining_time() return value to >= 0
3) change _winapi DWORD converter be unsigned long
4) use Job objects to group Windows processes for termination

Have I missed anything?  I should be able to knock out PRs for these today.
-- 
Jeremy Kloth

--
nosy: +jeremy.kloth

___
Python tracker 

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

[issue46739] dataclasses __eq__ isn't logical

[Craig Coleman]

New submission from Craig Coleman :

In a test, dataclasses generate an __eq__ function appears to be wrong.

@dataclass 
class C:
pass

class K:
pass

a = C()
b = C()
c = K()
d = K()

(a is b) # False
(a == b) # True # Incorrect, Why?
(c is d) # False
(c == d) # False # Correct

Using @dataclass(eq = False) for annotation of C would make (a == b) == False 
which I think is correct behaviour.

--
components: Library (Lib)
messages: 413188
nosy: ccoleman
priority: normal
severity: normal
status: open
title: dataclasses __eq__ isn't logical
type: behavior
versions: Python 3.7, Python 3.8

___
Python tracker 

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

[issue46622] Support decorating a coroutine with functools.cached_property

[Andrew Svetlov]

Andrew Svetlov  added the comment:

I have a design question.
Does `print(await a.hello)` look awkward?
I'm not speaking about correction.

In asyncio code I have seen before, `await val` means waiting for a future 
object. `await func()` means async function call.

`await obj.attr` looks more like a future waiting but, in fact, it is not.
Should we encourage such syntax?
I have no strong opinion here and like to hear other devs.

--

___
Python tracker 

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

[issue45976] Random._randbelow() loses time by caching an attribute lookup

[Raymond Hettinger]

Raymond Hettinger  added the comment:

I'm thinking that we care more about the unhappy cases (the extreme values) 
than we care about a mild and implementation dependent improvement to the 
average case.

--
resolution: later -> rejected

___
Python tracker 

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

[issue46586] In documentation contents enum.property erroneously links to built-in property

[Meer Suri]

Meer Suri  added the comment:

Looks like another one - 
https://docs.python.org/3.11/library/fileinput.html#fileinput.hook_encoded

Deprecated since version 3.10: This function is deprecated since input() and 
FileInput now have encoding and errors parameters.

The input() here points to builtins which doesnt have the mentioned parameters

--

___
Python tracker 

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

[issue46737] Default to the standard normal distribution

[Mark Dickinson]

Mark Dickinson  added the comment:

+1

--
nosy: +mark.dickinson

___
Python tracker 

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

[issue46735] gettext.translations crashes when locale is unset

[Pablo Galindo Salgado]

Change by Pablo Galindo Salgado :


--
nosy:  -pablogsal

___
Python tracker 

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

[issue46586] In documentation contents enum.property erroneously links to built-in property

[Meer Suri]

Meer Suri  added the comment:

Also this one?- 

https://docs.python.org/3.11/library/urllib.request.html?highlight=urllib%20request#urllib.request.OpenerDirector.open

Arguments, return values and exceptions raised are the same as those of 
urlopen() (which simply calls the open() method on the currently installed 
global OpenerDirector).

open() points to the builtins function but the markup used is :meth:`open` and 
the logic of the sentence suggests the link was meant to be to 
OpenerDirector.open()

--

___
Python tracker 

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

[issue39805] Copying functions doesn't actually copy them

[Numerlor]

Numerlor  added the comment:

Having copy be an identity function for anything mutable seems very bug prone, 
even if it's functions. If not changed in the copy interface I would say that 
at least a warning would be helpful.

--

___
Python tracker 

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

[issue46586] In documentation contents enum.property erroneously links to built-in property

[Meer Suri]

Meer Suri  added the comment:

Thanks Jelle for the cool idea of the script to look for more instances of this 
problem. I've been working on this script and am still refining it, but one of 
the candidates that my program returned is in zipfile.rst - 
https://docs.python.org/3.11/library/zipfile.html?highlight=zipfile#zipfile.ZipFile.open
 

Changed in version 3.6: open() can now be used to write files into the archive 
with the mode='w' option.
Changed in version 3.6: Calling open() on a closed ZipFile will raise a 
ValueError. Previously, a RuntimeError was raised.

Here the first instance of open() points to the builtins function rather than 
ZipFile.open(), whereas the second instance points to ZipFile.open(). Seems 
like a true positive to me, what do you think?

--

___
Python tracker 

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

[issue46622] Support decorating a coroutine with functools.cached_property

[Tzu-ping Chung]

Change by Tzu-ping Chung :


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

___
Python tracker 

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

[issue39805] Copying functions doesn't actually copy them

[Steven D'Aprano]

Steven D'Aprano  added the comment:

If we can't change the default behaviour of copying functions, can we 
add a specialised copy_function() function, for when we really need to 
make a genuine copy?

--

___
Python tracker 

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

[issue46738] Allow http.server to emit HTML 5

[Tzu-ping Chung]

New submission from Tzu-ping Chung :

Currently, a directory listing page emitted by http.parser uses the HTML 4.01 
doctype. While this is perfectly fine for most uses, the server tool is 
sometimes used for things that require another doctype; PEP 503[1], for 
example, requires an HTML 5 document.

>From what I can tell, http.parser is already emitting a valid HTML 5 page, so 
>it should be possible to simply change the doctype declaration. Or, if 
>backward compatibility is paramount, this could live behind a --doctype flag 
>as well. If we go the latter route, more doctypes (e.g. XHTML) could 
>potentially be supported as well with minimal modification.

[1]: https://www.python.org/dev/peps/pep-0503/

--
components: Library (Lib)
messages: 413179
nosy: uranusjr
priority: normal
severity: normal
status: open
title: Allow http.server to emit HTML 5

___
Python tracker 

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

[issue39805] Copying functions doesn't actually copy them

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

It is by design. Functions and types are pickled by name. The copy module uses 
the pickling protocol and only use different methods for performance or for 
non-pickleable objects. Changing this will break existing code.

--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue46737] Default to the standard normal distribution

[Raymond Hettinger]

New submission from Raymond Hettinger :

This is really minor, but it would convenient if we provided default arguments:

random.gauss(mu=0.0, sigma=1.0)
random.normalvariate(mu=0.0, sigma=1.0)

--
components: Library (Lib)
messages: 413177
nosy: rhettinger
priority: normal
severity: normal
status: open
title: Default to the standard normal distribution
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

[issue46615] Use-after-free by mutating set during set operations

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Thanks Dennis for your report and PRs.

Do you mind to analyze also uses of _PySet_NextEntry(), PyDict_Next() and 
_PyDict_Next()? Many of them look safe, but _pickle.c seems vulnerable.

--

___
Python tracker 

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

[issue46615] Use-after-free by mutating set during set operations

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:


New changeset c31b8a97a8a7e8255231c9e12ed581c6240c0d6c by Dennis Sweeney in 
branch '3.9':
bpo-46615: Don't crash when set operations mutate the sets (GH-31120) (GH-31312)
https://github.com/python/cpython/commit/c31b8a97a8a7e8255231c9e12ed581c6240c0d6c


--

___
Python tracker 

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

[issue46726] Thread spuriously marked dead after interrupting a join call

[Eryk Sun]

Eryk Sun  added the comment:

> is there a bulletproof way to guarantee that `self._stop()` gets 
> called if the acquire_and_release() succeeds? 

I don't think it's critical. But we still should deal with the common case in 
Windows in which a KeyboardInterrupt is raised immediately after the method 
returns. For example:

try:
if lock.acquire_and_release(block, timeout):
self._stop
except:
if not lock.locked():
self._stop()

The proposed acquire_and_release() method can also be used in 
threading._shutdown(), when it iterates _shutdown_locks to join non-daemon 
threads.

--

___
Python tracker 

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

[issue46736] Generate HTML 5 with SimpleHTTPRequestHandler.list_directory

[Dominic Davis-Foster]

New submission from Dominic Davis-Foster :

Currently SimpleHTTPRequestHandler.list_directory (which is used with `python3 
-m http.server` amongst other things) generates HTML with the doctype:

http://www.w3.org/TR/html4/strict.dtd;>

i.e. HTML 4.01.


I propose making the generated page HTML 5 instead. The only necessary change 
is in the doctype; the rest of the page is valid already. HTML 5 has been 
supported by Chrome, Firefox, Safari and Opera since 2013, and Edge since 2015 
so there shouldn't be any issues with browser compatibility.

The generated page has been HTML 4.01 since https://bugs.python.org/issue13295 
in 2011, where it was originally proposed to switch to HTML 5.


Switching to HTML 5 would also allow http.server to be used to serve a simple 
index for pip that's compliant with PEP 503.

There's some discussion in https://github.com/pypa/pip/issues/10825

--
components: Library (Lib)
messages: 413173
nosy: dom1310df
priority: normal
severity: normal
status: open
title: Generate HTML 5 with SimpleHTTPRequestHandler.list_directory
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

[issue46716] regrtest didn't respect the timeout when running test_subprocess on AMD64 Windows11 3.x

[Eryk Sun]

Eryk Sun  added the comment:

> the fix should be as simple as coercing the timeout values to >= 0.

Popen._remaining_time() should return max(endtime - _time(), 0).

Popen._wait() should raise OverflowError if the timeout is too large for the 
implementation. In Windows, the upper limit in milliseconds is 
`_winapi.INFINITE - 1` (about 49.7 days). It's important to only allow the 
timeout in milliseconds to be _winapi.INFINITE when `timeout is None`.

The DWORD converter in _winapi needs to subclass unsigned_long_converter. The 
current implementation based on the legacy format unit "k" is too lenient. 
Negative values and values that are too large should fail. I updated it to use 
the following definition:

class DWORD_converter(unsigned_long_converter):
type = 'DWORD'

This produces the following improved results:

>>> h = _winapi.GetCurrentProcess()
>>> _winapi.WaitForSingleObject(h, _winapi.INFINITE + 1)
Traceback (most recent call last):
  File "", line 1, in 
OverflowError: Python int too large to convert to C unsigned long

>>> _winapi.WaitForSingleObject(h, -1)
Traceback (most recent call last):
  File "", line 1, in 
ValueError: value must be positive

--

___
Python tracker 

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