[issue45545] chdir __exit__ is not safe

[Eryk Sun]

Eryk Sun  added the comment:

> Alternatively, can't we just os.chdir(self._old_cwd) in __enter__ and 
> preemptively fail? 

If the context manager isn't going to address the long-path case reliably using 
either a file-descriptor approach or repeated relative chdir() calls, then I 
think failing early like this is the next best choice.

The previous directory getting deleted is a random environment error, which can 
be left up to the caller. In POSIX, it might be avoidable using a 
file-descriptor approach, but POSIX doesn't actually guarantee that fchdir() 
will succeed if the file descriptor refers to a deleted directory.

--

___
Python tracker 

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

[issue45466] Simple curl/wget-like download functionality in urllib (like http offers server)

[Tom Pohl]

Tom Pohl  added the comment:

Thanks, Terry, for the hint.

The idea got some support on python-ideas, so I thought it is worthwhile to do 
a PR. As a first-time contributor, I now have to wait for approval for the 
pipeline to run...

--

___
Python tracker 

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

[issue22789] Compress the marshalled data in PYC files

[Barry A. Warsaw]

Change by Barry A. Warsaw :


--
nosy: +barry

___
Python tracker 

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

[issue45545] chdir __exit__ is not safe

[Barry A. Warsaw]

Barry A. Warsaw  added the comment:

> A LBYL won't always raise errors early as you point out. It will give earlier 
> warnings for a lot of cases, but makes contextlib.chdir usable in less places 
> than os.chdir.
> Some return paths will always be errors, and some will be technically 
> recoverable but too difficult to detect and or fragile. That's why I think 
> any solution should incorporate the `ignore_errors` flag. Its pretty ugly to 
> wrap a context manager in a try: except: just because you were trying to 
> clean up after whatever you were doing but the cwd changed in unexpected 
> ways, maybe out of your control.

How common do you expect such errors to be though?  Do you expect them to be 
more or less common than with os.chdir()?  Do you expect the mitigations to be 
any different than with a failing os.chdir()?

I’ve certainly written a chdir context manager several times and for the use 
cases I care about, I’ve never had such a failure, at least not one that wasn’t 
caused by some other underlying bug, which I was glad wasn’t silenced.

--

___
Python tracker 

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

[issue36675] Doctest directives and comments missing from code samples

[Ming Hua]

Change by Ming Hua :


--
nosy: +minghua

___
Python tracker 

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

[issue45545] chdir __exit__ is not safe

[Jeremy]

Jeremy  added the comment:

A LBYL won't always raise errors early as you point out. It will give earlier 
warnings for a lot of cases, but makes contextlib.chdir usable in less places 
than os.chdir.
Some return paths will always be errors, and some will be technically 
recoverable but too difficult to detect and or fragile. That's why I think any 
solution should incorporate the `ignore_errors` flag. Its pretty ugly to wrap a 
context manager in a try: except: just because you were trying to clean up 
after whatever you were doing but the cwd changed in unexpected ways, maybe out 
of your control.

--

___
Python tracker 

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

[issue45610] Cookies with longer paths are listed before cookies with shorter paths.

[IYism]

New submission from IYism :

E.g:
Set-Cookie: a=1; Domain=test.com;  Path=/
Set-Cookie: a=2; Domain=demo.test.com; Path=/

Browser send Cookie: a=2; a=1


According to the agreed specification, a=2 should be read first, not a=1

But the wrong behavior of python is that the cookie reads a=1 by default

--
components: Library (Lib)
messages: 405020
nosy: FFY00, IYism
priority: normal
pull_requests: 27486
severity: normal
status: open
title: Cookies with longer paths are listed before cookies with shorter paths.
type: behavior
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

[issue45545] chdir __exit__ is not safe

[Barry A. Warsaw]

Barry A. Warsaw  added the comment:

Does a LBYL strategy actually fix the problem?  E.g. what if the directory gets 
rm'd between __enter__ and __exit__?  Maybe we shouldn't try to be clever at 
all and just leave it to the user to decide what to do, and how to handle any 
chdir-back failures?  Keep it simple?

--

___
Python tracker 

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

[issue45350] configure incorrectly ignores pkg-config information for libffi and Tcl/Tk in 3.10

[Ned Deily]

Ned Deily  added the comment:

Note that we have since discovered that the fix for this problem inadvertently 
did not make it into the 3.10.0 release. It is in the current 3.10 branch and 
will be in 3.10.1, the first bugfix release for 3.10.

--

___
Python tracker 

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

[issue45096] Update Tools/freeze to make use of Tools/scripts/freeze_modules.py?

[Eric Snow]

Change by Eric Snow :


--
keywords: +patch
pull_requests: +27485
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/29222

___
Python tracker 

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

[issue11477] Incorrect operand precedence when implementing sequences in C

[Gregory P. Smith]

Gregory P. Smith  added the comment:

Given that a lot of code is presumably relying on this (see the notes from 
2015)... I wouldn't be surprised if this turns into a wart we document but not 
actually fix. :/

Or a conditional behavior we control via a `from __future__ import 
correct_extension_operator_precedence` on a per file / per Notebook basis.

Ever actually flipping the default sounds difficult without disruption.  We'd 
need input from the community where extensions that rely on it have been 
produced and widely deployed.

--

___
Python tracker 

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

[issue45607] Make it possible to enrich an exception's error message

[Zac Hatfield-Dodds]

Zac Hatfield-Dodds  added the comment:

This code shows my current best workaround based on a wrapper exception, with 
the traceback below annotating the additional details that I'd prefer to omit 
for clarity:


$ python example.py
Traceback (most recent call last):
  File "example.py", line 8, in 
raise AssertionError(why)
AssertionError: Failed!
# These 
lines are
The above exception was the direct cause of the following exception:# 
confusing for new 
# 
users, and they
Traceback (most recent call last):  # only 
exist due 
  File "example.py", line 10, in# to 
