Re: how to make format operator % work with unicode as expected

[John Machin]

On Jan 27, 3:06 pm, "Peter Pei" <[EMAIL PROTECTED]> wrote:
> I probably should mention that what I want is to make all parts of the
> string aligned, and look like table. I am not looking for other ways to make
> it table-alike, but only interested in making % work with unicode -counting
> characters not bytes...

Can you show some *code* that demonstrates the alleged problem?
E.g. len("" % some_unicode) != expected_len

Reading this may help:
http://www.chiark.greenend.org.uk/~sgtatham/bugs.html

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Using a dict as if it were a module namespace

[thebjorn]

On Jan 27, 8:45 am, Steven D'Aprano <[EMAIL PROTECTED]
cybersource.com.au> wrote:
> I have a problem which I think could be solved by using a dict as a
> namespace, in a similar way that exec and eval do.
>
> When using the timeit module, it is very inconvenient to have to define
> functions as strings. A good alternative is to create the function as
> normal, and import it:
>
> def myfunc(x, y):
> return x+y
>
> timeit.Timer("myfunc(59, 60)", "from __main__ import myfunc").timeit()
>
> Not only is this an easy idiom to follow, but myfunc can live in another
> module: just replace __main__ with the module name.
>
> Now, I'm trying to build a suite of tests to use with timeit. I have a
> bunch of tests which I've created as dicts:
>
> test_suite= [dict(x=59, y=60), dict(x=-1, y=-2)]
>
> What I *think* I want to do is use the from ... import idiom to grab
> arguments from the dicts as if they were modules, but this doesn't work:
>
> expr = "myfunc(x, y)"
> for test in test_suite:
> setup = "from __main__ import myfunc; from test import x, y"
> t = timeit.Timer(expr, setup).timeit()
>
> Even if the Timer could see test, it is not a module and you can't import
> from it. Naturally.
>
> Alternatives that I have found:
>
> (1) Import the test and grab the values needed from it:
>
> setup = """from __main__ import myfunc, test
> x, y = test['x'], test['y']"""
>
> I don't like this one. It doesn't seem very elegant to me, and it gets
> unwieldy as the complexity increases. Every item I need from test has to
> be named twice, violating the principle Don't Repeat Yourself. If the
> tests change, the setup string has to be explicitly changed also.
>
> (2) Mess with the global namespace:
>
> globals().update(t)
> setup = "from __main__ import myfunc"
>
> I don't like this one. It looks hackish, and I worry about conflicts and
> side-effects. If it works (and I haven't tested it) it relies on an
> implementation detail of timeit.Timer.__init__, namely the line
> "exec code in globals(), ns". Worst of all, it pollutes or even mangles
> the global namespace of the calling code, not the code being tested.
>
> (3) Explicitly pass a namespace dict to the Timer class, possibly even
> getting rid of setup altogether:
>
> test['myfunc'] = myfunc
> t = timeit.Timer(expr, '', ns=test).timeit()
>
> This would be the most elegant solution, but at this time it is
> completely hypothetical. Timer does not have that functionality.
>
> (4) Dump the test data straight into the setup string:
>
> setup = "from __main__ import myfunc; x = %(x)s; y = %(y)s" % t
>
> Again, unwieldy and against DRY. The additional disadvantage is that
> there are many types of test data that can't be converted to and from
> strings like that.
>
> What do others think? Have I missed something? What other alternatives
> are there?
>
> --
> Steven

You might have lost me, but wouldn't it be easier to do some variation
on this

test_suite = [
'(x=59, y=60)',  # either have strings here...
'(x=-1, y=-2)',
]

for test in test_suite:
# ... or convert the dicts to appropriate strings here...
expr = 'myfunc' + test
t = timeit.Timer(expr, 'from __main__ import myfunc').timeit()
...

-- bjorn
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: file write question

[thebjorn]

On Jan 27, 4:02 am, "Robb Lane (SL name)" <[EMAIL PROTECTED]> wrote:
> I have written a script which:
> - opens a file
> - does what it needs to do, periodically writing to the file... for a
> few hours
> - then closes the file when it's done
> So my question is:
> Would it be better to 'open' and 'close' my file on each write cycle?
> e.g.
> def writeStuff(content):
>  myFile = open('aFile.txt', 'a+')
>  myFile.write(content)
>  myFile.close()
>
> ... or just leave it till it's done?
> I don't need to use the file contents until the script is done
> (although it would be nice... just to check it while it's working), so
> just curious what people think is the better method.
> - rd

Sounds like a classic case for a database to me (long running process
producing sporadic output that you might want to tinker with as it's
being produced). Python 2.5 comes with sqlite3 included...

-- bjorn
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: how to make format operator % work with unicode as expected

[Stefan Behnel]

Ever heard the word "PLONK"?

Peter Pei harshly top-posted:
> You didn't understand my question, but thanks any way.
> 
> Yes, it is true that %s already support unicode, and I did not
> contradict that. But it counts the number of bytes instead of
> characters, and makes things like %-20s out of alignment. If you don't
> understand my assertion, please don't argue back and I am only
> interested in answers from those who are qualified.
> ==
> 
> "Steven D'Aprano" <[EMAIL PROTECTED]> wrote
[pretty qualifying response stripped]
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: translating Python to Assembler

[over]

On Fri, 25 Jan 2008 17:36:06 -0800 (PST), ajaksu <[EMAIL PROTECTED]>
wrote:

>On Jan 25, 11:10 pm, [EMAIL PROTECTED] wrote:
>> Once a python py file is compiled into a pyc file, I can disassemble
>> it into assembler. Assembler is nothing but codes, which are
>> combinations of 1's and 0's. You can't read a pyc file in a hex
>> editor, but you can read it in a disassembler. It doesn't make a lot
>> of sense to me right now, but if I was trying to trace through it with
>> a debugger, the debugger would disassemble it into assembler, not
>> python.
>
>


>Please, tell me you're kidding...

hehe...which part am I kidding about? The explanation was for someone
who thought python scripts were translated directly by the processor.
I had no idea how much he knew, so I kept it basic (no pun intended). 

Or...do you disagree with what I'm saying? You didn't say much. I have
already disassembled a pyc file as a binary file. Maybe I was using
the term assembler too broadly. A binary compiled from an assembler
source would look similar in parts to what I disassembled. 

That's not the point, however. I'm trying to say that a processor
cannot read a Python script, and since the Python interpreter as
stored on disk is essentially an assembler file, any Python script
must be sooner or later be converted to assembler form in order to be
read by its own interpreter. Whatever is typed in a Python script must
be converted to binary code.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: translating Python to Assembler

[over]

On Fri, 25 Jan 2008 17:44:07 -0800 (PST), ajaksu <[EMAIL PROTECTED]>
wrote:

>On Jan 25, 11:36 pm, ajaksu <[EMAIL PROTECTED]> wrote:
>> On Jan 25, 11:10 pm, [EMAIL PROTECTED] wrote:
>[...]
>
>Gaah, is this what's going on?
>
>[EMAIL PROTECTED]:~$ cat error.txt
>This is not assembler...
>
>[EMAIL PROTECTED]:~$ ndisasm error.txt
>  54push sp
>0001  686973push word 0x7369
>0004  206973and [bx+di+0x73],ch
>0007  206E6Fand [bp+0x6f],ch
>000A  7420  jz 0x2c
>000C  61popa
>000D  7373  jnc 0x82
>000F  656D  gs insw
>0011  626C65bound bp,[si+0x65]
>0014  722E  jc 0x44
>0016  2Edb 0x2E
>0017  2Edb 0x2E
>0018  0Adb 0x0A
>
>:/

not sure what you're saying. Sure looks like assembler to me. Take the
'54   push sp'. The 54 is an assembler opcode for push and the sp is
the stack pointer, on which it is operating. 
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: translating Python to Assembler

[thebjorn]

On Jan 27, 9:58 am, [EMAIL PROTECTED] wrote:
> On Fri, 25 Jan 2008 17:44:07 -0800 (PST), ajaksu <[EMAIL PROTECTED]>
> wrote:
>
>
>
> >On Jan 25, 11:36 pm, ajaksu <[EMAIL PROTECTED]> wrote:
> >> On Jan 25, 11:10 pm, [EMAIL PROTECTED] wrote:
> >[...]
>
> >Gaah, is this what's going on?
>
> >[EMAIL PROTECTED]:~$ cat error.txt
> >This is not assembler...
>
> >[EMAIL PROTECTED]:~$ ndisasm error.txt
> >  54push sp
> >0001  686973push word 0x7369
> >0004  206973and [bx+di+0x73],ch
> >0007  206E6Fand [bp+0x6f],ch
> >000A  7420  jz 0x2c
> >000C  61popa
> >000D  7373  jnc 0x82
> >000F  656D  gs insw
> >0011  626C65bound bp,[si+0x65]
> >0014  722E  jc 0x44
> >0016  2Edb 0x2E
> >0017  2Edb 0x2E
> >0018  0Adb 0x0A
>
> >:/
>
> not sure what you're saying. Sure looks like assembler to me. Take the
> '54   push sp'. The 54 is an assembler opcode for push and the sp is
> the stack pointer, on which it is operating.

go troll somewhere else (you obviously don't know anything about
assembler and don't want to learn anything about Python).

-- bjorn
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: translating Python to Assembler

[Steven D'Aprano]

On Sun, 27 Jan 2008 08:58:01 +, over wrote:

> On Fri, 25 Jan 2008 17:44:07 -0800 (PST), ajaksu <[EMAIL PROTECTED]>
> wrote:
> 
>>On Jan 25, 11:36 pm, ajaksu <[EMAIL PROTECTED]> wrote:
>>> On Jan 25, 11:10 pm, [EMAIL PROTECTED] wrote:
>>[...]
>>
>>Gaah, is this what's going on?
>>
>>[EMAIL PROTECTED]:~$ cat error.txt
>>This is not assembler...
>>
>>[EMAIL PROTECTED]:~$ ndisasm error.txt
>>  54push sp
>>0001  686973push word 0x7369 0004  206973   
>>and [bx+di+0x73],ch 0007  206E6Fand [bp+0x6f],ch
>>000A  7420  jz 0x2c
>>000C  61popa
>>000D  7373  jnc 0x82
>>000F  656D  gs insw
>>0011  626C65bound bp,[si+0x65] 0014  722E   
>>  jc 0x44
>>0016  2Edb 0x2E
>>0017  2Edb 0x2E
>>0018  0Adb 0x0A
>>
>>:/
> 
> not sure what you're saying. Sure looks like assembler to me. Take the
> '54   push sp'. The 54 is an assembler opcode for push and the sp is the
> stack pointer, on which it is operating.


Deary deary me...

Have a close look again at the actual contents of the file:

$ cat error.txt
This is not assembler...


If you run the text "This is not assembler..." through a disassembler, it 
will obediently disassemble the bytes "This is not assembler..." into a 
bunch of assembler opcodes. Unfortunately, although the individual 
opcodes are "assembly", the whole set of them together is nonsense. 
You'll see that it is nonsense the moment you try to execute the supposed 
assembly code.

It would be a fascinating exercise to try to generate a set of bytes 
which could be interpreted as both valid assembly code *and* valid 
English text simultaneously. For interest, here you will find one quine 
(program which prints its own source code) which is simultaneously valid 
in C and TCL, and another which is valid in C and Lisp:

http://www.uwm.edu/~chruska/recursive/selfish.html



-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Sorting Large File (Code/Performance)

[Stefan Behnel]

Gabriel Genellina wrote:
> use the Windows sort command. It has been
> there since MS-DOS ages, there is no need to download and install other
> packages, and the documentation at
> http://technet.microsoft.com/en-us/library/bb491004.aspx says:
> 
> Limits on file size:
>   The sort command has no limit on file size.

Sure, since no-one can ever try it with more than 640k, it's easy to state
that there is no limit. :)

Stefan

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: how to make format operator % work with unicode as expected

[Marc 'BlackJack' Rintsch]

On Sun, 27 Jan 2008 05:32:40 +, Peter Pei wrote:

> You didn't understand my question, but thanks any way.
> 
> Yes, it is true that %s already support unicode, and I did not contradict 
> that. But it counts the number of bytes instead of characters, and makes 
> things like %-20s out of alignment. If you don't understand my assertion, 
> please don't argue back and I am only interested in answers from those who 
> are qualified.

I have the impression from your original post

  […] because it is unicode, and one byte is not neccessary one character.

that you confuse unicode and utf-8.  Are you sure you are qualified to ask
such a question in the first place!?  :-þ

Ciao,
Marc 'BlackJack' Rintsch
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Some questions about decode/encode

[glacier]

On 1月24日, 下午5时51分, John Machin <[EMAIL PROTECTED]> wrote:
> On Jan 24, 2:49 pm, glacier <[EMAIL PROTECTED]> wrote:
>
> > I use chinese charactors as an example here.
>
> > >>>s1='你好吗'
> > >>>repr(s1)
>
> > "'\\xc4\\xe3\\xba\\xc3\\xc2\\xf0'"
>
> > >>>b1=s1.decode('GBK')
>
> > My first question is : what strategy does 'decode' use to tell the way
> > to seperate the words. I mean since s1 is an multi-bytes-char string,
> > how did it determine to seperate the string every 2bytes or 1byte?
>
> The usual strategy for encodings like GBK is:
> 1. If the current byte is less than 0x80, then it's a 1-byte
> character.
> 2. Current byte 0x81 to 0xFE inclusive: current byte and the next byte
> make up a two-byte character.
> 3. Current byte 0x80: undefined (or used e.g. in cp936 for the 1-byte
> euro character)
> 4: Current byte 0xFF: undefined
>
> Cheers,
> John

Thanks John, I will try to write a function to test if the strategy
above caused the problem I described in the 1st post:)

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Sorting Large File (Code/Performance)

[Grant Edwards]

On 2008-01-27, Stefan Behnel <[EMAIL PROTECTED]> wrote:
> Gabriel Genellina wrote:
>> use the Windows sort command. It has been
>> there since MS-DOS ages, there is no need to download and install other
>> packages, and the documentation at
>> http://technet.microsoft.com/en-us/library/bb491004.aspx says:
>> 
>> Limits on file size:
>>   The sort command has no limit on file size.
>
> Sure, since no-one can ever try it with more than 640k, it's
> easy to state that there is no limit. :)

Huh?  I used DOS sort to sort files much bigger than 640K.  And
I used the Unix sort command on a machine with 64K bytes of
data space to sort files even larger than the ones under DOS.

-- 
Grant

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Some questions about decode/encode

[glacier]

On 1月24日, 下午3时29分, "Gabriel Genellina" <[EMAIL PROTECTED]> wrote:
> En Thu, 24 Jan 2008 04:52:22 -0200, glacier <[EMAIL PROTECTED]> escribió:
>
> > According to your reply, what will happen if I try to decode a long
> > string seperately.
> > I mean:
> > ##
> > a='你好吗'*10
> > s1 = u''
> > cur = 0
> > while cur < len(a):
> > d = min(len(a)-i,1023)
> > s1 += a[cur:cur+d].decode('mbcs')
> > cur += d
> > ##
>
> > May the code above produce any bogus characters in s1?
>
> Don't do that. You might be splitting the input string at a point that is  
> not a character boundary. You won't get bogus output, decode will raise a  
> UnicodeDecodeError instead.
> You can control how errors are handled, see  
> http://docs.python.org/lib/string-methods.html#l2h-237
>
> --
> Gabriel Genellina

Thanks Gabriel,

I guess I understand what will happen if I didn't split the string at
the character's boundry.
I'm not sure if the decode method will miss split the boundry.
Can you tell me then ?

Thanks a lot.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Some questions about decode/encode

[glacier]

On 1月24日, 下午4时44分, Marc 'BlackJack' Rintsch <[EMAIL PROTECTED]> wrote:
> On Wed, 23 Jan 2008 19:49:01 -0800, glacier wrote:
> > My second question is: is there any one who has tested very long mbcs
> > decode? I tried to decode a long(20+MB) xml yesterday, which turns out
> > to be very strange and cause SAX fail to parse the decoded string.
>
> That's because SAX wants bytes, not a decoded string.  Don't decode it
> yourself.
>
> > However, I use another text editor to convert the file to utf-8 and
> > SAX will parse the content successfully.
>
> Because now you feed SAX with bytes instead of a unicode string.
>
> Ciao,
> Marc 'BlackJack' Rintsch

Yepp. I feed SAX with the unicode string since SAX didn't support my
encoding system(GBK).

Is there any way to solve this better?
I mean if I shouldn't convert the GBK string to unicode string, what
should I do to make SAX work?

Thanks , Marc.
:)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Index of maximum element in list

