[issue41745] BoundArguments.arguments used in the recommended way to call a callable silently succeeds for nonexistent arguments

2020-09-12 Thread Julian Berman


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

2020-09-11 Thread Julian Berman


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

2020-09-08 Thread Julian Berman


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

2020-09-08 Thread Julian Berman


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

2020-09-08 Thread Julian Berman


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

2020-06-24 Thread Julian Berman


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

2020-05-24 Thread Julian Berman


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

2019-09-12 Thread Julian Berman


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

2019-09-03 Thread Julian Berman


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

2019-08-24 Thread Julian Berman


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

2019-08-09 Thread Julian Berman


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

2019-06-12 Thread Julian Berman


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

2019-03-28 Thread Julian Berman


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

2019-03-28 Thread Julian Berman


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

2018-06-30 Thread Julian Berman


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

2017-06-26 Thread Julian Berman

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 <rep...@bugs.python.org>
<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

2017-06-25 Thread Julian Berman

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 <rep...@bugs.python.org>
<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.

2017-01-27 Thread Julian Berman

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 <rep...@bugs.python.org>
<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.

2017-01-25 Thread Julian Berman

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 <rep...@bugs.python.org>
<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 "~"

2016-03-28 Thread Julian Berman

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 <rep...@bugs.python.org>
<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

2015-02-16 Thread Julian Berman

Julian Berman added the comment:

+1 to lists all over, this is just confusing.

--
nosy: +Julian

___
Python tracker rep...@bugs.python.org
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

2014-10-12 Thread Julian Berman

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 rep...@bugs.python.org
http://bugs.python.org/issue11664
___
___
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

2014-07-26 Thread Julian Berman

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 rep...@bugs.python.org
http://bugs.python.org/issue22088
___
___
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

2014-07-26 Thread Julian Berman

Julian Berman added the comment:

Created issue22088 to address not having fixed Py2 here.

--
nosy: +Julian

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1466065
___
___
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 ~

2013-12-14 Thread Julian Berman

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 rep...@bugs.python.org
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

2013-12-01 Thread Julian Berman

Changes by Julian Berman julian+python@grayvines.com:


--
nosy: +Julian

___
Python tracker rep...@bugs.python.org
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

2013-11-29 Thread Julian Berman

Changes by Julian Berman julian+python@grayvines.com:


--
nosy: +Julian

___
Python tracker rep...@bugs.python.org
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.

2013-08-15 Thread Julian Berman

Changes by Julian Berman julian+python@grayvines.com:


--
nosy: +Julian

___
Python tracker rep...@bugs.python.org
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

2013-06-08 Thread Julian Berman

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 rep...@bugs.python.org
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

2013-06-05 Thread Julian Berman

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 rep...@bugs.python.org
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

2013-06-04 Thread Julian Berman

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 rep...@bugs.python.org
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

2013-06-03 Thread Julian Berman

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 rep...@bugs.python.org
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

2013-06-03 Thread Julian Berman

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 rep...@bugs.python.org
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

2013-06-03 Thread Julian Berman

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 rep...@bugs.python.org
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

2013-06-02 Thread Julian Berman

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 rep...@bugs.python.org
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

2013-06-01 Thread Julian Berman

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 rep...@bugs.python.org
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

2013-06-01 Thread Julian Berman

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 rep...@bugs.python.org
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

2013-06-01 Thread Julian Berman

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 rep...@bugs.python.org
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

2013-05-31 Thread Julian Berman

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 rep...@bugs.python.org
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

2013-05-31 Thread Julian Berman

Changes by Julian Berman julian+python@grayvines.com:


--
keywords: +patch
Added file: http://bugs.python.org/file30437/minmaxdefault.patch

___
Python tracker rep...@bugs.python.org
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

2013-05-27 Thread Julian Berman

Changes by Julian Berman julian+python@grayvines.com:


--
nosy: +Julian

___
Python tracker rep...@bugs.python.org
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

2013-04-12 Thread Julian Berman

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:\x018.2f}.format(12)
'\x01\x01\x0112.00'

