[issue43598] test_subprocess logs multiple ResourceWarning warnings

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Resource warnings in test_subprocess

___
Python tracker 

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

[issue38912] test_asyncio altered the execution environment

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
status: open -> pending

___
Python tracker 

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

[issue44988] Use the newest tcl/tk support

[Terry J. Reedy]

Terry J. Reedy  added the comment:

I am sympathetic to the idea, but is 8.7 out of beta yet?  Do you have a link 
to the release page?

Is it backward compatible, so that tkinter code written to run on current 8.6 
would run on new binaries?  In any case, such a change would only be done in a 
future release.

There should be separate patches for Windows and macOS.

--
nosy: +markroseman, serhiy.storchaka, terry.reedy
versions:  -Python 3.10, Python 3.9

___
Python tracker 

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

[issue34990] year 2038 problem in compileall.py

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:


New changeset bb21e28fd08f894ceff2405544a2f257d42b1354 by Ammar Askar in branch 
'main':
bpo-34990: Treat the pyc header's mtime in compileall as an unsigned int 
(GH-19708)
https://github.com/python/cpython/commit/bb21e28fd08f894ceff2405544a2f257d42b1354


--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue34990] year 2038 problem in compileall.py

[miss-islington]

Change by miss-islington :


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

___
Python tracker 

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

[issue34990] year 2038 problem in compileall.py

[miss-islington]

Change by miss-islington :


--
pull_requests: +26379
pull_request: https://github.com/python/cpython/pull/27929

___
Python tracker 

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

[issue33710] Deprecate gettext.lgettext()

[Karthikeyan Singaravelan]

Karthikeyan Singaravelan  added the comment:

It seems like the docs have a note that these functions were removed in Python 
3.10 but they probably missed the release. Doc : 
https://docs.python.org/3.10/library/gettext.html#gettext.lgettext

--

___
Python tracker 

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

[issue44962] asyncio.create_task weakrefset race condition

[Thomas Grainger]

Change by Thomas Grainger :


--
nosy: +pitrou

___
Python tracker 

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

[issue44990] Change layout of frames back to specials-locals-stack (from locals-specials-stack)

[Mark Shannon]

New submission from Mark Shannon :

The two plausible layouts from evaluation stack frames are described here:

https://github.com/faster-cpython/ideas/issues/31#issuecomment-844263795

We opted for layout A, although it is a bit more complex to manage and slightly 
more expensive in terms of pointers. The reason for this was that it 
theoretically allows zero-copying Python-to-Python calls.

I now believe this was the wrong decision and we should have chosen layout B.

B is cheaper. It needs 2 pointers, not 3, meaning that there is another 
register available for use in the interpreter.
Also the linkage area doesn't need the nlocalsplus field.

The benefit of zero-copy calls is much smaller than I thought:
* Any calls from a generator functions do not benefit
* An additional check is needed to make sure that both frames are in the same 
stack chunk
* Any jitted code will keep stack values in registers, so stores will still be 
needed in either case.
* The average number of arguments copied is low (typically 2 or 3).

Even in the ideal case (interpreter, no generator, same stack chunk) changing 
to layout B
will cost 2/3 memory moves (independent of each other), but will gain us extra 
code for checking chunks, and one move (moving nlocalsplus). So at best we only 
save 1/2 moves.

In other cases layout B is better.

One final improvement to layout B: saving the stackdepth as an offset from 
locals[0] not from stack[0] further speeds frame handling.

--
assignee: Mark.Shannon
messages: 400202
nosy: Mark.Shannon, pablogsal
priority: normal
severity: normal
status: open
title: Change layout of frames back to specials-locals-stack (from 
locals-specials-stack)

___
Python tracker 

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

[issue43826] Resource warnings in test_subprocess

[Karthikeyan Singaravelan]

Karthikeyan Singaravelan  added the comment:


New changeset 7179930ab5f5b2dea039023bec968aadc03e3775 by Karthikeyan 
Singaravelan in branch 'main':
bpo-43826: Fix resource warning due to unclosed objects. (GH-25381)
https://github.com/python/cpython/commit/7179930ab5f5b2dea039023bec968aadc03e3775


--

___
Python tracker 

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

[issue44985] Inconsistent returned value of inspect.getfullargspec(object.__init__).