[bearophileHUGS]

bearophile:
> That version is easy to translate to other languages and you can
> probably find that Psyco makes it much faster still.

That operation is quite common, so it deserves a bit more work:
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/543271

(I can show you the D/C code if you want it. The C code is just for
testing, while the D code is usable).

The final sum: the Psyco version is almost 40 times faster than the
Python version, and just 2.8 times slower than the D version, and 3.4
times slower than a C version (that doesn't use too many pointer
tricks). I think this is good enough.

Bye,
bearophile
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Sorting Large File (Code/Performance)

[Marc 'BlackJack' Rintsch]

On Sun, 27 Jan 2008 10:00:45 +, Grant Edwards wrote:

> On 2008-01-27, Stefan Behnel <[EMAIL PROTECTED]> wrote:
>> Gabriel Genellina wrote:
>>> use the Windows sort command. It has been
>>> there since MS-DOS ages, there is no need to download and install other
>>> packages, and the documentation at
>>> http://technet.microsoft.com/en-us/library/bb491004.aspx says:
>>> 
>>> Limits on file size:
>>>   The sort command has no limit on file size.
>>
>> Sure, since no-one can ever try it with more than 640k, it's
>> easy to state that there is no limit. :)
> 
> Huh?  I used DOS sort to sort files much bigger than 640K.

That was an allusion to a quote misattributed to Bill Gates about DOS:

  640K ought to be enough for anybody.

http://en.wikiquote.org/wiki/Bill_Gates#Misattributed

Ciao,
Marc 'BlackJack' Rintsch
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: translating Python to Assembler

[Bjoern Schliessmann]

[EMAIL PROTECTED] wrote:

> hehe...which part am I kidding about? The explanation was for
> someone who thought python scripts were translated directly by the
> processor. 

Who might this have been? Surely not Tim.

> I have already disassembled a pyc file as a binary file. 

Have you? How's it look?

> Maybe I was using the term assembler too broadly. A binary
> compiled from an assembler source would look similar in parts to
> what I disassembled.

What is this supposed to mean?

> That's not the point, however. I'm trying to say that a processor
> cannot read a Python script, and since the Python interpreter as
> stored on disk is essentially an assembler file, 

It isn't; it's an executable.

> any Python script must be sooner or later be converted to
> assembler form in order to be read by its own interpreter.

This "assembler form" is commonly referred to as "Python byte code".

> Whatever is typed in a Python script must be converted to binary
> code. 

That, however, is true, though blurred.

Regards,


Björn

-- 
BOFH excuse #120:

we just switched to FDDI.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Some questions about decode/encode

[Marc 'BlackJack' Rintsch]

On Sun, 27 Jan 2008 02:18:48 -0800, glacier wrote:

> Yepp. I feed SAX with the unicode string since SAX didn't support my
> encoding system(GBK).

If the `decode()` method supports it, IMHO SAX should too.

> Is there any way to solve this better?
> I mean if I shouldn't convert the GBK string to unicode string, what
> should I do to make SAX work?

Decode it and then encode it to utf-8 before feeding it to the parser.

Ciao,
Marc 'BlackJack' Rintsch
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Index of maximum element in list

[Paul Rubin]

[EMAIL PROTECTED] writes:
> The final sum: the Psyco version is almost 40 times faster than the
> Python version, and just 2.8 times slower than the D version, and 3.4
> times slower than a C version (that doesn't use too many pointer
> tricks). I think this is good enough.

I can't help wishing that psyco could do as good a job with the
simpler expressions of that function.  I'll have to see what JHC does.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: translating Python to Assembler

[over]

On Sat, 26 Jan 2008 14:47:50 +0100, Bjoern Schliessmann
<[EMAIL PROTECTED]> wrote:

>[EMAIL PROTECTED] wrote:
>
>> Intel processors can only process machine language[...] There's no
>> way for a processor to understand any higher level language, even
>> assembler, since it is written with hexadecimal codes and basic
>> instructions like MOV, JMP, etc. The assembler compiler can
>> convert an assembler file to a binary executable, which the
>> processor can understand.
>
>This may be true, but I think it's not bad to assume that machine
>language and assembler are "almost the same" in this context, since
>the translation between them is non-ambiguous (It's
>just "recoding"; this is not the case with HLLs).

I have no problem with your explanation. It's nearly impossible to
program in machine code, which is all 1's and 0's. Assembler makes it
infinitely easier by converting the machine 1's and 0's to their
hexadecimal equivalent and assigning an opcode name to them, like
PUSH, MOV, CALL, etc.

Still, the older machine-programmable processors used switches to set
the 1's and 0's. Or, the machine code was fed in on perforated cards
or tapes that were read. The computer read the switches, cards or
tapes, and set voltages according to what it scanned.

the difference is that machine code can be read directly, whereas
assembler has to be compiled in order to convert the opcodes to binary
data.

>
>> Both Linux and Windows compile down to binary files, which are
>> essentially 1's and 0's arranged in codes that are meaningful to
>> the processor.
>
>(Not really -- object code files are composed of header data and
>different segments, data and code, and only the code segments are
>really meaningful to the processor.)

I agree that the code segments, and the data, are all that's
meaningful to the processor. There are a few others, like interrupts
that affect the processor directly. 

I understand what you're saying but I'm refering to an executable file
ready to be loaded into memory. It's stored on disk in a series of 1's
and 0's. As you say, there are also control codes on disk to separate
each byte along with CRC codes, timing codes, etc. However, that is
all stripped off by the hard drive electronics. 

The actual file on disk is in a certain format that only the operating
system understands. But once the code is read in, it goes into memory
locations which hold individual arrays of bits. Each memory location
holds a precise number of bits corresponding to the particular code it
represents.  For example, the ret instruction you mention below is
represent by hex C3 (0xC3), which represents the bits 1111. 

That's a machine code, since starting at  to , you
have 256 different codes available. When those 1's and 0's are
converted to volatges, the computer can analyze them and set circuits
in action which will bring about the desired operation. Since Linux is
written in C, it must convert down to machine code, just as Windows
must. 

>
>> Once a python py file is compiled into a pyc file, I can
>> disassemble it into assembler. 
>
>But you _do_ know that pyc files are Python byte code, and you could
>only directly disassemble them to Python byte code directly?

that's the part I did not understand, so thanks for pointing that out.
What I disassembled did not make sense. I was looking for assembler
code, but I do understand a little bit about how the interpreter reads
them. 

For example, from os.py, here's part of the script:

# Note:  more names are added to __all__ later.
__all__ = ["altsep", "curdir", "pardir", "sep", "pathsep", "linesep",
   "defpath", "name", "path", "devnull"]

here's the disassembly from os.pyc:

0C0406 00 00 00 dd 6
0C0861 6C 74 73 65 70 74 db 'altsept'
0C0F06 00 00 00 dd 6
0C1363 75 72 64 69 72 74db 'curdirt'
0C1A06 00 00 00 dd 6
0C1E70 61 72 64 69 72 74 db 'pardirt'
0C2503 00 00 00  dd 3
0C2973 65 70db 'sep'
0C2C74 07 00 00 dd 774h
0C3000  db0
0C3170 61 74 68 73 65 70db 'pathsep'
0C3874 07 00 00 dd 774h
0C3C00   db0
0C3D6C 69 6E 65 73 65 70db 'linesep'
0C4474 07 00 00 dd 774h
0C4800  db0
0C4964 65 66 70 61 74 68db 'defpath'
0C5074 04 00 00 dd offset unk_474
0C5400  db0
0C556E 61 6D 65 db 'name'
0C5974 04 00 00 dd offset unk_474
0C5D00  db0

Re: Some questions about decode/encode

[John Machin]

On Jan 27, 9:18 pm, glacier <[EMAIL PROTECTED]> wrote:
> On 1月24日, 下午4时44分, Marc 'BlackJack' Rintsch <[EMAIL PROTECTED]> wrote:
>
> > On Wed, 23 Jan 2008 19:49:01 -0800, glacier wrote:
> > > My second question is: is there any one who has tested very long mbcs
> > > decode? I tried to decode a long(20+MB) xml yesterday, which turns out
> > > to be very strange and cause SAX fail to parse the decoded string.
>
> > That's because SAX wants bytes, not a decoded string.  Don't decode it
> > yourself.
>
> > > However, I use another text editor to convert the file to utf-8 and
> > > SAX will parse the content successfully.
>
> > Because now you feed SAX with bytes instead of a unicode string.
>
> > Ciao,
> > Marc 'BlackJack' Rintsch
>
> Yepp. I feed SAX with the unicode string since SAX didn't support my
> encoding system(GBK).

Let's go back to the beginning. What is "SAX"? Show us exactly what
command or code you used.

How did you let this SAX know that the file was encoded in GBK? An
argument to SAX? An encoding declaration in the first few lines of the
file? Some other method? ... precise answer please. Or did you expect
that this SAX would guess correctly what the encoding was without
being told?

What does "didn't support my encoding system" mean? Have you actually
tried pushing raw undecoded GBK at SAX using a suitable documented
method of telling SAX that the file is in fact encoded in GBK? If so,
what was the error message that you got?

How do you know that it's GBK, anyway? Have you considered these
possible scenarios:
(1) It's GBK but you are telling SAX that it's GB2312
(2) It's GB18030 but you are telling SAX it's GBK

HTH,
John
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Some questions about decode/encode

[John Machin]

On Jan 27, 9:17 pm, glacier <[EMAIL PROTECTED]> wrote:
> On 1月24日, 下午3时29分, "Gabriel Genellina" <[EMAIL PROTECTED]> wrote:
>
>
>
> > En Thu, 24 Jan 2008 04:52:22 -0200, glacier <[EMAIL PROTECTED]> escribió:
>
> > > According to your reply, what will happen if I try to decode a long
> > > string seperately.
> > > I mean:
> > > ##
> > > a='你好吗'*10
> > > s1 = u''
> > > cur = 0
> > > while cur < len(a):
> > > d = min(len(a)-i,1023)
> > > s1 += a[cur:cur+d].decode('mbcs')
> > > cur += d
> > > ##
>
> > > May the code above produce any bogus characters in s1?
>
> > Don't do that. You might be splitting the input string at a point that is
> > not a character boundary. You won't get bogus output, decode will raise a
> > UnicodeDecodeError instead.
> > You can control how errors are handled, see  
> > http://docs.python.org/lib/string-methods.html#l2h-237
>
> > --
> > Gabriel Genellina
>
> Thanks Gabriel,
>
> I guess I understand what will happen if I didn't split the string at
> the character's boundry.
> I'm not sure if the decode method will miss split the boundry.
> Can you tell me then ?
>
> Thanks a lot.

*IF* the file is well-formed GBK, then the codec will not mess up when
decoding it to Unicode. The usual cause of mess is a combination of a
human and a text editor :-)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: translating Python to Assembler

[over]

>
>> That's not the point, however. I'm trying to say that a processor
>> cannot read a Python script, and since the Python interpreter as
>> stored on disk is essentially an assembler file, 
>
>It isn't; it's an executable.

I appreciated the intelligent response I received from you earlier,
now we're splitting hairs.  :-)  Assembler, like any other higher
level language is written as a source file and is compiled to a
binary. An executable is one form of a binary, as is a dll. When you
view the disassembly of a binary, there is a distinct difference
between C, C++, Delphi, Visual Basic, DOS, or even between the
different file types like PE, NE, MZ, etc. But they all decompile to
assembler. 

While they are in the binary format, they are exactly that...binary.
Who would want to interpret a long string of 1's and 0's. Binaries are
not stored in hexadecimal on disk nor are they in hexadecimal in
memory. But, all the 1's and 0's are in codes when they are
instructions or ASCII strings. No other high level language has the
one to one relationship that assembler has to machine code, the actual
language of the computer. 

Dissassemblers can easily convert a binary to assembler due to the one
to one relationship between them. That can't be said for any other
higher level language. Converting back to C or Python would be a
nightmare, although it's becoming a reality. Converting a compiled
binary back to hexadecimal is basically a matter of converting the
binary to hexadecimal, as in a hex editor. There are exceptions to
that, of course, especially with compound assembler statements that
use extensions to differentiate between registers. 


>
>> any Python script must be sooner or later be converted to
>> assembler form in order to be read by its own interpreter.
>
>This "assembler form" is commonly referred to as "Python byte code".
>
thanks for pointing that out. It lead me to this page:

http://docs.python.org/lib/module-dis.html

where it is explained that the opcodes are in Include/opcode.h. I'll
take a look at that. 

The light goes on. From opcode.h:

#define PRINT_NEWLINE_TO 74

All the ASCIi strings end with 0x74 in the disassembly. I have noted
that Python uses a newline as a line feed/carriage return. Now I'm
getting it. It could all be disassembled with a hex editor, but a
disassembler is better for getting things in order. 

OK. So the pyc files use those defs...that's cool. 
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Index of maximum element in list

[Arnaud Delobelle]

On Jan 26, 10:07 pm, Steven D'Aprano <[EMAIL PROTECTED]
cybersource.com.au> wrote:
> On Sat, 26 Jan 2008 12:40:26 -0800, Paul Rubin wrote:
> > [EMAIL PROTECTED] writes:
> >> > def posmax(seq, key=lambda x:x):
> >> >    return max(enumerate(seq), key=lambda k: key(k[1]))[0]
>
> >> Is the Python max able to tell that's the identity function? I don't
> >> think so, so your version may be slower and more memory hungry in the
> >> common situation where you don't have a key function. So I think my
> >> version is better :-)
>
> > I don't think there will be a noticable memory increase.  It's not a DSU
> > situation like in sorting, it's just a small constant parameter. Yes
> > there might be a small speed hit.  The compiler in principle could
> > convert the (lambda k: lambda x: k[1]) to something like
> > operator.itemgetter(1), but I doubt that it actually does so.
>
> Actually there is a big speed hit. Until such time that Python has a fast
> identity function, and lambda x:x isn't it, your version is about three
> times slower than Bearophile's.
>
> Much to my surprise, the fastest solution I've tried appears to be a pure
> Python version not even using max() at all.
>
> Here are the three versions:
>
> def posmax1(seq, key=None):  # bearophile's version
>     """Return the position of the first maximum item of a sequence.
>     It accepts the usual key parameter too."""
>     if key:
>         return max(enumerate(seq), key=lambda k: key(k[1]))[0]
>     else:
>         return max(enumerate(seq), key=itemgetter(1))[0]
>
> def posmax2(seq, key=lambda x:x):  # Paul Rubin's version
>     return max(enumerate(seq), key=lambda k: key(k[1]))[0]
>
> def posmax3(seq, key=None):  # Pure Python version
>     if key is None:
>         m = seq[0]
>         index = 0
>         for i, x in enumerate(seq):
>             if x > m:
>                 m = x
>                 index = i
>         return index
>     else:
>         return NotImplemented
>
> And my timing results:
>
> >>> alist = [3]*1000 + [5] + [3]*1000
> >>> assert alist.index(5) == 1000
> >>> assert posmax1(alist) == posmax2(alist) == posmax3(alist) == 1000
>
> >>> min(timeit.Timer('posmax1(alist)',
>
> ...     'from __main__ import posmax1, alist').repeat(number=1000))/1000
> 0.00074387979507446289>>> min(timeit.Timer('posmax2(alist)',
>
> ...     'from __main__ import posmax2, alist').repeat(number=1000))/1000
> 0.0022983889579772949>>> min(timeit.Timer('posmax3(alist)',
>
> ...     'from __main__ import posmax3, alist').repeat(number=1000))/1000
> 0.00063846302032470701
>
> --
> Steven

I don't think one should dismiss the simplest solution l.index(max(l))
out of hand (benchmark function borrowed from bearophile):

=== posmax.py ==
from operator import itemgetter

def simple_posmax(l, key=None):
if key:
return l.index(max(l, key=key))
else:
return l.index(max(l))

