On Fri, Apr 10, 2015 at 5:19 AM, Ben Bacarisse wrote:
> Chris Angelico writes:
>
>> On Fri, Apr 10, 2015 at 4:46 AM, Ben Finney
>> wrote:
>>> Travis Griggs writes:
>>>
Here’s 3 examples:
if k + ‘_@‘ in documents:
timeKey = k + ‘_@‘
historyKey = th
Chris Angelico writes:
> On Fri, Apr 10, 2015 at 4:46 AM, Ben Finney
> wrote:
>> Travis Griggs writes:
>>
>>> Here’s 3 examples:
>>>
>>> if k + ‘_@‘ in documents:
>>>
>>> timeKey = k + ‘_@‘
>>>
>>> historyKey = thingID + ‘_’ + k
>>
>> In addition to the other responses, I'll point
On Thu, Apr 9, 2015 at 2:42 PM, Ben Finney wrote:
> Larry Martell writes:
>
>> I have an XML file that looks like this (this is just the pertinent
>> part, the file is huge):
>
> It's also not a very helpful schema. Elements called “Node”, where the
> actual type of element is in an attribute, ju
On Fri, Apr 10, 2015 at 4:46 AM, Ben Finney wrote:
> Travis Griggs writes:
>
>> Here’s 3 examples:
>>
>> if k + ‘_@‘ in documents:
>>
>> timeKey = k + ‘_@‘
>>
>> historyKey = thingID + ‘_’ + k
>
> In addition to the other responses, I'll point out a different issue:
>
> Your client is
On Thu, Apr 9, 2015 at 2:39 PM, Peter Otten <__pete...@web.de> wrote:
> Larry Martell wrote:
>
>> I have an XML file that looks like this (this is just the pertinent
>> part, the file is huge):
>>
>>
>>
>>
>>
>>
>>
>>
>> KA21
>>
Travis Griggs writes:
> Here’s 3 examples:
>
> if k + ‘_@‘ in documents:
>
> timeKey = k + ‘_@‘
>
> historyKey = thingID + ‘_’ + k
In addition to the other responses, I'll point out a different issue:
Your client is composing messages that munge your text. Ensure you post
only the e
I am under the impression that using format() is the canonically "right way
to do it". It is certainly more readable than using ''.join() and is more
semantically specific than string addition.
On Thu, Apr 9, 2015 at 1:35 PM, Chris Angelico wrote:
> On Fri, Apr 10, 2015 at 4:29 AM, Travis Griggs
On Fri, Apr 10, 2015 at 4:44 AM, Andrew Farrell wrote:
> I am under the impression that using format() is the canonically "right way
> to do it". It is certainly more readable than using ''.join() and is more
> semantically specific than string addition.
Depends what you're doing. Sometimes it's
Larry Martell writes:
> I have an XML file that looks like this (this is just the pertinent
> part, the file is huge):
It's also not a very helpful schema. Elements called “Node”, where the
actual type of element is in an attribute, just make your job needlessly
harder.
They also pointlessly fo
Larry Martell wrote:
> I have an XML file that looks like this (this is just the pertinent
> part, the file is huge):
>
>
>
>
>
>
>
>
> KA21
> KA21
>
>
>
>
>
>
>
On Fri, Apr 10, 2015 at 4:29 AM, Travis Griggs wrote:
>
> if k + ‘_@‘ in documents:
>
> timeKey = k + ‘_@‘
>
> historyKey = thingID + ‘_’ + k
>
> I’m curious where others lean stylistically with this kind of thing. I see
> *at least* 2 other alternatives:
>
So few? I'd just use strin
I was doing some maintenance now on a script of mine… I noticed that I compose
strings in this little 54 line file multipole times using the + operator. I was
prototyping at the time I wrote it and it was quick and easy. I don’t really
care for the way they read. Here’s 3 examples:
if k + ‘
Steven D'Aprano :
> It's not so much the undefined behaviour part that gets me. That's bad
> enough. But the concept that having the compiler ignore what you write
> in the source code because you've accidentally hit some undefined part
> of the spec *is a feature* rather than a horrible, horrible
Chris Angelico :
> With applications languages, as earlier mentioned, none of this should
> be necessary. Sacrifice the performance and have arbitrary-precision
> integers, Unicode strings, garbage collection, and first-class
> lists/functions/mappings etc. This is only about lower-level
> languag
Steven D'Aprano :
> There are good ways to deal with out-of-range results in systems
> languages:
>
> - well-defined wrap-around behaviour;
> - saturation;
> - trapping.
Some months back I reported a bug in LXDE's CPU monitor applet: after a
couple of months of operation, the CPU monitor displaye
On Fri, Apr 10, 2015 at 3:41 AM, Steven D'Aprano
wrote:
> There are good ways to deal with out-of-range results in systems languages:
>
> - well-defined wrap-around behaviour;
> - saturation;
> - trapping.
>
> "Do whatever the hell the compiler feels like doing" is not one of them.
Systems langua
I have an XML file that looks like this (this is just the pertinent
part, the file is huge):
KA21
KA21
00:00:00
15/03/2014 05:56:
On Fri, Apr 10, 2015 at 3:35 AM, Steven D'Aprano
wrote:
> It's not so much the undefined behaviour part that gets me. That's bad
> enough. But the concept that having the compiler ignore what you write in
> the source code because you've accidentally hit some undefined part of the
> spec *is a fea
On Fri, 10 Apr 2015 02:36 am, Chris Angelico wrote:
> *According to the C standard*, you just did something impossible
Woo-hoo! I can do the impossible! Immovable objects? I juggle them like
rubber balls. Unstoppable forces? I don't even notice them. The very gods
themselves will fear me!
--
Chris Angelico :
> For low-level bit manipulation work, you usually want an *unsigned*
> integer of specific size, with well defined wrap-around behaviour.
> When do you actually want a signed integer with well-defined overflow
> behaviour?
Bit manipulation is not the issue here.
The reason for
On 2015-04-09, Chris Angelico wrote:
> On Fri, Apr 10, 2015 at 2:53 AM, Grant Edwards
> wrote:
>> On 2015-04-09, Chris Angelico wrote:
>>
>>> For application work, it's usually much better to have an integer
>>> type like Python's or Pike's int - a signed integer that can never
>>> overflow. Fo
On Fri, 10 Apr 2015 02:43 am, Chris Angelico wrote:
> For application work, it's usually much better to have an integer type
> like Python's or Pike's int - a signed integer that can never
> overflow. For low-level bit manipulation work, you usually want an
> unsigned integer of specific size, wit
On Fri, 10 Apr 2015 02:25 am, Marko Rauhamaa wrote:
> Chris Angelico :
>
>> As far as it's concerned, it's impossible for a CPU register to
>> arbitrarily change without notice. It's equally impossible for the
>> addition of two positive signed integers to result in a negative
>> integer.
>
> Th
On 2015-04-09, Chris Angelico wrote:
> For application work, it's usually much better to have an integer
> type like Python's or Pike's int - a signed integer that can never
> overflow. For low-level bit manipulation work, you usually want an
> *unsigned* integer of specific size, with well defin
On Fri, Apr 10, 2015 at 2:53 AM, Grant Edwards wrote:
> On 2015-04-09, Chris Angelico wrote:
>
>> For application work, it's usually much better to have an integer
>> type like Python's or Pike's int - a signed integer that can never
>> overflow. For low-level bit manipulation work, you usually w
On Fri, Apr 10, 2015 at 2:25 AM, Marko Rauhamaa wrote:
> Chris Angelico :
>
>> As far as it's concerned, it's impossible for a CPU register to
>> arbitrarily change without notice. It's equally impossible for the
>> addition of two positive signed integers to result in a negative
>> integer.
>
> T
On 2015-04-09 16:21, Steven D'Aprano wrote:
On Fri, 10 Apr 2015 01:02 am, Chris Angelico wrote:
On Fri, Apr 10, 2015 at 12:53 AM, Alain Ketterlin
wrote:
Ouch, you're right, I tried to stick with Marko's example and forgot the
basics. I meant "signed ints", but the "removable" condition should
On Fri, Apr 10, 2015 at 2:15 AM, Steven D'Aprano
wrote:
> On Fri, 10 Apr 2015 01:34 am, Chris Angelico wrote:
>
>> It's equally impossible for the addition of two positive signed
>> integers to result in a negative integer.
>
> Why oh why do C programmers tell such porkies??? *semi-wink*
>
> [stev
On Thu, Apr 9, 2015 at 9:21 AM, wrote:
> And i know for a fact
What do you know for a fact?
> (i've factored RSA in the 200 digit range on a 486 in a couple of hours 98-)
Bullshit. RSA-200 wasn't factored until 2005, and the group that did
it required three months on a cluster of 80 2.2-GHz Op
Chris Angelico :
> As far as it's concerned, it's impossible for a CPU register to
> arbitrarily change without notice. It's equally impossible for the
> addition of two positive signed integers to result in a negative
> integer.
The standard says that any program that takes a signed integer out
On 2015-04-09, Travis Griggs wrote:
>
>> On Apr 7, 2015, at 8:42 AM, Hugo Caldas wrote:
>>
>> read and write the port values with multi threading
>
> Care to elaborate what you mean by this part? In general, serial
> ports and multi threading don’t mix well. IOW, you’ll need to use
> multithre
On Fri, 10 Apr 2015 01:34 am, Chris Angelico wrote:
> It's equally impossible for the addition of two positive signed
> integers to result in a negative integer.
Why oh why do C programmers tell such porkies??? *semi-wink*
[steve@ando c]$ gcc add.c
[steve@ando c]$ ./a.out
a = 1
b = 2147483647
a+
> On Apr 4, 2015, at 4:43 PM, Damien George wrote:
>
> Hello everyone,
>
> We are pleased to announce the release of MicroPython version 1.4.1!
>
> MicroPython is an implementation of Python 3.4 which is optimised for
> systems with minimal resources, including microcontrollers.
>
> Since our
> On Apr 7, 2015, at 8:42 AM, Hugo Caldas wrote:
>
> read and write the port values with multi threading
Care to elaborate what you mean by this part? In general, serial ports and
multi threading don’t mix well. IOW, you’ll need to use multithreading pieces
to make sure you serialize your a
On Fri, Apr 10, 2015 at 1:21 AM, Steven D'Aprano
wrote:
> On Fri, 10 Apr 2015 01:02 am, Chris Angelico wrote:
>
>> On Fri, Apr 10, 2015 at 12:53 AM, Alain Ketterlin
>> wrote:
>>> Ouch, you're right, I tried to stick with Marko's example and forgot the
>>> basics. I meant "signed ints", but the "r
On Fri, Apr 10, 2015 at 1:11 AM, Steven D'Aprano
wrote:
> On Thu, 9 Apr 2015 11:33 pm, Marko Rauhamaa wrote:
>
>> In this day and age, heavily optimized compilers (including gcc)
>> actively exploit undefined behavior in code generation.
>
> Optimization and undefined behaviour reminds me of a sto
On Fri, 10 Apr 2015 01:02 am, Chris Angelico wrote:
> On Fri, Apr 10, 2015 at 12:53 AM, Alain Ketterlin
> wrote:
>> Ouch, you're right, I tried to stick with Marko's example and forgot the
>> basics. I meant "signed ints", but the "removable" condition should be
>> something like:
>>
>> if (
Den torsdag 9 april 2015 kl. 17:04:53 UTC+2 skrev Ian:
> On Thu, Apr 9, 2015 at 8:54 AM, wrote:
> > Aside from the base changer i've written a bignumb anybase generic
> > multiplication, addition and subtraction routine. My goal is to make the
> > arithmetic in the base of choice whatever size.
On Thu, 9 Apr 2015 11:33 pm, Marko Rauhamaa wrote:
> In this day and age, heavily optimized compilers (including gcc)
> actively exploit undefined behavior in code generation.
Optimization and undefined behaviour reminds me of a story my wife told me,
of a time she was crossing the US with some r
Den torsdag 9 april 2015 kl. 17:02:24 UTC+2 skrev Chris Angelico:
> On Fri, Apr 10, 2015 at 12:53 AM, Alain Ketterlin
> wrote:
> > Ouch, you're right, I tried to stick with Marko's example and forgot the
> > basics. I meant "signed ints", but the "removable" condition should be
> > something like:
On Thu, 9 Apr 2015 07:31 pm, Palpandi wrote:
> Hi all,
>
> Is there any way to roll back or undo changes which are all done before
> exception occurs.
Not automatically. You have to program it yourself.
--
Steven
--
https://mail.python.org/mailman/listinfo/python-list
On Thu, Apr 9, 2015 at 8:54 AM, wrote:
> Aside from the base changer i've written a bignumb anybase generic
> multiplication, addition and subtraction routine. My goal is to make the
> arithmetic in the base of choice whatever size.
>
> And i think i can do it, i already have mult, add , subt w
On Fri, Apr 10, 2015 at 12:53 AM, Alain Ketterlin
wrote:
> Ouch, you're right, I tried to stick with Marko's example and forgot the
> basics. I meant "signed ints", but the "removable" condition should be
> something like:
>
> if ( x>0 && y>0 && z ...
>
> i.e., some condition that is n
Chris Angelico writes:
> On Thu, Apr 9, 2015 at 11:57 PM, Alain Ketterlin
> wrote:
>> Because, in:
>>
>> z = x+y; // all signed ints
>> if ( z < x )
>> ...
>>
>> either there was no overflow (and the condition is false), or there was,
>> and the result is undefined, i.e., "z
> Do
Den torsdag 9 april 2015 kl. 16:08:48 UTC+2 skrev Chris Angelico:
> On Thu, Apr 9, 2015 at 11:57 PM, Alain Ketterlin
> wrote:
> > Because, in:
> >
> > z = x+y; // all signed ints
> > if ( z < x )
> > ...
> >
> > either there was no overflow (and the condition is false), or there wa
On Thursday, April 9, 2015 at 4:23:55 PM UTC+5:30, Tim Golden wrote:
> On 09/04/2015 11:25, wrote:
> > Dear Group,
> >
> > I was trying to convert .doc file to .txt file.
> >
> > I got of python-docx, zipfile but they do not seem to help me much.
> >
> > You may kindly suggest how to convert fro
On Thu, Apr 9, 2015 at 11:57 PM, Alain Ketterlin
wrote:
> Because, in:
>
> z = x+y; // all signed ints
> if ( z < x )
> ...
>
> either there was no overflow (and the condition is false), or there was,
> and the result is undefined, i.e., "zhttps://mail.python.org/mailman/listinfo/p
Marko Rauhamaa writes:
> Dave Angel :
>
>> So the C standard can specify such things as undefined. The
>> architecture still will do something specific, right or wrong, and
>> that's what Marko's claim was about. The C compiler has separate types
>> for unsigned and for signed, while the underlyi
Marko Rauhamaa :
> In this day and age, heavily optimized compilers (including gcc)
> actively exploit undefined behavior in code generation.
Example: Find the value of INT_MAX programmatically.
#include
int main()
{
Dave Angel :
> So the C standard can specify such things as undefined. The
> architecture still will do something specific, right or wrong, and
> that's what Marko's claim was about. The C compiler has separate types
> for unsigned and for signed, while the underlying architecture of
> every twos
Alain Ketterlin :
> Marko Rauhamaa writes:
>
>> Alain Ketterlin :
>>
>>> No, it would not work for signed integers (i.e., with lo and hi of
>>> int64_t type), because overflow is undefined behavior for signed.
>>
>> All architectures I've ever had dealings with have used 2's-complement
>> integer
On 04/09/2015 08:56 AM, Alain Ketterlin wrote:
Marko Rauhamaa writes:
Alain Ketterlin :
No, it would not work for signed integers (i.e., with lo and hi of
int64_t type), because overflow is undefined behavior for signed.
All architectures I've ever had dealings with have used 2's-complemen
Marko Rauhamaa writes:
> Alain Ketterlin :
>
>> No, it would not work for signed integers (i.e., with lo and hi of
>> int64_t type), because overflow is undefined behavior for signed.
>
> All architectures I've ever had dealings with have used 2's-complement
> integers. Overflow is well-defined,
Alain Ketterlin :
> No, it would not work for signed integers (i.e., with lo and hi of
> int64_t type), because overflow is undefined behavior for signed.
All architectures I've ever had dealings with have used 2's-complement
integers. Overflow is well-defined, well-behaved and sign-independent
w
On 04/09/2015 05:33 AM, janhein.vanderb...@gmail.com wrote:
Op donderdag 19 februari 2015 19:25:14 UTC+1 schreef Dave Angel:
I wrote the following pair of functions:
Here's a couple of ranges of output, showing that the 7bit scheme does
better for values between 384 and 16379.
Thanks fo
Marko Rauhamaa writes:
> The basic arithmetic algorithms are independent of the base.
Right.
> For example, here's how you can add two 128-bit integers in C using
> 64-bit digits:
>
> typedef struct {
> uint64_t lo, hi;
> } uint128_t;
>
> uint128_t add128(uint128_t x, uint12
On 2015-04-09 03:25, subhabrata.bane...@gmail.com wrote:
> You may kindly suggest how to convert from .doc
> to .docx/.html/.pdf/.rtf as from them I am being able to convert
> to .txt.
Use an external tool such as "wv", "antiword", or "catdoc" that has
already done the hard work for you.
-tkc
On Thursday, April 9, 2015 at 3:56:09 PM UTC+5:30, subhabrat...@gmail.com wrote:
> Dear Group,
>
> I was trying to convert .doc file to .txt file.
>
> I got of python-docx, zipfile but they do not seem to help me much.
>
> You may kindly suggest how to convert from .doc to .docx/.html/.pdf/.rt
On 09/04/2015 11:25, subhabrata.bane...@gmail.com wrote:
> Dear Group,
>
> I was trying to convert .doc file to .txt file.
>
> I got of python-docx, zipfile but they do not seem to help me much.
>
> You may kindly suggest how to convert from .doc to
> .docx/.html/.pdf/.rtf as from them I am bein
On Thu, Apr 9, 2015 at 7:31 PM, Palpandi wrote:
> Hi all,
>
> Is there any way to roll back or undo changes which are all done before
> exception occurs.
In Python itself? Not directly; there are no facilities for undoing
Python code. But if you're serious about integrity, you probably want
to b
Dear Group,
I was trying to convert .doc file to .txt file.
I got of python-docx, zipfile but they do not seem to help me much.
You may kindly suggest how to convert from .doc to .docx/.html/.pdf/.rtf as
from them I am being able to convert to .txt.
If any one of the Python experts may kind
kai.pet...@gmail.com wrote:
> I just wrote this bit (coming from Pascal)
> if (((xdim / 8) * ydim) + header) <> filesize:
Yeah, either Pascal or Barry Warsaw is your uncle ;)
https://www.python.org/dev/peps/pep-0401/
> and am wondering how seasoned
> Python programmers would have done the
BartC :
> On 08/04/2015 23:06, Marko Rauhamaa wrote:
>> Arithmetics is performed just like in elementary school.
>
> Not in the school I went to; we used decimal!
The basic arithmetic algorithms are independent of the base.
For example, here's how you can add two 128-bit integers in C using
64-b
Op donderdag 19 februari 2015 19:25:14 UTC+1 schreef Dave Angel:
> I wrote the following pair of functions:
>
> def seven_code(n):
> acc = bytearray()
> if n == 0:
> acc.append(0)
> while n > 0:
> quotient, remainder = divmod(n, 128)
> acc.append(remainder
Hi all,
Is there any way to roll back or undo changes which are all done before
exception occurs.
--
https://mail.python.org/mailman/listinfo/python-list
On 08/04/2015 23:06, Marko Rauhamaa wrote:
BartC :
So the the number 3,012,345, in base 100, could represented in
text form as the two 'digit':
(3, 12345)
ie. 3*100 + 12345*1. In internal binary, each digit can just be
stored in the normal form, probably as one digit per 32-bit inte
Op donderdag 19 februari 2015 19:05:12 UTC+1 schreef Ian:
> That stop-bit variant looks extremely inefficient (and wrong) to me.
You are right; I was wrong.
> encoding with just a small amount of binary at the end. This is what I
> would expect a 2-bit stop-bit encoding to look like:
>
> 0: 00
>
On 08.04.15 16:23, Mattias Ugelvik wrote:
I'm making a string manipulation tool in which I need to know this correlation.
Take this example: re.match('(?Pa?)(?Pb?)', '')
I need to know that 'first' is group #1, and 'second' is group #2. I
need this to resolve certain ambiguities. I was hopin
On 03/28/2015 11:43 AM, Steven D'Aprano wrote:
> On Sat, 28 Mar 2015 08:53 pm, Steven D'Aprano wrote:
>
>
>> It saves typing. It might even allow a micro-optimization in the generated
>> bytecode (see below).
> Oops, I forgot to include the "see below" bit.
>
> Comparing
>
> a = a.spam()
>
> a .=
(sorry if I'm spamming the mailing list, my reply didn't seem to show
up in the archive)
I'm making a 'declarative string manipulation' tool, the interface of
which should work like this:
>>> rules(r'(?P(?Pa?))(?Pb?)', {
... 'separate': '.suffix',
... 'inner': 'abc',
... 'outer': lambda str
I'm making a 'declarative string manipulation' tool, the interface of
which should work like this:
>>> rules(r'(?P(?Pa?))(?Pb?)', {
... 'separate': '.suffix',
... 'inner': 'abc',
... 'outer': lambda string: 'some-{}-manipulation'.format(string)
... }).apply('a')
'some-abc-manipulation.suffix
71 matches
Mail list logo
