[issue46637] Incorrect error message: "missing 1 required positional argument"
Anders Hovmöller added the comment: For `foo(a, /, b)`, it could be: "TypeError: foo() missing 1 required argument 'a', and one required positional argument 'b'. If we start on this road there are some more, like for `def foo(a, *, b)` you get the error "TypeError: foo() missing 1 required positional argument: 'a'" which leaves out that the keyword only argument is also required. Another solution would be something like: TypeError: foo() missing 3 required arguments: 'a' (positional only), 'b', 'c' (keyword only) This solution scales to the worst complex cases, and is a lot clearer imo. Could even be further improved with some nicer formatting: TypeError: foo() missing 3 required arguments: 'a' (positional only) 'b' 'c' (keyword only) But that might be a bit overkill :) -- ___ Python tracker <https://bugs.python.org/issue46637> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46637] Incorrect error message: "missing 1 required positional argument"
Anders Hovmöller added the comment: Just dropping the word "positional" is very good. That word is a lie, and just removing it makes it true. -- ___ Python tracker <https://bugs.python.org/issue46637> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46637] Incorrect error message: "missing 1 required positional argument"
New submission from Anders Hovmöller : >>> def foo(a): ... pass ... >>> foo() Traceback (most recent call last): File "", line 1, in TypeError: foo() missing 1 required positional argument: 'a' This error is incorrect. It says "positional argument", but it's just "argument". The proof is that if you call it with foo(a=3) it works fine. -- components: Interpreter Core messages: 412510 nosy: Anders.Hovmöller priority: normal severity: normal status: open title: Incorrect error message: "missing 1 required positional argument" type: enhancement versions: Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue46637> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32308] Replace empty matches adjacent to a previous non-empty match in re.sub()
Anders Hovmöller added the comment: We were also bitten by this. In fact we still run a compatibility shim in production where we log if the new and old behavior are different. We also didn't think this "bug fix" made sense or was treated with the appropriate gravity in the release notes. I understand the logic in the bug tracker and they it matches other languages is good. But the bahvior also makes no sense for the .* case unfortunately. > On 21 Jan 2020, at 05:56, David Barnett wrote: > > > David Barnett added the comment: > > We were also bitten by this behavior change in > https://github.com/google/vroom/issues/110. I'm kinda baffled by the new > behavior and assumed it had to be an accidental regression, but I guess not. > If you have any other context on the BDFL conversation and reasoning for > calling this behavior correct, I'd love to see additional info. > > -- > nosy: +mu_mind > > ___ > Python tracker > <https://bugs.python.org/issue32308> > ___ -- ___ Python tracker <https://bugs.python.org/issue32308> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32308] Replace empty matches adjacent to a previous non-empty match in re.sub()
Anders Hovmöller added the comment: That might be true, but that seems like a weak argument. If anything, it means those others are broken. What is the logic behind "(.*)" returning the entire string (which is what you asked for) and exactly one empty string? Why not two empty strings? 3? 4? 5? Why not an empty string at the beginning? It makes no practical sense. We will have to spend considerable effort to work around this change and adapt our code to 3.7. The lack of a discussion about backwards compatibility in this, and the other, thread before making this change is also a problem I think. -- ___ Python tracker <https://bugs.python.org/issue32308> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32308] Replace empty matches adjacent to a previous non-empty match in re.sub()
Anders Hovmöller added the comment: Just as a comparison, sed does the 3.6 thing: > echo foo | sed 's/\(.*\)/x\1y/g' xfooy -- ___ Python tracker <https://bugs.python.org/issue32308> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32308] Replace empty matches adjacent to a previous non-empty match in re.sub()
Anders Hovmöller added the comment:
This was a really bad idea in my opinion. We just found this and we have no way
to know how this will impact production. It's really absurd that
re.sub('(.*)', r'foo', 'asd')
is "foo" in python 1 to 3.6 but 'foofoo' in python 3.7.
--
nosy: +Anders.Hovmöller
___
Python tracker
<https://bugs.python.org/issue32308>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36485] Add a way to clear all caches
Anders Hovmöller added the comment: I think this is a great idea. We would have needed this many times for tests over the years. -- nosy: +Anders.Hovmöller ___ Python tracker <https://bugs.python.org/issue36485> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22490] Using realpath for __PYVENV_LAUNCHER__ makes Homebrew installs fragile
Anders Hovmöller added the comment: I just discovered this ticket again and see that it's stuck! I have read through the thread but it's still a bit unclear what would be required to test this with homebrew like Guido says is needed for this to go forward. Is there anyone who can explain or better yet test? -- ___ Python tracker <https://bugs.python.org/issue22490> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34861] Improve cProfile standard output
Anders Hovmöller added the comment: Output before this patch: 3666 function calls (3556 primitive calls) in 0.005 seconds Ordered by: standard name ncalls tottime percall cumtime percall filename:lineno(function) 20.0000.0000.0020.001 :1009(_handle_fromlist) 70.0000.0000.0000.000 :103(release) 50.0000.0000.0000.000 :143(__init__) 50.0000.0000.0000.000 :147(__enter__) 50.0000.0000.0000.000 :151(__exit__) 70.0000.0000.0000.000 :157(_get_module_lock) 50.0000.0000.0000.000 :176(cb) 20.0000.0000.0000.000 :194(_lock_unlock_module) 7/10.0000.0000.0030.003 :211(_call_with_frames_removed) 530.0000.0000.0000.000 :222(_verbose_message) 50.0000.0000.0000.000 :307(__init__) 50.0000.0000.0000.000 :311(__enter__) 50.0000.0000.0000.000 :318(__exit__) 200.0000.0000.0000.000 :321() 40.0000.0000.0000.000 :35(_new_module) 50.0000.0000.0000.000 :369(__init__) 90.0000.0000.0000.000 :403(cached) 70.0000.0000.0000.000 :416(parent) 50.0000.0000.0000.000 :424(has_location) 50.0000.0000.0000.000 :504(_init_module_attrs) 50.0000.0000.0000.000 :576(module_from_spec) 50.0000.0000.0000.000 :58(__init__) 5/10.0000.0000.0040.004 :663(_load_unlocked) 50.0000.0000.0000.000 :719(find_spec) 70.0000.0000.0000.000 :78(acquire) 50.0000.0000.0000.000 :792(find_spec) 150.0000.0000.0000.000 :855(__enter__) 150.0000.0000.0000.000 :859(__exit__) 50.0000.0000.0010.000 :882(_find_spec) 5/10.0000.0000.0040.004 :948(_find_and_load_unlocked) 5/10.0000.0000.0040.004 :978(_find_and_load) 10.0000.0000.0000.000 :1072(__init__) 10.0000.0000.0000.000 :1083(create_module) 10.0000.0000.0000.000 :1091(exec_module) 10.0000.0000.0000.000 :1233(_path_hooks) 120.0000.0000.0000.000 :1246(_path_importer_cache) 50.0000.0000.0010.000 :1283(_get_spec) 50.0000.0000.0010.000 :1315(find_spec) 10.0000.0000.0000.000 :1362(__init__) 80.0000.0000.0000.000 :1368() 50.0000.0000.0000.000 :1394(_get_spec) 100.0000.0000.0010.000 :1399(find_spec) 10.0000.0000.0000.000 :1447(_fill_cache) 10.0000.0000.0000.000 :1476() 10.0000.0000.0000.000 :1488(path_hook_for_FileFinder) 80.0000.0000.0000.000 :282(cache_from_source) 100.0000.0000.0000.000 :36(_relax_case) 50.0000.0000.0000.000 :412(_get_cached) 40.0000.0000.0000.000 :444(_check_name_wrapper) 40.0000.0000.0000.000 :481(_classify_pyc) 120.0000.0000.0000.000 :51(_r_long) 40.0000.0000.0000.000 :514(_validate_timestamp_pyc) 510.0000.0000.0000.000 :56(_path_join) 40.0000.0000.0000.000 :566(_compile_bytecode) 510.0000.0000.0000.000 :58() 50.0000.0000.0000.000 :617(spec_from_file_location) 80.0000.0000.0000.000 :62(_path_split) 230.0000.0000.0000.000 :74(_path_stat) 40.0000.0000.0000.000 :762(create_module) 4/10.0000.0000.0040.004 :765(exec_module) 40.0000.0000.0010.000 :836(get_code) 90.0000.0000.0000.000 :84(_path_is_mode_type) 40.0000.0000.0000.000 :927(__init__) 80.0000.0000.0000.000 :93(_path_isfile) 40.0000.0000.0000.000 :952(get_filename) 40.0000.0000.0000.000 :957(get_data) 10.0000.0000.0000.000 :98(_path_isdir) 40.0000.0000.0000.000 :994(path_stats) 1000.0000.0000.0010.000 __init__.py:183(dumps) 10.0000.0000.0030.003 __init__.py:97() 10.0000.0000.0020.002 decoder.py:2() 10.0000.0000.0000.000 decoder.py:20(JSONDecodeError) 10.0000.0000.0000.000 decoder.py:254(JSONDecoder) 10.0000.0000.0000.000
[issue34861] Improve cProfile standard output
Anders Hovmöller added the comment: There is an example output on github. Should I paste it here too? I can do it once I get home if you want. -- ___ Python tracker <https://bugs.python.org/issue34861> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34861] Improve cProfile standard output
Change by Anders Hovmöller : -- keywords: +patch pull_requests: +9046 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue34861> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34861] Improve cProfile standard output
New submission from Anders Hovmöller : The standard output for cProfile when run from a command line is not very useful. It has two main flaws: - Default sort order is by name of function - It strips the full path of source files The first makes it very hard to look at the output. The second is very annoying when you get a bunch of __init__.py in the output. Suggested solution: - Default cumulative time sort order - Show one additional folder level when filename is __main__ or __init__ -- components: Library (Lib) messages: 326793 nosy: Anders.Hovmöller priority: normal severity: normal status: open title: Improve cProfile standard output type: enhancement versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue34861> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22490] Using realpath for __PYVENV_LAUNCHER__ makes Homebrew installs fragile
Change by Anders Hovmöller : -- nosy: +Anders.Hovmöller ___ Python tracker <https://bugs.python.org/issue22490> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22490] Using realpath for __PYVENV_LAUNCHER__ makes Homebrew installs fragile
Change by Anders Hovmöller : -- versions: +Python 3.6 ___ Python tracker <https://bugs.python.org/issue22490> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15873] datetime: add ability to parse RFC 3339 dates and times
Anders Hovmöller added the comment: @larsonreever That lib is pretty limited, in that it doesn't handle dates or deltas. Again: my lib that is linked above does and has comprehensive tests. -- ___ Python tracker <http://bugs.python.org/issue15873> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15873] datetime: add ability to parse RFC 3339 dates and times
Anders Hovmöller added the comment: Hmm, ok. I guess I was confused by "dates and times" part of the subject. Ok, so only datetimes. My other comments still apply though. > On 19 Jul 2016, at 16:20, Mathieu Dupuy wrote: > > > Mathieu Dupuy added the comment: > > because it limits itself to only support the RFC 3339 subset, as > explained in the begining of the discussion. > > 2016-07-19 16:07 GMT+02:00 Anders Hovmöller : >> >> Anders Hovmöller added the comment: >> >> The tests attached to this ticket seem pretty bare. Issues that I can spot >> directly: >> >> - only tests for datetimes, not times or dates >> - only tests for zulu and "-8:00” timezones >> - no tests for invalid input (parsing a valid date as a datetime for example) >> - only tests for -MM-DDTHH:MM:SSZ, but ISO8601 supports: >>- Naive times >>- Timezone information (specified as offsets or as Z for 0 offset) >>- Year >>- Year-month >>- Year-month-date >>- Year-week >>- Year-week-weekday >>- Year-ordinal day >>- Hour >>- Hour-minute >>- Hour-minute >>- Hour-minute-second >>- Hour-minute-second-microsecond >>- All combinations of the three "families" above! >> (the above list is a copy paste from my project that implements all ISO8601 >> that fits into native python: https://github.com/boxed/iso8601 >> <https://github.com/boxed/iso8601>) >> >> This is a more reasonable test suite: >> https://github.com/boxed/iso8601/blob/master/iso8601.py#L166 >> <https://github.com/boxed/iso8601/blob/master/iso8601.py#L166> although it >> lacks the tests for bogus inputs. >> >>> On 2016-07-16, at 03:41, Alexander Belopolsky >>> wrote: >>> >>> >>> Alexander Belopolsky added the comment: >>> >>> I would very much like to see this ready before the feature cut-off for >>> Python 3.6. Could someone post a summary on python-ideas to get a show of >>> hands on some of the remaining wrinkles? >>> >>> I would not worry about a C implementation at this point. We can put >>> python implementation in _strptime.py and call it from C as we do for the >>> strptime method. >>> >>> -- >>> >>> ___ >>> Python tracker >>> <http://bugs.python.org/issue15873> >>> ___ >> >> -- >> >> ___ >> Python tracker >> <http://bugs.python.org/issue15873> >> ___ > > -- > > ___ > Python tracker > <http://bugs.python.org/issue15873> > ___ -- ___ Python tracker <http://bugs.python.org/issue15873> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15873] datetime: add ability to parse RFC 3339 dates and times
Anders Hovmöller added the comment: The tests attached to this ticket seem pretty bare. Issues that I can spot directly: - only tests for datetimes, not times or dates - only tests for zulu and "-8:00” timezones - no tests for invalid input (parsing a valid date as a datetime for example) - only tests for -MM-DDTHH:MM:SSZ, but ISO8601 supports: - Naive times - Timezone information (specified as offsets or as Z for 0 offset) - Year - Year-month - Year-month-date - Year-week - Year-week-weekday - Year-ordinal day - Hour - Hour-minute - Hour-minute - Hour-minute-second - Hour-minute-second-microsecond - All combinations of the three "families" above! (the above list is a copy paste from my project that implements all ISO8601 that fits into native python: https://github.com/boxed/iso8601 <https://github.com/boxed/iso8601>) This is a more reasonable test suite: https://github.com/boxed/iso8601/blob/master/iso8601.py#L166 <https://github.com/boxed/iso8601/blob/master/iso8601.py#L166> although it lacks the tests for bogus inputs. > On 2016-07-16, at 03:41, Alexander Belopolsky wrote: > > > Alexander Belopolsky added the comment: > > I would very much like to see this ready before the feature cut-off for > Python 3.6. Could someone post a summary on python-ideas to get a show of > hands on some of the remaining wrinkles? > > I would not worry about a C implementation at this point. We can put python > implementation in _strptime.py and call it from C as we do for the strptime > method. > > -- > > ___ > Python tracker > <http://bugs.python.org/issue15873> > ___ -- ___ Python tracker <http://bugs.python.org/issue15873> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24954] No way to generate or parse timezone as produced by datetime.isoformat()
Anders Hovmöller added the comment: > The `arrow` library depends on the supposed "strict" behaviour of strptime > that has never been guaranteed, which often results in very buggy behaviour > under some conditions. Well… the arrow library accepts all sorts of broken input and gives you a date back. I think they even think that’s a feature and not a bug so no use in trying to help people who are adamant that they don’t want to be helped :/ -- ___ Python tracker <http://bugs.python.org/issue24954> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15873] datetime: add ability to parse RFC 3339 dates and times
Anders Hovmöller added the comment: > > By the way, I just discovered, that the way we treat microseconds differs > from the strptime one : we are smarter read every digits and smartly round to > six, strptime doesn't go that far and just *truncate* to this. Should go that > way, for consistency with what strptime does, maybe ? I'm strongly against silently throwing away data and calling it even. If we want compatibility with strptime then it should be a separate flag like silent_truncate_milliseconds=True. On another matter: does the latest proposed code pass the tests in my ISO8601 implementation that I mentioned 2013 (! time flies)? -- ___ Python tracker <http://bugs.python.org/issue15873> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15873] "datetime" cannot parse ISO 8601 dates and times
Anders Hovmöller added the comment: Éric Araujo: absolutely. Although I think my code can be improved (speed wise, elegance, etc) since I just wrote it quickly a weekend :) -- ___ Python tracker <http://bugs.python.org/issue15873> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15873] "datetime" cannot parse ISO 8601 dates and times
Anders Hovmöller added the comment: I've written a parser for ISO 8601: https://github.com/boxed/iso8601 Some basic tests are included and it supports most of the standard. Haven't gotten around to the more obscure parts like durations and intervals, but those are trivial to add... -- nosy: +Anders.Hovmöller ___ Python tracker <http://bugs.python.org/issue15873> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