def clever_posmax(seq, key=None):
if key:
return max(enumerate(seq), key=lambda k: key(k[1]))[0]
else:
return max(enumerate(seq), key=itemgetter(1))[0]

def posmax_benchmark(posmax):
from time import clock
alist = [3]*1000 + [5] + [3]*1000

t = clock()
for _ in xrange(6000):
r = posmax(alist)
print posmax.__name__, round(clock() - t, 2), r

if __name__ == "__main__":
posmax_benchmark(clever_posmax)
posmax_benchmark(simple_posmax)
=

marigold:python arno$ python posmax.py
clever_posmax 3.25 1000
simple_posmax 0.95 1000

simple_posmax is more than 3x faster on my machine.  It's not
surprising as even though the list is walked twice, it is all done in
C and no new objects have to be created. Then only non-C bit is when
the result of max(l) is fed to l.index().

--
Arnaud


-- 
http://mail.python.org/mailman/listinfo/python-list

python regex: misbehaviour with "\r" (0x0D) as Newline character in Unicode Mode

[Arian Sanusi]

Hi,

concerning to unicode, "\n", "\r "and "\r\n" (0x000A, 0x000D and 
0x000D+0x000A) should be threatened as newline character
at least this is how i understand it: 
(http://en.wikipedia.org/wiki/Newline#Unicode)

obviously, the re module does not care, and on unix, only threatens \n 
as newline char:

 >>> a=re.compile(u"^a",re.U|re.M)
 >>> a.search(u"bc\ra")
 >>> a.search(u"bc\na")
<_sre.SRE_Match object at 0xb5908fa8>

same thing for $:
 >>> b = re.compile(u"c$",re.U|re.M)
 >>> b.search(u"bc\r\n")
 >>> b.search(u"abc")
<_sre.SRE_Match object at 0xb5908f70>
 >>> b.search(u"bc\nde")
<_sre.SRE_Match object at 0xb5908fa8>

is this a known bug in the re module? i couldn't find any issues in the 
bug tracker.
Or is this just a user fault and you guys can help me?

arian

p.s.: appears in both python2.4 and 2.5
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Index of maximum element in list

[Paul Rubin]

Arnaud Delobelle <[EMAIL PROTECTED]> writes:

> def simple_posmax(l, key=None):
> if key:
> return l.index(max(l, key=key))
> else:
> return l.index(max(l))

def simple_posmax(l, **kw):
   return l.index(max(l, **kw))

> simple_posmax is more than 3x faster on my machine.  It's not
> surprising as even though the list is walked twice, it is all done in
> C and no new objects have to be created. Then only non-C bit is when
> the result of max(l) is fed to l.index().

It does expose a slight danger in that the list might somehow
self-mutate during the first traversal.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Index of maximum element in list

[Arnaud Delobelle]

On Jan 27, 11:42 am, Paul Rubin  wrote:
> Arnaud Delobelle <[EMAIL PROTECTED]> writes:
> > def simple_posmax(l, key=None):
> >     if key:
> >         return l.index(max(l, key=key))
> >     else:
> >         return l.index(max(l))
>
> def simple_posmax(l, **kw):
>    return l.index(max(l, **kw))

Yes.  I wanted to make simple_posmax and clever_posmax as identical as
possible to make the comparison fair.

>
> > simple_posmax is more than 3x faster on my machine.  It's not
> > surprising as even though the list is walked twice, it is all done in
> > C and no new objects have to be created. Then only non-C bit is when
> > the result of max(l) is fed to l.index().
>
> It does expose a slight danger in that the list might somehow
> self-mutate during the first traversal.

I suppose.  Although you'd have to be mad to have comparisons mutate
stuff...
Also, it only works with sequences.
--
Arnaud

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: translating Python to Assembler

[Marc 'BlackJack' Rintsch]

On Sun, 27 Jan 2008 10:55:20 +, over wrote:

> On Sat, 26 Jan 2008 14:47:50 +0100, Bjoern Schliessmann
> <[EMAIL PROTECTED]> wrote:
> 
> The script is essentially gone. I'd like to know how to read the pyc
> files, but that's getting away from my point that there is a link
> between python scripts and assembler. At this point, I admit the code
> above is NOT assembler, but sooner or later it will be converted to
> machine code by the interpreter and the OS and that can be
> disassembled as assembler.  

No it will not be converted to assembler.  The byte code is *interpreted*
by Python, not compiled to assembler.  If you want to know how this
happens get the C source code of the interpreter and don't waste your time
with disassembling `python.exe`.  C is much easier to read and there are
useful comments too.

Ciao,
Marc 'BlackJack' Rintsch
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: translating Python to Assembler

[Marc 'BlackJack' Rintsch]

On Sun, 27 Jan 2008 11:23:20 +, over wrote:

> Don't fucking tell me about assembler, you asshole. I can read
> disassembled code in my sleep.

Yes you can read it, but obviously you don't understand it.

Ciao,
Marc 'BlackJack' Rintsch
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Index of maximum element in list

[Arnaud Delobelle]

On Jan 27, 11:32 am, Arnaud Delobelle <[EMAIL PROTECTED]> wrote:

[...]
>
> simple_posmax is more than 3x faster on my machine.  It's not
> surprising as even though the list is walked twice, it is all done in
> C and no new objects have to be created. Then only non-C bit is when
> the result of max(l) is fed to l.index().

Of course that's incorrect in general: if comparison functions between
objects in l are python functions then some bytecode will be run and
some new objects may be created.  But in most cases I think it stands
true.

--
Arnaud

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: how to make format operator % work with unicode as expected

[Colin J. Williams]

Peter Pei wrote:
> You didn't understand my question, but thanks any way.
> 
> Yes, it is true that %s already support unicode, and I did not 
> contradict that. But it counts the number of bytes instead of 
> characters, and makes things like %-20s out of alignment. If you don't 
> understand my assertion, please don't argue back and I am only 
> interested in answers from those who are qualified.


Peter,

Rudeness is inappropriate whether the 
person being attacked is
a frequent or infrequent contributer to 
this list.

Colin W
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Some questions about decode/encode

[glacier]

On 1月27日, 下午7时20分, John Machin <[EMAIL PROTECTED]> wrote:
> On Jan 27, 9:17 pm, glacier <[EMAIL PROTECTED]> wrote:
>
>
>
>
>
> > On 1月24日, 下午3时29分, "Gabriel Genellina" <[EMAIL PROTECTED]> wrote:
>
> > > En Thu, 24 Jan 2008 04:52:22 -0200, glacier <[EMAIL PROTECTED]> escribió:
>
> > > > According to your reply, what will happen if I try to decode a long
> > > > string seperately.
> > > > I mean:
> > > > ##
> > > > a='你好吗'*10
> > > > s1 = u''
> > > > cur = 0
> > > > while cur < len(a):
> > > > d = min(len(a)-i,1023)
> > > > s1 += a[cur:cur+d].decode('mbcs')
> > > > cur += d
> > > > ##
>
> > > > May the code above produce any bogus characters in s1?
>
> > > Don't do that. You might be splitting the input string at a point that is
> > > not a character boundary. You won't get bogus output, decode will raise a
> > > UnicodeDecodeError instead.
> > > You can control how errors are handled, see  
> > > http://docs.python.org/lib/string-methods.html#l2h-237
>
> > > --
> > > Gabriel Genellina
>
> > Thanks Gabriel,
>
> > I guess I understand what will happen if I didn't split the string at
> > the character's boundry.
> > I'm not sure if the decode method will miss split the boundry.
> > Can you tell me then ?
>
> > Thanks a lot.
>
> *IF* the file is well-formed GBK, then the codec will not mess up when
> decoding it to Unicode. The usual cause of mess is a combination of a
> human and a text editor :-)- 隐藏被引用文字 -
>
> - 显示引用的文字 -

I guess firstly, I should check if the file I used to test is well-
formed GBK..:)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Some questions about decode/encode

[glacier]

On 1月27日, 下午7时04分, John Machin <[EMAIL PROTECTED]> wrote:
> On Jan 27, 9:18 pm, glacier <[EMAIL PROTECTED]> wrote:
>
>
>
>
>
> > On 1月24日, 下午4时44分, Marc 'BlackJack' Rintsch <[EMAIL PROTECTED]> wrote:
>
> > > On Wed, 23 Jan 2008 19:49:01 -0800, glacier wrote:
> > > > My second question is: is there any one who has tested very long mbcs
> > > > decode? I tried to decode a long(20+MB) xml yesterday, which turns out
> > > > to be very strange and cause SAX fail to parse the decoded string.
>
> > > That's because SAX wants bytes, not a decoded string.  Don't decode it
> > > yourself.
>
> > > > However, I use another text editor to convert the file to utf-8 and
> > > > SAX will parse the content successfully.
>
> > > Because now you feed SAX with bytes instead of a unicode string.
>
> > > Ciao,
> > > Marc 'BlackJack' Rintsch
>
> > Yepp. I feed SAX with the unicode string since SAX didn't support my
> > encoding system(GBK).
>
> Let's go back to the beginning. What is "SAX"? Show us exactly what
> command or code you used.
>
SAX is the package 'xml.sax' distributed with Python 2.5:)
1,I read text from a GBK encoded XML file then I skip the first line
declare the encoding.
2,I converted the string to uncode by call decode('mbcs')
3,I used xml.sax.parseString to parse the string.


f = file('e:/temp/456.xml','rb')
s = f.read()
f.close()
n = 0
for i in xrange(len(s)):
if s[i]=='\n':
n += 1
if n == 1:
s = s[i+1:]
break
s = ''+s+''
s = s.decode('mbcs')
xml.sax.parseString(s,handler,handler)



> How did you let this SAX know that the file was encoded in GBK? An
> argument to SAX? An encoding declaration in the first few lines of the
> file? Some other method? ... precise answer please. Or did you expect
> that this SAX would guess correctly what the encoding was without
> being told?
I didn't tell the SAX the file is encoded in GBK since I used the
'parseString' method.
>
> What does "didn't support my encoding system" mean? Have you actually
> tried pushing raw undecoded GBK at SAX using a suitable documented
> method of telling SAX that the file is in fact encoded in GBK? If so,
> what was the error message that you got?
I mean SAX only support a limited number of encoding such as utf-8
utf-16 etc.,which didn't include GBK.

>
> How do you know that it's GBK, anyway? Have you considered these
> possible scenarios:
> (1) It's GBK but you are telling SAX that it's GB2312
> (2) It's GB18030 but you are telling SAX it's GBK
>
Frankly speaking, I cannot tell if the file contains any GB18030
characters...^__^
> HTH,
> John- 隐藏被引用文字 -
>
> - 显示引用的文字 -

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: translating Python to Assembler

