On Sat, Oct 8, 2011 at 12:50 AM, Terry Reedy wrote:
> That latter function probably want integers code in range(256).
Yes! Non-unicode. The source reads:
def _encrypt(self, m):
# compute m**d (mod n)
return pow(m, self.e, self.n)
>From the source, it is provided as is.
The ar
Kayode Odeyemi wrote:
> On Sat, Oct 8, 2011 at 12:50 AM, Terry Reedy wrote:
>
>> That latter function probably want integers code in range(256).
>
>
> Yes! Non-unicode. The source reads:
>
> def _encrypt(self, m):
> # compute m**d (mod n)
> return pow(m, self.e, self.n)
>
>>F
On Sat, Oct 8, 2011 at 10:37 AM, Peter Otten <__pete...@web.de> wrote:
> Kayode Odeyemi wrote:
>
> > On Sat, Oct 8, 2011 at 12:50 AM, Terry Reedy wrote:
> >
> >> That latter function probably want integers code in range(256).
> >
> >
> > Yes! Non-unicode. The source reads:
> >
> > def _encrypt(se
Basically there can be quite a big job to do based on the user selection and
I've pipelined it so after the user selects the output location the next job
can
get started so long as the first job (preparing the data) has been running for
5
or so seconds roughly. Its just a lot nicer to have this
Python provides
-- the not operator, meaning logical negation
-- the in operator, meaning membership
On the other hand, Python provides the not in operator meaning
non-membership. However, it seems we can reformulate any "not in"
expression using only "not" and "in" operation. For inst
Tim Golden timgolden.me.uk> writes:
>
> On 07/10/2011 11:15, Paul wrote:
> > My first thought was to use a flag but wouldn't the new thread see the
cancel
> > flag and stop as well? I could set it back but then any other threads might
have
> > been busy and not seen it while the flag was on.
>
On Oct 8, 11:42 am, candide wrote:
> Python provides
>
> -- the not operator, meaning logical negation
> -- the in operator, meaning membership
>
> On the other hand, Python provides the not in operator meaning
> non-membership. However, it seems we can reformulate any "not in"
> express
So what is the usefulness of the "not in" operator ? Recall what Zen of
Python tells
There should be one-- and preferably only one --obvious way to do it.
the zen of python also says (amongst other things):
...
Readability counts.
...
Although practicality beats purity
...
Best regards,
St
candide wrote:
> So what is the usefulness of the "not in" operator ? Recall what Zen of
> Python tells
>
> There should be one-- and preferably only one --obvious way to do it.
And "not in" is the obvious way to do it.
"If the key is not in the ignition, you won't be able to start the car."
I am currently debugging the django test cases, and there are a lot of
variables names like w, q, where, condition and so on. Especially variables
like w, q, c, r are really annoying. It would be cool if pdb would detect a
clash and in that case ask you what to do. Nothing more annoying than ste
candide writes:
> Python provides
>
> -- the not operator, meaning logical negation
> -- the in operator, meaning membership
>
> On the other hand, Python provides the not in operator meaning
> non-membership. However, it seems we can reformulate any "not in"
> expression using only "not"
Steven D'Aprano wrote:
> candide wrote:
>
>> So what is the usefulness of the "not in" operator ? Recall what Zen of
>> Python tells
>>
>> There should be one-- and preferably only one --obvious way to do it.
>
> And "not in" is the obvious way to do it.
>
>
> "If the key is not in the igniti
Mel writes:
> Steven D'Aprano wrote:
>
> > candide wrote:
> >
> >> So what is the usefulness of the "not in" operator ? Recall what Zen of
> >> Python tells
> >>
> >> There should be one-- and preferably only one --obvious way to do it.
> >
> > And "not in" is the obvious way to do it.
> >
>
In article <87ehyn8xlp@dpt-info.u-strasbg.fr>,
Alain Ketterlin wrote:
> Sure, but note that you can also reformulate != using not and ==, <
> using not and >=, etc. Operators like "not in" and "is not" should
> really be considered single tokens, even though they seem to use "not".
> And I t
Le 08/10/2011 14:41, Alain Ketterlin a écrit :
Operators like "not in" and "is not" should
really be considered single tokens, even though they seem to use "not".
And I think they are really convenient.
I realize that I was confused by the lexical form of the "not in"
operator : it is made by
Le 08/10/2011 14:01, Steven D'Aprano a écrit :
> And "not in" is the obvious way to do it.
>
>
Obvious ? Not so. I performed some code mining and it appears that even
good sources make use of "not (foo in bar)" expressions.
begin examples ***
from drpython/drPlugin
Le 08/10/2011 12:42, candide a écrit :
>>> not ('th' in "python")
False
>>>
After browsing source code, I realize that parenthesis are not necessary
("not" has higher precedence than "in").
--
http://mail.python.org/mailman/listinfo/python-list
On Sun, Oct 9, 2011 at 1:40 AM, candide wrote:
> A notin operator or isnot operator would be less confusing (at least in my
> case ;) ).
>
Let's replace both of them.
in --> foo extant bar
not in --> foo extinct bar
That would solve the problem, wouldn't it?
*ducking for cover*
ChrisA
--
htt
Le 08/10/2011 12:50, Jon Clements a écrit :
10 - 5 as 10 + -5 (as obviously the - is redundant as an operation),
and 10 / 2 as int(10 * .5) or something, who needs a divide!?
OK, I see your point but I was supposing non-membershipness seldom
needed and in fact one can suppose that test memb
* candide (Sat, 08 Oct 2011 16:41:11 +0200)
> After browsing source code, I realize that parenthesis are not
> necessary ("not" has higher precedence than "in").
Lower precedence.
Thorsten
--
http://mail.python.org/mailman/listinfo/python-list
On 01/-10/-28163 02:59 PM, candide wrote:
Le 08/10/2011 12:42, candide a écrit :
>>> not ('th' in "python")
False
>>>
After browsing source code, I realize that parenthesis are not
necessary ("not" has higher precedence than "in").
You should say
"... parenthesis are not necessary
Le 08/10/2011 17:13, Thorsten Kampe a écrit :
* candide (Sat, 08 Oct 2011 16:41:11 +0200)
After browsing source code, I realize that parenthesis are not
necessary ("not" has higher precedence than "in").
Lower precedence.
Ooops, thanks.
--
http://mail.python.org/mailman/listinfo/python-list
On Sun, Oct 9, 2011 at 2:16 AM, Dave Angel wrote:
> You should say
> "... parenthesis are not necessary ("not" has LOWER precedence than
> "in")."
>
Is "are not" an operator in English, or should this be "not
parentheses are necessary"?
ChrisA
--
http://mail.python.org/mailman/listinfo/pytho
On 2011-10-08, Steven D'Aprano wrote:
> candide wrote:
>
>> So what is the usefulness of the "not in" operator ? Recall what Zen of
>> Python tells
>>
>> There should be one-- and preferably only one --obvious way to do it.
>
> And "not in" is the obvious way to do it.
>
>
> "If the key is not in
On Wed, 05 Oct 2011 21:39:17 -0700, Greg wrote:
> Here is the final code for those who are struggling with similar
> problems:
>
> ## open and decode file
> # In this case, the encoding comes from the charset argument in a meta
> tag
> # e.g.
> fileObj = open(filePath,"r").read()
> fileContent =
Roy Smith wrote:
> If you want to take it one step further, all the boolean operators can
> be derived from nand (the dualists would insist on using nor).
Let's define the boolean values and operators using just two functions:
def true(x, y):
return x
def false(x, y):
return y
That's
Le 08/10/2011 17:16, Dave Angel a écrit :
You should say
"... parenthesis are not necessary ("not" has LOWER precedence than "in")."
I should, yes, I confess ;)
In my defense, I must tell that Python document reference here :
http://docs.python.org/reference/expressions.html#summary
has
candide wrote:
> Le 08/10/2011 14:01, Steven D'Aprano a écrit :
>
> > And "not in" is the obvious way to do it.
>
> Obvious ? Not so. I performed some code mining and it appears that even
> good sources make use of "not (foo in bar)" expressions.
All that proves is that even expert Python dev
On Oct 8, 2:51 pm, X1 wrote:
> easy_install does not exist on Fedora.
http://lmgtfy.com/?q=easy_install+fedora
--
http://mail.python.org/mailman/listinfo/python-list
In article <4e906108$0$27980$426a3...@news.free.fr>,
candide wrote:
> After browsing source code, I realize that parenthesis are not necessary
> ("not" has higher precedence than "in").
Here's my take on parenthesis: If you need to look up whether they're
necessary or not, they are :-)
--
h
On Oct 8, 6:31 pm, Roy Smith wrote:
> In article <87ehyn8xlp@dpt-info.u-strasbg.fr>,
> Alain Ketterlin wrote:
>
> > Sure, but note that you can also reformulate != using not and ==, <
> > using not and >=, etc. Operators like "not in" and "is not" should
> > really be considered single token
On Sun, Oct 9, 2011 at 3:31 AM, rusi wrote:
>> If you want to take it one step further, all the boolean operators can
>> be derived from nand (the dualists would insist on using nor).
>
>
>
I'm not sure what you're questioning, but it's possible to derive
In article
,
rusi wrote:
> On Oct 8, 6:31 pm, Roy Smith wrote:
> > In article <87ehyn8xlp@dpt-info.u-strasbg.fr>,
> > Alain Ketterlin wrote:
> >
> > > Sure, but note that you can also reformulate != using not and ==, <
> > > using not and >=, etc. Operators like "not in" and "is not" sho
On the subject of the gui discussion mentioned here last year, which you get
lead to if you read around in the pyjamas docs, I have to admit, since I know
both development types (gwt, wx, qt) and (django, jquery), I have to state the
fact, that pyjamas should also consider bonding with native ja
On Oct 8, 1:18 pm, Kääriäinen Anssi wrote:
> I am currently debugging the django test cases, and there are a lot of
> variables names like w, q, where, condition and so on. Especially variables
> like w, q, c, r are really annoying. It would be cool if pdb would detect a
> clash and in that cas
Dennis Lee Bieber wrote:
>
> While I wouldn't want to write an FFT in COBOL, one can't deny that
>laying out fixed width reports and moving blocks of decimal data between
>record layouts is quite easy in COBOL.
Absolutely. I've always thought the Data Section in COBOL was conceptually
ahea
Roy Smith wrote:
>In article <4e906108$0$27980$426a3...@news.free.fr>,
> candide wrote:
>
>> After browsing source code, I realize that parenthesis are not necessary
>> ("not" has higher precedence than "in").
>
>Here's my take on parenthesis: If you need to look up whether they're
>necessary
On 09.10.2011 01:35, Tim Roberts wrote:
Roy Smith wrote:
In article<4e906108$0$27980$426a3...@news.free.fr>,
candide wrote:
After browsing source code, I realize that parenthesis are not necessary
("not" has higher precedence than "in").
Here's my take on parenthesis: If you need to look
I sent this email twelve hours ago but to the wrong mailing list
*blush*. Since nobody else has raised the point, I'll repost it.
On Sun, Oct 9, 2011 at 12:07 AM, Jussi Piitulainen
wrote:
> But both negations can be avoided by modus tollens.
>
> "If you are able to start the car, the key is in th
In article ,
Chris Angelico wrote:
> I sent this email twelve hours ago but to the wrong mailing list
> *blush*. Since nobody else has raised the point, I'll repost it.
>
> On Sun, Oct 9, 2011 at 12:07 AM, Jussi Piitulainen
> wrote:
> > But both negations can be avoided by modus tollens.
> >
>
If you want to view the variable, use the "p" (print) command. Then there is no
name clash.
--
http://mail.python.org/mailman/listinfo/python-list
I'm writing a bunch of classes that have "Interface" in the name and
find that the length of the subsequent names is starting to get in the
way of readability (I don't really care about saving keystrokes). Is
"IX" conventional enough to use in place of "Interface" in a class
name? Thanks!
-eric
On Sat, Oct 8, 2011 at 9:21 PM, Eric Snow wrote:
> I'm writing a bunch of classes that have "Interface" in the name and
> find that the length of the subsequent names is starting to get in the
> way of readability (I don't really care about saving keystrokes). Is
> "IX" conventional enough to use
On Sat, Oct 8, 2011 at 10:31 PM, Chris Rebert wrote:
> On Sat, Oct 8, 2011 at 9:21 PM, Eric Snow wrote:
>> I'm writing a bunch of classes that have "Interface" in the name and
>> find that the length of the subsequent names is starting to get in the
>> way of readability (I don't really care abou
Eric Snow writes:
> I'm writing a bunch of classes that have "Interface" in the name and
> find that the length of the subsequent names is starting to get in the
> way of readability (I don't really care about saving keystrokes). Is
> "IX" conventional enough to use in place of "Interface" in a
Hi,
Does anyone know a good tutorial about working with Spreadsheet files (e.g.
excel files) with Python. I have found xlutils, but there doesn't seem to be
any documentation or tutorial about it that I could find. So, any
suggestions?
--
http://yasar.serveblog.net/
--
http://mail.python.org/ma
46 matches
Mail list logo