implementation
raise Explanation(msg) from e   # via 
the Explanation
Explanation:# 
wrapper type :-(
You can reproduce this error by ...
...


The motivation for this is that we'd like to use ExceptionGroup to indicate 
that `MultipleFailures` is a group of exceptions, and replace our current 
print()-based method of reporting the details of the inner exceptions.

--

___
Python tracker 

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

[issue45609] Specialize STORE_SUBSCR

[Dennis Sweeney]

Change by Dennis Sweeney :


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

___
Python tracker 

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

[issue45609] Specialize STORE_SUBSCR

[Dennis Sweeney]

New submission from Dennis Sweeney :

See the issue here for lots of data from before specializing: 
https://github.com/faster-cpython/ideas/issues/105

See https://gist.github.com/sweeneyde/91855e50feb9992b604ddda2d4f1511e for 
specialization data, pyperformance benchmarks, and microbenchmarks.

Right now the PR draft specializes list[int], dict[str], and bytearray[int], 
although I don't if the bytearray opcode should be kept. I considered 
specializing dict[object], but I figured the overhead of PyDict_SetItem isn't 
that much less than PyObject_SetItem.

--
components: Interpreter Core
messages: 405015
nosy: Dennis Sweeney
priority: normal
severity: normal
status: open
title: Specialize STORE_SUBSCR
type: performance
versions: Python 3.11

___
Python tracker 

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

[issue2628] ftplib Persistent data connection

[Ethan Furman]

Ethan Furman  added the comment:

We don't have a CLA from jbell.  I've sent an email asking him to do so... 
we'll see what happens.

--
nosy: +ethan.furman

___
Python tracker 

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

[issue45588] cached_method similar to cached_property to cache with classes

[Raymond Hettinger]

Raymond Hettinger  added the comment:

> The lru_cache can trigger infinite recursion if it is used 
> to cache a hash computation because the cache look-up itself 
> requires the hash.

Yes, I see the problem.  Am not sure whether I should add a note to the docs 
for this.


> The dataclass thing also makes close() awkward because
> then I would have an outwardly resource-ful dataclass 
> which is against the spirit of a dataclass.

If you think of a dataclass as just a data holder like a mutable named tuple, I 
can see where the notion of the "spirit of dataclass" comes from.

However, if you think of it as a code generator for handling the boilerplate 
code in a more complex class, the only "spirit" is to do anything that any 
other class does.

For objects that hold resources, an explicit close() method is common and well 
supported (i.e. contextlib.closing and generator.close()).  It is a perfectly 
reasonable thing to do.

That said, it's a matter of taste.  Just do what works best for you.


> I will think about putting this on pypi instead.

If you do post it, let me know.  I'll add a link to it from the FAQ entry.

--

___
Python tracker 

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

[issue45607] Make it possible to enrich an exception's error message

[Andre Roberge]

Change by Andre Roberge :


--
nosy: +aroberge

___
Python tracker 

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

[issue45545] chdir __exit__ is not safe

[Filipe Laíns]

Change by Filipe Laíns :


--
pull_requests: +27483
pull_request: https://github.com/python/cpython/pull/29220

___
Python tracker 

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

[issue45545] chdir __exit__ is not safe

[Filipe Laíns]

Filipe Laíns  added the comment:

s/if we can chdir/if we can't chdir/

--

___
Python tracker 

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

[issue45545] chdir __exit__ is not safe

[Filipe Laíns]

Filipe Laíns  added the comment:

Alternatively, can't we just os.chdir(self._old_cwd) in __enter__ and 
preemptively fail? IMO it's probably better to just straight up fail if we can 
chdir back to the original directory than to have relatively fragile recovery 
logic.

--

___
Python tracker 

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

[issue45504] [argparse] Entering a partial config_parser flag works with subparsers

[Steven W]

Steven W  added the comment:

Thanks. This can be closed.

https://docs.python.org/3/library/argparse.html

--

___
Python tracker 

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

[issue41592] Make _SubParsersAction public

[paul j3]

paul j3  added the comment:

A _SubParsersAction is private to the extent that users should not attempt to 
create it directly, and thus don't need to know the details - beyond what's 
documented:

"The add_subparsers() method is normally called with no arguments and returns a 
special action object. This object has a single method, add_parser(), which 
takes a command name and any ArgumentParser constructor arguments, and returns 
an ArgumentParser object that can be modified as usual."

All action objects have methods like __call__ and format_usage. The subparsers 
Action has other methods, but add_parser is the only new "public" method.

There's a tension in writing documentation between getting all details just 
right, and providing just enough for most users.  As it is, many new users are 
over whelmed by the documentation.

My understanding is that the "private/public" designation is a convenience for 
users, and not enforced by Python developers.  

I gather though that some corporate users have policies that prohibit 
modification of "private" objects, supposedly due to a fear that Python could 
modify or eliminate those objects without proper notification.  Somehow the 
"public" documentation sets that part of the code in stone.  My experience here 
is that it's easier modify the documentation to fit the code than the other way 
around :)

--

___
Python tracker 

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

[issue39846] Register .whl as a unpack format in shutil unpack

[John Andersen]

John Andersen  added the comment:

I ran into this today. Using a wrapper function around _make_zipfile due to 
https://github.com/python/cpython/blob/d5650a1738fe34f6e1db4af5f4c4edb7cae90a36/Lib/shutil.py#L817-L819
 where there is a check for if the format is zip then don't pass owner and 
group.

```
def make_whlfile(*args, owner=None, group=None, **kwargs):
return shutil._make_zipfile(*args, **kwargs)


shutil.register_archive_format("whl", make_whlfile, description="Wheel file")
shutil.register_unpack_format(
"whl", [".whl"], shutil._unpack_zipfile, description="Wheel file"
)
```

--
nosy: +pdxjohnny

___
Python tracker 

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

[issue45235] argparse does not preserve namespace with subparser defaults

[paul j3]

paul j3  added the comment:

parser = argparse.ArgumentParser()
sub = parser.add_subparsers()
example_subparser = sub.add_parser("example")
example_subparser.add_argument("--flag", default=10)
print(parser.parse_args(["example","--flag=15"], 
argparse.Namespace(flag=20)))

still returns flag=20

User input should override values set by the provided Namespace.

--

___
Python tracker 

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

RE: New assignmens ...

[Avi Gross via Python-list]

Stefan,

Yes, I often pass even fairly trivial functions like "add" or "+" or
whatever the language makes me say, to other functions in various forms of
functional programing. My point is that my example may seem trivial and not
necessary as an EXAMPLE of the greater point that may be easier to
understand than something complex. A sum() is often a generalization  of
adding two things by allowing a second addition to the sub-sum and so on.
But in a straightforward program where I am asking to add exactly two
things, few would use sum(a,b) versus just a+b. On the other hand, in
agreement with you, if I have two vectors or matrices or some other such
data holder and I want to add each position to a corresponding position,
then some kind of call to a function where I pass the two objects and the
name of a function that adds two things, is a decent way to go. But it need
not be a souped-up generalized_sum() function when a simple one will do and
be faster when invoked so many times.

And note often what is used is a temporary lambda anonymous function that
may look like \(x,y) x+y ... or whatever syntax your language uses.


-Original Message-
From: Python-list  On
Behalf Of Stefan Ram
Sent: Monday, October 25, 2021 12:57 PM
To: python-list@python.org
Subject: Re: New assignmens ...

"Avi Gross"  writes:
>Now, yes, nobody needs a function to just add two numbers.

  If one uses a framework like "functools.reduce", the only
  way to reduce an iterable to its sum, is to do just that:
  Write a function to add two numbers.

  Of course, one can circumvent "functools.reduce" (or use
  "operator.add"), but in other cases there are frameworks
  that need to be used and where one sometimes does need to
  write functions (callbacks) as simple as "lambda: None".


-- 
https://mail.python.org/mailman/listinfo/python-list

-- 
https://mail.python.org/mailman/listinfo/python-list

[issue45607] Make it possible to enrich an exception's error message

[Guido van Rossum]

Change by Guido van Rossum :


--
nosy: +Zac Hatfield-Dodds

___
Python tracker 

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

[issue45607] Make it possible to enrich an exception's error message

[Guido van Rossum]

Change by Guido van Rossum :


--
nosy: +gvanrossum

___
Python tracker 

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

[issue2771] Test issue

[Ezio Melotti]

Change by Ezio Melotti :


--
assignee: python-dev -> ezio.melotti

___
Python tracker 

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

[issue2771] Test issue

[Ezio Melotti]

Change by Ezio Melotti :


--
assignee: python-dev -> 

___
Python tracker 

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

[issue2771] Test issue

[Ezio Melotti]

Change by Ezio Melotti :


--
assignee:  -> python-dev

___
Python tracker 

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

[issue2771] Test issue

[Ezio Melotti]

Change by Ezio Melotti :


--
assignee: ezio.melotti -> python-dev
versions: +Python 3.11 -Python 3.9

___
Python tracker 

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

RE: Beginner in python

[Avi Gross via Python-list]

Chris,

I was just about to suggest:

1+3+5+7+9

and

50*101

but that would mean helping with what does seem like fairly simple homework
with no effort to show us what they already tried and got stuck with!

So, ignore my attempts at trivial humor as I suspect some form of loop was
anticipated. 

Avi
-Original Message-
From: Python-list  On
Behalf Of Chris Angelico
Sent: Monday, October 25, 2021 6:25 PM
To: Python 
Subject: Re: Beginner in python