[Steven D'Aprano]

On Sun, 27 Jan 2008 10:55:20 +, over wrote:

> I can understand people thinking I'm full of beans.


Oh no, not full of beans. Full of something, but not beans.

Everything you have written about assembly, machine code, compilers, 
Linux, Python and so forth has been a confused mish-mash of half-truths, 
distortions, vaguely correct factoids and complete nonsense.

I'm starting to wonder if it is possible for somebody to be 
simultaneously so self-assured and so ignorant, or if we're being trolled.


-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: how to make format operator % work with unicode as expected

[Diez B. Roggisch]

Peter Pei schrieb:
> I am using things like "%-20s%-60s%-10s" in tkinter listbox to make it 
> look like a table, with mono sized font like lucie system. But this does 
> not work with data contains "Les misérables", because it is unicode, and 
> one byte is not neccessary one character. Now how can I resolve this issue?

By learning that unicode is not UTF-8, instead of insulting others of 
being incompetent.


Diezz
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python System information

[Martin Saturka]

> How can i get system information like CPU load and RAM usage in linux.

What about 'pystatgrab'?
It provides good info, with a limitation - it does not have CPU info
for particular CPUs, it takes just the cumulative CPU info.
http://www.i-scream.org/pystatgrab/
http://packages.debian.org/statgrab

M.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: raw_input(), STRANGE behaviour

[Dox33]

Yes, I know.
There are several ways to work around the problem.
(Look at the innitial code I provided in this discussion start)
Fact is, every time I'm getting a script from somewhere or someone, I
have to search and replace all the affected code.
Not very conveniant.
That's why I rather would have a correct working version.

On 27 jan, 04:20, Hrvoje Niksic <[EMAIL PROTECTED]> wrote:
> Dox33 <[EMAIL PROTECTED]> writes:
> > Thanks for your reply.  Since I momentarily do not have the ability
> > to build a new python executable, I would like to ask for your help
> > in this case.  Are you able to supply me with a corrected version?
>
> You can simply choose not to use raw_input, and use sys.stdin.readline
> instead.  Or define your own corrected raw_input:
>
> def my_raw_input(msg):
>     print msg,
>     return raw_input()

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Using a dict as if it were a module namespace

[Ross Ridge]

Steven D'Aprano writes:
>(1) Import the test and grab the values needed from it:
>
>setup = """from __main__ import myfunc, test
>x, y = test['x'], test['y']"""
>
>
>I don't like this one. It doesn't seem very elegant to me, and it gets 
>unwieldy as the complexity increases. Every item I need from test has to 
>be named twice, violating the principle Don't Repeat Yourself. If the 
>tests change, the setup string has to be explicitly changed also. 

I think this is the way to go as it follows the principle of "say what
you mean."  You can however simplify it, and repeat yourself less,
by using the extended call syntax:

expr = "myfunc(**test)"
setup = """from __main__ import myfunc, test"""

...
>I don't like this one. It looks hackish, and I worry about conflicts and 
>side-effects. If it works (and I haven't tested it) it relies on an 
>implementation detail of timeit.Timer.__init__, namely the line
>"exec code in globals(), ns". Worst of all, it pollutes or even mangles 
>the global namespace of the calling code, not the code being tested.

It wouldn't work because the timeit module's "globals" are different
from the __main__ module's globals.

Ross Ridge

-- 
 l/  //   Ross Ridge -- The Great HTMU
[oo][oo]  [EMAIL PROTECTED]
-()-/()/  http://www.csclub.uwaterloo.ca/~rridge/ 
 db  //   
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: translating Python to Assembler

[Marc 'BlackJack' Rintsch]

On Sun, 27 Jan 2008 13:41:54 +, Steven D'Aprano wrote:

> On Sun, 27 Jan 2008 10:55:20 +, over wrote:
> 
>> I can understand people thinking I'm full of beans.
> 
> Oh no, not full of beans. Full of something, but not beans.
> 
> Everything you have written about assembly, machine code, compilers, 
> Linux, Python and so forth has been a confused mish-mash of half-truths, 
> distortions, vaguely correct factoids and complete nonsense.
> 
> I'm starting to wonder if it is possible for somebody to be 
> simultaneously so self-assured and so ignorant, or if we're being trolled.

I recently learned that this is called the Dunning-Kruger effect:

  The Dunning-Kruger effect is the phenomenon wherein people who have
  little knowledge think that they know more than others who have much
  more knowledge.

  […]

  The phenomenon was demonstrated in a series of experiments performed by
  Justin Kruger and David Dunning, then both of Cornell University. Their
  results were published in the Journal of Personality and Social
  Psychology in December 1999.

  http://en.wikipedia.org/wiki/Dunning-Kruger_effect

See, there's almost always a rational explanation.  ;-)

Ciao,
Marc 'BlackJack' Rintsch
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: how to make format operator % work with unicode as expected

[Peter Pei]

"I V" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
> On Sun, 27 Jan 2008 05:32:40 +, Peter Pei wrote:
>> Yes, it is true that %s already support unicode, and I did not
>> contradict that. But it counts the number of bytes instead of
>> characters, and makes things like %-20s out of alignment. If you don't
>> understand my assertion, please don't argue back and I am only
>> interested in answers from those who are qualified.
>
> What version of python are you using? On python 2.4 and 2.5 on linux,
2.5.2 on windows, if you have tested linux, maybe... windows is the issue?
> %-20s counts the characters, not the bytes, or, I think it does. when I
> run:
>
 print u'%-20s|\n%-20s|' % (u'foo bar', u'foo bár')
>
> the output is:
>
> foo bar |
> foo bár |
> 

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: translating Python to Assembler

[Grant Edwards]

On 2008-01-27, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:

> Whatever is typed in a Python script must be converted to
> binary code.

Python scripts _are_ in a binary code when the start out.

-- 
Grant Edwards   grante Yow!  What UNIVERSE is
  at   this, please??
   visi.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: how to make format operator % work with unicode as expected

[Peter Pei]

"Steven D'Aprano" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
> On Sun, 27 Jan 2008 05:32:40 +, Peter Pei wrote:
>
>> You didn't understand my question, but thanks any way.
>>
>> Yes, it is true that %s already support unicode, and I did not
>> contradict that. But it counts the number of bytes instead of
>> characters, and makes things like %-20s out of alignment. If you don't
>> understand my assertion, please don't argue back and I am only
>> interested in answers from those who are qualified.
>
> I understand your assertion. I think it is nonsense.
this kind of reply only embarrase yourself
>
 def test():
> ... print "12345678901234567890 +"
> ... print "%-20s +" % "Plain ASCII"
> ... print u"%-20s +" % u"Les misérables-\320\321\322"
> ...
 test()
> 12345678901234567890 +
> Plain ASCII  +
> Les misérables-ÐÑÒ   +
>
>
>
>
> -- 
> Steven 

-- 
http://mail.python.org/mailman/listinfo/python-list

Workshop "Medical Imaging Systems" within EUROMEDIA 2008 - Last Call for Papers

[[EMAIL PROTECTED]]

-

(Apologies for cross-posting)

Workshop "Medical Imaging Systems" within EUROSIS EUROMEDIA 2008
April 9-11, 2008, University of Porto, Porto, Portugal
http://www.eurosis.org/cms/index.php?q=node/461

We would appreciate if you could distribute this information by your
colleagues and co-workers.

-

Dear Colleague,

In recent years, extensive research has been performed to develop more
and more efficient and powerful medical imaging systems. Such systems
are crucial for medical specialists, allowing a deeper analysis and to
understand what is going inside the human body, and therefore they
play an essential role for adequate medical diagnosis and treatments.
To accomplish efficient and powerful medical imaging systems, many
research works have being done in many domains, like the ones related
with medical image devices, signal processing, image processing and
analysis, biomechanical simulation and data visualization.
The main goal of the Workshop "Medical Imaging Systems" is to bring
together researchers involved in the related domains, in order to set
the major lines of development for the near future.
Therefore, the proposed Workshop will consist of researchers
representing various fields related to Medical Devices, Signal
Processing, Computational Vision, Computer Graphics, Computational
Mechanics, Scientific Visualization, Mathematics and Medical Imaging.
The Workshop endeavours to contribute to obtain better solutions for
more efficient and powerful medical imaging systems, and attempts to
establish a bridge between clinicians and researchers from these
diverse fields.
The proposed Workshop will cover topics related with medical imaging
systems, such as: image acquisition, signal processing, image
processing and analysis, modelling and simulation, computer aided
diagnosis, surgery, therapy, and treatment, computational bioimaging
and visualization, software development, virtual reality and
telemedicine systems and their applications.
Due to your research activities in the field, we would like to invite
you to submit a contributed paper. Your contribution is mostly
welcomed and we would be honoured if you could participate in
EUROMEDIA 2008.

DEADLINE FOR PAPERS SUBMISSION: February 5, 2008

SCIENTIFIC COMMITTEE:

Alberto De Santis, Università degli Studi di Roma "La Sapienza", Italy
Ana Mafalda Reis, Instituto de Ciências Biomédicas Abel Salazar,
Portugal
Arrate Muñoz Barrutia, University of Navarra, Spain
Behnam Heidari, University College Dublin, Ireland
Bernard Gosselin, Faculte Polytechnique de Mons, Belgium
Chandrajit Bajaj, University of Texas, USA
Christos E. Constantinou, Stanford University School of Medicine, USA
Daniela Iacoviello, Università degli Studi di Roma "La Sapienza",
Italy
Dinggang Shen, University of Pennsylvania, USA
Djemel Ziou, University of Sherbrooke, Canada
Gerald Schaefer, Aston University, UK
João Krug Noronha, Dr. Krug Noronha Clinic, Portugal
João Manuel R. S. Tavares, Faculty of Engineering of University of
Porto, Portugal
João Paulo Costeira, Instituto Superior Técnico, Portugal
Jorge M. G. Barbosa, Faculty of Engineering of University of Porto,
Portugal
Lyuba Alboul, Sheffield Hallam University, UK
Manuel González Hidalgo, Balearic Islands University, Spain
Maria Elizete Kunkel, Universität Ulm, Germany
Mário Forjaz Secca, Universidade Nova de Lisboa, Portugal
Miguel Angel López, Faculty University of Ciego de Avila, Cuba
Miguel Velhote Correia, Faculty of Engineering of University of Porto,
Portugal
Patrick Dubois, Institut de Technologie Médicale, France
Reneta Barneva, State University of New York, USA
Renato M. Natal Jorge, Faculty of Engineering of University of Porto,
Portugal
Sabina Tangaro, University of Bari, Italy
Valentin Brimkov, State University of New York, USA
Yongjie Zhan, Carnegie Mellon University, USA

For further details please see the conference website at:
http://www.eurosis.org/cms/index.php?q=node/461

We are looking forward to see you in Porto next April.

Kind regards,

João Manuel R. S. Tavares
University of Porto
[EMAIL PROTECTED]
www.fe.up.pt/~tavares
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: how to make format operator % work with unicode as expected

[Peter Pei]

"Marc 'BlackJack' Rintsch" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
> On Sun, 27 Jan 2008 05:32:40 +, Peter Pei wrote:
>
>> You didn't understand my question, but thanks any way.
>>
>> Yes, it is true that %s already support unicode, and I did not contradict
>> that. But it counts the number of bytes instead of characters, and makes
>> things like %-20s out of alignment. If you don't understand my assertion,
>> please don't argue back and I am only interested in answers from those 
>> who
>> are qualified.
>
> I have the impression from your original post
>
>  […] because it is unicode, and one byte is not neccessary one character.
>
> that you confuse unicode and utf-8.  Are you sure you are qualified to ask
> such a question in the first place!?  :-þ
so you are saying, with utf-8 encoding a byte is a character, shame on you.
>
> Ciao,
> Marc 'BlackJack' Rintsch 

-- 
http://mail.python.org/mailman/listinfo/python-list

Python self-evaluating strings

[Arnaud Delobelle]

Hi all,

An earlier post today got me thinking about "quines" (programs that  
output themselves) in Python.  I tried to find some on the web but  
didn't find many ([1]).  In particular I didn't find any that  
corresponded to my instinctive (LISP-induced, probably) criterion:

def self_evaluating(s):
"Return True if string s evaluates to itself"
return s == eval(s)

Here is the result of my efforts so far:

1. Starting from the classic idea (lambda x:x%x)('lambda x:x%x') I got  
the following
v=(lambda x:x%('"''""'+x+'"''""'))("""(lambda x:x%%('"''""'+x+'"''""')) 
(%s)""")

2. (Given that if s is a nonempty string, s*2 is a longer string).   
Starting from the idea "%s %s" % (("%s %s",)*2) I got the following
u="\"%s\" %% ((r\"%s\",)*2)" % ((r"\"%s\" %% ((r\"%s\",)*2)",)*2)

Most of my problems in creating these 2 was with finding a suitable  
way of quoting strings that propagates well. Both u and v are one- 
liners.  I'm hoping for no funky line wrapping here.

Note: I'm not quoting the string as it makes no difference since they  
evaluate to themselves:)

I'd like to know if anyone on the list has indulged in this time- 
bending/mind-wasting activity before.  If so, it would be nice to  
create a list of such expressions.

Quining's-better-than-ironing'ly yours

-- 
Arnaud

[1] http://www.nyx.net/~gthompso/self_pyth.txt

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Klik2 Project, Python apps on linux

[Bill Mill]

Jason,

Can you give a little more detail on the problem? What's the directory
structure of a Klik package that's failing look like? What program is
trying to import what module from where that's failing?

-Bill Mill

On Jan 27, 2008 1:49 AM, Jason Taylor <[EMAIL PROTECTED]> wrote:
> Hi
>
> We've been working on klik2, http://code.google.com/p/klikclient/, which
> implements OSX like application files on linux (with applications working on
> all distros), In which every user desktop application is 1 file
>
> We've run into a bit of a problem with python apps,  so while we can run a
> complicated application like openoffice.org on ubuntu, fedora and suse from
> a single file we cant run any python applications such as
>  jokosher
> gnome-specimen
> angrydd
> gausssum
> pathological
> quodlibet
> webboard
> istanbul
> exaile
> ccsm
> bittornado
> pessulus
> labyrinth
> wammu
> accerciser
>
>  We'd like to fix this in a clean way with out resorting to nasty hacks
> involving $PYTHON_PATH.
>
> If any one has any suggestions please email me or drop by #klik on freenode
>
> Issue http://code.google.com/p/klikclient/issues/detail?id=144
>
> Cheers
>
> Jason Taylor
>
> --
> "Why isn't my life like a situation comedy? Why don't I have a bunch of
> friends with nothing better to do but drop by and instigate wacky
> adventures? Why aren't my conversations peppered with spontaneous
> witticisms? Why don't my friends demonstrate heartfelt concern for my well
> being when I have problems? ...I gotta get my life some writers." - Calven
> --
> http://mail.python.org/mailman/listinfo/python-list
>
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: translating Python to Assembler

[Grant Edwards]

On 2008-01-27, Marc 'BlackJack' Rintsch <[EMAIL PROTECTED]> wrote:

>> I'm starting to wonder if it is possible for somebody to be 
>> simultaneously so self-assured and so ignorant, or if we're
>> being trolled.
>
> I recently learned that this is called the Dunning-Kruger effect:
>
>   The Dunning-Kruger effect is the phenomenon wherein people who have
>   little knowledge think that they know more than others who have much
>   more knowledge.
>
>   [?]
>
>   The phenomenon was demonstrated in a series of experiments performed by
>   Justin Kruger and David Dunning, then both of Cornell University. Their
>   results were published in the Journal of Personality and Social
>   Psychology in December 1999.

I remember reading that paper about a year ago and it sure
seemd to explain the behavior of a number of people I've known.
Not only is it possible to be simultaneously self-assured and
ignorant, that appears to be the normal way that the human mind
works.

... must restist ... urge... to mention... Bush...   

Damn.

-- 
Grant Edwards   grante Yow!  You can't hurt
  at   me!! I have an ASSUMABLE
   visi.comMORTGAGE!!
-- 
http://mail.python.org/mailman/listinfo/python-list

is it a bug?

[Mr Shore]

import threading
import time
class timer(threading.Thread):
def __init__(self,no,interval):
threading.Thread.__init__(self)
self.no=no
self.interval=interval

def run(self):
while True:
print 'Thread Object (%d), Time:%s'%(self.no,time.ctime())
time.sleep(self.interval)

def test():
threadone=timer(1,1)
threadtwo=timer(2,3)
threadone.start()
threadtwo.start()
print 'main thread'

if __name__=='__main__':
test()
when I run the above programme,an error comes out but ignored
Exception exceptions.AttributeError: '_shutdown' in  ignored
-- 
http://mail.python.org/mailman/listinfo/python-list

py3k feature proposal: field auto-assignment in constructors

[coldpizza]

There is a pattern that occurs fairly often in constructors in Python
and other OOP languages.

Let's take an example:

class Server(object):
def __init__(self, host, port, protocol, bufsize, timeout):
self.host = host
self.port = port
self.protocol = protocol
self.bufsize = bufsize
self.maxthreads = maxthreads
self.timeout = timeout

Imho, in the class above the assignment to instance fields does not
contain much programming logic and therefore can be safely 'abstracted
away' by the language itself with a syntax which would look something
like this:

class Server(object):
def __init__(self, @host, @port, @protocol, @bufsize, @timeout):
pass

This would be equivalent to the first example above, yet it does not
obfuscate the code in any way. Or does it? It does look much cleaner
to me.

Of course, the ampersand is just an arbitrary choice and might have
bad connotations for those who read it as 'take address of' but @ has
some allusion to delegates which maybe is ok.

I am not an experienced programmer and I am not sure if this is
necessarily a good idea, so I wanted to get some feedback from more
experienced Pythonistas before submitting it elsewhere.


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: how to make format operator % work with unicode as expected

[Marc 'BlackJack' Rintsch]

On Sun, 27 Jan 2008 16:00:42 +, Peter Pei wrote:

> "Marc 'BlackJack' Rintsch" <[EMAIL PROTECTED]> wrote in message 
> news:[EMAIL PROTECTED]
>> On Sun, 27 Jan 2008 05:32:40 +, Peter Pei wrote:
>>
>>> You didn't understand my question, but thanks any way.
>>>
>>> Yes, it is true that %s already support unicode, and I did not contradict
>>> that. But it counts the number of bytes instead of characters, and makes
>>> things like %-20s out of alignment. If you don't understand my assertion,
>>> please don't argue back and I am only interested in answers from those 
>>> who are qualified.
>>
>> I have the impression from your original post
>>
>>  […] because it is unicode, and one byte is not neccessary one character.
>>
>> that you confuse unicode and utf-8.  Are you sure you are qualified to
>> ask such a question in the first place!?  :-þ
> so you are saying, with utf-8 encoding a byte is a character, shame on
> you.

No I don't say that.  I say unicode has no bytes but codepoints.  And with
unicode objects Python counts characters and not bytes.  So I guess you
are trying to format utf-8 encoded byte strings instead of unicode
strings.  Because with unicode strings your "problem" simply does not
exist.  As several people already *showed* to you with examples.  Once
again:

In [346]: u = u'sm\xf8rebr\xf8d'

In [347]: s = u.encode('utf-8')

In [348]: print '%-20s+\n%-20s+' % (s, 'spam')
smørebrød +
spam+

In [349]: print '%-20s+\n%-20s+' % (u, 'spam')
smørebrød   +
spam+

348 is what you are doing, utf-8 encoded byte strings, but you claim that's
a problem with unicode.

And 349 is formatting unicode.  See, no problem -- lines up nicely.

Instead of embarrassing yourself and being rude to people you should take
some time and learn something about unicode and encodings.  Especially that
utf-8 ≠ unicode.

Ciao,
Marc 'BlackJack' Rintsch
-- 
http://mail.python.org/mailman/listinfo/python-list

Bash the Bush [WAS: Re: translating Python to Assembler]

[Wildemar Wildenburger]

Grant Edwards wrote:
> On 2008-01-27, Marc 'BlackJack' Rintsch <[EMAIL PROTECTED]> wrote:
>>   The Dunning-Kruger effect is the phenomenon wherein people who have
>>   little knowledge think that they know more than others who have much
>>   more knowledge.
>> [snip]
> [snip as well]
> ... must restist ... urge... to mention... Bush...   
> 
Well, I think that G.W. Bush knows perfectly well that he is not really 
up to the task. I still suspect that it never really was his decision to 
become president, if you follow me.

/W
(What do I care, he's not my president after all ... although, in a way 
... YYRRR!)
-- 
http://mail.python.org/mailman/listinfo/python-list

REALLY simple xml reader

[Simon Pickles]

Hi

Can anyone suggest a really simple XML reader for python? I just want to 
be able to do something like this:

xmlDoc = xml.open("file.xml")
element = xmlDoc.GetElement("foo/bar")

... to read the value of:


   42



Thanks

Simon

-- 
Linux user #458601 - http://counter.li.org.



-- 
http://mail.python.org/mailman/listinfo/python-list

Re: getting values from cache

[Gabriel Genellina]

En Sat, 26 Jan 2008 05:21:52 -0200, nodrogbrown <[EMAIL PROTECTED]>  
escribi�:

> hi
> i am writing code to check a folder containing images and then process
> thir vals using PIL and do some calc to create a matrix of values .if
> the folder has any new imgs added the program will do all calc again
> and dump the values into a cachefile.If the folder contents remain
> unaltered the program should not do calc but load the vals from
> cachefile..it is assumed that malicious alterations are not made on
> the folder and so i wont be doing any thorogh check but just checking
> if contents of folder have changed..i do something like this
>
>
> def checkCache(self):
>filenameslist=getfilenameslist() # made by parsing folder before
> this
>try:
>   f=open(cachefile)
>
>except IOError:
>   #no cache found ,do all calc
> mynumpymatrix1,imgwdth,imght=docalculations()
> f2=open(cachefile,"w")
> #dump values as tuple
> pickle.dump((filenameslist,imgwdth,imght,mynumpymatrix1),f2)
>   f2.close()
>else:
> #cache exists, need to check if folder contents changed
> oldfilenameslist,wd,ht, mynumpymatrix1=pickle.load(f)
> f.close()
>
> if(filenamelist==oldfilelist):
> #if oldfilenamelst same,it means folder hasn't changed
> #use the vals from cache.
> else:
> #folder changed
> mynumpymatrix1,imgwdth,imght=docalculations()
> f3=open(cachefile,"w")
> pickle.dump((filenameslist,imgwdth,imght,mynumpymatrix1),f3)
> f3.close()
>
>  this works and does what i need in my code..but i want to know if a
> more elegant solution is possible
>  i am not worried about someone deliberately renaming files like
> .jpeg to aaa.jped and a.jpeg to deceive the checking
>  since it is assumed that noone has permission to modify the folder
> except a trusted admin/code
>
>  will be grateful for your suggestions
>  tia

I'd try to avoid duplicating the calculation code.

   get newfilenameslist
   update_cache = True
   try:
 f=open(cachefile)
   except IOError:
 pass
   else:
 read oldfilenameslist
 f.close()
 if oldfilenameslist==newfilenameslist:
   update_cache = False
   if update_cache:
 do calculations
 write file

Also, if you split the data in two, you can just read the filename list  
alone:

pickle.dump(filenameslist, f2)
pickle.dump((imgwdth,imght,mynumpymatrix1),f2)

-- 
Gabriel Genellina

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: REALLY simple xml reader

[Diez B. Roggisch]

Simon Pickles schrieb:
> Hi
> 
> Can anyone suggest a really simple XML reader for python? I just want to 
> be able to do something like this:
> 
> xmlDoc = xml.open("file.xml")
> element = xmlDoc.GetElement("foo/bar")
> 
> ... to read the value of:
> 
> 
>   42
> 

Since python2.5, the ElementTree module is available in the standard 
lib. Before 2.5, you can of course install it.

Your code then would look like this:

import xml.etree.ElementTree  as et


doc = """

   42

"""

root = et.fromstring(doc)

for bar in root.findall("bar"):
 print bar.text



Diez

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: py3k feature proposal: field auto-assignment in constructors

[André]

On Jan 27, 1:06 pm, coldpizza <[EMAIL PROTECTED]> wrote:
> There is a pattern that occurs fairly often in constructors in Python
> and other OOP languages.
>
> Let's take an example:
>
> class Server(object):
> def __init__(self, host, port, protocol, bufsize, timeout):
> self.host = host
> self.port = port
> self.protocol = protocol
> self.bufsize = bufsize
> self.maxthreads = maxthreads
> self.timeout = timeout
>
> Imho, in the class above the assignment to instance fields does not
> contain much programming logic and therefore can be safely 'abstracted
> away' by the language itself with a syntax which would look something
> like this:
>
> class Server(object):
> def __init__(self, @host, @port, @protocol, @bufsize, @timeout):
> pass
>
> This would be equivalent to the first example above, yet it does not
> obfuscate the code in any way. Or does it? It does look much cleaner
> to me.
>
> Of course, the ampersand is just an arbitrary choice and might have
> bad connotations for those who read it as 'take address of' but @ has
> some allusion to delegates which maybe is ok.
>
> I am not an experienced programmer and I am not sure if this is
> necessarily a good idea, so I wanted to get some feedback from more
> experienced Pythonistas before submitting it elsewhere.

If you search on this list, you will find that there has been *many*
proposals to remove self (which, I realize is slightly different than
what yo propose) and that the main argument can be summarized as
"Explicit is better than implicit."

Personally, I like the idea you suggest, with the modification that I
would use "." instead of "@", as in

class Server(object):
def __init__(self, .host, .port, .protocol, .bufsize, .timeout):
pass

André

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Exceptions on delete in pysqlite

[Gabriel Genellina]

En Fri, 25 Jan 2008 22:12:57 -0200, Wildemar Wildenburger  
<[EMAIL PROTECTED]> escribi�:

> Using pysqlite, I'd like to check if some dataset that I removed has
> been in the database at all. Ideally I'd like pysqlite to raise an
> Exception if deleting does nothing. Is that possible?

I don't think so. It isn't an error, like a SELECT which returns an empty  
set isn't an error either.

> Codewise, I'd like the following, but without me checking for and
> raising the exception myself:
>
> cur = con.execute("""DELETE FROM SomeTable WHERE id=? AND name=?""",
>   (ID, NAME))
> if cur.rowcount == 0:
>  raise Exception

Write a function to do that.

-- 
Gabriel Genellina

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: REALLY simple xml reader

[Mark Tolonen]

"Simon Pickles" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
> Hi
>
> Can anyone suggest a really simple XML reader for python? I just want to 
> be able to do something like this:
>
> xmlDoc = xml.open("file.xml")
> element = xmlDoc.GetElement("foo/bar")
>
> ... to read the value of:
>
> 
>   42
> 
>
>
> Thanks
>
> Simon
>
> -- 
> Linux user #458601 - http://counter.li.org.
>
>
>

>>> from xml.etree import ElementTree as ET
>>> tree=ET.parse('file.xml')
>>> tree.find('bar').text
'42'
>>>

--Mark

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Exceptions on delete in pysqlite

[Wildemar Wildenburger]

Gabriel Genellina wrote:
> En Fri, 25 Jan 2008 22:12:57 -0200, Wildemar Wildenburger 
> <[EMAIL PROTECTED]> escribi�:
> 
>> Using pysqlite, I'd like to check if some dataset that I removed has
>> been in the database at all. Ideally I'd like pysqlite to raise an
>> Exception if deleting does nothing. Is that possible?
> 
> I don't think so. It isn't an error, like a SELECT which returns an 
> empty set isn't an error either.
> 
Of course, but you know ... I was hoping.


>> Codewise, I'd like the following, but without me checking for and
>> raising the exception myself:
>>
>> cur = con.execute("""DELETE FROM SomeTable WHERE id=? AND name=?""",
>>   (ID, NAME))
>> if cur.rowcount == 0:
>>  raise Exception
> 
> Write a function to do that.
> 
Yeah well you see, I have several similar functions for inserting, 
updating and deleting on different tables. And I wanted them all to 
behave uniformly, raising some exception when the operation did not do 
quite right (in this case: delete something that is not there.). That 
way, all those functions would even have looked similar, and I would 
have liked that for readability. Or for my autism, you pick. :)

