[issue39110] UserList-subclass Tree slicing changes the original list unexpectedly

[Tarn Yeong Ching]

Tarn Yeong Ching  added the comment:

and more... It doesn't happen when Tree directly subclasses list.

--

___
Python tracker 

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

[issue39110] UserList-subclass Tree slicing changes the original list unexpectedly

[ctarn]

ctarn  added the comment:

Moreover, it works as expected with Python 3.6 (the owner of each of them is 
d), and Python 3.8 and Python 3.7 work differently.
I didn't try it using Python 3.9 yet.

--
versions: +Python 3.7 -Python 3.9

___
Python tracker 

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

[issue39110] UserList-subclass Tree slicing changes the original list unexpectedly

[ctarn]

Change by ctarn :


Removed file: https://bugs.python.org/file48797/bug.py

___
Python tracker 

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

[issue39110] UserList-subclass Tree slicing changes the original list unexpectedly

[ctarn]

ctarn  added the comment:

I tried to remove list(), and just use cmd like `_ = d[0:1]`, and it 
surprisingly changed d[0].owner from d to d[0:1]!
The file attached is updated.
I pretty sure that it is a (serious) bug. Please check it more carefully. 
Thanks.

--
title: UserList-subclass Tree slicing changes node attribute -> 
UserList-subclass Tree slicing changes the original list unexpectedly
Added file: https://bugs.python.org/file48799/bug.py

___
Python tracker 

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

[issue39113] PyUnicode_AsUTF8AndSize Sometimes Segfaults With Incomplete Surrogate Pair

[william.ayd]

william.ayd  added the comment:

Hmm my mistake - thanks!

--

___
Python tracker 

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

[issue24945] Expose Py_TPFLAGS_ values from Python

[Batuhan]

Batuhan  added the comment:

IMHO inspect would be a better place to put these constants (like CO_ flags).

--
nosy: +BTaskaya
versions: +Python 3.9 -Python 3.6

___
Python tracker 

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

[issue13047] imp.find_module("") and imp.find_module(".")

[Batuhan]

Batuhan  added the comment:

`imp` is now deprecated and IMHO no reason to make this change after this 
deprecation.

--
nosy: +BTaskaya

___
Python tracker 

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

[issue36051] Drop the GIL during large bytes.join operations?

[Batuhan]

Change by Batuhan :


--
versions: +Python 3.9 -Python 3.8

___
Python tracker 

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

[issue36051] Drop the GIL during large bytes.join operations?

[Batuhan]

Change by Batuhan :


--
nosy: +BTaskaya, vstinner

___
Python tracker 

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

[issue33772] Fix few dead code paths

[Batuhan]

Batuhan  added the comment:

I agree, can be closed

--
nosy: +BTaskaya

___
Python tracker 

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

[issue39106] Add suggestions to argparse error message output for unrecognized arguments

[Raymond Hettinger]

Raymond Hettinger  added the comment:

-1  Given an unknown argument, we really can't know what the user intended.  
The usage string already lists all available options and -h --help gives more 
detail when requested.

--

___
Python tracker 

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

[issue39113] PyUnicode_AsUTF8AndSize Sometimes Segfaults With Incomplete Surrogate Pair

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Your function returns a borrowed reference. It xiuld cause  ceash even without 
calling PyUnicode_AsUTF8AndSize. Add Py_INCREF(str)

--
nosy: +serhiy.storchaka
resolution:  -> not a bug

___
Python tracker 

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

[issue39110] UserList-subclass Tree slicing changes node attribute

[ctarn]

Change by ctarn :


--
resolution: not a bug -> 

___
Python tracker 

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

[issue39110] UserList-subclass Tree slicing changes node attribute

[ctarn]

ctarn  added the comment:

Sorry but it is not. See the first time I print ls[4].owner. We get d as 
expected, not a slice of d, that is, d[0:2].

However the next time we print it after _ = list(d[0:1]), noticed that ls[4] == 
d[0:1], we get d[0:1], it’s extremely surprising!!!

I have to highlight it: we just print *.owner before and after `_ = 
list(d[0:1])`, and the results are different!!!

The latest 3 lines show more strange results.

By the way, it’s my first time to report bug, and I don’t know what is 
discussion list, and reopened the issue. Thank you.

--
status: closed -> open

___
Python tracker 

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

[issue39113] PyUnicode_AsUTF8AndSize Sometimes Segfaults With Incomplete Surrogate Pair

[william.ayd]

New submission from william.ayd :

With the attached extension module, if I run the following in the REPL:

>>> import libtest
>>>
>>> libtest.error_if_not_utf8("foo")
'foo'
>>> libtest.error_if_not_utf8("\ud83d")
Traceback (most recent call last):
  File "", line 1, in 
UnicodeEncodeError: 'utf-8' codec can't encode character '\ud83d' in position 
0: surrogates not allowed
>>> libtest.error_if_not_utf8("foo")
'foo'

Things seem OK. But the next invocation of

>>> libtest.error_if_not_utf8("\ud83d")