On Tue, Oct 26, 2021 at 9:23 AM Kian Kwame  wrote:
>
> hi buddie
> am new to python  somebody kindly advice the coding which will count odd
number from 1  to 10 , and counting number from 1 tp 100

Sounds like homework. What have you written so far?

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Beginner in python

[Chris Angelico]

On Tue, Oct 26, 2021 at 9:23 AM Kian Kwame  wrote:
>
> hi buddie
> am new to python  somebody kindly advice the coding which will count odd 
> number from 1  to 10 , and counting number from 1 tp 100

Sounds like homework. What have you written so far?

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: New assignmens ...

[Chris Angelico]

On Tue, Oct 26, 2021 at 9:19 AM dn via Python-list
 wrote:
> Back on-topic, I am slightly curious:-
>
> aside from 'starting small' with an option to widen/'open-up' later, is
> there a particular reason why 'the walrus' has not been made available
> (could not be ...?) for use with object-attributes?

I can't think of any other reasons. But the one you cite is quite an
important one. In order to get real-world usage examples, the feature
was rolled out in the restricted form, because threads like this are
*exactly* how the value can be judged. So I do not in any way regret
that assignment expressions were accepted in their current form, but
also, don't be afraid to propose an opening up of the syntax. Be
specific, and cite usage examples that would benefit.

TBH, I don't think there's a lot of value in multiple-assignment,
since it has a number of annoying conflicts of syntax and few viable
use-cases. But if you have great examples of "x.y :=" or "x[y] :=",
then by all means, post on python-ideas to propose widening the scope.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Beginner in python

[Kian Kwame]

hi buddie 
am new to python  somebody kindly advice the coding which will count odd number 
from 1  to 10 , and counting number from 1 tp 100
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: New assignmens ...

[dn via Python-list]

On 26/10/2021 10.45, Chris Angelico wrote:
> On Tue, Oct 26, 2021 at 8:42 AM Avi Gross via Python-list
>  wrote:
>> Personally, I don't care what is done and suspect I will rarely feel much
>> need to use the current walrus operator, let alone an enhanced Odobenus
>> rosmarus operator like ::== ...
>>
> 
> . wait what?
> 
> Ah. Had to look that one up. :)


Each year I assist friends who own one of local orchards, at harvest
time. I usually run the sealing machine, to preserve fruit which will be
 transported refrigerated. It is such a novelty to be asked to fill-out
a time-sheet. Under "name" it asks for "position", so I entered
"Erignathus barbatus" (bearded seal), which caused similar
consternation, and for some days, until someone thought to look it up...


Back on-topic, I am slightly curious:-

aside from 'starting small' with an option to widen/'open-up' later, is
there a particular reason why 'the walrus' has not been made available
(could not be ...?) for use with object-attributes?
-- 
Regards,
=dn
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue45591] PathFinder does not find namespace packages children

[Filipe Laíns]

Filipe Laíns  added the comment:

Ah, this was not obvious to me! I did not specify a path, but as it defaults to 
`sys.path` and `namespace.a` is available there, I was expecting it to find it.
One of the things that threw me off was the first arguments being called 
`fullname`, which I assumed implied that `PathFinder` was able to do a 
recursive search.


This indeed works:
```
$ ./python
Python 3.11.0a1+ (heads/main:9e05da6224, Oct 23 2021, 20:36:14) [GCC 11.1.0] on 
linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from importlib.machinery import PathFinder
>>> spec = PathFinder.find_spec('namespace')
>>> PathFinder.find_spec('a', path=spec.submodule_search_locations)
ModuleSpec(name='a', loader=<_frozen_importlib_external.SourceFileLoader object 
at 0x7f245d0d3e80>, origin='/home/anubis/git/cpython/namespace/a.py')
```

I should have validated if normal packages also had the same behavior, which 
they do, before opening this -.-

I am curious, what is `fullname` supposed to mean then? "full" in what sense?

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

[issue21876] os.rename(src, dst) does nothing when src and dst files are hard-linked

[Irit Katriel]

Change by Irit Katriel :


--
nosy: +vstinner

___
Python tracker 

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

[issue17569] urllib2 urlopen truncates https pages after 32768 characters

[Irit Katriel]

Irit Katriel  added the comment:

Python 2.7 is no longer maintained. Please create a new issue if you are seeing 
this problem on 3.9+.

--
nosy: +iritkatriel
resolution:  -> out of date
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

Re: New assignmens ...

[Chris Angelico]

On Tue, Oct 26, 2021 at 8:42 AM Avi Gross via Python-list
 wrote:
> Personally, I don't care what is done and suspect I will rarely feel much
> need to use the current walrus operator, let alone an enhanced Odobenus
> rosmarus operator like ::== ...
>

. wait what?

Ah. Had to look that one up. :)

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue33552] f-strings and string annotations

[Irit Katriel]

Change by Irit Katriel :


--
versions: +Python 3.10, Python 3.11, Python 3.9 -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

RE: New assignmens ...

[Avi Gross via Python-list]

We have had discussions debating if Python is a good language for teaching.
The short answer is NO unless you only teach a small subset and the students
know there is more they can learn as needed. The language is too rich and
has too many ways to do seemingly anything and that is before you add more
functionality. But that can make it a great language for developers.

Assignments in middle of expressions are often syntactic sugar that may be
re-arranged internally to similar code  than what could be done other ways
without it. It can lead to ambiguities. And it can make it harder for anyone
other than the programmer that wrote it (or them a day later) to understand.

So, while we are at it, why not add the ++ and --- operators that were
deliberately NOT included in Python? Why not throw back pointers?

The short answer is that there are plenty of programming languages to choose
from and some of those do have the features you want and some do not want
them. Sure, you might push in what you want but have you considered all the
places it might be tried? Can you do it in a comprehension where an
assignment is implicitly being done?

[ var := 5  in range(10) ]

The old adage is that some people will be given a finger and take a hand. I
had NOTHING to do with the process but others here know more. Chris suggests
that there was a compromise of sorts here and a choice to implement a
limited subset of fuller functionality for NOW without ruling out doing some
more later. So those wanting more, feel free to petition for it as an
ADDITION but I suggest a more polite tone than trying to say the people who
did it were idiots who did it badly.

Personally, I don't care what is done and suspect I will rarely feel much
need to use the current walrus operator, let alone an enhanced Odobenus
rosmarus operator like ::== ...

-Original Message-
From: Python-list  On
Behalf Of Christman, Roger Graydon
Sent: Monday, October 25, 2021 12:48 PM
To: python-list@python.org
Subject: Re: New assignmens ...

Message: 8
Date: Mon, 25 Oct 2021 11:20:52 +0200
From: Antoon Pardon 
To: python-list@python.org
Subject: Re: New assignmens ...
Message-ID: <5761dd65-4e87-8b8c-1400-edb821204...@vub.be>
Content-Type: text/plain; charset=utf-8; format=flowed On 25/10/2021 11:20,
Anton Pardon wrote:
> Suppose I would like to write a loop as follows:

 >while ((a, b) := next_couple(a, b))[1]:
 >do needed calculations


> What I can do is write it as follows:

> while [tmp := next_couple(a,b), a := tmp[0], b := tmp[1]][-1]:
 >do needed calculations

> I really don't see what is gained by "forcing" me to right the second code
over the first.

No, nobody is forcing you to right it the second way over the first.
Nobody is forcing you to use the walrus operator at all!

Instead, I would recommend something more like:

   while b:
 do needed calculations
 (a,b) = next_couple(a,b)

This requires even less typing than what you had before!