Well, thanks anyway. :)
/W
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Using a dict as if it were a module namespace

[Steven Bethard]

Steven D'Aprano wrote:
> I have a problem which I think could be solved by using a dict as a 
> namespace, in a similar way that exec and eval do.
> 
> When using the timeit module, it is very inconvenient to have to define 
> functions as strings. A good alternative is to create the function as 
> normal, and import it:
> 
> def myfunc(x, y):
> return x+y
> 
> timeit.Timer("myfunc(59, 60)", "from __main__ import myfunc").timeit()
> 
> 
> Not only is this an easy idiom to follow, but myfunc can live in another 
> module: just replace __main__ with the module name.
> 
> Now, I'm trying to build a suite of tests to use with timeit. I have a 
> bunch of tests which I've created as dicts:
> 
> test_suite= [dict(x=59, y=60), dict(x=-1, y=-2)]
> 
> What I *think* I want to do is use the from ... import idiom to grab 
> arguments from the dicts as if they were modules, but this doesn't work:
> 
> expr = "myfunc(x, y)"
> for test in test_suite:
> setup = "from __main__ import myfunc; from test import x, y"
> t = timeit.Timer(expr, setup).timeit()
[snip]
> (2) Mess with the global namespace:
> 
> globals().update(t)
> setup = "from __main__ import myfunc"

Why not mess with the namespace inside the setup code? E.g.::

 >>> test_suite = [dict(x=59, y=60), dict(x=-1, y=-2)]
 >>> expr = "myfunc(x, y)"
 >>> for test in test_suite:
 ... setup = textwrap.dedent('''
 ... from __main__ import myfunc, test
 ... globals().update(test)''')
 ... t = timeit.Timer(expr, setup).timeit()
 ...

That shouldn't pollute your actual namespace::

 >>> x
 Traceback (most recent call last):
   File "", line 1, in 
 NameError: name 'x' is not defined
 >>> y
 Traceback (most recent call last):
   File "", line 1, in 
 NameError: name 'y' is not defined

STeVe
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How to modify the content of an email

[Gabriel Genellina]

En Fri, 25 Jan 2008 20:59:41 -0200, <[EMAIL PROTECTED]> escribi�:

> Hello, I'm trying to make a python script that take an email in (raw)
> text format, and add a footer to the text (or html) body of the email.
>
> I'm aware of the email and email.mime modules, but I can't figure out
> how to identify 'the main text (or html) content' from the email, and
> how to be sure that I don't incorrectly identify a txt (or html)
> attach as the main content of the email.
> By 'main text (or html) content' I mean the text (or html) that is
> showed by a Mail User Agent when it display the email to the
> recipient.

I suggest you read or overview the MIME specification (RFC 2045 and a few  
others), or some introductory text, in order to understand the terminology  
and what the email package does.
Simple messages have is_multipart()==False and get_payload() gives you the  
message text.
Multipart messages (e.g. having attachments, or an html/plaintext  
alternative) have is_multipart()==False and get_payload() returns a list  
of its parts. The parts may be Messages too, and can be multipart also.
HTML messages usually have Content-Type: multipart/alternative, coming  
first the text part and later the HTML part. You probably will have to  
modify both, because it's up to the MUA to decide which part to show.
When you modify an existing part you have to *remove* some headers like  
Content-Transfer-Encoding if you don't honor them in the replaced part. By  
example, the original may have been encoded in base64 or quoted-printable  
(but you didn't notice that because Python decoded the part for you).

-- 
Gabriel Genellina

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: py3k feature proposal: field auto-assignment in constructors

[Wildemar Wildenburger]

André wrote:
> Personally, I like the idea you suggest, with the modification that I
> would use "." instead of "@", as in
> 
> class Server(object):
> def __init__(self, .host, .port, .protocol, .bufsize, .timeout):
> pass
> 
I like :)

However, you can probably cook up a decorator for this (not certain, I'm 
not a decorator Guru), which is not that much worse.

Still, I'd support that syntax (and the general idea.).

/W
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python regex: misbehaviour with "\r" (0x0D) as Newline character in Unicode Mode

[Fredrik Lundh]

Arian Sanusi wrote:

 > concerning to unicode, "\n", "\r "and "\r\n" (0x000A, 0x000D and
0x000D+0x000A) should be threatened as newline character

the link says that your application should treat them line terminators, 
not that they should all be equal to a new line character.

to split on Unicode line endings, use the splitlines method.  for the 
specific characters you mention, you can also read the file in universal 
mode.



-- 
http://mail.python.org/mailman/listinfo/python-list

Re: py3k feature proposal: field auto-assignment in constructors

[Diez B. Roggisch]

Wildemar Wildenburger schrieb:
> André wrote:
>> Personally, I like the idea you suggest, with the modification that I
>> would use "." instead of "@", as in
>>
>> class Server(object):
>> def __init__(self, .host, .port, .protocol, .bufsize, .timeout):
>> pass
>>
> I like :)
> 
> However, you can probably cook up a decorator for this (not certain, I'm 
> not a decorator Guru), which is not that much worse.
> 
> Still, I'd support that syntax (and the general idea.).

Just for the fun of it, I implemented a decorator:

from functools import *
from inspect import *

def autoassign(_init_):
 @wraps(_init_)
 def _autoassign(self, *args, **kwargs):
 argnames, _, _, _ = getargspec(_init_)
 for name, value in zip(argnames[1:], args):
 setattr(self, name, value)
 _init_(self, *args, **kwargs)

 return _autoassign

class Test(object):
 @autoassign
 def __init__(self, foo, bar):
 pass



t = Test(10, 20)

print t.bar


Diez
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: ElementTree.fromstring(unicode_html)

[Fredrik Lundh]

globophobe wrote:

> In [1]: unicode_html = u'\u3055\u3080\u3044\uff0f\r\n\u3064\u3081\u305f
> \u3044\r\n'
> 
> I need to turn this into an elementtree, but some of the data is
> japanese whereas the rest is html. This string contains a .

where?   is an element, not a character.  "\r" and "\n" are 
characters, not elements.

If you want to build a tree where "\r\n" is replaced with a  
element, you can encode the string as UTF-8, use the replace method to 
insert the element, and then call fromstring.

Alternatively, you can build the tree yourself:

 import xml.etree.ElementTree as ET

 unicode_html = 
u'\u3055\u3080\u3044\uff0f\r\n\u3064\u3081\u305f\u3044\r\n'

 parts = unicode_html.splitlines()

 elem = ET.Element("data")
 elem.text = parts[0]
 for part in parts[1:]:
 ET.SubElement(elem, "br").tail = part

 print ET.tostring(elem)



-- 
http://mail.python.org/mailman/listinfo/python-list

Re: REALLY simple xml reader

[Navtej Singh]

check the implementation of XMLNode class here
http://hsivonen.iki.fi/group-feed/flickrapi.py

HTH
N

On Jan 27, 2008 11:05 PM, Simon Pickles <[EMAIL PROTECTED]> wrote:
> Hi
>
> Can anyone suggest a really simple XML reader for python? I just want to
> be able to do something like this:
>
> xmlDoc = xml.open("file.xml")
> element = xmlDoc.GetElement("foo/bar")
>
> ... to read the value of:
>
> 
>42
> 
>
>
> Thanks
>
> Simon
>
> --
> Linux user #458601 - http://counter.li.org.
>
>
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python self-evaluating strings

[dg . google . groups]

It's a bit cheap, but how about

>>> from inspect import getsource
>>> print getsource(getsource)

or similarly

def f(g):
import inspect
return inspect.getsource(g)
print f(f)

Dan
-- 
http://mail.python.org/mailman/listinfo/python-list

ANN: Leo 4.4.6 final released

[Edward K Ream]

Leo 4.4.6 final is available at:
http://sourceforge.net/project/showfiles.php?group_id=3458&package_id=29106

Leo 4.4.6 fixes several recently reported bugs, all minor.

Leo is a text editor, data organizer, project manager and much more. See:
http://webpages.charter.net/edreamleo/intro.html

The highlights of Leo 4.4.6:

- Fixes all known bugs.
- Added @auto importers for javascript and xml files.
- Added find-next-clone and toggle-sparse-move commands.

Links:
--
Leo:  http://webpages.charter.net/edreamleo/front.html
Home: http://sourceforge.net/projects/leo/
Download: http://sourceforge.net/project/showfiles.php?group_id=3458
CVS:  http://leo.tigris.org/source/browse/leo/
Quotes:   http://webpages.charter.net/edreamleo/testimonials.html

Edward K. Ream   email:  [EMAIL PROTECTED]
Leo: http://webpages.charter.net/edreamleo/front.html



-- 
http://mail.python.org/mailman/listinfo/python-list

Re: raw_input(), STRANGE behaviour

[Gabriel Genellina]

En Sun, 27 Jan 2008 12:51:51 -0200, Dox33 <[EMAIL PROTECTED]>  
escribi�:

> Yes, I know.
> There are several ways to work around the problem.
> (Look at the innitial code I provided in this discussion start)
> Fact is, every time I'm getting a script from somewhere or someone, I
> have to search and replace all the affected code.
> Not very conveniant.
> That's why I rather would have a correct working version.

Add this on your sitecustomize.py module (or create one)

import sys

def raw_input(prompt=None):
   if prompt: sys.stdout.write(prompt)
   return original_raw_input()

import __builtin__
original_raw_input = __builtin__.raw_input
__builtin__.raw_input = raw_input

It just replaces the builtin raw_input with a custom function.

-- 
Gabriel Genellina

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: py3k feature proposal: field auto-assignment in constructors

[Torsten Bronger]

Hallöchen!

Wildemar Wildenburger writes:

> André wrote:
>
>> Personally, I like the idea you suggest, with the modification
>> that I would use "." instead of "@", as in
>>
>> class Server(object):
>> def __init__(self, .host, .port, .protocol, .bufsize, .timeout):
>> pass
>
> I like :)
>
> However, you can probably cook up a decorator for this (not
> certain, I'm not a decorator Guru), which is not that much worse.
>
> Still, I'd support that syntax (and the general idea.).

Well, you save one or two lines per class.  Not enough in my
opinion.

Tschö,
Torsten.

-- 
Torsten Bronger, aquisgrana, europa vetus
  Jabber ID: [EMAIL PROTECTED]
   (See http://ime.webhop.org for further contact info.)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: py3k feature proposal: field auto-assignment in constructors

[Wildemar Wildenburger]

Diez B. Roggisch wrote:
> Just for the fun of it, I implemented a decorator:
> 
> from functools import *
> from inspect import *
> 
> def autoassign(_init_):
> @wraps(_init_)
> def _autoassign(self, *args, **kwargs):
> argnames, _, _, _ = getargspec(_init_)
> for name, value in zip(argnames[1:], args):
> setattr(self, name, value)
> _init_(self, *args, **kwargs)
> 
> return _autoassign
> 

This is neat. :) Could that maybe be extended to only assign selected 
args to the instance and let others pass unchanged. So that, for instance:

@autoassign("foo", "bar")
def __init__(self, foo, bar, baz):
 super(baz)

?W
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: read and readline hanging

[Olivier Lefevre]

> The `trheading` module is modeled after Java's threading API.

OK. Thanks for the hint. However BufferedReader.readline() does
not block in Java, so it is still difficult to transpose.

>> But how can I find out *programmatically* that there is no more
>> input?
> 
> You can't.

How do people handle this, then? Reading from a process that will
block if you ask too much yet won't let you know how much there is
to read right now has to be some kind of FAQ.

> This doesn't answer if the interpreter doesn't flush its output buffer
> after every line.

I think it must otherwise you might get incomplete answers or no
answers at the interactive prompt and that never happens. It may
not flush its buffer after every line but it must flush them at
the end of an answer.

-- O.L.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: py3k feature proposal: field auto-assignment in constructors

[André]

On Jan 27, 2:48 pm, Wildemar Wildenburger
<[EMAIL PROTECTED]> wrote:
> Diez B. Roggisch wrote:
> > Just for the fun of it, I implemented a decorator:
>
> > from functools import *
> > from inspect import *
>
> > def autoassign(_init_):
> > @wraps(_init_)
> > def _autoassign(self, *args, **kwargs):
> > argnames, _, _, _ = getargspec(_init_)
> > for name, value in zip(argnames[1:], args):
> > setattr(self, name, value)
> > _init_(self, *args, **kwargs)
>
> > return _autoassign
>
> This is neat. :) Could that maybe be extended to only assign selected
> args to the instance and let others pass unchanged. So that, for instance:
>
> @autoassign("foo", "bar")
> def __init__(self, foo, bar, baz):
>  super(baz)
>
> ?W

If one goes back to the original idea instead, the decision of using
automatic assignment should depend on the signature of the __init__
function.  Here's an implementation (using "_" instead of "." as it
would lead to a syntax error):

from functools import *
from inspect import *

def autoassign(_init_):
 @wraps(_init_)
 def _autoassign(self, *args, **kwargs):
 argnames, _, _, _ = getargspec(_init_)
 for name, value in zip(argnames[1:], args):
 if name.startswith("_"):
 setattr(self, name[1:], value)
 _init_(self, *args, **kwargs)

 return _autoassign

class Test(object):
 @autoassign
 def __init__(self, _foo, _bar, baz):
 print 'baz =', baz

t = Test(1, 2, 3)
print t.foo
print t.bar
print t.baz

#== the output is

baz = 3
1
2
Traceback (most recent call last):
File "/Users/andre/CrunchySVN/branches/andre/src/tools_2k.py", line
24, in exec_code
exec code in local_dict
  File "User's code", line 23, in 
AttributeError: 'Test' object has no attribute 'baz'

#==
André
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python self-evaluating strings

[Boris Borcic]

Now there's always that style :

 >>> print x

Traceback (most recent call last):
   File "", line 1, in 
 eval(x)
   File "", line 2
 Traceback (most recent call last):
  ^
SyntaxError: invalid syntax

 >>> eval(x)

Traceback (most recent call last):
   File "", line 1, in 
 eval(x)
   File "", line 2
 Traceback (most recent call last):
  ^
SyntaxError: invalid syntax
 >>>


Arnaud Delobelle wrote:
> Hi all,
> 
> An earlier post today got me thinking about "quines" (programs that 
> output themselves) in Python.  I tried to find some on the web but 
> didn't find many ([1]).  In particular I didn't find any that 
> corresponded to my instinctive (LISP-induced, probably) criterion:
> 
> def self_evaluating(s):
> "Return True if string s evaluates to itself"
> return s == eval(s)
> 
> Here is the result of my efforts so far:
> 
> 1. Starting from the classic idea (lambda x:x%x)('lambda x:x%x') I got 
> the following
> v=(lambda x:x%('"''""'+x+'"''""'))("""(lambda 
> x:x%%('"''""'+x+'"''""'))(%s)""")
> 
> 2. (Given that if s is a nonempty string, s*2 is a longer string).  
> Starting from the idea "%s %s" % (("%s %s",)*2) I got the following
> u="\"%s\" %% ((r\"%s\",)*2)" % ((r"\"%s\" %% ((r\"%s\",)*2)",)*2)
> 
> Most of my problems in creating these 2 was with finding a suitable way 
> of quoting strings that propagates well. Both u and v are one-liners.  
> I'm hoping for no funky line wrapping here.
> 
> Note: I'm not quoting the string as it makes no difference since they 
> evaluate to themselves:)
> 
> I'd like to know if anyone on the list has indulged in this 
> time-bending/mind-wasting activity before.  If so, it would be nice to 
> create a list of such expressions.
> 
> Quining's-better-than-ironing'ly yours
> 
> --Arnaud
> 
> [1] http://www.nyx.net/~gthompso/self_pyth.txt
> 
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: read and readline hanging

[Olivier Lefevre]

>> Indeed, if I do this interactively, I can tell after 3 lines that I've
>> gotten all there is to get right now and the fourth readline() call
>> hangs.
> 
> Can you really? 

Yes interactively: at the command prompt, you can tell when it's over
because you know the command you just sent and whether it requires an
answer and of which kind. Also, even if there is no answer you get a
fresh prompt when the interpreter is done.

> Unless there is some way to differentiate between the last line
> and all the other lines of a response, you can't really be sure.

Yes, that has since occurred to me. I need to echo some magic string
after each command to know that I reached the end of the answer to
the previous command. In interactive mode the prompt fulfills that
role.

> To check if there is something to read at this very moment, you
> can use any of the following methods:

Thanks for all the suggestions! That is just what I needed.

>   - select.select()
>   - the FIONREAD ioctl (the ioctl() function lives in the fcntl
> module, and the FIONREAD constant is in the termios module)
>   - set the underlying file descriptor in non-blocking mode:
> flags = fcntl.fcntl(fd, fcntl.F_GETFL)
> fcntl.fcntl(fd, fcntl.F_SETFL, flags | os.O_NDELAY)
> After that, reads on the pipe will raise an IOError exception
> with the errorcode EWOULDBLOCK.

That sounds like the simplest approach.

>   - start a thread that does blocking reads from the pipe, and
> puts the chunks it reads on a queue for your main thread to
> grab.

Yes but my python threading is worse than rudimentary. I will look
into the `trheading` module suggested by the other poster.

> For the last approach, you might be interested in my asyncproc
> module, which does exactly that.  You can download it from
> .

OK, I'll look into that, too.

Thanks again,

-- O.L.

-- 
http://mail.python.org/mailman/listinfo/python-list

explicit protocols and duck typing

[dg . google . groups]

Hi all,

As I understand it, the idea behind duck typing is that you just take
an object and if it has the methods you want to use you use it
assuming it to be the right type of object. I'm interested in
extending this idea a bit, but I feel the sort of thing I have in mind
has already been thought of. So for example, in the program I'm
writing a 'state variable' specifier can be either an integer or a
string (the string name is mapped to an integer by another function
getvarindex(name)). In this case, I can't do duck typing by seeing if
the object has a method or not, because both of the types are built in
types. I don't want to have to force the user to have objects like
StateVariableSpecifier(name). Now at the moment, what I'm doing is
accepting anything as a state variable specifier, and just passing it
through the getvarindex function when I want to use it. This sort of
specifies a protocol for state variable specifiers without making it
explicit (like the sequence or mapping protocols built in to Python).

What I'm wondering though is whether there is any value in making this
more explicit? Say, have a class which makes explicit the various
relationships involved, such as that the type of a state variable
specifier can be correct or incorrect (it has to be an int or a
string), that the value has to be correct (the integer has to be
between 0 and n for some n, and the string has to be in a dict of
names), and that there is a relationship between state variable
specifiers (int, string) and the underlying data type (the index of
the variable in an array). Making it more explicit seems like a good
idea, the question is in what way to make it more explicit. I can make
it explicit just by documenting the behaviour, or I can make it
explicit by adding code that enforces certain ways of using things.
For this simple example, it seems like just documenting it is the best
route, but I have similar issues with other more complicated parts of
the code. At the moment, a model for instance can be a Model object,
an Equation object or a tuple of functions, but this could be subject
to change in the future.

The issue I want to address is the long term maintainability of the
code when possibly many people might be contributing, the transparency
for other users, and the ease of documenting it. Any opinions?

Dan Goodman
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Replacing a package with another

[Gabriel Genellina]

En Sat, 26 Jan 2008 12:10:03 -0200, J. Pablo Fernández <[EMAIL PROTECTED]>  
escribi�:

> Is it possible to replace one package with another at runtime, that is, I
> have package a.blah which I want instead of b.blah, so I can "inject"
> functionality in an existing package?

It might be done, just assign the replacement functions/classes to the  
existing module.
This has the same warnings as the reload() function: already created  
objects maintain their original behavior, already imported names from  
modules maintain their original value, already bound names to default  
arguments maintain their original value, etc.
So it is best to do it as early as possible, but anyway some effects can't  
be avoided:

=== a.py ===
default_tax_pct = 21
print "in a, default_tax_pct=",default_tax_pct

def foo():
   print "original foo"

def tax(amount, pct=default_tax_pct):
   print amount, pct, amount*pct/100

=== path_a.py ===
import a

def foo():
   print "other foo"

print "patching a.foo",
a.foo = foo
print a.foo

print "patching a.default_tax_pct",
a.default_tax_pct = 15
print a.default_tax_pct

=== main.py ===
import a
 from a import default_tax_pct
import patch_a

print "in main, a.default_tax_pct", a.default_tax_pct
print "in main, default_tax_pct", default_tax_pct
print "calling a.foo:"
a.foo()
print "calling a.tax(100.0):"
a.tax(100.0)

=== output ===
in a, default_tax_pct= 21
patching a.foo 
patching a.default_tax_pct 15
in main, a.default_tax_pct 15
in main, default_tax_pct 21
calling a.foo:
other foo
calling a.tax(100.0):
100.0 21 21.0

-- 
Gabriel Genellina

-- 
http://mail.python.org/mailman/listinfo/python-list

strftime return value encoding (mbcs, locale, etc.)

[Giovanni Bajo]

Hello,

I am trying to find a good way to portably get the output of strftime() 
and put it onto a dialog (I'm using PyQt, but it doesn't really matter). 
The problem is that I need to decode the byte stream returned by strftime
() into Unicode.

This old bug:
http://mail.python.org/pipermail/python-bugs-list/2003-
November/020983.html

(last comment) mentions that it is "byte string in the locale's encoding".

The comment also suggests to use "mbcs" in Windows (which, AFAIK, it's 
sort of an "alias" encoding for the current Windows codepage), and to 
find out the exact encoding using locale.getpreferredencoding().

Thus, I was hoping that something like:

  strftime("%#c", localtime()).decode(locale.getpreferredencoding())

would work... but alas I was reported this exception:

  LookupError: unknown encoding: cp932

So: what is the correct code to achieve this? Will something like this 
work:

  data = strftime("%#c", localtime())
  if os.name == "nt":
 data = data.decode("mbcs")
  else:
 data = dada.decode(locale.getpreferredencoding())

Is this the correct way of doing it? (Yes, it sucks).

Shouldn't Python automatically alias whatever is returned by 
locale.getpreferredencoding() to "mbcs", so that my original code works 
portably?

Thanks in advance!
-- 
Giovanni Bajo
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Klik2 Project, Python apps on linux

[Jason Taylor]

Perhaps this would help, heres a list of our error reports
http://klik.atekon.de/feedback/details.php?e=ImportError

On 27/01/2008, Jason Taylor <[EMAIL PROTECTED]> wrote:
>
> Hi
>
> We've been working on klik2, http://code.google.com/p/klikclient/, which
> implements OSX like application files on linux (with applications working on
> all distros), In which every user desktop application is 1 file
>
> We've run into a bit of a problem with python apps,  so while we can run a
> complicated application like openoffice.org on ubuntu, fedora and suse
> from a single file we cant run any python applications such as
>
> jokosher
> gnome-specimen
> angrydd
> gausssum
> pathological
> quodlibet
> webboard
> istanbul
> exaile
> ccsm
> bittornado
> pessulus
> labyrinth
> wammu
> accerciser
>
>
> We'd like to fix this in a clean way with out resorting to nasty hacks
> involving $PYTHON_PATH.
>
> If any one has any suggestions please email me or drop by #klik on
> freenode
>
> Issue http://code.google.com/p/klikclient/issues/detail?id=144
>
> Cheers
>
> Jason Taylor
>
> --
> "Why isn't my life like a situation comedy? Why don't I have a bunch of
> friends with nothing better to do but drop by and instigate wacky
> adventures? Why aren't my conversations peppered with spontaneous
> witticisms? Why don't my friends demonstrate heartfelt concern for my well
> being when I have problems? ...I gotta get my life some writers." - Calven




-- 
"Why isn't my life like a situation comedy? Why don't I have a bunch of
friends with nothing better to do but drop by and instigate wacky
adventures? Why aren't my conversations peppered with spontaneous
witticisms? Why don't my friends demonstrate heartfelt concern for my well
being when I have problems? ...I gotta get my life some writers." - Calven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Some questions about decode/encode

[Martin v. Löwis]

>> Is there any way to solve this better?
>> I mean if I shouldn't convert the GBK string to unicode string, what
>> should I do to make SAX work?
> 
> Decode it and then encode it to utf-8 before feeding it to the parser.

The tricky part is that you also need to change the encoding declaration
in doing so, but in this case, it should be fairly simple:

unicode_doc = original_doc.decode("gbk")
unicode_doc = unicode_doc.replace('gbk','utf-8',1)
utf8_doc = unicode_doc.encode("utf-8")

This assumes that the string "gbk" occurs in the encoding declaration
as



If the encoding name has a different spelling (e.g. GBK), you need to
cater for that as well. You might want to try replacing the entire
XML declaration (i.e. everything between ), or just the
encoding= parameter. Notice that the encoding declaration may include
' instead of ", and may have additional spaces, e.g.



HTH,
Martin
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: is it a bug?

[Gabriel Genellina]

En Sun, 27 Jan 2008 14:21:20 -0200, Mr Shore <[EMAIL PROTECTED]>  
escribi�:

> import threading
> import time
> class timer(threading.Thread):
> def __init__(self,no,interval):
> threading.Thread.__init__(self)
> self.no=no
> self.interval=interval
>
> def run(self):
> while True:
> print 'Thread Object (%d), Time:%s'%(self.no,time.ctime())
> time.sleep(self.interval)
>
> def test():
> threadone=timer(1,1)
> threadtwo=timer(2,3)
> threadone.start()
> threadtwo.start()
> print 'main thread'
>
> if __name__=='__main__':
> test()
> when I run the above programme,an error comes out but ignored
> Exception exceptions.AttributeError: '_shutdown' in  from
> 'F:
> \Python25\lib\threading.pyc'> ignored

That looks like an error when Python is shutting down itself. As your  
program never ends, how did you stop it?

-- 
Gabriel Genellina

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Some questions about decode/encode

[Mark Tolonen]

>"John Machin" <[EMAIL PROTECTED]> wrote in message 
>news:[EMAIL PROTECTED]
>On Jan 27, 9:17 pm, glacier <[EMAIL PROTECTED]> wrote:
>> On 1月24日, 下午3时29分, "Gabriel Genellina" <[EMAIL PROTECTED]> 
>> wrote:
>
>*IF* the file is well-formed GBK, then the codec will not mess up when
>decoding it to Unicode. The usual cause of mess is a combination of a
>human and a text editor :-)

