Re: [Tutor] test
On Thu, Mar 30, 2017 at 4:11 PM, bruce wrote: > sent a question earlier.. and got a reply saying it was in the > moderation process??? You've made it through the process. See the bottom of https://mail.python.org/pipermail/tutor/2017-March/thread.html to see your original question and the answers. -- boB ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
[Tutor] test
sent a question earlier.. and got a reply saying it was in the moderation process??? ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Test for type(object) == ???
On Sat, Feb 11, 2017 at 01:00:11PM +1100, Ben Finney wrote: > boB Stepp writes: > > > I was playing around with type() tonight. If I type (pun intended), I get: > > > > py3: type(5) > > > > Ceci n'est pas un ‘int’. [...] > https://en.wikipedia.org/wiki/The_Treachery_of_Images> For anyone interested in this concept and how it relates to programming, and many other mind-expanding concepts, I cannot recommend enough the famous book Gödel, Escher, Bach: An Eternal Golden Braid by Douglas Hofstadter. It is a mighty tome, but don't be put off by the size and weight. It covers some *extremely* subtle concepts, but it works up to them in baby steps, with the aid of dialogs between Archilles and the Tortoise. -- Steve ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Test for type(object) == ???
On Fri, Feb 10, 2017 at 07:34:35PM -0600, boB Stepp wrote: > I was playing around with type() tonight. If I type (pun intended), I get: > > py3: type(5) > > > So I naively thought a test for type int should go like: > > py3: type(5) == "" > False The interactive intepreter is great, but you have to remember that what you see is not necessarily what you've got. What you *see* is the string representation of the object: py> print but what you've actually got is the object itself; in this case, it is the print function, and in your case, it is the int class. Generally angle brackets < > mean that the text between the brackets is just a display form, something intended for the human reader, and not a programmable syntax. You then have to know (from experience) how to refer to the object in code. In the case of int, there are three distinct things here: - the class (or type) itself, a blob of memory somewhere in the interpreter containing various methods and attributes used for working with integers; - the name the interpreter knows that class by, namely "int"; - the string representation for the human reader, "". So long as you remember the difference between the object itself, the name we use to talk about the object, and the way we visually display the object, you can't go wrong :-) (The nation Russia is not the same as a map of Russia, which is not the same as the word Russia, which is not the same as the letters R u s s i a, or even Р о с с и ́я for that matter). As they say: the map is not the territory. Or in the words of Steven Wright, "I have a map of the United States... Actual size. It says, 'Scale: 1 mile = 1 mile.' I spent last summer folding it." > I finally stumbled onto the correct form: > > py3: type(5) == int > True type(5) returns the class that we call "int". The name "int" returns that same class. > So my question is why does "type(5)" result in "", No, that's just the string representation of int. Inside the interactive interpreter, when you hit ENTER, the interpreter evaluates the line of code you have, generates a result, and then does the equivalent of: print(repr(result)) (except that None is suppressed). -- Steve ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Test for type(object) == ???
On Sat, Feb 11, 2017 at 7:35 AM, boB Stepp wrote: > Has this PEP been implemented yet? I am running Python 3.5.2 and it > appears not to work. Also, in "What's New In Python 3.6" > (https://docs.python.org/3/whatsnew/3.6.html) I did not see a mention > of it. You can see in the document header that PEP 457 is an Informational document at the draft stage, as opposed to a Standards Track document that's finalized. It's the best I could find as provisional documentation of CPython's usage of '/' to mark positional-only arguments of built-in functions. FYI, the PEP's author, Larry Hastings, is also the author of Argument Clinic. ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Test for type(object) == ???
On Sat, Feb 11, 2017 at 12:57 AM, eryk sun wrote: > > The '/' syntax for positional-only arguments is documented in PEP 457. > > https://www.python.org/dev/peps/pep-0457 At https://www.python.org/dev/peps/pep-0457/#id14 in PEP 457 it says: >From the "ten-thousand foot view", and ignoring *args and **kwargs for now, the grammar for a function definition currently looks like this: def name(positional_or_keyword_parameters, *, keyword_only_parameters): Building on that perspective, the new syntax for functions would look like this: def name(positional_only_parameters, /, positional_or_keyword_parameters, *, keyword_only_parameters): All parameters before the / are positional-only. If / is not specified in a function signature, that function does not accept any positional-only parameters. Has this PEP been implemented yet? I am running Python 3.5.2 and it appears not to work. Also, in "What's New In Python 3.6" (https://docs.python.org/3/whatsnew/3.6.html) I did not see a mention of it. > Also see the how-to for CPython's "Argument Clinic" preprocessor, > since (for now) positional-only arguments are only a concern for > built-in functions. So I am assuming this syntax is only being used for some built-in functions? You have provided a lot of interesting information. I'm not sure if I am comprehending everything, but it has made interesting reading and Googling tonight. Enough so that I have stayed up much later than I meant to! Thanks! -- boB ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Test for type(object) == ???
On Sat, Feb 11, 2017 at 6:22 AM, boB Stepp wrote: > On Fri, Feb 10, 2017 at 11:49 PM, eryk sun wrote: > >> It's from the function's __text_signature__. >> >> >>> repr.__text_signature__ >> '($module, obj, /)' >> >> It means "obj" is a positional-only argument that cannot be passed as a >> keyword. > > [snip] > >> Look at open() for comparison. >> >> >>> open.__text_signature__ >> "($module, /, file, mode='r', buffering=-1, encoding=None,\n >> errors=None, newline=None, closefd=True, opener=None)" > > In your comparison example, a forward slash appears again, but this > time after "$module" in the location where "obj" previously appeared > in the repr example. Is it indicating a similar use here? All parameters listed before the slash are position-only. Everything after the slash can be passed as a keyword argument. > Can you provide a link to "__text_signature__" in the docs? I tried > searching for it, but came up empty. No, I can't. It was added in issue 19674. http://bugs.python.org/issue19674 The '/' syntax for positional-only arguments is documented in PEP 457. https://www.python.org/dev/peps/pep-0457 Also see the how-to for CPython's "Argument Clinic" preprocessor, since (for now) positional-only arguments are only a concern for built-in functions. https://docs.python.org/3/howto/clinic.html ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Test for type(object) == ???
On Fri, Feb 10, 2017 at 11:49 PM, eryk sun wrote: > On Sat, Feb 11, 2017 at 3:22 AM, boB Stepp wrote: >> >> py3: help(repr) >> Help on built-in function repr in module builtins: >> >> repr(obj, /) >> Return the canonical string representation of the object. >> >> For many object types, including most builtins, eval(repr(obj)) == obj. >> >> Question: What does the forward slash represent in this context? > > It's from the function's __text_signature__. > > >>> repr.__text_signature__ > '($module, obj, /)' > > It means "obj" is a positional-only argument that cannot be passed as a > keyword. [snip] > Look at open() for comparison. > > >>> open.__text_signature__ > "($module, /, file, mode='r', buffering=-1, encoding=None,\n > errors=None, newline=None, closefd=True, opener=None)" In your comparison example, a forward slash appears again, but this time after "$module" in the location where "obj" previously appeared in the repr example. Is it indicating a similar use here? Can you provide a link to "__text_signature__" in the docs? I tried searching for it, but came up empty. -- boB ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Test for type(object) == ???
On Sat, Feb 11, 2017 at 3:22 AM, boB Stepp wrote: > > py3: help(repr) > Help on built-in function repr in module builtins: > > repr(obj, /) > Return the canonical string representation of the object. > > For many object types, including most builtins, eval(repr(obj)) == obj. > > Question: What does the forward slash represent in this context? It's from the function's __text_signature__. >>> repr.__text_signature__ '($module, obj, /)' It means "obj" is a positional-only argument that cannot be passed as a keyword. >>> s = inspect.signature(repr) >>> s.parameters['obj'].kind <_ParameterKind.POSITIONAL_ONLY: 0> CPython has a lot of built-in functions that don't allow keyword arguments. >>> repr(obj=42) Traceback (most recent call last): File "", line 1, in TypeError: repr() takes no keyword arguments Look at open() for comparison. >>> open.__text_signature__ "($module, /, file, mode='r', buffering=-1, encoding=None,\n errors=None, newline=None, closefd=True, opener=None)" All of its parameters can be passed as keyword arguments. >>> s = inspect.signature(open) >>> s.parameters['file'].kind <_ParameterKind.POSITIONAL_OR_KEYWORD: 1> >>> s.parameters['mode'].kind <_ParameterKind.POSITIONAL_OR_KEYWORD: 1> For example: >>> open(file='spam', mode='w') <_io.TextIOWrapper name='spam' mode='w' encoding='UTF-8'> ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Test for type(object) == ???
Thanks for the detailed information. I have a final really nitpicky question. On Fri, Feb 10, 2017 at 11:27 PM, eryk sun wrote: > On Sat, Feb 11, 2017 at 4:32 AM, boB Stepp wrote: >> >> This bit got me experimenting. Since the integer "5" is an integer >> object instance, I am wondering why I can't do: >> >> py3: 5.__repr__() >> File "", line 1 >> 5.__repr__() >> ^ >> SyntaxError: invalid syntax [snip] > The parser sees "5." as a floating point number. I am curious as to why the caret does not point to the first underscore after the decimal point in the error message? It is at that precise character that the discerned syntax error occurs. boB ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Test for type(object) == ???
On Sat, Feb 11, 2017 at 4:32 AM, boB Stepp wrote: > > This bit got me experimenting. Since the integer "5" is an integer > object instance, I am wondering why I can't do: > > py3: 5.__repr__() > File "", line 1 > 5.__repr__() > ^ > SyntaxError: invalid syntax > > , but I can do: > > py3: x = 5 > py3: x.__repr__() > '5' The parser sees "5." as a floating point number. You can use parentheses to force it to parse 5 as an integer: >>> (5).__repr__() '5' > But in class examples I've seen posted, I do not recall __repr__ ever > being defined. So I infer that most of the time I should not or need not > do so, but under what circumstances should I do so? Classes inherit a default __repr__ from `object`. For example: >>> object.__repr__(5) '' Define a custom __repr__ when it's useful for debugging to include additional information. It also gets called for str() if you don't implement a custom __str__. > Another curiosity question. If I type: > > py3: repr(int) > "" > > I get what I expect, but if I do the same with my custom class, "boB", > I instead get: > > py3: repr(boB) > "" > > Why the difference between the Python class "int" and my custom class > "boB"? Did I not define __repr__() correctly? The __repr__ defined by your class is used for instances of the class, not for the class itself. In the above you're seeing the return value from the metaclass __repr__ that's defined by `type`: In CPython, type.__repr__ is implemented in C as type_repr in Objects/typeobject.c. If it can determine the module and qualified name of a class, then it uses the template "". Otherwise it uses the template "" with the basic char *tp_name from the PyTypeObject. ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Test for type(object) == ???
On Fri, Feb 10, 2017 at 8:05 PM, eryk sun wrote: > Speaking of classes and metaclasses, note that you can't call > int.__repr__(int) to get this representation, because the __repr__ > special method of int is meant for instances of int such as int(5). This bit got me experimenting. Since the integer "5" is an integer object instance, I am wondering why I can't do: py3: 5.__repr__() File "", line 1 5.__repr__() ^ SyntaxError: invalid syntax , but I can do: py3: x = 5 py3: x.__repr__() '5' ? More experimentation. Is this how I would define __repr__() for a custom class? py3: class boB: ... def __repr__(self): ... return "" ... py3: x = boB() py3: repr(x) "" Seems to work. But in class examples I've seen posted, I do not recall __repr__ ever being defined. So I infer that most of the time I should not or need not do so, but under what circumstances should I do so? Another curiosity question. If I type: py3: repr(int) "" I get what I expect, but if I do the same with my custom class, "boB", I instead get: py3: repr(boB) "" Why the difference between the Python class "int" and my custom class "boB"? Did I not define __repr__() correctly? -- boB ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Test for type(object) == ???
On Fri, Feb 10, 2017 at 7:50 PM, Zachary Ware wrote: > Try `help(repr)` and `int` on its own at the interactive prompt, and py3: help(repr) Help on built-in function repr in module builtins: repr(obj, /) Return the canonical string representation of the object. For many object types, including most builtins, eval(repr(obj)) == obj. Question: What does the forward slash represent in this context? If I type: py3: repr(int, /) File "", line 1 repr(int, /) ^ SyntaxError: invalid syntax whereas: py3: repr(int) "" appears to be correct. -- boB ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Test for type(object) == ???
On Sat, Feb 11, 2017 at 1:34 AM, boB Stepp wrote: > I was playing around with type() tonight. If I type (pun intended), I get: > > py3: type(5) > `type` is a metaclass that either creates a new class (given 3 arguments: name, bases, and dict) or returns a reference to the class of an existing object. type(5) is the latter case, and it returns a reference to the class `int`. What you see printed in the REPL is repr(int), a string representation of the class object: >>> repr(int) "" Speaking of classes and metaclasses, note that you can't call int.__repr__(int) to get this representation, because the __repr__ special method of int is meant for instances of int such as int(5). Instead you have to explicitly use __repr__ from the metaclass, i.e. `type`: >>> type(int) >>> type.__repr__(int) "" But just use built-in repr(). ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Test for type(object) == ???
boB Stepp writes: > I was playing around with type() tonight. If I type (pun intended), I get: > > py3: type(5) > Ceci n'est pas un ‘int’. > So I naively thought a test for type int should go like: > > py3: type(5) == "" > False > > Hmm. The output from the REPL can only be text. But a type, or any other object in memory, is not text on the screen; the text only *represents* an object. More than that: You can't type objects into your program code. You have to *reference* them, often by using names. So the type ‘int’ can be referenced by the name, ‘int’: >>> type(5) is int True And that type, when asked for a text representation, will give you some text. >>> type(5) The object is not its name. The object is not its representation. And those can (and in this case, are) all different. https://en.wikipedia.org/wiki/The_Treachery_of_Images> -- \ “Programs must be written for people to read, and only | `\incidentally for machines to execute.” —Abelson & Sussman, | _o__) _Structure and Interpretation of Computer Programs_ | Ben Finney ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Test for type(object) == ???
On 2017-02-10 17:34, boB Stepp wrote: I was playing around with type() tonight. . I've also "played around" with this subject- Here's a source: http://stackoverflow.com/questions/152580/whats-the-canonical-way-to-check-for-type-in-python ... and a successful experiment: alex@X301n3:~$ python3 Python 3.4.3 (default, Nov 17 2016, 01:11:57) [GCC 4.8.4] on linux Type "help", "copyright", "credits" or "license" for more information. type(5) is int True isinstance(5, int) True ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Test for type(object) == ???
On Fri, Feb 10, 2017 at 7:34 PM, boB Stepp wrote: > So my question is why does "type(5)" result in "", but > the correct Boolean test is "type(5) == int"? I suspect it has > something to do with the built-in attributes of Python objects that I > currently know so very little about. Try `help(repr)` and `int` on its own at the interactive prompt, and see if that clarifies anything. I hope that might be enough to nudge you in the right direction, but if not, come back and ask :) -- Zach ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
[Tutor] Test for type(object) == ???
I was playing around with type() tonight. If I type (pun intended), I get: py3: type(5) So I naively thought a test for type int should go like: py3: type(5) == "" False Hmm. So I tried these other failing tests: py3: type(5) == File "", line 1 type(5) == ^ SyntaxError: invalid syntax py3: type(5) == 'int()' False I finally stumbled onto the correct form: py3: type(5) == int True So my question is why does "type(5)" result in "", but the correct Boolean test is "type(5) == int"? I suspect it has something to do with the built-in attributes of Python objects that I currently know so very little about. As always, many thanks in advance! -- boB ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Test discovery not locating module to test
boB Stepp wrote: > On Thu, Aug 20, 2015 at 2:37 AM, Peter Otten <__pete...@web.de> wrote: > >> Assuming E:/Projects/mcm/src is in the PYTHONPATH mcm_db_mgr.py (what an >> alphabet soup!)... > > Written out in full, this would be > > montessori_classroom_manager_database_manager.py > Hmm. Perhaps just db_manager.py? How about manager.py? If you increase the nesting level by introducing an mcm toplevel package you can access the module formerly known as db.mcm_db_mgr with import mcm.db.manager or from mcm.db import manager and avoid the mixture of logical "_" and physical "." separators. ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Test discovery not locating module to test
On Thu, Aug 20, 2015 at 2:37 AM, Peter Otten <__pete...@web.de> wrote: > Assuming E:/Projects/mcm/src is in the PYTHONPATH mcm_db_mgr.py (what an > alphabet soup!)... Written out in full, this would be montessori_classroom_manager_database_manager.py Hmm. Perhaps just db_manager.py? > ...is part of your db package and has to be imported with > > import db.mcm_db_mgr > > or > > from db import mcm_db_mgr > > by modules outside the db package. I'm bad! So clear in the morning, so obscure for me just before bed. In my defense, I have intellectually *known* about this, but have not used the standard library much to this point, and this is the first time I have tried this *package* structure of a project, so that aspect is all new to me. Thanks, Peter! boB ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Test discovery not locating module to test
boB Stepp wrote: > W7 64-bit. Py 3.4.3 > > unittest result: > > E:\Projects\mcm>python -m unittest > E > == > ERROR: test.db.test_mcm_db_mgr (unittest.loader.ModuleImportFailure) > -- > Traceback (most recent call last): > File "C:\Python34\lib\unittest\case.py", line 58, in testPartExecutor > yield > File "C:\Python34\lib\unittest\case.py", line 577, in run > testMethod() > File "C:\Python34\lib\unittest\loader.py", line 32, in testFailure > raise exception > ImportError: Failed to import test module: test.db.test_mcm_db_mgr > Traceback (most recent call last): > File "C:\Python34\lib\unittest\loader.py", line 312, in _find_tests > module = self._get_module_from_name(name) > File "C:\Python34\lib\unittest\loader.py", line 290, in > _get_module_from_name > __import__(name) > File "E:\Projects\mcm\test\db\test_mcm_db_mgr.py", line 22, in > import mcm_db_mgr > ImportError: No module named 'mcm_db_mgr' > > > -- > Ran 1 test in 0.000s > > FAILED (errors=1) > > Relevant code in test_mcm_db_mgr.py: > > import unittest > > # import modules to be tested: > import mcm_db_mgr > > class MCMDBMgrTestCase(unittest.TestCase): > def setUp(self): > # Insert setup code here... > pass > > def test_open_mcm_db(self): > pass > > def tearDown(self): > # Insert tear-down code here... > pass > > > I suspect that there is something wrong with my project structure. > Currently it is as follows: > > Projects/ > --mcm/ > .git/ > doc/ > src/ > --db/ > __init__.py > mcm_db_mgr.py > --ui/ > __init__.py > test/ > --db/ > __init__.py > test_mcm_db_mgr.py > --ui/ > __init__.py > .gitignore > LICENSE.txt > README.txt > > All __init__.py files are currently empty. Alex had asked a question > very similar to this situation, and I thought I had understood the > answer Laura had given, but apparently I do not understand. Where am > I going wrong this time? Assuming E:/Projects/mcm/src is in the PYTHONPATH mcm_db_mgr.py (what an alphabet soup!) is part of your db package and has to be imported with import db.mcm_db_mgr or from db import mcm_db_mgr by modules outside the db package. ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
[Tutor] Test discovery not locating module to test
W7 64-bit. Py 3.4.3 unittest result: E:\Projects\mcm>python -m unittest E == ERROR: test.db.test_mcm_db_mgr (unittest.loader.ModuleImportFailure) -- Traceback (most recent call last): File "C:\Python34\lib\unittest\case.py", line 58, in testPartExecutor yield File "C:\Python34\lib\unittest\case.py", line 577, in run testMethod() File "C:\Python34\lib\unittest\loader.py", line 32, in testFailure raise exception ImportError: Failed to import test module: test.db.test_mcm_db_mgr Traceback (most recent call last): File "C:\Python34\lib\unittest\loader.py", line 312, in _find_tests module = self._get_module_from_name(name) File "C:\Python34\lib\unittest\loader.py", line 290, in _get_module_from_name __import__(name) File "E:\Projects\mcm\test\db\test_mcm_db_mgr.py", line 22, in import mcm_db_mgr ImportError: No module named 'mcm_db_mgr' -- Ran 1 test in 0.000s FAILED (errors=1) Relevant code in test_mcm_db_mgr.py: import unittest # import modules to be tested: import mcm_db_mgr class MCMDBMgrTestCase(unittest.TestCase): def setUp(self): # Insert setup code here... pass def test_open_mcm_db(self): pass def tearDown(self): # Insert tear-down code here... pass I suspect that there is something wrong with my project structure. Currently it is as follows: Projects/ --mcm/ .git/ doc/ src/ --db/ __init__.py mcm_db_mgr.py --ui/ __init__.py test/ --db/ __init__.py test_mcm_db_mgr.py --ui/ __init__.py .gitignore LICENSE.txt README.txt All __init__.py files are currently empty. Alex had asked a question very similar to this situation, and I thought I had understood the answer Laura had given, but apparently I do not understand. Where am I going wrong this time? TIA! -- boB ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Test to check if values of dictionary are all equal (which happen to be dictionaries)
Jignesh Sutar wrote:
> I needed to test if the values of all entries in a dictionary were equal
> but since the values themselves were dictionaries I couldn't simply take a
> set of the values and test if this equated to one. So I ended up taking
> all combination of the keys and testing pairs of sub dictionaries. I just
> want to check that there isn't a more direct way of doing this that
> testing all combinations?
>
>
> import itertools
>
> dictmain={"K1": {1:"SD_V1",2:"SD_V2"},
> "K2": {1:"SD_V1",2:"SD_V2"},
> "K3": {1:"SD_V1",2:"SD_V2"}}
>
> for compare in list(itertools.combinations(dictmain,2)):
> print "Comparing dictionaries:", compare
>
> if dictmain[compare[0]]==dictmain[compare[1]]:
> print "comb dict are equal"
> else:
> print "comb dict are NOT equal"
> break
>
>
> Many thanks in advance,
> Jignesh
If you don't have exotic data in your dicts equality should be transitive,
i. e. from
a == b and a == c
follows
b == c
so that you don't have to test the latter explicitly.
This reduces the number of tests significantly.
values = dictmain.itervalues() # Python 3: iter(dictmain.values())
first = next(values) # pick an arbitrary value to compare against all others
if all(first == item for item in values):
print("all dicts are equal")
else:
print("not all dicts are equal")
___
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor
[Tutor] Test to check if values of dictionary are all equal (which happen to be dictionaries)
I needed to test if the values of all entries in a dictionary were equal
but since the values themselves were dictionaries I couldn't simply take a
set of the values and test if this equated to one. So I ended up taking all
combination of the keys and testing pairs of sub dictionaries. I just want
to check that there isn't a more direct way of doing this that testing all
combinations?
import itertools
dictmain={"K1": {1:"SD_V1",2:"SD_V2"},
"K2": {1:"SD_V1",2:"SD_V2"},
"K3": {1:"SD_V1",2:"SD_V2"}}
for compare in list(itertools.combinations(dictmain,2)):
print "Comparing dictionaries:", compare
if dictmain[compare[0]]==dictmain[compare[1]]:
print "comb dict are equal"
else:
print "comb dict are NOT equal"
break
Many thanks in advance,
Jignesh
___
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Test Question
Many thanks, everyone. Great answers. I decided to read the manual
properly. May take some time but well worth it.
On Mon, Jul 1, 2013 at 2:40 PM, Steven D'Aprano wrote:
> On 01/07/13 19:58, John Steedman wrote:
>
>> Good morning all,
>>
>> A question that I am unsure about. I THINK I have the basics, but I am
>> not
>> sure and remain curious.
>>
>> 1. What does this mean?
>>
>>> if my_object in my_sequence:
>
...
>>
>
>
> Others have already answered this, but for completion, it is testing
> whether "my_object" can be found as an element of the sequence, iterable,
> or container "my_sequence".
>
>
>
> 2. What can go wrong with this? What should a code review pick up on?
>>
>
> Depends on context. Without context, nearly anything could go wrong:
>
> NameError -- perhaps one or both of the names are undefined;
>
> TypeError -- perhaps the names are misleading, and my_sequence is not a
> sequence at all;
>
> Perhaps my_sequence is an infinite iterator and the above will never
> complete;
>
> etc.
>
>
> I believe that "my_sequence" might be a either container class or a
>> sequence type. An effective __hash__ function would be required for each
>> "my_object".
>>
>
> Correct, if my_sequence is in fact a dict or other mapping that relies on
> hashing.
>
> But in fact it's not just the presence of a __hash__ method on my_object
> which is required, but that the __hash__ method can actually return. E.g.
> tuples have a __hash__ method, but that relies on every element of the
> tuple being hashable:
>
> py> (1, 2, 3) in {}
> False
> py> (1, 2, [3]) in {}
> Traceback (most recent call last):
> File "", line 1, in
> TypeError: unhashable type: 'list'
>
>
>
> I HTINK you'd need to avoid using floating point variables
>> that might round incorrectly.
>>
>
> No, Python floats are not rounded when doing containment testing. They may
> have been rounded earlier, but `x in container` will use the full precision
> of the float.
>
>
> Are there other issues?
>>
>
> Nothing obvious to me.
>
>
>
>
>
> --
> Steven
> __**_
> Tutor maillist - Tutor@python.org
> To unsubscribe or change subscription options:
> http://mail.python.org/**mailman/listinfo/tutor
>
___
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Test Question
On 01/07/13 19:58, John Steedman wrote:
Good morning all,
A question that I am unsure about. I THINK I have the basics, but I am not
sure and remain curious.
1. What does this mean?
if my_object in my_sequence:
...
Others have already answered this, but for completion, it is testing whether "my_object"
can be found as an element of the sequence, iterable, or container "my_sequence".
2. What can go wrong with this? What should a code review pick up on?
Depends on context. Without context, nearly anything could go wrong:
NameError -- perhaps one or both of the names are undefined;
TypeError -- perhaps the names are misleading, and my_sequence is not a
sequence at all;
Perhaps my_sequence is an infinite iterator and the above will never complete;
etc.
I believe that "my_sequence" might be a either container class or a
sequence type. An effective __hash__ function would be required for each
"my_object".
Correct, if my_sequence is in fact a dict or other mapping that relies on
hashing.
But in fact it's not just the presence of a __hash__ method on my_object which
is required, but that the __hash__ method can actually return. E.g. tuples have
a __hash__ method, but that relies on every element of the tuple being hashable:
py> (1, 2, 3) in {}
False
py> (1, 2, [3]) in {}
Traceback (most recent call last):
File "", line 1, in
TypeError: unhashable type: 'list'
I HTINK you'd need to avoid using floating point variables
that might round incorrectly.
No, Python floats are not rounded when doing containment testing. They may have
been rounded earlier, but `x in container` will use the full precision of the
float.
Are there other issues?
Nothing obvious to me.
--
Steven
___
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Test Question
On 01/07/13 22:15, Oscar Benjamin wrote:
On 1 July 2013 12:01, Dave Angel wrote:
Third if my_object is something that doesn't equal anything else, such as a
floating point NAN. Two NANs are not equal, and a NAN is not even equal to
itself.
Many builtin collection types do an identity 'is' check before an
equality '==' check so nan behaviour depends on whether it is the
exact same nan:
float('nan') in [1, 2, 3, float('nan')]
False
nan = float('nan')
nan in [1, 2, 3, nan]
True
I don't know to what extent that is a deliberate feature or an
optimisation that wasn't fully considered but it at least maintains
the following invariant:
It's an optimization, but one which by declaration of the BDFL stands. It
simply isn't worth slowing down list processing for something as uncommon as
NANs. Lists are general purpose containers, and shouldn't be expected to
understand every little quirk of every weird value.
I am a strong supporter of the IEEE 754 behaviour of NANs, namely that if x is
a NAN, x == x returns False. There are good reasons for this, *in the context
of numerical computing*. Nevertheless, I support Guido's ruling on this. Lists
are not part of IEEE 754, neither is object identity, and if somebody wants a
list that is NAN-aware, they can make one:
# Untested.
class MyList(list):
def __contains__(self, value):
if math.isnan(value): return False
return super().__contains__(value)
--
Steven
___
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Test Question
On Mon, Jul 1, 2013 at 1:01 PM, Dave Angel wrote: > On 07/01/2013 05:58 AM, John Steedman wrote: > >> >> I believe that "my_sequence" might be a either container class or a >> sequence type. An effective __hash__ function would be required for each >> "my_object". >> > > "in" doesn't care if there's a __hash__ function. It just cares if the > collection has a __contains__() method. If the collection is a dict, the > dict will enforce whatever constraints it needs. If the collection is a > list, no has is needed, but the __contains__() method will probably be > slower. In an arbitrary sequence it won't have a __contains__() method, > and I believe 'in' will iterate. > > It will indeed iterate. It's always useful to check the language reference in cases like these to see precise behaviour: http://docs.python.org/2/reference/expressions.html#membership-test-details Hugo ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Test Question
On 07/01/2013 05:58 AM, John Steedman wrote: Good morning all, A question that I am unsure about. I THINK I have the basics, but I am not sure and remain curious. 1. What does this mean? if my_object in my_sequence: ... We can be sure what 'if' and 'in' mean, but not the other two items. They're just names, and the behavior of the test will depend on the types of the objects the names are bound to. By calling it my_sequence, you're implying that the object is not only a collection, but an ordered one. So if we trust the names, this will iterate through the sequence, testing each item in the sequence against my_object for "==" and stop when a match is found. If one is found the if clause will execute, and if the sequence is exhausted without finding one, the else clause (or equivalent) will execute. 2. What can go wrong with this? What should a code review pick up on? The main thing that can go wrong is that the objects might not match the names used. For example, if the name my_sequence is bound to an int, you'll get a runtime exception. Second, if the items look similar (eg. floating point, but not limited to that), but aren't actually equal, you could get a surprise. For example if my_object is a byte string, and one of the items in my_sequence is a unicode string representing exactly the same thing. Python 2 will frequently consider them the same, and Python 3 will know they're different. Third if my_object is something that doesn't equal anything else, such as a floating point NAN. Two NANs are not equal, and a NAN is not even equal to itself. By a different definition of 'wrong' if the sequence is quite large, and if all its items are hashable and it may have been faster to pass a dict instead of a sequence. And if my_sequence is a dict, it'll probably be faster, but the name is a misleading one. I believe that "my_sequence" might be a either container class or a sequence type. An effective __hash__ function would be required for each "my_object". "in" doesn't care if there's a __hash__ function. It just cares if the collection has a __contains__() method. If the collection is a dict, the dict will enforce whatever constraints it needs. If the collection is a list, no has is needed, but the __contains__() method will probably be slower. In an arbitrary sequence it won't have a __contains__() method, and I believe 'in' will iterate. I HTINK you'd need to avoid using floating point variables that might round incorrectly. One of the issues already covered. Are there other issues? Those are all I can think of off the top of my head. -- DaveA ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
[Tutor] Test Question
Good morning all, A question that I am unsure about. I THINK I have the basics, but I am not sure and remain curious. 1. What does this mean? >>> if my_object in my_sequence: ... 2. What can go wrong with this? What should a code review pick up on? I believe that "my_sequence" might be a either container class or a sequence type. An effective __hash__ function would be required for each "my_object". I HTINK you'd need to avoid using floating point variables that might round incorrectly. Are there other issues? Many thanks indeed. John ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
[Tutor] Test - please ignore
___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] test- why no traffic?
i see you. did you change your settings so you don't get e-mails? On Tue, Jan 11, 2011 at 12:17 PM, wrote: > hmmm, wonder if my membership went belly up... no traffic arriving... > hmmm... > > ___ > Tutor maillist - tu...@python.org > To unsubscribe or change subscription options: > http://mail.python.org/mailman/listinfo/tutor > ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
[Tutor] test- why no traffic?
hmmm, wonder if my membership went belly up... no traffic arriving... hmmm... ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] test
Chrystal wrote:
Hi guys
I'll be happy if someone can help evaluate the result of this statement:
for n in range (3, 20):
for x in range (2, n):
print (n)
I tried but couldn't figure out why the loop returned such a result
It would help if you told us what result you get, what result you
expected, and what you don't understand about it.
My guess is that you expected it to print:
2
2
3
2
3
4
2
3
4
5
...
but instead it prints:
2
3
3
4
4
4
5
5
5
5
...
Hint: you are print n each time, not x. n doesn't vary inside the inner
loop, only in the outer loop.
To understand what is going on better, it might help if you run this
instead:
for n in range(3, 20):
for x in range(2, n):
print('n = %d, x = %d' % (n, x))
--
Steven
___
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] test
Il 27/12/2010 14.44, Chrystal ha scritto: > Hi guys > > I'll be happy if someone can help evaluate the result of this statement: > > for n in range (3, 20): > for x in range (2, n): > print (n) > > > I tried but couldn't figure out why the loop returned such a result > > Merry Christmas > > Thanks > > What result is so strange for you? I get a perfectly understandable 3 4 4 5 5 5 6 6 6 6 7 7 7 7 7 ... And so on up to 19 repeated 17 times... cheers paolino ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] test
Hi guys I'll be happy if someone can help evaluate the result of this statement: for n in range (3, 20): > for x in range (2, n): > print (n) > I tried but couldn't figure out why the loop returned such a result Merry Christmas Thanks ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
[Tutor] Test Automation framework recommendation....
Thanks all here. I'm asked UML and UI tools for python in the other thread. I'm looking for any suggestions to build test automation system, from the test plan management, test execution, python scripting management. Testplan: Testlink is a good example and I used it for the small project, but it lacks of prompt support. Editing function is not that good for word, ppt or xls. Silk havn't tried yet. Test manager: managing the testing execution across the platform, check out test plan and TCs from Testplan manager, control the test process for distributed UUT, collect stats, upload results. Script managenet: suvversion control, Thanks -- Sent from my mobile device ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] test
On Sat, Nov 06, 2010 at 04:20:54PM +1100, Steven D'Aprano wrote: > Luke Paireepinart wrote: > >You don't get your own e-mails back. > > I do. > > Perhaps it's an option when you sign up? I think it is an irritating gmail-only "feature". I use a google apps domain and face the same issue. I see that the OP also uses gmail. http://mail.google.com/support/bin/answer.py?hl=en&answer=82454 """ Finally, if you're sending mail to a mailing list that you subscribe to, those messages will only appear in 'Sent Mail.' """ - Sandip ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] test
On 6 November 2010 16:20, Steven D'Aprano wrote: > Luke Paireepinart wrote: >> >> You don't get your own e-mails back. > > I do. > > Perhaps it's an option when you sign up? For any list (like this one) hosted by mailman, the default is set by list administrator, but every user can customise this at their list config via the URL mentioned in the footer. ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] test
Luke Paireepinart wrote: You don't get your own e-mails back. I do. Perhaps it's an option when you sign up? -- Steven ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] test
You don't get your own e-mails back. On Fri, Nov 5, 2010 at 11:37 PM, Danyelle Davis wrote: > im wondering if im able to mail this list. I sent an email asking for good > newbie projects but never saw it post. All i got was the welcome/ info > email. > LN > ___ > Tutor maillist - tu...@python.org > To unsubscribe or change subscription options: > http://mail.python.org/mailman/listinfo/tutor > > ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
[Tutor] test
im wondering if im able to mail this list. I sent an email asking for good newbie projects but never saw it post. All i got was the welcome/ info email. LN ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Test Drive Development, DocTest, UnitTest
> The lines between doc tests, blackbox testing, whitebox testing, and > regression testing is blurry. People may legitimately disagree on > whether a specific test is documentation, testing the interface, > testing the implementation, or all three. > Wow!!! Ok that clears up a lot. Thank you Just to clear some things up: Internal == doctest External == blackbox testng (using unit tests) Thanks again! Now off to go write some doctests and unit tests! :) -Tino ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Test Drive Development, DocTest, UnitTest
On Wed, 22 Sep 2010 09:44:17 pm Tino Dai wrote:
> > The *primary* purpose of doctests are to be executable examples.
> > When you write documentation, including example code is the most
> > natural thing in the world. doctest lets you execute those
> > examples, to ensure that they work. They're certainly not meant
> > as an exhaustive test of every single feature in the program, but
> > as *documentation* that happens to also work as tests.
> >
> > Unit tests can be a little heavyweight, but they're designed for
> > exhaustive tests of the *entire* program, not just the parts with
> > user-documentation. You should write whitebox tests, not just
> > blackbox tests. That means don't just write tests for the
> > published interface, but write tests for the unpublished internal
> > details as well.
>
> So, the gist is write tests for everything and the "external
> testing" should be
> handled by unit tests and the "internal testing" by doctests. Is
> that correct?
I'm not sure I understand what you mean by "external" and "internal",
but if I do understand, you should swap them around.
What I mean is this:
Functions and classes have (or at least should have) a published
interface, the API, which tell the user what they can expect the
function to do and what arguments they need to provide. This is the
external interface. It could be as simple as:
parrot.colour
Read-only attribute giving the colour of the parrot. The
default colour is "blue".
or it could be thirty pages of tightly-written documentation. Either
way, a small number of examples are useful, and having those examples
be executable is even better:
>>> p = Parrot()
>>> p.colour
'blue'
This should go in the function's __doc__ string, where it is easily
discoverable by users using the interactive help() function, as well
as documentation discovery tools.
But there's no need to give an example of *every* tiny facet of
behaviour, even if your documentation specifically mentions it.
There's very little gained from having *both* these additional tests,
as far as documentation is concerned:
>>> Parrot('light green').colour
'light green'
>>> Parrot(' LIGHT GREEN ').colour
'light green'
If you find yourself saying "Yes, yes, I get the point!" while reading
documentation, then you've got too many examples and some tests need
to be removed.
But you do need to have those tests *somewhere*, otherwise, how do you
know they work as expected? You need to verify the promises you have
made, that is, test the external interface. This is "blackbox
testing": you can't see inside the function, only the outside
behaviour:
>>> Parrot().colour
'blue'
>>> Parrot(None).colour
'blue'
>>> Parrot('').colour
'blue'
>>> Parrot('BLUE').colour
'blue'
>>> Parrot(' \\v\\r red \\n\\t ').colour
'red'
>>> Parrot('rEd').colour
'red'
>>> Parrot('yellow').colour
'yellow'
>>> p = Parrot()
>>> p.resting = False
>>> p.colour
'blue'
>>> p.resting = True
>>> p.colour
'blue'
>>> Parrot(state='transparent').colour
Traceback (most recent call last):
...
ParrotError: invisible parrots don't have colour
>>> Parrot(species='Norwegian Blue').colour # are we bored yet?
'blue'
>>> Parrot(species='Giant Man-eating Kakapo').colour
'green'
Nobody needs to see *all* of that in a docstring, but it does need to
be tested somewhere. You can use doctest for that, in an external
file rather than the __doc__ string, but often unit tests give you
more power and flexibility.
Blackbox testing is good, but it's not complete. You should also use
whitebox testing, where you are expected to consider all the paths
the code might take, and ensure that each and every one of those are
tested. (At least that's the ideal, in practice sometimes you can't
test *every* corner of the code. But you should try.) This is testing
the internal implementation, and it certainly doesn't belong in the
external documentation!
Real world example: Python's list.sort() method and sorted() functions
use a custom-made, high-performance sort algorithm written by Tim
Peters, but it only kicks in for sufficiently large lists. For small
lists, they use a simpler sort algorithm. Whitebox testing needs to
have tests for both cases, but you don't want to make the cutoff
between the two part of your published external interface:
>>> # test a small list that uses algorithm 1
... sorted([1, 5, 3, 5, 9])
[1, 3, 5, 5, 9]
>>> # and test a big list that uses algorithm 2
... sorted([1, 5, 3, 5, 9, 8])
[1, 3, 5, 5, 8, 9]
What if the cutoff changes? You will have to revise your manuals! Why
do you think the users of sort() need to know exactly where the
cutoff is? Nobody cares what the exact value is. (It's not 5 items,
by the way.)
For whitebox testing, doctests are often too limiting, and they're
certainly too noisy to
Re: [Tutor] Test Drive Development, DocTest, UnitTest
On Wed, Sep 22, 2010 at 3:53 AM, Walter Prins wrote: > You might also have a look at some of the other popular testing frameworks > e.g. Nose (http://somethingaboutorange.com/mrl/projects/nose/0.11.2/) and > py.test (http://wiki.python.org/moin/PyTest) Both of these have the > advantage that they're discovery based, so they'll go and sniff out tests > from your source, whererver they may be. > > Walter > > I will have to check this out. Django and doctest's seem kind of limited. :( -Thanks, Tino ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Test Drive Development, DocTest, UnitTest
> > The *primary* purpose of doctests are to be executable examples. When > you write documentation, including example code is the most natural > thing in the world. doctest lets you execute those examples, to ensure > that they work. They're certainly not meant as an exhaustive test of > every single feature in the program, but as *documentation* that > happens to also work as tests. > > Unit tests can be a little heavyweight, but they're designed for > exhaustive tests of the *entire* program, not just the parts with > user-documentation. You should write whitebox tests, not just blackbox > tests. That means don't just write tests for the published interface, > but write tests for the unpublished internal details as well. > So, the gist is write tests for everything and the "external testing" should be handled by unit tests and the "internal testing" by doctests. Is that correct? > > E.g. if your function has special processing to deal with lists of > strings, then you need a test for input that is a list of strings. But > it's not necessary to document that fact in the doc string. What do the > users care that your function calls a special subroutine to deal with > lists of strings? So it would be inappropriate to draw attention to > this fact with a doctest. > > Doctests don't just execute themselves. If your developers, junior or > otherwise, don't know about the tests, don't keep the tests up to date, > and don't run the tests, then it doesn't matter what testing framework > you use. > Point taken... > > Doctests and unittests are complementary. They work well together. In > fact, the unittest module can even execute doctests. > > This I didn't know this. I will have to do more investigation about this today. I did find that the Django doctest's were kind of limiting (at the documentation that I read). This opens up more possibilities to unify my tests. Thanks Steven for the pointers ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Test Drive Development, DocTest, UnitTest
You might also have a look at some of the other popular testing frameworks e.g. Nose (http://somethingaboutorange.com/mrl/projects/nose/0.11.2/) and py.test (http://wiki.python.org/moin/PyTest) Both of these have the advantage that they're discovery based, so they'll go and sniff out tests from your source, whererver they may be. Walter ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Test Drive Development, DocTest, UnitTest
On Wed, 22 Sep 2010 01:37:42 am Tino Dai wrote: > I am > torn between the DocTest and UnitTest. I like the one "fileness" of > the DocTest, but am concerned > about the length of my tests being several orders of magnitude bigger > than the actual code. I > like the UnitTest having a separate file but am worried about the > tests getting lost or never getting > executed because a junior developer doesn't know about them. I'm > wondering in respect to TDD, which > is better or is it a matter of taste? Neither is better. They're just different, with different purposes. The *primary* purpose of doctests are to be executable examples. When you write documentation, including example code is the most natural thing in the world. doctest lets you execute those examples, to ensure that they work. They're certainly not meant as an exhaustive test of every single feature in the program, but as *documentation* that happens to also work as tests. Unit tests can be a little heavyweight, but they're designed for exhaustive tests of the *entire* program, not just the parts with user-documentation. You should write whitebox tests, not just blackbox tests. That means don't just write tests for the published interface, but write tests for the unpublished internal details as well. E.g. if your function has special processing to deal with lists of strings, then you need a test for input that is a list of strings. But it's not necessary to document that fact in the doc string. What do the users care that your function calls a special subroutine to deal with lists of strings? So it would be inappropriate to draw attention to this fact with a doctest. Doctests don't just execute themselves. If your developers, junior or otherwise, don't know about the tests, don't keep the tests up to date, and don't run the tests, then it doesn't matter what testing framework you use. Doctests and unittests are complementary. They work well together. In fact, the unittest module can even execute doctests. -- Steven D'Aprano ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
[Tutor] Test Drive Development, DocTest, UnitTest
Hi All, In my journey from a hacker to a professional software developer, I have started to learn the finer points of Test Drive Development via Django (no questions about Django though). I am torn between the DocTest and UnitTest. I like the one "fileness" of the DocTest, but am concerned about the length of my tests being several orders of magnitude bigger than the actual code. I like the UnitTest having a separate file but am worried about the tests getting lost or never getting executed because a junior developer doesn't know about them. I'm wondering in respect to TDD, which is better or is it a matter of taste? TIA, Tino ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] test again
ook, thi new thunderbird 3.foo is... different, takes some getting used to. Sorry about the noise on the channel. On 2/25/2010 5:31 PM, Kirk Bailey wrote: test- where is the list, nothing is coming to me! -- Cheers! -Kirk D Bailey THINK +-+ .*.| BOX | ..*+-+ *** THINK ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
[Tutor] test again
test- where is the list, nothing is coming to me! -- Cheers! -Kirk D Bailey THINK +-+ .*.| BOX | ..*+-+ *** THINK ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] test
On Thu, Feb 25, 2010 at 4:03 PM, Kirk Bailey wrote: > test > -- > > > Cheers! > -Kirk D Bailey > > THINK > +-+ > .*.| BOX | > ..*+-+ > *** THINK > ___ > Tutor maillist - Tutor@python.org > To unsubscribe or change subscription options: > http://mail.python.org/mailman/listinfo/tutor > Hello World! << usually a good test ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
[Tutor] test
test -- Cheers! -Kirk D Bailey THINK +-+ .*.| BOX | ..*+-+ *** THINK ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] test
Nope. Kirk Bailey wrote: is my posting getting through? ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] test
yup On Mon, Aug 25, 2008 at 11:47 AM, Kirk Bailey <[EMAIL PROTECTED]>wrote: > is my posting getting through? > -- > > > Cheers! > -Kirk D Bailey > > THINK > +-+ > .*.| BOX | > ..*+-+ > *** THINK > ___ > Tutor maillist - Tutor@python.org > http://mail.python.org/mailman/listinfo/tutor > -- To be considered stupid and to be told so is more painful than being called gluttonous, mendacious, violent, lascivious, lazy, cowardly: every weakness, every vice, has found its defenders, its rhetoric, its ennoblement and exaltation, but stupidity hasn't. - Primo Levi ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
[Tutor] test
is my posting getting through? -- Cheers! -Kirk D Bailey THINK +-+ .*.| BOX | ..*+-+ *** THINK ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
[Tutor] Test - please ignore
Just testing as recently I'm not seeing my posts even though Receive your own posts to the list? is Yes. -- Bob Gailer 919-636-4239 Chapel Hill, NC ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
[Tutor] Test
It's just a test message -- http://ekd.tolosano.info ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
[Tutor] Test
Hey, my messages don't seem to be showing up on the list... So if this one works, sorry for the test message, everybody! My school just decided not to allow any outgoing email to any SMTP server but their own *grumble* So I've been sending my tutor messages through that server but with this address munged into the headers. Seems to send messages through fine, but I guess the list doesn't like it for some reason. If this message works, it'll be proof of that (since this is from the gmail web interface) and I'll re-subscribe to the list from my other address ([EMAIL PROTECTED]) so my messages will come from there from now on. Sorry again for the test, Jordan Greenberg ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
[Tutor] Test
I got a bounce... but have been on this list for months... S. ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Test If File System is mounted in Linux
Dnia piątek, 17 marca 2006 19:22, Bill Campbell napisał: > If you're sure it's a Linux system, fine. Like /etc/mtab, this isn't > portable. Looking at some of the systems we have here: Fortezza mentioned it the way I assumed he has Linux: >> If there a semi-standard way to test if a file system has been mounted >> or not using Python? In the Linux command line, I can type "mount" and >> see all mounted file system, and then see if the one I am looking for is But, generally - you are right. Each system has its own rules for accessing mount table. Anyway - this would be a great exercise to make a portable pure-python library to get this information. -- Pawel www.kraszewscy.net ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Test If File System is mounted in Linux
On Fri, Mar 17, 2006, Pawel Kraszewski wrote: >Dnia piÄ tek, 17 marca 2006 18:41, Adam napisaÅ: > >> > The more general problem is to get a list of mounted file systems. > >> How about just reading the mtab? That's usually /etc/mtab it should be >> readable as a user and it means you don't have to rely on any other >> programs. > >Or always-up-to-date & user readable '/proc/mounts' ? If you're sure it's a Linux system, fine. Like /etc/mtab, this isn't portable. Looking at some of the systems we have here: Linux -- systems from Caldera OpenLinux 2.3 through SuSE 10.0, have /proc/mounts and /etc/mtab. FreeBSD 4.8 Stable -- has /proc file system, but no /proc/mounts, and no /etc/mtab (yeah 4.8 is out of date, but it's been up 632 days and I want to see how long it will stay up :-). OS X 10.4.5 (Tiger) -- no /proc/mounts or /etc/fstab SCO OpenServer 5.0.6a -- no /proc/mounts or /etc/fstab All of these systems have the gnu gdf which returns information in the same format. Bill -- INTERNET: [EMAIL PROTECTED] Bill Campbell; Celestial Systems, Inc. URL: http://www.celestial.com/ PO Box 820; 6641 E. Mercer Way FAX:(206) 232-9186 Mercer Island, WA 98040-0820; (206) 236-1676 ``Fix reason firmly in her seat and call to her tribunal every fact, every opinion. Question with boldness even the existence of a God; because, if there is one, he must more approve of the homage of reason, than that of blindfolded fear.'' --Thomas Jefferson ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Test If File System is mounted in Linux
On Fri, Mar 17, 2006, Adam wrote: >On 17/03/06, Bill Campbell <[EMAIL PROTECTED]> wrote: >> On Fri, Mar 17, 2006, Michael Lange wrote: >> >On Fri, 17 Mar 2006 00:36:35 -0700 >> >fortezza-pyt <[EMAIL PROTECTED]> wrote: >> > >> >> If there a semi-standard way to test if a file system has been mounted >> >> or not using Python? In the Linux command line, I can type "mount" and >> >> see all mounted file system, and then see if the one I am looking for is >> >> in the list. While I could replicate this with >> >> Python, I am curious if there is an easier way. >> >> >> > >> >Hi Fortezza, >> > >> >try os.path.ismount() . >> >> That's fine if one knows what the mount points are. >> >> The more general problem is to get a list of mounted file systems. >> >How about just reading the mtab? That's usually /etc/mtab it should be >readable as a user and it means you don't have to rely on any other >programs. The words usually, and should are the kickers. In the 24 years I've been making my living on various versions of Unix type systems, I've seen a lot of cases where this type of assumption either fails totally or gets me in trouble because the vendor didn't do it the way they should. This is the reason I started building standard open source tools for all the systems we support (Richard Stallman would probably have said I was creating GNU/Xenix and GNU/OpenServer systems back when we supported many SCO systems :-). My fingers automatically type gfind, gdu, etc., even on Linux systems where I make symbolic links as necessary so I don't have to remember what type of system I'm typing on. One of the basic tenets of the *nix philosophy is ``build on the work of others'', and it's a lot easier to leave figuring out the guts of various systems to the authors of the gnu fileutils than it is to reinvent their work every time I want to do something. Bill -- INTERNET: [EMAIL PROTECTED] Bill Campbell; Celestial Software LLC URL: http://www.celestial.com/ PO Box 820; 6641 E. Mercer Way FAX:(206) 232-9186 Mercer Island, WA 98040-0820; (206) 236-1676 A fake fortuneteller can be tolerated. But an authentic soothsayer should be shot on sight. Cassandra did not get half the kicking around she deserved. -- R.A. Heinlein ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Test If File System is mounted in Linux
Dnia piątek, 17 marca 2006 18:41, Adam napisał: > > The more general problem is to get a list of mounted file systems. > How about just reading the mtab? That's usually /etc/mtab it should be > readable as a user and it means you don't have to rely on any other > programs. Or always-up-to-date & user readable '/proc/mounts' ? -- Pawel Kraszewski ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Test If File System is mounted in Linux
On 17/03/06, Bill Campbell <[EMAIL PROTECTED]> wrote: > On Fri, Mar 17, 2006, Michael Lange wrote: > >On Fri, 17 Mar 2006 00:36:35 -0700 > >fortezza-pyt <[EMAIL PROTECTED]> wrote: > > > >> If there a semi-standard way to test if a file system has been mounted > >> or not using Python? In the Linux command line, I can type "mount" and > >> see all mounted file system, and then see if the one I am looking for is > >> in the list. While I could replicate this with > >> Python, I am curious if there is an easier way. > >> > > > >Hi Fortezza, > > > >try os.path.ismount() . > > That's fine if one knows what the mount points are. > > The more general problem is to get a list of mounted file systems. > How about just reading the mtab? That's usually /etc/mtab it should be readable as a user and it means you don't have to rely on any other programs. ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Test If File System is mounted in Linux
On Fri, Mar 17, 2006, Michael Lange wrote:
>On Fri, 17 Mar 2006 00:36:35 -0700
>fortezza-pyt <[EMAIL PROTECTED]> wrote:
>
>> If there a semi-standard way to test if a file system has been mounted
>> or not using Python? In the Linux command line, I can type "mount" and
>> see all mounted file system, and then see if the one I am looking for is
>> in the list. While I could replicate this with
>> Python, I am curious if there is an easier way.
>>
>
>Hi Fortezza,
>
>try os.path.ismount() .
That's fine if one knows what the mount points are.
The more general problem is to get a list of mounted file systems.
The most standard way I've found to get a list of mounted systems is to
parse the output of the gdf program from the gnu fileutils compiled with
the program prefix `g' so it's called gdf. The gdf program handles a lot
of the dirty work, and its output is standard regardless of the underlying
system, which you can't say about the system's mount or df commands.
The routine below is one I've used for years (actually I used a perl
version for a long time before switching primarily to python :-).
# This aren't real file systems.
pseudofilesys = \
dict(map((lambda x: (x, 1)), ('none', 'shmfs', 'procfs', 'tmpfs')))
gdf_cols = ('filesys', 'blocks', 'used', 'avail', 'use', 'dir')
def mounted():
'''Get Mounted File Systems'''
df = os.popen('gdf 2>/dev/null', 'r')
df.readline() # skip first line
mounted = []
for line in df.readlines():
line = line.strip()
rec = dict(zip(gdf_cols, line.split(None, 5)))
filesys = rec['filesys']
dir = rec.get('dir')
if (
dir and not (filesys.find(':') >= 0
or pseudofilesys.get(filesys))
): mounted.append(dir)
df.close()
return mounted
Bill
--
INTERNET: [EMAIL PROTECTED] Bill Campbell; Celestial Systems, Inc.
URL: http://www.celestial.com/ PO Box 820; 6641 E. Mercer Way
FAX:(206) 232-9186 Mercer Island, WA 98040-0820; (206) 236-1676
``I presume you all know who I am. I am humble Abraham Lincoln. I have been
solicited by many friends to become a candidate for the legistlature. My
politics are short and sweet, like the old woman's dance. I am in favor of
a national bank ... in favor of the internal improvements system, and a
high protective tariff.'' -- Abraham Lincoln, 1832
___
Tutor maillist - Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Test If File System is mounted in Linux
On Fri, 17 Mar 2006 00:36:35 -0700 fortezza-pyt <[EMAIL PROTECTED]> wrote: > If there a semi-standard way to test if a file system has been mounted > or not using Python? In the Linux command line, I can type "mount" and > see all mounted file system, and then see if the one I am looking for is > in the list. While I could replicate this with > Python, I am curious if there is an easier way. > Hi Fortezza, try os.path.ismount() . HTH Michael ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Test If File System is mounted in Linux
On Fri, March 17, 2006 1:06 pm, fortezza-pyt wrote: > If there a semi-standard way to test if a file system has been mounted > or not using Python? In the Linux command line, I can type "mount" and > see all mounted file system, and then see if the one I am looking for is > in the list. While I could replicate this with > Python, I am curious if there is an easier way. A quick Google search gives this http://bebop.bigasterisk.com/python/docs/MtPython Non standard perhaps but someone seems to have implemented a module that does something like this. -- -NI ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
[Tutor] Test If File System is mounted in Linux
If there a semi-standard way to test if a file system has been mounted or not using Python? In the Linux command line, I can type "mount" and see all mounted file system, and then see if the one I am looking for is in the list. While I could replicate this with Python, I am curious if there is an easier way. Thank You, Fortezza ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Test code organization
Willi Richert wrote:
> Hi,
>
> for some time I try to find the best test code organization. I've come
> up with the following solution, which I guess is not optimal. Please
> comment.
OK I'll take a stab at it.
>
> In the code directory there is a special tests directory, which contains
> all the unit test files.
This is a common organization but I find I prefer to put the tests in
the same directory as the modules under test. It makes the directory a
bit more crowded but it keeps the modules and their tests close together.
> There is the file alltests.py which collects
> all python test files and executes them:
>
> =
> import sys, unittest
> sys.path.append(".")
> sys.path.append("..")
>
> TEST_DIR = "tests"
>
> import glob
> testCases = [t.split(".")[0] for t in glob.glob1(TEST_DIR, "*Tests.py")]
> print "Found test case modules "+", ".join(testCases)
> print
>
> for t in testCases:
> exec("from %s import %s"%(TEST_DIR, t))
You could probably replace this with __import__ (or my_import() from the
doc page for __import__()) but maybe it's not worth the trouble.
>
> def suite():
> exec("suites = tuple([x.suite() for x in [%s]])"%str(",
> ".join(testCases)))
I don't think you need exec here, you could use
suites = [sys.modules.get(x).suite() for x in testCases]
> suite = unittest.TestSuite(suites)
> return suite
>
>
> if __name__ == '__main__':
> suite = suite()
> result = unittest.TextTestRunner(verbosity=2).run(suite)
> if result.wasSuccessful():
> sys.exit(0)
> else:
> sys.exit(1)
> ==
>
>
> For every class to test I create a ClassTests.py file which contains the
> following code:
> Header:
> ==
> import sys
> sys.path.append("..")
>
> import unittest
> from Class... import *
> ==
>
> The footer parses the available test classes:
> ==
> def _testclasses():
> mod = sys.modules[__name__]
> return [getattr(mod, name) for name in dir(mod) if
> name.endswith('TestCase')]
>
> def suite():
> return unittest.TestSuite([unittest.makeSuite(tc) for tc in
> _testclasses()])
I think all the above footer could be replaced with
def suite():
return
unittest.defaultTestLoader.loadTestsFromModule(sys.modules.get(__name__))
>
> if __name__ == '__main__':
> unittest.main()
> ==
>
>
> What smalls badly is the sys.path.append() stuff every test file must
> have. Improvements?
I usually run everything from the base directory of the project. On
Windows, the current dir is added to sys.path automatically. (On linux
apparently this is not true.) Then the test classes can use normal
imports and there is no need to alter sys.path in each test class.
You might want to look at some of the other auto-discovery methods such
as those included in nose and py.test, either for your own use or to see
how they work.
http://somethingaboutorange.com/mrl/projects/nose/
http://codespeak.net/py/current/doc/test.html
Kent
___
Tutor maillist - Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor
[Tutor] Test code organization
Hi,
for some time I try to find the best test code organization. I've come
up with the following solution, which I guess is not optimal. Please
comment.
In the code directory there is a special tests directory, which contains
all the unit test files. There is the file alltests.py which collects
all python test files and executes them:
=
import sys, unittest
sys.path.append(".")
sys.path.append("..")
TEST_DIR = "tests"
import glob
testCases = [t.split(".")[0] for t in glob.glob1(TEST_DIR, "*Tests.py")]
print "Found test case modules "+", ".join(testCases)
print
for t in testCases:
exec("from %s import %s"%(TEST_DIR, t))
def suite():
exec("suites = tuple([x.suite() for x in [%s]])"%str(",
".join(testCases)))
suite = unittest.TestSuite(suites)
return suite
if __name__ == '__main__':
suite = suite()
result = unittest.TextTestRunner(verbosity=2).run(suite)
if result.wasSuccessful():
sys.exit(0)
else:
sys.exit(1)
==
For every class to test I create a ClassTests.py file which contains the
following code:
Header:
==
import sys
sys.path.append("..")
import unittest
from Class... import *
==
The footer parses the available test classes:
==
def _testclasses():
mod = sys.modules[__name__]
return [getattr(mod, name) for name in dir(mod) if
name.endswith('TestCase')]
def suite():
return unittest.TestSuite([unittest.makeSuite(tc) for tc in
_testclasses()])
if __name__ == '__main__':
unittest.main()
==
What smalls badly is the sys.path.append() stuff every test file must
have. Improvements?
Thanks for any comment,
wr
___
Tutor maillist - Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor
[Tutor] Test code organization
Hi,
for some time I try to find the best test code organization. I've come up with
the following solution, which I guess is not optimal. Please comment.
In the code directory there is a special tests directory, which contains all
the unit test files. There is the file alltests.py which collects all python
test files and executes them:
=
import sys, unittest
sys.path.append(".")
sys.path.append("..")
TEST_DIR = "tests"
import glob
testCases = [t.split(".")[0] for t in glob.glob1(TEST_DIR, "*Tests.py")]
print "Found test case modules "+", ".join(testCases)
print
for t in testCases:
exec("from %s import %s"%(TEST_DIR, t))
def suite():
exec("suites = tuple([x.suite() for x in [%s]])"%str(",
".join(testCases)))
suite = unittest.TestSuite(suites)
return suite
if __name__ == '__main__':
suite = suite()
result = unittest.TextTestRunner(verbosity=2).run(suite)
if result.wasSuccessful():
sys.exit(0)
else:
sys.exit(1)
==
For every class to test I create a ClassTests.py file which contains the
following code:
Header:
==
import sys
sys.path.append("..")
import unittest
from Class... import *
==
The footer parses the available test classes:
==
def _testclasses():
mod = sys.modules[__name__]
return [getattr(mod, name) for name in dir(mod) if
name.endswith('TestCase')]
def suite():
return unittest.TestSuite([unittest.makeSuite(tc) for tc in
_testclasses()])
if __name__ == '__main__':
unittest.main()
==
What smalls badly is the sys.path.append() stuff every test file must have.
Improvements?
Thanks for any comment,
wr
--
Gruss,
wr
--
Dipl.-Inform. Willi Richert
C-LAB - Cooperative Computing & Communication Laboratory
der Universität Paderborn und Siemens
FU.323
Fürstenallee 11
D-33102 Paderborn
Tel: +49 5251 60 6120
Fax: +49 5251 60 6165
http://www.c-lab.de
___
Tutor maillist - Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] TEST to see if this gets out
On Fri, 2 Sep 2005, Jack Anema wrote: > TEST Hi Jack, We're here. Do you have a question about learning Python? ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
[Tutor] Test to see if this gets out
TEST Jack Anema ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
[Tutor] TEST to see if this gets out
TEST Jack Anema ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] test
Asif Iqbal wrote:
>On Fri, Jun 17, 2005 at 07:41:17AM, Chad Crabtree wrote:
>
>
>>How about this.
>> >>> from random import choice
>> >>> alist=[choice(range(100)) for x in range(1000)] #just making a
>>
>>
>
>How do I do this in python?
> alist < /tmp/logfile
>
>The logfile has the list of entries.
>
>
>
ok sorry
filehandle=open('/tmp/logfile','r').readlines()
Look here
http://docs.python.org/lib/built-in-funcs.html#built-in-funcs
and
http://docs.python.org/lib/bltin-file-objects.html
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
___
Tutor maillist - Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] test
On Fri, Jun 17, 2005 at 07:41:17AM, Chad Crabtree wrote: > How about this. > >>> from random import choice > >>> alist=[choice(range(100)) for x in range(1000)] #just making a How do I do this in python? alist < /tmp/logfile The logfile has the list of entries. -- Asif Iqbal PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu "..there are two kinds of people: those who work and those who take the credit...try to be in the first group;...less competition there." - Indira Gandhi ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] test
How about this.
>>> from random import choice
>>> alist=[choice(range(100)) for x in range(1000)] #just making a
list
to look at pretend this is a file
>>>
>>> counter={}
>>> for item in alist:
... if item in counter.keys():
... counter[item]+=1
... else:
... counter[item]=1
...
>>> counter
{0: 9, 1: 9, 2: 9, 3: 14, 4: 15, 5: 15, 6: 13, 7: 5, 8: 11, 9: 12,
10:
9, 11: 12, 12: 13, 13: 8, 14: 5, 15: 12, 16: 14, 17: 9, 18: 11, 19:
8,
20: 6, 21: 13, 22: 11, 23: 10, 24: 8, 25: 15, 26: 19, 27: 11, 28: 13,
29: 13, 30: 12, 31: 18, 32: 10, 33: 5, 34: 9, 35: 5, 36: 9, 37: 12,
38:
8, 39: 11, 40: 8, 41: 12, 42: 6, 43: 13, 44: 11, 45: 8, 46: 8, 47: 6,
48: 9, 49: 6, 50: 5, 51: 11, 52: 11, 53: 12, 54: 15, 55: 15, 56: 10,
57:
12, 58: 13, 59: 6, 60: 6, 61: 7, 62: 8, 63: 13, 64: 14, 65: 7, 66: 7,
67: 12, 68: 5, 69: 10, 70: 8, 71: 7, 72: 12, 73: 12, 74: 6, 75: 13,
76:
12, 77: 13, 78: 9, 79: 5, 80: 13, 81: 14, 82: 4, 83: 6, 84: 8, 85:
12,
86: 8, 87: 10, 88: 10, 89: 7, 90: 7, 91: 9, 92: 12, 93: 14, 94: 8,
95:
7, 96: 10, 97: 11, 98: 8, 99: 8}
>>>
Asif Iqbal wrote:
>Hi All
>
>I have a very simple problem and I am looking for the simplest
solution.
>
>I have a list of elements in a file. I like to find the total
occurance
>of each element in the list like this
>
>10 string1
>7 string2
>1 string3
>
>from a list which has only string1,string2 and string3 like this
>
>string1
>..
>string2
>...
>string1
>..
>string3
>...
>...
>
>
>I have a list of 3 lines and I think I have only 615 unique
>elements. So I like the script not to take too much memory of the
>system. I will be running it on Solaris 8
>
>Thanks a lot
>
>
>
Yahoo! Sports
Rekindle the Rivalries. Sign up for Fantasy Football
http://football.fantasysports.yahoo.com
___
Tutor maillist - Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor
[Tutor] test
Hi All I have a very simple problem and I am looking for the simplest solution. I have a list of elements in a file. I like to find the total occurance of each element in the list like this 10 string1 7 string2 1 string3 from a list which has only string1,string2 and string3 like this string1 .. string2 ... string1 .. string3 ... ... I have a list of 3 lines and I think I have only 615 unique elements. So I like the script not to take too much memory of the system. I will be running it on Solaris 8 Thanks a lot -- Asif Iqbal PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu "..there are two kinds of people: those who work and those who take the credit...try to be in the first group;...less competition there." - Indira Gandhi ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
[Tutor] test
test! ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
[Tutor] Test
Test, please disregard. ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
[Tutor] test
test Jason Christopher Child Computer Network Services Professionals Tech Support 505-986-1669 1-877-321-9165 [EMAIL PROTECTED] VOZ Online VOIP Install Tech 505-428-7500 1-877-428-7550 ___ Tutor maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/tutor
[Tutor] test
Jason Christopher Child Computer Network Services Professionals Tech Support 505-986-1669 1-877-321-9165 [EMAIL PROTECTED] VOZ Online VOIP Install Tech 505-428-7500 1-877-428-7550 ___ Tutor maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/tutor