But it also raises a whole lot of problems with this particular example:
-- neither a nor b is defined in your sample while loop.   It seems you
would
need to initialize a and b before your while loop (and mine)
-- is b truly a boolean value, or are you short-cutting some other value?
-- are a and b truly necessary parameters to next_couple, or are they just
there to remind the function of its previous return values?
If the latter, poerhaps you want a stream or list or something with
yield

This example (and some of the others I have seen) just highlight how
programmers will take advantage of any new tool to help them write
worse code than if they did not have the tool.   In my mind, the walrus
operator was designed to serve a particular niche case like this one:

while (x := input()) > 0:

where not having the operator required duplicating the input() operation
both before the loop and at the end of the loop  -- or more complicated
cases where some additional operations had to be performed to get that test
value for the while condition (such as getting the b out of (a,b)).

But the walrus only adds a benefit if it is there to avoid the duplication
of the code that is used to obtain that test condition.   This next_couple
example does not qualify, since apparently (a,b) are initialized by some
other means (and not be a call to next_couple with undefined values)

Or the other abuse I saw recently about using the walrus operator:

while (self.ctr := self.ctr-1) > 0:

-- there was no compelling reason for a loop counter to be a class variable
(anyone who peeks at this counter when the loop is down would only see a
zero)
-- this requires self.ctr to be initialized to a value one higher than the
first meaningful value (start at 11 if you want to count down from 10) So my
recommended alternative, which furthermore also takes less typing:

while ctr > 0:
  ...
  ctr = ctr-1

TL;DR:   The Walrus operator serves the purpose as described in its PEP
just as it is, 

[issue45608] [sqlite3] some DB-API attributes are undocumented

[Erlend E. Aasland]

Change by Erlend E. Aasland :


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

___
Python tracker 

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

[issue45608] [sqlite3] some DB-API attributes are undocumented

[Erlend E. Aasland]

New submission from Erlend E. Aasland :

Some DB-API 2.0 attributes are undocumented:

- apilevel
- threadsafety
- paramstyle

These attributes should be documented.


See also:
- bpo-8196
- 
https://discuss.python.org/t/is-sqlite3-threadsafety-the-same-thing-as-sqlite3-threadsafe-from-the-c-library/11463

--
assignee: docs@python
components: Documentation
messages: 405004
nosy: docs@python, erlendaasland, lemburg
priority: normal
severity: normal
status: open
title: [sqlite3] some DB-API attributes are undocumented
versions: Python 3.10, Python 3.11, Python 3.9

___
Python tracker 

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

[issue35174] Calling for super().__str__ seems to call self.__repr__ in list subclass

[Irit Katriel]

Change by Irit Katriel :


--
resolution:  -> not a bug
status: open -> closed

___
Python tracker 

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

[issue31594] Make bytes and bytearray maketrans accept dictionaries as first argument as it's done in str

[Irit Katriel]

Change by Irit Katriel :


--
resolution:  -> rejected
stage:  -> resolved
status: open -> closed
type: behavior -> enhancement

___
Python tracker 

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

[issue11477] Incorrect operand precedence when implementing sequences in C

[Irit Katriel]

Irit Katriel  added the comment:

Reproduced on 3.11.

--
nosy: +iritkatriel
versions: +Python 3.11 -Python 3.6

___
Python tracker 

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

[issue45020] Freeze all modules imported during startup.

[Eric Snow]

Eric Snow  added the comment:


New changeset 6afb285ff0790471a6858e44f85d143f07fda70c by Eric Snow in branch 
'main':
bpo-45020: Add tests for the -X "frozen_modules" option. (gh-28997)
https://github.com/python/cpython/commit/6afb285ff0790471a6858e44f85d143f07fda70c


--

___
Python tracker 

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

[issue13298] Result type depends on order of operands for bytes and bytearray

[Irit Katriel]

Irit Katriel  added the comment:

Reproduced on 3.11.

--
nosy: +iritkatriel
versions: +Python 3.11 -Python 3.3

___
Python tracker 

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

Re: New assignmens ...

[Chris Angelico]

On Tue, Oct 26, 2021 at 7:18 AM Antoon Pardon  wrote:
>
> Op 25/10/2021 om 20:39 schreef Chris Angelico:
> > On Tue, Oct 26, 2021 at 5:35 AM Antoon Pardon  wrote:
> >> By putting limits on the walrus code, you are not reducing complexity, you 
> >> are increasing it.
> >> You are increasing complexity because you can't just reuse the code that 
> >> handles an ordinary
> >> assignment. You now need specific code to limit it's use.
> >>
> > What does this code do?
> >
> > while x, y := foo():
> > ...
> >
> > Is it more complicated or less complicated when arbitrary assignment
> > targets are permitted?
>
> Well I would guess it would do something similar to
>
> while [x, y := foo()]:
> ...
>

And does it unpack what foo returns?

Should it?

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue23556] [doc] Scope for raise without argument is different in Python 2 and 3

[Irit Katriel]

Irit Katriel  added the comment:

Martin's patch needs to be converted to a GitHub PR and then reviewed.

--
keywords: +easy -patch
nosy: +iritkatriel
title: Scope for raise without argument is different in Python 2 and 3 -> [doc] 
Scope for raise without argument is different in Python 2 and 3
versions: +Python 3.10, Python 3.11, Python 3.9 -Python 2.7, Python 3.4, 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

[issue45545] chdir __exit__ is not safe

[Jeremy]

Change by Jeremy :


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

___
Python tracker 

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

[issue45607] Make it possible to enrich an exception's error message

[Irit Katriel]

New submission from Irit Katriel :

The requirement comes from Hypothesis, see
https://github.com/python/cpython/pull/28569#discussion_r730338369

It is necessary there to add a note to an exception describing which test case 
it comes from. The note should be printed by __str__ of this exception. 


class Explanation(Exception):
__module__ = "builtins"
def __str__(self) -> str:
return f"\n{self.args[0]}"

try:
why = "Failed!"
raise AssertionError(why)
except Exception as e:
msg = "You can reproduce this error by ...\n..."
raise Explanation(msg) from e

# Ideally something more like:
e.__note__ = msg
raise

--
components: Interpreter Core
messages: 404999
nosy: iritkatriel
priority: normal
severity: normal
status: open
title: Make it possible to enrich an exception's error message
type: enhancement

___
Python tracker 

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

[issue15795] Zipfile.extractall does not preserve file permissions

[Selim Belhaouane]

Change by Selim Belhaouane :


--
nosy: +selimb

___
Python tracker 

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

[issue45466] Simple curl/wget-like download functionality in urllib (like http offers server)

[Terry J. Reedy]

Change by Terry J. Reedy :


--
nosy:  -terry.reedy

___
Python tracker 

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

Re: New assignmens ...

[Antoon Pardon]

Op 25/10/2021 om 20:39 schreef Chris Angelico:
> On Tue, Oct 26, 2021 at 5:35 AM Antoon Pardon  wrote:
>> By putting limits on the walrus code, you are not reducing complexity, you 
>> are increasing it.
>> You are increasing complexity because you can't just reuse the code that 
>> handles an ordinary
>> assignment. You now need specific code to limit it's use.
>>
> What does this code do?
>
> while x, y := foo():
> ...
>
> Is it more complicated or less complicated when arbitrary assignment
> targets are permitted?

Well I would guess it would do something similar to

while [x, y := foo()]:
...

-- 
https://mail.python.org/mailman/listinfo/python-list

[issue37658] In some cases asyncio.wait_for can lead to socket leak.

[Sam Bull]

Sam Bull  added the comment:

Can I get a review? 
https://github.com/python/cpython/pull/29202

Seems like a simple mistake given the original description of this issue:

> 1. the inner task is completed and the outer task will receive the result – 
> transport and protocol in this case
> 2. The inner task is cancelled and no connection was established