SAX uses the expat parser.  From the pyexpat module docs:

Expat doesn't support as many encodings as Python does, and its repertoire 
of encodings can't be extended; it supports UTF-8, UTF-16, ISO-8859-1 
(Latin1), and ASCII. If encoding is given it will override the implicit or 
explicit encoding of the document.

--Mark 

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Minimum Requirements for Python

[[EMAIL PROTECTED]]

On 25 jan, 12:50, [EMAIL PROTECTED] wrote:
> Can someone tell me the minimum requitements for Python as I can't
> find it anwhere on the site. I have 3 PC's which are only 256mb RAM,
> wanted to know if this was sufficenent.

The first machine I installed Python on was a pentium133 with 32mb
ram.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: strftime return value encoding (mbcs, locale, etc.)

[Mark Tolonen]

"Giovanni Bajo" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
> Hello,
>
> I am trying to find a good way to portably get the output of strftime()
> and put it onto a dialog (I'm using PyQt, but it doesn't really matter).
> The problem is that I need to decode the byte stream returned by strftime
> () into Unicode.
>
> This old bug:
> http://mail.python.org/pipermail/python-bugs-list/2003-
> November/020983.html
>
> (last comment) mentions that it is "byte string in the locale's encoding".
>
> The comment also suggests to use "mbcs" in Windows (which, AFAIK, it's
> sort of an "alias" encoding for the current Windows codepage), and to
> find out the exact encoding using locale.getpreferredencoding().
>
> Thus, I was hoping that something like:
>
>  strftime("%#c", localtime()).decode(locale.getpreferredencoding())
>
> would work... but alas I was reported this exception:
>
>  LookupError: unknown encoding: cp932
>
> So: what is the correct code to achieve this? Will something like this
> work:
>
>  data = strftime("%#c", localtime())
>  if os.name == "nt":
> data = data.decode("mbcs")
>  else:
> data = dada.decode(locale.getpreferredencoding())
>
> Is this the correct way of doing it? (Yes, it sucks).
>
> Shouldn't Python automatically alias whatever is returned by
> locale.getpreferredencoding() to "mbcs", so that my original code works
> portably?
>
> Thanks in advance!
> -- 
> Giovanni Bajo

Odd, what version of Python are you using?  Python 2.5 works:

>>> import time,locale
>>> time.strftime('%#c').decode(locale.getpreferredencoding()) # cp1252 on 
>>> my system
u'Sunday, January 27, 2008 12:56:30'
>>> time.strftime('%#c').decode('cp932')
u'Sunday, January 27, 2008 12:56:40'
>>> time.strftime('%#c').decode('mbcs')
u'Sunday, January 27, 2008 12:56:48'

--Mark

-- 
http://mail.python.org/mailman/listinfo/python-list

python valentine

[nurple11]

Slightly off-topic, but this is the best Valentine's Day card I've
seen in a while: http://unholidaycards.com/code.html

I think I just might get some for my lab.

#!/usr/bin/env python


from relationships import *
from alcohol import shot, beer

def valentines_day(self):
if self.dating:
if self.money == 0:
self.dating = False
elif self.num_prev_dates == 0:
self.money -= dinner()
self.money -= pointless_gift()
else:
self.money -= dinner()/sqrt(self.num_prev_dates)
if randInt(self.num_prev_dates):
self.money -= pointless_gift()/self.num_prev_dates
elif self.married:
if self.years_married < 5:
 self.money -= dinner()/(self.years_married ** 2)
else:
 pass
else:
while self.blood_alcohol < .08:
self.blood_alcohol += beer()
while self.blood_alcohol < .22:
self.blood_alcohol += shot()
sleep(86400)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Some questions about decode/encode

[John Machin]

On Jan 28, 7:47 am, "Mark Tolonen" <[EMAIL PROTECTED]>
wrote:
> >"John Machin" <[EMAIL PROTECTED]> wrote in message
> >news:[EMAIL PROTECTED]
> >On Jan 27, 9:17 pm, glacier <[EMAIL PROTECTED]> wrote:
> >> On 1月24日, 下午3时29分, "Gabriel Genellina" <[EMAIL PROTECTED]>
> >> wrote:
>
> >*IF* the file is well-formed GBK, then the codec will not mess up when
> >decoding it to Unicode. The usual cause of mess is a combination of a
> >human and a text editor :-)
>
> SAX uses the expat parser.  From the pyexpat module docs:
>
> Expat doesn't support as many encodings as Python does, and its repertoire
> of encodings can't be extended; it supports UTF-8, UTF-16, ISO-8859-1
> (Latin1), and ASCII. If encoding is given it will override the implicit or
> explicit encoding of the document.
>
> --Mark

Thank you for pointing out where that list of encodings had been
cunningly concealed. However the relevance of dropping it in as an
apparent response to my answer to the OP's question about decoding
possibly butchered GBK strings is  what?

In any case, it seems to support other 8-bit encodings e.g. iso-8859-2
and koi8-r ...

C:\junk>type gbksax.py
import xml.sax, xml.sax.saxutils
import cStringIO

unistr = u''.join(unichr(0x4E00+i) + unichr(ord('W')+i) for i in
range(4))
print 'unistr=%r' % unistr
gbkstr = unistr.encode('gbk')
print 'gbkstr=%r' % gbkstr
unistr2 = gbkstr.decode('gbk')
assert unistr2 == unistr

print "latin1 FF -> utf8 = %r" %
'\xff'.decode('iso-8859-1').encode('utf8')
print "latin2 FF -> utf8 = %r" %
'\xff'.decode('iso-8859-2').encode('utf8')
print "koi8r FF -> utf8 = %r" % '\xff'.decode('koi8-r').encode('utf8')

xml_template = """%s"""

