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 unde
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
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 the
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..."
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.
Augme
On Tue, Nov 2, 2010 at 12:37 PM, Jacob Kaplan-Moss 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.
"A storm broke loose in my mind." --Albert Einstein
__
On Tue, Nov 2, 2010 at 11:23 AM, Terry Reedy 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,
> such as lex
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 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 inexperience
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.
>
> Many programmers do know
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.
Many programmers do know that sets are partially ordered by inclusion,
preordered by size, and (in Python) tot
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 man
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 that
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 implem
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-d
Raymond Hettinger 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
assertItemsEqual would no longe
On Sun, Oct 31, 2010 at 9:11 AM, Barry Warsaw 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().
>
> As a g
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 document
On Sat, 30 Oct 2010 14:24:10 -0400
"R. David Murray" wrote:
> On Sat, 30 Oct 2010 18:36:45 +0200, Antoine Pitrou
> wrote:
> > On Sat, 30 Oct 2010 12:02:27 -0400
> > "R. David Murray" wrote:
> > >
> > > I don't disagree with this simplification, but given that you all want
> > > to pare down t
On Sat, 30 Oct 2010 18:36:45 +0200, Antoine Pitrou wrote:
> On Sat, 30 Oct 2010 12:02:27 -0400
> "R. David Murray" 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. Beca
On Sat, 30 Oct 2010 12:02:27 -0400
"R. David Murray" 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
> argument, it seems
On Sat, 30 Oct 2010 14:51:28 +0200, Antoine Pitrou wrote:
> On Fri, 29 Oct 2010 20:14:27 -0700
> Raymond Hettinger wrote:
> >
> > I would like to simplify and clean-up the API for the unittest module
> > by de-documenting assertSetEqual(), assertDictEqual(),
> > assertListEqual, and assertTupleE
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 woul
On Fri, 29 Oct 2010 20:14:27 -0700
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().
+1 from me.
Regards
Antoine.
_
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 t
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
>> asser
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 thos
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 name
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 clea
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 de-doc
30 matches
Mail list logo
