On 2011-12-16, Gregory Ewing wrote:
> Eelco wrote:
>> the actual english usage of the phrase, which omits
>> the negation completely :). (I could care less)
>
> No, that's the American usage.
That's the _ignorant_ American usage. Americans with a clue use the
"couldn't" version. I won't comment
On Fri, Dec 16, 2011 at 7:54 PM, Steven D'Aprano
wrote:
> On Fri, 16 Dec 2011 11:40:11 -0800, Eelco wrote:
>
>> On 16 dec, 18:38, rusi wrote:
>>> On Dec 16, 3:25 pm, Eelco wrote:
>>>
>>> > Pseudo-backwards compatibility with other languages, I couldnt not
>>> > care less for.
>>>
>>> Double nega
On Fri, 16 Dec 2011 11:40:11 -0800, Eelco wrote:
> On 16 dec, 18:38, rusi wrote:
>> On Dec 16, 3:25 pm, Eelco wrote:
>>
>> > Pseudo-backwards compatibility with other languages, I couldnt not
>> > care less for.
>>
>> Double negations n Goedelian situations have interesting implications
>> (tho
In article
<2420abd7-7d91-4bc9-bb3b-d8ec1680e...@u32g2000yqe.googlegroups.com>,
Eelco wrote:
> And yes, I agree; 'I couldnt care less' makes much more sense. 'I
> could care less' can only make sense if you interpret it
> sarcastically, as if omitting an 'oh wait, I cant', but that does not
> s
On Dec 17, 12:49 am, Gregory Ewing
wrote:
> Eelco wrote:
> > the actual english usage of the phrase, which omits
> > the negation completely :). (I could care less)
>
> No, that's the American usage. The English usage is
> "I couldn't care less", which has the advantage of
> actually making sense.
Eelco wrote:
the actual english usage of the phrase, which omits
the negation completely :). (I could care less)
No, that's the American usage. The English usage is
"I couldn't care less", which has the advantage of
actually making sense.
--
Greg
--
http://mail.python.org/mailman/listinfo/pyth
On 16 dec, 18:38, rusi wrote:
> On Dec 16, 3:25 pm, Eelco wrote:
>
> > Pseudo-backwards compatibility with other
> > languages, I couldnt not care less for.
>
> Double negations n Goedelian situations have interesting implications
> (tho here its triple)
Heh. Well at least my extra (unintended)
On Dec 16, 3:25 pm, Eelco wrote:
> Pseudo-backwards compatibility with other
> languages, I couldnt not care less for.
Double negations n Goedelian situations have interesting implications
(tho here its triple)
--
http://mail.python.org/mailman/listinfo/python-list
On Dec 16, 6:30 am, alex23 wrote:
> On Dec 16, 3:01 pm, Chris Angelico wrote:
>
> > And I would be most sorry to see % renamed to mod in Python.
>
> > "Hello, %s! My favourite number is %d." mod ("Fred",42) # This just
> > looks wrong.
>
> Finally we can give this operator a more fitting name -
On Dec 16, 3:58 am, MRAB wrote:
> On 16/12/2011 02:14, alex23 wrote:
>
> > Eelco wrote:
> >> To tie it back in with python language design; all the more reason
> >> not to opt for pseudo-backwards compatibility. If python wants a
> >> remainder function, call it 'remainder'. Not 'rem', not 'mod',
On Dec 15, 2011 8:01 PM, "MRAB" wrote:
> Python has "def", "del", "int", "str", "len", and so on. "rem" or "mod"
> (Ada has both, I believe) would be in keeping with the language.
I think I would have to object to "rem" purely on the basis that it denotes
comments in BASIC.
--
http://mail.python
On Dec 16, 3:01 pm, Chris Angelico wrote:
> And I would be most sorry to see % renamed to mod in Python.
>
> "Hello, %s! My favourite number is %d." mod ("Fred",42) # This just
> looks wrong.
Finally we can give this operator a more fitting name - I propose
'inject' - and put an end to this ins
On Fri, Dec 16, 2011 at 1:58 PM, MRAB wrote:
> In financial circles it could be an operator for calculating
> percentages, eg. "5 % x" would be 5 percent of x.
>
> It's an oddity, but an established one. :-)
And I would be most sorry to see % renamed to mod in Python.
"Hello, %s! My favourite nu
On 16/12/2011 02:14, alex23 wrote:
Eelco wrote:
To tie it back in with python language design; all the more reason
not to opt for pseudo-backwards compatibility. If python wants a
remainder function, call it 'remainder'. Not 'rem', not 'mod', and
certainly not '%'.
Python has "def", "del", "i
Eelco wrote:
> To tie it back in with python language design; all the more reason not
> to opt for pseudo-backwards compatibility. If python wants a remainder
> function, call it 'remainder'. Not 'rem', not 'mod', and certainly not
> '%'.
Good luck with the PEP.
> Its the more pythonic way; a se
On 12/15/2011 6:04 AM, rusi wrote:
On Dec 15, 3:58 pm, Chris Angelico wrote:
On Thu, Dec 15, 2011 at 9:47 PM, Robert Kern wrote:
42 = 2 mod 5
2 = 42 mod 5
It might make more sense to programmers if you think of it as written:
42 = 2, mod 5
2 = 42, mod 5
Better, using ascii text, woul
rusi writes:
> On Dec 15, 3:58 pm, Chris Angelico wrote:
> > On Thu, Dec 15, 2011 at 9:47 PM, Robert Kern wrote:
> > > 42 = 2 mod 5
> > > 2 = 42 mod 5
> >
> > It might make more sense to programmers if you think of it as
> > written:
> >
> > 42 = 2, mod 5
> > 2 = 42, mod 5
> >
> > ChrisA
>
> Fo
On Dec 15, 11:56 am, rusi wrote:
> On Dec 15, 2:44 pm, Eelco wrote:
>
> > In other words, what logic needs is a better exception-handling
> > system, which completes the circle with programming languages quite
> > nicely. :)
>
> Cute... but dangerously recursive (if taken literally)
> Remember th
On Dec 15, 11:47 am, Robert Kern wrote:
> On 12/14/11 12:32 PM, Steven D'Aprano wrote:
>
> > On Wed, 14 Dec 2011 10:56:02 +0200, Jussi Piitulainen wrote:
> >> I'm not misunderstanding any argument. There was no argument. There was
> >> a blanket pronouncement that _in mathematics_ mod is not a bin
On Dec 15, 3:58 pm, Chris Angelico wrote:
> On Thu, Dec 15, 2011 at 9:47 PM, Robert Kern wrote:
> > 42 = 2 mod 5
> > 2 = 42 mod 5
>
> It might make more sense to programmers if you think of it as written:
>
> 42 = 2, mod 5
> 2 = 42, mod 5
>
> ChrisA
For the record I should say that the guy who
On Dec 15, 2:44 pm, Eelco wrote:
> In other words, what logic needs is a better exception-handling
> system, which completes the circle with programming languages quite
> nicely. :)
Cute... but dangerously recursive (if taken literally)
Remember that logic is the foundation of programming langua
On Thu, Dec 15, 2011 at 9:47 PM, Robert Kern wrote:
> 42 = 2 mod 5
> 2 = 42 mod 5
It might make more sense to programmers if you think of it as written:
42 = 2, mod 5
2 = 42, mod 5
ChrisA
--
http://mail.python.org/mailman/listinfo/python-list
On 12/14/11 12:32 PM, Steven D'Aprano wrote:
On Wed, 14 Dec 2011 10:56:02 +0200, Jussi Piitulainen wrote:
I'm not misunderstanding any argument. There was no argument. There was
a blanket pronouncement that _in mathematics_ mod is not a binary
operator. I should learn to challenge such pronoun
On Dec 15, 4:43 am, rusi wrote:
> On Dec 14, 10:15 pm, Eelco wrote:
>
> > 'Kindof' off-topic, but what the hell :).
>
>
> We keep having these debates -- so I wonder how off-topic it is...
> And so do famous
> CSists:http://research.microsoft.com/en-us/um/people/gurevich/opera/123.pdf
>
Well,
On Dec 14, 10:15 pm, Eelco wrote:
> 'Kindof' off-topic, but what the hell :).
We keep having these debates -- so I wonder how off-topic it is...
And so do famous CSists:
http://research.microsoft.com/en-us/um/people/gurevich/opera/123.pdf
:
:
> > Again, you are completely mis-representing the
On 12/14/2011 5:09 AM, Eelco wrote:
Arguably, the most elegant thing to do is to define integer division
and remainder as a single operation;
It actually is, as quotient and remainder are calculated together. The
microprocessors I know of expose this (as does Python). 'a divmod b'
puts the q
'Kindof' off-topic, but what the hell :).
On Dec 14, 5:13 pm, Arnaud Delobelle wrote:
> On 14 December 2011 12:33, Eelco wrote:
> > On 14 dec, 12:55, Arnaud Delobelle wrote:
> >> On 14 December 2011 07:49, Eelco wrote:
> >> > On Dec 14, 4:18 am, Steven D'Aprano >> > +comp.lang.pyt...@pearwood
On 14 December 2011 12:33, Eelco wrote:
> On 14 dec, 12:55, Arnaud Delobelle wrote:
>> On 14 December 2011 07:49, Eelco wrote:
>> > On Dec 14, 4:18 am, Steven D'Aprano > > +comp.lang.pyt...@pearwood.info> wrote:
>> >> > They might not be willing to define it, but as soon as we programmers
>> >>
On Wed, Dec 14, 2011 at 6:29 AM, Eelco wrote:
> On Dec 14, 1:38 pm, Steven D'Aprano +comp.lang.pyt...@pearwood.info> wrote:
>> On Wed, 14 Dec 2011 02:09:32 -0800, Eelco wrote:
>> > Arguably, the most elegant thing to do is to define integer division and
>> > remainder as a single operation; which
On Thu, Dec 15, 2011 at 12:29 AM, Eelco wrote:
> On Dec 14, 1:38 pm, Steven D'Aprano +comp.lang.pyt...@pearwood.info> wrote:
>> That would be:
>>
>> >>> divmod(17, 5)
>>
>> (3, 2)
>
> Cool; if only it were in the math module id be totally happy.
That's easily solved.
import math
math.divmod=div
On Dec 14, 1:38 pm, Steven D'Aprano wrote:
> On Wed, 14 Dec 2011 02:09:32 -0800, Eelco wrote:
> > Arguably, the most elegant thing to do is to define integer division and
> > remainder as a single operation; which is not only the logical thing to
> > do mathematically, but might work really well p
Steven D'Aprano writes:
> On Wed, 14 Dec 2011 10:56:02 +0200, Jussi Piitulainen wrote:
> > I'm not misunderstanding any argument. There was no
> > argument. There was a blanket pronouncement that _in mathematics_
> > mod is not a binary operator. I should learn to challenge such
> > pronouncements
rusi writes:
> On Dec 14, 1:56 pm, Jussi Piitulainen
> wrote:
> >
> > Is someone saying that _division_ is not defined because -42 div -5 is
> > somehow both 9 and 8? Hm, yes, I see that someone might. The two
> > operations, div and rem, need to be defined together.
> ---
On 14 dec, 13:22, Jussi Piitulainen wrote:
> > > Is someone saying that _division_ is not defined because -42 div
> > > -5 is somehow both 9 and 8? Hm, yes, I see that someone might. The
> > > two operations, div and rem, need to be defined together.
>
> > > (There is no way to make remainder a bi
On Wed, 14 Dec 2011 02:09:32 -0800, Eelco wrote:
> Arguably, the most elegant thing to do is to define integer division and
> remainder as a single operation; which is not only the logical thing to
> do mathematically, but might work really well programmatically too.
>
> The semantics of python d
On 14 dec, 12:55, Arnaud Delobelle wrote:
> On 14 December 2011 07:49, Eelco wrote:
> > On Dec 14, 4:18 am, Steven D'Aprano > +comp.lang.pyt...@pearwood.info> wrote:
> >> > They might not be willing to define it, but as soon as we programmers
> >> > do, well, we did.
>
> >> > Having studied the
On Wed, 14 Dec 2011 10:56:02 +0200, Jussi Piitulainen wrote:
> Steven D'Aprano writes:
>> On Mon, 12 Dec 2011 09:29:11 -0800, Eelco wrote:
>>
>> [quoting Jussi Piitulainen ]
>> >> They recognize modular arithmetic but for some reason insist that
>> >> there is no such _binary operation_. But as I
Eelco writes:
> On 14 dec, 09:56, Jussi Piitulainen wrote:
> > But I think the argument "there are several such functions,
> > therefore, _in mathematics_, there is no such function" is its own
> > caricature.
>
> Indeed. Obtaining a well defined function is just a matter of
> picking a convention
On 14 December 2011 07:49, Eelco wrote:
> On Dec 14, 4:18 am, Steven D'Aprano +comp.lang.pyt...@pearwood.info> wrote:
>> > They might not be willing to define it, but as soon as we programmers
>> > do, well, we did.
>>
>> > Having studied the contemporary philosophy of mathematics, their concern
On Wed, Dec 14, 2011 at 10:47 PM, rusi wrote:
> `quot` is integer division truncated toward zero, while the result of
> `div` is truncated toward negative infinity.
All these problems just because of negative numbers. They ought never
to have been invented.
At least nobody rounds toward positive
On Dec 14, 1:56 pm, Jussi Piitulainen
wrote:
>
> Is someone saying that _division_ is not defined because -42 div -5 is
> somehow both 9 and 8? Hm, yes, I see that someone might. The two
> operations, div and rem, need to be defined together.
-
Haskell defines a quot-re
On 14 dec, 09:56, Jussi Piitulainen wrote:
> Steven D'Aprano writes:
> > On Mon, 12 Dec 2011 09:29:11 -0800, Eelco wrote:
>
> > [quoting Jussi Piitulainen ]
> > >> They recognize modular arithmetic but for some reason insist that
> > >> there is no such _binary operation_. But as I said, I don't
>
Nick Dokos writes:
> Jussi Piitulainen wrote:
> > They recognize modular arithmetic but for some reason insist that
> > there is no such _binary operation_. But as I said, I don't
> > understand their concern. (Except the related concern about some
> > programming languages, not Python, where the r
Steven D'Aprano writes:
> On Mon, 12 Dec 2011 09:29:11 -0800, Eelco wrote:
>
> [quoting Jussi Piitulainen ]
> >> They recognize modular arithmetic but for some reason insist that
> >> there is no such _binary operation_. But as I said, I don't
> >> understand their concern. (Except the related con
On Dec 14, 4:18 am, Steven D'Aprano wrote:
> > They might not be willing to define it, but as soon as we programmers
> > do, well, we did.
>
> > Having studied the contemporary philosophy of mathematics, their concern
> > is probably that in their minds, mathematics is whatever some dead guy
> > s
On Mon, 12 Dec 2011 09:29:11 -0800, Eelco wrote:
[quoting Jussi Piitulainen ]
>> They recognize modular arithmetic but for some reason insist that there
>> is no such _binary operation_. But as I said, I don't understand their
>> concern. (Except the related concern about some programming language
On Dec 13, 7:15 pm, Ian Kelly wrote:
> On Tue, Dec 13, 2011 at 1:44 AM, Eelco wrote:
> > 'for i in llist' is not quite going to fly is it? Thats probably the
> > reason noone ever uses that construct; its not a proper sequence type.
>
> Not really a problem, because fortunately Python makes it su
On Dec 13, 8:11 pm, Cameron Simpson wrote:
> On 13Dec2011 00:30, Eelco wrote:
> | On Dec 13, 1:27 am, alex23 wrote:
> | > On Dec 13, 3:12 am, Eelco wrote:
> | > > But to relate it to the topic of this thread: no, the syntax does not
> | > > allow one to select the type of the resulting sequence
On 13Dec2011 00:30, Eelco wrote:
| On Dec 13, 1:27 am, alex23 wrote:
| > On Dec 13, 3:12 am, Eelco wrote:
| > > But to relate it to the topic of this thread: no, the syntax does not
| > > allow one to select the type of the resulting sequence. It always
| > > constructs a list.
| >
| > So by thi
On Tue, Dec 13, 2011 at 1:44 AM, Eelco wrote:
> 'for i in llist' is not quite going to fly is it? Thats probably the
> reason noone ever uses that construct; its not a proper sequence type.
Not really a problem, because fortunately Python makes it super-easy
to create custom iterators.
def listi
On 13 dec, 14:14, Chris Angelico wrote:
> On Tue, Dec 13, 2011 at 11:47 PM, Eelco wrote:
> >> def f(*args) *constructs* a tuple, it
> >> doesn't perform a type-check.
>
> > I am talking about type constraints... A type-check is something
> > along the lines of type(args)==list, a runtime thing an
On Tue, Dec 13, 2011 at 11:47 PM, Eelco wrote:
>> def f(*args) *constructs* a tuple, it
>> doesn't perform a type-check.
>
> I am talking about type constraints... A type-check is something
> along the lines of type(args)==list, a runtime thing and something
> completely different. I havnt mention
On 13 dec, 12:13, Steven D'Aprano wrote:
> On Tue, 13 Dec 2011 01:15:46 -0800, Eelco wrote:
> > On Dec 13, 3:43 am, Steven D'Aprano > +comp.lang.pyt...@pearwood.info> wrote:
> >> On Mon, 12 Dec 2011 04:21:15 -0800, Eelco wrote:
> >> >> No more, or less, explicit than the difference between "==" a
On 13 dec, 12:28, Steven D'Aprano wrote:
> On Tue, 13 Dec 2011 02:46:13 -0800, Eelco wrote:
> > With all this being said, I must say that the notion of indtroducing
> > type constraints into Python is quite a radical one*,
>
> Not that radical. Here's the creator of Python musing about adding
> op
On Tue, 13 Dec 2011 02:46:13 -0800, Eelco wrote:
> With all this being said, I must say that the notion of indtroducing
> type constraints into Python is quite a radical one*,
Not that radical. Here's the creator of Python musing about adding
optional type checks to Python:
http://www.artima.c
On Tue, 13 Dec 2011 01:15:46 -0800, Eelco wrote:
> On Dec 13, 3:43 am, Steven D'Aprano +comp.lang.pyt...@pearwood.info> wrote:
>> On Mon, 12 Dec 2011 04:21:15 -0800, Eelco wrote:
>> >> No more, or less, explicit than the difference between "==" and
>> >> "is".
>>
>> > == may be taken to mean iden
With all this being said, I must say that the notion of indtroducing
type constraints into Python is quite a radical one*, and one that
should not be taken lightly, so I understand the general conservative
vibe the notion is getting. It probably has implications beyond just
collection types, and if
On 13 dec, 11:15, Arnaud Delobelle wrote:
> On 13 December 2011 09:50, Eelco wrote:
>
> >> To answer that question: for the same reasons. The conversion is
> >> wasteful; allowing python to do the right thing based on a
> >> typeconstraint is not. Plus, it is less code, and more readable code;
>
On 13 December 2011 09:50, Eelco wrote:
>> To answer that question: for the same reasons. The conversion is
>> wasteful; allowing python to do the right thing based on a
>> typeconstraint is not. Plus, it is less code, and more readable code;
>> the only rule you have to learn is quite general, wh
> To answer that question: for the same reasons. The conversion is
> wasteful; allowing python to do the right thing based on a
> typeconstraint is not. Plus, it is less code, and more readable code;
> the only rule you have to learn is quite general, which is that :: is
> a type constraint annotat
> > Python users generally follow the rule "explicit is better than
> > implicit". Setting a general constraint and letting the language "do
> > the right thing" is a kind of black magic that feels off because it
> > tends to break that rule. But that's not to say that black magic
> > never wins
On Dec 13, 3:43 am, Steven D'Aprano wrote:
> On Mon, 12 Dec 2011 04:21:15 -0800, Eelco wrote:
> >> No more, or less, explicit than the difference between "==" and "is".
>
> > == may be taken to mean identity comparison; 'equals' can only mean one
> > thing.
>
> Nonsense. "Equals" can be taken to m
On Dec 13, 2:41 am, Ian Kelly wrote:
> On Mon, Dec 12, 2011 at 4:40 PM, Eelco wrote:
> >> For a linked list, no *target and no copying is needed:
>
> >> head, tail = llist
>
> > I have no idea what this means.
>
> Each node of a linked list consists of a data member and a "next"
> member, that ho
On Dec 13, 1:34 am, Ian Kelly wrote:
> On Mon, Dec 12, 2011 at 11:51 AM, Eelco wrote:
> > Either way, its not hard to add some detail to the semantics to allow
> > all this. Even this function definition:
>
> > def func(Foo(args), Foo(kwargs))
>
> > ...could even be defined unambigiously by overl
On Dec 13, 1:27 am, alex23 wrote:
> On Dec 13, 3:12 am, Eelco wrote:
>
> > But to relate it to the topic of this thread: no, the syntax does not
> > allow one to select the type of the resulting sequence. It always
> > constructs a list.
>
> So by this argument, _every_ function that returns a li
On Mon, Dec 12, 2011 at 7:43 PM, Steven D'Aprano
wrote:
> If I want to collect a sequence of arguments into a string, why shouldn't
> I be allowed to write this?
>
> def func(parg, str(args)): ...
Obviously, because the correct syntax would be:
def func(parg, ''.join(args)): ...
:-P
--
http
On Tue, Dec 13, 2011 at 1:43 PM, Steven D'Aprano
wrote:
> It merely happens that C's
> use of the notation % for the remainder operation likely influenced
> Python's choice of the same notation.
Considering that Python also had the notion that "integer divided by
integer yields integer" until Py3
On Mon, 12 Dec 2011 04:21:15 -0800, Eelco wrote:
>> No more, or less, explicit than the difference between "==" and "is".
>
> == may be taken to mean identity comparison; 'equals' can only mean one
> thing.
Nonsense. "Equals" can be taken to mean anything the language designer
chooses, same as
On Mon, Dec 12, 2011 at 4:40 PM, Eelco wrote:
>> For a linked list, no *target and no copying is needed:
>>
>> head, tail = llist
>
> I have no idea what this means.
Each node of a linked list consists of a data member and a "next"
member, that holds the next node in the list. The natural contai
On Mon, 12 Dec 2011 16:58:33 -0500, Terry Reedy wrote:
> On 12/12/2011 12:12 PM, Eelco wrote:
>> Yes, we can cast the list to be whatever we want on the next line,
>
> Convert. For the very few cases one wants to do this, it is quite
> adequate.
+1
with the small proviso that there's not much
On Mon, Dec 12, 2011 at 11:51 AM, Eelco wrote:
> Either way, its not hard to add some detail to the semantics to allow
> all this. Even this function definition:
>
> def func(Foo(args), Foo(kwargs))
>
> ...could even be defined unambigiously by overloading first on base
> type, and if that does no
On Dec 13, 3:12 am, Eelco wrote:
> But to relate it to the topic of this thread: no, the syntax does not
> allow one to select the type of the resulting sequence. It always
> constructs a list.
So by this argument, _every_ function that returns a list should take
an optional argument to specify a
> > Im not sure if this is a genuine understanding, or trollish
> > obtuseness.
>
> If you are referring to what I write, it is based on genuine
> understanding of Python.
This is getting 'interesting'. In a way. I meant to write
'misunderstanding', as I think the context made quite clear. So agai
On Dec 12, 10:21 pm, Eelco wrote:
> > Modulo is hardly an obscure operation. "What's the remainder...?" is a
> > simple question that people learn about in primary school.
>
> So is 'how much wood would a woodchucker chuck if a woodchucker could
> chuck wood?'. But how often does that concept tu
On 12/12/2011 12:12 PM, Eelco wrote:
Im not sure if this is a genuine understanding, or trollish
obtuseness.
If you are referring to what I write, it is based on genuine
understanding of Python.
Yes, the target can be anywhere in the sequence. And yes, the
resulting list can contain object
Steven D'Aprano wrote:
> And you can blame C for the use of % instead of mod or modulo.
Anytime you can blame C for something, you can also blame a bunch
of other languages for foolishly perpetuating the inanities of C.
--
--OKB (not okblacke)
Brendan Barnwell
"Do not follow where the
On Dec 12, 8:05 pm, Eelco wrote:
> To get back on topic a little bit, lets get back to the syntax of all
> this: I think we all agree that recycling the function call syntax is
> less than ideal, since while it works in special contexts like a
> function signature, its symmetric counterpart inside
To get back on topic a little bit, lets get back to the syntax of all
this: I think we all agree that recycling the function call syntax is
less than ideal, since while it works in special contexts like a
function signature, its symmetric counterpart inside a function call
already has the meaning o
> False.
I stand corrected.
> Or are you saying that only classes specifically derived from list,
> tuple, or dict should be considered, and custom containers that are
> not derived from any of those but implement the correct protocols
> should be excluded? If so, that sounds less than ideal.
T
On Mon, Dec 12, 2011 at 11:17 AM, Eelco wrote:
> Im not sure if I was clear on that, but I dont care what the
> constructors accept; I meant to overload on the concept the underlying
> type models. Dicts model a mapping, lists/tuples model a sequence. MI
> deriving from both these models is illega
On Dec 12, 7:09 pm, Ian Kelly wrote:
> On Mon, Dec 12, 2011 at 5:21 AM, Eelco wrote:
> > You cannot; only constructors modelling a sequence or a dict, and
> > only
> > in that order. Is that rule clear enough?
>
> The dict constructor can receive either a sequence or a mapping, so if
> I write th
gene heskett wrote:
> On Monday, December 12, 2011 12:44:27 PM Chris Angelico did opine:
>
> > On Tue, Dec 13, 2011 at 2:55 AM, Nick Dokos
> wrote:
> > > Terry Reedy wrote:
> > >> calculations are helped by the fact that (a+b) % c == a%c + b%c, so
> > >
> > > As long as we understand that ==
Eelco writes:
> > They recognize modular arithmetic but for some reason insist that
> > there is no such _binary operation_. But as I said, I don't understand
> > their concern. (Except the related concern about some programming
> > languages, not Python, where the remainder does not behave well w
On Mon, Dec 12, 2011 at 5:21 AM, Eelco wrote:
> You cannot; only constructors modelling a sequence or a dict, and
> only
> in that order. Is that rule clear enough?
The dict constructor can receive either a sequence or a mapping, so if
I write this:
def func(a, b, dict(c)):
what will I
On 12/12/2011 12:46 PM, gene heskett wrote:
On Monday, December 12, 2011 12:44:27 PM Chris Angelico did opine:
This is the basis of the grade-school "casting out nines" method of
checking arithmetic. Set c=9 and you can calculate N%c fairly readily
(digit sum - I'm assuming here that the arithm
Jussi Piitulainen wrote:
> Terry Reedy writes:
> > On 12/12/2011 5:59 AM, Jussi Piitulainen wrote:
> >
> > > Past experience in mathematics newsgroups tells me
> > > that some mathematicians do not accept the existence of any remainder
> > > operator at all.
> >
> > Even though they carry hour/
On Monday, December 12, 2011 12:44:27 PM Chris Angelico did opine:
> On Tue, Dec 13, 2011 at 2:55 AM, Nick Dokos
wrote:
> > Terry Reedy wrote:
> >> calculations are helped by the fact that (a+b) % c == a%c + b%c, so
> >
> > As long as we understand that == here does not mean "equal", only
> >
> They recognize modular arithmetic but for some reason insist that
> there is no such _binary operation_. But as I said, I don't understand
> their concern. (Except the related concern about some programming
> languages, not Python, where the remainder does not behave well with
> respect to divisi
> > I personally quite like them, but I would like them to be more general.
>
> It already is. The *target can be anywhere in the sequence.
Im not sure if this is a genuine understanding, or trollish
obtuseness.
Yes, the target can be anywhere in the sequence. And yes, the
resulting list can con
Terry Reedy writes:
> On 12/12/2011 5:59 AM, Jussi Piitulainen wrote:
>
> > Past experience in mathematics newsgroups tells me
> > that some mathematicians do not accept the existence of any remainder
> > operator at all.
>
> Even though they carry hour/minute/second remindering devices on their
On Tue, Dec 13, 2011 at 3:15 AM, Arnaud Delobelle wrote:
>
> You mean (a + b) % c == (a%c + b%c) % c
>
> :)
It's just integer wraparound. Modulo 9 is the same as "render this
number in base 9 and take the last digit" (and printing a number in
base 9 would normally be done with mod 9 division), an
On Tue, Dec 13, 2011 at 2:55 AM, Nick Dokos wrote:
> Terry Reedy wrote:
>> calculations are helped by the fact that (a+b) % c == a%c + b%c, so
>
> As long as we understand that == here does not mean "equal", only
> "congruent modulo c", e.g try a = 13, b = 12, c = 7.
This is the basis of the gra
On 12 December 2011 15:36, Terry Reedy wrote:
> Huh? Funny you should say 'everyday'. It is now 10 o'clock. In 20 hours, it
> will be (10+20) % 12 == 6 o'clock. It is now day 1 of the week. In 9 days it
> will be day (1+9) % 7 == 3 of the week. Mental calculations are helped by
> the fact that (a+
On 12 December 2011 15:52, Terry Reedy wrote:
> No, *target unpacking (singular) is quite useful in specialized cases. But
> it is not specifically head/tail unpacking.
>
a,*b,c = 1,2,3,4,5,6
a,b,c
> (1, [2, 3, 4, 5], 6)
*a,b,c = 1,2,3,4,5
a,b,c
> ([1, 2, 3], 4, 5)
>
>> I pers
Terry Reedy wrote:
> calculations are helped by the fact that (a+b) % c == a%c + b%c, so
As long as we understand that == here does not mean "equal", only
"congruent modulo c", e.g try a = 13, b = 12, c = 7.
Nick
--
http://mail.python.org/mailman/listinfo/python-list
On 12/12/2011 4:12 AM, Eelco Hoogendoorn wrote:
The above examples are seldom needed in Python because we have one
general method to repeatedly split a sequence into head and tail.
it = iter(iterable) # 'it' now represents the sequenced iterable
head = next(it) # 'it' now represents the tail a
On 12/12/2011 5:59 AM, Jussi Piitulainen wrote:
Past experience in mathematics newsgroups tells me
that some mathematicians do not accept the existence of any remainder
operator at all.
Even though they carry hour/minute/second remindering devices on their
bodies and put year/month/day remai
On 12/12/2011 3:09 AM, Gregory Ewing wrote:
people who don't become programmers, I suspect they never
have much use for remainders in everyday life.
Huh? Funny you should say 'everyday'. It is now 10 o'clock. In 20 hours,
it will be (10+20) % 12 == 6 o'clock. It is now day 1 of the week. In 9
> No more, or less, explicit than the difference between "==" and "is".
== may be taken to mean identity comparison; 'equals' can only mean
one
thing. Of course 'formally' these symbols are well defined, but so is
brainf*ck
> Modulo is hardly an obscure operation. "What's the remainder...?" is a
Eelco writes:
> > The modulus is not the result but one of the arguments: when numbers x
> > and y are congruent modulo n (stated in terms of the modulo operation:
> > x mod n = y mod n), the modulus is n. A word for x mod n is remainder.
> >
> > I agree about the obscurity of using the percent si
1 - 100 of 124 matches
Mail list logo
