[issue43878] ./configure fails on Apple Silicon with coreutils uname
Keith Smiley added the comment: Someone nonchalantly updated these in https://github.com/python/cpython/commit/2fc857a5721a5b42bcb696c9cae1bbcc82a91b17 so this bug is now fixed -- stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue43878> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43878] ./configure fails on Apple Silicon with coreutils uname
Keith Smiley added the comment: I think given that this file seems to be updated occasionally anyways we should still land this. I agree with the sentiment that if this was a super specific fix just for this edge case maybe it wouldn't be worth it. -- ___ Python tracker <https://bugs.python.org/issue43878> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43878] ./configure fails on Apple Silicon with coreutils uname
Keith Smiley added the comment: Yep for sure, this is the first time I've hit a difference with uname specifically -- title: ./configure fails on Apple Silicon -> ./configure fails on Apple Silicon with coreutils uname ___ Python tracker <https://bugs.python.org/issue43878> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43878] ./configure fails on Apple Silicon
Keith Smiley added the comment: Thanks for checking, I was able to debug further and it turns out the actual issue is if you use `uname` from `coreutils`, you get different results: ``` % /opt/homebrew/opt/coreutils/libexec/gnubin/uname -p arm64 % /usr/bin/uname -p arm ``` I have this in my $PATH (not specifically for uname but for other coreutils binaries) which is what lead to this. This update fixes this because the newer config.sub version contains a case for `arm64` that didn't exist before https://github.com/python/cpython/pull/25450/files#diff-9c966208fd0a0c8e24a1526da6904887c378283b9b645b9740c19339884174d9R1107 So this isn't as big of an issue as I thought, but I still think it makes sense to update these files. -- ___ Python tracker <https://bugs.python.org/issue43878> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43878] ./configure fails on Apple Silicon
Keith Smiley added the comment: Thanks for taking a look. My limited understanding is also that these should be able to be updated separately from autoconf, and I feel slightly more confident knowing that in the past folks treated this update as trivial. It seems like the changes should be entirely additive, as in they support new triples but otherwise are API compatible. -- ___ Python tracker <https://bugs.python.org/issue43878> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43878] ./configure fails on Apple Silicon
Change by Keith Smiley : -- keywords: +patch pull_requests: +24179 stage: -> patch review pull_request: https://github.com/python/cpython/pull/25450 ___ Python tracker <https://bugs.python.org/issue43878> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43878] ./configure fails on Apple Silicon
New submission from Keith Smiley : It seems that Apple Silicon support has been added in https://github.com/python/cpython/pull/22855, but when I try to build locally I see this error: ``` % ./configure checking for git... found checking build system type... Invalid configuration `arm64-apple-darwin20.3.0': machine `arm64-apple' not recognized configure: error: /bin/sh ./config.sub arm64-apple-darwin20.3.0 failed ``` I went through the `autoreconf` instructions to see if the checked in configure script was outdated, but it doesn't seem to have fixed the issue. I was able to fix this locally by updating the config.sub and config.guess files (only the former was required but I noticed in previous updates that they were updated in lockstep). I'm a bit wary about that change because it doesn't seem like they are updated frequently (they haven't been in over 3 years), but I will submit it for discussion. -- components: Build messages: 391272 nosy: keith priority: normal severity: normal status: open title: ./configure fails on Apple Silicon type: compile error versions: Python 3.10, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue43878> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43220] Argparse: Explicit default required arguments with add_mutually_exclusive_group are rejected
Keith Smiley added the comment: Would someone be able to review this change? -- ___ Python tracker <https://bugs.python.org/issue43220> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43220] Explicit default required arguments with add_mutually_exclusive_group are rejected
Keith Smiley added the comment:
Here's an example outside of argparse showing this is caused by the `is`
comparison with interned string:
```
import sys
short_string = sys.argv[1]
short_default = '1'
long_string = sys.argv[2]
long_default = 'not-interned'
print(f"short comparisons: id1: {id(short_default)} id2: {id(short_string)},
eq: {short_default == short_string}, is: {short_default is short_string}")
print(f"long comparisons: id1: {id(long_default)} id2: {id(long_string)}, eq:
{long_default == long_string}, is: {long_default is long_string}")
```
```
% ./python.exe /tmp/foo.py 1 not-interned
short comparisons: id1: 4523386416 id2: 4523386416, eq: True, is: True
long comparisons: id1: 4524440064 id2: 4523395296, eq: True, is: False
```
--
___
Python tracker
<https://bugs.python.org/issue43220>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43220] Explicit default required arguments with add_mutually_exclusive_group are rejected
Change by Keith Smiley : -- keywords: +patch pull_requests: +23311 stage: -> patch review pull_request: https://github.com/python/cpython/pull/24526 ___ Python tracker <https://bugs.python.org/issue43220> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43220] Explicit default required arguments with add_mutually_exclusive_group are rejected
New submission from Keith Smiley :
With this code:
```
import argparse
parser = argparse.ArgumentParser()
group = parser.add_mutually_exclusive_group(required=True)
group.add_argument("--foo", default="1")
group.add_argument("--bar")
args = parser.parse_args()
print(args)
```
When you explicitly pass `--foo 1`, it is treated as if no argument was passed:
```
% python3 /tmp/bug.py --foo 1
usage: bug.py [-h] (--foo FOO | --bar BAR)
bug.py: error: one of the arguments --foo --bar is required
```
I can't tell if this behavior is intentional, but it was surprising to me. It
also seems to be somewhat based on the length of the default string. For
example on my macOS machine if I change the default to `longerstring` it does
not have this issue.
--
components: Library (Lib)
messages: 386934
nosy: keith
priority: normal
severity: normal
status: open
title: Explicit default required arguments with add_mutually_exclusive_group
are rejected
versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9
___
Python tracker
<https://bugs.python.org/issue43220>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