The try/except blocks clearly add a 3rd condition, where the inner task is 
completed and a TimeoutError is raised without returning the result.

--

___
Python tracker 

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

[issue45466] Simple curl/wget-like download functionality in urllib (like http offers server)

[Roundup Robot]

Change by Roundup Robot :


--
keywords: +patch
nosy: +python-dev
nosy_count: 2.0 -> 3.0
pull_requests: +27479
stage: test needed -> patch review
pull_request: https://github.com/python/cpython/pull/29217

___
Python tracker 

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

[issue45606] pathlib.Path.glob() does not list dangling symlink when pattern is the exact filenane

[Rasmus Bondesson]

New submission from Rasmus Bondesson :

Create a symlink that points to file that doesn't exist:

ln -s /nonexisting_file my_symlink

Then try to glob for that symlink from Python using pathlib:

python3
>>> import pathlib
>>> list(pathlib.Path(".").glob("my_symlink"))
[]
>>> list(pathlib.Path(".").glob("my_symlink*"))
[PosixPath('my_symlink')]

I'm a bit surprised that these two globs do not return the same results. 
Personally I would expect both to find the symlink.

Is this behaviour a bug or is it intentional?

--
components: Library (Lib)
messages: 404996
nosy: raek
priority: normal
severity: normal
status: open
title: pathlib.Path.glob() does not list dangling symlink when pattern is the 
exact filenane
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

[issue45592] NamespaceLoader does not implement create_module or exec_module

[Brett Cannon]

Brett Cannon  added the comment:

create_module() being empty is on purpose: 
https://docs.python.org/3/library/importlib.html#importlib.abc.Loader.create_module
 . You only define create_module() if you need a specific type of object for 
the module instance.

--

___
Python tracker 

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

[issue45438] inspect not capturing type annotations created by __class_getitem__

[Guido van Rossum]

Guido van Rossum  added the comment:

> The issue is that this feature is internally inconsistent (isinstance() is 
> not consistent with issubclass()),

issubclass(x, list[int]) rejects the second argument for reasons explained in 
the PEP. I don't think from that reasoning you can infer that list[int] is not 
a type. Rather the contrary -- if it's not a type the PEP could just have said 
"it's not a type" but it doesn't, it says "it's unacceptable as second arg to 
issubclass()". In fact, the PEP uses language ("instances of parameterized 
collections") that makes me think in the PEP author's mind list[int] *is* a 
type.

> the C implementation of list[int] is not consistent with the Python 
> implementation of List[int],

Consistency with typing was not a goal of the PEP.

> and a lot of code was not tested with this feature,

What other places are there that are broken because of this?

> so we perhaps have a lot of bugs in the stdlib and in the third-party 
> libraries.

Without more evidence this sounds like speculation. *With* evidence you might 
well convince me.

> Are we going to backport changes for making code working with GenericAlias as 
> a type to 3.9 and 3.10?

I'm fine with backporting the fix in the PR, GH-29212.

> If not, we will actually add new features in 3.11 and keep 3.9 and 3.10 
> broken. If yes, these changes can have larger effect than just making 
> isinstance(list[int], type) returning False, and they can break more code.

Are there other fixes you already know about besides GH-29212? That PR seems 
100% beneficial.

> Note also that isinstance(List[int], type) was True before 3.7, and we 
> intentionally made it False in 3.7 (it was required significant rewriting of 
> the typing module and introducing __mro_entries__). Do we want to revert this 
> decision?

I don't recall why we changed that, I thought it was a side effect of making 
the implementation faster, not because of a decision that we didn't want these 
to be treated as types. I looked at inspect.py in 3.6, and it seems its 
formatannotation() has a special case for annotations that come from the typing 
module (like List[int]). I guess nobody thought to have a test for that, so the 
bug in inspect.py slipped by when it was introduced in 3.9 -- we're relying on 
Raymond's keen eye here. But if we had had such a test, and it had alerted us 
to the problem in 3.9 when types.GenericAlias was introduced, I expect that we 
would have fixed it just like martinitus does in his PR.

Anyway, I am willing to be swayed by evidence, but this bug in inspect.py isn't 
enough.

--

___
Python tracker 

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

[issue45591] PathFinder does not find namespace packages children

[Brett Cannon]

Brett Cannon  added the comment:

You didn't specify the path to search in to find `a`. 
https://docs.python.org/3/library/importlib.html#importlib.machinery.PathFinder.find_spec
 says that PathFinder only has class methods, which means find_spec() won't 
know where 'namespace' is, so the search will fail to find anything, hence 
returning None.

--

___
Python tracker 

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

[issue45548] Update Modules/Setup

[Christian Heimes]

Christian Heimes  added the comment:


New changeset 2b8677a3cd855eb3a579894c64588eab0e006269 by Christian Heimes in 
branch 'main':
bpo-45548: FreeBSD doesn't like auto vars in makesetup (GH-29216)
https://github.com/python/cpython/commit/2b8677a3cd855eb3a579894c64588eab0e006269


--

___
Python tracker 

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

[issue45235] argparse does not preserve namespace with subparser defaults

[paul j3]

paul j3  added the comment:

I just downloaded this `argparse.py`.

This change makes it impossible to use a subparser argument if it is defined in 
the user provided namespace, or by the main parser.  It blocks not only 
subparser default, but also user input.

It has reverted the 9351 patch which dates to 2014.

--

___
Python tracker 

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

Re: New assignmens ...

[Chris Angelico]

On Tue, Oct 26, 2021 at 5:35 AM Antoon Pardon  wrote:
> By putting limits on the walrus code, you are not reducing complexity, you 
> are increasing it.
> You are increasing complexity because you can't just reuse the code that 
> handles an ordinary
> assignment. You now need specific code to limit it's use.
>

What does this code do?

while x, y := foo():
...

Is it more complicated or less complicated when arbitrary assignment
targets are permitted?

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue45595] [Build] Make extensions depend on header files

[Christian Heimes]

Change by Christian Heimes :


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

Re: New assignmens ...

[Antoon Pardon]

Op 25/10/2021 om 18:06 schreef Avi Gross via Python-list:
> Antoon,
>
> Just to be clear. I am talking about a different measure of efficiency.

No you are not.

>
> The topic here is the Python run-time parser though.

Yes and that is what I am talking about.

>  It is reading your code
> and doing whatever complex set of things it has to do to parse from a fairly
> large set of possible valid programs as well as invalid ones. I have never
> looked deeply at how it works but my guess is that somewhere in there are
> concepts like:
>
> simple_asignment_expression can look like THIS.
> complex _assignment expression can look like simple_assignment_expression OR
> THAT OR ...
>
> So to parse code you often need to look at alternate ways of connecting
> symbols and hopefully find the one and only way it has to be looked at.
> Parentheses as an example have many possible meanings and you may not know
> which meaning when you encounter it until you keep going and see where there
> may be a matching one but ignore any within a character string. I won't go
> on but the point is that the parser can jump through more hoops even in the
> most usual cases when it has to look for new cases not originally designed
> in.

IMO that extra complexity is insignificant. You really don't reduce the 
complexity of your
parser much if you would limit it so that indexes can only be names so that the 
programmer
instead of being able to write:

var = tab[some expression]

is forced to write it as:

index = some expression
var = tab[index]

Because all that machinery to evaluate some expression needs to be there anyway.

In the same way we have already all the machinery present for assignments.

By putting limits on the walrus code, you are not reducing complexity, you are 
increasing it.
You are increasing complexity because you can't just reuse the code that 
handles an ordinary
assignment. You now need specific code to limit it's use.

-- 
Antoon Pardon.

-- 
https://mail.python.org/mailman/listinfo/python-list

