[issue42830] tempfile mkstemp() leaks file descriptors if os.close() is not called

[Mieczysław Torchała]

Mieczysław Torchała  added the comment:

Yes, having it written explicitly in docs (that remove means not only a file 
removal with unlink/remove and warn about lacking file descriptors), or/and 
providing a remove function in tempfile which will both unlink and close, would 
be valuable.

The use case is that when the process crashes during some scientific 
computations, I still want to keep the file to investigate. Of course, one can 
argue that try/except could copy the file somewhere else, but having it still 
in /tmp (and pointing to this file in the log) is pretty useful.

--

___
Python tracker 

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

[issue43059] sqlite3: Externally developed?

[Erlend Egeberg Aasland]

Erlend Egeberg Aasland  added the comment:

> Before removing public documented attribute it should be deprecated.

Of course.

> […], I have a large patch for removing obsolete version attributes in process.

Great!

--

___
Python tracker 

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

[issue43059] sqlite3: Externally developed?

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Before removing public documented attribute it should be deprecated.

Don't haste with this, I have a large patch for removing obsolete version 
attributes in process.

--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue43029] unittest: Add assertUniqeIn

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

It looks pretty niche. I do not remember a single case in which such method 
would help.

--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue43029] unittest: Add assertUniqeIn

[Raymond Hettinger]

Raymond Hettinger  added the comment:

-0 on this one because the algorithm is quadratic, the name is opaque, and 
because the common case can already be clearly expressed with sets.

--
nosy: +rhettinger

___
Python tracker 

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

[issue23544] IDLE hangs when selecting Stack View with debug active

[Terry J. Reedy]

Change by Terry J. Reedy :


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

___
Python tracker 

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

[issue23544] IDLE hangs when selecting Stack View with debug active

[Terry J. Reedy]

Terry J. Reedy  added the comment:

Tal, I agree with you.

The debugger is an execution controller with an optional current-frame viewer 
updated whenever execution is paused.  It displays both name and value.  I 
believe a current PR addresses the issue of value representations being 
indefinitely long and possibly overflowing the space allotted.