[Mehrzad]

Mehrzad  added the comment:

My suggestion:

Although both `object(...)` and `object.__init__(...)`, run through the same 
method, they are semantically and intentionally different.

1. `ObjectType(...)`; implicit call of `object.__init__`: The user intends to 
create an object. If extra arguments given, the following error should rise:

'TypeError: Obj() takes no arguments'

This error is already raised from `object.__new__` before `object.__init__` is 
invoked -- the init function is not reached at all.

2. `object.__init__(object_instance, ...)`; explicit call of `object.__init__`: 
The user intends to call the `__init__` function for some reason beyond object 
instance creation. If n-ary arguments given, the following error should *not* 
rise:

'ObjectType.__init__() takes exactly one argument (the instance to 
initialize)'


One reason I suggest the error should be eliminated is the message is 
confusing; while `object.__init__` has been called, the name of the 
non-existing `ObjectType.__init__` method appears on the error message.

3. `object_instance.__init__(...)` where `type(object_instance) == object`: 
Same behavior as (2).

4. `object_instance.__init__(...)` where `type(object_instance)` is a subclass 
of `object`: Same behavior as (3).


This is one possible solution I can think of -- which also makes the title sort 
of misleading. This is of course in the case that there are no use-cases making 
the `object.__init__` exception necessary. However, even in those cases, the 
implicit and explicit init calls might be distinguishable and the exception may 
be raised outside `object.__init__`, e.g. by the parser before calling the init.

--

___
Python tracker 

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

[issue42064] Convert sqlite3 to multi-phase initialisation (PEP 489)

[Petr Viktorin]

Petr Viktorin  added the comment:

I think the module could use a more comprehensive review for GIL handling, 
rather than doing it piecewise in individual PRs. I recommend that any function 
passed to SQLite (and only those) should
  - be named `*_callback`, for clarity
  - acquire the GIL at the very start
  - release the GIL at the very end

--

___
Python tracker 

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

[issue42064] Convert sqlite3 to multi-phase initialisation (PEP 489)

[miss-islington]

miss-islington  added the comment:


New changeset 9ed523159c7ba840dbf403e02498eeae1b5d3ed9 by Erlend Egeberg 
Aasland in branch 'main':
bpo-42064: Pass module state to `sqlite3` UDF callbacks (GH-27456)
https://github.com/python/cpython/commit/9ed523159c7ba840dbf403e02498eeae1b5d3ed9


--

___
Python tracker 

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

[issue43826] Resource warnings in test_subprocess

[Karthikeyan Singaravelan]

Change by Karthikeyan Singaravelan :


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

___
Python tracker 

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

[issue44991] [sqlite3] cleanup GIL handling

[Erlend E. Aasland]

New submission from Erlend E. Aasland :

Quoting msg400205 by Petr in bpo-42064:
I think the module could use a more comprehensive review for GIL handling, 
rather than doing it piecewise in individual PRs. I recommend that any function 
passed to SQLite (and only those) should
  - be named `*_callback`, for clarity
  - acquire the GIL at the very start
  - release the GIL at the very end

--
assignee: erlendaasland
components: Extension Modules
messages: 400207
nosy: erlendaasland, petr.viktorin
priority: normal
severity: normal
status: open
title: [sqlite3] cleanup GIL handling
type: enhancement

___
Python tracker 

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

[issue42064] Convert sqlite3 to multi-phase initialisation (PEP 489)

[Erlend E. Aasland]

Erlend E. Aasland  added the comment:

Petr:
> I think the module could use a more comprehensive review for GIL handling 
> [...]

I agree. I created bpo-44991 for this.

--

___
Python tracker 

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

[issue44992] functools.lru_cache does not consider strings and numpy strings as equivalent

[Brian Lee]

New submission from Brian Lee :

This seems like unexpected behavior: Two keys that are equal and have equal 
hashes should yield cache hits, but they do not.


