[Python-ideas] Re: Add @parametrize decorator to unittest library
07.09.21 05:31, Leonardo Freua пише:
> When writing some unit tests with the standard Unittest library, I missed
> being able to create parameterized tests. This functionality exists in PyTest
> (https://docs.pytest.org/en/6.2.x/parametrize.html) and there is also a
> library called *parameterized*(https://github.com/wolever/parameterized)
> which aims to add this functionality.
>
> However, I think it would be beneficial to have a decorator in Python's
> standard Unittest library.
>
> Note: If this functionality exists natively in Python, please put some
> example or documentation link below.
It was discussed before and subTest() was added as more general alternative.
Instead of
@parametrize("a", [1, 2, 10])
def test(self, a):
...
you should write
def test(self):
for a in [1, 2, 10]:
with self.subTest(a=a):
...
The advantage is that you can generate parameters at run time. You can
add a code before and after the loop. Use several sequential loops.
There are also other use cases for subTest().
The disadvantage is that it adds at least two indentation levels (more
if you use nested loops) to the test code. A simple decorator would be
more convenient in simple cases.
It is easy to implement the decorator in terms of subtests, but
currently there are some issues with outputting results of subtests:
https://bugs.python.org/issue25894
https://bugs.python.org/issue30856
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/5ES2KP34Z4PC75MBAHAAL4JYRQJ7UDJ6/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add @parametrize decorator to unittest library
On Mon, Sep 6, 2021 at 21:45 Christopher Barker wrote: > Just use pytest. > For third party code I agree, it’s the way to go. —Guido -- --Guido (mobile) ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/75MAGYGI3NKUTVFWQ4P3QHO5OX6JQORF/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add @parametrize decorator to unittest library
I believe he is looking for something like pytest’s parameterize: https://docs.pytest.org/en/6.2.x/example/parametrize.html This is actually pretty basic functionality for writing DRY tests, a key missing feature. Frankly though, unittest is painfully unpythonic and hard to extend. I’ve given up. Just use pytest. -CHB On Mon, Sep 6, 2021 at 7:56 PM Steven D'Aprano wrote: > Hi Leonardo, > > On Tue, Sep 07, 2021 at 02:31:26AM -, Leonardo Freua wrote: > > > When writing some unit tests with the standard Unittest library, I > > missed being able to create parameterized tests. > > Could you please explain what you mean by "parameterized tests", and how > you would use a decorator for it? What you mean by it may not be what > other people understand it to be. > > > > -- > Steve > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/CA7ZUSS7OXSM42IWZUXRKYNKVQG6MF2F/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/54DSL6XLGAYMQ3DYVCE7HMQGG3HSK5NU/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add @parametrize decorator to unittest library
Hi Leonardo, On Tue, Sep 07, 2021 at 02:31:26AM -, Leonardo Freua wrote: > When writing some unit tests with the standard Unittest library, I > missed being able to create parameterized tests. Could you please explain what you mean by "parameterized tests", and how you would use a decorator for it? What you mean by it may not be what other people understand it to be. -- Steve ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/CA7ZUSS7OXSM42IWZUXRKYNKVQG6MF2F/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Context manager for csv module 'reader' and 'DictReader'?
On 7/09/21 5:46 am, C. Titus Brown via Python-ideas wrote: Maybe Greg missed that DictReader.open didn’t exist and was in fact what I was asking for! Sorry about that, I thought you were asking for context manager methods to be added to an existing file-like object. If csv.DictReader had a close() method you could use closing() on it, but it seems it doesn't, so closing() doesn't really help here. -- Greg ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/SI55YOIAXFMWS5EUPXQZ4OZHYMQAHGNO/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Add @parametrize decorator to unittest library
When writing some unit tests with the standard Unittest library, I missed being able to create parameterized tests. This functionality exists in PyTest (https://docs.pytest.org/en/6.2.x/parametrize.html) and there is also a library called *parameterized*(https://github.com/wolever/parameterized) which aims to add this functionality. However, I think it would be beneficial to have a decorator in Python's standard Unittest library. Note: If this functionality exists natively in Python, please put some example or documentation link below. Thanks in advance. ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/TUWJSRWQCDDRDSOUIFJBUWOEPZHCMUH7/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Context manager for csv module 'reader' and 'DictReader'?
On 2021-09-06 10:50, Christopher Barker wrote: I think the point here is not the context manager, but rather, having the reader open the file itself, rather than taking an already open file-like object. I agree, and I think having such capability is very useful. I'm always annoyed by things like json.load that require me to open the file separately. There isn't much genuine ambiguity here: I think it's fine to treat strings and Path instances as meaning "this is a filename, open it" and if it's not specifically one of those, then treat it as a file-like object and try to read it. Alternatively, as mentioned on this thread, there's no reason that all these functions that require you to open the file yourself couldn't just grow a new method that's explicitly documented to accept a filename instead of an open file. But I don't see how requiring the user to open the file first on their own gains anything. In my experience 90% of the time that's just more cumbersome and I would prefer the library to handle the entire file operation internally (like pandas does). -- Brendan Barnwell "Do not follow where the path may lead. Go, instead, where there is no path, and leave a trail." --author unknown ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/73P4PFAG7IDCSXPWSCODPKGCB3VNICFD/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Context manager for csv module 'reader' and 'DictReader'?
I really like json.loadf I'd also like to see a csv.loadf. not sure the `f` is needed: you could use @functools.singledispatch On Mon, 6 Sep 2021, 01:12 Christopher Barker, wrote: > On Sun, Sep 5, 2021 at 10:32 AM David Mertz, Ph.D. > wrote: > >> Most Pandas read methods take either a path-like argument or a file-like >> argument, and figure out which it is by introspection when called. >> Actually, most of them even accept a URL-like argument as well >> >> I don't think this is a terrible approach. It doesn't make things quite >> as explicit as the standard library generally does. >> > > The folks in favor of adding this to json are split between overloading > load() (my preference) and adding a new, explicit method: loadf() or > something like that. Either way, it's useful. I honestly don't get the > objection. MY takle is that mosto f the core devs are doing "systsms > programming" rather than "scripting" -- which means that they a: > > Want to be more explicit and robust > Need more flexibiilty around various file-like objects > Don't mind a bit more expertise required. (e.g. specifying the encoding > correctly) > Don't mind a couple extra lines of code. > > So why add a function to make it simple and easy to read a file fro a > path-like? > > I really wish the core devs would remember how useful Python is as a > scripting language, and how many people use it that way. > > Pandas is a good example, I lot of folks use it in a scripting context, so > it provided features that make it easy to do so. > > -CHB > > > On Sun, Sep 5, 2021, 1:19 PM Christopher Barker >> wrote: >> >>> >>> This would only be helpful when the CSV is on the disk but csv.reader() takes a file object so that it can used with anything like a socket for example. json.load() does the same thing. >>> >>> There has been discussion about adding loading from a “path like” to the >>> JSON lib. See this list about ten months ago and a recent thread on discuss. >>> >>> There resistance, but it ended with the idea that maybe there should be >>> a PEP for a common interface for all “file” readers — eg JSON, CSV, etc.. >>> And that interface could be supported by third party libs. That interface >>> *maybe* would include a single step load from a path-like functionality. >>> >>> It seems to me that it is better to keep a generic interface that are composable. >>> >>> No one is suggesting removing the load-from-a-file-like interface. I >>> have no idea why the fact that some people sometimes need a more flexible >>> interface (maybe most people, even) somehow means that we shouldn’t make >>> things easy and obvious for a common use case. >>> >>> -CHB >>> >>> >>> >>> Cheers, Rémi ? And something similar for ‘csv.reader’? I’m not wedded to the details here. The two main reasons I think this might be a positive addition are - * you wouldn’t have to know or remember the right way to open a CSV file (newline=“”). * it elides very common code. but perhaps there are things I’m missing here? As a side note, I think ‘csv.reader’ could usefully be renamed to something else (maybe just Reader?), since it’s kind of out of sync with the CamelCase used in ‘DictReader’. But maybe that’s just an attempt at foolish consistency :). best, —titus ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/EKHYCTYMXZG3VI4JYFA3Y3LD3ZNMI3IX/ Code of Conduct: http://python.org/psf/codeofconduct/ ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/ZJNJQFC2LKQ76GTEBQNKTB3WO2POTKEN/ Code of Conduct: http://python.org/psf/codeofconduct/ >>> -- >>> Christopher Barker, PhD (Chris) >>> >>> Python Language Consulting >>> - Teaching >>> - Scientific Software Development >>> - Desktop GUI and Web Development >>> - wxPython, numpy, scipy, Cython >>> ___ >>> Python-ideas mailing list -- python-ideas@python.org >>> To unsubscribe send an email to python-ideas-le...@python.org >>> https://mail.python.org/mailman3/lists/python-ideas.python.org/ >>> Message archived at >>> https://mail.python.org/archives/list/python-ideas@python.org/message/GAPBNBGLOWD27FCTJJV7FEPUZRKUE6FL/ >>> Code of Conduct: http://python.org/psf/codeofconduct/ >>> >> > > -- > Christopher Barker, PhD (Chris) > > Python La
[Python-ideas] Re: Context manager for csv module 'reader' and 'DictReader'?
I think the point here is not the context manager, but rather, having the reader open the file itself, rather than taking an already open file-like object. And if it’s going to do that, it should provide. Context manager. Personally, while we are at it, I’d like to see a “read all” method, analogous to file.readlines(). For scripting use cases, reading a standard file format should be a one liner. -CHB On Sun, Sep 5, 2021 at 5:31 PM Oscar Benjamin wrote: > On Mon, 6 Sept 2021 at 01:13, Greg Ewing > wrote: > > > > On 6/09/21 3:07 am, C. Titus Brown via Python-ideas wrote: > > > with csv.DictReader.open(filename) as r: > > > for row in r: > > >… > > > > You can do this now: > > > > from contextlib import closing > > with closing(csv.DictReader.open(filename)) as r: > > ... > > What version of Python are you using? > > >>> import csv > >>> csv.DictReader.open > Traceback (most recent call last): > File "", line 1, in > AttributeError: type object 'DictReader' has no attribute 'open' > > > IMO this is preferable than going around adding context manager > > methods to everything that has open-like functionality. > > I disagree. It would be better if resource acquisition (e.g. opening a > file) always took place in an __enter__ method so that it could always > be under control of a with statement. Having closing as a separate > function negates that because there has to be a separate function that > acquires the resource before the closing function is called and hence > before __enter__ is called. > > -- > Oscar > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/AR6IHZ2HY4TKZXKANUGA7HTPDQMBCLRC/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/GBWWTGTSWJAFJ64PR377NOCGYMHBOJUQ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Context manager for csv module 'reader' and 'DictReader'?
Thanks for your comments, everyone! Right, I’m struggling to figure out Greg's example :). Maybe Greg missed that DictReader.open didn’t exist and was in fact what I was asking for! (contextlib.closing is great, thank you for that!) Anyway, just to re-up the original points and add a few - * opening a CSV file with the right newline setting and then applying csv.reader and csv.DictReader is super common. * newline=“” has important ramifications for Windows functionality, as we recently discovered when we tried to extend sourmash with windows compat. * yes it’s very easy to write my own utility function to do this, and in fact I have done so …repeatedly. :) * no one is proposing to remove any functionality. * I like Chris Barker’s comment, “”” it ended with the idea that maybe there should be a PEP for a common interface for all “file” readers — eg JSON, CSV, etc.. And that interface could be supported by third party libs. That interface *maybe* would include a single step load from a path-like functionality. “”” I’m +0 on David Mertz’s suggestion, “”" Most Pandas read methods take either a path-like argument or a file-like argument, and figure out which it is by introspection when called. Actually, most of them even accept a URL-like argument as well I don't think this is a terrible approach. It doesn't make things quite as explicit as the standard library generally does. But it's convenient, and there's no real ambiguity. “”” mostly because when we’ve done this in our own packages, I've struggled to figure out the best method to figure out if something is file-like. For example, it looks like ‘csv.DictReader’ will take any iterable, which means passing in a string is problematic; perhaps we could be looking for read or readline instead? Codifying that in some standard way could be nice. best, —titus > On Sep 5, 2021, at 5:30 PM, Oscar Benjamin wrote: > > On Mon, 6 Sept 2021 at 01:13, Greg Ewing wrote: >> >> On 6/09/21 3:07 am, C. Titus Brown via Python-ideas wrote: >>> with csv.DictReader.open(filename) as r: >>>for row in r: >>> … >> >> You can do this now: >> >> from contextlib import closing >> with closing(csv.DictReader.open(filename)) as r: >>... > > What version of Python are you using? > import csv csv.DictReader.open > Traceback (most recent call last): > File "", line 1, in > AttributeError: type object 'DictReader' has no attribute 'open' > >> IMO this is preferable than going around adding context manager >> methods to everything that has open-like functionality. > > I disagree. It would be better if resource acquisition (e.g. opening a > file) always took place in an __enter__ method so that it could always > be under control of a with statement. Having closing as a separate > function negates that because there has to be a separate function that > acquires the resource before the closing function is called and hence > before __enter__ is called. > > -- > Oscar > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/AR6IHZ2HY4TKZXKANUGA7HTPDQMBCLRC/ > Code of Conduct: http://python.org/psf/codeofconduct/ ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/CNMK76RBWQKVP6F3IZIDTCPFDTFI7HV4/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Improve traceback for common `with` statement mistake
06.09.21 18:42, Chris Angelico пише: > On Tue, Sep 7, 2021 at 1:36 AM Finn Mason wrote: >> Thank you for testing that. I dug through the change log, and found >> bpo-12022: >> https://bugs.python.org/issue12022 >> It has been fixed in 3.11, but not mentioned in the What's New document. >> Should it be? > > If it was indeed a side effect of that change, then there *is* a > What's New entry about it, but it's focusing on other changes: "TypeError: __enter__" would look silly. Minor changes in error messages and docstrings are not worth mentioning in What's New. And changing the type of exception outweigh a change in error message. ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/WTGGVCV53ZDBWFDYKTBU7RILEC7B3T3D/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Improve traceback for common `with` statement mistake
On Tue, Sep 7, 2021 at 1:36 AM Finn Mason wrote: > > Thank you for testing that. I dug through the change log, and found bpo-12022: > https://bugs.python.org/issue12022 > It has been fixed in 3.11, but not mentioned in the What's New document. > Should it be? > If it was indeed a side effect of that change, then there *is* a What's New entry about it, but it's focusing on other changes: https://github.com/python/cpython/pull/26809/files#diff-78f24041d66ab8ed2ae1aee94bcd42396d27af833cb96a3c506294c6d6dce82d It's looking like 3.11 is the version where error messages get improved in all the different ways :) ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/R3G2HIAWPM4YOBE2QORPASCKXWBPD6ML/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Improve traceback for common `with` statement mistake
Thank you for testing that. I dug through the change log, and found
bpo-12022:
https://bugs.python.org/issue12022
It *has* been fixed in 3.11, but not mentioned in the What's New document.
Should it be?
On Sun, Sep 5, 2021, 5:49 PM Chris Angelico wrote:
> On Mon, Sep 6, 2021 at 9:37 AM Finn Mason wrote:
> >
> > Hello all,
> >
> > In Python 3.10 and 3.11, exception tracebacks are being greatly
> improved. I noticed that there's nothing related to a fairly common (in my
> personal experience) cryptic traceback relating to the `with` statement:
> >
> > >>> with ContextManager as ctx:
> > ... # do something with `ctx`
> > ...
> > Traceback (most recent call last):
> > File "", line 1, in
> > AttributeError: __enter__
>
> I'm seeing a different message, so it looks like something HAS been
> improved:
>
> Python 3.11.0a0 (heads/main:ed524b4569, Aug 14 2021, 11:29:01) [GCC
> 8.3.0] on linux
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import contextlib
> >>> with contextlib.ExitStack: ...
> ...
> Traceback (most recent call last):
> File "", line 1, in
> TypeError: 'ABCMeta' object does not support the context manager protocol
>
>
> > This occurs when one forgets to use a instance of a context manager
> class and uses the class itself. It's obviously not a very helpful
> traceback. ("Is it not a context manager?" "Is it the wrong class?")
> Something like the following would be better.
> >
> > >>> with ContextManager as ctx:
> > ... # do something with `ctx`
> > ...
> > Traceback (most recent call last):
> > File "", line 1, in
> > AttributeError: is not a context manager. Did you
> mean "with ContextManager()..."?
> >
> > The actual traceback message should probably be more specific than
> " is not a context manager".
> > Thoughts?
> >
>
> The "did you mean" part depends on or assumes that it can figure out
> that calling it would have given a viable context manager. This could
> be done by probing whether thing.__enter__ exists, but I'm not sure
> that'd be entirely safe. Also, it won't catch those made from
> generators:
>
> >>> @contextlib.contextmanager
> ... def foo(): yield
> ...
> >>> with foo: ...
> ...
> Traceback (most recent call last):
> File "", line 1, in
> TypeError: 'function' object does not support the context manager protocol
> >>> with foo(): ...
> ...
> Ellipsis
> >>> foo
>
>
>
> In any case, the biggest advantage (IMO) comes from naming the type,
> which will make it easy to distinguish the object from its type.
>
> ChrisA
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/NGP5LQSRS2XPNHIRBN3O76UGMEB623TW/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/56MVDUFOD6GLSTCWIKZBJQO65P3HHJ6N/
Code of Conduct: http://python.org/psf/codeofconduct/