The stack viewer can view any frame on the stack, but only after an exception.  
At least currently, on Windows, it omits value names. And there are other 
issues (#24790).  The debugger viewer and stack viewer should be combined with 
the best features of each (new issues).

In the meanwhile, I finished PR and merged.

--

___
Python tracker 

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

[issue23544] IDLE hangs when selecting Stack View with debug active

[Terry J. Reedy]

Terry J. Reedy  added the comment:


New changeset 901a9834420e516c07d6cad356d2be481db6d8d1 by Miss Islington (bot) 
in branch '3.8':
bpo-23544: Disable IDLE Stack Viewer when running user code (GH-17163) (#24366)
https://github.com/python/cpython/commit/901a9834420e516c07d6cad356d2be481db6d8d1


--

___
Python tracker 

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

[issue43051] Pip Permissions Error overwriting pip directory

[Steve Dower]

Steve Dower  added the comment:

This is better reported at https://github.com/pypa/pip, as it will be fixed out 
of their repository and then updated into here.

Seems like the failed install did not roll back properly. Those directories are 
the backup of the uninstallation so that if it fails, they can be restored. 
It's not obvious why that didn't work here.

--
resolution:  -> third party
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

[issue23544] IDLE hangs when selecting Stack View with debug active

[miss-islington]

miss-islington  added the comment:


New changeset 6d87dec5818667168cc7e4ad972dde8aeec6d900 by Miss Islington (bot) 
in branch '3.9':
bpo-23544: Disable IDLE Stack Viewer when running user code (GH-17163)
https://github.com/python/cpython/commit/6d87dec5818667168cc7e4ad972dde8aeec6d900


--

___
Python tracker 

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

[issue23544] IDLE hangs when selecting Stack View with debug active

[miss-islington]

Change by miss-islington :


--
pull_requests: +23189
pull_request: https://github.com/python/cpython/pull/24366

___
Python tracker 

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

[issue23544] IDLE hangs when selecting Stack View with debug active

[miss-islington]

Change by miss-islington :


--
nosy: +miss-islington
nosy_count: 4.0 -> 5.0
pull_requests: +23188
pull_request: https://github.com/python/cpython/pull/24365

___
Python tracker 

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

[issue23544] IDLE hangs when selecting Stack View with debug active

[Terry J. Reedy]

Terry J. Reedy  added the comment:


New changeset 23a567c11ca36eedde0e119443c85cc16075deaf by Zackery Spytz in 
branch 'master':
bpo-23544: Disable IDLE Stack Viewer when running user code (GH-17163)
https://github.com/python/cpython/commit/23a567c11ca36eedde0e119443c85cc16075deaf


--

___
Python tracker 

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

[issue43059] sqlite3: Externally developed?

[user1347091]

user1347091  added the comment:

At least in Python 3.9.1, these commands still exist:
Python 3.9.1 (default, Dec 13 2020, 11:55:53) 
[GCC 10.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import sqlite3
>>> sqlite3.version
'2.6.0'
>>> sqlite3.version_info
(2, 6, 0) 
So if they are obsolete as well, they should be removed from cpython as well, 
and not only from the documentation.

I have created a pull request for the obsolete link, and I'd be happy to take 
care of this as well if we decide to do so.

--

___
Python tracker 

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

[issue43059] sqlite3: Externally developed?

[Erlend Egeberg Aasland]

Erlend Egeberg Aasland  added the comment:

Perhaps we should remove the (pysqlite) version attributes while we're there? 
Ref. 
https://mail.python.org/archives/list/python-...@python.org/message/NS6YVA3QCAXELK7KROOLULKXOF3KFFJA/

>>> import sqlite3
>>> sqlite3.version
'2.6.0'
>>> sqlite3.version_info
(2, 6, 0)


Berker?

--

___
Python tracker 

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

[issue43059] sqlite3: Externally developed?

[Roundup Robot]

Change by Roundup Robot :


--
keywords: +patch
nosy: +python-dev
nosy_count: 5.0 -> 6.0
pull_requests: +23186
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/24364

___
Python tracker 

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

[issue43059] sqlite3: Externally developed?

[Zachary Ware]

Zachary Ware  added the comment:

Looks like that link could be safely removed from our docs.  Would you like to 
submit a pull request doing so?

--
nosy: +berker.peksag, erlendaasland, zach.ware

___
Python tracker 

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

[issue43059] sqlite3: Externally developed?

[user1347091]

user1347091  added the comment:

The documentation page in question is the following:

https://docs.python.org/3.10/library/sqlite3.html
(Sorry, I forgot to add this information to my original post)

--

___
Python tracker 

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

[issue43059] sqlite3: Externally developed?

[user1347091]

New submission from user1347091 :

In the documentation of the sqlite3 module it says:

See also:
https://github.com/ghaering/pysqlite
The pysqlite web page – sqlite3 is developed externally under the name 
“pysqlite”.

However, the README.md of the linked repository says:

This project is not actively maintained any more: You are better off using 
the "sqlite3" module in the Python standard library, which originated from the 
pysqlite codebase.

Which information is correct? They seem contraticting to me. It looks like this 
is old information from times where sqlite3 wasn't integrated in the Python 
standard library yet - or am I missing something?

--
assignee: docs@python
components: Documentation
messages: 385884
nosy: docs@python, user1347091
priority: normal
severity: normal
status: open
title: sqlite3: Externally developed?
type: enhancement
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

[issue42972] [C API] Heap types (PyType_FromSpec) must fully implement the GC protocol

[Erlend Egeberg Aasland]

Erlend Egeberg Aasland  added the comment:

Should we proceed with fixing GC for all heap types before continuing work with 
bpo-40077?

--

___
Python tracker 

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

[issue43046] argparse: capturing actions

[Glenn Linderman]

Glenn Linderman  added the comment:

Raymond Hettinger  added the comment:

>> Sounds like another wet blanket argpment

> Please watch your tone.  It borders on being abusive.

I considered that as a canonical description of the type of negativity 
presented by your comment. It was not intended to be abusive, just a 
descriptive summary.


> It is entirely appropriate to set limits on the scope of what a module is 
> trying to achieve.  It is appropriate to consider module learnability.  It is 
> appropriate to limit sprawl and feature creep.  It is appropriate to consider 
> whether the pattern being encouraged and supported by the PR is 
> intellectually manageable by end users.


I agree that all those considerations are worthwhile, but I see this as a small 
extension that adds significant power. No one is forced to use the new 
features, or the old features, or argparse at all. There are already features 
in argparse that I simply ignore, because I have no need for them. It doesn't 
make using the feature I do use more difficult. I just look for what I need, 
and use those features.


> It is correct that argparse set out to handle more complex cases than 
> optparse.  But even then, it was aiming to cases that commonly arose it the 
> wild (subparsers are not uncommon).  It never aspired to be all things to all 
> users.

And unfortunately, in so doing, it failed to support some cases that optparse 
could handle, although for the cases that argparse could handle, the user code 
to use it was far simpler.  This was improved somewhat by the addition of 
parse_intermixed_args.

Since argparse is provided in stdlib, it seems very reasonable to me to enhance 
it to support command line parsing paradigms used effectively since 1979, at 
least (ref: tar).

--

___
Python tracker 

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

[issue43009] Port curses capi pointer array to a struct

[Erlend Egeberg Aasland]

Erlend Egeberg Aasland  added the comment:

The _decimal API is also just an array of pointers. Should we change that to a 
struct as well?

--
nosy: +erlendaasland

___
Python tracker 

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

[issue43058] setting a logging Handler name

[Brett Cohen]

New submission from Brett Cohen :

When using the logging module to add a new handler, the documentation doesn't 
mention the ability to set the name of the handler. It turns out that it's 
actually a supported feature by using:

handler_instance.set_name("YOUR_NAME_HERE")

I'd suggest updating the documentation to indicate the ability to set the name 
of the handler. It'd be very nice if the name was settable in the constructor 
of the Handler class. This could be done by including an optional `name` 
argument that defaults to None:

class Handler(Filterer):
def __init__(self, level=NOTSET, name=None):
Filterer.__init__(self)
self._name = name
...
...

I noticed the problem when trying to call logging.config.dictConfig with a 
config which specified a handler (it crashes: `ValueError: No handler found 
with name 'my_handler'`).

I initially thought to manually alter the _handlers directly since the docs 
didn't indicate how to set the name. After digging into the source code I found 
the undocumented `set_name` function.

--
assignee: docs@python
components: Documentation, Library (Lib)
messages: 385880
nosy: bcohen, docs@python, vinay.sajip
priority: normal
severity: normal
status: open
title: setting a logging Handler name
type: enhancement
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

[issue43057] Timezone 'Etc/GMT-5' functions as Timezone 'Etc/GMT+5'

[Mark Dickinson]

Mark Dickinson  added the comment:

This isn't a Python bug - it's a quirk of the way that the "Etc/***" timezones 
are defined. See for example https://en.wikipedia.org/wiki/Tz_database#Area:

> In order to conform with the POSIX style, those zone names beginning with 
> "Etc/GMT" have their sign reversed from the standard ISO 8601 convention. In 
> the "Etc" area, zones west of GMT have a positive sign and those east have a 
> negative sign in their name (e.g "Etc/GMT-14" is 14 hours ahead of GMT).

--
nosy: +mark.dickinson
resolution:  -> third party
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

[issue42380] Build windows binaries with MS VS2019 16.8+ / MSVC 19.28+

[Terry J. Reedy]

Terry J. Reedy  added the comment:

Judging from the link you posted to version numbering
https://en.wikipedia.org/wiki/Microsoft_Visual_C%2B%2B#Internal_version_numbering
the first line should have 'MSVC 14.28' the middle column title should be  'MS 
Visual Studio'.

Mark Shannon today posted "Why aren't we allowing the use of C11?" on pydev.
https://mail.python.org/archives/list/python-...@python.org/thread/PLXETSQE7PRFXBXN2QY6VNPKUTM6I7OD/

--
nosy: +terry.reedy

___
Python tracker 

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

[issue24275] lookdict_* give up too soon

[Hristo Venev]

Hristo Venev  added the comment:

Benchmark program attached.

0. Creates a dict with str keys
1. str lookups
2. str subclass lookups on the same dict
3. str lookups on the same dict

Results before patch:
0.9493069459404069 +- 0.004707371313935551
1.47313450980997 +- 0.01350596115630158
1.3181799192904144 +- 0.006550182814933545

Results after patch:
0.9498907704499289 +- 0.003721378313122522
1.4936510094799451 +- 0.057905386684185135
0.9494844124498195 +- 0.0029465760297623235

--
Added file: https://bugs.python.org/file49773/bench.py

___
Python tracker 

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

[issue24275] lookdict_* give up too soon

[Hristo Venev]

Hristo Venev  added the comment:

I've attached a patch. I will soon provide benchmark results.

--
keywords: +patch
nosy: +h.venev
Added file: 
https://bugs.python.org/file49772/0001-Don-t-downgrade-unicode-only-dicts-to-mixed-on-non-u.patch

___
Python tracker 

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

[issue43057] Timezone 'Etc/GMT-5' functions as Timezone 'Etc/GMT+5'

[Dennis Sweeney]

Dennis Sweeney  added the comment:

I reproduced something similar in 3.9 with standard library modules:

>>> from datetime import datetime
>>> from zoneinfo import ZoneInfo
>>> zone = ZoneInfo(key='Etc/GMT-3')
>>> zone.tzname(datetime(2021, 1, 28))
'+03'

--
nosy: +Dennis Sweeney

___
Python tracker 

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

[issue43040] random.py randrange() is very slow if the range is a power of 2.

[Raymond Hettinger]

Raymond Hettinger  added the comment:

> python2's implementation of randrange() that uses random() 
> under the hood was noticeably faster than python3's 
> randrange() that uses getrandbits() under the hood.

Yes, that was a conscious decision. See https://bugs.python.org/issue9025 . We 
traded performance in order to gain correctness.  As noted in the docs:

"Changed in version 3.2: randrange() is more sophisticated about producing 
equally distributed values. Formerly it used a style like int(random()*n) which 
could produce slightly uneven distributions."

--

___
Python tracker 

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

[issue43053] Speed up math.isqrt, again

[Mark Dickinson]

Mark Dickinson  added the comment:

Translation of the proposal to the iterative version described here: 
https://github.com/python/cpython/blob/64fc105b2d2faaeadd1026d2417b83915af6622f/Modules/mathmodule.c#L1591-L1611

The main loop:

c = (n.bit_length() - 1) // 2
a = 1
d = 0
for s in reversed(range(c.bit_length())):
# Loop invariant: (a-1)**2 < (n >> 2*(c - d)) < (a+1)**2
e = d
d = c >> s
a = (a << d - e - 1) + (n >> 2*c - e - d + 1) // a

becomes (again identical except for the last line):

c = (n.bit_length() - 1) // 2
a = 1
d = 0
for s in reversed(range(c.bit_length())):
# Loop invariant: (a-1)**2 < (n >> 2*(c - d)) < (a+1)**2
e = d
d = c >> s
a = (a << d - e) + ((n >> 2*c - e - d + 1) - (a*a << d - e - 1)) // 
a

--

___
Python tracker 

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

[issue43053] Speed up math.isqrt, again

[Mark Dickinson]

Mark Dickinson  added the comment:

Some comments, now that I've had a chance to look properly at the suggestion.

For reference, here's the "near square root" function that forms the basis of 
Python's isqrt algorithm. For clarity, I've written it recursively, but it's 
equivalent to the iterative version described in mathmodule.c. (Definition: for 
a positive integer n, a "near square root" of n is an integer a such that |a - 
√n| < 1; or in other words the near square roots of n are the floor and the 
ceiling of √n.)

def nsqrt(n):
"""Compute a near square root for a positive integer n."""
if n < 4:
return 1
else:
e = (n.bit_length() - 3) // 4
a = nsqrt(n >> 2*e + 2)
return (a << e) + (n >> e + 2) // a

Juraj's suggestion, applied to each step of the recursion rather than just the 
outer step, amounts to computing the expression in the last line in a different 
way. (What follows isn't *identical* to what Juraj is suggesting in all the 
details, but it's essentially equivalent and has the same key performance 
implications.) Here's the proposed new version, identical to the previous one 
except for the last line:

def nsqrt(n):
"""Compute a near square root for a positive integer n."""
if n < 4:
return 1
else:
e = (n.bit_length() - 3) // 4
a = nsqrt(n >> 2*e + 2)
return (a << e + 1) + ((n >> e + 2) - (a * a << e)) // a

With regards to proof, it's straightforward to see that this is equivalent: we 
have

(a << e) + (n >> e + 2) // a
 == (a << e) + (a << e) + (n >> e + 2) // a - (a << e)
 == (a << e + 1) + (n >> e + 2) // a - (a << e)
 == (a << e + 1) + ((n >> e + 2) - (a * a << e)) // a

It's interesting to note that with this version we *do* rely on Python's floor 
division semantics for negative numbers, since the quantity ((n >> e + 2) - (a 
* a << e)) could be negative; that last equality is not valid with C-style 
sign-of-result-is-sign-of-dividend division. The first version works entirely 
with nonnegative integers. (And the version proposed by Juraj also works 
entirely with nonnegative integers, as a result of the extra correction step.)

And now the key point is that the dividend (n >> e + 2) - (a * a << e) in the 
second version is significantly smaller (roughly two-thirds the bit count) than 
the original divisor n >> e + 2. That should make the division roughly twice as 
fast (in the limit as n gets large), and since the division is the main 
bottleneck in the algorithm for large n, it should speed up the algorithm 
overall, again in the limit for large n, despite the fact that we have a 
greater number of arithmetic operations per iteration. And with Python's 
current subquadratic multiplication but quadratic division, the advantage 
becomes more significant as n gets large.

The second version is a little more complicated than the first, but the 
complication probably amounts to no more than 10-20 extra lines of C code. 
Still, there's a maintenance cost in adding that complication to be considered.

But here's the thing: I don't actually care about the performance for *huge* n 
- people who care about that sort of thing would be better off using gmpy2. I'm 
much more interested in the performance implications for *smaller* n: that is, 
integers of length 64-256 bits, say. (For n smaller than 2**64 the difference 
is irrelevant, since we have a pure C fast path there.) If the second version 
performs better across the board it may be worth the extra complexity. If it 
doesn't, then what's the cutoff? That is, where does the second version start 
outperforming the first? I'm not really so interested in having a hybrid 
algorithm that switches from one solution to the other at some threshold - 
that's a step too far complexity-wise.

So I propose that the next step be to code up the second variant in 
mathmodule.c and do some performance testing.

Juraj: are you interested in working on a PR?

--
nosy: +tim.peters

___
Python tracker 

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

[issue43057] Timezone 'Etc/GMT-5' functions as Timezone 'Etc/GMT+5'

[killv5]

New submission from killv5 :

When I run the code attached I get the results below. This is not the expected 
behavior because I was expecting the GMT-5 timezone instead of GMT+5. When I 
tried to use GMT-5 I had the result of GMT+5. Luckily the timezone names still 
work ('EST','CST', etc.)

2021-01-28 19:10:47+05:00
+05

--
components: Library (Lib)
files: timezone_example.py
messages: 385871
nosy: killv5
priority: normal
severity: normal
status: open
title: Timezone 'Etc/GMT-5' functions as Timezone 'Etc/GMT+5'
type: behavior
versions: Python 3.8
Added file: https://bugs.python.org/file49771/timezone_example.py

___
Python tracker 

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

[issue43056] Use of dicts in sections 4.2 and 4.7 of Python tutorial a bit confusing

[Jesse Silverman]

New submission from Jesse Silverman :

The Python tutorial was not my first introduction to Python, but I see things 
in sections 4.2 and 4.7 that likely would have confused me a lot if it was.

In 4.2 near the end, we have great advice about how to avoid problems with 
modifying a collection while iterating thru it.

Unfortunately, it both makes use of a dict despite not having introduced it 
before at all within the tutorial (I wasn't shocked because it was NOT my first 
introduction to Python) and in fact, the .items() method which is beautifully 
explained in section 5.6, which hasn't been read yet.

I got thru it a bit shakily, and in a reference, rather than an introductory 
tutorial, it is quite literally impossible to present everything in a strict 
sequence, but I would definitely have been thrown for a loop if it was actually 
my first introduction to Python.

All was good again until I got to section 4.7.2, where I was again glad I had 
previously consumed tutorial materials concerning dict.  There is a forward 
reference to:
https://docs.python.org/3.9/library/stdtypes.html#typesmapping

Which every Python programmer should undoubtedly be familiar with eventually, 
but "why not?" to the more novice-friendly:
https://docs.python.org/3.9/tutorial/datastructures.html#dictionaries

The forward reference from this section to tuples in section 5 of the tutorial 
suggests that this might have been appropriate as well.

The dict, the tuple and parameter passing are all very basic topics indeed, but 
I would have found 4.7 very rough going if I had no prior exposure to dict and 
tuple.

This isn't a complaint demanding a refund for the cost of the tutorial, so much 
as an indication of where I think true novices attempting to follow the 
tutorial in sequence would likely be thrown for a loop.  I understand there is 
a healthy ecosystem of free and paid introductory tutorial material for Python, 
as evidenced by the fact that I was only working thru the tutorial just now, 
having been referred to it as a pre-req for other material I will be moving on 
to soon.

--
assignee: docs@python
components: Documentation
messages: 385870
nosy: docs@python, jessevsilverman
priority: normal
severity: normal
status: open
title: Use of dicts in sections 4.2 and 4.7 of Python tutorial a bit confusing
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

[issue29076] Mac installer shell updater script silently fails if default shell is fish

[Ned Deily]

Ned Deily  added the comment:

Thanks for the PR!

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

[issue29076] Mac installer shell updater script silently fails if default shell is fish

[Ned Deily]

Ned Deily  added the comment:


New changeset 81b23a9b148b60f8f541e4b06e1d88c58644e3b8 by Miss Islington (bot) 
in branch '3.8':
bpo-29076: Add fish support to macOS installer (GH-23302) (GH-23938)
https://github.com/python/cpython/commit/81b23a9b148b60f8f541e4b06e1d88c58644e3b8


--

___
Python tracker 

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

[issue29076] Mac installer shell updater script silently fails if default shell is fish

[Ned Deily]

Ned Deily  added the comment:


New changeset e9c6c26aff08e4c7bc6f1e8015cdd8edcc92dbef by Miss Islington (bot) 
in branch '3.9':
bpo-29076: Add fish support to macOS installer (GH-23302) (GH-23937)
https://github.com/python/cpython/commit/e9c6c26aff08e4c7bc6f1e8015cdd8edcc92dbef


--

___
Python tracker 

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

[issue42988] [security] Information disclosure via pydoc -p: /getfile?key=path allows to read arbitrary file on the filesystem

[Ned Deily]

Ned Deily  added the comment:

Resolution of this issue is blocking 3.7.x and 3.6.x security releases and 
threatens to block upcoming maintenance releases.

--
nosy: +lukasz.langa, ned.deily
priority: normal -> release blocker
title: Information disclosure via pydoc -p: /getfile?key=path allows to read 
arbitrary file on the filesystem -> [security] Information disclosure via pydoc 
-p: /getfile?key=path allows to read arbitrary file on the filesystem

___
Python tracker 

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

[issue42967] [security] urllib.parse.parse_qsl(): Web cache poisoning - `; ` as a query args separator

[Ned Deily]

Ned Deily  added the comment:

Resolution of this issue is blocking 3.7.x and 3.6.x security releases and 
threatens to block upcoming maintenance releases.

--
nosy: +lukasz.langa, ned.deily
priority: normal -> release blocker

___
Python tracker 

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

[issue42819] readline 8.1 bracketed paste

[Ned Deily]

Change by Ned Deily :


--
nosy: +twouters

___
Python tracker 

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

[issue24790] Idle: improve stack viewer

[Terry J. Reedy]

Terry J. Reedy  added the comment:

9. As of now, values are not named, whereas I believe they are in debugger.  IE 
given def f(a,b,c): 1/0; f(1,2,3), viewer prints unlaabelled 1, 2, 3 on 
separate lines.

Also, the representation of a value may not fit on a line.  I believe a current 
debugger patch addresses this issue.  Clearly, there should be one function for 
displaying locals and globals.  And in debugger, one should be able to display 
them for previous frames.

--
versions: +Python 3.10 -Python 3.6

___
Python tracker 

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

[issue43053] Speed up math.isqrt, again

[Juraj Sukop]

Juraj Sukop  added the comment:

The rounding down of `l` might compute more than half of the bits so that the 
final Heron' step in `isqrt_2` might correct the uncertain low bit if `a - (a*a 
> n)` is missing from `isqrt`.

As it currently stands, `a - (a*a > n)` is computed both in `isqrt` and 
`isqrt_2`. So I was thinking that maybe the former might be dropped.

Are you saying that both correction are need?

--

___
Python tracker 

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

[issue43053] Speed up math.isqrt, again

[Mark Dickinson]

Mark Dickinson  added the comment:

> As it currently stands, `a - (a*a > n)` is computed both in `isqrt` and 
> `isqrt_2`. So I was thinking that maybe the former might be dropped.

Ah, sorry; I misunderstood. Yes, I think so. I'll respond more fully later. 
(Sorry - real life getting in the way right now.)

--

___
Python tracker 

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

[issue43053] Speed up math.isqrt, again

[Mark Dickinson]

Mark Dickinson  added the comment:

> the only thing I'm not sure about is whether the final correction in the 
> original `isqrt` is needed

Well, *some* part of the algorithm has to make use of the low-order bits of n. 
Otherwise we won't be able to distinguish n = 4a**2 + 4a + 1 (whose isqrt is 2a 
+ 1) from 4a**2 + 4a (whose isqrt is 2a).

--

___
Python tracker 

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

[issue43055] Inconsistent behaviour when using walrus operator with 'and'/'or'

[Eric V. Smith]

Eric V. Smith  added the comment:

I'm going to close this. The short circuit evaluation of and/or expressions is 
already documented, and this behavior follows directly from that.

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

[issue36207] robotsparser deny all with some rules

[jeanotlapin]

jeanotlapin  added the comment:

Il semblerait que le script continue d'afficher des erreurs et rencontre des 
bugs. Preuve en est puisque j'ai testé sur ce site d'auto hypnose 
https://www.lautohypnose.com/ en vain...

--
nosy: +jeanotlapin

___
Python tracker 

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

[issue43055] Inconsistent behaviour when using walrus operator with 'and'/'or'

[Eric V. Smith]

Eric V. Smith  added the comment:

I think this is pretty clearly the intended semantics. In your first example, 
what do you propose "print(x)" would produce? Consider:

if False and (x:=input()) != '':
  pass
else:
  print(x)

We cannot change the semantics to now call input(), or any function with side 
effects, just to do the assignment to x.

--
nosy: +eric.smith

___
Python tracker 

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

[issue43025] Use normal 'i' character to denote imaginary part of complex numbers

[Eric V. Smith]

Eric V. Smith  added the comment:

Thanks, Mark. I'll just close it now. I've made a reminder about the PEP, but 
not sure when/if I'll get to it.

--
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

___
Python tracker 

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

[issue43053] Speed up math.isqrt, again

[Juraj Sukop]

Juraj Sukop  added the comment:

What the proof goes, you did most of the work already. Consider the following:

l = (n.bit_length() - 1)//4
a = isqrt(n >> 2*l)
a = ((a << l) + n//(a << l))//2
return a - (a*a > n)

This computes the square root of the (possibly longer) upper half, applies one 
Heron's step and a single correction. I think it is functionally equal to what 
you wrote. Those zeros don't contribute to the quotient so we could instead 
write:

a = ((a << l) + (n >> l)//a)//2

The problem is that the 3n/n division in the step `(a + n//a)//2` basically 
recomputes the upper half we already know and so we want to avoid it: instead 
of 3n/n giving 2n quotient, we want 2n/n giving 1n quotient. If the upper half 
is correct, the lower half to be taken care of is `n - a**2`:

a = (a << l) + ((n - (a << l)**2) >> l)//a//2

And there is no need to square the zeros either:

a = (a << l) + ((n - (a**2 << 2*l) >> l)//a//2

So I *think* it should be correct, the only thing I'm not sure about is whether 
the final correction in the original `isqrt` is needed. Perhaps the automated 
proof of yours could give an answer?

--

___
Python tracker 

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

[issue42819] readline 8.1 bracketed paste

[Dustin Rodrigues]

Dustin Rodrigues  added the comment:

Bumping this issue because it's a bug affecting all users who build or use a 
Python built with the current version of readline, to include all macOS 
HomeBrew and Arch Linux users who use the python from the respective package 
managers.

--

___
Python tracker 

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

[issue43048] Printing RecursionError results in RecursionError

[Irit Katriel]

Change by Irit Katriel :


--
resolution:  -> duplicate
status: open -> pending
superseder:  -> asyncio produces an unexpected traceback with recursive 
__getattribute__

___
Python tracker 

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

[issue43054] What does the existence of a struct in a header file imply about the C-API

[Petr Viktorin]

Petr Viktorin  added the comment:

When we're talking just about API, not the stable ABI (which contains only a 
few structs), reordering and additions should be fair game.


> Rather than go through this tortuous analysis for all headers, it might be 
> better to document which structs are part of the API.

Yup. I'm trying to do this for stable ABI/limited API, and it's unfortunately 
taking quite a long time.

--

___
Python tracker 

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

[issue43055] Inconsistent behaviour when using walrus operator with 'and'/'or'

[Aman Anifer]

New submission from Aman Anifer :

Using the walrus operator (:=) alongside 'and'/'or' shows inconsistent 
behaviour which changes with the order of given conditions. 

For example:
if(False and (x := 0)<1):
print("Yes")
else:
print(x)

Gives the error that 'NameError: name 'x' is not defined'
Whereas if the walrus operator is used first, like:
if((x := 0)>1 and False):
print("Yes")
else:
print(x)

Prints the value 0 without any error. This behaviour is the same when using 
'or'. For example:

if(True or (y:=0)<1):
print(y)
else:
print("No")

Gives the same error but this:
if((y:=0)<1 or True):
print(y)
else:
print("No")

Prints the value 0.
I am guessing that this is because 'and' doesn't check the second operand if 
the first operand is False, also 'if' doesn't check the second operand if the 
first operand is True. I don't know if this is an intended behaviour.

Thanks

--
components: Interpreter Core
messages: 385853
nosy: FuturisticGoo
priority: normal
severity: normal
status: open
title: Inconsistent behaviour when using walrus operator with 'and'/'or'
type: behavior
versions: Python 3.10, 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

[issue43025] Use normal 'i' character to denote imaginary part of complex numbers

[Mark Dickinson]

Mark Dickinson  added the comment:

@Eric: Are you okay with closing this issue, or do you think we should leave it 
open as a reminder to write that PEP?

--

___
Python tracker 

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

[issue43054] What does the existence of a struct in a header file imply about the C-API

[Mark Shannon]

New submission from Mark Shannon :

Given the lack of explicit documentation on this subject, and differing 
opinions among core developers, I though it would be good to discuss how the 
existence of a struct in a header file constrains the C-API.

Original PR provoking this discussion: 
https://github.com/python/cpython/pull/24298

Suppose a header file, e.g. funcobject.h, contains a struct, e.g. 
PyFunctionObject, to what extent is that struct part of the API?


If a struct is present in a header file, there are three options for what means 
in terms of the API (that make sense to me).

1. That the struct is not part of the API and may be freely changed or deleted.
2. That the struct is produced, or initialized, by an API function, which 
implies that existing fields will continue to exist, but they can be reorder or 
added to.
3. That the struct is consumed by an API function, which implies that the 
struct must keep its exact shape, only adding fields if flags are present in 
the pre-existing fields to indicate the use of the extension.

PyTypeObject is an example of (3).

We should be able to infer which of the above cases applies, if not explicitly 
documented, for any struct.

Using PyFunctionObject in funcobject.h as an example:

There is no API function or macro that directly produces or consumes the 
struct, which would imply case 1. But, the struct is documented as the struct 
for Python functions, and `PyFunction_Check()` exists, which strongly implies 
that the following code is OK:

if (PyFunction_Check(obj)) {  
PyFunctionObject *func = (PyFunctionObject *)obj;
...

which therefore implies that (2) applies.
(3) does not apply as there is no API that takes a PyFunctionObject struct as a 
parameter.

Similar logic can be applied to other parts of the API.


Rather than go through this tortuous analysis for all headers, it might be 
better to document which structs are part of the API.

--
messages: 385851
nosy: Mark.Shannon, gvanrossum, petr.viktorin, vstinner
priority: normal
severity: normal
status: open
title: What does the existence of a struct in a header file imply about the 
C-API

___
Python tracker 

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

[issue42830] tempfile mkstemp() leaks file descriptors if os.close() is not called

[Isaac Young]

Isaac Young  added the comment:

Perhaps the documentation should be more explicit, but I wouldn't say this is 
an issue. Both mkstemp and mkdtemp are low level functions which are intended 
to have this kind of flexibility.

The os.unlink, and the equivalent os.remove, are POSIX defined functions which 
always deletes the name from the filesystem but the file will remain in memory 
so long as there are file descriptors referencing it. So using 
os.close(file_descriptor) is actually how you are expected to use this API.

Is there any reason you don't want to use [Named]TemporaryFile? They are  high 
level interfaces which handle the cleanup.

--
nosy: +StillSubjectToChange

___
Python tracker 

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

[issue43053] Speed up math.isqrt, again

[Mark Dickinson]

Mark Dickinson  added the comment:

Thanks; I'll take a look at this at the weekend. Do you have a sketch of a 
proof of correctness available?

--
assignee:  -> mark.dickinson

___
Python tracker 

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

[issue43053] Speed up math.isqrt, again

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
nosy: +mark.dickinson, rhettinger, serhiy.storchaka, stutzbach

___
Python tracker 

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

[issue43053] Speed up math.isqrt, again

[Juraj Sukop]

New submission from Juraj Sukop :

This is a follow up to https://bugs.python.org/issue36887 and 
https://bugs.python.org/issue36957 .

The new `isqrt` is remarkably simple but it does not split the number at hand 
optimally. Ideally one would want to have 2n/n division everywhere but since 
the last iteration takes as much effort as all of the iterations before it this 
is what the attached code focuses on.

At least in my testing the `isqrt_2` code below improved the performance by 50% 
(3s down to 2s, for example) and, if used, perhaps the original `isqrt` could 
do without the final correction `a - (a*a > n)`.

--
components: Extension Modules
files: isqrt_2.py
messages: 385848
nosy: juraj.sukop
priority: normal
severity: normal
status: open
title: Speed up math.isqrt, again
type: performance
versions: Python 3.8
Added file: https://bugs.python.org/file49770/isqrt_2.py

___
Python tracker 

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