Python 3.9.6 (default, Aug 18 2021, 19:38:01) 
[GCC 7.5.0] :: Anaconda, Inc. on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import functools
>>> 
>>> import numpy as np
>>> 
>>> @functools.lru_cache(maxsize=None)
... def f(x):
...   return x
... 
>>> py_str = 'hello world'
>>> np_str = np.str_(py_str)
>>> 
>>> assert py_str == np_str
>>> assert hash(py_str) == hash(np_str)
>>> 
>>> assert f.cache_info().currsize == 0
>>> f(py_str)
'hello world'
>>> assert f.cache_info().currsize == 1
>>> f(np_str)
'hello world'
>>> assert f.cache_info().currsize == 2
>>> print(f.cache_info())
CacheInfo(hits=0, misses=2, maxsize=None, currsize=2)

--
components: Library (Lib)
messages: 400209
nosy: brilee
priority: normal
severity: normal
status: open
title: functools.lru_cache does not consider strings and numpy strings as 
equivalent
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

[issue42064] Convert sqlite3 to multi-phase initialisation (PEP 489)

[Petr Viktorin]

Change by Petr Viktorin :


--
pull_requests: +26380
pull_request: https://github.com/python/cpython/pull/27931

___
Python tracker 

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

[issue44993] enum.auto() starts with one instead of zero

[David Rebbe]

New submission from David Rebbe :

enum.auto() By default, the initial value starts at 1. Per the documentation 
here: https://docs.python.org/3/library/enum.html#enum.auto

This doesn't really follow expected behavior in majority of programming 
languages nor python. Most will expect starting value to be zero. I personally 
skipped over this as I've never seen an enum start at 1 in any language before. 
Excuse my ignorance if this is more common place then I realize.

I propose an optional argument to the class to allow different starting values: 
enum.auto(0)

--
messages: 400210
nosy: David Rebbe2
priority: normal
severity: normal
status: open
title: enum.auto() starts with one instead of zero
versions: Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python 
3.9

___
Python tracker 

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

[issue44993] enum.auto() starts with one instead of zero

[Vedran Čačić]

Vedran Čačić  added the comment:

For IntEnum, maybe. But for Enum, the whole point of auto() is that the values 
don't really matter. The rationale was that with IntEnum, truth testing (which 
is often used in Python to realize Optional) would distinguish None, and then 
all true Enums would actually be true in the boolean sense.

In a way, most real examples of enums already have some "fake" value which they 
map to 0. In Python, you idiomatically use None for that.

--
nosy: +veky

___
Python tracker 

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

[issue44993] enum.auto() starts with one instead of zero

[David Rebbe]

David Rebbe  added the comment:

Understandable and I do believe IntEnum should default as zero as its the 
default type most will choose when trying to mimic other languages.

C/C++ has the same problem where the value isn't suppose to matter but as soon 
as you go across the compiled / interpreted application (libraries and network 
communication) the value of the enum becomes important. 

I have corrected all my code to have a "fake" value of 0 instead of using 
enum.auto() as the first value, but it would be nice to not have to use that 
workaround. Maybe a new class CIntEnum would be acceptable?

--

___
Python tracker 

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

[issue7057] tkinter doc: more 3.x updates

[Mark Roseman]

Mark Roseman  added the comment:

yes this should be closed.. with latest doc updates, most of these are no 
longer at all relevant

--
nosy: +markroseman

___
Python tracker 

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

[issue34990] year 2038 problem in compileall.py

[Ammar Askar]

Ammar Askar  added the comment:


New changeset 9d3b6b2472f7c7ef841e652825de652bc8af85d7 by Miss Islington (bot) 
in branch '3.9':
[3.9] bpo-34990: Treat the pyc header's mtime in compileall as an unsigned int 
(GH-19708)
https://github.com/python/cpython/commit/9d3b6b2472f7c7ef841e652825de652bc8af85d7


--

___
Python tracker 

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

[issue34990] year 2038 problem in compileall.py

[Ammar Askar]

Ammar Askar  added the comment:


New changeset 0af681b652c43f0ba90988400ecc1e7934fbfc5d by Miss Islington (bot) 
in branch '3.10':
[3.10] bpo-34990: Treat the pyc header's mtime in compileall as an unsigned int 
(GH-19708)
https://github.com/python/cpython/commit/0af681b652c43f0ba90988400ecc1e7934fbfc5d


--

___
Python tracker 

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

[issue34990] year 2038 problem in compileall.py

[Ammar Askar]

Change by Ammar Askar :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.10, Python 3.11 -Python 3.5, 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

