C. Titus Brown writes:
p.s. Seriously? I can accept that there's a rational minimalist argument
for this feature,
It is a feature, even if you aren't gonna need it. I want it.wink
Many programmers do know that sets are partially ordered by inclusion,
preordered by size, and (in Python)
On Tue, Nov 02, 2010 at 05:28:43PM +0900, Stephen J. Turnbull wrote:
C. Titus Brown writes:
p.s. Seriously? I can accept that there's a rational minimalist argument
for this feature,
It is a feature, even if you aren't gonna need it. I want it.wink
Many programmers do know that
On 11/2/2010 10:05 AM, C. Titus Brown wrote:
...but, as someone who has to figure out how to teach stuff to CSE undergrads
(and biology grads) I hate the statement ...any programmer should
expect this...
And indeed I (intentionally) did not say that. People who are ignorant
and inexperienced
On 02/11/2010 16:23, Terry Reedy wrote:
On 11/2/2010 10:05 AM, C. Titus Brown wrote:
...but, as someone who has to figure out how to teach stuff to CSE
undergrads
(and biology grads) I hate the statement ...any programmer should
expect this...
And indeed I (intentionally) did not say that.
On Tue, Nov 2, 2010 at 11:23 AM, Terry Reedy tjre...@udel.edu wrote:
What I did say in the post you responded to is Any programmer who sorts (or
uses functions that depend on proper sorting) should know and respect the
difference between partial orders, such as set inclusion, and total orders,
On Tue, Nov 2, 2010 at 12:37 PM, Jacob Kaplan-Moss ja...@jacobian.org wrote:
Hopefully I'm still allowed to use Python.
Definitely! Python's a great place to learn about all these things. :-)
-Fred
--
Fred L. Drake, Jr. fdrake at acm.org
A storm broke loose in my mind. --Albert
Terry Reedy writes:
ethical character. Or have them consider the partial order dependencies
between morning get-ready-for-class activities (socks before shoes
versus pants and shirt in either order). They already do topological
sorting every day, even if the name seems fancy.
Augment
On 04:29 pm, fuzzy...@voidspace.org.uk wrote:
On 02/11/2010 16:23, Terry Reedy wrote:
On 11/2/2010 10:05 AM, C. Titus Brown wrote:
...but, as someone who has to figure out how to teach stuff to CSE
undergrads
(and biology grads) I hate the statement ...any programmer should
expect this...
On 02/11/2010 17:17, exar...@twistedmatrix.com wrote:
On 04:29 pm, fuzzy...@voidspace.org.uk wrote:
On 02/11/2010 16:23, Terry Reedy wrote:
On 11/2/2010 10:05 AM, C. Titus Brown wrote:
...but, as someone who has to figure out how to teach stuff to CSE
undergrads
(and biology grads) I hate
On 11/2/2010 1:23 PM, Michael Foord wrote:
Right, I did quote that exact text earlier in the thread. False
expectations come when there are exceptions to otherwise-consistent
behaviour.
Particularly as it still works for other mutable collections. Worth
being aware that custom implementations
exar...@twistedmatrix.com wrote:
I can't help thinking that most of this confusion is caused by using
for determining subsets. If were not defined for sets and people had
to use set.issubset (which exists already), then sorting a list with
sets would raise an exception, a much more
On 10/31/2010 10:55 PM, Michael Foord wrote:
fact that sets / frozensets can't be sorted in the standard Python way
(their less than comparison adheres to the set definition). This is
something that will probably surprise many Python developers:
Any programmer who sorts (or uses functions
On Mon, Nov 01, 2010 at 02:37:33PM -0400, Terry Reedy wrote:
On 10/31/2010 10:55 PM, Michael Foord wrote:
fact that sets / frozensets can't be sorted in the standard Python way
(their less than comparison adheres to the set definition). This is
something that will probably surprise many
On Oct 29, 2010, at 08:14 PM, Raymond Hettinger wrote:
I would like to simplify and clean-up the API for the unittest module
by de-documenting assertSetEqual(), assertDictEqual(),
assertListEqual, and assertTupleEqual().
As a general principle, I think all public API methods should be
On Sun, Oct 31, 2010 at 9:11 AM, Barry Warsaw ba...@python.org wrote:
On Oct 29, 2010, at 08:14 PM, Raymond Hettinger wrote:
I would like to simplify and clean-up the API for the unittest module
by de-documenting assertSetEqual(), assertDictEqual(),
assertListEqual, and assertTupleEqual().
Raymond Hettinger raymond.hettin...@gmail.com wrote:
I looked at this again and think we should just remove
assertItemsEqual() from Py3.2 and dedocument it in Py2.7. It is listed
as being new in 3.2 so nothing is lost.
One thing that would be lost is that correct Python 2.7 code using
On Oct 31, 2010, at 09:54 AM, Gregory P. Smith wrote:
- moving the documentation to an advanced or complete reference section
Agreed, I perfer simply deemphasizing these methods by reorganizing the
documentation and mentioning in their documentation to, just use
assertEqual. De-documenting
On 30/10/2010 06:56, Raymond Hettinger wrote:
On Oct 29, 2010, at 9:11 PM, Michael Foord wrote:
Just to clarify. The following fails in Python 3:
sorted([3, 1, 2, None])
If you want to compare that two iterables containing heterogeneous
types have the same members then it is tricky to
Raymond Hettinger wrote:
The API for the unittest module has grown fat (the documentation
is approaching 2,000 lines and 10,000 words like a small book).
I think we can improve learnability by focusing on the most
important parts of the API.
I would like to simplify and clean-up the API for
On Fri, 29 Oct 2010 20:14:27 -0700
Raymond Hettinger raymond.hettin...@gmail.com wrote:
I would like to simplify and clean-up the API for the unittest module
by de-documenting assertSetEqual(), assertDictEqual(),
assertListEqual, and assertTupleEqual().
+1 from me.
Regards
Antoine.
On 30/10/2010 02:41, Steven D'Aprano wrote:
Raymond Hettinger wrote:
The API for the unittest module has grown fat (the documentation
is approaching 2,000 lines and 10,000 words like a small book). I
think we can improve learnability by focusing on the most important
parts of the API.
I
On Sat, 30 Oct 2010 14:51:28 +0200, Antoine Pitrou solip...@pitrou.net wrote:
On Fri, 29 Oct 2010 20:14:27 -0700
Raymond Hettinger raymond.hettin...@gmail.com wrote:
I would like to simplify and clean-up the API for the unittest module
by de-documenting assertSetEqual(),
On Sat, 30 Oct 2010 12:02:27 -0400
R. David Murray rdmur...@bitdance.com wrote:
I don't disagree with this simplification, but given that you all want
to pare down the unittest API, I'd be interested in your opinions on
issue 10164. Because the assertBytesEqual method takes an optional
On Sat, 30 Oct 2010 18:36:45 +0200, Antoine Pitrou solip...@pitrou.net wrote:
On Sat, 30 Oct 2010 12:02:27 -0400
R. David Murray rdmur...@bitdance.com wrote:
I don't disagree with this simplification, but given that you all want
to pare down the unittest API, I'd be interested in your
On Sat, 30 Oct 2010 14:24:10 -0400
R. David Murray rdmur...@bitdance.com wrote:
On Sat, 30 Oct 2010 18:36:45 +0200, Antoine Pitrou solip...@pitrou.net
wrote:
On Sat, 30 Oct 2010 12:02:27 -0400
R. David Murray rdmur...@bitdance.com wrote:
I don't disagree with this simplification,
The API for the unittest module has grown fat (the documentation
is approaching 2,000 lines and 10,000 words like a small book).
I think we can improve learnability by focusing on the most
important parts of the API.
I would like to simplify and clean-up the API for the unittest module
by
On 29/10/2010 23:14, Raymond Hettinger wrote:
The API for the unittest module has grown fat (the documentation
is approaching 2,000 lines and 10,000 words like a small book).
I think we can improve learnability by focusing on the most
important parts of the API.
I would like to simplify and
On 29/10/2010 23:29, Michael Foord wrote:
[snip...]
Besides de-documenting those four redundant methods,
I propose that assertItemsEqual() be deprecated just like
its brother assertSameElements(). I haven't found anyone
who accurately guesses what those methods entail based
on their method
On 29/10/2010 23:56, Michael Foord wrote:
On 29/10/2010 23:29, Michael Foord wrote:
[snip...]
Besides de-documenting those four redundant methods,
I propose that assertItemsEqual() be deprecated just like
its brother assertSameElements(). I haven't found anyone
who accurately guesses what
On Oct 29, 2010, at 9:11 PM, Michael Foord wrote:
Just to clarify. The following fails in Python 3:
sorted([3, 1, 2, None])
If you want to compare that two iterables containing heterogeneous types
have the same members then it is tricky to implement correctly and
assertItemsEqual
30 matches
Mail list logo