asciidoc = xml_template % ('ascii', 'The quick brown fox etc')
utf8doc = xml_template % ('utf-8', unistr.encode('utf8'))
latin1doc = xml_template % ('iso-8859-1', 'nil illegitimati
carborundum' + '\xff')
latin2doc = xml_template % ('iso-8859-2', 'duo secundus' + '\xff')
koi8rdoc = xml_template % ('koi8-r', 'Moskva' + '\xff')
gbkdoc = xml_template % ('gbk', gbkstr)

for doc in (asciidoc, utf8doc, latin1doc, latin2doc, koi8rdoc,
gbkdoc):
f = cStringIO.StringIO()
handler = xml.sax.saxutils.XMLGenerator(f, encoding='utf8')
xml.sax.parseString(doc, handler)
result = f.getvalue()
f.close
print repr(result[result.find(''):])

C:\junk>gbksax.py
unistr=u'\u4e00W\u4e01X\u4e02Y\u4e03Z'
gbkstr='[EMAIL PROTECTED]'
latin1 FF -> utf8 = '\xc3\xbf'
latin2 FF -> utf8 = '\xcb\x99'
koi8r FF -> utf8 = '\xd0\xaa'
'The quick brown fox etc'
'\xe4\xb8\x80W\xe4\xb8\x81X\xe4\xb8\x82Y\xe4\xb8\x83Z'
'nil illegitimati carborundum\xc3\xbf'
'duo secundus\xcb\x99'
'Moskva\xd0\xaa'
Traceback (most recent call last):
  File "C:\junk\gbksax.py", line 27, in 
xml.sax.parseString(doc, handler)
  File "C:\Python25\lib\xml\sax\__init__.py", line 49, in parseString
parser.parse(inpsrc)
  File "C:\Python25\lib\xml\sax\expatreader.py", line 107, in parse
xmlreader.IncrementalParser.parse(self, source)
  File "C:\Python25\lib\xml\sax\xmlreader.py", line 123, in parse
self.feed(buffer)
  File "C:\Python25\lib\xml\sax\expatreader.py", line 211, in feed
self._err_handler.fatalError(exc)
  File "C:\Python25\lib\xml\sax\handler.py", line 38, in fatalError
raise exception
xml.sax._exceptions.SAXParseException: :1:30: unknown
encoding

C:\junk>
-- 
http://mail.python.org/mailman/listinfo/python-list

optional static typing for Python

[Russ P.]

A while back I came across a tentative proposal from way back in 2000
for optional static typing in Python:

http://www.python.org/~guido/static-typing

Two motivations were given:

-- faster code
-- better compile-time error detection

I'd like to suggest a third, which could help extend Python into the
safety-critical domain:

-- facilitates automated source-code analysis

There has been much heated debate in the past about whether Python is
appropriate for safety-critical software. Some argue that, with
thorough testing, Python code can be as reliable as code in any
language. Well, maybe. But then, a famous computer scientist once
remarked that,

"Program testing can be used to show the presence of bugs, but never
to show their absence!" --Edsger Dijkstra

The next step beyond extensive testing is automated, "static" analysis
of source-code ("static" in the sense of analyzing it without actually
running it). For example, Spark Ada is a subset of Ada with
programming by contract, and in some cases it can formally prove the
correctness of a program by static analysis.

Then there is Java Pathfinder (http://javapathfinder.sourceforge.net),
an "explicit state software model checker." The developers of JPF
wanted
to use it on a prototype safety-critical application that I wrote in
Python, but JPF only works on Java code. We considered somehow using
Jython and Jythonc, but neither did the trick. So they ended up having
someone manually convert my Python code to Java! (The problem is that
my code was still in flux, and the Java and Python versions have now
diverged.)

In any case, optional static typing in Python would help tremendously
here. The hardest part of automated conversion of Python to a
statically typed language is the problem of type inference. If the
types are explicitly declared, that problem obviously goes away.
Explicit typing would also greatly facilitate the development of a
"Python Pathfinder," so the conversion would perhaps not even be
necessary in the first place.

Note also that, while "static" type checking would be ideal,
"explicit" typing would be a major step in the right direction and
would probably be much easier to implement. That is, provide a syntax
to explicitly declare types, then just check them at run time. A
relatively simple pre-processor could be implemented to convert the
explicit type declarations into "isinstance" checks or some such
thing. (A pre-processor command-line argument could be provided to
disable the type checks for more efficient production runs if
desired.)

I noticed that Guido has expressed further interest in static typing
three or four years ago on his blog. Does anyone know the current
status of this project? Thanks.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: strftime return value encoding (mbcs, locale, etc.)

[Martin v. Löwis]

>   LookupError: unknown encoding: cp932

What Python version are you using? cp932 is supported cross-platform
since Python 2.4.

> So: what is the correct code to achieve this? Will something like this 
> work:
> 
>   data = strftime("%#c", localtime())
>   if os.name == "nt":
>  data = data.decode("mbcs")
>   else:
>  data = dada.decode(locale.getpreferredencoding())
>
> Is this the correct way of doing it?

Not necessarily. On some systems, and in some locales, Python will not
have any codec that converts the locale's encoding to Unicode.

In such a case, using ASCII with replacement characters might be the
best bet, as long as the locale's charset is an ASCII superset (i.e.
you don't work on an EBCDIC machine).

> Shouldn't Python automatically alias whatever is returned by 
> locale.getpreferredencoding() to "mbcs", so that my original code works 
> portably?

No. The "mbcs" codec has a slightly different semantics from the cp932
codec, on your system. Specifically, the "mbcs" codec might map
characters as approximations, whereas the cp932 codec will give errors
if a certain Unicode character is not supported in the target character
set.

Regards,
Martin
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: translating Python to Assembler

[John Machin]

On Jan 27, 10:23 pm, [EMAIL PROTECTED] wrote:
> >> >[EMAIL PROTECTED]:~$ ndisasm error.txt
> >> >  54push sp
> >> >0001  686973push word 0x7369
> >> >0004  206973and [bx+di+0x73],ch
> >> >0007  206E6Fand [bp+0x6f],ch
> >> >000A  7420  jz 0x2c
> >> >000C  61popa
> >> >000D  7373  jnc 0x82
> >> >000F  656D  gs insw
> >> >0011  626C65bound bp,[si+0x65]
> >> >0014  722E  jc 0x44
> >> >0016  2Edb 0x2E
> >> >0017  2Edb 0x2E
> >> >0018  0Adb 0x0A
>
> >> >:/
>
> >> not sure what you're saying. Sure looks like assembler to me. Take the
> >> '54   push sp'. The 54 is an assembler opcode for push and the sp is
> >> the stack pointer, on which it is operating.
>
> >go troll somewhere else (you obviously don't know anything about
> >assembler and don't want to learn anything about Python).
>
> >-- bjorn
>
> before you start mouthing off, maybe you should learn assembler. If
> you're really serious, go to the Intel site and get it from the horses
> mouth. The Intel manual on assembler lists the mneumonics as well as
> the opcodes for each instruction. It's not called the Intel Machine
> Code and Assembler Language Manual. It's the bible on assembly
> language, written by Intel.
>
> If you're not so serious, here's a URL explaining it, along with an
> excerpt from the article:
>
> http://en.wikipedia.org/wiki/X86_assembly_language
>
> Each x86 assembly instruction is represented by a mnemonic, which in
> turn directly translates to a series of bytes which represent that
> instruction, called an opcode. For example, the NOP instruction
> translates to 0x90 and the HLT instruction translates to 0xF4. Some
> opcodes have no mnemonics named after them and are undocumented.
> However processors in the x86-family may interpret undocumented
> opcodes differently and hence might render a program useless. In some
> cases, invalid opcodes also generate processor exceptions.
>
> As far as this line from your code above:
>
> 0001  686973push word 0x7369
>
> 68 of 686973 is the opcode for PUSH. Go on, look it up. The 6973 is
> obviously the word address, 0x7369. Or, do you think that's
> coincidence?
>
> Don't fucking tell me about assembler, you asshole. I can read
> disassembled code in my sleep.

What was originally posted was:
"""
[EMAIL PROTECTED]:~$ cat error.txt
This is not assembler...

[EMAIL PROTECTED]:~$ ndisasm error.txt
  54push sp
0001  686973push word 0x7369
0004  206973and [bx+di+0x73],ch
[snip]
"""

Read it again -- he's "disassembled" the text "This is not
assembler..."

54 -> "T"
686973 -> "his"
206973 -> " is"

but you say "68 of 686973 is the opcode for PUSH. Go on, look it up.
The 6973 is obviously the word address, 0x7369. Or, do you think
that's coincidence?"

You are a genius of a kind encountered only very rarely. Care to share
with us your decryption of the Voynich manuscript?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: read and readline hanging

[Thomas Bellman]

Olivier Lefevre <[EMAIL PROTECTED]> wrote:

>> Can you really? 

> Yes interactively: at the command prompt, you can tell when it's over
> because you know the command you just sent and whether it requires an
> answer and of which kind. Also, even if there is no answer you get a
> fresh prompt when the interpreter is done.

Then you just need to encode that knowledge into your program.

>> Unless there is some way to differentiate between the last line
>> and all the other lines of a response, you can't really be sure.

> Yes, that has since occurred to me. I need to echo some magic string
> after each command to know that I reached the end of the answer to
> the previous command. In interactive mode the prompt fulfills that
> role.

And hope that that "magic string" does not occur somewhere within
the response...

> Yes but my python threading is worse than rudimentary. I will look
> into the `trheading` module suggested by the other poster.

I think you would be better off looking into the correctly spelled
'threading' module rather than the misspelled 'trheading' module. :-)


-- 
Thomas Bellman,   Lysator Computer Club,   Linköping University,  Sweden
"God is real, but Jesus is an integer."  !  bellman @ lysator.liu.se
 !  Make Love -- Nicht Wahr!
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: explicit protocols and duck typing

[Arnaud Delobelle]

On Jan 27, 7:10 pm, [EMAIL PROTECTED] wrote:
> Hi all,
>
> As I understand it, the idea behind duck typing is that you just take
> an object and if it has the methods you want to use you use it
> assuming it to be the right type of object. I'm interested in
> extending this idea a bit, but I feel the sort of thing I have in mind
> has already been thought of. So for example, in the program I'm
> writing a 'state variable' specifier can be either an integer or a
> string (the string name is mapped to an integer by another function
> getvarindex(name)). In this case, I can't do duck typing by seeing if
> the object has a method or not, because both of the types are built in
> types. I don't want to have to force the user to have objects like
> StateVariableSpecifier(name). Now at the moment, what I'm doing is
> accepting anything as a state variable specifier, and just passing it
> through the getvarindex function when I want to use it. This sort of
> specifies a protocol for state variable specifiers without making it
> explicit (like the sequence or mapping protocols built in to Python).
>
> What I'm wondering though is whether there is any value in making this
> more explicit? Say, have a class which makes explicit the various
> relationships involved, such as that the type of a state variable
> specifier can be correct or incorrect (it has to be an int or a
> string), that the value has to be correct (the integer has to be
> between 0 and n for some n, and the string has to be in a dict of
> names), and that there is a relationship between state variable
> specifiers (int, string) and the underlying data type (the index of
> the variable in an array). Making it more explicit seems like a good
> idea, the question is in what way to make it more explicit. I can make
> it explicit just by documenting the behaviour, or I can make it
> explicit by adding code that enforces certain ways of using things.

I would filter uses of a state variable specifier through a 'decode'
function:

def decode_svs(svs):
for decode in decode_as_int, decode_as_str:
try:
return decode_as_int(svs)
except DecodeError:
continue
raise DecodeError("Invalid svs")

That could be done via overloading (see below)

> For this simple example, it seems like just documenting it is the best
> route, but I have similar issues with other more complicated parts of
> the code. At the moment, a model for instance can be a Model object,
> an Equation object or a tuple of functions, but this could be subject
> to change in the future.

What does object have to promise to be able to do in order to be a
'model'?

> The issue I want to address is the long term maintainability of the
> code when possibly many people might be contributing, the transparency
> for other users, and the ease of documenting it. Any opinions?

Maybe I'm way off mark here, but have you looked at overloading/
generic functions?

The concept is explained in PEP 3124 [http://www.python.org/dev/peps/
pep-3124/]

There's an implementation by Philip J. Eby in the svn repository:

Some documentation:
http://svn.python.org/view/sandbox/trunk/Overload3K/overloading.txt?rev=45971&view=markup

The implementation:
http://svn.python.org/view/sandbox/trunk/Overload3K/overloading.py?rev=45971&view=markup
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: optional static typing for Python

[André]

On Jan 27, 6:19 pm, "Russ P." <[EMAIL PROTECTED]> wrote:
> A while back I came across a tentative proposal from way back in 2000
> for optional static typing in Python:
>
> http://www.python.org/~guido/static-typing
>
> Two motivations were given:
>
> -- faster code
> -- better compile-time error detection
>
> I'd like to suggest a third, which could help extend Python into the
> safety-critical domain:
>
> -- facilitates automated source-code analysis
>
> There has been much heated debate in the past about whether Python is
> appropriate for safety-critical software. Some argue that, with
> thorough testing, Python code can be as reliable as code in any
> language. Well, maybe. But then, a famous computer scientist once
> remarked that,
>
> "Program testing can be used to show the presence of bugs, but never
> to show their absence!" --Edsger Dijkstra
>
> The next step beyond extensive testing is automated, "static" analysis
> of source-code ("static" in the sense of analyzing it without actually
> running it). For example, Spark Ada is a subset of Ada with
> programming by contract, and in some cases it can formally prove the
> correctness of a program by static analysis.
>
> Then there is Java Pathfinder (http://javapathfinder.sourceforge.net),
> an "explicit state software model checker." The developers of JPF
> wanted
> to use it on a prototype safety-critical application that I wrote in
> Python, but JPF only works on Java code. We considered somehow using
> Jython and Jythonc, but neither did the trick. So they ended up having
> someone manually convert my Python code to Java! (The problem is that
> my code was still in flux, and the Java and Python versions have now
> diverged.)
>
> In any case, optional static typing in Python would help tremendously
> here. The hardest part of automated conversion of Python to a
> statically typed language is the problem of type inference. If the
> types are explicitly declared, that problem obviously goes away.
> Explicit typing would also greatly facilitate the development of a
> "Python Pathfinder," so the conversion would perhaps not even be
> necessary in the first place.
>
> Note also that, while "static" type checking would be ideal,
> "explicit" typing would be a major step in the right direction and
> would probably be much easier to implement. That is, provide a syntax
> to explicitly declare types, then just check them at run time. A
> relatively simple pre-processor could be implemented to convert the
> explicit type declarations into "isinstance" checks or some such
> thing. (A pre-processor command-line argument could be provided to
> disable the type checks for more efficient production runs if
> desired.)
>
> I noticed that Guido has expressed further interest in static typing
> three or four years ago on his blog. Does anyone know the current
> status of this project? Thanks.

Perhaps this: http://www.python.org/dev/peps/pep-3107/ might be
relevant?
André
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: optional static typing for Python

[Jarek Zgoda]

Russ P. pisze:

> I noticed that Guido has expressed further interest in static typing
> three or four years ago on his blog. Does anyone know the current
> status of this project? Thanks.

I thought it was april fools joke?

-- 
Jarek Zgoda
http://zgodowie.org/

"We read Knuth so you don't have to" - Tim Peters
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: optional static typing for Python

[Russ P.]

On Jan 27, 2:36 pm, Jarek Zgoda <[EMAIL PROTECTED]> wrote:
> Russ P. pisze:
>
> > I noticed that Guido has expressed further interest in static typing
> > three or four years ago on his blog. Does anyone know the current
> > status of this project? Thanks.
>
> I thought it was april fools joke?

On January 21, 2000? Which calendar do you use?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: translating Python to Assembler

[ajaksu]

This message got huge :/

Sorry for being so cryptic and unhelpful. I now believe that you're
incurring in a (quite deep) misunderstanding and wish to make things
clear for both of us :)

On Jan 27, 6:58 am, [EMAIL PROTECTED] wrote:
> On Fri, 25 Jan 2008 17:44:07 -0800 (PST), ajaksu <[EMAIL PROTECTED]>
> wrote:
>
>
>
> >On Jan 25, 11:36 pm, ajaksu <[EMAIL PROTECTED]> wrote:
> >> On Jan 25, 11:10 pm, [EMAIL PROTECTED] wrote:
> >[...]
>
> >Gaah, is this what's going on?
>
> >[EMAIL PROTECTED]:~$ cat error.txt
> >This is not assembler...
>
> >[EMAIL PROTECTED]:~$ ndisasm error.txt
> >  54push sp
> >0001  686973push word 0x7369
> >0004  206973and [bx+di+0x73],ch
> >0007  206E6Fand [bp+0x6f],ch
> >000A  7420  jz 0x2c
> >000C  61popa
> >000D  7373  jnc 0x82
> >000F  656D  gs insw
> >0011  626C65bound bp,[si+0x65]
> >0014  722E  jc 0x44
> >0016  2Edb 0x2E
> >0017  2Edb 0x2E
> >0018  0Adb 0x0A
>
> >:/
>
> not sure what you're saying. Sure looks like assembler to me. Take the
> '54   push sp'. The 54 is an assembler opcode for push and the sp is
> the stack pointer, on which it is operating.

What I did above was:
1- create a file called "error.txt" that contains the string "This is
not assembler..."
2- show the contents of the file ("cat" being the relevant command)
3- run the NetWideDisassembler (ndisasm) on error.txt
4- watch as it "disassembled" the text file (in fact, "assembling" the
code above reconstructs part of the string!)
5-  conclude that you were misguided by this behavior of
disassemblers, for AFAIK .pyc files contain Python
"opcodes" (bytecode), that in no way I can think of could be parsed by
a generic disassembler
6- form a belief that you were trying to understand meaningless
"assembler" like the above (that would have no bearing on what Python
does!)

Now, it seems that we're in flaming mode and that is unfortunate,
because I do believe in your expertise. In part, because my father was
a systems analyst for IBM mainframes and knows (a huge) lot about
informatics. However, I've seen him, due to simple misunderstandings
like this, building a complex scenario to explain his troubles with
MSWord. I believe this is what's happening here, so I suggest that we
take a step back and stop calling names.

Given that you're in the uncomfortable place of the "troll assigned by
votes" outsider in this issue, let me expose some relevant data. The
people you're pissed off with (and vice-versa) are very competent and
knowledgeable Python (and other languages) programmers, very kind to
newcomers and notably helpful (as you might find out lurking in this
newsgroup or reading the archives). They spend time and energy helping
people to solve problems and understand the language. Seriously, they
know about assembler (a lot more than I do) and how Python works. And
they know and respect each other.

Now, your attitude and faith in your own assumptions (of which,
"the .pyc contains assembler" in special) was both rude and upsetting.
This doesn't mean that you're not an assembler expert (I believe you
are). But it seemed like you were trying to teach us how Python works,
and that was considered offensive, specially due to your words.

OTOH, my responses were cryptic, unhelpful and smell of "mob
thinking". While Steven D'Aprano and others showed a lot more of
patience and willingness to help. So please forgive me and please PAY
ATTENTION to those trying to HELP and make things clearer to you.

As a simple example of my own e Dunning-Kruger effect, I was sure I'd
get errors on trying to "assemble" the output of the disassembling,
but it does roundtrip part of the string and I was baffled. I'd guess
you know why, I have no idea. The 0x74 finding was also curious, you
are indeed getting part of the binary format of bytecode, but (AFAICT)
you won't find real assembler there.

In summary, you can show us what you know and put your knowledge
(instead of what you got wrong and how you upset people) in focus. Try
to set things right. Believe me, this here community packs an uncommon
amount of greatness and openness.

HTH,
Daniel
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: optional static typing for Python

[Russ P.]

On Jan 27, 2:49 pm, "André" <[EMAIL PROTECTED]> wrote:
> On Jan 27, 6:19 pm, "Russ P." <[EMAIL PROTECTED]> wrote:
>
>
>
> > A while back I came across a tentative proposal from way back in 2000
> > for optional static typing in Python:
>
> >http://www.python.org/~guido/static-typing
>
> > Two motivations were given:
>
> > -- faster code
> > -- better compile-time error detection
>
> > I'd like to suggest a third, which could help extend Python into the
> > safety-critical domain:
>
> > -- facilitates automated source-code analysis
>
> > There has been much heated debate in the past about whether Python is
> > appropriate for safety-critical software. Some argue that, with
> > thorough testing, Python code can be as reliable as code in any
> > language. Well, maybe. But then, a famous computer scientist once
> > remarked that,
>
> > "Program testing can be used to show the presence of bugs, but never
> > to show their absence!" --Edsger Dijkstra
>
> > The next step beyond extensive testing is automated, "static" analysis
> > of source-code ("static" in the sense of analyzing it without actually
> > running it). For example, Spark Ada is a subset of Ada with
> > programming by contract, and in some cases it can formally prove the
> > correctness of a program by static analysis.
>
> > Then there is Java Pathfinder (http://javapathfinder.sourceforge.net),
> > an "explicit state software model checker." The developers of JPF
> > wanted
> > to use it on a prototype safety-critical application that I wrote in
> > Python, but JPF only works on Java code. We considered somehow using
> > Jython and Jythonc, but neither did the trick. So they ended up having
> > someone manually convert my Python code to Java! (The problem is that
> > my code was still in flux, and the Java and Python versions have now
> > diverged.)
>
> > In any case, optional static typing in Python would help tremendously
> > here. The hardest part of automated conversion of Python to a
> > statically typed language is the problem of type inference. If the
> > types are explicitly declared, that problem obviously goes away.
> > Explicit typing would also greatly facilitate the development of a
> > "Python Pathfinder," so the conversion would perhaps not even be
> > necessary in the first place.
>
> > Note also that, while "static" type checking would be ideal,
> > "explicit" typing would be a major step in the right direction and
> > would probably be much easier to implement. That is, provide a syntax
> > to explicitly declare types, then just check them at run time. A
> > relatively simple pre-processor could be implemented to convert the
> > explicit type declarations into "isinstance" checks or some such
> > thing. (A pre-processor command-line argument could be provided to
> > disable the type checks for more efficient production runs if
> > desired.)
>
> > I noticed that Guido has expressed further interest in static typing
> > three or four years ago on his blog. Does anyone know the current
> > status of this project? Thanks.
>
> Perhaps this:http://www.python.org/dev/peps/pep-3107/might be
> relevant?
> André

Thanks. If I read this correctly, this PEP is on track for Python 3.0.
Wonderful!

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python System information

[NMBooker]

On Jan 27, 2:23 pm, Martin Saturka <[EMAIL PROTECTED]> wrote:
> > How can i get system information like CPU load and RAM usage in linux.
>
> What about 'pystatgrab'?
> It provides good info, with a limitation - it does not have CPU info
> for particular CPUs, it takes just the cumulative CPU 
> info.http://www.i-scream.org/pystatgrab/http://packages.debian.org/statgrab
>
> M.

Brilliant.  Sorry about my misleading post I didn't know about
statgrab.

Thanks M.

Nick Booker
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: optional static typing for Python

[Jarek Zgoda]

Russ P. pisze:

>>> I noticed that Guido has expressed further interest in static typing
>>> three or four years ago on his blog. Does anyone know the current
>>> status of this project? Thanks.
>> I thought it was april fools joke?
> 
> On January 21, 2000? Which calendar do you use?

Static typing in Python is usual theme of april fools jokes.

-- 
Jarek Zgoda
http://zgodowie.org/

"We read Knuth so you don't have to" - Tim Peters
-- 
http://mail.python.org/mailman/listinfo/python-list

Python Genetic Algorithm

[Max]

Hi all. I'm just getting introduced to Python (mostly through Dive
Into Python), and I've decided to use it for a project where I have to
write my own Genetic Algorithm. Even if you don't know about GAs, you
might be able to help with an issue I'm having. I'm just starting the
project off, so I'm still in the conceptual phase, and I'm stuck on
how I'm going to be able to implement something.

In GAs, you operate on a Population of solutions. Each Individual from
the Population is a potential solution to the problem you're
optimizing, and Individuals have what's called a chromosome - a
specification of what it contains. For example, common chromosomes are
bit strings, lists of ints/floats, permutations...etc. I'm stuck on
how to implement the different chromosomes. I have a Population class,
which is going to contain a list of Individuals. Each individual will
be of a certain chromosome. I envision the chromosomes as subclasses
of an abstract Individual class, perhaps all in the same module. I'm
just having trouble envisioning how this would be coded at the
population level. Presumably, when a population is created, a
parameter to its __init__ would be the chromosome type, but I don't
know how to take that in Python and use it to specify a certain class.

I'm doing something similar with my crossover methods, by specifying
them as functions in a module called Crossover, importing that, and
defining

crossover_function = getattr(Crossover, "%s_crossover" % xover)

Where xover is a parameter defining the type of crossover to be used.
I'm hoping there's some similar trick to accomplish what I want to do
with chromosomes - or maybe I'm going about this completely the wrong
way, trying to get Python to do something it's not made for. Any help/
feedback would be wonderful.

Thanks,
Max Martin
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: optional static typing for Python

[Russ P.]

On Jan 27, 3:08 pm, Jarek Zgoda <[EMAIL PROTECTED]> wrote:
> Russ P. pisze:
>
> >>> I noticed that Guido has expressed further interest in static typing
> >>> three or four years ago on his blog. Does anyone know the current
> >>> status of this project? Thanks.
> >> I thought it was april fools joke?
>
> > On January 21, 2000? Which calendar do you use?
>
> Static typing in Python is usual theme of april fools jokes.

I hope Guido doesn't find out about that!

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: optional static typing for Python

[Arnaud Delobelle]

On Jan 27, 11:00 pm, "Russ P." <[EMAIL PROTECTED]> wrote:
> On Jan 27, 2:49 pm, "André" <[EMAIL PROTECTED]> wrote:
> > Perhaps this:http://www.python.org/dev/peps/pep-3107/mightbe
> > relevant?
> > André
>
> Thanks. If I read this correctly, this PEP is on track for Python 3.0.
> Wonderful!

Note that annotations do not provide explicit typing, AFAIK:

def f(x:int) -> int: return x*2

is stricly equivalent to

def f(x): return x*2
f.__annotations__ = {'x':int, 'return':int}

You still need to write a type-checking wrapper. PEP 3107 mentions two
such tools:
* http://oakwinter.com/code/typecheck/
* http://maxrepo.info/taxonomy/term/3,6/all
Neither require annotations.

-- 
http://mail.python.org/mailman/listinfo/python-list