Gregory P. Smith g...@krypto.org added the comment:
fyi - since I didn't chime in earlier on this: I think you made the right
choice with what was decided in msg122413 and implemented in the renaming done
in r86910 and the work done in issue10242.
--
Ezio Melotti ezio.melo...@gmail.com added the comment:
s/regexp/regex/ done in r86910.
--
resolution: - fixed
stage: - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10273
Michael Foord mich...@voidspace.org.uk added the comment:
Raymond - I created a new issue for moving the tests: issue 10572
However, it seems that you are incorrect in saying that Python practise is to
avoid putting tests inside standard library packages. In fact current Python
practise seems
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
Ezio, please do the regexp--regex changes and move the tests under Lib/test.
--
assignee: rhettinger - ezio.melotti
___
Python tracker rep...@bugs.python.org
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
After discussion with Michael and Guido, am limiting this to:
* Fixing assertItemsEqual as described in issue10242
* Moving the docs for type specific equality methods inside the docs for
assertEqual to emphasize that those
Ezio Melotti ezio.melo...@gmail.com added the comment:
* Moving the docs for type specific equality methods inside the docs for
assertEqual to emphasize that those get dispatched automatically and need not
be called directly.
I already fixed this on py3k, adding a section where the
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
Yes, all the variants of RegexpMatches -- Regex
No, on deprecations. Just add a new alias and note in the docs that the
oldname is obsolete. Naming deprecations cause too much trouble for too little
benefit.
--
Ezio Melotti ezio.melo...@gmail.com added the comment:
If I implement what I suggested in #10535, it will be possible to deprecate
them without too much trouble. I offer to do it after #10535.
--
___
Python tracker rep...@bugs.python.org
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
people who are used to the current spelling
will have to notice the change, note that one
name is now deprecated
I haven't proposed any deprecations.
Just add the new names as aliases.
Change the docs list the new names
Changes by Éric Araujo mer...@netwok.org:
--
nosy: +eric.araujo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10273
___
___
Python-bugs-list
Ezio Melotti ezio.melo...@gmail.com added the comment:
It should be noted that, if we re-use assertSameElements, the default behavior
should be preserved for compatibility with 3.1, and that is different (and
possibly less useful) than the one of assertItemsEqual. Ambiguities could be
solved
Changes by Ezio Melotti ezio.melo...@gmail.com:
--
nosy: +flox, gregory.p.smith
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10273
___
___
R. David Murray rdmur...@bitdance.com added the comment:
assertEquals existed forever, too, but we deprecated that :) (with no intent to
remove it, as I understand it).
There is no more ambiguity in assertLessThan than there is in assertLT, one
just has more letters. True, you have to look
Michael Foord mich...@voidspace.org.uk added the comment:
Renaming and aliasing methods has a cost. It confuses users of the old names
(including future users - the current API is now baked into django 1.3 unless I
can get an update done in time for them to change the version they're using).
Antoine Pitrou pit...@free.fr added the comment:
For assertItemsEqual Raymond suggests assertElementCountsEqual. See
issue 10242.
Why replace a long awkward name with an even longer and more awkward
name?
--
___
Python tracker
Ezio Melotti ezio.melo...@gmail.com added the comment:
An alternative would be adding check_order and check_duplicates to
assertSameElements and de-deprecate it.
Python 2.7 could be left unchanged because it's too late to
add/rename/deprecate methods (it has assertItemsEqual but not
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
For the regexp methods we should use assertRegexp
assertRegex is better. it matches the name used in other unittest
implementations, there is not confusion with camel casing RegExp vs Regexp, and
it matches the former
R. David Murray rdmur...@bitdance.com added the comment:
assertCountsEqual is IMO much clearer than assertItemsCountsEqual (or however
you spell it). I was unclear on what the latter did, but the former is fairly
clear. Ezio's suggestion is also clearer.
Raymond, since you said 'never' your
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
assertLess, on the other hand, I often get wrong,
since it is *not* __lt__ spelled out.
Right. Even Michael gets that one wrong.
Meditate on why Guido created the special method __lt__ instead of
__less_than__.
Ezio Melotti ezio.melo...@gmail.com added the comment:
FWIW in addition to assertRegexpMatches and assertNotRegexpMatches there are 2
more methods that use Regexp: assertRaisesRegexp and the newly introduced
assertWarnsRegexp.
--
components: +Tests
Michael Foord mich...@voidspace.org.uk added the comment:
@Ezio
Good catch. Even though several of us (including myself) prefer assertRegex
over assertRegexp it is probably better to have consistent APIs otherwise
people will never remember which methods have the 'p' and which don't.
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
After discussion on python-dev, it seems that API lock-in precludes any change
to the package structure. So, the main proposals left are the addition of new
better aliases for some of the functions and changing to the docs
R. David Murray rdmur...@bitdance.com added the comment:
I don't think assertLE is enough of an improvement over assertLessEqual to be
worth adding yet more deprecated names to unittest. So I'm -0 on this change in
general. (I'd be -1 except that it would be kind of nice to have the names be
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
Besides being shorter, the advantages of assertLE are consistent with the rich
comparison method names, no worries about Than, no camel casing ambiguities, no
pluralization or other nmemonic issues (LessThanEqual or
Ezio Melotti ezio.melo...@gmail.com added the comment:
* I would leave asserttypeEqual documented and specify that they should be
called directly only if the type should be checked, otherwise (if the type
doesn't matter or it's already tested elsewhere) using assertEqual is enough
(see also
Antoine Pitrou pit...@free.fr added the comment:
Just my 2 cents:
- I think dedocumenting the type-specific methods is fine (it doesn't mean
removing them, though); or perhaps relegate them to some advanced section
- It's unfortunate that the renaming suggestion comes so late; I'm not sure
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
[Antoine]
I would prefer assertRegex to assertRegexp
That makes sense. It is the name used in other unittest implementations, it
matches what the re module used to be called in Python, and it avoids issues
with camel
Changes by Raymond Hettinger rhettin...@users.sourceforge.net:
--
assignee: michael.foord - rhettinger
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10273
___
Brett Cannon br...@python.org added the comment:
Just sent an email to python-dev, but since this issue sparked it, I might as
well comment here: unittest shouldn't be made back into a single module.
Ignoring the fact that the file structure has nothing to do with the public API
and so is
New submission from Raymond Hettinger rhettin...@users.sourceforge.net:
* Dedocument assertSetEqual, assertDictEqual, assertListEqual, and
assertTupleEqual. These are all automatically dispatched from assertEqual.
The user need not call any of these directly. These methods should not have
Changes by Ezio Melotti ezio.melo...@gmail.com:
--
nosy: +ezio.melotti, michael.foord
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10273
___
___
Antoine Pitrou pit...@free.fr added the comment:
I would prefer assertRegex to assertRegexp.
--
nosy: +pitrou
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10273
___
Michael Foord mich...@voidspace.org.uk added the comment:
In general *none* of this should be done until there is clear consensus on
Python-dev and it isn't clear that this is the case.
* On the deocumenting: barry warsaw objects to public apis that aren't
documented and gregory smith asserts
33 matches
Mail list logo
