[issue47257] add methods to get first and last elements of a range
paul rubin added the comment: Oh nice, I didn't realize you could do that. len(range) and bool(range) (to test for empty) also work. Ok I guess this enhancement is not needed. I will close ticket, hope that is procedurally correct, otherwise feel free to fix. Thanks. -- resolution: -> rejected stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue47257> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47257] add methods to get first and last elements of a range
New submission from paul rubin : Inspired by a question on comp.lang.python about how to deal with an int set composed of integers and ranges. Range objects like range(1,5,2) contain start, stop, and step values, but it's messy and potentially tricky to get the actual first and last values of the range. Examples: range(1,5,2) - first = 1, last = 3 range (5, 1, 2) - range is empty, first = last = None range(5, 1, -1) - first is 5, last is 2 Note in the case where the range is not empty, you can get the "last" by a messy calculation but it's easier to pick the first element from the reverse iterator. But then you might forget to catch the stopiteration exception in the case that the list is empty. The same goes for the first element, roughly. And constructing the iterators just to pick one element seems like unnecessary overhead. So it is better to have actual methods for these, with type Optional[int]. Then mypy should remind you to check for the empty case if you forget. -- messages: 416962 nosy: phr priority: normal severity: normal status: open title: add methods to get first and last elements of a range type: enhancement ___ Python tracker <https://bugs.python.org/issue47257> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47228] Document that naïve datetime objects represent local time
New submission from Paul Ganssle : Currently, the `datetime` documentation has this to say about naïve datetimes: > A naive object does not contain enough information to unambiguously locate > itself relative to other date/time objects. Whether a naive object represents > Coordinated Universal Time (UTC), local time, or time in some other timezone > is purely up to the program, just like it is up to the program whether a > particular number represents metres, miles, or mass. Naive objects are easy > to understand and to work with, at the cost of ignoring some aspects of > reality. This was accurate in Python 2.7, but as of Python 3, the picture is a bit more nuanced. `.astimezone()` and `.timestamp()` work for naïve datetimes, but they are treated as *system local times*. It is no longer really appropriate to use a naïve datetime to a datetime in any specific concrete time zone — instead, they should be considered either abstract datetimes for the purposes of calendar calculations, or they should be considered as representing the realization of that abstract datetime *in the current system locale*. This new behavior is referenced in, for example, the warning in `.utcnow()`: https://docs.python.org/3.10/library/datetime.html#datetime.datetime.utcnow We make reference to this in the documentation for `.timestamp()`: https://docs.python.org/3.10/library/datetime.html#datetime.datetime.timestamp and in `.astimezone()`: https://docs.python.org/3.10/library/datetime.html#datetime.datetime.astimezone, but the top level explanation makes no reference to it. I have written a blog post about *why* this is the case: https://blog.ganssle.io/articles/2022/04/naive-local-datetimes.html and made reference to this behavior in an earlier blog post about `utcnow`: https://blog.ganssle.io/articles/2019/11/utcnow.html, but I think it would be a good idea to revamp the official documentation to reflect this change in status (12 years or so after the change…) -- assignee: p-ganssle components: Documentation messages: 416778 nosy: belopolsky, p-ganssle priority: normal severity: normal stage: needs patch status: open title: Document that naïve datetime objects represent local time type: enhancement versions: Python 3.10, Python 3.11, Python 3.9 ___ Python tracker <https://bugs.python.org/issue47228> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47207] Switch datetime docstrings / documentation to using "Returns" rather than "Return"?
New submission from Paul Ganssle : In bpo-9305, Fred Drake recommends preferring `Returns ...` over the imperative `Return ...`: https://bugs.python.org/issue9305#msg110912 Currently we're pretty consistent about `Return ...`, which is consistent with PEP 257: https://peps.python.org/pep-0257/ That said, I actually think "Returns ..." sounds much better in the documentation, and I'd be happy to see it changed if others agree. I have spun this off from bpo-9305 so that we can unblock https://github.com/python/cpython/pull/31697. -- assignee: docs@python components: Documentation messages: 416628 nosy: belopolsky, docs@python, fdrake, p-ganssle, slateny priority: normal severity: normal status: open title: Switch datetime docstrings / documentation to using "Returns" rather than "Return"? versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue47207> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46614] Add option to output UTC datetimes as "Z" in `.isoformat()`
Paul Ganssle added the comment: I think this approach is probably the best we can do, but I could also imagine that users might find it to be confusing behavior. I wonder if there's any informal user testing we can do? I guess the ISO 8601 spec does call "Z" the "UTC designator", so `use_utc_designator` seems like approximately the right name. My main hesitation with this name is that I suspect users may think that `use_utc_designator` means that they *unconditionally* want to use `Z` — without reading the documentation (which we can assume 99% of users won't do) — you might assume that `dt.isoformat(use_utc_designator=True)` would translate to `dt.astimezone(timezone.utc).replace(tzinfo=None).isoformat() + "Z"`. A name like `utc_as_z` is definitely less... elegant, but conveys the concept a bit more clearly. Would be worth throwing it to a poll or something before merging. -- ___ Python tracker <https://bugs.python.org/issue46614> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47170] py launcher on windows opens new terminal window when parsing python script with shebang
Paul Moore added the comment: This is Windows (shell) behaviour. To avoid this, you need to add the .py extension to the PATHEXT environment variable. -- ___ Python tracker <https://bugs.python.org/issue47170> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43323] UnicodeEncodeError: surrogates not allowed when parsing invalid charset
John Paul Adrian Glaubitz added the comment: > Awesome, thanks! I'll give it a try later today or tomorrow. I have applied the patch and the problem seems to have been fixed. \o/ -- ___ Python tracker <https://bugs.python.org/issue43323> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43323] UnicodeEncodeError: surrogates not allowed when parsing invalid charset
John Paul Adrian Glaubitz added the comment: Awesome, thanks! I'll give it a try later today or tomorrow. -- ___ Python tracker <https://bugs.python.org/issue43323> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43323] UnicodeEncodeError: surrogates not allowed when parsing invalid charset
John Paul Adrian Glaubitz added the comment: Hi Serhiy! > The simple fix is to add UnicodeEncodeError to "except LookupError". But > there may be other places where we can get a similar error. They should be > fixed too. I would be very interested to test this as this issue currently blocks my use of offlineimap. Would you mind creating a proof-of-concept patch for me if it's not too much work? Thanks! -- ___ Python tracker <https://bugs.python.org/issue43323> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22628] Idle: Tree lines are spaced too close together.
Jean-Paul Calderone added the comment: This is still/again broken, probably because the "fixed" version still hard-codes all of the geometry values and these will certainly not be correct for all combinations of display dpi, font configuration, etc. Instead, `TreeNode.draw` and `TreeNode.drawtext` (at least) need to consider the size of the children and space them accordingly. -- nosy: +exarkun resolution: fixed -> status: closed -> open ___ Python tracker <https://bugs.python.org/issue22628> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46566] Support -3.11-arm64 in py.exe launcher
Paul Moore added the comment: > as well as potentially being able to be a script or .pyz launcher with a > simple rename. Would it be possible to also make the launcher work when prepended to a zipfile? That's a really useful use-case (make a zipapp automatically runnable, but still a single file) that at the moment needs a 3rd party launcher (Vinay's simple-launcher project). If not, then that's fine, but if we're already doing a significant rewrite that might be a good time to add it. -- ___ Python tracker <https://bugs.python.org/issue46566> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47002] argparse - "expected one argument" when used -: in argument
paul j3 added the comment:
'-1' and '-1.23' are recognized as numbers, and treated as arguments. '-1'
requires some special handling because it is allowed as a flag, as in
parser.add_argument('-1','--one')
'-1:00' on the other hand is no different from a string like '-foo'. Default
is to parse it as a flag. If you don't get this error
argument -f: expected one argument
you are likely to get:
error: unrecognized arguments: -1:23
This can probably be closed as a duplicate of:
https://bugs.python.org/issue9334
argparse does not accept options taking arguments beginning with dash
(regression from optparse)
--
___
Python tracker
<https://bugs.python.org/issue47002>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46682] python 3.10 Py_Initialize/Py_Main std path no longer includes site-packages
New submission from Paul Jaggi :
Have the following simple program:
#include
#include
using namespace std;
int main(int argc, char** argv) {
wchar_t* args[argc];
for(int i = 0; i < argc; ++i) {
args[i] = Py_DecodeLocale(argv[i], nullptr);
}
Py_Initialize();
const int exit_code = Py_Main(argc, args);
cout << "Exit code: " << exit_code << endl;
cout << "press any key to exit" << endl;
cin.get();
return 0;
}
When you run this program and in the console:
import sys
sys.path
for Python versions between 3.7-3.9, you get the installed python site-packages
by default. For Python 3.10, you don't. This happens on both windows and Mac.
Is this an intentional change?
--
components: C API
messages: 412848
nosy: pjaggi1
priority: normal
severity: normal
status: open
title: python 3.10 Py_Initialize/Py_Main std path no longer includes
site-packages
type: behavior
versions: Python 3.10
___
Python tracker
<https://bugs.python.org/issue46682>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46628] Can't install YARL
Paul Koning added the comment: Thanks, I'll pass the word to the yarl and aiohttp team (both have this issue). -- ___ Python tracker <https://bugs.python.org/issue46628> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46628] Can't install YARL
Paul Koning added the comment: The only dependency mentioned by the yarl documentation is multidict and installing that makes no difference. I see I can tell yarl to build a pure-python version to avoid compiling stuff. If I do that it installs. But what I actually wanted to do is install aiohttp, and that step fails with the exact same error message. Given that it works in 3.10 but fails in 3.11a4, it does seem there is something about the new code that is involved here. -- ___ Python tracker <https://bugs.python.org/issue46628> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46628] Can't install YARL
New submission from Paul Koning : Trying to install "aiohttp" with pip I get a compile error installing "yarl". I get the same error when I install just that module. But it installs fine on 3.10. This is on an Apple M1 (ARM64) machine. -- components: macOS files: yarl.log messages: 412453 nosy: ned.deily, pkoning, ronaldoussoren priority: normal severity: normal status: open title: Can't install YARL type: compile error versions: Python 3.11 Added file: https://bugs.python.org/file50602/yarl.log ___ Python tracker <https://bugs.python.org/issue46628> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35829] datetime: parse "Z" timezone suffix in fromisoformat()
Paul Ganssle added the comment: I don't think it's necessary to add a feature to `isoformat()` just for the purpose of being able to add the corresponding parser, particularly when the plan is to implement a much broader ISO 8601 parser for Python 3.11 (I've done most of the implementation in C already, I can share the progress I've made, particularly if someone else wants to pick up the baton there before I get back to it). That said, I think it's useful for `isoformat()` to be able to output UTC times as "Z", so we may as well do that as part of 3.11 anyway. I think that's a separate issue to discuss, so I've created bpo-46614 to hammer out the details. -- versions: +Python 3.11 -Python 3.8 ___ Python tracker <https://bugs.python.org/issue35829> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46614] Add option to output UTC datetimes as "Z" in `.isoformat()`
New submission from Paul Ganssle :
As part of bpo-35829, it was suggested that we add the ability to output the
"Z" suffix in `isoformat()`, so that `fromisoformat()` can both be the exact
functional inverse of `isoformat()` and parse datetimes with "Z" outputs. I
think that that's not a particularly compelling motivation for this, but I also
see plenty of examples of `datetime.utcnow().isoformat() + "Z"` out there, so
it seems like this is a feature that we would want to have *anyway*,
particularly if we want to deprecate and remove `utcnow`.
I've spun this off into its own issue so that we can discuss how to implement
the feature. The two obvious questions I see are:
1. What do we call the option? `use_utc_designator`, `allow_Z`, `utc_as_Z`?
2. What do we consider as "UTC"? Is it anything with +00:00? Just
`timezone.utc`? Anything that seems like a fixed-offset zone with 0 offset?
For example, do we want this?
>>> LON = zoneinfo.ZoneInfo("Europe/London")
>>> datetime(2022, 3, 1, tzinfo=LON).isoformat(utc_as_z=True)
2022-03-01T00:00:00Z
>>> datetime(2022, 6, 1, tzinfo=LON).isoformat(utc_as_z=True)
2022-06-01T00:00:00+01:00
Another possible definition might be if the `tzinfo` is a fixed-offset zone
with offset 0:
>>> datetime.timezone.utc.utcoffset(None)
timedelta(0)
>>> zoneinfo.ZoneInfo("UTC").utcoffset(None)
timedelta(0)
>>> dateutil.tz.UTC.utcoffset(None)
timedelta(0)
>>> pytz.UTC.utcoffset(None)
timedelta(0)
The only "odd man out" is `dateutil.tz.tzfile` objects representing fixed
offsets, since all `dateutil.tz.tzfile` objects return `None` when `utcoffset`
or `dst` are passed `None`. This can and will be changed in future versions.
I feel like "If the offset is 00:00, use Z" is the wrong rule to use
conceptually, but considering that people will be opting into this behavior, it
is more likely that they will be surprised by `datetime(2022, 3, 1,
tzinfo=ZoneInfo("Europe/London").isoformat(utc_as_z=True)` returning
`2022-03-01T00:00:00+00:00` than alternation between `Z` and `+00:00`.
Yet another option might be to add a completely separate function,
`utc_isoformat(*args, **kwargs)`, which is equivalent to (in the parlance of
the other proposal) `dt.astimezone(timezone.utc).isoformat(*args, **kwargs,
utc_as_z=True)`. Basically, convert any datetime to UTC and append a Z to it.
The biggest footgun there would be people using it on naïve datetimes and not
realizing that it would interpret them as system local times.
--
assignee: p-ganssle
components: Library (Lib)
messages: 412384
nosy: belopolsky, brett.cannon, p-ganssle
priority: normal
severity: normal
stage: needs patch
status: open
title: Add option to output UTC datetimes as "Z" in `.isoformat()`
type: enhancement
versions: Python 3.11
___
Python tracker
<https://bugs.python.org/issue46614>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46228] argparse docs: default for prog= in ArgumentParser() should be basename of argv[0], not argv[0], to match behaviour
Change by paul j3 : -- nosy: +paul.j3 ___ Python tracker <https://bugs.python.org/issue46228> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46101] argparse: using parents & subcommands, options can be ignored
Change by paul j3 : -- resolution: -> rejected stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46101> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46080] argparse.BooleanOptionalAction with default=argparse.SUPPRESS and help specified raises exception
Change by paul j3 : -- nosy: +paul.j3 ___ Python tracker <https://bugs.python.org/issue46080> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46440] ArgumentParser.parse_args exits on missing required argument with exit_on_error=False
paul j3 added the comment: Duplicate of https://bugs.python.org/issue41255 Argparse.parse_args exits on unrecognized option with exit_on_error=False -- nosy: +paul.j3 resolution: -> duplicate stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46440> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42982] Update suggested number of iterations for pbkdf2_hmac()
Paul Kehrer added the comment: NIST provides no official guidance on iteration count other than NIST SP 800-132 Appendix A.2.2, which states "The number of iterations should be set as high as can be tolerated for the environment, while maintaining acceptable performance." I can think of no better resource for what constitutes acceptable performance at the highest iteration count than popular packages like Django. Django's choice (and lack of evidence that they've had any cause to revert due to performance issues) argues that 390k iterations is a reasonable number in 2022. Certainly the 100k suggested in these docs as of 2013 is no longer best practice as we've seen 9 years of computational improvement in the intervening time. I would, additionally, suggest that the documentation recommend the use of scrypt where possible over any iteration count of PBKDF2, but increasing the iteration count is still a useful improvement to the docs! -- nosy: +reaperhulk ___ Python tracker <https://bugs.python.org/issue42982> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46447] datetime.isoformat() documentation does not point to the risk of using it with naive datetime objects
Paul Ganssle added the comment: Sorry I missed this! Thank you for taking the time to write this up and to make a PR. Unfortunately, I don't think I agree with the idea of warning about this. The warnings about `utcnow` and `utcfromtimestamp` are a problem because `utcnow` and `utcfromtimestamp` are intended to represent times in UTC, but they return datetimes that actually represent local times in the semantics of modern Python. Basically, these functions are dangerous not because they are using naïve datetimes, but because they are *mis*using naïve datetimes. The same can not be said of `.isoformat()`, which is doing the right thing when you use `datetime.now().isoformat()`. If you look at Wikipedia's article on ISO 8601 (which is pretty much the best resource on this, since ISO 8601 is itself paywalled and we never should have standardized on a proprietary standard in the first place), you'll see it says: > Local time (unqualified) > If no UTC relation information is given with a time representation, the time > is assumed to be in local time. While it may be safe to assume local time > when communicating in the same time zone, it is ambiguous when used in > communicating across different time zones. It may be that for the kind of programming you do, it doesn't make sense to use local datetimes in an interchange format — but it is a legitimate use case and there are definitely situations where it is very much the right thing to do, so I don't think we should warn against it in the `datetime.isoformat` documentation. There is *might* be some case for warning about this or something like it in the `datetime.now` documentation. The major use cases for naïve datetimes are things where you are working with system time or things where you are working with dates in the future — you don't want to specify that some event is going to happen at 2030-03-31T12:00Z if the actual event is planned for April 1, 2030 at 13:00 *London time*, because if, between now and then, the UK decides to cancel DST or move the start back a week, the event you've stored as a UTC time now longer represents what it was intended to represent. In a lot of cases `datetime.now()` will just be used as "what time is it now", which is not subject to that particular problem because by the time the datetime gets stored or used, `datetime.now()` is a date in the *past*, and can safely be converted to UTC for all time. Of course, if you are consuming a bunch of event dates stored in local time and you want to compare them to the current time, then `datetime.now()` would be appropriate. Similarly if you want to display the current time to a user on a given system (rather than logging or storing it), it would also make sense to do things like `print(datetime.now().isoformat())`, so there are definitely also legitimate use cases for `datetime.now()`. I'm inclined to say that we should *not* have a warning on `datetime.now()`, because we will give people warning fatigue if we do, and we definitely want people to see `now()` as the correct alternative to `utcnow()`. I am more sympathetic to rewording the `.now()` documentation to make it clear that this will be a naïve time *representing the current time in the system local time zone* if `None` is passed (i.e. rewording or appending to the "If optional argument `tz`" paragraph). -- nosy: +belopolsky, p-ganssle ___ Python tracker <https://bugs.python.org/issue46447> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46159] Segfault when using trace functions in 3.11a3
Paul Kehrer added the comment: Changes in ABI don't seem to be the likely culprit since the Dockerfile provided can demonstrate this bug and has no caching that would result in obtaining alpha2-based binaries. -- ___ Python tracker <https://bugs.python.org/issue46159> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29964] [doc] %z directive has no effect on the output of time.strptime
Change by Paul Pinterits : -- nosy: -Paul Pinterits ___ Python tracker <https://bugs.python.org/issue29964> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43323] UnicodeEncodeError: surrogates not allowed when parsing invalid charset
John Paul Adrian Glaubitz added the comment: I'm running into exactly this issue when using 'offlineimap' which is written in Python. -- nosy: +glaubitz ___ Python tracker <https://bugs.python.org/issue43323> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46303] _Py_stat and _Py_wstat using incorrect type for status argument
Paul Campbell added the comment: Victor: The changes in the main branch gets me past this issue without having to make additional changes. -- ___ Python tracker <https://bugs.python.org/issue46303> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46303] _Py_stat and _Py_wstat using incorrect type for status argument
Paul Campbell added the comment: > In Python, we are trying to provide a same C API on all platforms. If "struct > stat" is no longer considered as portable, IMO we should attempt to avoid it, > at least in the public C API. Microsoft provides stat and struct stat, but they prepend the names with an underscore. So functions like stat are named _stat and struct stat is named struct _stat, etc. Not sure if pros/cons of using such functions are though. Seems it would go back to depending on some type nonstandard python macro to translate between the two during build. -- ___ Python tracker <https://bugs.python.org/issue46303> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46303] _Py_stat and _Py_wstat using incorrect type for status argument
Paul Campbell added the comment: Hi Victor, I was trying to compile with clang on Windows 10. I will try to pull your 3.11 changes and test. Sorry to cause so much churn. It looked to me like a simple issue that was missed, probably because whatever was trying to compile was not normally compiled on Windows. I was not trying to make a lot of work to support a new platform :) -- ___ Python tracker <https://bugs.python.org/issue46303> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46303] _Py_stat and _Py_wstat using incorrect type for status argument
Paul Campbell added the comment: I was trying to build python core (-DMS_WINDOWS -DPy_BUILD_CORE). I was using clang, which I think is unsupported looking at Windows doc. After looking at the issue though, it seemed that it was just some slight mistake which is why I filed the bug. clang version 13.0.0 Target: x86_64-pc-windows-msvc Thread model: posix I can test to see if it fixes the immediate build problem, but I still find your fix not quite addressing the issue which I initially tried to create a patch for. Someone has already developed a shim here for Windows and it just was not used properly. `_Py_stat_struct` is a define which either evaluates to `stat` on non-Windows systems or a compatibility structure on Windows. Simply replacing the use of `struct stat` with `struct _Py_stat_struct` should solve the issue. -- ___ Python tracker <https://bugs.python.org/issue46303> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46057] argparse: embedded groups may prevent options from being in help output
paul j3 added the comment: "I tried to create a group hierarchy in a way that I can pass the responsibility of argument validation to the argument parser." I looked at your example in: https://bugs.python.org/issue46058 The many levels of nesting groups was confusing, but now I realize that by nesting argument_groups in a mutually_exlusive_group you were try to implement some sort of any/all group within the xor group. This cannot be done within argparse. Mutually_exclusive only implements a flat xor. Argument_groups are used for help display, but play no role in parsing. Some years ago I explored the use of nest parsing groups: https://bugs.python.org/issue11588 Add "necessarily inclusive" groups to argparse I was trying to allow for nested groups that implemented all logical options - xor, or, and, not. Defining such groups wasn't hard. And I think I got the testing logic working right. But usage display required too big of a change to the formatter, and left too many loose ends. So I have let that languish. Now I recommend focusing on doing the testing after parsing. Use meaningful defaults where possible, and use `is None` to test whether a users has provided a value or not. -- ___ Python tracker <https://bugs.python.org/issue46057> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46101] argparse: using parents & subcommands, options can be ignored
paul j3 added the comment: This patch should be rejected. By using `common_opts_parser` as parent to both the main and subparsers, you have defined the same argument in both. By a long standing patch, the value assigned in the subparser has precedence (whether it's the default or user supplied). https://bugs.python.org/issue9351 argparse set_defaults on subcommands should override top level set_defaults Partial retraction of this override has been explored, but any changes are still up for debate https://bugs.python.org/issue45235 argparse does not preserve namespace with subparser defaults The bottom line is that we should not try to define the same argument (or more specifically the same `dest`) in both main and subparsers. Duplicate flags are ok. But resolving the conflicting values should be done after parsing. Some users will want to give priority to the main parser's values, others to the subparser's. Or their own defaults. argparse cannot handle all cases cleanly. -- ___ Python tracker <https://bugs.python.org/issue46101> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12756] datetime.datetime.utcnow should return a UTC timestamp
Paul Ganssle added the comment: > from practical experience, it is a whole lot better to not deal with > timezones in data processing code at all, but instead only use naive UTC > datetime values everywhere, expect when you have to prepare reports or output > which has a requirement to show datetime value in local time or some specific > timezone. This is not good advice. It is out of date, and has some significant pitfalls. See my blog post on the subject: https://blog.ganssle.io/articles/2019/11/utcnow.html If you are working with `datetime` objects that represent time in a specific time zone other than the system local zone, you should probably have them carry around a tzinfo object. > Note also that datetime.now() gives you a naive datetime. From an API > consistency standpoint I think it makes sense that datetime.utcnow() gives a > naive datetime. This... is not accurate. `.now()` gives you the local time; to the extent that they represent a date in a time zone at all, naïve time zones represent times in the *system local time*, which is why it makes sense for `.now()` to default to returning naïve time zones. For example, `datetime.now().timestamp()` will give accurate information, whereas `datetime.utcnow().timestamp()` will *not* (unless your local zone happens to be UTC or equivalent). > It would actually be confusing (IMO) for it to return an aware datetime. I > can see why you might disagree, but backward compatibility wins in this case > regardless. As evidenced by this thread, the fact that we have some APIs that return naïve datetimes generated by a process that treats them as localized datetimes in something other than system local times is actually the source of confusion That said, from a backwards compatibility point of view, we simply cannot change this. It has been proposed many times and it would be a major breaking change for almost no reason. The best we can do is to deprecate the offending methods and remove them. There is more information about the challenge that doing this would present in this datetime-SIG thread: https://mail.python.org/archives/list/datetime-...@python.org/thread/PT4JWJLYBE5R2QASVBPZLHH37ULJQR43/ I am sympathetic to the idea of removing it, but we would probably want to put some optimizations in place for `UTC` first, to make the transition more seamless in the few places where there are legitimate uses for `utcnow` and `utcfromtimestamp`. > I would argue that PEP20 should win over backward compatibility, in addition > to the points I hinted at above, practicality beats purity PEP 20 contains a bunch of contradictory advice, and it's not really a binding document anyway, so it definitely doesn't "win" over anything, but in this case you have it backwards. "Purity" would be making a breaking change for the purposes of making the function do what a lot of people think it does, but doing so would actually be impractical, because it would cause a lot of work for people, and create a lot of ambiguity in what people meant when they wrote a given line of code. The practical things to do here would be to either do nothing (not break anything that works and try and guide people away from using `utcnow` — maybe get a linting rule added to `pylint` to warn against it), or to deprecate and remove the function. -- ___ Python tracker <https://bugs.python.org/issue12756> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46319] datetime.utcnow() should return a timezone aware datetime
Paul Ganssle added the comment: Yes, this is the documented behavior, including a warning against using UTC now in the documentation! There is some possibility of removing utcnow entirely as an "attractive nuisance", but I suspect that this will lead to much consternation and hand-wringing, and there are some legitimate uses for `utcnow`, so I haven't made it a high priority to have that particular fight... -- resolution: -> duplicate stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46319> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46303] _Py_stat and _Py_wstat using incorrect type for status argument
Change by Paul Campbell : -- title: _Py_stat using incorrect type for status argument -> _Py_stat and _Py_wstat using incorrect type for status argument ___ Python tracker <https://bugs.python.org/issue46303> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46303] _Py_stat using incorrect type for status argument
Change by Paul Campbell : -- keywords: +patch pull_requests: +28681 stage: -> patch review pull_request: https://github.com/python/cpython/pull/30478 ___ Python tracker <https://bugs.python.org/issue46303> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46303] _Py_stat using incorrect type for status argument
Change by Paul Campbell : -- components: +Build, Windows nosy: +paul.moore, steve.dower, tim.golden, zach.ware type: -> compile error ___ Python tracker <https://bugs.python.org/issue46303> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46303] _Py_stat using incorrect type for status argument
New submission from Paul Campbell : While attempting to embed the full cpython source in my application, I found that during compilation on Windows, there was a compilation issue due to struct stat not being defined. Taking a look at the file cpython/fileutils.h, it seems that the type of the status argument should be _Py_stat_struct instead of just stat to satisfy compilation for all supported platforms. -- messages: 410073 nosy: pacampbell priority: normal severity: normal status: open title: _Py_stat using incorrect type for status argument versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue46303> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34602] python3 resource.setrlimit strange behaviour under macOS
Jean-Paul Calderone added the comment: My understanding of the resolution of this ticket is that it is still not possible to use setrlimit with RLIMIT_STACK to raise the soft stack limit. Is that correct? In that case, the original bug report still seems valid and unresolved (and indeed, I am porting a project from Python 2.7 to Python 3.9 and on macOS it fails because it cannot raise the stack limit). -- nosy: +exarkun ___ Python tracker <https://bugs.python.org/issue34602> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46057] argparse: embedded groups may prevent options from being in help output
paul j3 added the comment: Don't add an argument_group to another argument_group. While input allows this nesting, the formatting is not designed to handle it. Nor does the documentation illustrate such nesting. Nesting a mutually_exclusive_group in an argument_group works because the exclusive_group is not used in formatting the help lines. The two class of groups have very different purposes. Note that the add_argument_group() method is defined for the parent _ActionsContainer class. ArgumentParser inherits from this, as do both of the group classes. While one could make a case for changing the group's inheritance of this method to Not-implemented, it's only a problem when users, like you, try to push for undocumented usage. In general argparse has a clean and powerful class structure. But it doesn't do a lot of checking and pruning, so there loose ends like this. The Action class and its subclasses is similarly powerful, with enough loose ends to allow adventurous users to hang themselves :). -- nosy: +paul.j3 ___ Python tracker <https://bugs.python.org/issue46057> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46058] argparse: arg groups and mutually exclusive groups behave inconsitently
paul j3 added the comment: At least until these latest deprecations, the only nesting that made sense was to put a mutually_exclusive_group inside an argument_group. This was a way of providing a title and description for the exclusive_group. (And not documented.) I don't know if that's still possible. 'required' only makes sense for the exclusive_group. I don't know what happens when one tries to give it to an argument_group. If it doesn't raise an error, I expect it to be ignored. argument_groups are only used for help formatting; they have no role in parsing. exclusive_groups are primarily a parsing checking tool. Usage formatting tries to display exclusive groups, but is easily broken. While mutually_exclusive_group is a subclass of argument_group (and that in turn a subclass of argument_container), very little usage or behavior is inherited. Don't expect any consistency. A key point, that is easily lost, is that all groups share the _actions list with the parser. When an argument is added a group (either kind), it is, in effect, added to the parser's _actions list. So when parsing, there's only one list of Actions. A group will also keep the Action in its own _group_actions list, which is used for formatting or for exclusive checking. But otherwise the _group_actions list not used for parsing. Another point, is that there are 2 default argument_groups. Thus every Action is in an _group_actions list. If an exclusive_group is not nested in an argument_group, its Actions will be added to one of the defaults (optionals or positionals). -- nosy: +paul.j3 ___ Python tracker <https://bugs.python.org/issue46058> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46101] argparse: using parents & subcommands, options can be ignored
Change by paul j3 : -- nosy: +paul.j3 ___ Python tracker <https://bugs.python.org/issue46101> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46124] Deprecation warning in zoneinfo module
Paul Ganssle added the comment: Jason's patch looks good to me, but I don't understand why Karthikeyan originally suggested using `normalize_path`. Trying to dig through exactly how `files().joinpath().open` is implemented has so many layers of indirection and abstract classes that I can't quite figure out if the two things are equivalent or not. Seems like `joinpath()` is the right thing to do, but does it have less validation than the `normalize_path` method? -- ___ Python tracker <https://bugs.python.org/issue46124> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46159] Segfault when using trace functions in 3.11a3
Change by Paul Kehrer : -- title: Segfault -> Segfault when using trace functions in 3.11a3 ___ Python tracker <https://bugs.python.org/issue46159> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46159] Segfault
New submission from Paul Kehrer : In Python 3.11a3 on Linux/x86_64 (failed to replicate on macOS, not attempted on Windows) the interpreter non-deterministically segfaults when running some code under coverage. This did not occur under 3.11a2. Looking at the backtrace from a core dump I see: #0 _PyFrame_FastToLocalsWithError (frame=0x7fedf9e1f608) at Objects/frameobject.c:903 #1 0x7fedfa15f593 in call_trampoline (tstate=0x55b767a44080, callback=0x7fedf8bbd9c0, This is the trace received if I use pure Python coverage (sys.settrace) while I get one inside coverage's ctracer if I use the native library. However, at the moment I don't believe the bug resides within coverage. Since stack frame optimization has been a focus in 3.11 could something have changed that is causing issues with sys.settrace/PyEval_SetTrace? I haven't managed to reduce this test case much but here's a somewhat messy dockerfile that can demonstrate it: FROM ubuntu:focal RUN apt-get update && apt-get install -y build-essential git cargo libffi-dev libssl-dev libsqlite3-dev zlib1g-dev curl RUN curl -OL https://www.python.org/ftp/python/3.11.0/Python-3.11.0a3.tgz && \ tar zxf Python-3.11* && \ cd Python-3.11* && \ ./configure --prefix=/opt && \ make -j4 && make install RUN /opt/bin/pip3 install tox && git clone https://github.com/pyca/cryptography RUN cd cryptography && /opt/bin/tox -e py311 -- messages: 409061 nosy: reaperhulk priority: normal severity: normal status: open title: Segfault type: crash versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue46159> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46060] Clarify asyncio.new_event_loop return value
Change by Paul Bryan : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46060> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46060] Clarify asyncio.new_event_loop return value
Change by Paul Bryan : -- keywords: +patch nosy: +pbryan nosy_count: 2.0 -> 3.0 pull_requests: +28299 stage: -> patch review pull_request: https://github.com/python/cpython/pull/30078 ___ Python tracker <https://bugs.python.org/issue46060> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46060] Clarify asyncio.new_event_loop return value
New submission from Paul Bryan : Currently, the documentation states it creates a new event loop; it should also indicate that it returns the newly created event loop. -- assignee: docs@python components: Documentation messages: 408425 nosy: docs@python, pbryan2 priority: normal severity: normal status: open title: Clarify asyncio.new_event_loop return value versions: Python 3.10, Python 3.11 ___ Python tracker <https://bugs.python.org/issue46060> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32683] isinstance is calling ob.__getattribute__ as a fallback instead of object.__class__.__get__
Paul Moore added the comment: I tend to agree with Steven and David here. You define __getattribute__ and so that's the behaviour you get when an attribute of the class is requested (whether by the system or by your code). The documentation (here: https://docs.python.org/3/reference/datamodel.html#object.__getattribute__) seems to support this view as well. Do you have a real-world example of code that is broken by this behaviour, or is this just a theoretical problem? Is it particularly hard to make the code work the way you want it to with the current behaviour? For example, # Don't intercept __class__ if attr == "__class__": return object.__getattribute__(self, attr) -- nosy: +paul.moore ___ Python tracker <https://bugs.python.org/issue32683> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41260] datetime, date and time: strftime method takes different keyword argument: fmt (pure) or format (C)
Paul Ganssle added the comment: Updating this issue to cover the problem in date, time and datetime. -- title: datetime: strftime method takes different keyword argument: fmt (pure) or format (C) -> datetime, date and time: strftime method takes different keyword argument: fmt (pure) or format (C) ___ Python tracker <https://bugs.python.org/issue41260> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45814] datetime.time.strftime: use the same function signature for C and Python implementations
Paul Ganssle added the comment: I think this is mostly a duplicate of bpo-41260, which has an open PR on it. I think that got lost in the shuffle, I'm sad we didn't fix it in Python 3.10. I think we should migrate all of these signatures that differ to whichever one the C implementation is using (I believe that's 3.11). I'm going to close that one and edit the other one to cover `time` and `date` as well. Thanks for the report Yevhenii! -- resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> datetime: strftime method takes different keyword argument: fmt (pure) or format (C) ___ Python tracker <https://bugs.python.org/issue45814> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40740] Missing api-ms-win-core-path-l1-1.0.dll for python-3.9.0b1-amd64.exe Under Win7
Paul Moore added the comment: Well, we don't support doing that - so I'm not sure what you want beyond the statement "it's not supported". If it works for you, then by all means use it, but you'll be on your own for any issues you encounter unless you can reproduce them in a "normal" supported installation. And I assume it goes without saying, don't do this in a production environment :-) -- ___ Python tracker <https://bugs.python.org/issue40740> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45673] argparse error with option with optional value
paul j3 added the comment: Put the required positional first $ myapp myfile -s or one of the store_true arguments $ myapp -s -j myfile I think $ myapp -s -- myfile will work as well, but that needs to be tested. The '-s' has to be followed by something won't be confused for an argument, such as nothing, or a flag. -- ___ Python tracker <https://bugs.python.org/issue45673> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45673] argparse error with option with optional value
paul j3 added the comment: https://bugs.python.org/issue9338 argparse optionals with nargs='?', '*' or '+' can't be followed by positionals As you can see this is an old issue, but still too big for a quick fix. As a general rule, don't use `nargs` like this where there's ambiguity as to how many values will be allocated to the argument. -- ___ Python tracker <https://bugs.python.org/issue45673> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45656] argparse bug: prefix_chars argument to add_argument_group doesn't really work
paul j3 added the comment:
prefix_chars is a parameter of the parent _ActionsContainer
class _ActionsContainer(object):
def __init__(self,
description,
prefix_chars,
argument_default,
conflict_handler):
super(_ActionsContainer, self).__init__()
self.description = description
self.argument_default = argument_default
self.prefix_chars = prefix_chars
self.conflict_handler = conflict_handler
add_argument is also a method in this class. It uses its own prefix_chars to
categorize arguments as optional/positional
chars = self.prefix_chars
if not args or len(args) == 1 and args[0][0] not in chars:
see also _get_optional_kwargs method.
class _ArgumentGroup(_ActionsContainer):
inherits from _ActionsContainer, and usually gets the prefix_chars from its
container (the parser)
update('prefix_chars', container.prefix_chars)
The parser is created with
class ArgumentParser(_AttributeHolder, _ActionsContainer):
and documents the use of prefix_chars.
In addition to passing prefix_chars to its Super, it uses
default_prefix = '-' if '-' in prefix_chars else prefix_chars[0]
to define the -h help argument.
Early in parsing, args strings are categorized as 'O' or 'A'. That is done in,
which uses:
def _parse_optional(self, arg_string):
# if it doesn't start with a prefix, it was meant to be positional
if not arg_string[0] in self.prefix_chars:
return None
def _get_option_tuples(self, option_string):
also uses the parser's own prefix_chars.
During parsing (several layers down)
def consume_optional(start_index):
# if the action is a single-dash option and takes no
# arguments, try to parse more single-dash options out
# of the tail of the option string
chars = self.prefix_chars
if arg_count == 0 and option_string[1] not in chars:
Here, the parser's own prefix_chars is used to handle the chained short-dash
options.
---
In sum, while Argument_Group can have its own prefix_chars, that is only used
for help formatting. It's the parser's prefix_chars that is used when parsing.
The group's chars is ignored.
The _ArgumentGroup__init__ suggests something more than simple inheritance may
have been intended for prefix_chars, but in practice all it affects is the
help.
I haven't seen this issue raised before, and since this group parameter is not
documented, I think it's safe to ignore it.
An alternative is to have add_argument_group (or _ArgumentGroup__init__)
explicitly reject the prefix_chars parameter.
--
___
Python tracker
<https://bugs.python.org/issue45656>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45690] Argparse exclusive group inside required exclusive group displays incorrectly
paul j3 added the comment: https://bugs.python.org/issue29553 Argparser does not display closing parentheses in nested mutex groups supposedly fixed the parentheses for nested groups. You can read its discussion and patches to see why it does not handle your case. I don't see any examples have required groups. [] is used for un-required, () for required. This patch did not change how the usage was generated. It just refined how excess [()] were removed. Proper handling of groups requires a major rewrite of the usage formatter. -- ___ Python tracker <https://bugs.python.org/issue45690> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45656] argparse bug: prefix_chars argument to add_argument_group doesn't really work
paul j3 added the comment: Use of 'prefix_chars' as a argument_group parameter is not documented, nor intended. If it does appear to work in the help formatting, it is probably the result of inheritance, since both ArgumentParser and Argument_group subclass a _Actions_Container class. I'd have to examine the code to see what's happening. Argument_groups are used only for help formatting, not for parsing. In any case, I don't think anything needs to be changed or fixed. -- nosy: +paul.j3 ___ Python tracker <https://bugs.python.org/issue45656> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45673] argparse error with option with optional value
paul j3 added the comment: This is too big of an example for this board; I think it should have been asked on StackOverFlow. Or maybe trimmed do to a more compact example. But in any case, this is normal behavior for argparse. Type checking, here 'int', is done after the string is allocated to the '-s' argument. Reserving that string for the required positional requires a form of look ahead that argparse does not currently do. I think there's an old bug/issue on the topic, but the fix was, if I remember correctly, too complex to simply drop in. I may look that up later. -- nosy: +paul.j3 ___ Python tracker <https://bugs.python.org/issue45673> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45690] Argparse exclusive group inside required exclusive group displays incorrectly
paul j3 added the comment: There was a bug/issue that addressed problems with nested mutually_exclusive_groups. It should be easy to find. The problem is that the usage formatter is brittle, building a string and then striping out "unnecessary" characters. I assume the fix handled the default case (not required), but apparently it missed this variation. I wasn't too involved with that, since in my opinion nesting these groups is useless, and should be avoided. You might as well use one union group. Test the parsing for yourself. -- nosy: +paul.j3 ___ Python tracker <https://bugs.python.org/issue45690> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9351] argparse set_defaults on subcommands should override top level set_defaults
paul j3 added the comment: A new patch, https://bugs.python.org/issue45235 has clobbered this patch. It has also exposed the inadequate unittesting for the case(s) where the 'dest' of main namespace, subparser namespace, user provided namespace overlap. -- ___ Python tracker <https://bugs.python.org/issue9351> ___ ___ 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 added the comment: I should study previous posts in more detail, but here are some thoughts on correctly handling user namespace. At the start of `parse_known_args`, there's a if namespace is None: namespace = Namespace() We need to hang on to a copy of this namespace, e.g. call it import copy orig_namespace = copy.copy(namespace) In _SubParsersAction.__call__, pass this copy to the subparser (instead of None): subnamespace, arg_strings = parser.parse_known_args(arg_strings, orig_namespace) for key, value in vars(subnamespace).items(): setattr(namespace, key, value) Prior to 9351, the main namespace was passed to the subparser namespace, arg_strings = parser.parse_known_args(arg_strings, namespace) The trick is to get orig_namespace from the main parse_known_args to SubParsersAction.__call__ method. in a 9351 post I explore the idea of allowing the user to specify a 'sub_namespace' for the subparser. https://bugs.python.org/msg230056 In any case, this is a complicated issue that needs careful thought and more extensive testing. I didn't entirely like the original 9351 change, but since that's been part of argparse for many years, we need to very careful about clobbering it. -- status: pending -> open ___ Python tracker <https://bugs.python.org/issue45235> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45631] missing unittests for overlapping dest when using subparsers
New submission from paul j3 : https://bugs.python.org/issue45235 argparse does not preserve namespace with subparser defaults was passed and put into the latest release with rather obvious buggy behavior. This means that the unittest file does not adequately test for overlapping 'dest' in the main and subparsers. It probably also does not test many (any?) cases of user provided namespace. Issue9351 added a test, but it only tested defaults set with parser.set_defaults(foo=1) xparser.set_defaults(foo=2) not the more common practice of setting defaults in add_argument. 45235 adds one test, but again only for xparser.set_defaults(foo=1) It doesn't test for user inputs, as with ['X','--foo=3'] -- messages: 405110 nosy: ALSchwalm, paul.j3, rhettinger priority: normal severity: normal stage: needs patch status: open title: missing unittests for overlapping dest when using subparsers ___ Python tracker <https://bugs.python.org/issue45631> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34046] subparsers -> add_parser doesn't support hyphen char '-'
paul j3 added the comment: Артём Иконников, developers and experienced users are familiar with other programs, such as 'svn' which is used as an example svn checkout, svn update, and svn commit Also the use of '--foo' as flagged/optional(s) argument is so familiar to developers, that it does nor occur us that new users might want to use that form here. While there's no explicit prohibition of using the dash, non of the examples use it. Examples are a good starting place when using new features. If this problem came up more often, I'd recommend modifying the `add_parser` method to raise an error if the user provides a dashed command name (or alias). -- ___ Python tracker <https://bugs.python.org/issue34046> ___ ___ 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
Change by paul j3 : -- stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue45504> ___ ___ 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
Change by paul j3 : -- stage: resolved -> test needed status: closed -> pending ___ Python tracker <https://bugs.python.org/issue45235> ___ ___ 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 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 <https://bugs.python.org/issue41592> ___ ___ 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 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
<https://bugs.python.org/issue45235>
___
___
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 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 <https://bugs.python.org/issue45235> ___ ___ 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 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 <https://bugs.python.org/issue45235> ___ ___ 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
Change by paul j3 : -- nosy: +paul.j3 ___ Python tracker <https://bugs.python.org/issue45235> ___ ___ 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 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 <https://bugs.python.org/issue45504> ___ ___ 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 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
<https://bugs.python.org/issue45275>
___
___
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 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 <https://bugs.python.org/issue45580> ___ ___ 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 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 <https://bugs.python.org/issue41592> ___ ___ 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
Change by paul j3 : -- nosy: +paul.j3 ___ Python tracker <https://bugs.python.org/issue45587> ___ ___ 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 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 <https://bugs.python.org/issue24739> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45553] The modules Scipy and Pandas don't install in Win11-64
Paul Moore added the comment: That's probably because you're using Python 3.10 (assuming the "version" tag you added is correct) and those libraries haven't released Windows binaries for Python 3.10 yet. You should wait for binaries to be released, and check with the projects themselves if you need an indication of timescales. It's not unusual for projects to take a few weeks to get binaries built after a new Python release. If this isn't the issue, please provide more details of what is wrong. -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue45553> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45515] Add reference to zoneinfo in the datetime module documetnation
Change by Paul Ganssle : -- keywords: +patch pull_requests: +27309 stage: -> patch review pull_request: https://github.com/python/cpython/pull/29038 ___ Python tracker <https://bugs.python.org/issue45515> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45515] Add reference to zoneinfo in the datetime module documetnation
New submission from Paul Ganssle : Right now the datetime documentation recommends using `dateutil.tz` for IANA time zones, but we should update this to point to `zoneinfo`. -- assignee: p-ganssle components: Documentation messages: 404207 nosy: p-ganssle priority: low severity: normal status: open title: Add reference to zoneinfo in the datetime module documetnation versions: Python 3.10, Python 3.11, Python 3.9 ___ Python tracker <https://bugs.python.org/issue45515> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35228] Index search in CHM help crashes viewer
Change by Stephen Paul Chappell : -- nosy: +Zero ___ Python tracker <https://bugs.python.org/issue35228> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45432] sys.argv is processed strangely under Windows
Paul added the comment: oh ok. thx -- ___ Python tracker <https://bugs.python.org/issue45432> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45432] sys.argv is processed strangely under Windows
New submission from Paul : here is my test file: ''' import sys print(sys.argv) ''' when I then try 'python test.py ^test' the ^ character is stripped away, this doesn't happen on Linux. This also doesn't happen if I put ^test in quotes (only ") the ' quotes don't work -- components: Windows messages: 403656 nosy: paul.moore, paulhippler21, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: sys.argv is processed strangely under Windows type: behavior versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue45432> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44571] itertools: takedowhile()
paul rubin added the comment: Bah, the above doesn't work in the cases where the iterator is empty or (different symptom) where the tail part is empty. Rather than posting a corrected version (unless someone wants it) I'll just say not to use that code fragment, but that the intended API still looks reasonable. I do support having some kind of solution but don't want to keep stretching out an already closed discussion unless people think there is more to say. -- ___ Python tracker <https://bugs.python.org/issue44571> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44571] itertools: takedowhile()
paul rubin added the comment: Oh wow, before_and_after will go into the itertools module per that patch? I found this issue while looking for a way to this, but had written the following implementation: def span(pred, xs): # split xs into two iterators a,b where a() is the prefix of xs # that satisfies the predicate, and b() is the rest of xs. # Similar to Data.List.Span in Haskell. ixs = iter(xs) t = None def a(): nonlocal t for x in ixs: if pred(x): yield x else: break t = x def b(): return itertools.chain([t], ixs) return a, b def tspan(): # test xs = [1,3,5,2,4,6,8] def odd(x): return x%2==1 # This should print [1,3,5] then [2,4,6,8] for p in span(odd, xs): print(list(p())) -- nosy: +phr ___ Python tracker <https://bugs.python.org/issue44571> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45414] pathlib.Path.parents negative indexing is wrong for absolute paths
Paul Ganssle added the comment:
This is a great bug report, but for anyone else who gets a bit lost in the
details, here's the core of the issue:
>>> p = Path("/1/2")
>>> q = Path("1/2")
>>> p.parents[-1] # This is correct
PosixPath('/')
>>> q.parents[-1]
PosixPath('.')
>>> p.parents[-2] # Should be PosixPath('/1')
PosixPath('/')
>>> q.parents[-2]
PosixPath('1')
>>> p.parents[-3] # Should be PosixPath('/1/2')
PosixPath('/1')
>>> q.parents[-3]
PosixPath('1/2')
I think a refactoring where '/' doesn't appear in ._parts would be a good idea
if we can get past Chesterton's Fence and determine that this was indeed not a
deliberate design decision (or at least one whose concerns no longer apply),
but at least in the short term, I agree that transforming negative indexes into
positive indices is the right, expedient thing to do.
We'll definitely want to make sure that we're careful about bad indices (and
add relevant tests), though, since it would be easy to get weird behavior where
too-large negative indexes start "wrapping around" (e.g. p.parents[-4] with
len(p._parents) == 3 → p.parents[-1]).
--
type: -> behavior
___
Python tracker
<https://bugs.python.org/issue45414>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45414] pathlib.Path.parents negative indexing is wrong for absolute paths
Change by Paul Ganssle : -- nosy: +p-ganssle ___ Python tracker <https://bugs.python.org/issue45414> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45267] New install Python 3.9.7 install of Sphinx Document Generator fails
Paul Broe added the comment: Good Morning: I was able to resolve the issue based on your assistance. I created this topic at github.com https://github.com/sphinx-doc/sphinx/issues/9669 Someone answered it and it was simple: Thank you so much. That was it. I thought it was looking for a package but I completely missed the fact that the package name was package. I can't connect to the internet from my machines. So, I have to download everything manually from PyPI. I added packages pyparsing and packaging ... And Building wheels for collected packages: sphinx Building wheel for sphinx (setup.py) ... done Created wheel for sphinx: filename=Sphinx-4.2.0-py3-none-any.whl size=3061858 sha256=c5b28f87749557dc8c06b9820c748d6c5e764e32f2f25620d08b3259993ea90a Stored in directory: /usr/opt/oracle/.cache/pip/wheels/31/d2/bc/aa1cbddf1cd38373f4632ab20b0e3400f 037bcf271b50b2397 Successfully built sphinx Installing collected packages: sphinx Successfully installed sphinx-4.2.0 You can close the issue.. It was not a python bug -- status: pending -> open ___ Python tracker <https://bugs.python.org/issue45267> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45267] New install Python 3.9.7 install of Sphinx Document Generator fails
New submission from Paul Broe : Brand new build of Python 3.9.7 on RHEL 7. Placed in /usr/local/python3 Created new python environment cd /usr/opt/oracle/ python3 -m venv py3-sphinx source /usr/opt/oracle/py3-sphinx/bin/activate Now verify that python is now linked to Python 3. In this virtual environment python python3 python -V Python 3.9.7 I installed all the pre-requisites correctly for Sphinx 4.2.0 See the output of the command in the attached file command: pip install -vvv --no-index --find-link=/usr/opt/oracle/downloads/python-addons sphinx -- components: Demos and Tools files: Sphinx install output.txt messages: 402472 nosy: pcbroe priority: normal severity: normal status: open title: New install Python 3.9.7 install of Sphinx Document Generator fails versions: Python 3.9 Added file: https://bugs.python.org/file50295/Sphinx install output.txt ___ Python tracker <https://bugs.python.org/issue45267> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41255] Argparse.parse_args exits on unrecognized option with exit_on_error=False
Change by paul j3 : -- Removed message: https://bugs.python.org/msg401554 ___ Python tracker <https://bugs.python.org/issue41255> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41255] Argparse.parse_args exits on unrecognized option with exit_on_error=False
paul j3 added the comment: In https://stackoverflow.com/questions/69108632/unable-to-catch-exception-error-for-argparse it looked like `exit_on_error` does not work when using subparsers. On on further thought, I realized that it has to included in the definition of the subparser. As with other `ArgumentParser` parameters, the subparsers does not inherit from the main parser. So it's basically a documentation issue. The `add_parser` method is described briefly as: which takes a command name and any ArgumentParser constructor arguments, and returns an ArgumentParser object that can be modified as usual. But as my experience shows, its relevance is easily missed, even by an experienced users. -- ___ Python tracker <https://bugs.python.org/issue41255> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41255] Argparse.parse_args exits on unrecognized option with exit_on_error=False
paul j3 added the comment: In https://stackoverflow.com/questions/69108632/unable-to-catch-exception-error-for-argparse we found that `exit_on_error` does not work when the error occurs in a subparser. Unless someone wants to take time to get this right, I think this feature should be removed. It's too buggy. -- ___ Python tracker <https://bugs.python.org/issue41255> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45148] ensurepip upgrade fails
Paul Moore added the comment: > I don't know technical details but i can successfully use this command: `pip > install --upgrade pip`. On Windows (and not under something like cygwin or msys, which have their own rules)? Anyway, it's not that important, the recommended approach is `python -m pip`, so whether using the non-recommended approach works or not doesn't really matter. > On pip's issues tracker i was suggested to use `ensurepip --upgrade`. Let's take that question back to the pip tracker. If you want the latest version of pip (as opposed to the bundled version) ensurepip isn't the right approach. -- ___ Python tracker <https://bugs.python.org/issue45148> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45148] ensurepip upgrade fails
Paul Moore added the comment: > You are wrong. Windows lets me update pip via pip. You have misinterpreted what you are seeing. > Should i create new issue for this? No, you should follow the correct process and use `python -m pip`, and not use pip directly. -- ___ Python tracker <https://bugs.python.org/issue45148> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45148] ensurepip upgrade fails
Change by Paul Moore : -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue45148> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45148] ensurepip upgrade fails
Paul Moore added the comment: >From the documentation: > upgrade indicates whether or not to upgrade an existing installation of an > earlier version of pip to the bundled version. Note the comment "to the bundled version". This command will not access the internet (also noted in the documentation) and so will not get a later version than the bundled one. To get the latest version of pip, you need to use /path/to/your/python -m pip install --upgrade pip Note: 1. You must *not* use the pip executable, you must use `python -m pip`, as the command will be upgrading the pip executable and Windows won't let you upgrade an executable you are using. 2. You should use the full path to your Python, or ensure by other means that you are running the correct copy of Python. This command only upgrades the copy of pip associated with the Python interpreter you use to run the upgrade command. -- ___ Python tracker <https://bugs.python.org/issue45148> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45110] argparse repeats itself when formatting help metavars
paul j3 added the comment: The idea of combining help features by defining a subclass that inherits from other subclasses was endorsed by the original developer (we could dig up an old bug/issue to prove that). The provided subclasses all tweak a "private" method, often one that's buried deep in the calling stack. I can't quote any official policy, but my sense is that Python developers are ok with users subclassing and modifying "private" methods. Methods, functions and classes (and variables) with leading '_' aren't documented, or imported via `__all__`, but otherwise the boundary between what is part of the user API and what's "hidden" is loose in Python. Apparently some corporate policies prohibit use or modification of things that aren't in the public API, but I don't think that policy protects you from changes. 'argparse' changes at a glacial rate, with a lot of concern for backward compatibility. In fact it's that fear of unintended consequences that slows down the pace of change. Subclassing a help formatter is preferred because it minimizes the chance of hurting existing users. -- ___ Python tracker <https://bugs.python.org/issue45110> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45110] argparse repeats itself when formatting help metavars
paul j3 added the comment: https://bugs.python.org/issue42980 argparse: GNU-style help formatter https://bugs.python.org/issue33389 argparse redundant help string https://bugs.python.org/issue29626 Issue with spacing in argparse module while using help https://bugs.python.org/issue27303 [argparse] Unify options in help output https://stackoverflow.com/questions/23936145/python-argparse-help-message-disable-metavar-for-short-options https://stackoverflow.com/questions/18275023/dont-show-long-options-twice-in-print-help-from-argparse -- ___ Python tracker <https://bugs.python.org/issue45110> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45110] argparse repeats itself when formatting help metavars
paul j3 added the comment: This is has been requested various times on StackOverflow, and possibly here (I'd have to do a search). The closest thing to making a compact action_invocation is to set the metavar to '', and even thing we get a space, eg. -f , --foo Help text This repeat has been a part of argparse from the beginning, so I can't see changing the default behavior. But we could add a HelpFormatter subclass that changes one (or two methods) such as _format_action_invocation. Subclassing the formatter is the accepted way of adding help features. I, and possibly others, must have suggested such a change on SO. Of course people can use such a subclass without it being part of the standard module. -- ___ Python tracker <https://bugs.python.org/issue45110> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44587] argparse BooleanOptionalAction displays default=SUPPRESS unlike other action types
Change by paul j3 : -- nosy: +paul.j3 ___ Python tracker <https://bugs.python.org/issue44587> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