[issue45548] Update Modules/Setup

[Christian Heimes]

Change by Christian Heimes :


--
pull_requests: +27478
pull_request: https://github.com/python/cpython/pull/29216

___
Python tracker 

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

[issue45235] argparse does not preserve namespace with subparser defaults

[paul j3]

paul j3  added the comment:

I haven't studied or tested this change, but it looks like a partial retraction 
of

https://bugs.python.org/issue9351 
argparse set_defaults on subcommands should override top level set_defaults

Originally the main namespace was passed to the subparser.  Steven Bethard 
changed it so that the subparser got a fresh namespace, and all values were 
copied to the main namespace.

I and others raised the question of how it affected user provided values 

https://bugs.python.org/issue27859
argparse - subparsers does not retain namespace

Looks like this patch tries to solve some problems by moving the self._defaults 
step to the end of parser_know_args.  I view that change with some trepidation. 
 Handling defaults is tricky enough, with setting them at the start, but then 
only passing them through 'type' at the end if they still match the original 
strings.

Mostly I've been telling StackOverflow questioners that it best not to use the 
same argument 'dest' in both the main and subparsers.  Flags can be the same, 
but the 'dest' should be different to avoid conflicts over which default has 
priority.

Again, I haven't tested this change, but I have a gut feeling it could have 
backward compatibility issues.

--

___
Python tracker 

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

[issue43656] TracebackException or StackSummary.extract with capture_locals=True fail to catch exceptions raised by repr() on value of frame local variable in FrameSummary.__init__.

[Irit Katriel]

Irit Katriel  added the comment:

Martin, would you like to submit a patch with this addition to the doc?

--

___
Python tracker 

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

[issue43656] TracebackException or StackSummary.extract with capture_locals=True fail to catch exceptions raised by repr() on value of frame local variable in FrameSummary.__init__.

[Andrei Kulakov]

Andrei Kulakov  added the comment:

I've been thinking that perhaps it makes sense to special case printing of 
`self` argument in `__init__` methods. The same exact issue happens with PDB 
`args` command in `__init__` methods.

My idea is that in the __init__, you generally don't want to print `self`  arg 
and trying to do so can cause this type of unexpected errors.

The reason is that __repr__ is not designed to be used for objects with 
unfinished initialization, because even if it doesn't break, it will give you 
incomplete or even misleading representation.

In case when __init__ has some complex logic that can raise an exception, it's 
likely that other local variables will help you identify the object. If there 
is no complex logic or other arguments, and __init__ still failed, you can say 
that there wasn't yet an actual object that can be uniquely represented.

Therefore I think it makes sense to simply omit representing `self` arg (or 
first arg of the method) in both `StackSummary.extract()` and PDB `args` 
command. It may break some existing code but I think it would be a small amount 
of code affected. Because of this it can only go into 3.11 version. I feel like 
on the balance it would be a good change to make, but I'm curious to hear other 
opinions.

--

___
Python tracker 

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

[issue45548] Update Modules/Setup

[Christian Heimes]

Christian Heimes  added the comment:


New changeset ece916e92ce76cfdbfd208605a6fc827db0fbd52 by Christian Heimes in 
branch 'main':
bpo-45548: Add missing extensions to Modules/Setup (GH-29199)
https://github.com/python/cpython/commit/ece916e92ce76cfdbfd208605a6fc827db0fbd52


--

___
Python tracker 

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

[issue45595] [Build] Make extensions depend on header files

[Christian Heimes]

Christian Heimes  added the comment:


New changeset 81669d1b7bd668d1bd0fab92836e8b5e7976e362 by Christian Heimes in 
branch 'main':
bpo-45595: Make extensions depend on header files (GH-29198)
https://github.com/python/cpython/commit/81669d1b7bd668d1bd0fab92836e8b5e7976e362


--

___
Python tracker 

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

Re: what's unsafe to do in a __getattr__?

[Dieter Maurer]

Mats Wichmann wrote at 2021-10-24 19:10 -0600:
>Have run into a problem on a "mature" project I work on (there are many
>years of history before I joined), there are a combination of factors
>that combine to trigger a KeyError when using copy.copy().
> ...
>There's a class that's a kind of proxy ...

"Proxying" has become very difficult since the introduction
of Python's "new style classes" and looking up "special methods"
on the type rather then the type instance.

This essentially means that the proxy must implement all
"special methods" that may be relevant to the application.

All special methods start and end with `"__"`.
Your `__getattr__` could raise an `AttributeError` as soon as
it is called with such a name.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: New assignmens ...

[Chris Angelico]

On Tue, Oct 26, 2021 at 3:07 AM Avi Gross via Python-list
 wrote:
> I will end with this. If someone wants to design a new language from scratch
> and with a goal of starting with as general a set of concepts as they can,
> fine. Design it carefully. Build it and if it works well enough, use it.

I'll add to this: Please do exactly that! It's a great mental
exercise. Sometimes you'll end up using it as a domain-specific
language, or maybe it'll become a sort of ersatz command interpreter,
or something; other times, you do the work of designing it purely for
the effect of trying it, and you've learned how languages work.

