Re: How to test?
On 25/04/20 5:16 PM, Manfred Lotz wrote: On Fri, 24 Apr 2020 19:12:39 -0300 Cholo Lennon wrote: On 24/4/20 15:40, Manfred Lotz wrote: I have a command like application which checks a directory tree for certain things. If there are errors then messages will be written to stdout. How to test this in the best way? One idea was for the error situations to write messages to files and then later when running the tests to compare the error messages output to the previously saved output. Is there anything better? Maybe I am wrong because I don't understand your scenario: If your application is like a command, it has to return an error code to the system, a distinct number for each error condition. The error code is easier to test than the stdout/stderr. Yes, a different error code for each condition is good to test. However, I need to test as well the correct file name and other values belonging to a certain error condition. It is frustrating to be shown only part of the information, and later be told our efforts aren't good-enough. How about respecting our (donated) time, and posting some sample code that shows exactly what/where the problem lies? From the above, I'm wondering if a custom exception might be applicable. -- Regards =dn -- https://mail.python.org/mailman/listinfo/python-list
Re: How to test?
On 24 Apr 2020 22:18:45 GMT r...@zedat.fu-berlin.de (Stefan Ram) wrote: > DL Neil writes: > >Python's logging library enables messages to be formatted > >accordingly, and directed differently, depending upon 'level of > >severity'. So, as well as the flexibility mentioned before, there is > >an option to direct logging output to stdout/stderr as a > >matter-of-course! > > Here's some example code I wrote: > > import logging > > def setup_logging( logging ): > """Setup a logger using the standard logging module, > which needs to be passed as the argument""" > logger = logging.getLogger() > handler = logging.StreamHandler() > formatter = logging.Formatter( '%(asctime)s %(name)-12s > %(levelname)-8s %(message)s' ) handler.setFormatter( formatter ) > logger.addHandler( handler ) > logger.setLevel( logging.DEBUG ) > return logger > > logger = setup_logging( logging ) > logger.debug( "Hi!" ) > > It outputs (apparently to sys.stderr): > > 2020-04-24 23:13:59,467 root DEBUGHi! > > Yes, I know about this. But in this particular case I don't gain much by using a logger. print() is good enough. I will investigate yielding and callback to see which is best in my particular case. -- https://mail.python.org/mailman/listinfo/python-list
Re: How to test?
On Fri, 24 Apr 2020 19:12:39 -0300 Cholo Lennon wrote: > On 24/4/20 15:40, Manfred Lotz wrote: > > I have a command like application which checks a directory tree for > > certain things. If there are errors then messages will be written to > > stdout. > > > > How to test this in the best way? > > > > One idea was for the error situations to write messages to files and > > then later when running the tests to compare the error messages > > output to the previously saved output. > > > > Is there anything better? > > > > > > Maybe I am wrong because I don't understand your scenario: If your > application is like a command, it has to return an error code to the > system, a distinct number for each error condition. The error code is > easier to test than the stdout/stderr. > Yes, a different error code for each condition is good to test. However, I need to test as well the correct file name and other values belonging to a certain error condition. -- https://mail.python.org/mailman/listinfo/python-list
Re: How to test?
On 24/4/20 15:40, Manfred Lotz wrote: I have a command like application which checks a directory tree for certain things. If there are errors then messages will be written to stdout. How to test this in the best way? One idea was for the error situations to write messages to files and then later when running the tests to compare the error messages output to the previously saved output. Is there anything better? Maybe I am wrong because I don't understand your scenario: If your application is like a command, it has to return an error code to the system, a distinct number for each error condition. The error code is easier to test than the stdout/stderr. -- Cholo Lennon Bs.As. ARG -- https://mail.python.org/mailman/listinfo/python-list
Re: How to test?
May I point-out that the above may not be the best approach. Rather than using screen-prints to report errors, another method is to utilise "logging" to collect such data - so that there is always a formal record (regardless of user behavior). During 'production' the information could be collected at some central 'location' for inspection by competent staff. During 'development', it is possible, by changing one line, to re-direct the log to wherever you would like - including the above! Logging wouldn't help here as the person running the program is competent, and it likes to see what the errors are. Perhaps it is a 'traditional view' that "logging" implies capture to some "log file". Python's logging library enables messages to be formatted accordingly, and directed differently, depending upon 'level of severity'. So, as well as the flexibility mentioned before, there is an option to direct logging output to stdout/stderr as a matter-of-course! (and thus, today's user can have output to the screen, but if another and less-capable user joins-the-club, his/her output could easily be re-directed. On the other hand: YAGNI!) -- Regards =dn -- https://mail.python.org/mailman/listinfo/python-list
Re: How to test?
On Sat, 25 Apr 2020 08:25:00 +1200 DL Neil wrote: > On 25/04/20 6:40 AM, Manfred Lotz wrote: > > I have a command like application which checks a directory tree for > > certain things. If there are errors then messages will be written to > > stdout. > > > > How to test this in the best way? > > > > One idea was for the error situations to write messages to files and > > then later when running the tests to compare the error messages > > output to the previously saved output. > > > > Is there anything better? > > Yes, as well as reproducing the output on-screen, there are now three > ways to deal with stdout. The newest is "tee", which like the Linux > command of the same name, gives the best of both worlds - display and > 'capture'! > > Capturing of the stdout/stderr output > https://docs.pytest.org/en/latest/capture.html > > This is interesing. > May I point-out that the above may not be the best approach. Rather > than using screen-prints to report errors, another method is to > utilise "logging" to collect such data - so that there is always a > formal record (regardless of user behavior). During 'production' the > information could be collected at some central 'location' for > inspection by competent staff. During 'development', it is possible, > by changing one line, to re-direct the log to wherever you would like > - including the above! > Logging wouldn't help here as the person running the program is competent, and it likes to see what the errors are. -- Manfred -- https://mail.python.org/mailman/listinfo/python-list
Re: How to test?
On 24 Apr 2020 20:17:04 GMT r...@zedat.fu-berlin.de (Stefan Ram) wrote: > Manfred Lotz writes: > >I have a command like application which checks a directory tree for > >certain things. If there are errors then messages will be written to > >stdout. > > Error messages should be written to sys.stderr. > Yes. But for testing it doesn't matter if it is written to stdout or stderr. > >How to test this in the best way? > > The functions that check the tree should not write to > the console. Instead, when an error occurs they > > - raise an exception, This would be bad. In my case I want to report all the errors to somebody else. An exception means I don't see more errors which may have occured. > - yield an error information, Hm, you mean the check function would be something like an iterator. Sounds interesting. > - return an error information, or I think this is harder to implement. > - call a callback with the error information. > > Their callers than can be either high-level console code, > that writes those information to a console, or test code. > This is also very interesting. So, I think yield or callback are the ideas I have to investigate. Thanks a lot. -- Manfred -- https://mail.python.org/mailman/listinfo/python-list
Re: How to test?
On 25/04/20 6:40 AM, Manfred Lotz wrote: I have a command like application which checks a directory tree for certain things. If there are errors then messages will be written to stdout. How to test this in the best way? One idea was for the error situations to write messages to files and then later when running the tests to compare the error messages output to the previously saved output. Is there anything better? Yes, as well as reproducing the output on-screen, there are now three ways to deal with stdout. The newest is "tee", which like the Linux command of the same name, gives the best of both worlds - display and 'capture'! Capturing of the stdout/stderr output https://docs.pytest.org/en/latest/capture.html May I point-out that the above may not be the best approach. Rather than using screen-prints to report errors, another method is to utilise "logging" to collect such data - so that there is always a formal record (regardless of user behavior). During 'production' the information could be collected at some central 'location' for inspection by competent staff. During 'development', it is possible, by changing one line, to re-direct the log to wherever you would like - including the above! Python library: https://docs.python.org/3/library/logging.html Logging (testing): https://docs.pytest.org/en/latest/logging.html -- Regards =dn -- https://mail.python.org/mailman/listinfo/python-list
How to test?
I have a command like application which checks a directory tree for certain things. If there are errors then messages will be written to stdout. How to test this in the best way? One idea was for the error situations to write messages to files and then later when running the tests to compare the error messages output to the previously saved output. Is there anything better? -- Thanks, Manfred -- https://mail.python.org/mailman/listinfo/python-list
Re: Why does super(bool) give None
On Sat, Apr 25, 2020 at 4:20 AM Random832 wrote: > > On Fri, Apr 24, 2020, at 02:10, Cecil Westerhof wrote: > > issubclass(bool, int) gives True > > but > > super(bool) gives > > > > Do I not understand the meaning of super, or is this inconsistent? > > I've never heard of a one-argument form for super, but I just tried something > and now I'm confused about the two-argument form > > >>> super(bool, True).__str__() > 'True' > > I expected '1' - does anyone know why this happens? The bool type doesn't actually define __str__, so calling it via super gives the same result that you get by calling it directly. Since __str__ isn't defined, the default implementation (on object itself) returns self.__repr__(), so you get the same result that you'd get by looking at the repr for it. But if you do that same exercise with repr... >>> super(bool, True).__repr__() '1' That's what you're expecting. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Why does super(bool) give None
On Fri, Apr 24, 2020, at 02:10, Cecil Westerhof wrote: > issubclass(bool, int) gives True > but > super(bool) gives > > Do I not understand the meaning of super, or is this inconsistent? I've never heard of a one-argument form for super, but I just tried something and now I'm confused about the two-argument form >>> super(bool, True).__str__() 'True' I expected '1' - does anyone know why this happens? -- https://mail.python.org/mailman/listinfo/python-list
Re: Problem in importing pandas
For the same problem, The solution, I found is to install package spicy. Then *import spicy* along with *import pandas. * It really works - But the instructions should be - *import spicy* *import pandas* On Fri, 24 Apr 2020, 01:12 MRAB, wrote: > On 2020-04-23 18:57, Amit Jain wrote: > > Dear Sir/Madam, > > After *successful installation of PIP for PANDAS *when I try to *import > > pandas*, It gives error as given below - > > > import pandas as pd > > Traceback (most recent call last): > >File "", line 1, in > > import pandas as pd > >File > > > "C:\Users\Amit\AppData\Local\Programs\Python\Python38-32\lib\site-packages\pandas\__init__.py", > > line 55, in > > from pandas.core.api import ( > >File > > > "C:\Users\Amit\AppData\Local\Programs\Python\Python38-32\lib\site-packages\pandas\core\api.py", > > line 29, in > > from pandas.core.groupby import Grouper, NamedAgg > >File > > > "C:\Users\Amit\AppData\Local\Programs\Python\Python38-32\lib\site-packages\pandas\core\groupby\__init__.py", > > line 1, in > > from pandas.core.groupby.generic import DataFrameGroupBy, NamedAgg, > > SeriesGroupBy > >File > > > "C:\Users\Amit\AppData\Local\Programs\Python\Python38-32\lib\site-packages\pandas\core\groupby\generic.py", > > line 60, in > > from pandas.core.frame import DataFrame > >File > > > "C:\Users\Amit\AppData\Local\Programs\Python\Python38-32\lib\site-packages\pandas\core\frame.py", > > line 124, in > > from pandas.core.series import Series > >File > > > "C:\Users\Amit\AppData\Local\Programs\Python\Python38-32\lib\site-packages\pandas\core\series.py", > > line 4572, in > > Series._add_series_or_dataframe_operations() > >File > > > "C:\Users\Amit\AppData\Local\Programs\Python\Python38-32\lib\site-packages\pandas\core\generic.py", > > line 10349, in _add_series_or_dataframe_operations > > from pandas.core.window import EWM, Expanding, Rolling, Window > >File > > > "C:\Users\Amit\AppData\Local\Programs\Python\Python38-32\lib\site-packages\pandas\core\window\__init__.py", > > line 1, in > > from pandas.core.window.ewm import EWM # noqa:F401 > >File > > > "C:\Users\Amit\AppData\Local\Programs\Python\Python38-32\lib\site-packages\pandas\core\window\ewm.py", > > line 5, in > > import pandas._libs.window.aggregations as window_aggregations > > ImportError: DLL load failed while importing aggregations: The specified > > module could not be found. > > > > > > I am not able to run pandas. > > *Kindly help me to resolve this problem.* > > > After searching on Google, this looks like your problem: > > ImportError: DLL load failed with Windows wheel for 1.0.2 and 1.0.3 #32857 > https://github.com/pandas-dev/pandas/issues/32857 > > The last comment (jshridha) gives a solution. > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: Why does super(bool) give None
Cecil Westerhof writes: >> I've never actually looked at the repr of a super object - I've always >> just called a method on it immediately after constructing it. Never >> seen a need to hang onto one :) > > Well, maybe I will never need it, but I am just curious. And sometimes > it was very handy that I had sought out 'useless' things. You can get the information with the inspect module (done with ipython3): In [1]: import inspect In [2]: inspect.getmro(bool) Out[2]: (bool, int, object) -- Cecil Westerhof Senior Software Engineer LinkedIn: http://www.linkedin.com/in/cecilwesterhof -- https://mail.python.org/mailman/listinfo/python-list
Re: Why does super(bool) give None
Chris Angelico writes: > On Fri, Apr 24, 2020 at 4:16 PM Cecil Westerhof wrote: >> >> issubclass(bool, int) gives True >> but >> super(bool) gives >> >> Do I not understand the meaning of super, or is this inconsistent? >> >> (Until now I have not down much work with classes in Python.) >> > > One-arg super is an unbound object, and the "None" just indicates > that. (Although every Python that I've tried says NULL there, not > None. What version are you using?) That was because I was using ipython3, python does what you expect: Python 3.7.3 (default, Dec 20 2019, 18:57:59) [GCC 8.3.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> super(bool) , NULL> When using ipython3 it goes like: Python 3.7.3 (default, Dec 20 2019, 18:57:59) Type 'copyright', 'credits' or 'license' for more information IPython 7.13.0 -- An enhanced Interactive Python. Type '?' for help. In [1]: super(bool) Out[1]: > It doesn't say what "the parent class" is, because super doesn't > actually work with parent classes - it lets you call the *next* > class. (In complex inheritance trees, that can mean going across a > diamond or anything.) I have more learning to do as I tought. ;-) > I've never actually looked at the repr of a super object - I've always > just called a method on it immediately after constructing it. Never > seen a need to hang onto one :) Well, maybe I will never need it, but I am just curious. And sometimes it was very handy that I had sought out 'useless' things. -- Cecil Westerhof Senior Software Engineer LinkedIn: http://www.linkedin.com/in/cecilwesterhof -- https://mail.python.org/mailman/listinfo/python-list