Then causes a segfault. Note that the order of the input seems important; 
simply repeating the call with the invalid surrogate doesn't cause the segfault

--
files: testmodule.c
messages: 358755
nosy: william.ayd
priority: normal
severity: normal
status: open
title: PyUnicode_AsUTF8AndSize Sometimes Segfaults With Incomplete Surrogate 
Pair
Added file: https://bugs.python.org/file48798/testmodule.c

___
Python tracker 

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

[issue39108] random needs doc for "gauss" versus "normalvariate"

[Raymond Hettinger]

Raymond Hettinger  added the comment:

I can make the update for you.

--
assignee: docs@python -> rhettinger

___
Python tracker 

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

[issue39112] Misleading documentation for tuple

[Simon Berens]

New submission from Simon Berens :

Sorry if this is a silly question (my first bug report), but it seems that 
https://docs.python.org/3/library/functions.html#func-tuple
should say "class tuple" instead of just "tuple", as list, dict, and set do.

--
assignee: docs@python
components: Documentation
messages: 358753
nosy: docs@python, sberens
priority: normal
severity: normal
status: open
title: Misleading documentation for tuple
type: enhancement
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

___
Python tracker 

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

[issue39111] Misleading documentation for NotImplemented

[Steven D'Aprano]

Change by Steven D'Aprano :


--
title: Misleading documentation -> Misleading documentation for NotImplemented

___
Python tracker 

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

[issue39111] Misleading documentation

[Steven D'Aprano]

Steven D'Aprano  added the comment:

The behaviour is correct: `==` should not raise, even if both objects' `__eq__` 
method returns NotImplemented.

I agree that the documentation needs improvement. Looking at the current 
version:

https://docs.python.org/3/library/constants.html#NotImplemented

it says:

Note: When a binary (or in-place) method returns NotImplemented 
the interpreter will try the reflected operation on the other 
type (or some other fallback, depending on the operator). If all
attempts return NotImplemented, the interpreter will raise an
appropriate exception. Incorrectly returning NotImplemented will
result in a misleading error message or the NotImplemented value
being returned to Python code.


(1) In the case of `==` and `!=`, an exception is not raised even all relevant 
methods return NotImplemented.

The source code for PyObject_RichCompare in object.c says:

/* If neither object implements it, provide a sensible default
   for == and !=, but raise an exception for ordering. */

and then falls back to object identity.

If we wanted to lawyer up, the current docs don't say that "some other 
fallback" is limited to Python dunder methods. But that's the strong impression 
it gives, and it is actively misleading in that there's no hint that the 
fallback includes a default notion of equality as object identity, built right 
into the interpreter itself.

Even Brett got this wrong: object.__eq__ can return NotImplemented, so it isn't 
a suitable final fallback:

py> object.__eq__(o, None)
NotImplemented


so I think these docs could do with some improvement. Based on the current 
docs, I too would expect equality to raise an exception for a class that 
defines `__eq__`  and `__ne__` to always return NotImplemented.


(2) The last sentence, about "incorrectly returning NotImplemented", confuses 
me. Why are we warning about that? If you incorrectly return any value, whether 
it is NotImplemented, True, False, None or 3.1415, it will result in a 
misleading error message or incorrect value being returned.

Is it perhaps meant to say "incorrectly *raising* NotImplemented"?

I'm reopening this for a doc enhancement. Unfortunately I can't use github for 
technical reasons, so can't do a PR, but I'll suggest an updated description 
for the first part. (I have no idea what to do for the second part.)

When a binary (or in-place) method returns NotImplemented 
the interpreter will try the reflected operation on the other 
type (or some other fallback, depending on the operator). If all
attempts return NotImplemented, the interpreter will fall back
to object identity for `==` and `!=` or raise an appropriate
exception for all other comparisons.

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

___
Python tracker 

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

[issue36476] Runtime finalization assumes all other threads have exited.

[Eric Snow]

Eric Snow  added the comment:

So I see 3 things to address here:

1. Python daemon threads
2. Python threads created in atexit handlers
3. non-Python threads accessing the C-API

Possible solutions (starting point for discussion):

1. stop them at the point we stop waiting for non-daemon threads (at the 
beginning of finalization)
2. disallow them?  do one more pass of wait-for-threads?
3. cause all (external) attempts to access the C-API to fail once finalization 
begins

Regarding daemon threads, the docs already say "Daemon threads are abruptly 
stopped at shutdown." [1]  So let's force them to stop.  Can we do that?  If we 
*can* simply kill the threads, can we do so without leaking resources?  
Regardless, the mechanism we currently use (check for finalizing each(?) time 
through the eval loop) mostly works fine.  The problem is when C code called 
from Python in a daemon thread blocks long enough that it makes C-API calls (or 
even the eval loop) *after* we've started cleaning up the runtime state.  So if 
there was a way to interrupt that blocking code, that would probably be good 
enough.

The other two possible solutions are, I suppose, a bit more drastic.  What are 
the alternatives?


[1] https://docs.python.org/3/library/threading.html#thread-objects

--
nosy: +nanjekyejoannah, ncoghlan, pablogsal, pitrou, tim.peters, vstinner

___
Python tracker 

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

[issue36476] Runtime finalization assumes all other threads have exited.

[Eric Snow]

Eric Snow  added the comment:

To put it another way:

(from issue33608#msg358748)

> The docs [1] aren't super clear about it, but there are some fundamental
> assumptions we make about runtime finalization:
>
> * no use of the C-API while Py_FinalizeEx() is executing (except for a
> few helpers like Py_Initialized)
> * only a small portion of the C-API is available afterward (at least
> until Py_Initialize() is run)
>
> I guess the real question is what to do about this?
> 
>[1] https://docs.python.org/3/c-api/init.html#c.Py_FinalizeEx

Adding to that list:

* no other Python threads are running once we start finalizing the runtime (not 
far into Py_FinalizeEx())

--

___
Python tracker 

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

[issue36476] Runtime finalization assumes all other threads have exited.

[Eric Snow]

Eric Snow  added the comment:

Analysis by @pconnell:

* https://bugs.python.org/issue33608#msg357169
* https://bugs.python.org/issue33608#msg357170
* https://bugs.python.org/issue33608#msg357179

tl;dr daemon threads and external C-API access during/after runtime 
finalization are causing crashes.

--

___
Python tracker 

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

[issue33608] Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed.

[Eric Snow]

Eric Snow  added the comment:

Thanks for the detailed analysis, Phil.  I think the results are pretty 
conclusive: daemon threads are the worst. :)  But seriously, thanks.

As you demonstrated, it isn't just Python "daemon" threads that cause the 
problem.  It is essentially any external access of the C-API once runtime 
finalization has started.  The docs [1] aren't super clear about it, but there 
are some fundamental assumptions we make about runtime finalization:

* no use of the C-API while Py_FinalizeEx() is executing (except for a few 
helpers like Py_Initialized)
* only a small portion of the C-API is available afterward (at least until 
Py_Initialize() is run)

I guess the real question is what to do about this?

Given that this is essentially a separate problem, let's move further 
discussion and effort over related to sorting out problematic threads to 
#36476, "Runtime finalization assumes all other threads have exited."  @Phil, 
would you mind attaching those same two files to that issue?


[1] https://docs.python.org/3/c-api/init.html#c.Py_FinalizeEx

--

___
Python tracker 

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

[issue36476] Runtime finalization assumes all other threads have exited.

[Eric Snow]

Change by Eric Snow :


--
nosy: +pconnell

___
Python tracker 

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

[issue36476] Runtime finalization assumes all other threads have exited.

[Eric Snow]

Eric Snow  added the comment:

Problems with lingering threads during/after runtime finalization continue to 
be a problem.  I'm going to use this issue as the focal point for efforts to 
resolve this.


Related issues:
* #36479 "Exit threads when interpreter is finalizing rather than runtime."
* #24770 "Py_Finalize() doesn't stop daemon threads"
* #23592 "SIGSEGV on interpreter shutdown, with daemon threads running wild"
* #37127 "Handling pending calls during runtime finalization may cause 
problems."
* #33608 "Add a cross-interpreter-safe mechanism to indicate that an object may 
be destroyed."
* #36818 "Add PyInterpreterState.runtime."
* #36724 "Clear _PyRuntime at exit"
* #14073 "allow per-thread atexit()"
* #1596321 "KeyError at exit after 'import threading' in other thread"
* #37266 "Daemon threads must be forbidden in subinterpreters"
* #31517 "MainThread association logic is fragile"

--

___
Python tracker 

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

[issue24770] Py_Finalize() doesn't stop daemon threads

[Eric Snow]

Eric Snow  added the comment:

I'm closing this in favor of #36476 "Runtime finalization assumes all other 
threads have exited."

--
nosy: +eric.snow
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Runtime finalization assumes all other threads have exited.
versions: +Python 3.8, Python 3.9 -Python 3.6

___
Python tracker 

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

[issue36476] Runtime finalization assumes all other threads have exited.

[Eric Snow]

Change by Eric Snow :


--
stage:  -> needs patch
versions: +Python 3.9 -Python 3.7

___
Python tracker 

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

[issue36476] Runtime finalization assumes all other threads have exited.

[Eric Snow]

Eric Snow  added the comment:

Adding to the list:

* any OS threads created by an extension module or embedding application

--

___
Python tracker 

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

[issue13077] Unclear behavior of daemon threads on main thread exit

[Eric Snow]

Change by Eric Snow :


--
nosy: +eric.snow

___
Python tracker 

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

[issue34296] Speed up python startup by pre-warming the vm

[Eric Snow]

Change by Eric Snow :


--
nosy: +eric.snow

___
Python tracker 

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

[issue31517] MainThread association logic is fragile

[Eric Snow]

Eric Snow  added the comment:

probably a duplicate: issue #39042 "Use the runtime's main thread ID in the 
threading module."

--

___
Python tracker 

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

[issue14073] allow per-thread atexit()

[Eric Snow]

Change by Eric Snow :


--
nosy: +eric.snow

___
Python tracker 

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

[issue28812] Deadlock between GIL and pystate head_mutex.

[Eric Snow]

Change by Eric Snow :


--
nosy: +eric.snow

___
Python tracker 

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

[issue1332869] Fatal Python error: Interpreter not initialized

[Eric Snow]

Change by Eric Snow :


--
nosy: +eric.snow

___
Python tracker 

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

[issue1596321] KeyError at exit after 'import threading' in other thread

[Eric Snow]

Eric Snow  added the comment:

related: issue #39042 "Use the runtime's main thread ID in the threading 
module."

--
nosy: +eric.snow

___
Python tracker 

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

[issue39102] Increase Enum performance

[Arseny Boykov]

Arseny Boykov  added the comment:

Also, do we need to leave compatibility with python <3.8? 
If not, we could use the fact that python 3.8 dicts and sets which are preserve 
order to speed things up even more. Also I'd replace % string formatting with 
f-strings, as they also faster.

And another thing to think about: maybe we can calculate values returned by 
__str__, __repr__ and __invert__ once on member creation, since they not 
supposed to change during its life?

For example __invert__ on Flag does a lot of work on every call:
def __invert__(self):
cls = self.__class__
members, uncovered = _decompose(cls, self._value_)
inverted = cls(0)
for m in cls:
if m not in members and not (m._value_ & self._value_):
inverted = inverted | m
return cls(inverted)

--

___
Python tracker 

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

[issue39110] UserList-subclass Tree slicing changes node attribute

[Terry J. Reedy]

Terry J. Reedy  added the comment:

(ctarn), if you want to discuss what you are doing further, please try a 
discussion list, such as python-list.

--
nosy: +terry.reedy

___
Python tracker 

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

[issue39110] UserList-subclass Tree slicing changes node attribute

[Terry J. Reedy]

Change by Terry J. Reedy :


--
stage:  -> resolved
status: pending -> closed

___
Python tracker 

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

[issue39110] UserList-subclass Tree slicing changes node attribute

[Terry J. Reedy]

Change by Terry J. Reedy :


--
status: open -> pending

___
Python tracker 

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

[issue39110] UserList-subclass Tree slicing changes node attribute

[Terry J. Reedy]

Change by Terry J. Reedy :


--
status: pending -> open
title: It seems that list() changes the value of the parameter -> 
UserList-subclass Tree slicing changes node attribute

___
Python tracker 

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

[issue39108] random needs doc for "gauss" versus "normalvariate"

[Terry J. Reedy]

Terry J. Reedy  added the comment:

You could start by posting suggested new text here.

--
nosy: +terry.reedy
title: Documentation for "random.gauss" vs "random.normalvariate" is lacking -> 
random needs doc for "gauss" versus "normalvariate"
versions:  -Python 3.5, Python 3.6

___
Python tracker 

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

[issue39102] Increase Enum performance

[Terry J. Reedy]

Change by Terry J. Reedy :


--
versions:  -Python 3.6, 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

[issue39098] OSError: handle closed, ProcessPoolExecutor shutdown(wait=False)

[Terry J. Reedy]

Change by Terry J. Reedy :


--
title: OSError: handle is closed in ProcessPoolExecutor  on 
shutdown(wait=False) -> OSError: handle closed, ProcessPoolExecutor 
shutdown(wait=False)

___
Python tracker 

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

[issue39096] "Format Specification Mini-Language" doc mistake for Decimal

[Terry J. Reedy]

Change by Terry J. Reedy :


--
title: Description of "Format Specification Mini-Language" not accurate for 
Decimal -> "Format Specification Mini-Language" doc mistake for Decimal

___
Python tracker 

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

[issue39062] ValueError in TarFile.getmembers

[Terry J. Reedy]

Terry J. Reedy  added the comment:

jvoisin, please consider rerunning such reproducers with lastest 3.8 and 3.9 
before submitting.  It is much easier for you to do so when you have the fuzz 
file, script, and command line already present.

--

___
Python tracker 

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

[issue39062] ValueError in TarFile.getmembers

[Terry J. Reedy]

Terry J. Reedy  added the comment:

jvoisin, what do you consider to be the bug?  Raising an exception  is exactly 
the right thing to do on bad input.  I leave it to others to decide if this 
should be closed as 'not a bug' or if the internal exception should be caught 
and replaced.  We don't pretend to document all possible exception from all 
functions.

The more important aim of fuzzing is to find inputs that cause no-exception 
crashes.

--

___
Python tracker 

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

[issue39062] ValueError in TarFile.getmembers

[Terry J. Reedy]

Terry J. Reedy  added the comment:

See #39065, #39067 for similar tarfile issues.

--
nosy: +terry.reedy

___
Python tracker 

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

[issue39062] ValueError in TarFile.getmembers

[Terry J. Reedy]

Change by Terry J. Reedy :


--
nosy: +lars.gustaebel, serhiy.storchaka

___
Python tracker 

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

[issue39060] asyncio.Task.print_stack doesn't print the full stack

[Terry J. Reedy]

Terry J. Reedy  added the comment:

Amit, is there a simple doc change that would have made the result clearer? 
(before getting Andrew's response?)

--
nosy: +terry.reedy
versions: +Python 3.8, Python 3.9

___
Python tracker 

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

[issue39048] Reorder __aenter__ & __aexit__ checks for async with statement

[Terry J. Reedy]

Change by Terry J. Reedy :


--
title: Reorder the __aenter__ and __aexit__ method checks for the async with 
statement -> Reorder  __aenter__ & __aexit__ checks for async with statement
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

[issue13305] datetime.strftime("%Y") not consistent for years < 1000

[Paul Ganssle]

Change by Paul Ganssle :


--
versions: +Python 3.7, Python 3.8, Python 3.9 -Python 3.6

___
Python tracker 

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

[issue39103] [linux] strftime renders %Y with only 3 characters

[Paul Ganssle]

Paul Ganssle  added the comment:

This is a duplicate of issue 13305.

Right now we have some shims around `strftime` to improve consistency in some 
situations and for other reasons, but mostly we just call the libc version.

There is an open issue from 2008 (#3173) to ship our own implementation of 
strftime that could smooth out some of these issues and try and make the 
behavior more consistent (though presumably some people have started to rely on 
platform-specific behaviors by now, so it may be a decent amount of work to 
roll it out).

I'm going to close this in favor of 13305, but thanks for reporting it!

--
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> datetime.strftime("%Y") not consistent for years < 1000
type:  -> behavior

___
Python tracker 

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

[issue38918] Add __module__ entry for function type in inspect docs table.

[Eric Snow]

Eric Snow  added the comment:

Thanks for working on this, @parthsharma2!

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

[issue38918] Add __module__ entry for function type in inspect docs table.

[miss-islington]

miss-islington  added the comment:


New changeset 44683bbc634bd007df572dce0d8bb348a469a6bb by Miss Islington (bot) 
in branch '3.8':
bpo-38918: Add __module__ entry for function & method type in inspect docs 
table (GH-17408)
https://github.com/python/cpython/commit/44683bbc634bd007df572dce0d8bb348a469a6bb


--

___
Python tracker 

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

[issue38918] Add __module__ entry for function type in inspect docs table.

[miss-islington]

miss-islington  added the comment:


New changeset 0ffc90031cadf5637cfc13a40899e71c259c49b1 by Miss Islington (bot) 
in branch '3.7':
bpo-38918: Add __module__ entry for function & method type in inspect docs 
table (GH-17408)
https://github.com/python/cpython/commit/0ffc90031cadf5637cfc13a40899e71c259c49b1


--

___
Python tracker 

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

[issue38918] Add __module__ entry for function type in inspect docs table.

[miss-islington]

Change by miss-islington :


--
pull_requests: +17136
pull_request: https://github.com/python/cpython/pull/17676

___
Python tracker 

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

[issue38918] Add __module__ entry for function type in inspect docs table.

[miss-islington]

Change by miss-islington :


--
pull_requests: +17135
pull_request: https://github.com/python/cpython/pull/17675

___
Python tracker 

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

[issue23868] Uninitialized objects are tracked by the garbage collector

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

In summary, a normal allocation for an object tracked by the Garbage collector 
follows these steps:

1.- Call PyObject_GC_New or PyObject_GC_NewVar or related APIs.
2.- Initialize everything and make sure the object is consistent.
3.- Call PyObject_GC_Track

You can check the implementation of containers types in the stdlib for 
reference or the documentation for the C API.

Closing this, feel free to reopen of you think there is something missing.

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

[issue38918] Add __module__ entry for function type in inspect docs table.

[miss-islington]

miss-islington  added the comment:


New changeset f522a6ddb67a238bab5673608111f74ec4e22205 by Miss Islington (bot) 
(Parth Sharma) in branch 'master':
bpo-38918: Add __module__ entry for function & method type in inspect docs 
table (GH-17408)
https://github.com/python/cpython/commit/f522a6ddb67a238bab5673608111f74ec4e22205


--
nosy: +miss-islington

___
Python tracker 

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

[issue23868] Uninitialized objects are tracked by the garbage collector

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

If I understand what you say correctly, it does not seem correct, the object 
will only be tracked by the collector when you call PyObject_GC_Track. indeed, 
the documentation warns about this:

void PyObject_GC_Track(PyObject *op)¶
Adds the object op to the set of container objects tracked by the collector. 
The collector can run at unexpected times so objects must be valid while being 
tracked. This should be called once all the fields followed by the tp_traverse 
handler become valid, usually near the end of the constructor.

--

___
Python tracker 

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

[issue26845] Misleading variable name in exception handling

[STINNER Victor]

STINNER Victor  added the comment:

Variable names have no impact on the execution. Sometimes, it's called "exc", 
sometimes "val", sometimes "exc_val" :-) This issue is not a bug.

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

[issue39042] Use the runtime's main thread ID in the threading module.

[Eric Snow]

Eric Snow  added the comment:

I don't see a reason not to consider this is a regression.

The only problem with the fix would be for any users that rely on the 
inaccurate reporting of the threading module.  Considering that possibly 
includes only some embedders (and folks using _thread module directly), I 
expect the impact would be extremely small.  A porting entry in the whats-new 
doc.

--
keywords: +3.8regression
priority: normal -> release blocker
stage: test needed -> needs patch
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

[issue39102] Increase Enum performance

[Ivan Levkivskyi]

Change by Ivan Levkivskyi :


--
nosy: +levkivskyi

___
Python tracker 

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

[issue39046] collections.abc.Reversible should not be a subclass of Hashable

[Ivan Levkivskyi]

Change by Ivan Levkivskyi :


--
nosy: +levkivskyi

___
Python tracker 

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

[issue39111] Misleading documentation

[Murali Ganapathy]

Murali Ganapathy  added the comment:

===
# python3
class Base:
  def __eq__(self, other):
print("base called")
return super().__eq__(other)


class Foo(Base):

  def __eq__(self, other):
print("foo called")
return NotImplemented

Foo() == Foo()
# foo called
# foo called
False


Base.__eq__ is not called here. Is calling of object.__eq__ special cased?

--

___
Python tracker 

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

[issue39110] It seems that list() changes the value of the parameter

[Eric Snow]

Eric Snow  added the comment:

Your problem is with UserList.  This is from the implementation:

def __getitem__(self, i):
if isinstance(i, slice):
return self.__class__(self.data[i])
else:
return self.data[i]

So each slice is creating a new Tree.  Then the __setitem__() of that new Tree 
gets triggered for each item, causing the owner to be set to the new Tree.  So 
that's the cause.

Is there a particular reason you are subclassing UserList?  Consider 
subclassing list or collections.abc.MutableSequence instead.  Or deal with the 
slice semantics manually.

Also, perhaps you expected that a slice would produce a view into the sequence? 
 I know that's how it works in some programming languages (but not Python, 
though you could make it do that if you wanted to).

Regardless, as far as I can tell everything is working as designed.  I 
recommend closing this.

--
nosy: +eric.snow
resolution:  -> not a bug
status: open -> pending
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

[issue26767] Inconsistant error messages for failed attribute modification

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Not all error messages contain an attribute name, an object type name and a 
reason.

--

___
Python tracker 

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

[issue39111] Misleading documentation

[Brett Cannon]

Brett Cannon  added the comment:

And to be more specific, == is guaranteed to work by falling back to 
object.__eq__() which falls back to object identity if the object doesn't have 
a custom __eq__() method.

--

___
Python tracker 

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

[issue39111] Misleading documentation

[Brett Cannon]

Brett Cannon  added the comment:

This is because your class implicitly inherits from object and object.__eq__() 
is implemented and does not return NotImplemented.

--
nosy: +brett.cannon
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

[issue39103] [linux] strftime renders %Y with only 3 characters

[Brett Cannon]

Brett Cannon  added the comment:

Due note, though, that there's a difference in the implementation of strftime 
versus strptime, as the former (at least the last time I looked ages ago) uses 
the libc version of the function and thus probably doesn't try to smooth out 
differences like this, while the latter is implemented in Python code in the 
stdlib itself.

--
nosy: +brett.cannon

___
Python tracker 

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

[issue39107] Consider building Tkinter with Tk 8.6.10

[Zachary Ware]

Zachary Ware  added the comment:

Looks like some enhancements on Windows as well; we should upgrade at least 3.9.

--
components: +Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware

___
Python tracker 

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

[issue39105] Spam

[Zachary Ware]

Change by Zachary Ware :


--
type: resource usage -> 
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

[issue39105] Spam

[Zachary Ware]

Change by Zachary Ware :


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

___
Python tracker 

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

[issue39105] Spam

[Zachary Ware]

Change by Zachary Ware :


Removed file: https://bugs.python.org/file48795/Roko-Logo-2-fi18353094x260.png

___
Python tracker 

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

[issue39111] Misleading documentation

[Murali Ganapathy]

New submission from Murali Ganapathy :

The documentation at 
https://docs.python.org/3.6/library/constants.html#NotImplemented states

If all attempts return NotImplemented, the interpreter will raise an 
appropriate exception. However this is not true for __eq__.

===
class Foo:
  def __eq__(self, other):
return NotImplemented

Foo() == Foo() # returns False, does not throw an exception


--
assignee: docs@python
components: Documentation
messages: 358719
nosy: docs@python, murali
priority: normal
severity: normal
status: open
title: Misleading documentation
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

___
Python tracker 

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

[issue34938] Fix mimetype.init() to account for from import

[YoSTEALTH]

YoSTEALTH  added the comment:

I didn't receive any notification of replay on this topic.

`_default_mime_types()` should never have been a function. This function should 
be safe to remove as its an internal function. This would avoid unneeded 
function call and globals used.

Stuff like `_suffix_map_default` could be constants like `SUFFIX_MAP_DEFAULT` 
with `suffix_map = SUFFIX_MAP_DEFAULT.copy()`

Ashley if you feel like making these changes (optional)

--

___
Python tracker 

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

[issue26767] Inconsistant error messages for failed attribute modification

[Batuhan]

Batuhan  added the comment:

> I think it would be nice to unify error messages and make them more specific.

How can they can be more specific when they are unified?

--
nosy: +BTaskaya
versions: +Python 3.9 -Python 3.6

___
Python tracker 

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

[issue26845] Misleading variable name in exception handling

[Batuhan]

Batuhan  added the comment:

I am not sure if calls like this constitutes a problem. By the way most of the 
things changed in Python/ceval.c including removal of END_FINALLY (issue 33387) 
but calls to _PyErr_Restore is still there with that same arguments.

--
nosy: +BTaskaya, vstinner

___
Python tracker 

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

[issue23868] Uninitialized objects are tracked by the garbage collector

[Batuhan]

Change by Batuhan :


--
nosy: +BTaskaya, pablogsal
type:  -> behavior

___
Python tracker 

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

[issue18930] os.spawnXX functions terminates process if second argument is empty list

[Batuhan]

Batuhan  added the comment:

@SSchukat can you reproduce this issue in python 3?

--
components: +Windows -Interpreter Core
nosy: +BTaskaya, paul.moore, steve.dower, tim.golden, zach.ware
type:  -> behavior

___
Python tracker 

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

[issue39110] It seems that list() changes the value of the parameter

[ctarn]

ctarn  added the comment:

OK, I mean... when I call `a = list(b)`, list() changes `b` unexpectedly, not 
`a != b` in this case. That is why I replace the left operand with `_`.

--

___
Python tracker 

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

[issue39110] It seems that list() changes the value of the parameter

[ctarn]

ctarn  added the comment:

I printed the value of *.owner before and after `_ = list(d...)`, and marked 
the results in the comments.

--

___
Python tracker 

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

[issue39110] It seems that list() changes the value of the parameter

[ctarn]

ctarn  added the comment:

Hi, thanks. It did call `list()` through `_ = list(d[0:2])`

--

___
Python tracker 

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

[issue39110] It seems that list() changes the value of the parameter

[Steven D'Aprano]

Steven D'Aprano  added the comment:

Can you give an example? Something simple, showing what you tried, what you 
expected, and what happened instead.

This may help: http://sscce.org/

Your bug.py file doesn't ever use the result of calling list(), so how do you 
know it changes the value of the parameter?

--
nosy: +steven.daprano

___
Python tracker 

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

[issue39110] It seems that list() changes the value of the parameter

[ctarn]

ctarn  added the comment:

In the code, each item of ls = [[0], [1], [2],...] has an owner pointing to d, 
which is a Tree inheriting from collections.UserList.
When `d[0] = a`, and `a.owner = d`, and `_ = list(d[0:1])` is called, a.owner 
will be changed to d[0:1].

--

___
Python tracker 

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

[issue39110] It seems that list() changes the value of the parameter

[ctarn]

Change by ctarn :


--
title: It seems that unittest.TestCase.assertListEqual changes the value of its 
parameters -> It seems that list() changes the value of the parameter
Added file: https://bugs.python.org/file48797/bug.py

___
Python tracker 

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

[issue39110] It seems that unittest.TestCase.assertListEqual changes the value of its parameters

[ctarn]

Change by ctarn :


Removed file: https://bugs.python.org/file48796/bug.py

___
Python tracker 

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

[issue39110] It seems that unittest.TestCase.assertListEqual changes the value of its parameters

[ctarn]

New submission from ctarn :

Sorry, it is caused by list(). I will update the issue very soon.

--
nosy: +ctarn

___
Python tracker 

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

[issue39110] It seems that unittest.TestCase.assertListEqual changes the value of its parameters

[ctarn]

Change by ctarn :


--
title: It seems that TestCase.assertListEqual change the value of its 
parameters -> It seems that unittest.TestCase.assertListEqual changes the value 
of its parameters

___
Python tracker 

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

[issue39110] It seems that TestCase.assertListEqual change the value of its parameters

[ctarn]

Change by ctarn :


--
nosy:  -ctarn
title: It -> It seems that TestCase.assertListEqual change the value of its 
parameters
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

[issue39110] It

[ctarn]

Change by ctarn :


--
files: bug.py
nosy: ctarn
priority: normal
severity: normal
status: open
title: It
type: behavior
Added file: https://bugs.python.org/file48796/bug.py

___
Python tracker 

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

[issue39094] Add a default to statistics.mean and related functions

[Yoni Lavi]

Yoni Lavi  added the comment:

Thanks for the good feedback everyone and apologies for the unresponsiveness 
over the past day.

I understand that my use cases may not reflect wider usage patterns and am not 
looking to argue against the closing. But anyway, for future reference, I'll 
add two real-life usage examples, which I should have included originally 
(again, apologies for the delay, things have been hectic).

The context is that I'm involved in running a coding bootcamp, and these are 
two recent cases when I needed a default of zero recently:

1. (Separately of the final grade calculations) We are interested in students' 
average grades on their projects as an indicator of their skills gained and 
their striving for excellence. When calculating this indicator, we use an 
average of 0 for a student who haven't yet submitted anything.

2. When providing tutoring support, we classify the "complexity" of each 
student issue, and then one of our indicators involves the average complexity 
of questions in a particular slice of time and the programme (this is 
particularly interesting around changes to the content). For this as well, a 
slice of time/programme/tutor during which there were no issues would be 
considered as having a complexity of 0.

Again, not disputing the decision to close, just adding these examples for 
future reference.
Thanks

--

___
Python tracker 

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

[issue39109] [C-API] PyUnicode_FromString

[STINNER Victor]

STINNER Victor  added the comment:

> I think the ob_refcnt Field should be 1 in both cases. Or why is the refcnt 
> here so high?

Python has singletons for short strings: empty string and 1-character latin1 
characters (unicode range [U+; U+00FF]).

Examples:

>>> sys.getrefcount("")
103
>>> sys.getrefcount("a")
11

It's not a bug, but an optimization to reduce the memory footprint ;-)

--
nosy: +vstinner
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

[issue39109] [C-API] PyUnicode_FromString

[Yannick]

New submission from Yannick :

Python version: 3.5
Tested with VS Studio 2017 in an C-API extension.

When you have a UTF-8 encoded char buffer which is filled with a 0 or empty, 
and you youse the PyUnicode_FromString() method on this buffer, you will get a 
PyObject*. The content looks good, but the refence counter looks strange. 

In case of an 0 as char in the buffer, the ob_refcnt Field is set to 100 and in 
case of an empty buffer, the ob_refcnt Field is set to something around 9xx. 

Example Code: 
  string s1 = u8"";
  string s2 = u8"0";

  PyObject *o1 = PyUnicode_FromString(s1.c_str());
  //o1->ob_refcnt = 9xx
  PyObject *o2 = PyUnicode_FromString(s2.c_str());
  //o2->ob_refcnt = 100

I think the ob_refcnt Field should be 1 in both cases. Or why is the refcnt 
here so high?

--
components: C API
messages: 358706
nosy: YannickSchmetz
priority: normal
severity: normal
status: open
title: [C-API] PyUnicode_FromString
type: behavior
versions: Python 3.5

___
Python tracker 

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

[issue39107] Consider building Tkinter with Tk 8.6.10

[Terry J. Reedy]

Terry J. Reedy  added the comment:

Ned is aware of this and needs to verify that it works with _tkinter and 
tkinter on multiple versions of macOS.

--
assignee: terry.reedy -> ned.deily
components: +macOS -IDLE
nosy: +ronaldoussoren

___
Python tracker 

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

[issue13153] IDLE 3.x on Windows exits when pasting non-BMP unicode

[Terry J. Reedy]

Terry J. Reedy  added the comment:

On Windows with 8.6.9, I see '\U0001f4bb' on 3.7.5 and '' on 3.8.0 and 
3.9.0a0.  I don't know why the difference as Serhiy's patch was backported. I 
will upgrade 3.7 and 3.8 and try again.

--

___
Python tracker 

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

[issue39107] Consider building Tkinter with Tk 8.6.10

[Karthikeyan Singaravelan]

Change by Karthikeyan Singaravelan :


--
nosy: +ned.deily

___
Python tracker 

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

[issue39108] Documentation for "random.gauss" vs "random.normalvariate" is lacking

[Karthikeyan Singaravelan]

Change by Karthikeyan Singaravelan :


--
nosy: +mark.dickinson, rhettinger

___
Python tracker 

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

[issue39108] Documentation for "random.gauss" vs "random.normalvariate" is lacking

[Charles Newey]

New submission from Charles Newey :

The Python 3 documentation for the "random" module mentions two possible ways 
to generate a random variate drawn from a normal distribution - "random.gauss" 
and "random.normalvariate" (see: 
https://docs.python.org/3/library/random.html#random.gauss).

It's not clear what the distinction is other than apparently the "random.gauss" 
function is faster. Digging through the source code, it eventually becomes 
apparent that "random.gauss" is NOT thread safe... but this isn't mentioned in 
the documentation anywhere.

Further, the documentation doesn't make explicit reference to the particular 
method used for generating these Gaussian variates.

Basically what I'm getting at is that it's difficult to tell which function 
("gauss" or "randomvariate") I should be using. I feel that the documentation 
could be clarified here. I'm happy to do this in a PR at some point if required.

--
assignee: docs@python
components: Documentation
messages: 358703
nosy: cnewey, docs@python
priority: normal
severity: normal
status: open
title: Documentation for "random.gauss" vs "random.normalvariate" is lacking
type: enhancement
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

___
Python tracker 

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

[issue39107] Consider building Tkinter with Tk 8.6.10

[Aivar Annamaa]

Change by Aivar Annamaa :


--
title: Consider upgrading Tkinter to Tk 8.6.10 -> Consider building Tkinter 
with Tk 8.6.10

___
Python tracker 

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