What you'll find is that there are extremes that are utterly and
completely useless, such as Turing tarpits (almost no language
facilities, but technically possible to write anything), or things so
generic that they are nothing more than containers ("a script in this
language is whatever code will make it happen"). In between, every
programming language has to make decisions. What are its goals? What
kinds of problems should be easy to solve in this language? Is it
meant to be general-purpose and able to do most things, or
special-purpose but extremely elegant within its domain?

And along the way, you'll gain a better appreciation for every
language you work with, plus a mental comprehension that lets you
understand WHY this language or that language is good for some task.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: what's unsafe to do in a __getattr__?

[Mats Wichmann]

On 10/25/21 10:48, Dieter Maurer wrote:

Mats Wichmann wrote at 2021-10-24 19:10 -0600:

Have run into a problem on a "mature" project I work on (there are many
years of history before I joined), there are a combination of factors
that combine to trigger a KeyError when using copy.copy().
...
There's a class that's a kind of proxy ...


"Proxying" has become very difficult since the introduction
of Python's "new style classes" and looking up "special methods"
on the type rather then the type instance.

This essentially means that the proxy must implement all
"special methods" that may be relevant to the application.

All special methods start and end with `"__"`.
Your `__getattr__` could raise an `AttributeError` as soon as
it is called with such a name.



Thanks. Raising an AttributeError here was what I was going to propose 
so maybe I'll take your reply as validation I was on the right track.


This stuff was definitely defined in an era before the new-style 
classes, might have to examine some other proxying classes to make sure 
there aren't other holes...


thanks again,

-- mats
--
https://mail.python.org/mailman/listinfo/python-list

[issue33439] python-config.py should be part of the stdlib

[Gregory P. Smith]

Gregory P. Smith  added the comment:

`Misc/python-config.in` ultimately becomes a Python script that prints things 
to stdout.  It isn't written to be a module as is.  Any work to make it one is 
effectively writing entirely new code to do what it does.

To keep a single source of truth for `python-config` behavior instead of having 
two as we do today (as doko noted in bpo-16235), while still exposing the 
values it provides for use from Python I suggest:

1. Get rid of the `Misc/python-config.in` python code.
2. Use `Misc/python-config.sh.in` exclusively.
3. Enhancing _that_ to be able to generate a tiny data-only 
`sysconfig.configure` module. 
4. Invoke `python-config.sh --generate-sysconfig-bits` during build time to 
generate a `sysconfig/configure.py`.

This should reduce the maintenance burden and is kinder to cross-compiliation 
builds (which we generally are lousy at supporting despite their importance to 
the world, so our bar today is merely "not regressing").


All that said, in what contexts would having anything that python-config 
produces today be available from sysconfig be useful?

--
nosy: +gregory.p.smith

___
Python tracker 

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

Re: New assignmens ...

[Christman, Roger Graydon]

Message: 8
Date: Mon, 25 Oct 2021 11:20:52 +0200
From: Antoon Pardon 
To: python-list@python.org
Subject: Re: New assignmens ...
Message-ID: <5761dd65-4e87-8b8c-1400-edb821204...@vub.be>
Content-Type: text/plain; charset=utf-8; format=flowed
On 25/10/2021 11:20, Anton Pardon wrote:
> Suppose I would like to write a loop as follows:

 >while ((a, b) := next_couple(a, b))[1]:
 >do needed calculations


> What I can do is write it as follows:

> while [tmp := next_couple(a,b), a := tmp[0], b := tmp[1]][-1]:
 >do needed calculations

> I really don't see what is gained by "forcing" me to right the second code 
> over the first.

No, nobody is forcing you to right it the second way over the first.
Nobody is forcing you to use the walrus operator at all!

Instead, I would recommend something more like:

   while b:
 do needed calculations
 (a,b) = next_couple(a,b)

This requires even less typing than what you had before!

But it also raises a whole lot of problems with this particular example:
-- neither a nor b is defined in your sample while loop.   It seems you would
need to initialize a and b before your while loop (and mine)
-- is b truly a boolean value, or are you short-cutting some other value?
-- are a and b truly necessary parameters to next_couple, or are they just
there to remind the function of its previous return values?
If the latter, poerhaps you want a stream or list or something with yield

This example (and some of the others I have seen) just highlight how
programmers will take advantage of any new tool to help them write
worse code than if they did not have the tool.   In my mind, the walrus
operator was designed to serve a particular niche case like this one:

while (x := input()) > 0:

where not having the operator required duplicating the input() operation
both before the loop and at the end of the loop  -- or more complicated
cases where some additional operations had to be performed to get
that test value for the while condition (such as getting the b out of (a,b)).

But the walrus only adds a benefit if it is there to avoid the duplication
of the code that is used to obtain that test condition.   This next_couple
example does not qualify, since apparently (a,b) are initialized by some
other means (and not be a call to next_couple with undefined values)

Or the other abuse I saw recently about using the walrus operator:

while (self.ctr := self.ctr-1) > 0:

-- there was no compelling reason for a loop counter to be a class variable
(anyone who peeks at this counter when the loop is down would only see a zero)
-- this requires self.ctr to be initialized to a value one higher than the first
meaningful value (start at 11 if you want to count down from 10)
So my recommended alternative, which furthermore also takes less typing:

while ctr > 0:
  ...
  ctr = ctr-1

TL;DR:   The Walrus operator serves the purpose as described in its PEP
just as it is, and I see no compelling reason to expand its use.
It is there to reduce code size by eliminating a duplication of code,
If the code you write using the walrus operator is longer or more
complicated than the code would be without it, you are misusing it.

Roger Christman
Pennsylvania State University
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue45235] argparse does not preserve namespace with subparser defaults

[paul j3]

Change by paul j3 :


--
nosy: +paul.j3

___
Python tracker 

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

[issue45504] [argparse] Entering a partial config_parser flag works with subparsers

[paul j3]

paul j3  added the comment:

As a default option flags can be abbreviated (unless there's a conflict).  
Recent version have a allow_abbrev parameter that lets you turn this off.

--
nosy: +paul.j3

___
Python tracker 

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

[issue45275] Make argparse print description of subcommand when invoke help doc on subcommand

[paul j3]

paul j3  added the comment:

Are you expecting the subcommand help to show the 'help' line that the main 
help shows?

subparsers.add_parser('a', help='a help')

add_parser takes all of the parameters that `ArgumentParser` takes, including 
description and epilog.  

I don't think we need to add anything to add_parser.

--
nosy: +paul.j3

___
Python tracker 

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

[issue41592] Make _SubParsersAction public

[Eric Pederson]

Eric Pederson  added the comment:

But is _SubParsersAction really private if there are methods on it that are 
required to use (add_parser())?

--

___
Python tracker 

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

[issue45580] argparse.ArgumentParser.add_mutually_exclusive_group : metavar create parenthesis undefined behavior

[paul j3]

paul j3  added the comment:

The usage formatting is fragile, with many associated bug reports.  Until 
someone does a major rewrite, it is best to avoid special characters, 
especially `()` and `[]` in the `dest` or `metavar`.

Usage uses () to encolde mutually_exclusive_groups and [] to mark non-required 
arguments.  Don't confuse your users (or argparse) with other uses of these 
characters.

--
nosy: +paul.j3

___
Python tracker 

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

[issue41592] Make _SubParsersAction public

[paul j3]

paul j3  added the comment:

`add_argument` also returns a Action subclass object.  All of those subclasses 
are "private".  While that return reference is usually ignored, sometimes it is 
useful to it, assigning it to a variable or list.  The documentation could be 
clearer about access to Action objects.

--
nosy: +paul.j3

___
Python tracker 

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

[issue45548] Update Modules/Setup

[Christian Heimes]

Christian Heimes  added the comment:


New changeset 77e3f224d6ae6d38e5fc899fb5eaadf2b7c255a1 by Christian Heimes in 
branch 'main':
bpo-45548: Remove checks for finite and gamma (GH-29206)
https://github.com/python/cpython/commit/77e3f224d6ae6d38e5fc899fb5eaadf2b7c255a1


--

___
Python tracker 

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

[issue45605] Return False from __contains__ method if object not hashable for set and dict

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

This is a duplicate of issue18510. It was also discussed on the Python-Dev 
mailing list (maybe more than once). If you have some new arguments or 
something in past 8 years made the old arguments no longer valid please open a 
new discussion on the mailing list.

--
nosy: +serhiy.storchaka
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> dict.__contains__ and dict.keys().__contains__ raises exception 
instead of returning False

___
Python tracker 

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

[issue45587] argparse add_argument_group: distinguish title and description from **kwargs

[paul j3]

Change by paul j3 :


--
nosy: +paul.j3

___
Python tracker 

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

[issue24739] allow argparse.FileType to accept newline argument

[paul j3]

paul j3  added the comment:

Adding `newline` to `FileType` requires modifying both the `__init__` and 
`__call__` methods.  That's nearly the whole class.  I'd copy and edit, and 
forget about subclassing.

--

___
Python tracker 

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

[issue45438] inspect not capturing type annotations created by __class_getitem__

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Two years is not so long for a bug. We fixed 8-year and 12-year bugs.

The issue is that this feature is internally inconsistent (isinstance() is not 
consistent with issubclass()), the C implementation of list[int] is not 
consistent with the Python implementation of List[int], and a lot of code was 
not tested with this feature, so we perhaps have a lot of bugs in the stdlib 
and in the third-party libraries. Are we going to backport changes for making 
code working with GenericAlias as a type to 3.9 and 3.10? If not, we will 
actually add new features in 3.11 and keep 3.9 and 3.10 broken. If yes, these 
changes can have larger effect than just making isinstance(list[int], type) 
returning False, and they can break more code.

Note also that isinstance(List[int], type) was True before 3.7, and we 
intentionally made it False in 3.7 (it was required significant rewriting of 
the typing module and introducing __mro_entries__). Do we want to revert this 
decision?

--

___
Python tracker 

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

RE: New assignmens ...

[Avi Gross via Python-list]

Antoon,

Just to be clear. I am talking about a different measure of efficiency. If
you have code that handles a limited functionality properly it can be quite
simple. If you then expand the code to handle ever more situations, then it
may do things like a series of IF statements to determine which of many
things to do so it now takes a while to just reach the part that does the
most common case. I have seen people use code that knows what arguments to
expect and just does things simply, like adding two integers together. Then
the code is improved so it detects if either argument is floating point and
now does any needed conversions. Soon you add support for complex numbers or
character strings that look like "23" and then even parse "twelve dollars
and forty two cents" in English and then a few other languages. Next you
accept range objects and other things that make sense to add and accept an
undefined number of arguments and name the darn thing sum_everything() and
proudly show it off. It now has an amazing number of errors it can propagate
or warn about. But, you can still use it to add 2 and 2.

Now, yes, nobody needs a function to just add two numbers. If that bothers
you, make is add the absolute values or something a tad more interesting.
But the point is that any code that invokes sum_everything() may now pay a
penalty in terms of performance just in the beginning part where it tests
how many arguments it got, what types they are, and so on.

The topic here is the Python run-time parser though. It is reading your code
and doing whatever complex set of things it has to do to parse from a fairly
large set of possible valid programs as well as invalid ones. I have never
looked deeply at how it works but my guess is that somewhere in there are
concepts like:

simple_asignment_expression can look like THIS.
complex _assignment expression can look like simple_assignment_expression OR
THAT OR ...

So to parse code you often need to look at alternate ways of connecting
symbols and hopefully find the one and only way it has to be looked at.
Parentheses as an example have many possible meanings and you may not know
which meaning when you encounter it until you keep going and see where there
may be a matching one but ignore any within a character string. I won't go
on but the point is that the parser can jump through more hoops even in the
most usual cases when it has to look for new cases not originally designed
in.

Your argument that people using other techniques to get the functionality
they want is not really relevant as I do not deny it. My point is that the
most common ways NORMALLY used are the ones that drive the efficiency of a
system. So if adding functionality to include new cases/situations doubles
the time it takes to do the most common case and that is used 98% of the
time, then how much overall gain for the other 2% is needed to
counterbalance it?

I find a common pattern in software that often looks like extra layers
around a function call. There may be a function to create an object given a
character string argument like vector("integer", 1, 2, 3") or
vector("character", "a", "b") that lets you create all kinds of vectors.
Someone comes along with a bright idea to make programmers instead call
make_integer(1, 2, 3) and make_character("a", "b") and more like that. We
now have lots of new function that are just going to turn around and call
vector() with a different appropriate string as the first argument and pass
along the rest. We now have a function calling a second function. Yes, there
are many possible advantages here including ways to check if you are using
your code as intended. But there is overhead. And in a tight loop repeated
millions of times, can you blame a programmer who knows, if they just call
vector() directly, or perhaps a deeper function that vector() calls when it
knows it is using integers?

I will end with this. If someone wants to design a new language from scratch
and with a goal of starting with as general a set of concepts as they can,
fine. Design it carefully. Build it and if it works well enough, use it. But
to ask an existing language to add features or expand existing ones is not
at all the same thing and requires much more care. In python, you can find
areas that are a bit confusing such as how multiple inheritance in objects
is done. It can require some tweaking to make your objects in ways that the
right thing is inherited from the other objects the way you want if more
than one has the same method and you can have subtle errors. Arguably the
darn thing is too general and many other languages instead decide not to
support multiple inheritance and may use other interesting ways to get
similar functionality. But although this can be a very nice feature allowing
you to design quite sophisticated sets of objects that inherit all kinds of
nifty powers from other existing objects, it can be a drag on performance if
it does a search through a big mess to find the 

[issue45605] Return False from __contains__ method if object not hashable for set and dict

[Eric V. Smith]

Eric V. Smith  added the comment:

I don't have any code that would care, but if there's one thing I've learned in 
15 years of python core development, it's that this will break someone's code.

If you want more feedback, you should probably bring this up for discussion on 
the python-ideas mailing list.

--

___
Python tracker 

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

[issue45438] inspect not capturing type annotations created by __class_getitem__

[Guido van Rossum]

Guido van Rossum  added the comment:

I really don't recall if we even seriously considered what 
isinstance(list[int], type) should return. PEP 585 doesn't mention it. I 
presume it falls out of the way it's being tested and the way list[int] passes 
most attribute requests on to the origin (i.e., to list).

Given that this has returned True for two releases now I'm very reluctant to 
changing this now. So our best option is pursuing Serhiy's option 1, at least 
partially. The fix for the OP should be simple enough, right?

--

___
Python tracker 

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

[issue45605] Return False from __contains__ method if object not hashable for set and dict

[Андрей Казанцев]

Андрей Казанцев  added the comment:

Can you please specify in what cases we need to get an exception instead of 
False? It just seems very strange to me to rely on this behaviour.

--

___
Python tracker 

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

[issue45605] Return False from __contains__ method if object not hashable for set and dict

[Eric V. Smith]

Eric V. Smith  added the comment:

That seems like a pretty big change that could break a lot of existing code. I 
suggest writing a wrapper around "in" if you want this behavior.

--
nosy: +eric.smith

___
Python tracker 

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

[issue40915] multiple problems with mmap.resize() in Windows

[Tim Golden]

Change by Tim Golden :


--
keywords: +patch
pull_requests: +27477
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/29213

___
Python tracker 

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

[issue45605] Return False from __contains__ method if object not hashable for set and dict

[Андрей Казанцев]

New submission from Андрей Казанцев :

Now if do something like `[] in set()` python raise an exception, but if an 
object isn't hashable then we know for sure that it isn't in the set. Propose 
return False for these cases.

P.S. I would like to make a patch

--
components: Library (Lib)
messages: 404971
nosy: heckad
priority: normal
severity: normal
status: open
title: Return False from __contains__ method if object not hashable for set and 
dict
versions: Python 3.11

___
Python tracker 

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

[issue45438] inspect not capturing type annotations created by __class_getitem__

[Ivan Levkivskyi]

Ivan Levkivskyi  added the comment:

> Was it mistake to make isinstance(list[int], type) returning True?

What was the motivation for this? At first glance returning True looks wrong.

--

___
Python tracker 

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

[issue45436] test_tk.test_configure_type() fails with Tcl/Tk 8.6.11

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Are there changes in handling empty values for other options? If yes, we 
perhaps need to add version-dependent tests for empty values instead of just 
skipping this case.

--

___
Python tracker 

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

[issue45436] test_tk.test_configure_type() fails with Tcl/Tk 8.6.11

[E. Paine]

E. Paine  added the comment:

> Any word on the tk Menu type parameter change?

I haven't submitted a bug report yet and want to do a little more research 
before I do so (the Tcl ticket system is quite difficult to search)

--

___
Python tracker 

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

[issue45438] inspect not capturing type annotations created by __class_getitem__

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

There are two ways to fix the larger issue.

1. Make issubclass(types.GenericAlias, type) returning True, and also make 
isinstance(typing.List[int], type) returning True and 
issubclass(typing._GenericAlias, type) returning True, and analyze every place 
in the interpreter and the stdlib which calls isinstance(..., type) or 
issubclass(..., type) and ensure that they work with types.GenericAlias and 
typing._GenericAlias and their instances as well as with ordinary types, fix 
them and add tests for them. And perhaps do the same for types.UnionType, 
typing._UnionGenericAlias, typing.TypeVar, typing.NewType, etc, etc.

2. Make isinstance(list[int], type) returning False. It would be nice to ad 
also tests for the same cases as in option 1, but it is not so urgent, and I 
expect that in most cases the current behavior which matches the status quo is 
expected.

I tried to implement option 1, but it is just too much places, so it would take 
a large amount of time which I do not have right now. First than invest my time 
in this I want to make sure which option is desirable in long term.

Guido, Ivan, Ken Jin, what would you say?

--

___
Python tracker 

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