[issue44993] enum.auto() starts with one instead of zero

[Vedran Čačić]

Vedran Čačić  added the comment:

I think you should be even more explicit. If values matter, they _should_ be 
seen in code. (All of them, not just the first one.) auto() just means "this 
value doesn't really matter". And it's not really hard to write concrete values 
instead of auto(), in many instances it's even easier. :-)

--

___
Python tracker 

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

[issue44992] functools.lru_cache does not consider strings and numpy strings as equivalent

[Raymond Hettinger]

Raymond Hettinger  added the comment:

Thanks for the report but this is an allowed behavior and not a bug.

Per the docs¹:  If typed is set to true, function arguments of different types 
will be cached separately. For example, f(3) and f(3.0) will always be treated 
as distinct calls with distinct results. If typed is false, the implementation 
will usually but not always regard them as equivalent calls and only cache a 
single result. 

¹ https://docs.python.org/3.10/library/functools.html#module-functools

In this particular case, exact type matches for str and int have an alternate 
path that tends to save space.

The cost is that str or int equivalents are cached separately.  That doesn't 
tend to be a problem in practice because functions are mostly called with the 
same types over and over again.

Note, we also treat equivalent calling patterns as distinct, f(a=1, b=2), is 
cached separately from f(b=2, a=1).

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

___
Python tracker 

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

[issue44993] enum.auto() starts with one instead of zero

[David Rebbe]

David Rebbe  added the comment:

I only created this issue because its a deviation from any standard that exists 
AFAIK. Nothing I know of starts at 1 in programming and I more than likely 
won't be the last one to make this mistake. If indexing in Python started at 1 
or any other accessor for that matter started with 1 I could understand it but 
it doesn't. Its even an ongoing online joke that "arrays start at 1". 

Most other language enum types are not explicit in value definitions because 
they don't matter, they now have to matter and be explicit in python due to 
this deviation.

--

___
Python tracker 

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

[issue39452] Improve the __main__ module documentation

[miss-islington]

Change by miss-islington :


--
nosy: +miss-islington
nosy_count: 8.0 -> 9.0
pull_requests: +26381
pull_request: https://github.com/python/cpython/pull/27932

___
Python tracker 

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

[issue39452] Improve the __main__ module documentation

[Łukasz Langa]

Łukasz Langa  added the comment:


New changeset 7cba23164cf82f6619db002cd30021b5dfb1f809 by Jack DeVries in 
branch 'main':
bpo-39452: Rewrite and expand __main__.rst (#26883)
https://github.com/python/cpython/commit/7cba23164cf82f6619db002cd30021b5dfb1f809


--
nosy: +lukasz.langa

___
Python tracker 

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

[issue44990] Change layout of frames back to specials-locals-stack (from locals-specials-stack)

[Mark Shannon]

Change by Mark Shannon :


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

___
Python tracker 

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

[issue44993] enum.auto() starts with one instead of zero

[Vedran Čačić]

Vedran Čačić  added the comment:

Honestly, I think it's backwards. Either they _do_ matter because of some 
external factor (you mention network interoperability, though I'd like you to 
clarify... what exactly did you send over the network?), or they don't matter 
(if done right, you shouldn't even _notice_ that they start at 1 --- unless you 
test their truth value, which was the reason for the original departure from 
the usual practice in the first place).

You mention indexing... I _hope_ you're not using IntEnums for indexing tuples 
(or lists). :-o In such a scenario, you're really much better off cutting the 
middleman and using objects with attributes directly (an interesting insight: 
due to the way most objects in Python are implemented, you _still_ have the 
middlemen integers in the process -- only they are called "hash values" and 
they _truly_ don't matter:).

--

___
Python tracker 

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

[issue44993] enum.auto() starts with one instead of zero

[David Rebbe]

David Rebbe  added the comment:

Welcome to enums, they don't matter until they do. I'm personally not a fan of 
enums for APIs but they exist all the time.

Indexing was an example case that nothing starts at 1.

See the attached file to demonstrate differences.

--
Added file: https://bugs.python.org/file50234/enum_comparison.txt

___
Python tracker 

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

[issue44993] enum.auto() starts with one instead of zero

[Vedran Čačić]

Vedran Čačić  added the comment:

_But why should it matter that starting value is the same_ unless you actually 
use IntEnums for indexing?

About your code: what do you _actually_ mean by "equivalent"? I hope you don't 
think that the memory representation is the same. You keep mentioning APIs and 
networks, but never concretely... do you intend to say that you somehow 
serialize those values, send them over the wire and then deserialize them into 
another language?

--

___
Python tracker 

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

[issue44991] [sqlite3] cleanup GIL handling

[Erlend E. Aasland]

Change by Erlend E. Aasland :


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

___
Python tracker 

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

[issue44992] functools.lru_cache does not guarantee cache hits for equal values

[Brian Lee]

Brian Lee  added the comment:

Thanks for clarifying - I see now that the docs specifically call out the lack 
of guarantees here with "usually but not always regard them as equivalent".

I did want to specifically explain the context of my bug; 

1. NumPy's strings have some unexpected behavior because they have fixed-length 
strings (represented inline) and var-length strings (which are pointers to 
Python strings). Various arcana dictate which version you get, and wrappers 
like pandas.read_csv can also throw a wrench in the mix. It is quite easy for 
the nominal "string type" to change from under you, which is how I stumbled on 
this bug.

2. I was using functools.cache as a way to intern objects and short-circuit 
otherwise very expensive equality calculations by reducing them to pointer 
comparisons - hence my desire for exact cache hits when typed=False.

While I agree this is Working As Documented, it does not Work As Expected in my 
opinion. I would expect the stdlib optimized implementation to follow the same 
behavior as this naive implementation, which does consider "hello world" and 
np.str_("hello world") to be equivalent.

def cache(func):
  _cache = {}
  @functools.wraps(func)
  def wrapped(*args, **kwargs):
cache_key = tuple(args) + tuple(kwargs.items())
if cache_key not in _cache:
  _cache[cache_key] = func(*args, **kwargs)
return _cache[cache_key]
  return wrapped

--
title: functools.lru_cache does not consider strings and numpy strings as 
equivalent -> functools.lru_cache does not guarantee cache hits for equal values

___
Python tracker 

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

[issue44993] enum.auto() starts with one instead of zero

[David Rebbe]

David Rebbe  added the comment:

Definition of equivalent
1: equal in force, amount, or value

Are you referring to memory space as what is actually stored in RAM? If so, 
that seems to be outside the scope here. I don't think anyone expected an 
interpreted language to have the same memory space as a compiled binary from C 
for example.

Concretely anything to do with Serialization, API (ctypes), network 
communication (non-serialization), etc will fail.

Regardless of the reasons above, 1 is never the intended default value of 
anything default initialized in any language I've ever come across.

--

___
Python tracker 

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

[issue44991] [sqlite3] cleanup callbacks (GIL handling, naming, ...)

[Erlend E. Aasland]

Erlend E. Aasland  added the comment:

I'd like to propose further enhancements:
  - use intermingled declarations in the affected functions; this will make GIL 
acquisition stand more out, and it also improves readability and makes it 
easier to trace refs
  - take the naming step further: I'd like to normalise PyObject * callback 
variable names, the extremely long function_pinboard_* names, and also drop the 
C callback prefixes ('_' and 'pysqlite_')

If you agree, I'll create separate PR's for those; one for each refactor. I 
think it will enhance readability a lot.

--
title: [sqlite3] cleanup GIL handling -> [sqlite3] cleanup callbacks (GIL 
handling, naming, ...)

___
Python tracker 

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

[issue44864] [argparse] Do not translate user-provided strings in `ArgumentParser.add_subparsers()`

[Jérémie Detrey]

Jérémie Detrey  added the comment:

Hi Terry,

Thanks for the feedback!

I've just added a blurb to the PR.

Regarding the issue type, even though this is indeed translation-related, I'd 
lean toward a bug report rather than an enhancement request: the fact that 
user-provided strings get fed to the localization function by the `argparse` 
module is contrary to the expected behavior, and thus should qualify as a bug.

However, since this is very minor, I'm totally fine with this being applied 
only to future versions!

Thanks again!

Kind regards,
Jérémie.

--

___
Python tracker 

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

[issue44993] enum.auto() starts with one instead of zero

[Eric V. Smith]

Eric V. Smith  added the comment:

Other than it’s not what you expect, do you have a concrete example of what 
problem this is causing you?

We’re unlikely to change anything without knowing what problem is being solved.

--
nosy: +eric.smith

___
Python tracker 

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

[issue44865] [argparse] Missing translations

[Jérémie Detrey]

Jérémie Detrey  added the comment:

Hi again!

As for #44864, I've just added a short blurb to the PR.

The fact that a few strings are missing calls to the localization function 
(whereas most of the other strings in `argparse` are already localized) might 
push this issue toward the bug-fix side, but, as for #44864, this is very minor 
and I really don't mind if it only gets merged into future releases.

Thanks!

Kind regards,
Jérémie.

--

___
Python tracker 

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

[issue44993] enum.auto() starts with one instead of zero

[David Rebbe]

David Rebbe  added the comment:

Seems like there is a misunderstanding here as to why this is an issue.  I can 
write an example up that would expand on the file I attached, but I feel like 
anyone that has experience in the above situations would identify this as an 
issue.

Can I ask why Python strayed from something that is considered a standard in 
almost all other languages?

--

___
Python tracker 

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

[issue44934] Windows installer: Append Python to PATH instead of prepending it

[Steve Dower]

Steve Dower  added the comment:

Removing environment variables is "known" to be unreliable - another reason I 
don't like modifying them from an installer. It's meant to remove the item from 
the list based on value, so if anything has changed then it's not a huge 
surprise it will fail.

I'm more inclined to think that the "[~]:" prefix might be up to something. I 
forget exactly what it means, but if it's not all resolving to an empty string, 
it might concatenate fine but then mess up the removal?

--

___
Python tracker 

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

[issue44864] [argparse] Do not translate user-provided strings in `ArgumentParser.add_subparsers()`

[Terry J. Reedy]

Terry J. Reedy  added the comment:

'bug', for the tracker, mean a divergence between implementation and doc. Hence 
my question about the current doc.  We could decide that either is wrong and 
should be changed.

A change to meet 'expectations' and fix a 'design bug' is an enhancement.

--

___
Python tracker 

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

[issue44993] enum.auto() starts with one instead of zero

[Eric V. Smith]

Eric V. Smith  added the comment:

I think everyone understands, we just feel that it doesn't matter.

You can see if PEP 435 answers your question.

Changing to an enhancement request for 3.11, for the proposal to add a optional 
argument to auto().

--
nosy: +ethan.furman
type:  -> enhancement
versions:  -Python 3.10, 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

[issue44988] Use the newest tcl/tk support

[Ned Deily]

Ned Deily  added the comment:

Thanks for the suggestion but 8.7 isn't even in beta yet, the most recent 
official release was 8.7a5. So it is way too early to consider moving the 
python.org installers to it.

https://www.tcl.tk/software/tcltk/8.7.html

--
nosy: +ned.deily
resolution:  -> third party
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

[issue39562] Asynchronous comprehensions don't work in asyncio REPL

[Anthony Sottile]

Anthony Sottile  added the comment:

this maybe shouldn't have been backported to 3.8.x as the change in compiler 
flags appears to break pyc files in subtle ways: 
https://stackoverflow.com/q/68910329/812183

--
nosy: +Anthony Sottile

___
Python tracker 

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

[issue44994] datetime's C implementation verifies fromisoformat is ASCII, but the pure python implementation does not

[Julian Berman]

New submission from Julian Berman :

This line (which contains a non-ASCII digit):

python3.9 -c "import datetime; datetime.date.fromisoformat('1963-06-1৪')"

raises:

Traceback (most recent call last):
  File "", line 1, in 
ValueError: Invalid isoformat string: '1963-06-1৪'

under the C implementation of the datetime module, but when the pure Python 
implementation is the one imported, succeeds (and produces `datetime.date(1963, 
6, 14)`)

The pure Python implementation should instead explicitly check and raise when 
encountering a non-ASCII string.

(On PyPy, which always uses the pure-Python implementation, this contributes to 
a behavioral difference)

--
components: Library (Lib)
messages: 400235
nosy: Julian, p-ganssle
priority: normal
severity: normal
status: open
title: datetime's C implementation verifies fromisoformat is ASCII, but the 
pure python implementation does not
type: behavior
versions: Python 3.10, Python 3.11, 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

[issue44993] enum.auto() starts with one instead of zero

[Ethan Furman]

Ethan Furman  added the comment:

Firstly (or Zeroithly ;) my apologies for not noticing this earlier.


In the functional API section:
--
The reason for defaulting to 1 as the starting number and not 0 is that 0 is 
False in a boolean sense, but enum members all evaluate to True.

---

To the best of my knowledge, Python Enums are different from other languages' 
enums in several respects; apparently this is one of them.  Having the default 
first value be 1 has been there since the beginning, and isn't going to change 
now.

Rather than allowing numbers to be assigned using the function that says the 
assigned number doesn't matter, I would rather add `start=x` in the header, the 
way I have it in `aenum`:

from aenum import Enum, auto

class ZeroEnum(Enum, start=0):
nothing = auto()
something = auto()

list(ZeroEnum)
# [, ]

class ZeroBaseEnum(Enum, start=0):
pass

class ZeroEnum2(ZeroBaseEnum):
nothing = auto()
something = auto()

list(ZeroEnum2)
# [, ]


Whether the `0` goes in the header, or in auto (which it isn't), people will 
still need to read the docs to find out about it (unless somebody asks an SO 
question, of course).

--
assignee:  -> ethan.furman
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

[issue44993] enum.auto() starts with one instead of zero

[Ethan Furman]

Ethan Furman  added the comment:

My apologies for my apologies -- for some reason I thought this was first 
posted in August of 2020.

--

___
Python tracker 

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

[issue39452] Improve the __main__ module documentation

[miss-islington]

miss-islington  added the comment:


New changeset ec5a03168f02ef92f98a94796bc6378fc73622e8 by Miss Islington (bot) 
in branch '3.10':
bpo-39452: Rewrite and expand __main__.rst (GH-26883)
https://github.com/python/cpython/commit/ec5a03168f02ef92f98a94796bc6378fc73622e8


--

___
Python tracker 

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

[issue39452] Improve the __main__ module documentation

[Łukasz Langa]

Łukasz Langa  added the comment:

Thanks a lot, Géry and Jack! ✨ 🍰 ✨

--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
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

[issue24632] Improve documentation about __main__.py

[Łukasz Langa]

Łukasz Langa  added the comment:

Solved as part of BPO-39452.

--
nosy: +lukasz.langa
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
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

[issue17359] Mention "__main__.py" explicitly in command line docs

[Łukasz Langa]

Łukasz Langa  added the comment:

Solved as part of BPO-39452.

--
nosy: +lukasz.langa
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
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

[issue44993] enum.auto() starts with one instead of zero

[Ethan Furman]

Ethan Furman  added the comment:

David, what is the actual use-case that tripped you up?  There are a few ways 
to create Enums from other systems (json files, cpp files, etc.).

--

___
Python tracker 

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

[issue44986] Date formats in help messages of argparse

[Raymond Hettinger]

Raymond Hettinger  added the comment:

I don't think anything like this should be done.  Besides breaking existing 
'%%' markup, it invents a new %-formatting notation.

--
nosy: +rhettinger
type: crash -> enhancement

___
Python tracker 

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

[issue44986] Date formats in help messages of argparse

[Raymond Hettinger]

Change by Raymond Hettinger :


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

___
Python tracker 

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

[issue44988] Use the newest tcl/tk support

[张峻铭]

张峻铭 <3180471...@qq.com> added the comment:

OK, I see. Thanks for your consideration.

--

___
Python tracker 

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

[issue44995] "Hide the prompts and output" works abnormal

[杨青]

New submission from 杨青 :

【url】https://docs.python.org/3/tutorial/classes.html
【chapter】9.4. Random Remarks

【problem description】
When I click on the demo "Hide the prompts and output" switch, the class 
definition statements were also hided.
Please take a look as the appended screenshot.

--
assignee: docs@python
components: Documentation
files: screenshot.png
messages: 400245
nosy: docs@python, yangqing
priority: normal
severity: normal
status: open
title: "Hide the prompts and output" works abnormal
versions: Python 3.9
Added file: https://bugs.python.org/file50235/screenshot.png

___
Python tracker 

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