Chris Angelico wrote:
Certainly not. A grammer is something which grams. A gram is one
thousandth of an SI unit.
Also, when ordering a hamburger in an SI-using country,
instead of a quarter-pounder you need to ask for a
125-grammer.
--
Greg
--
https://mail.python.org/mailman/listinfo/python-l
Mark Lawrence wrote:
Is it:-
modern art == crap
or
modern art = crap
It's modern == art == crap, surely?
--
Greg
--
https://mail.python.org/mailman/listinfo/python-list
Sven R. Kunze wrote:
Btw. ASCII art is also art. So, why does Python not have ASCII art to
define graphs and diagrams?
Nowadays it would have to support Unicode art. Mustn't
leave out all the world's non-English-speaking artists!
--
Greg
--
https://mail.python.org/mailman/listinfo/python-list
Marko Rauhamaa wrote:
"Sven R. Kunze" :
But I agree more than this often helps confusion more than it helps
clarity.
I see what you did there.
I see what you saw what he did there.
--
Greg
--
https://mail.python.org/mailman/listinfo/python-list
Chris Angelico wrote:
But are there _any_ comparison operators which
are unchainable? If not, there's no reason to disallow 'in';
My problem is that I find it difficult to remember that
Python considers 'in' to be a comparison operator.
To me, comparison is something you do between things of
t
On Wed, Sep 16, 2015, at 21:25, Steven D'Aprano wrote:
> So what? The intended purpose of `is` and `==` is not to return True. It
> is
> to perform a comparison which may return False, or True.
Yeah, but there's no point in doing a comparison unless you're doing it
in a context where it *might* re
On 2015-09-16 21:25, Mark Lawrence wrote:
> Is it:-
>
> modern art == crap
>
> or
>
> modern art = crap
Pretty sure they're both wrong...
modern art < crap
;-)
-tkc
--
https://mail.python.org/mailman/listinfo/python-list
On Sun, 13 Sep 2015 09:27 am, Ned Batchelder wrote:
> On Thursday, September 10, 2015 at 8:44:01 PM UTC-4, Denis McMahon wrote:
>> On Fri, 11 Sep 2015 03:54:14 +1000, Steven D'Aprano wrote:
>>
>> > If I did this thing, would people follow me down the street booing and
>> > jeering and throwing th
On Thu, 17 Sep 2015 10:06 am, Mark Lawrence wrote:
> On 16/09/2015 23:15, Sven R. Kunze wrote:
>> On 16.09.2015 23:30, Mark Lawrence wrote:
>>> Barry John art is also art. So, why does Python not have Barry John
>>> art to define graphs and diagrams?
>>
>> Too colorful for a grammer?
>
> I'm not
Em terça-feira, 15 de setembro de 2015 21:47:10 UTC-3, Chris Angelico escreveu:
> On Wed, Sep 16, 2015 at 10:29 AM, Rafael David wrote:
> > Oooohhh ... I think I got it! I'm assigning a reference to peca and not the
> > value itself! Thank you very much MRAB and C Smith for the enlightenment :)
On Thu, 17 Sep 2015 10:06 am, Mark Lawrence wrote:
> On 16/09/2015 23:15, Sven R. Kunze wrote:
>> On 16.09.2015 23:30, Mark Lawrence wrote:
>>> Barry John art is also art. So, why does Python not have Barry John
>>> art to define graphs and diagrams?
>>
>> Too colorful for a grammer?
>
> I'm not
On Thu, 17 Sep 2015 03:47 am, Random832 wrote:
> On Wed, Sep 16, 2015, at 13:33, Steven D'Aprano wrote:
>> On Thu, 17 Sep 2015 01:40 am, Random832 wrote:
>>
>> > "in" suggests a relationship between objects of different types (X and
>> > "something that can contain X") - all the other comparison
On Thu, 17 Sep 2015 03:41 am, Sven R. Kunze wrote:
> On 16.09.2015 19:33, Steven D'Aprano wrote:
>> On Thu, 17 Sep 2015 01:40 am, Random832 wrote:
>>
>>> "in" suggests a relationship between objects of different types (X and
>>> "something that can contain X") - all the other comparison operators
Às 11:42 de 15-09-2015, Laura Creighton escreveu:
> In a message of Tue, 15 Sep 2015 03:31:49 +0100, Paulo da Silva writes:
...
>> Now I would like to change the background color the editable field.
>>
...
>
> I just hardcoded it like this:
>
> integers_dict = {str(i): {'text': str(i), 'is_selec
On Thu, 17 Sep 2015 03:44 am, Grant Edwards wrote:
> On 2015-09-16, Steven D'Aprano wrote:
>> On Thu, 17 Sep 2015 03:27 am, Grant Edwards wrote:
>>
>>> On 2015-09-16, Sven R. Kunze wrote:
On 16.09.2015 18:57, Random832 wrote:
> I think that chaining should be limited to:
>
> A)
On 9/16/2015 5:53 PM, Chris Angelico wrote:
On Thu, Sep 17, 2015 at 10:06 AM, Mark Lawrence wrote:
On 16/09/2015 23:15, Sven R. Kunze wrote:
On 16.09.2015 23:30, Mark Lawrence wrote:
Barry John art is also art. So, why does Python not have Barry John
art to define graphs and diagrams?
T
Às 08:44 de 15-09-2015, David Aldrich escreveu:
>> Not sure if this is the place to ask about kivy ...
>
> Try the kivy users list here:
>
> https://groups.google.com/forum/#!forum/kivy-users
Thanks for the link.
--
https://mail.python.org/mailman/listinfo/python-list
On Thu, Sep 17, 2015 at 10:06 AM, Mark Lawrence wrote:
> On 16/09/2015 23:15, Sven R. Kunze wrote:
>>
>> On 16.09.2015 23:30, Mark Lawrence wrote:
>>>
>>> Barry John art is also art. So, why does Python not have Barry John
>>> art to define graphs and diagrams?
>>
>>
>> Too colorful for a grammer
On 16/09/2015 23:15, Sven R. Kunze wrote:
On 16.09.2015 23:30, Mark Lawrence wrote:
Barry John art is also art. So, why does Python not have Barry John
art to define graphs and diagrams?
Too colorful for a grammer?
I'm not with you, sorry. Is "grammer" the US spelling of the UK "grammar"?
In a message of Wed, 16 Sep 2015 21:29:23 +0200, Kristian Rink writes:
>Am 15.09.2015 um 08:59 schrieb paul.hermeneu...@gmail.com:
>>
>> https://docs.python.org/3/library/venv.html?highlight=venv#module-venv
>
>Thanks, this already is pretty close to what I need. Playing with this
>and virtualenv,
On 16.09.2015 23:30, Mark Lawrence wrote:
Barry John art is also art. So, why does Python not have Barry John
art to define graphs and diagrams?
Too colorful for a grammer?
--
https://mail.python.org/mailman/listinfo/python-list
On 16/09/2015 22:05, Sven R. Kunze wrote:
On 16.09.2015 21:47, Grant Edwards wrote:
On 2015-09-16, Sven R. Kunze wrote:
On 16.09.2015 19:46, Grant Edwards wrote:
On 2015-09-16, Steven D'Aprano wrote:
node = left <= ptr => right
Exactly. I've no clue what that means. ;)
Modern art. ;)
On 16/09/2015 21:39, Carl Meyer wrote:
On 09/16/2015 02:29 PM, Mark Lawrence wrote:
On 16/09/2015 18:53, Sven R. Kunze wrote:
On 16.09.2015 19:39, Steven D'Aprano wrote:
node = left <= ptr => right
Wow. I have absolutely no idea what this is supposed to mean. Do you
care to elaborate?
Best
On 16.09.2015 21:47, Grant Edwards wrote:
On 2015-09-16, Sven R. Kunze wrote:
On 16.09.2015 19:46, Grant Edwards wrote:
On 2015-09-16, Steven D'Aprano wrote:
node = left <= ptr => right
Exactly. I've no clue what that means. ;)
Modern art. ;)
Ah, well I know that _that_ means:
"I
On 16.09.2015 22:55, Random832 wrote:
On Wed, Sep 16, 2015, at 16:38, Mark Lawrence wrote:
On 16/09/2015 18:41, Sven R. Kunze wrote:
On 16.09.2015 19:33, Steven D'Aprano wrote:
And with operator overloading, < <= > and => could have any meaning you
like:
graph = a => b => c <= d <= e
Sorr
On Wed, Sep 16, 2015, at 16:38, Mark Lawrence wrote:
> On 16/09/2015 18:41, Sven R. Kunze wrote:
> > On 16.09.2015 19:33, Steven D'Aprano wrote:
> >> And with operator overloading, < <= > and => could have any meaning you
> >> like:
> >>
> >> graph = a => b => c <= d <= e
> >
> > Sorry? What are y
On 16/09/2015 18:41, Sven R. Kunze wrote:
On 16.09.2015 19:33, Steven D'Aprano wrote:
On Thu, 17 Sep 2015 01:40 am, Random832 wrote:
"in" suggests a relationship between objects of different types (X and
"something that can contain X") - all the other comparison operators are
meant to work on
On 09/16/2015 02:29 PM, Mark Lawrence wrote:
> On 16/09/2015 18:53, Sven R. Kunze wrote:
>> On 16.09.2015 19:39, Steven D'Aprano wrote:
>>> node = left <= ptr => right
>>
>> Wow. I have absolutely no idea what this is supposed to mean. Do you
>> care to elaborate?
>>
>>
>> Best,
>> Sven
>
> Simple
On 16/09/2015 18:53, Sven R. Kunze wrote:
On 16.09.2015 19:39, Steven D'Aprano wrote:
node = left <= ptr => right
Wow. I have absolutely no idea what this is supposed to mean. Do you
care to elaborate?
Best,
Sven
Simple, straight forward easy to read bit of Python, where is the
problem?
On 16/09/2015 20:47, Grant Edwards wrote:
On 2015-09-16, Sven R. Kunze wrote:
On 16.09.2015 19:46, Grant Edwards wrote:
On 2015-09-16, Steven D'Aprano wrote:
node = left <= ptr => right
Exactly. I've no clue what that means. ;)
Modern art. ;)
Ah, well I know that _that_ means:
"I
On 16/09/2015 18:41, Emile van Sebille wrote:
On 9/16/2015 10:27 AM, Grant Edwards wrote:
On 2015-09-16, Sven R. Kunze wrote:
On 16.09.2015 18:57, Random832 wrote:
I think that chaining should be limited to:
A) all operators are "="
B) all operators are "is"
C) all operators are either >= or
On 16/09/2015 17:16, Marko Rauhamaa wrote:
Chris Angelico :
Far as I can see, the only operator that you might want to disallow
chaining on is 'in' (and its mate 'not in', of course). It isn't
common, but "x is y is z is None" is a perfectly reasonable way to
ascertain whether or not they're al
Ah. Thanks.. I removed the previous code. Please excuse me. I will rewrite
the question so it is clear.
Here is my current solution in an imperative way. My application will work
with AWS boto library to create EC2 instances and RDS instances. Assuming
my API will simply send the request, and retu
"Sven R. Kunze" :
> On 16.09.2015 19:39, Steven D'Aprano wrote:
>> node = left <= ptr => right
>
> Wow. I have absolutely no idea what this is supposed to mean. Do you
> care to elaborate?
Python is an HC Language for HC Developers.
Marko
--
https://mail.python.org/mailman/listinfo/python-list
On 2015-09-16, Sven R. Kunze wrote:
> On 16.09.2015 19:46, Grant Edwards wrote:
>> On 2015-09-16, Steven D'Aprano wrote:
>>
>>> node = left <= ptr => right
>>
>> Exactly. I've no clue what that means. ;)
>
> Modern art. ;)
Ah, well I know that _that_ means:
"I think it exemplifies the angst
On 16.09.2015 19:46, Grant Edwards wrote:
On 2015-09-16, Steven D'Aprano wrote:
node = left <= ptr => right
Exactly. I've no clue what that means. ;)
Modern art. ;)
Best,
Sven
--
https://mail.python.org/mailman/listinfo/python-list
On 16.09.2015 19:39, Steven D'Aprano wrote:
node = left <= ptr => right
Wow. I have absolutely no idea what this is supposed to mean. Do you
care to elaborate?
Best,
Sven
--
https://mail.python.org/mailman/listinfo/python-list
Am 15.09.2015 um 08:59 schrieb paul.hermeneu...@gmail.com:
https://docs.python.org/3/library/venv.html?highlight=venv#module-venv
Thanks, this already is pretty close to what I need. Playing with this
and virtualenv, I figured out that this way it's pretty easily possible
to have isolated Py
On 9/16/2015 10:42 AM, Marko Rauhamaa wrote:
Steven D'Aprano :
The main reason for supporting arbitrary chained operators is that
they could be overloaded and have some meaning that makes sense:
Operator overloading is yet another unfortunate language feature.
dunder methods are there for c
On Wed, Sep 16, 2015 at 11:24 AM, Steven D'Aprano wrote:
>
> if word in line in text:
> print("word in line and line in text")
It find it hard to imagine how one would arrive at the situation of
needing to check this.
--
https://mail.python.org/mailman/listinfo/python-list
On 2015-09-16, Steven D'Aprano wrote:
> On Thu, 17 Sep 2015 02:57 am, Random832 wrote:
>
>
>> I think that chaining should be limited to:
>>
>> A) all operators are "="
>> B) all operators are "is"
>> C) all operators are either >= or >
>> D) all operators are either <= or <
>>
>> There's no oth
On 16.09.2015 19:36, Random832 wrote:
I just had another thought on *why* the other cases make me so uneasy.
The reason this is reasonable for simple cases like a > b > c or a < b
<= c is that, in their normal meanings, these operations are transitive.
a > b and b > c implies a > c. a < b and b
On Wed, Sep 16, 2015 at 11:44 AM, Grant Edwards wrote:
> On 2015-09-16, Steven D'Aprano wrote:
>> On Thu, 17 Sep 2015 03:27 am, Grant Edwards wrote:
>>
>>> On 2015-09-16, Sven R. Kunze wrote:
On 16.09.2015 18:57, Random832 wrote:
> I think that chaining should be limited to:
>
>
On Wed, Sep 16, 2015, at 13:44, Grant Edwards wrote:
> Well, that case hadn't been mentioned yet. But, I agree that should be
> added as case E and be allowed.
That's actually what I meant by A, I just spelled it wrong.
Multiple assignment isn't really the same construct as chained
comparisons, I
On 2015-09-16, Random832 wrote:
> On Wed, Sep 16, 2015, at 13:33, Steven D'Aprano wrote:
[...]
>> graph = a => b => c <= d <= e
>
> Are you suggesting that all objects concerned are a magical "graph node
> object", the <= and [sic] => operators of which return "edge objects",
> the and operator
On 2015-09-16, Steven D'Aprano wrote:
> On Thu, 17 Sep 2015 03:27 am, Grant Edwards wrote:
>
>> On 2015-09-16, Sven R. Kunze wrote:
>>> On 16.09.2015 18:57, Random832 wrote:
I think that chaining should be limited to:
A) all operators are "="
B) all operators are "is"
>
> [...
Steven D'Aprano :
> The main reason for supporting arbitrary chained operators is that
> they could be overloaded and have some meaning that makes sense:
Operator overloading is yet another unfortunate language feature.
Marko
--
https://mail.python.org/mailman/listinfo/python-list
On Thu, 17 Sep 2015 03:27 am, Grant Edwards wrote:
> On 2015-09-16, Sven R. Kunze wrote:
>> On 16.09.2015 18:57, Random832 wrote:
>>> I think that chaining should be limited to:
>>>
>>> A) all operators are "="
>>> B) all operators are "is"
[...]
> I'm not all that sure A and B should be allowe
On Wed, Sep 16, 2015, at 13:33, Steven D'Aprano wrote:
> On Thu, 17 Sep 2015 01:40 am, Random832 wrote:
>
> > "in" suggests a relationship between objects of different types (X and
> > "something that can contain X") - all the other comparison operators are
> > meant to work on objects of the same
On 16.09.2015 19:33, Steven D'Aprano wrote:
On Thu, 17 Sep 2015 01:40 am, Random832 wrote:
"in" suggests a relationship between objects of different types (X and
"something that can contain X") - all the other comparison operators are
meant to work on objects of the same or similar types.
`is`
On Thu, 17 Sep 2015 02:57 am, Random832 wrote:
> I think that chaining should be limited to:
>
> A) all operators are "="
> B) all operators are "is"
> C) all operators are either >= or >
> D) all operators are either <= or <
>
> There's no other scenario, if the operators have natural meanings
On 9/16/2015 10:27 AM, Grant Edwards wrote:
On 2015-09-16, Sven R. Kunze wrote:
On 16.09.2015 18:57, Random832 wrote:
I think that chaining should be limited to:
A) all operators are "="
B) all operators are "is"
C) all operators are either >= or >
D) all operators are either <= or <
I'
On Wed, Sep 16, 2015, at 13:24, Steven D'Aprano wrote:
> On Thu, 17 Sep 2015 12:03 am, Random832 wrote:
>
> if word in line in text:
> print("word in line and line in text")
>
> But I agree with Tim Chase: I wouldn't use it, even though it's legal.
I just had another thought on *why* the othe
On Thu, 17 Sep 2015 01:40 am, Random832 wrote:
> "in" suggests a relationship between objects of different types (X and
> "something that can contain X") - all the other comparison operators are
> meant to work on objects of the same or similar types.
`is` and the equality operators are intended
On 2015-09-16, Sven R. Kunze wrote:
> On 16.09.2015 18:57, Random832 wrote:
>> I think that chaining should be limited to:
>>
>> A) all operators are "="
>> B) all operators are "is"
>> C) all operators are either >= or >
>> D) all operators are either <= or <
>
> That certainly would be a fine gu
On Thu, 17 Sep 2015 12:03 am, Random832 wrote:
> Do chained "in" comparisons ever really make sense, even when they're
> all the same type?
>
> I mean, I suppose 1 in (1, 2) in ((1, 2), (3, 4)) is technically true,
> but how useful is it really?
if fly in spider in rat in cat in dog in old_woma
On 16.09.2015 18:57, Random832 wrote:
I think that chaining should be limited to:
A) all operators are "="
B) all operators are "is"
C) all operators are either >= or >
D) all operators are either <= or <
That certainly would be a fine guideline. Only use it with all operators
the same.
Eve
What is the best way to determine if a file object is unbuffered?
In Python 3.4, if I open the file with buffering=0, I get a FileIO object.
>>> fh = open("tmp", "rb+", buffering=0)
>>> fh
<_io.FileIO name='tmp' mode='rb+'>
Is the FileIO object always unbuffered?
If I open it without buffering=
On Wed, Sep 16, 2015, at 12:37, Sven R. Kunze wrote:
> I like it for x < y < z.
>
> But I agree more than this often helps confusion more than it helps
> clarity.
I think that chaining should be limited to:
A) all operators are "="
B) all operators are "is"
C) all operators are either >= or >
D)
"Sven R. Kunze" :
> On 16.09.2015 18:16, Marko Rauhamaa wrote:
>> Frankly, I don't think chaining was all that great of an idea.
>
> I like it for x < y < z.
>
> But I agree more than this often helps confusion more than it helps
> clarity.
I see what you did there.
Marko
--
https://mail.pytho
On 16.09.2015 18:16, Marko Rauhamaa wrote:
Chris Angelico :
Far as I can see, the only operator that you might want to disallow
chaining on is 'in' (and its mate 'not in', of course). It isn't
common, but "x is y is z is None" is a perfectly reasonable way to
ascertain whether or not they're al
Chris Angelico :
> Far as I can see, the only operator that you might want to disallow
> chaining on is 'in' (and its mate 'not in', of course). It isn't
> common, but "x is y is z is None" is a perfectly reasonable way to
> ascertain whether or not they're all None, just as "x = y = z = None"
> i
On Thu, Sep 17, 2015 at 1:26 AM, wrote:
> The installer should detect that it is being run on an unsupported system
> and do something helpful.
Fair point. Want to raise a tracker issue on bugs.python.org about it?
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
On Wed, Sep 16, 2015, at 10:26, Chris Angelico wrote:
> Quite probably never. But are there _any_ comparison operators which
> are unchainable? If not, there's no reason to disallow 'in'
"in" suggests a relationship between objects of different types (X and
"something that can contain X") - all th
The installer should detect that it is being run on an unsupported system
and do something helpful.
--
https://mail.python.org/mailman/listinfo/python-list
This bit me once. I was comparing a date to a datetime, both representing the
same day, so I expected them to be the same, but I was wrong. What I should
have done was extracting the date of the datetime with the .date() function,
and only then compare it to the other date:
>>> import datetime
On Wed, Sep 16, 2015 at 11:45 PM, Watson, Paul wrote:
> In terms of operator precedence, is "==" evaluated before "in"?
No, they're at the same precedence level. Within that, all comparison
operators are evaluated left-to-right, with the chaining that was
described earlier.
ChrisA
--
https://ma
On Thu, Sep 17, 2015 at 12:34 AM, John Wong wrote:
> Sorry first time posting to tutor / general list. Usually on TIP list. As
> per Mark's recommendation, now posting to python-list@python.org.
But, sadly, without a lot of context. When you change lists, it's
helpful to include a lot of extra ve
On 2015-09-16 10:03, Random832 wrote:
> Do chained "in" comparisons ever really make sense, even when
> they're all the same type?
>
> I mean, I suppose 1 in (1, 2) in ((1, 2), (3, 4)) is technically
> true, but how useful is it really?
I could concoct a "useful" example where "in" is involved in
In terms of operator precedence, is "==" evaluated before "in"?
*-*-*- PRESBYTERIAN_HEALTHCARE_SERVICES_DISCLAIMER -*-*-*
This message originates from Presbyterian Healthcare Services or one of its
affiliated organizations.
It contains information, whi
On Wed, Sep 16, 2015 at 7:54 AM, Mark Lawrence
wrote:
>
> Assuming your (Alan's) guess is correct, and I certainly agree it's
> plausible, I suspect this might be better asked on the main Python mailing
> list, I don't see this as tutor material.
>
> Sorry first time posting to tutor / general li
On Thu, Sep 17, 2015 at 12:03 AM, Random832 wrote:
> On Wed, Sep 16, 2015, at 09:05, Chris Angelico wrote:
>> My view is that they should remain in the language, but that
>> dissimilar comparisons should raise linter warnings. I can't imagine a
>> sane reason for chaining 'in' and equality like th
On Wed, Sep 16, 2015 at 8:55 AM, Nick Sarbicki
wrote:
> Just in the case you didn't figure it out:
>
> >>> datetime.datetime.today()
> datetime.datetime(2015, 9, 16, 14, 50, 47, 700828)
> >>> datetime.date.today()
> datetime.date(2015, 9, 16)
>
Yeah, I was aware of that. That is partly why I th
On Wed, Sep 16, 2015, at 09:05, Chris Angelico wrote:
> My view is that they should remain in the language, but that
> dissimilar comparisons should raise linter warnings. I can't imagine a
> sane reason for chaining 'in' and equality like that (since the RHS of
> 'in' will be a container, and if y
> This surprised me today:
>
> >>> import datetime
> >>> datetime.datetime.today(), datetime.datetime.now()
> (datetime.datetime(2015, 9, 16, 8, 44, 7, 723560), datetime.datetime(2015,
> 9, 16, 8, 44, 7, 723577))
>
> I naively expected today() to always return a datetime.date object. Oh
> well, bug
This surprised me today:
>>> import datetime
>>> datetime.datetime.today(), datetime.datetime.now()
(datetime.datetime(2015, 9, 16, 8, 44, 7, 723560), datetime.datetime(2015,
9, 16, 8, 44, 7, 723577))
I naively expected today() to always return a datetime.date object. Oh
well, bug in my code has
On Wednesday, September 16, 2015 at 9:08:54 AM UTC-4, jmp wrote:
> x = 5
> 3 < x < 10
That's a great example. I use this case all the time and didn't think to apply
the same principal to the in/== case. I assumed that "in" was evaluated first,
and then the == comparison was made. Thanks!
--
On Wednesday, September 16, 2015 at 8:54:07 AM UTC-4, Jussi Piitulainen wrote:
> The second test, test2, is interpreted (almost) as
>
> (1 in {1:1}) and ({1:1} == 1)
>
> which is obviously False.
Ah, that makes sense. It didn't occur to me that Python would interpret it
that way, and I'
In a message of Wed, 16 Sep 2015 17:35:18 +0800, "chenc...@inhand.com.cn" write
s:
>hi:
>I encountered a problem. I use ctypes load multiple C libraries, but
>the libraries have dependence each other.So, how can i load these
>libraries. For example, I have two libraries:A、B, but A depends on B,
On 09/16/2015 02:16 PM, Blake T. Garretson wrote:
1 in {1:1} == 1 #test2
The second test yield False, because True does not equal 1, apparently. Fair
enough.
No, it yields False because {1:1} == 1 is false. Test 2 looks actually like
(1 in {1:1}) and ({1:1} == 1).
Which in your example
On Wed, Sep 16, 2015 at 10:53 PM, Jussi Piitulainen
wrote:
> Ouch. I love chained comparisons more than most people, but this took a
> while to decipher. I blame you! Your parentheses mis-primed me for the
> wrong reading :) But now I expect to see a long thread about whether
> chained comparisons
Blake T. Garretson writes:
> I am maintaining some old code where the programmer used 1 for True
> because booleans hadn't been added to Python yet. I'm getting some
> weird behaviour, so I created some simple tests to illustrate my
> issue.
>
> >>> 1 in {1:1}#test1
> True
> >>> 1 i
I am maintaining some old code where the programmer used 1 for True because
booleans hadn't been added to Python yet. I'm getting some weird behaviour, so
I created some simple tests to illustrate my issue.
>>> 1 in {1:1}#test1
True
>>> 1 in {1:1} == 1 #test2
False
>>> (1 in {1:1}) ==
hi:
Most current compilers and linkers will search all object files,
regard-less of order, but since not all compilers do this it is best to
follow the
convention of ordering object files from left to right . Python do that.
So, is there anybody know how to solve the follow problem?
On 09/
On Wed, Sep 16, 2015 at 7:35 PM, chenc...@inhand.com.cn
wrote:
> I encountered a problem. I use ctypes load multiple C libraries, but the
> libraries have dependence each other.So, how can i load these libraries. For
> example, I have two libraries:A、B, but A depends on B, B depends on A. So
> ho
On Wed, Sep 16, 2015 at 7:27 PM, Victor Hooi wrote:
> Also, I originally used grouper because I thought it better to process lines
> in batches, rather than individually. However, is there actually any
> throughput advantage from doing it this way in Python? Or is there a better
> way of gettin
hi:
I encountered a problem. I use ctypes load multiple C libraries, but
the libraries have dependence each other.So, how can i load these
libraries. For example, I have two libraries:A、B, but A depends on B, B
depends on A. So how do I load them? Is there anybody know how to do it?
--
http
I'm using Python to parse metrics out of logfiles.
The logfiles are fairly large (multiple GBs), so I'm keen to do this in a
reasonably performant way.
The metrics are being sent to a InfluxDB database - so it's better if I can
batch multiple metrics into a batch ,rather than sending them indiv
Op 16-09-15 om 03:13 schreef Steven D'Aprano:
> On Mon, 14 Sep 2015 06:30 pm, Antoon Pardon wrote:
>
>> Op 12-09-15 om 05:48 schreef Steven D'Aprano:
>>> I believe I already acknowledged that assignment-as-expression was fine
>>> if it avoided the = versus == error, from the perspective of avoiding
Am Mittwoch, 16. September 2015 07:58:11 UTC+2 schrieb dieter:
> Thomas Güttler writes:
> > Am Freitag, 11. September 2015 11:03:52 UTC+2 schrieb jmp:
> > ...
> >> Something like (python 2.7)
> >>
> >> import logging
> >>
> >> logCfg = {
> >> 'remote':(
> >> logging.StreamHandler()
On Wed, Sep 16, 2015 at 6:24 PM, Ben Finney wrote:
> Chris Angelico writes:
>
>> On Wed, Sep 16, 2015 at 6:14 PM, Gregory Ewing
>> wrote:
>> > This suggests an alternative model for Python computation. All data
>> > is represented by cats. A variable is a box containing a cat.
>> > Assignment re
[This announcement is in German since it targets a Python sprint in
Düsseldorf, Germany]
ANKÜNDIGUNG
PyDDF Python Sprint 2015
in Düsseldorf
Samstag, 26.09.2015
Chris Angelico writes:
> On Wed, Sep 16, 2015 at 6:14 PM, Gregory Ewing
> wrote:
> > This suggests an alternative model for Python computation. All data
> > is represented by cats. A variable is a box containing a cat.
> > Assignment replaces one cat with an entangled copy of another cat,
> > so
On Wed, Sep 16, 2015 at 6:14 PM, Gregory Ewing
wrote:
> Emile van Sebille wrote:
>
>> Shroedingers-cat-was-just-a-cat-in-a-box-too-ly y'rs,
>
>
> The real question is, if you kill Schroedinger's cat, does
> Heisenberg's cat die too? If so, then either they're the
> same cat, or they're two entangl
Emile van Sebille wrote:
Shroedingers-cat-was-just-a-cat-in-a-box-too-ly y'rs,
The real question is, if you kill Schroedinger's cat, does
Heisenberg's cat die too? If so, then either they're the
same cat, or they're two entangled cats.
This suggests an alternative model for Python computation
On Tue, Sep 15, 2015 at 8:43 PM, Serj wrote:
> I just downloaded 3.5.0 install package for Win32
> (python-3.5.0-webinstall.exe) and I see some strange behaviour under Win
> XP: there is no "Next" or "Run" button in wizard )))
Python 3.5 no longer supports Windows XP, sorry. You can continue to
u
On 15/09/2015 11:43, Serj wrote:
> Hi there!
>
> I just downloaded 3.5.0 install package for Win32
> (python-3.5.0-webinstall.exe) and I see some strange behaviour under Win
> XP: there is no "Next" or "Run" button in wizard )))
>
> Clicked into space near "Cancel" I opened "options" screen, whil
Hi there!
I just downloaded 3.5.0 install package for Win32
(python-3.5.0-webinstall.exe) and I see some strange behaviour under Win
XP: there is no "Next" or "Run" button in wizard )))
Clicked into space near "Cancel" I opened "options" screen, while
clicked in another place (closer to center of
On Sat, Sep 12, 2015 at 9:58 PM, Tim Peters wrote:
> I think acceptance of 495 should be contingent upon
> someone first completing a fully functional (if not releasable)
> fold-aware zoneinfo wrapping.
>
After studying both pytz and dateutil offerings, I decided that it is
easier to add "fold-a
99 matches
Mail list logo
