[issue44986] Date formats in help messages of argparse
Julian Berman added the comment: This is documented already I believe: https://docs.python.org/3/library/argparse.html#help > As the help string supports %-formatting, if you want a literal % to appear > in the help string, you must escape it as %%. -- nosy: +Julian ___ Python tracker <https://bugs.python.org/issue44986> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44995] "Hide the prompts and output" works abnormal
Change by Julian Berman : -- keywords: +patch nosy: +Julian nosy_count: 2.0 -> 3.0 pull_requests: +26384 stage: -> patch review pull_request: https://github.com/python/cpython/pull/27939 ___ Python tracker <https://bugs.python.org/issue44995> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44994] datetime's C implementation verifies fromisoformat is ASCII, but the pure python implementation does not
New submission from Julian Berman :
This line (which contains a non-ASCII digit):
python3.9 -c "import datetime; datetime.date.fromisoformat('1963-06-1৪')"
raises:
Traceback (most recent call last):
File "", line 1, in
ValueError: Invalid isoformat string: '1963-06-1৪'
under the C implementation of the datetime module, but when the pure Python
implementation is the one imported, succeeds (and produces `datetime.date(1963,
6, 14)`)
The pure Python implementation should instead explicitly check and raise when
encountering a non-ASCII string.
(On PyPy, which always uses the pure-Python implementation, this contributes to
a behavioral difference)
--
components: Library (Lib)
messages: 400235
nosy: Julian, p-ganssle
priority: normal
severity: normal
status: open
title: datetime's C implementation verifies fromisoformat is ASCII, but the
pure python implementation does not
type: behavior
versions: Python 3.10, Python 3.11, Python 3.7, Python 3.8, Python 3.9
___
Python tracker
<https://bugs.python.org/issue44994>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36384] ipaddress Should not reject IPv4 addresses with leading zeroes as ambiguously octal
Change by Julian Berman : -- nosy: +Julian ___ Python tracker <https://bugs.python.org/issue36384> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22282] ipaddress module accepts octal formatted IPv4 addresses in IPv6 addresses
Change by Julian Berman : -- nosy: +Julian ___ Python tracker <https://bugs.python.org/issue22282> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43148] Call sys.unraisablehook in the REPL when sys.excepthook is broken
Julian Berman added the comment: Thanks Victor. Yes likely happy to send a PR (have to clear a few things off the yak stack first) On Tue, Feb 9, 2021 at 5:38 AM STINNER Victor wrote: > > STINNER Victor added the comment: > > It makes sense to call _PyErr_WriteUnraisableMsg() when sys.excepthook > raise a new exception. Do you want to propose a PR for that? > > sys.excepthook documentation mentions sys.unraisablehook: > https://docs.python.org/dev/library/sys.html#sys.excepthook > > threading._make_invoke_excepthook logs threading.excepthook failure using > sys.excepthook. > > Note: Carl also suggested to add a way to invoke sys.unraisablehook > explicitly, not only for testing purpose. It would help in some cases. > > -- > > ___ > Python tracker > <https://bugs.python.org/issue43148> > ___ > -- nosy: +Julian2 ___ Python tracker <https://bugs.python.org/issue43148> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43154] code.InteractiveConsole can crash if sys.excepthook is broken
Change by Julian Berman : -- nosy: +Julian ___ Python tracker <https://bugs.python.org/issue43154> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43148] Call sys.unraisablehook in the REPL when sys.excepthook is broken
New submission from Julian Berman : At the REPL, when sys.excepthook is broken (below by setting it to a non-callable), one sees: ``` ⊙ python3.9 julian@Airm Python 3.9.1 (default, Feb 2 2021, 22:54:59) [Clang 12.0.0 (clang-1200.0.32.29)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import sys; sys.excepthook = object(); asdf Error in sys.excepthook: TypeError: 'object' object is not callable Original exception was: Traceback (most recent call last): File "", line 1, in NameError: name 'asdf' is not defined ``` The implementation (https://github.com/python/cpython/blob/5f18c223391eef8c7d01241b51a7b2429609dd84/Python/pythonrun.c#L805-L817) seems to do so by reimplementing something like 3.8+'s sys.unraisablehook (well, technically it predates sys.unraisablehook by quite a while). Seems like now that it exists, that code should now call sys.unraisablehook. -- messages: 386569 nosy: Julian, vstinner priority: normal severity: normal status: open title: Call sys.unraisablehook in the REPL when sys.excepthook is broken versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue43148> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41745] BoundArguments.arguments used in the recommended way to call a callable silently succeeds for nonexistent arguments
Julian Berman added the comment: Totally fair! Sorry, was just making sure the label change wasn't intended to say it *wasn't* enough to warrant a design change :) (which I agree should be discussed with folks who do use that functionality, of which I only recently had to). -- ___ Python tracker <https://bugs.python.org/issue41745> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41745] BoundArguments.arguments used in the recommended way to call a callable silently succeeds for nonexistent arguments
Julian Berman added the comment: Not sure I agree with it being just a doc issue -- happy to clarify if something was unclear, not sure from your message if it was or if you disagree, but e.g.: > However, your 'two' function takes no arguments, so valid values of args and > kwargs must be empty for them to be used in a call. In all cases, args() and > kwargs() must look at the signature to see which key-value pairs they should > extract from arguments. Right, and that's "dangerous" behavior to me -- BoundArguments.arguments will happily let you add arguments to it, but does no error checking at that point, so does not raise an exception if you typo an argument that isn't in the signature of the callable, and then when you try to call the callable (via the only way possible, namely using .args and .kwargs), that argument that was never added is just dropped. Does that make sense? Or were you disagreeing with that being undesirable behavior? -- ___ Python tracker <https://bugs.python.org/issue41745> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41745] BoundArguments.arguments used in the recommended way to call a callable silently succeeds for nonexistent arguments
Julian Berman added the comment: As a secondary behavior here, which is actually the one that matters more for my use case, the following seems surprising as well: import inspect s = inspect.signature(lambda **kwargs: kwargs).bind() s.arguments["foo"] = 12 will similarly silently drop "foo" when attempting to call the function (i.e. it will not appear in bound.kwargs). This behavior I suspect is the intention of the docs saying "Contains only explicitly bound arguments." but still seems easily misused when .arguments is being used as a frontend for adding additional arguments. To me just brainstorming again it seems it'd be useful to provide a harder-to-misuse frontend, e.g. `BoundArguments.with_arguments(*args, **kwargs)` that returns a bound arguments with some additional to-be-bound arguments which may end up in `kwargs`. -- ___ Python tracker <https://bugs.python.org/issue41745> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41745] BoundArguments.arguments used in the recommended way to call a callable silently succeeds for nonexistent arguments
Change by Julian Berman : -- nosy: +yselivanov versions: -Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue41745> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41745] BoundArguments.arguments used in the recommended way to call a callable silently succeeds for nonexistent arguments
New submission from Julian Berman : The following code succeeds "silently", which seems undesirable: from inspect import signature def two(): return 2 bound = signature(two).bind() bound.arguments["does_not_exist"] = 12 two(*bound.args, **bound.kwargs) where the mechanism for finally calling `two` is the recommended way shown in the docs for `inspect.BoundArguments`: https://docs.python.org/3/library/inspect.html#inspect.BoundArguments.apply_defaults What's happened there is that: print(b.args, b.kwargs) "silently" ignored the non-existent argument. Somewhere along the line here it seems like something should complain. I don't see previous discussion of this from quickly searching on the bug tracker, but obviously if I've missed something let me know. I'm also not really sure what the desirable solution is. To me, it's possibly that BoundArguments should have a fully-managed way to invoke a callable rather than asking a user to unpack *args and *kwargs, and that that mechanism, say arguments.be_passed_to(callable) should do the error checking). Having `.arguments` full-on reject unknown parameters seems like another possibility but there may be reasons that's not a good idea (e.g. if you were to for some reason use a bound arguments object to call some other function that *did* take that additional argument). -- components: Library (Lib) messages: 376578 nosy: Julian priority: normal severity: normal status: open title: BoundArguments.arguments used in the recommended way to call a callable silently succeeds for nonexistent arguments type: behavior versions: Python 3.10, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue41745> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40379] multiprocessing's default start method of fork()-without-exec() is broken
Change by Julian Berman : -- nosy: +Julian ___ Python tracker <https://bugs.python.org/issue40379> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21724] resetwarnings doesn't reset warnings registry
Julian Berman added the comment: Just ran into this myself -- not sure what the intended fix is (hopefully it's "add a function that restores the warnings configuration to its defaults?" Changing resetwarnings seems likely to be not doable I assume.) But in the meanwhile, is a doc patch acceptable? The current documentation for resetwarnings is really deceptive, and makes it look like it does what @pitrou (and I) thought it did: > Reset the warnings filter. This discards the effect of all previous calls to > filterwarnings(), including that of the -W command line options and calls to > simplefilter(). Compare to the docstring of the function (and to what it actually does): > """Clear the list of warning filters, so that no filters are active.""" But there are still too many implementation details of the warnings module leaking through here -- for end users it's just "restore the warnings configuration to its defaults" (what it looks like resetwarnings should do) or "unfilter all warnings, even beyond the filters configured by default" (what it actually does). Is at least making the docs reflect the latter a reasonable patch to submit, to start, while what to do about the former is thought about? -- assignee: -> docs@python components: +Documentation nosy: +Julian, docs@python versions: +Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue21724> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37941] python -m and runpy.run_module set different __name__ by default
Julian Berman added the comment: That all makes sense, I understand that in the general case you can't really promise someone that if you mutate global state in-process that the runpy module has any way of preventing that. Except IMO, the module gives exactly the impression you're saying is bad (that you want to use it if you need to do what -m does from Python, assuming you are OK with the constraints there). And then runpy.run_module is a footgun, because it does not in fact do what -m does, so it's hard to imagine the kind of person who *does* want to use runpy -- it's basically "try it on your specific -m, and possibly it works, and then possibly it will continue to work" (to be slightly but hopefully not overwhelmingly facetious). Quoting the docs for it themselves: See also The -m <https://docs.python.org/3/using/cmdline.html#cmdoption-m> option offering equivalent functionality from the command line. >From an external developer's perspective, if some other thing would be necessary tomorrow that would only be for -m, could one rely on it being added to any or all of the functions in the runpy module? That sounds unclear if there isn't a function that represents what -m does and promises to stay that way. It seems to me that either exposing a public API that promises to be -m as much as possible (which means at least if an end-user knows they're just as "clean" as the process that -m will run, you're probably good), or otherwise deprecating the functions in here entirely as public, and just making them all private, would be improvements to being able to understand if someone wants to use this module or not, but I do appreciate you explaining how things got here. -J On Wed, Sep 11, 2019 at 7:03 PM Nick Coghlan wrote: > > Nick Coghlan added the comment: > > There is one, it just isn't public: runpy._run_module_as_main. > > It's a private API that the -m switch implementation calls, and was > introduced after the original runpy.run_module was found not to offer > everything the switch needed. > > It isn't possible to fully emulate -m from Python code though, as the > lifecycle of the real main module is intertwined with the lifecycle of the > underlying interpreter. > > So if folks really want to try to do this, the source code is there to > look at, but we're not giving the false impression that it's easy to do > correctly with no unintended consequences. > > -- > > ___ > Python tracker > <https://bugs.python.org/issue37941> > ___ > -- ___ Python tracker <https://bugs.python.org/issue37941> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37941] python -m and runpy.run_module set different __name__ by default
Julian Berman added the comment: Is there no desire to have an API that works like -m (entirely. In this and any other way)? On Tue, Sep 3, 2019, 09:41 Nick Coghlan wrote: > > Change by Nick Coghlan : > > > -- > stage: -> resolved > status: open -> closed > > ___ > Python tracker > <https://bugs.python.org/issue37941> > ___ > -- ___ Python tracker <https://bugs.python.org/issue37941> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37941] python -m and runpy.run_module set different __name__ by default
New submission from Julian Berman :
This seems brutally simple, to the point where I'm concerned I'm missing
something (or have seen this issue filed elsewhere but can't find it), but
`python -m` and `runpy.run_module` don't set the same __name__ -- specifically
`runpy.run_module`, when given a non-package, defaults to setting __name__ to
`mod_name`.
So, given package/foo.py, with the "common"
`if __name__ == "__main__":` check at the bottom, `python -m package.foo`
successfully executes, but `runpy.run_module("package.foo")` exits silently,
unless explicitly passed `runpy.run_module("package.foo", run_name="__main__").
[n.b. pep517.{build,check} is a specific example of such a module that
advertises itself as wanting to be executed via `python -m`]
issue16737 seems related but not exactly the same from what I can tell.
--
messages: 350387
nosy: Julian
priority: normal
severity: normal
status: open
title: python -m and runpy.run_module set different __name__ by default
___
Python tracker
<https://bugs.python.org/issue37941>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37805] json.dump(..., skipkeys=True) has no unit tests
New submission from Julian Berman : Looks like there possibly are upstream tests that could be pulled in with modification: https://github.com/simplejson/simplejson/blob/00ed20da4c0e5f0396661f73482418651ff4d8c7/simplejson/tests/test_dump.py#L53-L66 (Found via https://bitbucket.org/pypy/pypy/issues/3052/json-skipkeys-true-results-in-invalid-json) -- components: Tests messages: 349317 nosy: Julian priority: normal severity: normal status: open title: json.dump(..., skipkeys=True) has no unit tests versions: Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue37805> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30754] textwrap.dedent mishandles empty lines
Julian Berman added the comment: I still disagree :) but docs are better than nothing. On Wed, Jun 12, 2019, 18:05 Guido van Rossum wrote: > > Change by Guido van Rossum : > > > -- > nosy: +gvanrossum > > ___ > Python tracker > <https://bugs.python.org/issue30754> > ___ > -- ___ Python tracker <https://bugs.python.org/issue30754> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12445] dict view values objects are missing tp_richcmp and tp_as_number
Julian Berman added the comment:
Yes I know *why* it worked in Py2 -- still seems like an oversight :)
To me, comparing (multi)set-like is the only reasonable behavior there
which is what IIRC the patch did, but even without that, for a given dict,
d.values() != d.values().
So, it's not like comparison is currently unimplemented. It returns
answers, they just mostly make no sense. (And of course I know that what's
happening is we're falling back to an identity check)
On Thu, Mar 28, 2019, 09:51 Inada Naoki wrote:
>
> Inada Naoki added the comment:
>
> > Well, surely there are reasonable semantics :), because dict.values ==
> > dict.values was comparable before we had view objects.
>
> Because it was list.
>
> Now values view is not sequence-like or set-like.
>
> >>> {"a": "foo", "b": "bar"}.values() == {"a": "bar", "b": "foo"}.value()
> True if set-like. False if sequence-like.
>
> If you want Python 2 behavior, you should convert it to list.
> Then you can use "sequence" semantics.
>
> --
>
> ___
> Python tracker
> <https://bugs.python.org/issue12445>
> ___
>
--
___
Python tracker
<https://bugs.python.org/issue12445>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12445] dict view values objects are missing tp_richcmp and tp_as_number
Julian Berman added the comment:
Well, surely there are reasonable semantics :), because dict.values ==
dict.values was comparable before we had view objects.
It's been awhile since I filed this, and still seems rather silly that:
>>>> {"a": "foo"}.values() != {"a": "foo"}.values()
True
On Thu, Mar 28, 2019 at 9:18 AM Inada Naoki wrote:
>
> Inada Naoki added the comment:
>
> There is no reasonable semantics for values view.
> Keep it unimplemented.
>
> --
> nosy: +inada.naoki
> resolution: -> rejected
> stage: patch review -> resolved
> status: open -> closed
>
> ___
> Python tracker
> <https://bugs.python.org/issue12445>
> ___
>
--
___
Python tracker
<https://bugs.python.org/issue12445>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17894] Edits to descriptor howto
Julian Berman added the comment: This seems very very slightly overly conversational (specifically the "That's all there is to it" sentence), but overall like a pretty decent improvement here. Personally I'd axe that sentence but then seems like this should be merged as-is and any further improvements could always pile on after given how long this has sat. -- nosy: +Julian ___ Python tracker <https://bugs.python.org/issue17894> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30754] textwrap.dedent mishandles empty lines
Julian Berman added the comment: @Terry IMHO it conflicts with the fundamental description of the function. > Remove any common leading whitespace from every line in text. If this behavior is intentional, textwrap.dedent does not do that, it does that, but also some other stuff. As for whether it *should* do that, I can't really see how it'd be a good idea to do this -- whether indented blank lines are like trailing whitespace or not is a good reason not to *add* them, but if you've got some already, textwrap.dedent isn't responsible for them, they were there already. It is also extremely hard to get the other behavior given a function that does this one, but trivial to do the reverse. Also, the #1 reason to use textwrap.dedent (and also the very next line of the docstring after the one I quoted) is to line up sections of source code. With this behavior, that usecase goes away any time you need trailing whitespace, which is exactly how I found this behavior, by unittesting a function that was returning: textwrap.dedent( """ foo ' bar baz quux ' """, ) -- ___ Python tracker <http://bugs.python.org/issue30754> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30754] textwrap.dedent mishandles empty lines
New submission from Julian Berman:
⊙ python2 -c 'from textwrap import dedent; print repr(dedent(" " * 2 + "\n" +
" " * 4 + "\n"))'
'\n\n'
instead of the presumed '\n \n'
The same appears to be the case for py3.6.
(At first glance, this seems unrelated to http://bugs.python.org/issue19479
although that issue seems to have an unreviewed patch that changes the
implementation, so it might also "accidentally" fix the issue).
--
components: Library (Lib)
messages: 296825
nosy: Julian, georg.brandl, terry.reedy
priority: normal
severity: normal
status: open
title: textwrap.dedent mishandles empty lines
type: behavior
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7
___
Python tracker
<http://bugs.python.org/issue30754>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29182] Remove the warning in urllib docs that it doesn't do certificate validate by default.
Julian Berman added the comment: Cool! If I can nitpick one last time, in the versionchanged block, you have `HTTPS URIs` but in the warning you use `HTTPS Urls` -- probably best to use consistent casing and URL vs URI. Other than that, lgtm to merge. -- ___ Python tracker <http://bugs.python.org/issue29182> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29182] Remove the warning in urllib docs that it doesn't do certificate validate by default.
Julian Berman added the comment: The change note belongs outside the seealso. I think also that wasn't exactly what Martin had in mind, I think he meant a `.. versionchanged` directive -- and given that this was originally a warning, personally I'd leave the warning but reword it, it's still relevant for pre-2.7.9 users. E.g. something like: .. seealso:: .. versionchanged:: 2.7.9 HTTPS certificates now have hostname verification enabled by default. .. warning:: Versions prior to 2.7.9 do not safely verify hostnames. It is not recommended to use this module on these versions -- the aformentioned requests module can be used instead. Or the like. -- nosy: +Julian ___ Python tracker <http://bugs.python.org/issue29182> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19959] argparse.FileType does not expand tilde "~"
Julian Berman added the comment: My support (or really, asking for a more generic callable) was to enable other use cases, not this one specifically -- e.g., allowing for constructing a pathlib Path or a twisted.python.filepath.FilePath without needing to write one's own argparse action. For ~ specifically -- it's true if you're going to go via a shell it'd be expanded first, but I'm not sure that'd count as "conflicting" with the shell's expansion, it just won't be needed. Consider that twisted.python.filepath.FilePath for example, expands ~ in its constructor -- people often construct paths in other places and occasionally expansion is convenient. Like in test cases. I certainly don't feel strongly about the patch though, especially as-is. -- status: pending -> open ___ Python tracker <http://bugs.python.org/issue19959> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20598] argparse docs: '7'.split() is confusing magic
Julian Berman added the comment: +1 to lists all over, this is just confusing. -- nosy: +Julian ___ Python tracker <http://bugs.python.org/issue20598> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11664] Add patch method to unittest.TestCase
Julian Berman added the comment: My opinion is already here re: patch vs patch.object, so I won't repeat it, but @Michael, if you really want .patch, are you open to adding .patch_object as well? (Regardless, thanks for working on this Julien.) -- ___ Python tracker <http://bugs.python.org/issue11664> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1466065] base64 module ignores non-alphabet characters
Julian Berman added the comment: Created issue22088 to address not having fixed Py2 here. -- nosy: +Julian ___ Python tracker <http://bugs.python.org/issue1466065> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22088] base64 module still ignores non-alphabet characters
New submission from Julian Berman: The base64 module documentation claims that decode methods raise exceptions for non-base64 input, but they do not. There was a patch for Py3 done in issue1466065, but the documentation was not updated for Py2. I have not read that ticket carefully enough to be able to tell what the expected resolution was for Py2 (fixing the bug or just updating the docs). -- assignee: docs@python components: Documentation, Library (Lib) messages: 224089 nosy: Julian, docs@python, r.david.murray priority: normal severity: normal status: open title: base64 module still ignores non-alphabet characters type: behavior versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue22088> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19959] argparse.FileType does not expand tilde "~"
Julian Berman added the comment: Why not take this a step further and make it take a callable that's expected to take the command line argument and coerce it into a path -- nosy: +Julian ___ Python tracker <http://bugs.python.org/issue19959> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17909] Autodetecting JSON encoding
Changes by Julian Berman : -- nosy: +Julian ___ Python tracker <http://bugs.python.org/issue17909> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19645] decouple unittest assertions from the TestCase class
Changes by Julian Berman : -- nosy: +Julian ___ Python tracker <http://bugs.python.org/issue19645> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18335] Add textwrap.dedent, .indent, as str methods.
Changes by Julian Berman : -- nosy: +Julian ___ Python tracker <http://bugs.python.org/issue18335> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18111] Add a default argument to min & max
Julian Berman added the comment: New patchset addressing review. Not sure why upload.py isn't working for me (I assume it should?) -- Added file: http://bugs.python.org/file30510/minmax.patch ___ Python tracker <http://bugs.python.org/issue18111> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18111] Add a default argument to min & max
Julian Berman added the comment: Thanks for the offer Raymond. Here's a patch with some tests and doc updates, incorporating Nick's suggestion (but without a note in the docs, I didn't feel it's notable). Please let me know if anything needs tidying. -- Added file: http://bugs.python.org/file30479/minmax.patch ___ Python tracker <http://bugs.python.org/issue18111> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18054] Add more exception related assertions to unittest
Julian Berman added the comment: I don't either really off the top of my head, though I've toyed with some things. If there's support for some exploration I wouldn't mind attempting a POC externally though. -- ___ Python tracker <http://bugs.python.org/issue18054> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18054] Add more exception related assertions to unittest
Julian Berman added the comment: Can I throw in, and hopefully not in a way that's too out of place, that I think that unittest might want to rethink it's strategy re: assertion methods? The fact that the object that has all the assertions and the object that has the logic for running a test, and the thing that holds all the tests on it, makes things difficult. For a concrete example, subclasses of unittest.TestCase like e.g. trial.unittest.TestCase do not have easy ways of allowing pluggable assertions, by which I mean you can't show up and say "Here I have a thing with some assertions, use this". So, for trial, if we want to support unittest2 assertions (which I'd personally like), we have to put code in trial to do so. It would seem to me that it'd be nicer to (obviously keep what we have for backwards compatibility) but rather than adding a bunch of mixins, have an API that decouples things holding assertion methods from a TestCase, and mix those in by calling a method on the TestCase rather than mixing in a bunch of assertion mixins. (also, in a slightly lighter note, I might like an assertEqualAndAlsoNotUnequal method :D) -- nosy: +Julian ___ Python tracker <http://bugs.python.org/issue18054> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18111] Add a default argument to min & max
Julian Berman added the comment: Personally I don't care either way, I basically never use the multiple positional arg form, but what are we trying to prevent exactly? It's bad code, but it (would) do what the person was expecting. Am I not getting the point that's being made about that case? -- ___ Python tracker <http://bugs.python.org/issue18111> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18111] Add a default argument to min & max
Julian Berman added the comment: Raymond, I respect that in your opinion this seems to be overcomplexity, but you haven't addressed any of the arguments made, nor responded to any of the arguments against this being added complexity. I really don't understand the parallels you're making to str.*with, but as for other languages, as David pointed out already, you are looking at things in a vacuum. This is needed because min and max are already silly. In languages like Ruby and Clojure, which were the quickest I had handy, of course you don't need this, because calling min and max *by default* returns None. I'd bet Python 2's silly type comparison history had something to do with the return value not defaulting to None, but what's done is done. I don't like hard-fast rules, but I don't think APIs should ever be penalized for their own mistakes. We should make sane things possible in pleasant ways. If it's OK then (turning back to the patch), unless anyone has something additional to add I'm going to carve up some tests. -- ___ Python tracker <http://bugs.python.org/issue18111> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18111] Add a default argument to min & max
Julian Berman added the comment: I don't really care to push this much harder, but I'll just repeat that I've already made an argument against catching the exception. Calling this making the API too complex also seems quite silly to me. It's a thing that someone looking for would find and someone who wasn't wouldn't. -- ___ Python tracker <http://bugs.python.org/issue18111> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18111] Add a default argument to min & max
Julian Berman added the comment: It's not exactly the same of course, but calling next on a thing that might be empty would be somewhat close, and also is replacing an exception with a sentinel (an exception that is much easier to differentiate). You can always get a ValueError out of min/max, they're going to be ultimately calling __lt__ on stuff which can do what it wants, but that's admittedly quite unlikely. It's not really that readable though on the other hand. -- ___ Python tracker <http://bugs.python.org/issue18111> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18111] Add a default argument to min & max
Julian Berman added the comment: Yes that's a good description. I'm not sure the type of exception is the thing to look at as much as the behavior, I.e. I think next() is a good precedent. And it's not really pleasant to do this with a try/except. Of course everything's possible, but to catch the ValueError sanely requires checking the text of the exception so that the except isn't too broad. -- ___ Python tracker <http://bugs.python.org/issue18111> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18111] Add a default argument to min & max
Julian Berman added the comment: Thanks for finding that, I thought there was an issue that came out of that p-i thread but couldn't find it. I'd like to be more concrete, but "calling max on an iterable" seems concrete enough to me. If you'd like to know more though, personally I've wanted this at least twice in the past 4 or 5 months. Currently, I have code that looks like: def best_match(stuff): first = next(stuff, None) if first is None: return return max(itertools.chain([first], stuff)) which finds the best matching (error it happens to be) in the given stuff. A few months ago I had a similar need in a different application. The issues in that thread from 2009 revolved around a bunch of confusing and not so related things. And I definitely agree that `start` is a really bad name for this. But I don't find `default` to be at all confusing, and in fact this has come up in #python a few times and each time there hasn't really been a problem explaining to someone what `default` would do (or how it would interact with `key` for that matter, although if a precedent is desired, the default in `argparse` just returns the default, it doesn't call `type` or anything on it). -- ___ Python tracker <http://bugs.python.org/issue18111> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18111] Add a default argument to min & max
Changes by Julian Berman : -- keywords: +patch Added file: http://bugs.python.org/file30437/minmaxdefault.patch ___ Python tracker <http://bugs.python.org/issue18111> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18111] Add a default argument to min & max
New submission from Julian Berman: This has come up a number of times I'm aware, but no one has ever written a patch for it as far as a quick look uncovered. So here's one (written by Thomas Wouters but with permission to submit). Submitting without tests and docs, but those are incoming when I get a moment. The justification here is mostly related to being able to call min/max on an iterable of unknown length when there's a sensible default (which is usually going to be None, but that's not the default for backwards compat obviously). -- components: Interpreter Core messages: 190426 nosy: Julian, twouters priority: normal severity: normal status: open title: Add a default argument to min & max type: enhancement versions: Python 3.4, Python 3.5 ___ Python tracker <http://bugs.python.org/issue18111> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18050] embedded interpreter or virtualenv fails with "ImportError: cannot import name MAXREPEAT"
Changes by Julian Berman : -- nosy: +Julian ___ Python tracker <http://bugs.python.org/issue18050> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17705] Fill Character cannot be \0
New submission from Julian Berman:
The docs say:
"The fill character can be any character other than ‘{‘ or ‘}’."
http://docs.python.org/dev/library/string.html#format-specification-mini-language
But:
>>> "{0:\x01>8.2f}".format(12)
'\x01\x01\x0112.00'
whereas:
>>> "{0:\x00>8.2f}".format(12)
' 12.00'
--
components: Interpreter Core
messages: 186653
nosy: Julian
priority: normal
severity: normal
status: open
title: Fill Character cannot be \0
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4
___
Python tracker
<http://bugs.python.org/issue17705>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15351] Add to unittest.TestCase support for using context managers
Julian Berman added the comment: Now that we have contextlib.ExitStack, I think we should consider that here. I.e., I think ExitStack deserves a method that calls its __enter__ and __exit__, say .enter() and .exit(), and then the idiom for this wouldn't require anything on TestCase, it'd be: class TestStuff(TestCase): def setUp(self): self.stack = ExitStack() self.stack.enter_context(my_context_manager()) self.stack.enter_context(my_context_manager2()) self.stack.enter_context(my_context_manager3()) self.stack.enter() self.addCleanup(self.stack.exit) -- nosy: +Julian ___ Python tracker <http://bugs.python.org/issue15351> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9584] Allow curly brace expansion
Changes by Julian Berman : -- nosy: +Julian ___ Python tracker <http://bugs.python.org/issue9584> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13349] Non-informative error message in index() and remove() functions
Julian Berman added the comment: test_issuewhatever is a bit indescriptive. It'd be easier for someone glancing at the test to see what it claims to be testing if there were a more descriptive name given, like perhaps test_exception_message (or something even more verbose). -- nosy: +Julian ___ Python tracker <http://bugs.python.org/issue13349> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16293] curses.ungetch raises OverflowError when given -1
Julian Berman added the comment: Hi, sorry for being terse :). After checking a bit, man 3 getch says that it returns ERR (-1) in non-blocking mode if no input is available. I think you're right though -- calling ungetch without checking for the error value seems like it should be a bug in the application, and looking at some examples that seems to be correct. The reason this came up though is because the changes to range checking broke bpython, which does something like the code I pasted in the first post. The reason it appears to have worked before is because later on getkey is called, and getkey checks if it got ERR and converts that to an exception, which was being caught and silenced. Now though, the code will fail at the call to ungetch. So, I guess, besides the change in behavior, which I guess is less bug prone before so it's probably desirable, OverflowError sounds scary. Perhaps ungetch should check for -1 and raise a curses.error instead? -- ___ Python tracker <http://bugs.python.org/issue16293> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16293] curses.ungetch raises OverflowError when given -1
New submission from Julian Berman: The following code now raises an OverflowError on 3.3: import curses def test_screen(screen): screen.nodelay(True) key = screen.getch() screen.nodelay(False) curses.ungetch(key) curses.wrapper(test_screen) or equivalently just def test_screen(screen): curses.ungetch(-1) -- components: Library (Lib) messages: 173425 nosy: Julian, haypo priority: normal severity: normal status: open title: curses.ungetch raises OverflowError when given -1 versions: Python 3.3, Python 3.4, Python 3.5 ___ Python tracker <http://bugs.python.org/issue16293> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16279] namedtuple should compare equality with field names taken into account
New submission from Julian Berman:
I find the following to be unintuitive:
Python 3.3.0rc1 (default, Sep 6 2012, 16:02:32)
[GCC 4.2.1 Compatible Apple Clang 3.1 (tags/Apple/clang-318.0.58)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from collections import namedtuple
>>> F = namedtuple("F", "x")
>>> G = namedtuple("G", "y")
>>> F(12) == G(12)
True
I'm OK with not taking the class name into account, that sounds reasonable, but
I think field names should make those unequal.
--
components: Library (Lib)
messages: 173292
nosy: Julian, rhettinger
priority: normal
severity: normal
status: open
title: namedtuple should compare equality with field names taken into account
type: enhancement
versions: Python 3.4, Python 3.5
___
Python tracker
<http://bugs.python.org/issue16279>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15987] Provide a way to compare AST nodes for equality recursively
Julian Berman added the comment: I'd say yes (to both lineno/col_offset). And yeah that sounds like what I had in mind (a helper function). If I'm specific for a moment about implementation, perhaps something like `ast.diff`, which yielded tuples of differing nodes (in say, breadth first order down the tree) from two given nodes, and took args for configuration, compare_lineno and compare_col_offset (both defaulted to True), and then __eq__ was just `next(ast.diff(self, other, compare_lineno=True, compare_col_offset=True), None) is None`. Sound good to you? -- ___ Python tracker <http://bugs.python.org/issue15987> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15987] Provide a way to compare AST nodes for equality recursively
New submission from Julian Berman: As is, as far as I can tell, there's no way to easily compare two AST nodes to see if they have the same children and same fields (recursively). I'm writing some unit tests for a NodeTransformers, so I've settled for comparing `ast.dump()`s of each, which is kind of dirty, but 1) works and 2) produces reasonable failure messages. (As a side note of what else I've tried, comparing, say, a list of the `iter_child_nodes` is not a good alternative, since the tests I'm writing are making assertions that a given node was not modified, which means they deepcopy the node and then want to assert that the "transformed" node is unchanged.) I don't know the global implications of changing ast.AST.__eq__ to know if that's feasible (hopefully someone will comment on that), but if it isn't, another provided way would be nice. -- components: Library (Lib) messages: 170826 nosy: Julian priority: normal severity: normal status: open title: Provide a way to compare AST nodes for equality recursively type: enhancement versions: Python 3.3, Python 3.4 ___ Python tracker <http://bugs.python.org/issue15987> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7559] TestLoader.loadTestsFromName swallows import errors
Changes by Julian Berman : -- nosy: +Julian ___ Python tracker <http://bugs.python.org/issue7559> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11664] Add patch method to unittest.TestCase
Julian Berman added the comment: With all due respect, your response pretty much ignored mine completely. That's OK, I've agreed with you that patch seems more common. I'll point you additionally though to the fact that Éric's original post also used patch.object's semantics, as does test.test_support.swap_attr and patch. I don't know how hard I can push here though, since again, this would be really confusing to have it have the same name. -- ___ Python tracker <http://bugs.python.org/issue11664> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11664] Add patch method to unittest.TestCase
Julian Berman added the comment:
It's slightly less confusing -- "Where do I patch" is the question that will
never go away, and the fact that you don't have the `sys` module imported is a
small hint that you should be doing patch(mymodule.sys, "path") not
patch("sys.path"). Also, the fact that patch is more common doesn't reflect the
fact that most of those times, patch.object would have worked as well, but it's
longer to type (or people aren't as aware of it), since most of the time you're
patching things in a module you've imported already (at least this is true of
me, and I've started using patch.object whenever it works and only falling back
on patch).
Also, Twisted's TestCase (which already has a method to implement patch) is
functionally equivalent to patch.object, not patch, in case you wanted a
precedent.
--
___
Python tracker
<http://bugs.python.org/issue11664>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11664] Add patch method to unittest.TestCase
Julian Berman added the comment: It's kind of unfortunate that `mock.patch` is called `mock.patch`. I was thinking about this a bit more yesterday, and `mock.patch.object` is the one that I think would be most appropriate to put on `TestCase`, and the best name for it is probably `patch`, but doing that would be deathly confusing, so I don't think that's a real choice we can make. -- ___ Python tracker <http://bugs.python.org/issue11664> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15627] Add a method to importlib.abc.SourceLoader for converting source to a code object
Changes by Julian Berman : -- nosy: +Julian ___ Python tracker <http://bugs.python.org/issue15627> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9253] argparse: optional subparsers
Changes by Julian Berman : -- nosy: +Julian ___ Python tracker <http://bugs.python.org/issue9253> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11385] TextTestRunner methods are not documented
Changes by Julian Berman : -- nosy: +Julian ___ Python tracker <http://bugs.python.org/issue11385> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15891] A public facing API for __unittest = True
New submission from Julian Berman: Can `__unittest = True`, which is used to hide stack frames from tracebacks inside the testing framework, be documented as being public, or, if that's not acceptable, be replaced by something that is? `_exc_info_to_string` is a hairy function to need to rewrite when authoring a testing framework, but it's a rather common thing to want, and would be nice if it was easily done by integrating with what `TestCase` is already doing. It's also (with or without formal blessing) being used in the wild in at least one place I know of here http://bazaar.launchpad.net/~testtools-committers/testtools/trunk/view/head:/testtools/testcase.py#L798 and since it's not terribly critical and will fail rather nicely even if the API changes suddenly I'd bet other places are using it too, though I haven't bothered to check. See also http://twistedmatrix.com/trac/ticket/4127 which would be easier to implement if this were acceptable to use for external code. -- components: Library (Lib) messages: 170126 nosy: Julian, michael.foord priority: normal severity: normal status: open title: A public facing API for __unittest = True type: enhancement versions: Python 3.3, Python 3.4 ___ Python tracker <http://bugs.python.org/issue15891> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15867] make importlib documentation easier to use
Julian Berman added the comment: Eric: Yeah I've seen that, it's the one thing that I kept open as I was turning back and forth through the various parts of importlib. So yeah I like that document certainly at least a bit :). Also thanks to both you and Brett for linking that issue, that's certainly something I'll keep an eye on. Just to repeat the specific things that perhaps we could work on -- I strongly agree that the top of importlib's docs would benefit from reworking the See Also at the top. Also, perhaps that monumental undertaking would be a thing that could be wrangled :P -- like you said, import hooks seem to have two broad use cases: changing *where* a module comes from away from a simple file containing Python source code on a filesystem, and secondly changing what happens when a module is being imported. So I guess what I would love to have would be an example for each of those. An example of a Loader that loaded from somewhere else other than a file, and an example of an Importer that did something else when executing. I'm sure you'll correct me if I've missed an important one. If that's reasonable sounding and I manage to succeed in my own use case, perhaps I'll take a shot at that. One thing I certainly understand here is that usually I (we) wouldn't have this problem since blog posts and other third party documentation and code can provide examples that are helpful enough to help developers get a sense of what they need to write. The thing for me here was that I didn't really find anything helpful in that sector. importlib is new obviously, so maybe what's given me trouble will be mitigated after 3.3 gets released and a few people write up some examples on their own. I recognize that there was a huge undertaking here, and that it's still being honed, I hope in no way did this sound disparaging :). Also I hope it didn't sound like a misplaced StackOverflow post -- although certainly the confirmation that I was on the right track should help me finish this off quite easily, so thanks for that as well :). -- ___ Python tracker <http://bugs.python.org/issue15867> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15867] It's hard to decypher how to build off of the provided objects from the importlib docs
Changes by Julian Berman : -- type: -> enhancement ___ Python tracker <http://bugs.python.org/issue15867> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15867] It's hard to decypher how to build off of the provided objects from the importlib docs
New submission from Julian Berman: I find that the importlib documentation is a bit too low level. Import hooks are not that common, so requiring a bit of reading is OK with me, but I somewhat *understand* PEP 302, so I have a general idea of *what* I want to do and what kind of objects can accomplish that, and still find it hard to figure out how to take the pieces provided by importlib and use them to do what I want. If I provide a specific example, I want to create a path hook that "just" does the usual import behavior, but before executing the module, does some transformation on the source code, say. In trying to figure out the best way to do that I had a hard time using the docs to figure out which pieces I should assemble to do that. I'm going to just describe the rough series of steps I went through, and hopefully that will help give a picture of where in the docs I had trouble. `importlib.abc` has a few things that would appear to help. None of the things seem like an exact match, so immediately I'm confused -- after reading PEP 302 I'd have expected to need to find an object to implement one or both of `get_code` or `get_source` on, or one that has that implemented that I can subclass and extend. The closest thing there that I find is PyPycLoader, which seems to be saying it implements the standard import behavior, but the docs say its deprecated and to use SourceLoader. At this point, after checking out `SourceLoader` and seeing that it has me implementing two methods whose purpose I don't quite understand, even after reading the short descriptions of them, at least not in the context of what I want to do, I begin to suspect that what I really want is to combine SourceLoader with some things from the `imp` module, or maybe `importlib.__import__`, but am left wondering again how much I need to implement before I just can use that. I then notice `importlib. util.module_for_loader`, and add that to the simple loader I've written which I'm still waiting to plug `imp` into, before realizing that that decorator eats the `fullname` attribute and *only* passes along the module, which confuses me, since now I don't know how to retrieve the source for the module object that I'm being passed -- so I save the path name in `__init__` for the class, and assume that's what I should be doing, despite not seeing an example doing that. Assuming that's even correct as-is, it took me quite a bit to put those pieces together. So I apologize for rambling -- I think essentially what'd improve things is providing more examples, or perhaps a HOWTO entry, that targeted assembling the pieces provided in the module into a few clear, complete examples of finders, loaders and importers. -- assignee: docs@python components: Documentation messages: 169901 nosy: Julian, docs@python priority: normal severity: normal status: open title: It's hard to decypher how to build off of the provided objects from the importlib docs versions: Python 3.3, Python 3.4 ___ Python tracker <http://bugs.python.org/issue15867> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15860] Use TestCase assertion methods in unittest.mock.assert* to make them easier to read
New submission from Julian Berman: Mock's assertion failures can be extremely hard to read for a few reasons -- mostly the noisy default repr that mock objects have, but also because they don't give you the hints that `unittest.TestCase`'s `assert*` methods give you (things like diffing two lists for example). unittest.mock.Mock's `assert*` methods could hook into the TestCase's assertion methods if Mock either gained a MockInTestCase subclass or started taking an arg to `__init__` that was an instance of `TestCase`, so that `assert*` could then use the assertion methods on the instance. #11664 could (should) then obviously use this argument by default when patching. Another added advantage would be that the raised exception could then be `TestCase.failureException`, whatever that might be, rather than `AssertionError`, though I doubt that's that big a deal since that's usually a subclass of `AssertionError` I bet. -- components: Library (Lib) messages: 169826 nosy: Julian, michael.foord priority: normal severity: normal status: open title: Use TestCase assertion methods in unittest.mock.assert* to make them easier to read versions: Python 3.3, Python 3.4 ___ Python tracker <http://bugs.python.org/issue15860> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11664] Add patch method to unittest.TestCase
Changes by Julian Berman : -- nosy: +Julian ___ Python tracker <http://bugs.python.org/issue11664> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15023] listextend (and therefore list.extend and list.__init__) peek at len before iter
Julian Berman added the comment: Oh, and, with apologies for the double post, tuple does the same, while set, dict, collections.deque do not. -- ___ Python tracker <http://bugs.python.org/issue15023> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15023] listextend (and therefore list.extend and list.__init__) peek at len before iter
New submission from Julian Berman : The following code raises an unexpected exception: class Foo(object): def __len__(self): raise Exception() def __iter__(self): return iter([]) list(Foo()) In the optimizations being done in listextend, it appears len is getting called first for some reason (sorry, haven't gotten a chance to step through it carefully yet). Tangentially, PyPy (correctly I guess) throws no such exception. -- components: Interpreter Core messages: 162457 nosy: Julian priority: normal severity: normal status: open title: listextend (and therefore list.extend and list.__init__) peek at len before iter type: behavior versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4 ___ Python tracker <http://bugs.python.org/issue15023> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14086] str(KeyError("Foo")) Unexpected Result
Julian Berman added the comment: Hey there. Check out #2651 -- nosy: +Julian ___ Python tracker <http://bugs.python.org/issue14086> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13826] Having a shlex example in the subprocess.Popen docs is confusing
Julian Berman added the comment: Sounds reasonable to me. I'll take a look at adding one unless someone manages to beat me to it. -- ___ Python tracker <http://bugs.python.org/issue13826> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13826] Having a shlex example in the subprocess.Popen docs is confusing
New submission from Julian Berman : The example at http://docs.python.org/dev/library/subprocess.html#popen-constructor seems a bit misplaced, as it seems to suggest that one should use the shlex module. Most of the other examples in the module seem to use a list to provide the args, so if there was a need to just point out that shlex could be used for a corner case perhaps it'd be better suited as a footnote or another subsection somewhere. -- assignee: docs@python components: Documentation messages: 151624 nosy: Julian, docs@python priority: normal severity: normal status: open title: Having a shlex example in the subprocess.Popen docs is confusing type: enhancement versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3 ___ Python tracker <http://bugs.python.org/issue13826> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13774] json.loads raises a SystemError for invalid encoding on 2.7.2
New submission from Julian Berman :
>>> import json
>>> json.loads("{}", [1, 2, 3])
Traceback (most recent call last):
File "", line 1, in
File "/usr/local/Cellar/python/2.7.2/lib/python2.7/json/__init__.py", line
339, in loads
return cls(encoding=encoding, **kw).decode(s)
File "/usr/local/Cellar/python/2.7.2/lib/python2.7/json/decoder.py", line
359, in __init__
self.scan_once = scanner.make_scanner(self)
SystemError: NULL result without error in PyObject_Call
Python 3.2 and 2.6 are not affected it'd seem, so it looks to be 2.7 only.
--
components: Library (Lib)
messages: 151100
nosy: Julian
priority: normal
severity: normal
status: open
title: json.loads raises a SystemError for invalid encoding on 2.7.2
versions: Python 2.7
___
Python tracker
<http://bugs.python.org/issue13774>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7897] Support parametrized tests in unittest
Changes by Julian Berman : -- nosy: +Julian ___ Python tracker <http://bugs.python.org/issue7897> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13585] Add contextlib.CleanupManager
Julian Berman added the comment: For reference, the implementation that I posted in the other thread is: @contextlib.contextmanager def maybe(got, contextfactory, *args, checkif=bool, **kwargs): if checkif(got): yield got else: with contextfactory(*args, **kwargs) as got: yield got which produces code like: def fn(input_file=None): with maybe(input_file, open, "/default/input/file/location/"): for line in input_file: print line For the example given here in the OP, since rmtree isn't a contextmanager it'd require wrapping it in one first. I could probably understand if there was desire for these to be a recipe instead. The advantage (if any) of the above over this class is that it keeps context managers sorta looking like context managers. Here if you wanted to write my example it'd require writing code like with ContextManager() as mgr: foo = ctxtmgr() mgr.register(foo.__close__) which doesn't look too great :/ The class though does have wider scope though, since it doesn't necessarily only need a context manager, it can do cleanup for anything, which I guess is nice. -- nosy: +Julian ___ Python tracker <http://bugs.python.org/issue13585> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13523] Python does not warn in module .py files does not exist if there is still a .pyc file
Julian Berman added the comment: I know this is a feature, and on occasion as pointed out a useful one. But in some cases it can be a tad annoying as the OP probably considered it. I had a recent example where a lingering .pyc made my test suite pass (and me nearly push broken code) despite the fact that I'd moved the file away and edited it, with bugs. Obviously I now remember to rebuild and remove all .pyc's before I commit, but it took a near miss to remind me to. Would it be useful to have a command line flag that did something like this (perhaps that test runners could set by default) to prevent others from running into similar situations? -- nosy: +Julian ___ Python tracker <http://bugs.python.org/issue13523> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13437] Provide links to the source code for every module in the documentation
Julian Berman added the comment: Well, if there's opposition I don't know how strongly I feel about this then, but I generally agree with you Ezio, if there's an occasion where 1) applies fixing the docs is certainly reasonable. If I'm checking the source though, it's not necessarily since the documentation is unclear, just that it's often easier to read code than English. But, I guess if no one else feels it'd be helpful feel free to close this then. -- ___ Python tracker <http://bugs.python.org/issue13437> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13437] Provide links to the source code for every module in the documentation
Julian Berman added the comment: Here's first a quick list from one pass over the docs. I've attempted to limit myself to a few like you've suggested, though I'll wait for confirmation that Raymond is not willing to simply add them to everything once we're at it :). http://docs.python.org/library/difflib.html http://docs.python.org/library/stringio.html http://docs.python.org/library/codecs.html http://docs.python.org/library/stringprep.html http://docs.python.org/library/datetime.html http://docs.python.org/library/math.html http://docs.python.org/library/cmath.html http://docs.python.org/library/decimal.html http://docs.python.org/library/itertools.html http://docs.python.org/library/os.path.html http://docs.python.org/library/csv.html http://docs.python.org/library/configparser.html http://docs.python.org/library/logging.html http://docs.python.org/library/getpass.html http://docs.python.org/library/json.html http://docs.python.org/library/urllib2.html http://docs.python.org/library/unittest.html http://docs.python.org/library/code.html When I hit the docs to diagnose a problem, it's usually to take a quick look, and then to hit the source code to read that too, since most of the stuff that's in general use is common enough for me to know how it works in a general sense, so the source code is typically where I go pretty quickly after reading what the docs have to say. It's not a huge deal obviously, hg.python.com is not the furthest thing away. Just seems convenient, especially since like I said a lot of the other ones I peek at already have links. As for non-python modules, I really would like to say that linking to C source sounds just as reasonable to me, a little C never killed anyone :), but I don't want to push my luck, so I'll stick with whatever I can get here I guess (I know I put some non-python modules on the list). -- ___ Python tracker <http://bugs.python.org/issue13437> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13437] Provide links to the source code for every module in the documentation
New submission from Julian Berman : The documentation occasionally contains a link to the source code for a module in the stdlib. See for instance http://docs.python.org/library/urlparse.html and http://docs.python.org/library/collections.html , or many others. With a quick perusal, I couldn't immediately guess as to which ones managed to have one and which ones don't, but it'd be convenient to have a link in as many places as possible, which is certainly more than we have now. (See e.g. http://docs.python.org/library/json.html and http://docs.python.org/library/itertools.html and many others for examples of pages that lack a link). Perhaps putting it in a more conspicuous but still consistent location would be reasonable (the sidebar?). -- assignee: docs@python components: Documentation messages: 147973 nosy: Julian, docs@python priority: normal severity: normal status: open title: Provide links to the source code for every module in the documentation type: feature request versions: Python 2.7, Python 3.3 ___ Python tracker <http://bugs.python.org/issue13437> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13241] llvm-gcc-4.2 miscompiles Python (XCode 4.1 on Mac OS 10.7)
Julian Berman added the comment: Never mind, yes, you're correct, somehow my build dir must have been dirty. Sorry bout that. -- ___ Python tracker <http://bugs.python.org/issue13241> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13241] llvm-gcc-4.2 miscompiles Python (XCode 4.1 on Mac OS 10.7)
Julian Berman added the comment: I was unsuccessful building tip with any of the 3 compilers. Full paste of output from ./configure and make, along with haypo's test file are attached. http://paste.pound-python.org/show/14320/ I'm on 10.7.2, XCode is 4.1 (compiler versions in the paste). Upgrading to XCode 4.2 is undesirable, since it removes vanilla gcc. Myself and a few others are avoiding upgrading until homebrew adds vanilla gcc and / or Apple gets things fully sorted, so, being able to build with this would be nice. -- ___ Python tracker <http://bugs.python.org/issue13241> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13241] llvm-gcc-4.2 miscompiles Python (XCode 4.1 on Mac OS 10.7)
Changes by Julian Berman : -- nosy: +Julian ___ Python tracker <http://bugs.python.org/issue13241> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12941] add random.pop()
Julian Berman added the comment: Considering this is pretty easily written more or less as r = range(20) r.pop(random.randrange(0, len(r))) is it really worth adding? -- nosy: +Julian ___ Python tracker <http://bugs.python.org/issue12941> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12782] Multiple context expressions do not support parentheses for continuation across lines
Julian Berman added the comment: > we explicitly advise against importing too many modules in a single import > statement, but importing multiple names from a single location is often a > useful thing to do. Cool. I imagined this had to do with it. > there may be a grammar ambiguity problem in this case, since (unlike > from-import) with statements allow arbitrary subexpressions. Sorry, can you possibly clarify where the ambiguity might come in? -- ___ Python tracker <http://bugs.python.org/issue12782> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12782] Multiple context expressions do not support parentheses for continuation across lines
New submission from Julian Berman :
Using multiple `with` statements across multiple lines does not support using
parens to break them up:
with (open("a_really_long_foo") as foo,
open("a_really_long_bar") as bar):
pass
Traceback (most recent call last):
File "", line 1, in
File "demo.py", line 19
with (open("a_really_long_foo") as foo,
^
SyntaxError: invalid syntax
Also, without convoluting things, import also does not support doing so, and is
the only other example I can think of of a compound statement that forces you
to either be redundant or bite your teeth and use \, despite the fact that PEP
328 gave us parens for from imports.
(I did not find a discussion as to why import didn't grow it as well, so please
correct me as I'm sure it must have been discussed before).
It's understandably a lot rarer to need multiple lines when importing, but it'd
be nice if all compound statements uniformly allowed the same continuation
syntax.
--
components: Interpreter Core
messages: 142411
nosy: Julian
priority: normal
severity: normal
status: open
title: Multiple context expressions do not support parentheses for continuation
across lines
type: behavior
versions: Python 2.7, Python 3.3
___
Python tracker
<http://bugs.python.org/issue12782>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2651] Strings passed to KeyError do not round trip
Changes by Julian Berman : -- nosy: +Julian ___ Python tracker <http://bugs.python.org/issue2651> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12760] Add create mode to open()
Julian Berman added the comment: A minor documentation error in io.rst line 475 which was changed to: + The *mode* can be ``'c'``, ``'r'``, ``'w'`` or ``'a'`` for reading + (default), writing, or appending. and should have "creating" at the front I assume, like you have it later. -- nosy: +Julian ___ Python tracker <http://bugs.python.org/issue12760> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