whereas:

 {0:\x008.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 rep...@bugs.python.org
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

2013-04-06 Thread Julian Berman

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 rep...@bugs.python.org
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

2013-02-22 Thread Julian Berman

Changes by Julian Berman julian+python@grayvines.com:


--
nosy: +Julian

___
Python tracker rep...@bugs.python.org
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

2012-11-10 Thread Julian Berman

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 rep...@bugs.python.org
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

2012-10-21 Thread Julian Berman

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 rep...@bugs.python.org
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

2012-10-20 Thread Julian Berman

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 rep...@bugs.python.org
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

2012-10-18 Thread Julian Berman

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 rep...@bugs.python.org
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

2012-09-21 Thread Julian Berman

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 rep...@bugs.python.org
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

2012-09-20 Thread Julian Berman

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 rep...@bugs.python.org
http://bugs.python.org/issue15987
___
___
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

2012-09-18 Thread Julian Berman

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 rep...@bugs.python.org
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

2012-09-18 Thread Julian Berman

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 rep...@bugs.python.org
http://bugs.python.org/issue11664
___
___
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

2012-09-18 Thread Julian Berman

Changes by Julian Berman julian+python@grayvines.com:


--
nosy: +Julian

___
Python tracker rep...@bugs.python.org
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

2012-09-15 Thread Julian Berman

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 rep...@bugs.python.org
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

2012-09-14 Thread Julian Berman

Changes by Julian Berman julian+python@grayvines.com:


--
nosy: +Julian

___
Python tracker rep...@bugs.python.org
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

2012-09-13 Thread Julian Berman

Changes by Julian Berman julian+python@grayvines.com:


--
nosy: +Julian

___
Python tracker rep...@bugs.python.org
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

2012-09-12 Thread Julian Berman

Changes by Julian Berman julian+python@grayvines.com:


--
nosy: +Julian

___
Python tracker rep...@bugs.python.org
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

2012-09-09 Thread Julian Berman

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 rep...@bugs.python.org
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

2012-09-07 Thread Julian Berman

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 rep...@bugs.python.org
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

2012-09-05 Thread Julian Berman

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 rep...@bugs.python.org
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

2012-09-05 Thread Julian Berman

Changes by Julian Berman julian+python@grayvines.com:


--
type:  - enhancement

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15867
___
___
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

2012-09-04 Thread Julian Berman

Changes by Julian Berman julian+python@grayvines.com:


--
nosy: +Julian

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11664
___
___
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

2012-09-04 Thread Julian Berman

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 rep...@bugs.python.org
http://bugs.python.org/issue15860
___
___
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

2012-06-06 Thread Julian Berman

New submission from Julian Berman julian+python@grayvines.com:

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 rep...@bugs.python.org
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

2012-06-06 Thread Julian Berman

Julian Berman julian+python@grayvines.com added the comment:

Oh, and, with apologies for the double post, tuple does the same, while set, 
dict, collections.deque do not.

--

___
Python tracker rep...@bugs.python.org
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

2012-02-22 Thread Julian Berman

Julian Berman julian+python@grayvines.com added the comment:

Hey there. Check out #2651

--
nosy: +Julian

___
Python tracker rep...@bugs.python.org
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

2012-01-19 Thread Julian Berman

New submission from Julian Berman julian+python@grayvines.com:

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 rep...@bugs.python.org
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

2012-01-19 Thread Julian Berman

Julian Berman julian+python@grayvines.com 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 rep...@bugs.python.org
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

2012-01-11 Thread Julian Berman

New submission from Julian Berman julian+python@grayvines.com:

 import json
 json.loads({}, [1, 2, 3])
Traceback (most recent call last):
  File input, line 1, in module
  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 rep...@bugs.python.org
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

2011-12-15 Thread Julian Berman

Changes by Julian Berman julian+python@grayvines.com:


--
nosy: +Julian

___
Python tracker rep...@bugs.python.org
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

2011-12-12 Thread Julian Berman

Julian Berman julian+python@grayvines.com 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 rep...@bugs.python.org
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

2011-12-03 Thread Julian Berman

Julian Berman julian+python@grayvines.com 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 rep...@bugs.python.org
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

2011-11-26 Thread Julian Berman

Julian Berman julian+python@grayvines.com 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 rep...@bugs.python.org
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

2011-11-20 Thread Julian Berman

Julian Berman julian+python@grayvines.com 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 rep...@bugs.python.org
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

2011-11-19 Thread Julian Berman

New submission from Julian Berman julian+python@grayvines.com:

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 rep...@bugs.python.org
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)

2011-10-27 Thread Julian Berman

Changes by Julian Berman julian+python@grayvines.com:


--
nosy: +Julian

___
Python tracker rep...@bugs.python.org
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)

2011-10-27 Thread Julian Berman

Julian Berman julian+python@grayvines.com 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 rep...@bugs.python.org
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)

2011-10-27 Thread Julian Berman

Julian Berman julian+python@grayvines.com added the comment:

Never mind, yes, you're correct, somehow my build dir must have been dirty.

Sorry bout that.

--

___
Python tracker rep...@bugs.python.org
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()

2011-09-08 Thread Julian Berman

Julian Berman julian+python@grayvines.com 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 rep...@bugs.python.org
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

2011-08-22 Thread Julian Berman

Julian Berman julian+python@grayvines.com 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 rep...@bugs.python.org
http://bugs.python.org/issue12782
___
___
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()

2011-08-18 Thread Julian Berman

Julian Berman julian+python@grayvines.com 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 rep...@bugs.python.org
http://bugs.python.org/issue12760
___
___
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

2011-08-18 Thread Julian Berman

Changes by Julian Berman julian+python@grayvines.com:


--
nosy: +Julian

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2651
___
___
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

2011-08-18 Thread Julian Berman

New submission from Julian Berman julian+python@grayvines.com:

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 input, line 1, in module
  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 rep...@bugs.python.org
http://bugs.python.org/issue12782
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com