On 2011-12-16, Gregory Ewing greg.ew...@canterbury.ac.nz 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
On Dec 16, 3:58 am, MRAB pyt...@mrabarnett.plus.com wrote:
On 16/12/2011 02:14, alex23 wrote:
Eelcohoogendoorn.ee...@gmail.com 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,
On Dec 16, 6:30 am, alex23 wuwe...@gmail.com wrote:
On Dec 16, 3:01 pm, Chris Angelico ros...@gmail.com 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
On Dec 16, 3:25 pm, Eelco hoogendoorn.ee...@gmail.com 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 16 dec, 18:38, rusi rustompm...@gmail.com wrote:
On Dec 16, 3:25 pm, Eelco hoogendoorn.ee...@gmail.com 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)
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
--
On Dec 17, 12:49 am, Gregory Ewing greg.ew...@canterbury.ac.nz
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
In article
2420abd7-7d91-4bc9-bb3b-d8ec1680e...@u32g2000yqe.googlegroups.com,
Eelco hoogendoorn.ee...@gmail.com 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
On Fri, 16 Dec 2011 11:40:11 -0800, Eelco wrote:
On 16 dec, 18:38, rusi rustompm...@gmail.com wrote:
On Dec 16, 3:25 pm, Eelco hoogendoorn.ee...@gmail.com wrote:
Pseudo-backwards compatibility with other languages, I couldnt not
care less for.
Double negations n Goedelian situations have
On Fri, Dec 16, 2011 at 7:54 PM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
On Fri, 16 Dec 2011 11:40:11 -0800, Eelco wrote:
On 16 dec, 18:38, rusi rustompm...@gmail.com wrote:
On Dec 16, 3:25 pm, Eelco hoogendoorn.ee...@gmail.com wrote:
Pseudo-backwards compatibility with
On Dec 15, 4:43 am, rusi rustompm...@gmail.com wrote:
On Dec 14, 10:15 pm, Eelco hoogendoorn.ee...@gmail.com wrote:
'Kindof' off-topic, but what the hell :).
deja-vu
We keep having these debates -- so I wonder how off-topic it is...
And so do famous
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
On Thu, Dec 15, 2011 at 9:47 PM, Robert Kern robert.k...@gmail.com 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 Dec 15, 2:44 pm, Eelco hoogendoorn.ee...@gmail.com 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
On Dec 15, 3:58 pm, Chris Angelico ros...@gmail.com wrote:
On Thu, Dec 15, 2011 at 9:47 PM, Robert Kern robert.k...@gmail.com 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
On Dec 15, 11:47 am, Robert Kern robert.k...@gmail.com 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
On Dec 15, 11:56 am, rusi rustompm...@gmail.com wrote:
On Dec 15, 2:44 pm, Eelco hoogendoorn.ee...@gmail.com 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
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
For the record I should say
On 12/15/2011 6:04 AM, rusi wrote:
On Dec 15, 3:58 pm, Chris Angelicoros...@gmail.com wrote:
On Thu, Dec 15, 2011 at 9:47 PM, Robert Kernrobert.k...@gmail.com 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,
Eelco hoogendoorn.ee...@gmail.com 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
On 16/12/2011 02:14, alex23 wrote:
Eelcohoogendoorn.ee...@gmail.com 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 '%'.
On Fri, Dec 16, 2011 at 1:58 PM, MRAB pyt...@mrabarnett.plus.com 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,
On Dec 16, 3:01 pm, Chris Angelico ros...@gmail.com 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
On Dec 15, 2011 8:01 PM, MRAB pyt...@mrabarnett.plus.com 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.
--
On Dec 14, 4:18 am, Steven D'Aprano steve
+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
is probably that in their minds, mathematics is
Steven D'Aprano writes:
On Mon, 12 Dec 2011 09:29:11 -0800, Eelco wrote:
[quoting Jussi Piitulainen jpiit...@ling.helsinki.fi]
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
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 remainder
On 14 dec, 09:56, Jussi Piitulainen jpiit...@ling.helsinki.fi wrote:
Steven D'Aprano writes:
On Mon, 12 Dec 2011 09:29:11 -0800, Eelco wrote:
[quoting Jussi Piitulainen jpiit...@ling.helsinki.fi]
They recognize modular arithmetic but for some reason insist that
there is no such _binary
On Dec 14, 1:56 pm, Jussi Piitulainen jpiit...@ling.helsinki.fi
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 Wed, Dec 14, 2011 at 10:47 PM, rusi rustompm...@gmail.com 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
On 14 December 2011 07:49, Eelco hoogendoorn.ee...@gmail.com wrote:
On Dec 14, 4:18 am, Steven D'Aprano steve
+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
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 and
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 jpiit...@ling.helsinki.fi]
They recognize modular arithmetic but for some reason insist that
there is no such _binary
On 14 dec, 12:55, Arnaud Delobelle arno...@gmail.com wrote:
On 14 December 2011 07:49, Eelco hoogendoorn.ee...@gmail.com wrote:
On Dec 14, 4:18 am, Steven D'Aprano steve
+comp.lang.pyt...@pearwood.info wrote:
They might not be willing to define it, but as soon as we programmers
do,
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 dont
On 14 dec, 13:22, Jussi Piitulainen jpiit...@ling.helsinki.fi 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
rusi writes:
On Dec 14, 1:56 pm, Jussi Piitulainen jpiit...@ling.helsinki.fi
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.
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 and ask
On Dec 14, 1:38 pm, Steven D'Aprano steve
+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 is not only the logical thing to
do
On Thu, Dec 15, 2011 at 12:29 AM, Eelco hoogendoorn.ee...@gmail.com wrote:
On Dec 14, 1:38 pm, Steven D'Aprano steve
+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
On Wed, Dec 14, 2011 at 6:29 AM, Eelco hoogendoorn.ee...@gmail.com wrote:
On Dec 14, 1:38 pm, Steven D'Aprano steve
+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
On 14 December 2011 12:33, Eelco hoogendoorn.ee...@gmail.com wrote:
On 14 dec, 12:55, Arnaud Delobelle arno...@gmail.com wrote:
On 14 December 2011 07:49, Eelco hoogendoorn.ee...@gmail.com wrote:
On Dec 14, 4:18 am, Steven D'Aprano steve
+comp.lang.pyt...@pearwood.info wrote:
They might
'Kindof' off-topic, but what the hell :).
On Dec 14, 5:13 pm, Arnaud Delobelle arno...@gmail.com wrote:
On 14 December 2011 12:33, Eelco hoogendoorn.ee...@gmail.com wrote:
On 14 dec, 12:55, Arnaud Delobelle arno...@gmail.com wrote:
On 14 December 2011 07:49, Eelco hoogendoorn.ee...@gmail.com
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
On Dec 14, 10:15 pm, Eelco hoogendoorn.ee...@gmail.com wrote:
'Kindof' off-topic, but what the hell :).
deja-vu
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
/deja-vu
:
:
Again,
On Dec 13, 1:27 am, alex23 wuwe...@gmail.com wrote:
On Dec 13, 3:12 am, Eelco hoogendoorn.ee...@gmail.com 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,
On Dec 13, 1:34 am, Ian Kelly ian.g.ke...@gmail.com wrote:
On Mon, Dec 12, 2011 at 11:51 AM, Eelco hoogendoorn.ee...@gmail.com 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
On Dec 13, 2:41 am, Ian Kelly ian.g.ke...@gmail.com wrote:
On Mon, Dec 12, 2011 at 4:40 PM, Eelco hoogendoorn.ee...@gmail.com 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
On Dec 13, 3:43 am, Steven D'Aprano steve
+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 identity comparison; 'equals' can only mean one
thing.
Nonsense.
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 -- just look
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 annotation;
On 13 December 2011 09:50, Eelco hoogendoorn.ee...@gmail.com 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
On 13 dec, 11:15, Arnaud Delobelle arno...@gmail.com wrote:
On 13 December 2011 09:50, Eelco hoogendoorn.ee...@gmail.com 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
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
On Tue, 13 Dec 2011 01:15:46 -0800, Eelco wrote:
On Dec 13, 3:43 am, Steven D'Aprano steve
+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 identity
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:
On 13 dec, 12:28, Steven D'Aprano steve
+comp.lang.pyt...@pearwood.info 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
On 13 dec, 12:13, Steven D'Aprano steve
+comp.lang.pyt...@pearwood.info wrote:
On Tue, 13 Dec 2011 01:15:46 -0800, Eelco wrote:
On Dec 13, 3:43 am, Steven D'Aprano steve
+comp.lang.pyt...@pearwood.info wrote:
On Mon, 12 Dec 2011 04:21:15 -0800, Eelco wrote:
No more, or less, explicit
On Tue, Dec 13, 2011 at 11:47 PM, Eelco hoogendoorn.ee...@gmail.com 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
On 13 dec, 14:14, Chris Angelico ros...@gmail.com wrote:
On Tue, Dec 13, 2011 at 11:47 PM, Eelco hoogendoorn.ee...@gmail.com 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
On Tue, Dec 13, 2011 at 1:44 AM, Eelco hoogendoorn.ee...@gmail.com 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
On 13Dec2011 00:30, Eelco hoogendoorn.ee...@gmail.com wrote:
| On Dec 13, 1:27 am, alex23 wuwe...@gmail.com wrote:
| On Dec 13, 3:12 am, Eelco hoogendoorn.ee...@gmail.com wrote:
| But to relate it to the topic of this thread: no, the syntax does not
| allow one to select the type of the
On Dec 13, 8:11 pm, Cameron Simpson c...@zip.com.au wrote:
On 13Dec2011 00:30, Eelco hoogendoorn.ee...@gmail.com wrote:
| On Dec 13, 1:27 am, alex23 wuwe...@gmail.com wrote:
| On Dec 13, 3:12 am, Eelco hoogendoorn.ee...@gmail.com wrote:
| But to relate it to the topic of this thread: no,
On Dec 13, 7:15 pm, Ian Kelly ian.g.ke...@gmail.com wrote:
On Tue, Dec 13, 2011 at 1:44 AM, Eelco hoogendoorn.ee...@gmail.com 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
On Mon, 12 Dec 2011 09:29:11 -0800, Eelco wrote:
[quoting Jussi Piitulainen jpiit...@ling.helsinki.fi]
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
Steven D'Aprano wrote:
Modulo is hardly an obscure operation. What's the remainder...? is a
simple question that people learn about in primary school.
Well, sort of. The way I remember it, the remainder was just
something that fell out as a side effect of division -- the
annoying bit left
For what it's worth, googling for python asterisk
gives this as the very first result:
http://www.technovelty.org/code/python/asterisk.html
which tells you exactly what you're probably wanting
to know if you ask that.
To check that this phenomemon isn't restricted to
asterisks in particular,
On 12/11/2011 6:53 PM, Eelco Hoogendoorn wrote:
There are other means of finding information than Google. Really.
This is really only a very minor point in my argument, so I dont want to
put the focus on this.
On the contrary, it is a major point. You want us to change the language
so you
On 12/11/2011 6:44 PM, Eelco Hoogendoorn wrote:
Can you come up with some terse symbols that will be able to express all
of the below and dont make you wish you hadnt rather typed out the names?
head, tuple(tail) = iterable
head, list(tail) = iterable
head, str(tail) = somestring
head,
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 after removing the head
In other words,
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
On the contrary, it is a major point. You want us to change the language
so you can program by Google. Sorry, aint't gonna happen.
On the contrary; I believe I get to decide which points I consider
important. This one, I do not. Sorry for putting it in the first paragraph.
--
On the contrary, it is a major point.
Sorry, but im affraid it is up to ME to decide which point I feel are
important. No, this is a minor point to me, and one that has been
admirably put to rest by pointing out that spelling out the name of the
symbol in google directly leads you to the
Eelco Hoogendoorn writes:
As for %; it is entirely unclear to me why that obscure operation
ever got its own one-character symbol. Ill take 'mod', or even
better, 'modulus' any day of the week.
The modulus is not the result but one of the arguments: when numbers x
and y are congruent modulo n
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 sign as the operator.
A quick
By the way...
Is there any particular reason why some of my replies do not show up
on groups.google, and some of them do not show up on mail.python.org?
Sorry to annoy people with reposting, but im going to be forced to do
some of that until this is cleared up
--
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 sign as the
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
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
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
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
Terry Reedy tjre...@udel.edu 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 December 2011 15:52, Terry Reedy tjre...@udel.edu 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 personally
On 12 December 2011 15:36, Terry Reedy tjre...@udel.edu 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
On Tue, Dec 13, 2011 at 2:55 AM, Nick Dokos nicholas.do...@hp.com wrote:
Terry Reedy tjre...@udel.edu 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.
On Tue, Dec 13, 2011 at 3:15 AM, Arnaud Delobelle arno...@gmail.com 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
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
bodies
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
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 division.)
On Monday, December 12, 2011 12:44:27 PM Chris Angelico did opine:
On Tue, Dec 13, 2011 at 2:55 AM, Nick Dokos nicholas.do...@hp.com
wrote:
Terry Reedy tjre...@udel.edu wrote:
calculations are helped by the fact that (a+b) % c == a%c + b%c, so
As long as we understand that == here does
Jussi Piitulainen jpiit...@ling.helsinki.fi 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
On 12/12/2011 12:46 PM, gene heskett wrote:
On Monday, December 12, 2011 12:44:27 PM Chris Angelico did opine:
snip
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
On Mon, Dec 12, 2011 at 5:21 AM, Eelco hoogendoorn.ee...@gmail.com 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,
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 with
gene heskett ghesk...@wdtv.com 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 nicholas.do...@hp.com
wrote:
Terry Reedy tjre...@udel.edu wrote:
calculations are helped by the fact that (a+b) % c == a%c + b%c, so
On Dec 12, 7:09 pm, Ian Kelly ian.g.ke...@gmail.com wrote:
On Mon, Dec 12, 2011 at 5:21 AM, Eelco hoogendoorn.ee...@gmail.com 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
On Mon, Dec 12, 2011 at 11:17 AM, Eelco hoogendoorn.ee...@gmail.com 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
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.
That
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
On Dec 12, 8:05 pm, Eelco hoogendoorn.ee...@gmail.com 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
1 - 100 of 124 matches
Mail list logo
