Re: python list handling and Lisp list handling

[namekuseijin]

On Apr 26, 1:31 am, Steven D'Aprano  wrote:
> On Fri, 24 Apr 2009 21:01:10 -0700, Carl Banks wrote:
> > That's because Python lists aren't lists.
>
> Surely you meant to say that Lisp lists aren't lists?
>
> It-all-depends-on-how-you-define-lists-ly y'rs,

Yeah, the List Processing language got it all wrong by not going with
arrays like Python...
--
http://mail.python.org/mailman/listinfo/python-list

Re: python list handling and Lisp list handling

[namekuseijin]

On Apr 25, 4:34 am, Michele Simionato 
wrote:
> which has some feature you may like. For instance,
> there is a weak form of pattern matching built-in:
>
> >>> head, *tail = [1,2,3] # Python 3.0 only!
> >>> head
> 1
> >>> tail
>
> [2, 3]

Good seeing yet another long time Perl feature finally brought in. ;)
--
http://mail.python.org/mailman/listinfo/python-list

Re: Lisp mentality vs. Python mentality

[namekuseijin]

Ciprian Dorin, Craciun wrote:

On Sun, Apr 26, 2009 at 7:54 AM, Steven D'Aprano
 wrote:
I liked very much your implementation for the compare function, it
is very short and at the same time readable:


def compare(a, b, comp=operator.eq):
return (len(a) == len(b)) and all(comp(*t) for t in zip(a, b))


But I have only one problem, it is suboptimal, in the sense that:
* it constructs two intermediary lists (the list comprehension and
the zip call);



* it evaluates all the elements, even if one is false at the beginning;


This evaluates just until finding one that is false:

 return (len(a) == len(b)) and not any(not comp(*t) for t in 
(zip(a, b)))


plus the zip call enclosed in parentheses got turned into an iterator.

>>> def compare(a, b, comp=operator.eq):
... return (len(a) == len(b)) and not any(not comp(a,b) for (a,b) in 
(zip(a, b)))

...
>>> compare( [1,2,3], [1,3,3] )
False
>>> compare( [1,2,3], [1,2,3] )
True
--
http://mail.python.org/mailman/listinfo/python-list

Re: Lisp mentality vs. Python mentality

[Ciprian Dorin, Craciun]

On Sun, Apr 26, 2009 at 8:11 AM, Steven D'Aprano
 wrote:
> On Sat, 25 Apr 2009 10:30:56 +0200, Martin v. Löwis wrote:
>
>     Ok... Then what's pythonic? Please give a pythonic
>     implementation...
 Use the builtin a==b, similar to (equal a b)
>>>
>>>     But how about extensibility?
>>
>> == is extensible. To compare two things for equality, use ==.
>>
>> This is what Carl Banks referred in his original posting. You just
>> *don't* implement a function that compares two lists, not even as an
>> exercise for estetic, optimal, and useful implementations - because
>> you'll know that it won't be useful, anyway, if you can already use the
>> builtin == in the first place.
>>
>> I see that you allow for a different comparison function. I do wonder
>> what the use case for this is - in what application do you have to
>> compare two lists for equality, and the item's __eq__ is inappropriate?
>
> The above doesn't really compare for equality, it's a generic element-by-
> element comparison function, and so it is inappropriate to contrast it to
> __eq__ alone. Defaulting to equality testing is misleading, and if I were
> writing such a function I'd remove the default.
>
> compare(a, b, operator.eq) gives the same result as the simpler a == b,
> but compare(a, b, operator.lt) does something very different to a < b. I
> can't think of an application for element-by-element comparisons off the
> top of my head, but if the numpy people use it, there must be a need :)
>
>
> --
> Steven
> --

I agree with your comment, the presented function compare does
more than this, in fact checks if the elements in the two functions
match a given binary predicate. (In Scheme this is named "andmap")

About the compare (a, b, operator.lt) it does the same as a < b,
where a and b are lists of numbers.

An usage for the compare function (as I've shown in a previous
post to this thread) could also have been checking a list of strings
if they match to a list of regular expressions (we rename the function
compare to the name "match" as it is much general):
match (re.match, regexps, strings)

About the defaults, I really, really, agree with your comment:
"Defaulting to equality testing is misleading"... Most of the times
equality means equality by value, but sometimes you need the equality
to be more relaxed (maybe ignore case, maybe ignore spaces, or maybe
for real numbers to ignore a difference smaller than a chosen delta
(those writing scientific applications know this too well))...

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

Re: Lisp mentality vs. Python mentality

[Ciprian Dorin, Craciun]

On Sun, Apr 26, 2009 at 7:54 AM, Steven D'Aprano
 wrote:
> On Sat, 25 Apr 2009 10:50:50 +0300, Ciprian Dorin, Craciun wrote:
>
>> On Sat, Apr 25, 2009 at 10:43 AM,   wrote:
>>> Ciprian Dorin, Craciun:
 Python way:
 -
 def eq (a, b) :
     return a == b

 def compare (a, b, comp = eq) :
     if len (a) != len (b) :
         return False
     for i in xrange (len (a)) :
         if not comp (a[i], b[i]) :
             return False
     return True
>>>
>>> That's not "pythonic".
>>>
>>> Bye,
>>> bearophile
>>> --
>>> http://mail.python.org/mailman/listinfo/python-list
>>
>>     Ok... Then what's pythonic? Please give a pythonic implementation...
>
> Don't re-invent the wheel. Instead of creating your own functions, use
> existing tools to your advantage.
>
> import operator
>
> def compare(a, b, comp=operator.eq):
>     if len(a) != len(b):
>         return False
>     for a, b in zip(a, b):
>         if not comp(a[i], b[i]):
>             return False
>     return True
>
>
> But we can re-write that to be even more pythonic, by using the built-in
> all():
>
> def compare(a, b, comp=operator.eq):
>     if len(a) != len(b):
>         return False
>    return all(comp(x, y) for (x, y) in zip(a, b))
>
> or even:
>
> def compare(a, b, comp=operator.eq):
>     return (len(a) == len(b)) and all(comp(*t) for t in zip(a, b))
>
>
> (All the above are untested, so please excuse any errors.)
>
>
>>     Ciprian Craciun.
>>
>>     P.S.: Also, I'm tired of hearing about the pythonic way... Where
>> do I find a definitive description about the pythonic way?
>
> There is no such thing as a definitive description of pythonic -- it is
> like art, and pornography: you can recognise it when you see it (except
> when you can't).
>
> However, you can get close by doing:
>
> import this
>
> in the Python interactive interpreter. Or from a shell prompt:
>
> python -m this
>
>
>> I think that
>> this word is used only when someone sees something that he doesn't like,
>> he doesn't know what he doesn't like at it, and just goes to say its
>> un-pythonic, without saying what would be... Wouldn't be just easier to
>> say "I don't know" or "I doesn't feel right to me"?
>
> I think that there's a risk that people over-use unpythonic when they
> mean "I don't like it", but that doesn't mean that pythonic isn't a
> meaningful concept. However, it is a matter of degree, not kind: like
> mole-hills and mountains, unpythonic and pythonic are very different
> things, but there's no precise dividing line between them.
>
>
> --
> Steven

I liked very much your implementation for the compare function, it
is very short and at the same time readable:

> def compare(a, b, comp=operator.eq):
> return (len(a) == len(b)) and all(comp(*t) for t in zip(a, b))

But I have only one problem, it is suboptimal, in the sense that:
* it constructs two intermediary lists (the list comprehension and
the zip call);
* it evaluates all the elements, even if one is false at the beginning;

So, could you overcome these problems?

About the pythonic vs unpythonic words, I agree with you, there
are ofter overused and misused...

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

Re: Lisp mentality vs. Python mentality

[namekuseijin]

Paul Rubin wrote:

Python tries to be simple and pragmatic while not aiming for as
heavy-duty applications as Common Lisp.  Scheme is more of a research
language that's way past its prime.  If you like Scheme, you should
try Haskell.  Python has the motto "practicality beats purity".
With Haskell, it's exactly the opposite ;-).


Going from Scheme to Haskell is about the same as going from Python to 
Ruby:  you get far more concise and obfuscated syntax and get boggled 
down in tons of different ways to do the same thing.

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

Re: Lisp mentality vs. Python mentality

[anonymous . c . lisper]

On Apr 25, 2:06 am, Carl Banks  wrote:
> In answering the recent question by Mark Tarver, I think I finally hit
> on why Lisp programmers are the way they are (in particular, why they
> are often so hostile to the "There should only be one obvious way to
> do it" Zen).
>
> Say you put this task to a Lisp and a Python programmer: Come up with
> a good, generic, reusable way to compare two lists.  What are their
> respective trains of thought?
>
> Lisp programmer:
>
> Well, there is a standard function called mismatch that does it, but I
> can't recommend it.  First of all, you don't know where that
> function's been.  Anyone and their mother could have worked on it, did
> they have good, sound programming practice in mind when they wrote
> it?  Of course not.  Let's be real here, we have to implement this by
> hand.
>
> (defun lists-are-equal (a b)
>    (or (and (not a) (not b))
>        (and (= (car a) (car b)) (lists-are-equal (cdr a) (cdr b
>
> There, much better than the standard function, and better yet, it's in
> the *absolute minimal form possible*.  There is no way to express list
> comparison in a more reduced form.  It's almost erotic how awesome it
> is.  I'm---whoa, ok, I'm getting a little excited now, settle down.
> Well, come to think of it, that's really not that good.  First of all
> it's a function.  I mean, it just sits there and does nothing till you
> call it.  How boring is that?  It can't react to the current
> situation.  Plus it compares all lists the same way, and that is
> really inefficient.  Every list compare is a new problem.  Different
> lists need different comparative strategies.  This function simply
> won't do.  I need a macro that can intelligently compile the right
> list compare methodology in.  For instance, if we want to compare two
> lists that are known at compile time, we don't want to waste time
> comparing them at runtime.  No, the macro must detect constant
> arguments and special case them.  Good start.  Now, we have to
> consider the conditions this comparison is being done under.  If the
> user is passing the result of a sort to this macro, it's almost
> certain that they are trying to see whether the lists have the same
> elements.  We can do that a lot more efficiently with a countset.  So
> let's have the macro check to see if the forms passed to it are all
> sort calls.  Better yet, let's check for my own powerful sort macro.
> Hmm.  Wait... I think my 4600-line sort macro already checks its
> calling context to see if its results are being fed to a list
> comparison.  I'll have to refactor that together with this macro.  Ok,
> good, now I am sure other users will eventually want to customize list
> comparison for their own use, after all every list comparison is
> different and I can't possibly anticipate all of them.  A user needs
> to be able to adapt to the situation, so it's vitally important to
> create a plug-in infrastructure to give them that flexibility.  Now,
> what about exceptions, there's a millions ways to deal with that...
>
> ...and so on until eyelids can no longer stay open
>
> Python programmer:
>
> a == b.  Next question.
>
> Carl Banks, who might be exaggerating
>
> ...a little.

(equal a b) or (equalp a b)

Next question??

I understand where you are going with the analogy, but I think a lot
of what you describe as 'over-thinking' of the problem in lisp comes
from people having an honest desire to answer the /right/ question.

Lisp gives you a bit of granularity with regard to certain things
(like comparison), that in many languages amount to a single '=='
operator. I /believe/ that this is because of its origins in symbolic
programming.

You don't compare numeric functions in Perl and C, and then say 'Oh
those silly C programmers over-thinking things, they must have 10
different types of numbers!'
--
http://mail.python.org/mailman/listinfo/python-list

Re: Lisp mentality vs. Python mentality

[Steven D'Aprano]

On Sat, 25 Apr 2009 10:30:56 +0200, Martin v. Löwis wrote:

 Ok... Then what's pythonic? Please give a pythonic
 implementation...
>>> Use the builtin a==b, similar to (equal a b)
>> 
>> But how about extensibility?
> 
> == is extensible. To compare two things for equality, use ==.
> 
> This is what Carl Banks referred in his original posting. You just
> *don't* implement a function that compares two lists, not even as an
> exercise for estetic, optimal, and useful implementations - because
> you'll know that it won't be useful, anyway, if you can already use the
> builtin == in the first place.
> 
> I see that you allow for a different comparison function. I do wonder
> what the use case for this is - in what application do you have to
> compare two lists for equality, and the item's __eq__ is inappropriate?

The above doesn't really compare for equality, it's a generic element-by-
element comparison function, and so it is inappropriate to contrast it to 
__eq__ alone. Defaulting to equality testing is misleading, and if I were 
writing such a function I'd remove the default.

compare(a, b, operator.eq) gives the same result as the simpler a == b, 
but compare(a, b, operator.lt) does something very different to a < b. I 
can't think of an application for element-by-element comparisons off the 
top of my head, but if the numpy people use it, there must be a need :)


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

Re: Lisp mentality vs. Python mentality

[Steven D'Aprano]

On Sat, 25 Apr 2009 10:50:50 +0300, Ciprian Dorin, Craciun wrote:

> On Sat, Apr 25, 2009 at 10:43 AM,   wrote:
>> Ciprian Dorin, Craciun:
>>> Python way:
>>> -
>>> def eq (a, b) :
>>>     return a == b
>>>
>>> def compare (a, b, comp = eq) :
>>>     if len (a) != len (b) :
>>>         return False
>>>     for i in xrange (len (a)) :
>>>         if not comp (a[i], b[i]) :
>>>             return False
>>>     return True
>>
>> That's not "pythonic".
>>
>> Bye,
>> bearophile
>> --
>> http://mail.python.org/mailman/listinfo/python-list
> 
> Ok... Then what's pythonic? Please give a pythonic implementation...

Don't re-invent the wheel. Instead of creating your own functions, use 
existing tools to your advantage.

import operator

def compare(a, b, comp=operator.eq):
    if len(a) != len(b):
        return False
    for a, b in zip(a, b):
        if not comp(a[i], b[i]):
            return False
    return True


But we can re-write that to be even more pythonic, by using the built-in 
all():

def compare(a, b, comp=operator.eq):
    if len(a) != len(b):
        return False
return all(comp(x, y) for (x, y) in zip(a, b))

or even:

def compare(a, b, comp=operator.eq):
    return (len(a) == len(b)) and all(comp(*t) for t in zip(a, b))


(All the above are untested, so please excuse any errors.)


> Ciprian Craciun.
> 
> P.S.: Also, I'm tired of hearing about the pythonic way... Where
> do I find a definitive description about the pythonic way? 

There is no such thing as a definitive description of pythonic -- it is 
like art, and pornography: you can recognise it when you see it (except 
when you can't).

However, you can get close by doing:

import this

in the Python interactive interpreter. Or from a shell prompt:

python -m this


> I think that
> this word is used only when someone sees something that he doesn't like,
> he doesn't know what he doesn't like at it, and just goes to say its
> un-pythonic, without saying what would be... Wouldn't be just easier to
> say "I don't know" or "I doesn't feel right to me"?

I think that there's a risk that people over-use unpythonic when they 
mean "I don't like it", but that doesn't mean that pythonic isn't a 
meaningful concept. However, it is a matter of degree, not kind: like 
mole-hills and mountains, unpythonic and pythonic are very different 
things, but there's no precise dividing line between them.


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

Re: Lisp mentality vs. Python mentality

[Michele Simionato]

On Apr 25, 10:26 pm, Carl Banks  wrote:
> I totally disagree.  Scheme might be a pure language with no
> compromises and impurities, but Common Lisp is certainly not.

I can assure you that even Scheme is a language full
of compromises and inconsistencies :-/

  Michele, who is now writing a book about Scheme

http://www.phyast.pitt.edu/~micheles/scheme/TheAdventuresofaPythonistainSchemeland.pdf
--
http://mail.python.org/mailman/listinfo/python-list

Re: python list handling and Lisp list handling

[Steven D'Aprano]

On Fri, 24 Apr 2009 21:01:10 -0700, Carl Banks wrote:

> That's because Python lists aren't lists.

Surely you meant to say that Lisp lists aren't lists?


It-all-depends-on-how-you-define-lists-ly y'rs,


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

Re: Lisp mentality vs. Python mentality

[Steven D'Aprano]

On Fri, 24 Apr 2009 23:06:30 -0700, Carl Banks wrote:


> Lisp programmer:
> 
> Well, there is a standard function called mismatch that does it, but I
> can't recommend it.  First of all, you don't know where that function's
> been.  Anyone and their mother could have worked on it, did they have
> good, sound programming practice in mind when they wrote it?  Of course
> not.  Let's be real here, we have to implement this by hand.
[snip]


That's great stuff! An unfair and untrue caricature, but still great :)




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

Re: Lisp mentality vs. Python mentality

[namekuseijin]

That was amusing, but that's not a question of Lisp vs Python 
programmers, just one of fun vs practicality.  Mark Tarver is the 
implementor of Qi, a higher order Lisp of sorts.  He's writing a 
compiler from Qi to Python and was learning Python along the way.


He's having fun with it, not writing it to meet a deadline.  Who never 
reimplemented things for the sheer fun of it?  The fun of writing it to 
top the current implementation, to learn how it works or merely as 
example to fellow programmers?


Oh, I know who never did it:  programmers who are into programming only 
for the paycheck and who otherwise think it's a bore.

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

Re: Lisp mentality vs. Python mentality

[namekuseijin]

Paul Rubin wrote:

Carl Banks  writes:

Python programmer:

a == b.  Next question.


in lisp you'd use (equal a b)


I see you walk both sides. :)
--
http://mail.python.org/mailman/listinfo/python-list

Re: Lisp mentality vs. Python mentality

[John Yeung]

On Apr 25, 9:05 pm, Mark Wooding  wrote:
> Carl Banks  writes:
> > Graham, for his part, doesn't seem to appreciate that
> > what he does is beyond hope for average people, and
> > that sometimes reality requires average people to write
> > programs.
>
> I think he understands that perfectly well.  But I think he
> believes that the sorts of tools which help average people
> write programs get in the way of true wizards.
>
> I think I agree.  
>
> On the other hand, I don't think Python actually does get
> in the way very much.

Actually, Graham doesn't have particularly strong objection to
Python.  Partly this is because he sees it as being largely as capable
and expressive as Lisp (mainly sans macros, of course); partly because
he sees that Python tends to attract good programmers (chief among
them Trevor Blackwell).

In my view, what is remarkable about Python is that it is so
accessible to average programmers (and frankly, even rather poor
programmers) while still managing to stay appealing to top-notch
programmers.

That said, my experience with Lisp programmers has mainly been with
people who like Scheme, which may explain why Carl Banks and I have
different impressions of Lisp programmers.  (We also seem to differ on
how accurate it is to refer to Scheme as Lisp.)  But in my experience,
Lisp in any form tends not to attract average programmers, and
certainly not poor programmers.  I don't mean to say Banks is wrong; I
said up front my exposure to the Lisp community is limited.  I am just
giving my own impressions.

Python is easily powerful enough and expressive enough to be an
"enabler language".  I guess not Ultimate, but close enough that
Graham isn't particularly turned off by it!

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

Re: Minimal binary diff & version control in Python?

[Chris Rebert]

On Sat, Apr 25, 2009 at 7:47 PM, Kevin Ar18  wrote:
>
> 2. Has anyone ever tried to implement some form of version control in Python 
> (if so, where)?

Both Bazaar (http://bazaar-vcs.org/) and Mercurial
(http://www.selenic.com/mercurial/wiki/), two popular distributed
VCS-es, are written in Python (with some C for speed).

Cheers,
Chris
-- 
I have a blog:
http://blog.rebertia.com
--
http://mail.python.org/mailman/listinfo/python-list

Minimal binary diff & version control in Python?

[Kevin Ar18]

This is a two part question:
 
1. Is there a minimal binary diff comparison library for Python (like difflib, 
but able to create a minimal diff)?

2. Has anyone ever tried to implement some form of version control in Python 
(if so, where)?
 
I was just wonder about creating something small to handle version control on 
binary files -- maybe something in Python.  :)
_
Windows Live™ Hotmail®:…more than just e-mail.
http://windowslive.com/online/hotmail?ocid=TXT_TAGLM_WL_HM_more_042009
--
http://mail.python.org/mailman/listinfo/python-list

GoEar Mp3 download system

[Carlos Schwarz Júnior]

I developed an application using pyGTK to download the MP3 music that are 
hosted on GoEar http://www.goear.com/.
It's not totally finished, but the main functions are working and some other 
interesting features too.


It works well in Windows and Linux (not tested in MAC).
To download: http://code.google.com/p/goear2mp3/

Suggestions and comments are welcome. Enjoy!! 


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

Re: mailbox.mbox.add() sets access time as well as modification time

[Lawrence D'Oliveiro]

In message <_vqdnf6pny1gymzunz2dnuvz_qcdn...@posted.visi>, Grant Edwards 
wrote:

> ... if one didn't care about backwards-compatiblity with old e-mail
> apps, then one would use a less broken mailbox format like
> maildir.

It's only in the proprietary-software world that we need to worry about 
backward compatibility with old, obsolete software that the vendors cannot 
or will not fix. In the Free Software world, we fix the software to bring it 
up to date.

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

Re: Lisp mentality vs. Python mentality

[Carl Banks]

On Apr 25, 6:05 pm, Mark Wooding  wrote:
> Carl Banks  writes:
> > Graham, for his part, doesn't seem to appreciate that what he does is
> > beyond hope for average people, and that sometimes reality requires
> > average people to write programs.
>
> I think he understands that perfectly well.  But I think he believes
> that the sorts of tools which help average people write programs get in
> the way of true wizards.
>
> I think I agree.  
>
> On the other hand, I don't think Python actually does get in the way
> very much.
>
> -- [mdw], Lisp hacker.

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

Re: PEP 383: Non-decodable Bytes in System Character Interfaces

[Cameron Simpson]

On 25Apr2009 14:07, "Martin v. Löwis"  wrote:
| Cameron Simpson wrote:
| > On 22Apr2009 08:50, Martin v. Löwis  wrote:
| > | File names, environment variables, and command line arguments are
| > | defined as being character data in POSIX;
| > 
| > Specific citation please? I'd like to check the specifics of this.
| For example, on environment variables:
| http://opengroup.org/onlinepubs/007908799/xbd/envvar.html
[...]
| http://opengroup.org/onlinepubs/007908799/xsh/execve.html
[...]

Thanks.

| > So you're proposing that all POSIX OS interfaces (which use byte strings)
| > interpret those byte strings into Python3 str objects, with a codec
| > that will accept arbitrary byte sequences losslessly and is totally
| > reversible, yes?
| 
| Correct.
| 
| > And, I hope, that the os.* interfaces silently use it by default.
| 
| Correct.

Ok, then I'm probably good with the PEP. Though I have a quite strong
desire to be able to work in bytes at need without doing multiple
encode/decode steps.

| > | Applications that need to process the original byte
| > | strings can obtain them by encoding the character strings with the
| > | file system encoding, passing "python-escape" as the error handler
| > | name.
| > 
| > -1
| > This last sentence kills the idea for me, unless I'm missing something.
| > Which I may be, of course.
| > POSIX filesystems _do_not_ have a file system encoding.
| 
| Why is that a problem for the PEP?

Because you said above "by encoding the character strings with the file
system encoding", which is a fiction.

| > If I'm writing a general purpose UNIX tool like chmod or find, I expect
| > it to work reliably on _any_ UNIX pathname. It must be totally encoding
| > blind. If I speak to the os.* interface to open a file, I expect to hand
| > it bytes and have it behave.
| 
| See the other messages. If you want to do that, you can continue to.
| 
| > I'm very much in favour of being able to work in strings for most
| > purposes, but if I use the os.* interfaces on a UNIX system it is
| > necessary to be _able_ to work in bytes, because UNIX file pathnames
| > are bytes.
| 
| Please re-read the PEP. It provides a way of being able to access any
| POSIX file name correctly, and still pass strings.
| 
| > If there isn't a byte-safe os.* facility in Python3, it will simply be
| > unsuitable for writing low level UNIX tools.
| 
| Why is that? The mechanism in the PEP is precisely defined to allow
| writing low level UNIX tools.

Then implicitly it's byte safe. Clearly I'm being unclear; I mean
original OS-level byte strings must be obtainable undamaged, and it must
be possible to create/work on OS objects starting with a byte string as
the pathname.

| > Finally, I have a small python program whose whole purpose in life
| > is to transcode UNIX filenames before transfer to a MacOSX HFS
| > directory, because of HFS's enforced particular encoding. What approach
| > should a Python app take to transcode UNIX pathnames under your scheme?
| 
| Compute the corresponding character strings, and use them.

In Python2 I've been going (ignoring checks for unchanged names):

  - Obtain the old name and interpret it into a str() "correctly".
I mean here that I go:
  unicode_name = unicode(name, srcencoding)
in old Python2 speak. name is a bytes string obtained from listdir()
and srcencoding is the encoding known to have been used when the old name
was constructed. Eg iso8859-1.
  - Compute the new name in the desired encoding. For MacOSX HFS,
that's:
  utf8_name = unicodedata.normalize('NFD',unicode_name).encode('utf8')
Still in Python2 speak, that's a byte string.
  - os.rename(name, utf8_name)

Under your scheme I imagine this is amended. I would change your
listdir_b() function as follows:

  def listdir_b(bytestring, fse=None):
   if fse is None:
   fse = sys.getfilesystemencoding()
   string = bytestring.decode(fse, "python-escape")
   for fn in os.listdir(string):
   yield fn.encoded(fse, "python-escape")

So, internally, os.listdir() takes a string and encodes it to an
_unspecified_ encoding in bytes, and opens the directory with that
byte string using POSIX opendir(3).

How does listdir() ensure that the byte string it passes to the underlying
opendir(3) is identical to 'bytestring' as passed to listdir_b()?

It seems from the PEP that "On POSIX systems, Python currently applies the
locale's encoding to convert the byte data to Unicode". Your extension
is to augument that by expressing the non-decodable byte sequences in a
non-conflicting way for reversal later, yes?

That seems to double the complexity of my example application, since
it wants to interpret the original bytes in a caller-specified fashion,
not using the locale defaults.

So I must go:

  def macify(dirname, srcencoding):
# I need this to reverse your encoding scheme
fse = sys.getfilesystemencoding()
# I'll pretend dirname is ready for use
# it possibly has had to un

Re: python list handling and Lisp list handling

[Mark Wooding]

Mark Tarver  writes:

> But are Python lists also indistinguishable from conventional
> Lisplists for list processing. 
>
> For example, can I modify a Python list non-destructively?  

No.

> Are they equivalent to Lisp lists. Can CAR and CDR in Lisp be thought
> of as
>
> def car (x):
>   return x[0]
>
> def cdr (x):
>   return x[1:]

Not in the presence of side-effects, no.

The slice-extration operation on lists constructs a copy of the
original, and mutating the original doesn't affect the copy.  Here's a
simple example.

[Load your definitions...]

In [1]: def car (x): return x[0]
   ...:

In [2]: def cdr (x): return x[1:]
   ...:

[Python]   [Common Lisp]

In [3]: a = [1, 2, 3, 4]   CL-USER> (setf a (list 1 2 3 4))
   (1 2 3 4)

In [4]: b = cdr(a) CL-USER> (setf b (cdr a))
   (2 3 4)

In [5]: a[2] = 'banana'CL-USER> (setf (third a) "banana")
   "banana"

In [6]: a  CL-USER> a
Out[6]: [1, 2, 'banana', 4](1 2 "banana" 4)

In [7]: b  CL-USER> b
Out[7]: [2, 3, 4]! (2 "banana" 4)

Also, note:

In [8]: b is cdr(a)CL-USER> (eq b (cdr a))
Out[8]: False! T

Your Python `cdr' operation conses.  Until you create it explicitly,
there is no Python value corresponding to `all but the first element of
this list'.

But, apart from the performance and sharing characteristics, they're the
same.  I think those are pretty big differences, though.

-- [mdw]
--
http://mail.python.org/mailman/listinfo/python-list

Re: Weird lambda behavior (bad for)

[namekuseijin]

The real issue here has nothing to do with closures, lexical capture or 
anything like that.  It's a long known issue called side-effects.


Trying to program in a functional style in the presence of side-effects 
is bad.  *for* is the main perpetrator of side-effects here, because it 
updates its iterating variables rather than create a new lexical 
environment for them.


Say:
>>> x
Traceback (most recent call last):
  File "", line 1, in 
NameError: name 'x' is not defined
>>> ps=[]
>>> for x in range(3): ps.append( lambda y: x+y )
...
>>> ps
[ at 0x8389a04>,  at 0x8389a74>, 
 at 0x8389c34>]

>>> ps[0](1)
3
>>> ps[1](1)
3
>>> ps[2](1)
3

It also polutes the namespace by letting x live on:
>>> x
2

Even list comprehensions still suffer from the updating:
>>> xs=[lambda y:x+y for x in range(3)]
>>> xs[0](1)
3
>>> xs[1](1)
3
>>> xs[2](1)
3

No such issue with map, which truly does it the proper functional way:
>>> ys=map(lambda x: lambda y: x+y, range(3))
>>> ys[0](1)
1
>>> ys[1](1)
2
>>> ys[2](1)
3

I don't like *for* at all.  It both makes it tough to get true closures 
and also unnecessarily pollutes the namespace with non-local variables.


So, beware of the lack of true lexical bindings associated with the evil 
imperative *for*! :)

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

Re: __import__ function broken in 2.6

[Carl Banks]

On Apr 25, 2:37 pm, Paul  wrote:
> It seems in 2.6 you are no longer able to use the __import__ function
> with different paths.

That functionality was deliberately removed, since it was never
intended to be present in the first place, and it only "worked" before
by accident.  To get that behavior:

1. Insert the directory where it's located into sys.path.  (And be
wary of module name conflicts.)

2. If it's a small config-type file, then execfile() would

As for why it was removed, it's because importing is designed to work
on package names, not filenames.  (Given that Python's importing
framework is so complicated, though, one wonders whethter sticking to
a design ideal is worth it.)


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

Re: Lisp mentality vs. Python mentality

[Mark Wooding]

Carl Banks  writes:

> Graham, for his part, doesn't seem to appreciate that what he does is
> beyond hope for average people, and that sometimes reality requires
> average people to write programs.

I think he understands that perfectly well.  But I think he believes
that the sorts of tools which help average people write programs get in
the way of true wizards.

I think I agree.  

On the other hand, I don't think Python actually does get in the way
very much.

-- [mdw], Lisp hacker.
--
http://mail.python.org/mailman/listinfo/python-list

Re: debugging in IPython

[Esmail]

I seem to recall something about starting up the python
(and ipython) interpreter with the -i flag, but I am not
certain.

There is a ipython mailing list/user group too, you may
want to post your query there too.

Esmail

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

Re: New at Python, some trouble with examples

[Kevin Forbes VK3KUF]

 [snip]
>>
>> Oh, and I had to rename the Python26.dll to Python25.dll for Delphi to 
>> operate. ???
>>
> [snip]
> The fact that you had to rename to Python25.dll suggests that Delphi is
> expecting Python 2.5. You might want to download Python 2.5 (actually
> Python 2.5.4) instead to see whether that works better.


Hello again, it worked, beautiful, thanks.

It was a bit of a drag as Delphi 7 didn't compile it properly due to the 
mising vcldb etc from the free version, but Turbo Explorer 2006 to the 
rescue.

It has the missing components and I compiled the *.dpk files with that, I 
incorrectly said I did it by deleting refs in the files while using D7, I 
actually used turbo2006, also had to set all the paths in that to the lib 
and rtl dirs, it was a long day and didn't make all that many notes, I then 
installed the packages into Delphi 7.

Had to make sure a pile of paths were in the right places, one step at a 
time.

I'm here now, big smile on my face too.

Thank you. Kevin. 


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

Re: mailbox.mbox.add() sets access time as well as modification time

[Lawrence D'Oliveiro]

In message <49f33d8d$0$516$bed64...@news.gradwell.net>, tinn...@isbd.co.uk 
wrote:

> mbox has several advantages over maildir (for me anyway):-
> 
> It allows easy removal of empty mailboxes (in my case by the MUA)

Really? I just created a "junk" mail folder via my IMAP server using 
Thunderbird, and was able to delete it the same way. Or did you mean 
something else?

> It's much easier to search

Thunderbird seems to search maildir files just fine.

> It's easier to move things around

Actually, no. Maildir makes it easier--no need to worry about locking, so it 
works reliably even on network volumes.

> It doesn't have silly ways of delimiting directories as do some
> maildir implementations.

What do you mean?

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

Re: python list handling and Lisp list handling

[Rhodri James]

On Sat, 25 Apr 2009 08:07:19 +0100, Mark Tarver  
 wrote:



OK; I guess the answer to the question

"Assuming the following Python encodings, and ignoring questions
of performance, would Python and Lisp lists then be observationally
indistinguishable? i.e. would these then be fair encodings?"

is a 'yes'.   Any disagreement?


I'm probably being rather thick, but aren't you saying here
"Assuming that the answer to this question is 'yes', is the
answer to this question 'yes'?"

--
Rhodri James *-* Wildebeeste Herder to the Masses
--
http://mail.python.org/mailman/listinfo/python-list

Re: Lisp mentality vs. Python mentality

[Rhodri James]

On Sat, 25 Apr 2009 13:32:21 +0100, Ciprian Dorin, Craciun  
 wrote:



Should I update the
__eq__ method (for str class) and break almost everything? Can I write
now a == b?


Should you instead, perhaps, write a case-insensitive string class, since
seems to be what your data is asking for?


I like object oriented programming, but most of the times we are
just throwing together code and data even when the data has no
behavior and the code is in fact just one possible processing
algorithm. Like in the case you are mentioning, if I tie the
comparison code to the actual data structure, then I'll never be able
to reuse it... But if I leave the code as a standalone function, and
just use the data (or any data that resembles the original structure)
then maybe I'll be able to reuse it...


I'd say the reverse, personally.  A lot of what you've demonstrated is
varying algorithms, which are rarely going to reuse standalone code.
They still need to deal with case-insensitive strings, though.

--
Rhodri James *-* Wildebeeste Herder to the Masses
--
http://mail.python.org/mailman/listinfo/python-list

Re: __import__ function broken in 2.6

[Dave Angel]

Paul wrote:

Hi

It seems in 2.6 you are no longer able to use the __import__ function
with different paths. Here is our code:

sys.path = g.origSysPath[:] # copy, not reference
sys.path.insert(0, modulePath)

sys.modules = g.origSysModules.copy()
if sys.modules.get(moduleName):
del sys.modules[moduleName]

# look for modules in subdirectories
moduleName = "module_"+moduleName+"/"+moduleName

module = __import__(moduleName)

Unfortunately, this no longer works in 2.6. Does anyone have any idea
on how to make it work with file paths?

After quite a lot of searching, I was actually able to find a patch
that someone made to fix this. Here is the code:

sfepy.googlecode.com/issues/attachment?
aid=-8587746048072650671&name=import.patch

---

commit 2e92019ef957b547856e81a144db6845bf95d881
Author: Robert Cimrman 
Date:   Thu Mar 5 09:59:59 2009 +0100

fixed load_classes() for Python 2.6

- __import__() function does not work when passing a file path as
name

diff --git a/sfepy/terms/__init__.py b/sfepy/terms/__init__.py
index 3fab007..34a31a6 100644
--- a/sfepy/terms/__init__.py
+++ b/sfepy/terms/__init__.py
@@ -10,9 +10,9 @@ def load_classes( filenames, is_class ):
 table = {}
 for filename in filenames:
 name = os.path.splitext( filename )[0]
-#print filename, name
-mod = __import__( name )
-#print mod
+parts = name.split( os.path.sep )
+mod, name = '.'.join( parts ), parts[-1:]
+mod = __import__( mod, globals(), locals(), name )
 for key, var in mod.__dict__.iteritems():
 if is_class( key ):
 table[var.name] = var

---

However, after a lot of messing around with the new __import__( mod,
globals(), locals(), name ) function, I am still unable to make it
work. Perhaps I am just not able to understand exactly what is going
on here.

Can anyone offer some assistance?

Thank you,
Paul

  
"No longer works" is pretty vague.  If you get an error, how about 
showing us just what it is.  The following line builds a name with a 
slash in it.  What's the point?  If the module is in a subdirectory, add 
that subdirectory to modulePath.


moduleName = "module_"+moduleName+"/"+moduleName

DaveA

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

Re: how to suspend program and save state data in python or IDLE?

[Dave Angel]

ja...@biosci.utexas.edu wrote:
hi! i'm 
running computationally-intensive python programs for a student 
project, and i have a couple of questions.


1) how can i suspend program execution for brief periods either in 
python or through IDLE;


and 2) is there a way to save state data so that if i have to quit 
running a program in a student computer lab, i can write the state of 
the program and all intermediate data to -- say -- a usb drive, then 
read in the state data later so the program can pick up where it left 
off?


thanks,
james



1a)  A program can suspend itself, with a call to sleep().  While it's 
sleeping, it uses very little CPU time.  Similarly, if it's waiting for 
console input, or in an idle loop (for a GUI app).



1b) If the program is running from an IDE, such as Komodo, then you can 
set a breakpoint, and pause it, while examining values and stack 
information.  I'm not familiar with IDLE, so I don't know if it has 
similar abilities.


2)  As far as I know, there's no standardized to preserve the entire 
state of any process.  However, if you write a program with this in 
mind, you could preserve the state of your variables with pickle.  
Preserving the state of the local variables in functions currently 
executing is another story, however.  I don't know of any standard way 
of dumping the execution frames.


When writing a GUI program, it's sometimes necessary to break up a long 
computation, so that the GUI doesn't freeze.  The same techniques could 
be used here.



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

Re: __import__ function broken in 2.6

[Paul]

We found a quick workaround to make import work with paths. We just
append the folder we want to the system's path:

sys.path.append( moduleFolder )

If anyone has a better solution, that would be great. Until then, this
is ugly, but it works.
--
http://mail.python.org/mailman/listinfo/python-list

Re: best way to compare contents of 2 lists?

[Esmail]

norseman wrote:


Of course each method has its time and place of use and Python has some 
well oiled list search and list maintain routines of its own. List 
comparisons are most accurate when using presorted ones. (Some things 
don't lend themselves to sorting very well. Like paragraphs, books, 
chapters, computer programs, manuals, etc... These need the searchers 
(equivalent to the Unix diff) for checking equivalence.)



HTH

Steve


Thanks Steve for bringing up various items to consider for these sort
of tasks, very helpful indeed.

Best,
Esmail

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

Re: confused with so many python package locations for imports

[Ben Finney]

Chris Rebert  writes:

> Erm, .pyo-s aren't platform-specific.
[…]

> It's not like .pyo-s are compiled C extension modules.

Thank you for the correction. Please mentally substitute into my
argument the files that *are* compiled C extension modules; it remains
otherwise unchanged.

-- 
 \“If you ever drop your keys into a river of molten lava, let |
  `\ 'em go, because, man, they're gone.” —Jack Handey |
_o__)  |
Ben Finney
--
http://mail.python.org/mailman/listinfo/python-list

Re: how to suspend program and save state data in python or IDLE?

[Chris Rebert]

On Sat, Apr 25, 2009 at 3:18 PM,   wrote:
> hi! i'm running computationally-intensive python programs for a student
> project, and i have a couple of questions.
>
> 1) how can i suspend program execution for brief periods either in python or
> through IDLE;

Ctrl+Z on Unix shells will stop program execution and return you to
the shell. The command `fg 1` will resume execution.

>
> and 2) is there a way to save state data so that if i have to quit running a
> program in a student computer lab, i can write the state of the program and
> all intermediate data to -- say -- a usb drive, then read in the state data
> later so the program can pick up where it left off?

http://docs.python.org/library/pickle.html

Cheers,
Chris
-- 
I have a blog:
http://blog.rebertia.com
--
http://mail.python.org/mailman/listinfo/python-list

how to suspend program and save state data in python or IDLE?

[james]

hi! i'm running computationally-intensive python programs for a  
student project, and i have a couple of questions.


1) how can i suspend program execution for brief periods either in  
python or through IDLE;


and 2) is there a way to save state data so that if i have to quit  
running a program in a student computer lab, i can write the state of  
the program and all intermediate data to -- say -- a usb drive, then  
read in the state data later so the program can pick up where it left  
off?


thanks,
james
--
http://mail.python.org/mailman/listinfo/python-list

Re: Thread lag

[Yann Leboulanger]

Piet van Oostrum wrote:
>> Asterix  (A) a écrit:
> 
>> A> Hi,
>> A> Here is a small class I use in my GTK application, to do some job in a
>> A> thread.:
> 
>> A> class ThreadInterface:
>> A>def __init__(self, func, func_args, callback, callback_args):
>> A>   '''Call a function in a thread and then call callback'''
>> A>   def thread_function(func, func_args, callback, callback_args):
>> A>  print 'func start'
>> A>  output = func(*func_args)
>> A>  gobject.idle_add(callback, output, *callback_args)
>> A>   Thread(target=thread_function, args=(func, func_args, callback,
>> A>  callback_args)).start()
>> A>   print 'thread called'
> 
>> A> Here is the way I call the class:
> 
>> A> def decrypt_thread(encmsg, keyID):
>> A># Do things
>> A>return val1, val2)
> 
>> A> def _on_message_decrypted(output, val):
>> A># blabla
> 
>> A> ThreadInterface(decrypt_thread, [encmsg, keyID], _on_message_decrypted,
>> A> [val])
> 
> 
>> A> But between the time "thread called" is printed and the time "func
>> A> start" is printed, there is sometimes (it vary a lot) several seconds.
> 
>> A> How could it be? Why thread is not started instantly? How can I improve
>> A> that?
> 
> I don't know if it is related to our problem but I guess it is.
> 
> It appears that GTK and Python threads are incompatible UNLESS you call
> gtk.gdk.threads_init() before gtk.main(). This has something to do with
> releasing the GIL, which gtk optimizes away if it hasn't been told that
> your application uses threads.

Hehe, great! That was it!
Thank you
-- 
Yann
--
http://mail.python.org/mailman/listinfo/python-list

Re: PyQt4 - widget signal trouble

[Marco Bizzarri]

On Fri, Apr 24, 2009 at 7:37 PM, Joacim Thomassen
 wrote:
> Hello,
>
> I'm trying to get my first PyQt4 application to work as intended, but it
> seems I'm stuck and out of ideas for now.
>
> The program is a simple GUI showing an image. If the image on disk change
> my intension is that the displayed image in my application also change
> accordingly.
>
> What works: The filesystem change is detected and my program prints out
> "Change happened!"
>
> what is the problem: The image shown in the application is not changed.
>
> What am I doing wrong here? Any ideas and suggestions are appreciated.
>
> Best regards,
> Joacim Thomassen
>
> My program:
> #!/usr/bin/python
> """
> familyframe.py
>
> Simple photo frame for the desktop
>
> Author: Joacim Thomassen, 4/2-2009
> License: AGPLv3+
>
> Last change: 24/2-2009
> """
>
> from __future__ import division
> import sys
> from math import *
> from PyQt4.QtCore import *
> from PyQt4.QtGui import *
>
> import time
> import fcntl
> import os
> import signal
>
> fname = "/home/joacim/.familyframe"
>
> class Watcher(QObject):
>        def handler(self, signum, frame):
>                self.emit(SIGNAL("imageChange"))
>        def __init__(self, parent=None):
>                super(Watcher, self).__init__()
>                signal.signal(signal.SIGIO, self.handler)
>                fd = os.open(fname, os.O_RDONLY)
>                fcntl.fcntl(fd, fcntl.F_SETSIG, 0)
>                fcntl.fcntl(fd, fcntl.F_NOTIFY, fcntl.DN_MODIFY |
> fcntl.DN_CREATE | fcntl.DN_MULTISHOT)
>
> class ImageWidget(QLabel):
>        def __init__(self, parent=None):
>                super(QLabel, self).__init__(parent)
>                self.image = QImage("/home/joacim/.familyframe/image.jpg")
>                self.setMinimumSize(200, 200)
>                self.setAlignment(Qt.AlignCenter)
>                self.setPixmap(QPixmap.fromImage(self.image))
>        def reload(self):
>                print "Change happened!"
>                self.image.load("/home/joacim/.familyframe/image.jpg")
>                self.setPixmap(QPixmap.fromImage(self.image))
>                self.update()
>
> class CentralWidget(QWidget):
>        def __init__(self, parent=None):
>                super(QWidget, self).__init__(parent)
>                self.imagewidget = ImageWidget()
>                self.box = QHBoxLayout()
>                self.box.addWidget(self.imagewidget)
>                self.setLayout(self.box)
>        def reload(self):
>                self.imagewidget.reload()
>
> class MainWindow(QMainWindow):
>        def __init__(self, w, parent=None):
>                super(MainWindow, self).__init__(parent)
>                self.centralwidget = CentralWidget()
>                self.setWindowTitle("Family Frame")
>                self.setCentralWidget(self.centralwidget)
>                self.connect(w, SIGNAL("imageChange"), self.updateUi)
>                self.show()
>        def updateUi(self):
>                self.centralwidget.reload()
>
> if __name__ == "__main__":
>        app = QApplication(sys.argv)
>        w = Watcher()
>        main = MainWindow(w)
>        app.exec_()
> --
> http://mail.python.org/mailman/listinfo/python-list
>

Ciao, Joacim.

Too much since I 'played' with low level calls, so I may be wrong. But
it seems to me you're opening the image and monitoring for changes the
directory. Hence the problem. If you read/write a file, I think the
directory does not result as modified (but you should experiment by
yourself).

Regards
Marco


-- 
Marco Bizzarri
http://notenotturne.blogspot.com/
http://iliveinpisa.blogspot.com/
--
http://mail.python.org/mailman/listinfo/python-list

__import__ function broken in 2.6

[Paul]

Hi

It seems in 2.6 you are no longer able to use the __import__ function
with different paths. Here is our code:

sys.path = g.origSysPath[:] # copy, not reference
sys.path.insert(0, modulePath)

sys.modules = g.origSysModules.copy()
if sys.modules.get(moduleName):
del sys.modules[moduleName]

# look for modules in subdirectories
moduleName = "module_"+moduleName+"/"+moduleName

module = __import__(moduleName)

Unfortunately, this no longer works in 2.6. Does anyone have any idea
on how to make it work with file paths?

After quite a lot of searching, I was actually able to find a patch
that someone made to fix this. Here is the code:

sfepy.googlecode.com/issues/attachment?
aid=-8587746048072650671&name=import.patch

---

commit 2e92019ef957b547856e81a144db6845bf95d881
Author: Robert Cimrman 
Date:   Thu Mar 5 09:59:59 2009 +0100

fixed load_classes() for Python 2.6

- __import__() function does not work when passing a file path as
name

diff --git a/sfepy/terms/__init__.py b/sfepy/terms/__init__.py
index 3fab007..34a31a6 100644
--- a/sfepy/terms/__init__.py
+++ b/sfepy/terms/__init__.py
@@ -10,9 +10,9 @@ def load_classes( filenames, is_class ):
 table = {}
 for filename in filenames:
 name = os.path.splitext( filename )[0]
-#print filename, name
-mod = __import__( name )
-#print mod
+parts = name.split( os.path.sep )
+mod, name = '.'.join( parts ), parts[-1:]
+mod = __import__( mod, globals(), locals(), name )
 for key, var in mod.__dict__.iteritems():
 if is_class( key ):
 table[var.name] = var

---

However, after a lot of messing around with the new __import__( mod,
globals(), locals(), name ) function, I am still unable to make it
work. Perhaps I am just not able to understand exactly what is going
on here.

Can anyone offer some assistance?

Thank you,
Paul
--
http://mail.python.org/mailman/listinfo/python-list

Re: confused with so many python package locations for imports

[Chris Rebert]

On Sat, Apr 25, 2009 at 1:31 AM, Ben Finney  wrote:
> Krishnakant  writes:
>
>> My Basic question is that, what package directory is Standard as far
>> as all gnu/linux distros are concerned?
>
> Python has a habit of generating, and expecting to find,
> platform-specific files (‘foo.pyo’ extension modules)

Erm, .pyo-s aren't platform-specific. According to
http://docs.python.org/dev/tutorial/modules.html#compiled-python-files
:

When the Python interpreter is invoked with the -O flag, optimized
code is generated and stored in .pyo files. The optimizer currently
doesn’t help much; it only removes assert statements.

Passing two -O flags to the Python interpreter (-OO) will cause the
bytecode compiler to perform optimizations that could in some rare
cases result in malfunctioning programs. Currently only __doc__
strings are removed from the bytecode, resulting in more compact .pyo
files.

A program doesn’t run any faster when it is read from a .pyc or .pyo
file than when it is read from a .py file; the only thing that’s
faster about .pyc or .pyo files is the speed with which they are
loaded.


It's not like .pyo-s are compiled C extension modules.

Cheers,
Chris
-- 
I have a blog:
http://blog.rebertia.com
--
http://mail.python.org/mailman/listinfo/python-list

Re: Marshal vs pickle...

[Lawson English]

Lawson English wrote:
Marshalling is only briefly mentioned in most python books I have, and 
"pickling" is declared teh preferred method for serialization.


I read somewhere that Marshalling is version-dependent while pickling 
is not, but can't find that reference. OTOH, pickling can lead to 
loading of malicious code (I understand) while marshalling only 
handles basic Python types?



Could anyone point me to a reasonable discussion of the pros and cons 
of each method for serialization?



Thanks.


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


Thanks for the responses.

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

Re: Lisp mentality vs. Python mentality

[Ciprian Dorin, Craciun]

On Sat, Apr 25, 2009 at 11:36 PM, Brett Hoerner  wrote:
> On Apr 25, 8:11 am, "Ciprian Dorin, Craciun"
>  wrote:
>>     Well in fact I would have written it like:
>>
>> def validate_commandline(rexes, line) :
>>     if not compare (rexes, line, re.match) :
>>         if len (rexes) != len (line) :
>>             raise ValueError ("mismatch len")
>>         mismatch = find_index (rexes, line, re.match, negate = True)
>>         raise ValueError ("mismatch at %d" % (mismatch))
>>
>>     Assuming, that I would have the function find_index.
>>
>>     Ciprian.
>
> I think you've hit on the definition of "unpythonic".  (No, I don't
> have a dictionary definition for you, sorry).
>
> Using a function called "compare" to run a list of regexes against
> another list of regexes to get a boolean?  And then another find_index
> function doing the same where you pass in negate?  What is even going
> on here?
>
> I, for one, would take Martin's any day of the week.  It reads like
> good pseudocode as much "proper" Python does.
>
> Brett

From your comments I understand that the only problem with my code
proposal are the function names... Well instead of compare (which was
kept from the beginning of the post) we could just rename it to
"matches". Does the name "matches" matches what it does? :) (If not we
can keep discussing for a proper name...)

And about the find_index, we could rename it to
first_matching_index. About the negation optional parameter, we could
eliminate it if we allow either: to have another function
first_missmatching_index, but this leads to namespace bloat, or we
have a function named negate, that takes another function, and negates
it meaning. (Although i don't see anything wrong in the negate
argument... It's just like having order by asc | desc in SQL...)

Thus the code would have been rewritten as: (we also put the
function on the first argument as its the most important argument)

def validate_commandline(rexes, line) :
if not matches (re.match, rexes, line) :
if len (rexes) != len (line) :
raise ValueError ("mismatch len")
mismatch = first_matching_index (negate (re.match), rexes, line)
raise ValueError ("mismatch at %d" % (mismatch))

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

Re: Marshal vs pickle...

[Erik Max Francis]

Lawson English wrote:
Marshalling is only briefly mentioned in most python books I have, and 
"pickling" is declared teh preferred method for serialization.


I read somewhere that Marshalling is version-dependent while pickling is 
not, but can't find that reference. OTOH, pickling can lead to loading 
of malicious code (I understand) while marshalling only handles basic 
Python types?


Could anyone point me to a reasonable discussion of the pros and cons of 
each method for serialization?


They're both standard libraries and the official documentation for them 
on python.org describes their functionality in detail.


--
Erik Max Francis && m...@alcyone.com && http://www.alcyone.com/max/
 San Jose, CA, USA && 37 18 N 121 57 W && AIM, Y!M, Skype erikmaxfrancis
  The hour which gives us life begins to take it away.
   -- Seneca
--
http://mail.python.org/mailman/listinfo/python-list

Re: Marshal vs pickle...

[Benjamin Peterson]

Lawson English  cox.net> writes:

> 
> Marshalling is only briefly mentioned in most python books I have, and 
> "pickling" is declared teh preferred method for serialization.
> 
> I read somewhere that Marshalling is version-dependent while pickling is 
> not, but can't find that reference. OTOH, pickling can lead to loading 
> of malicious code (I understand) while marshalling only handles basic 
> Python types?

marshal isn't any more secure than pickle is.

> 
> Could anyone point me to a reasonable discussion of the pros and cons of 
> each method for serialization?

The Python developers can change the marshal format at will, so the only reason
I can think of you should use marshal is for serializing and unserializing data
during the runtime of your program.
 




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

Re: python list handling and Lisp list handling

[Carl Banks]

On Apr 25, 12:07 am, Mark Tarver  wrote:
> On 25 Apr, 05:01, Carl Banks  wrote:
>
>
>
> > On Apr 24, 8:19 am, Mark Tarver  wrote:
>
> > > This page says that Python lists are often flexible arrays
>
> > >http://www.brpreiss.com/books/opus7/html/page82.html
>
> > > but also says that their representation is implementation dependent.
> > > As far as I see this should mean that element access in Python should
> > > run in constant time.  Now if so this is a boon, because generally
>
> > > 'A list is a sequence of elements, but it is not a single primitive
> > > object; it is made of cons cells, one cell per element. Finding the
> > > nth element requires looking through n cons cells, so elements farther
> > > from the beginning of the list take longer to access. But it is
> > > possible to add elements to the list, or remove elements.'
>
> > > (fromhttp://www.chemie.fu-berlin.de/chemnet/use/info/elisp/elisp_7.html)
>
> > > But are Python lists also indistinguishable from conventional
> > > Lisplists for list processing.  For example, can I modify a Python
> > > list non-destructively?  Are they equivalent to Lisp lists. Can CAR
> > > and CDR in Lisp be thought of as
>
> > > def car (x):
> > >   return x[0]
>
> > > def cdr (x):
> > >   return x[1:]
>
> > > The idea of a list in which elements can be accessed in constant time
> > > is novel to me.
>
> > That's because Python lists aren't lists.
>
> > It might be an interesting exercise to compare Python lists and Lisp
> > lists, but you should do it under the understanding that they are not
> > analogous types.  (A Python list is analogous to a Lisp vector.)  The
> > two objects have almost no similarity in typical their manner of use;
> > even the way you iterate through them is different.
>
> > You could, as you've tried to do here, operate on Python lists the
> > same way you operate on Lisp lists, but you'd just be doing things the
> > hard way.  Whatever you're trying to do with cons, car, and cdr,
> > chances are Python has a high-level way to do it built in that
> > performs a lot better.
>
> > Then again, Lispers seem to like to reimplement high-level operations
> > from low-level primitives every time they need it.  So if you liked
> > doing that you might not mind doing a lot of extra work using your
> > homebrew cons, car, and cdr.
>
> > Carl Banks- Hide quoted text -
>
> > - Show quoted text -
>
> OK; I guess the answer to the question
>
> "Assuming the following Python encodings, and ignoring questions
> of performance, would Python and Lisp lists then be observationally
> indistinguishable? i.e. would these then be fair encodings?"
>
> is a 'yes'.   Any disagreement?

In Python

cdr([]) == []

And I'd think that'd be an exception in Lisp depending on variants and
such.  That's the only difference I can think of.


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

Re: Python not importing mysqldb

[83nini]

On 25 Apr, 18:35, Marco Bizzarri  wrote:
> On Fri, Apr 24, 2009 at 10:04 PM, 83nini <83n...@gmail.com> wrote:
> > hi guys,
>
> > i've been sweating the whole day trying to make python work with mysql
> > but in vain!
> > i'm doing the following:
> > 1. visitinghttp://sourceforge.net/projects/mysql-python
> > 2. dowloading mysql-python-test-1.2.3c1
> > 3. extracting the files to C:\Python26\Lib\site-packages
> > 4. writing "import MySQLdb" in the python prompt
>
> > getting
>
> > Traceback (most recent call last):
> >  File "", line 1, in 
> >  File "C:\Python26\lib\site-packages\MySQLdb\__init__.py", line 19,
> > in 
>
> >    import _mysql
> > ImportError: No module named _mysql
>
> > WHY Y
> > why does it have to be so complicated what am i doing wrong for
> > god's sake?
>
> Suggestion: install python2.5 for windows, and then download this one:
>
> http://sourceforge.net/project/downloading.php?group_id=22307&filenam...
>
> I'm sure you'll save yourself a lot of time.
>
> Regards
> Marco
>
> --
> Marco 
> Bizzarrihttp://notenotturne.blogspot.com/http://iliveinpisa.blogspot.com/- 
> Dölj citerad text -
>
> - Visa citerad text -

Thanx guys for the helpful information, i did as Marco suggested and
it worked.
FINAY :D

cheers,
Lina
--
http://mail.python.org/mailman/listinfo/python-list

Re: Lisp mentality vs. Python mentality

[Brett Hoerner]

On Apr 25, 8:11 am, "Ciprian Dorin, Craciun"
 wrote:
>     Well in fact I would have written it like:
>
> def validate_commandline(rexes, line) :
>     if not compare (rexes, line, re.match) :
>         if len (rexes) != len (line) :
>             raise ValueError ("mismatch len")
>         mismatch = find_index (rexes, line, re.match, negate = True)
>         raise ValueError ("mismatch at %d" % (mismatch))
>
>     Assuming, that I would have the function find_index.
>
>     Ciprian.

I think you've hit on the definition of "unpythonic".  (No, I don't
have a dictionary definition for you, sorry).

Using a function called "compare" to run a list of regexes against
another list of regexes to get a boolean?  And then another find_index
function doing the same where you pass in negate?  What is even going
on here?

I, for one, would take Martin's any day of the week.  It reads like
good pseudocode as much "proper" Python does.

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

Re: Lisp mentality vs. Python mentality

[Carl Banks]

On Apr 25, 1:44 am, "Ciprian Dorin, Craciun"
 wrote:
> On Sat, Apr 25, 2009 at 11:30 AM, "Martin v. Löwis"  
> wrote:
>
>      Ok... Then what's pythonic? Please give a pythonic implementation...
> >>> Use the builtin a==b, similar to (equal a b)
>
> >>     But how about extensibility?
> > [...]
>
> > I see that you allow for a different comparison function. I do wonder
> > what the use case for this is - in what application do you have to
> > compare two lists for equality, and the item's __eq__ is inappropriate?
> > What would break if you fix the item's __eq__, instead of writing
> > your own comparison algorithm?
>
> > [...]
>
>     A practical example: I have lists that contain strings, but I want
> to compare them in an case-insensitive way... Should I update the
> __eq__ method (for str class) and break almost everything?

The practical way to deal with this issue is to write your own
function when you encounter a situation where == doesn't suffice.


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

Re: Lisp mentality vs. Python mentality

[Carl Banks]

On Apr 25, 12:36 am, John Yeung  wrote:
> On Apr 25, 2:06 am, Carl Banks  wrote:
>
> > In answering the recent question by Mark Tarver, I think I finally hit
> > on why Lisp programmers are the way they are (in particular, why they
> > are often so hostile to the "There should only be one obvious way to
> > do it" Zen).
>
> I don't get that impression from Lisp programmers.  I suppose it's
> only fair that I disclose (1) I admire Lisp, especially Scheme, (2) I
> hardly know Lisp at all, and (3) I don't frequent any Lisp forums/
> newsgroups/etc.

No it doesn't really apply to Scheme.  (The Scheme programmer would
have stopped after implementing the new function.)

Some people seem to want to hypertarget everything.  Common Lisp seems
to attract these people in big numbers because it has powerful
metaprogramming facilities and expressivity on steroids, making
hypertargeting easy.  It's like the Ultimate Enabler language.


> I do get the impression that Lispers tend to feel Lisp is superior to
> all other languages, and I agree that in some ways it is.  I don't
> think most Lispers' main objection to Python is about "only one
> obvious way" but rather things like the limitations, compromises, and
> impurities in the language.

I totally disagree.  Scheme might be a pure language with no
compromises and impurities, but Common Lisp is certainly not.  The
"One Obvious Way" philosophy isn't their main objection so much as the
most emblematic difference.


> Certainly compared to Scheme, Python
> sacrifices a lot of purity for practicality.  (And I guess some fans
> of Scheme would argue that Common Lisp does the same!)
>
> Ultimately, Lisp is first and foremost academic (Scheme especially so)
> while Python is first and foremost practical.  I think Paul Graham's
> essays on Lisp exemplify the Lisp mentality.

I don't agree.  I agree that Lisp programmers think that's their
mentality; I doubt many can actually take fullest advantage of Lisp
the way Graham has.  I think Paul Graham is a freak of nature whose
brain is hardwired to notice patterns in places different from where
most peoeple see patterns.  Graham, for his part, doesn't seem to
appreciate that what he does is beyond hope for average people, and
that sometimes reality requires average people to write programs.


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

Re: Thread lag

[Piet van Oostrum]

> Asterix  (A) a écrit:

>A> Hi,
>A> Here is a small class I use in my GTK application, to do some job in a
>A> thread.:

>A> class ThreadInterface:
>A>def __init__(self, func, func_args, callback, callback_args):
>A>   '''Call a function in a thread and then call callback'''
>A>   def thread_function(func, func_args, callback, callback_args):
>A>  print 'func start'
>A>  output = func(*func_args)
>A>  gobject.idle_add(callback, output, *callback_args)
>A>   Thread(target=thread_function, args=(func, func_args, callback,
>A>  callback_args)).start()
>A>   print 'thread called'

>A> Here is the way I call the class:

>A> def decrypt_thread(encmsg, keyID):
>A># Do things
>A>return val1, val2)

>A> def _on_message_decrypted(output, val):
>A># blabla

>A> ThreadInterface(decrypt_thread, [encmsg, keyID], _on_message_decrypted,
>A> [val])


>A> But between the time "thread called" is printed and the time "func
>A> start" is printed, there is sometimes (it vary a lot) several seconds.

>A> How could it be? Why thread is not started instantly? How can I improve
>A> that?

I don't know if it is related to our problem but I guess it is.

It appears that GTK and Python threads are incompatible UNLESS you call
gtk.gdk.threads_init() before gtk.main(). This has something to do with
releasing the GIL, which gtk optimizes away if it hasn't been told that
your application uses threads.
-- 
Piet van Oostrum 
URL: http://pietvanoostrum.com [PGP 8DAE142BE17999C4]
Private email: p...@vanoostrum.org
--
http://mail.python.org/mailman/listinfo/python-list

Re: Marshal vs pickle...

[Paul Rubin]

Lawson English  writes:
> I read somewhere that Marshalling is version-dependent while pickling
> is not, but can't find that reference. 

It is in the python library docs for the marshal module.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Lisp mentality vs. Python mentality

[Paul Rubin]

Hrvoje Niksic  writes:
> I guess you meant map(a, str.upper) == map(b, str.upper)?  a and b are
> lists of strings.

Oh, sorry.  Yes, either 

map(str.upper, a) == map(str.upper, b)

or

all(str.upper(x)==str.upper(y) for x,y in zip(a,b))
--
http://mail.python.org/mailman/listinfo/python-list

Re: Marshal vs pickle...

[Pascal Chambon]

Hello

I've never run into a discussion on pickle vs marshal, but clearly if 
the point is to exchange data between different clients, or to store it, 
pickle is the preferred solution, as masrhal is really too low level and 
its format too unstable.
Indeed, the problem of pickle is that at the contrary, it transmits too 
much information, including executable code, etc, so it's a security risk.


If you only need to transmit data, like objects (without their methods), 
arrays, dicts etc. over networks or time, I'd advise a dedicated 
solution like json or xml, for which python as easy serializers.


Regards,
Pascal



Lawson English a écrit :


Marshalling is only briefly mentioned in most python books I have, and 
"pickling" is declared teh preferred method for serialization.


I read somewhere that Marshalling is version-dependent while pickling 
is not, but can't find that reference. OTOH, pickling can lead to 
loading of malicious code (I understand) while marshalling only 
handles basic Python types?



Could anyone point me to a reasonable discussion of the pros and cons 
of each method for serialization?



Thanks.


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





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

Marshal vs pickle...

[Lawson English]

Marshalling is only briefly mentioned in most python books I have, and 
"pickling" is declared teh preferred method for serialization.


I read somewhere that Marshalling is version-dependent while pickling is 
not, but can't find that reference. OTOH, pickling can lead to loading 
of malicious code (I understand) while marshalling only handles basic 
Python types?



Could anyone point me to a reasonable discussion of the pros and cons of 
each method for serialization?



Thanks.


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

Thread lag

[Asterix]

Hi,

Here is a small class I use in my GTK application, to do some job in a
thread.:

class ThreadInterface:
   def __init__(self, func, func_args, callback, callback_args):
  '''Call a function in a thread and then call callback'''
  def thread_function(func, func_args, callback, callback_args):
 print 'func start'
 output = func(*func_args)
 gobject.idle_add(callback, output, *callback_args)
  Thread(target=thread_function, args=(func, func_args, callback,
 callback_args)).start()
  print 'thread called'

Here is the way I call the class:

def decrypt_thread(encmsg, keyID):
   # Do things
   return val1, val2)

def _on_message_decrypted(output, val):
   # blabla

ThreadInterface(decrypt_thread, [encmsg, keyID], _on_message_decrypted,
[val])


But between the time "thread called" is printed and the time "func
start" is printed, there is sometimes (it vary a lot) several seconds.

How could it be? Why thread is not started instantly? How can I improve
that?

Thanks for your help
--
http://mail.python.org/mailman/listinfo/python-list

Re: PyQt4 - widget signal trouble

[Joacim Thomassen]

Den Fri, 24 Apr 2009 22:24:46 +0100, skrev Phil Thompson:

> On Fri, 24 Apr 2009 12:37:02 -0500, Joacim Thomassen
>  wrote:
>> Hello,
>> 
>> I'm trying to get my first PyQt4 application to work as intended, but
>> it seems I'm stuck and out of ideas for now.
>> 
>> The program is a simple GUI showing an image. If the image on disk
>> change
> 
>> my intension is that the displayed image in my application also change
>> accordingly.
>> 
>> What works: The filesystem change is detected and my program prints out
>> "Change happened!"
>> 
>> what is the problem: The image shown in the application is not changed.
>> 
>> What am I doing wrong here? Any ideas and suggestions are appreciated.
> 
> I don't know if it is the cause but 2 of your super() calls use the
> wrong class.
> 
> Phil

Thanks,

I changed the super() call for Watcher to QObject and MainWindow to 
QMainWindow, but it did not seem to directly help me closer to my goal. I 
still only get the "Change happened!" printed to stdout as I exit my 
application. No change is seen as long as the widget is shown. And the 
image file image.jpg overwritten on the file system did not reload in my 
application.

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

Re: mailbox.mbox.add() sets access time as well as modification time

[MRAB]

tinn...@isbd.co.uk wrote:

Grant Edwards  wrote:

On 2009-04-24, Grant Edwards  wrote:


Anybody writing to an mbox mailbox has to follow the rules if
they expect to interoperate with other mail applications.  If
mailbox.mbox.add() doesn't preserve the atime when writing to
an mbox, then mailbox.mbox.add is broken.

I should qualify that: since the documentation for add()
doesn't specify whether or not it's supposed to add a "new"
message or an "old" message, one could argue that either
behavior is correct.

However, since the maildir add() method adds a "new" message,
one would reasonably expect that the mbox add() method do the
same.  Or, I suppose one might expect the converse: since mbox
add() creates an "old" message, then maildir add() should do
the same.

I have my filesystems mouted with the "noatime" option and use
maildir...


Whatever, if mailbox.mbox.add() doesn't preserve the atime when adding
messages to an mbox then it's close to useless.

I suppose I could do the following:-

lock the mbox
get the atime
add the new message with mailbox.mbox.add()
restore the atime
unlock the mbox

All I need to do now is find out how to get and set atime with python.


os.path.getmtime(path)
os.path.getatime(path)
os.utime(path, (atime, mtime))
--
http://mail.python.org/mailman/listinfo/python-list

Re: mailbox.mbox.add() also seems to set file permissions

[Grant Edwards]

On 2009-04-25, tinn...@isbd.co.uk  wrote:

> Where should one report bugs/errors in python library classes?

http://docs.python.org/bugs.html

-- 
Grant Edwards   grante Yow! Gee, I feel kind of
  at   LIGHT in the head now,
   visi.comknowing I can't make my
   satellite dish PAYMENTS!
--
http://mail.python.org/mailman/listinfo/python-list

Re: mailbox.mbox.add() sets access time as well as modification time

[Grant Edwards]

On 2009-04-25, tinn...@isbd.co.uk  wrote:
> Grant Edwards  wrote:
>> On 2009-04-24, Grant Edwards  wrote:
>> 
>> > Anybody writing to an mbox mailbox has to follow the rules if
>> > they expect to interoperate with other mail applications.  If
>> > mailbox.mbox.add() doesn't preserve the atime when writing to
>> > an mbox, then mailbox.mbox.add is broken.
>> 
>> I should qualify that: since the documentation for add()
>> doesn't specify whether or not it's supposed to add a "new"
>> message or an "old" message, one could argue that either
>> behavior is correct.
>> 
>> However, since the maildir add() method adds a "new" message,
>> one would reasonably expect that the mbox add() method do the
>> same.  Or, I suppose one might expect the converse: since mbox
>> add() creates an "old" message, then maildir add() should do
>> the same.
>> 
>> I have my filesystems mouted with the "noatime" option and use
>> maildir...
>
> Whatever, if mailbox.mbox.add() doesn't preserve the atime when adding
> messages to an mbox then it's close to useless.

That's what I said: it's broken.  Nobody is arguing that it
isn't.  The question is who's going to step up and fix it.
Those of us who don't use mbox format are a bit less motivated
than those who do.

> I suppose I could do the following:-
>
> lock the mbox
> get the atime
> add the new message with mailbox.mbox.add()
> restore the atime
> unlock the mbox

You could fix mbox.add().  ;)

> All I need to do now is find out how to get and set atime with python.

You use os.utime().

>From http://docs.python.org/library/os.html#module-os:

os.utime(path, times)

Set the access and modified times of the file specified by
path. If times is None, then the file's access and
modified times are set to the current time. (The effect is
similar to running the Unix program touch on the path.)
Otherwise, times must be a 2-tuple of numbers, of the form
(atime, mtime) which is used to set the access and modified
times, respectively. Whether a directory can be given for
path depends on whether the operating system implements
directories as files (for example, Windows does not). Note
that the exact times you set here may not be returned by a
subsequent stat() call, depending on the resolution with
which your operating system records access and modification
times; see stat().

Changed in version 2.0: Added support for None for times.

Availability: Unix, Windows.


-- 
Grant Edwards   grante Yow! My vaseline is
  at   RUNNING...
   visi.com
--
http://mail.python.org/mailman/listinfo/python-list

Re: Help AIX 5.3 build on Python-3.1a2

[Aahz]

In article ,
  wrote:
>
>> make
>xlc_r -q64 -c  -DNDEBUG -O2  -I. -IInclude -I./Include   -
>DPy_BUILD_CORE -o Modules/python.o ./Modules/python.c
>1506-507 (W) No licenses available. Contact your program supplier to
>add additional users. Compilation will proceed shortly.
>xlc_r -q64 -c  -DNDEBUG -O2  -I. -IInclude -I./Include   -
>DPy_BUILD_CORE -o Parser/acceler.o Parser/acceler.c
>1506-507 (W) No licenses available. Contact your program supplier to
>add additional users. Compilation will proceed shortly.
>"Include/token.h", line 42.9: 1506-213 (S) Macro name TILDE cannot be
>redefined.
>"Include/token.h", line 42.9: 1506-358 (I) "TILDE" is defined on line
>250 of /usr/include/sys/ioctl.h.
>make: 1254-004 The error code from the last command is 1.

Posting the entire autoconf output without first summarizing the problem
will likely cause many people to ignore your post.  In addition, AIX is
traditionally one of the problem platforms, which also will generate
little interest.  You will almost certainly need to do a lot of the
gruntwork, and unless you're already familiar with AIX foibles, this is
likely to be unfixable.  Can you try trimming down the compilation to a
small reproducible case?
-- 
Aahz (a...@pythoncraft.com)   <*> http://www.pythoncraft.com/

"If you think it's expensive to hire a professional to do the job, wait
until you hire an amateur."  --Red Adair
--
http://mail.python.org/mailman/listinfo/python-list

Re: and [True,True] --> [True, True]?????

[Duncan Booth]

jazbees  wrote:

 hasvowels = lambda x:max([y in x for y in "aeiou"])
 hasvowels("parsnips")
> True
 hasvowels("sfwdkj")
> False
> 

Do you object to using def to define functions?

Anyway, it is probably clearer to use the builtin 'any' for code like this:

>>> def hasvowels(s):
... return any(v in s for v in "aeiou")
...
>>> hasvowels("parsnips")
True
>>> hasvowels("sfwdkj")
False
>>>



 foo = ["green", "orange"]
 bar = ["blue", "green", "red", "yellow"]
 found = lambda x,y:max([z in y for z in x] if x else [False])
 found(foo, bar)
> True
 foo = []
 found(foo, bar)
> False

If you are doing a lot of this consider whether you might be better off 
using sets:

>>> def found(x,y):
...return bool(set(x).intersection(y))
...
--
http://mail.python.org/mailman/listinfo/python-list

Re: pythonCE GetSystemPowerState windows api

[lorenzo . mentaschi]

On Apr 25, 6:19 pm, Thomas Heller  wrote:
> lorenzo.mentas...@yahoo.it schrieb:
>
>
>
> > Hi all,
> > I need to call GetSystemPowerState windows api from pythonCE, because
> > I need to know if a windows ce 5 device is in sleep/off status.
> > I can find this api in ctypes.windll.coredll, but I cannot figure out
> > how to pass parameters to this procedure: msdn giude (
> >http://msdn.microsoft.com/en-us/library/ms899319.aspx) speaks about 3
> > parameters, of wich 2 are output: a "LPWSTR pBuffer" and a "PDWORD
> > pFlags". Returned value of the call is an exit status code
> > rappresenting if call succeded or failed.
>
> > I tried to call this api in several ways, but obtained always exit
> > code 87 (meaning that parameters are wrong) or 122 (meaning "pBuffer"
> > variable is too small, in this case I passed None as pBuffer, since
> > I'm interested only in pFlags result).
>
> > Have you any idea? Maybe another api or way to perform this simple
> > task?
>
> Python 2.5 (release25-maint, Dec 19 2006, 23:22:00) [MSC v.1201 32 bit (ARM)] 
> on win32>>> from ctypes import *
> >>> d=windll.coredll
> >>> d.GetSystemPowerState
>
> <_FuncPtr object at 0x0016EC60>
>
> >>> p=create_unicode_buffer(256)
> >>> flags=c_ulong()
> >>> f=d.GetSystemPowerState
> >>> f(p,256,byref(flags))
> 0
> >>> p.value
> u'on'
> >>> flags
> c_ulong(268500992L)
> >>> hex(flags.value)
> '0x1001L'
>
> Thomas

Thank you very much! :)
--
http://mail.python.org/mailman/listinfo/python-list

mailbox.mbox.add() also seems to set file permissions

[tinnews]

mailbox.mbox.add() has *another* 'quirk'.  When it adds a message to
an mbox file it seems to set the permissions to 0755 which is quite
wrong for mbox files.  I get the feeling that the mbox versions of the
functions are just bodged maildir ones.  If one was creating a maildir
it *might* make some sense setting to 0755.

Where should one report bugs/errors in python library classes?

-- 
Chris Green

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

Re: DigitalSigner in Python

[Martin P. Hellwig]

Marco Bizzarri wrote:

On Fri, Apr 24, 2009 at 7:57 AM, Good Z  wrote:

Hello All,

I need to digitally sign a document in python. Is there any equivalent
directory in Python like the DigitalSigner we have in Java.

Best Regards,
Mike





Maybe you could take a look at M2Crypto?

http://chandlerproject.org/Projects/MeTooCrypto

Regards
Marco


If all else fail you could wrap the openssl command line exe with 
subprocess.


--
MPH
http://blog.dcuktec.com
--
http://mail.python.org/mailman/listinfo/python-list

Daemonic processes in multiprocessing

[Pascal Chambon]

Hello everyone


I've just read the doc of the (awesome) "multiprocessing" module, and 
there are some little things I don't understand, concerning daemon 
processes (see quotes below).


When a python process exits, the page says it attempts to join all its 
children. Is this just a design choice, or are there constraints behind 
this ? Because normally, when a parent process exits, its child gets 
adopted by init, and that can be useful for creating daemons, can't it ?


Concerning daemons processes, precisely, the manual states that they are 
all terminated when their parent process exits. But isn't it contrary to 
the concept of dameons, which are supposed to have become independent 
from their parent ?


And I don't understand how "the initial value (of the "daemonic" 
attribute) is inherited from the creating process", since "daemonic 
processes are not allowed to create child processes". Isn't it the same 
to say that "daemonic" is always false by default, then ?
And finally, why can't daemonic processes have children ? If these 
children get "orphaned" when the daemonic process gets terminated (by 
its parent), they'll simply get adpoted by init, won't they ?


Thanks a lot for helping me get rid of my confusion,
regards,
Pascal


=QUOTES==
daemon¶ 



   The process's daemon flag, a Boolean value. This must be set before
   start()
   

   is called.

   The initial value is inherited from the creating process.

   When a process exits, it attempts to terminate all of its daemonic
   child processes.

   Note that a daemonic process is not allowed to create child
   processes. Otherwise a daemonic process would leave its children
   orphaned if it gets terminated when its parent process exits.

   --

Similarly, if the child process is non-daemonic then the parent
process may hang on exit when it tries to join all its non-daemonic children.
--
Remember also that non-daemonic
processes will be automatically be joined.


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

Re: authentication example with urllib.request

[Marco Bizzarri]

On Sat, Apr 25, 2009 at 8:09 AM, larryzhang  wrote:
> Dear all,
>
> I am trying to download data from a website that requires
> authentication (maybe with cookies). Any suggestions on how i can do
> this with the urllib.request module in py3? Where can I can find some
> working examples? Thanks a lot.
>
> Larry
> --
> http://mail.python.org/mailman/listinfo/python-list
>


Hi, Larry.

Did you get a look at library documentation? If you take a look at
http://docs.python.org/3.0/library/urllib.request.html, FancyURLOpener
could do the job for you... (once you subclass it, and redefine the
promp_user_password method).

Regards
Marco



-- 
Marco Bizzarri
http://notenotturne.blogspot.com/
http://iliveinpisa.blogspot.com/
--
http://mail.python.org/mailman/listinfo/python-list

Re: mailbox.mbox.add() sets access time as well as modification time

[tinnews]

Grant Edwards  wrote:
> On 2009-04-24, Lawrence D'Oliveiro  wrote:
> > In message , Grant Edwards 
> > wrote:
> >
> >> AFAIK, atime >> when an mbox contains new mail for at least 20 years.
> >
> > Doesn't apply to maildir though, does it?
> 
> Nope.  With maildir, there's a completely separate directory
> where one puts new messages.
> 
> > Updating atime adds a lot of filesystem overhead; that's why
> > the relatime option was invented .
> 
> The relatime should cut down a great deal on system overhead
> and yet still preserves the atime/mtime semantics used by mbox
> clients.
> 
Yes, my filesystems are mounted with relatime set.  It's not much use
if mailbox.mbox.add() doesn't play by the rules though.

mbox has several advantages over maildir (for me anyway):-

It allows easy removal of empty mailboxes (in my case by the MUA)

It's much easier to search

It's easier to move things around

It doesn't have silly ways of delimiting directories as do some
maildir implementations.

-- 
Chris Green

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

Re: mailbox.mbox.add() sets access time as well as modification time

[tinnews]

Grant Edwards  wrote:
> On 2009-04-24, Grant Edwards  wrote:
> 
> > Anybody writing to an mbox mailbox has to follow the rules if
> > they expect to interoperate with other mail applications.  If
> > mailbox.mbox.add() doesn't preserve the atime when writing to
> > an mbox, then mailbox.mbox.add is broken.
> 
> I should qualify that: since the documentation for add()
> doesn't specify whether or not it's supposed to add a "new"
> message or an "old" message, one could argue that either
> behavior is correct.
> 
> However, since the maildir add() method adds a "new" message,
> one would reasonably expect that the mbox add() method do the
> same.  Or, I suppose one might expect the converse: since mbox
> add() creates an "old" message, then maildir add() should do
> the same.
> 
> I have my filesystems mouted with the "noatime" option and use
> maildir...
> 
Whatever, if mailbox.mbox.add() doesn't preserve the atime when adding
messages to an mbox then it's close to useless.

I suppose I could do the following:-

lock the mbox
get the atime
add the new message with mailbox.mbox.add()
restore the atime
unlock the mbox

All I need to do now is find out how to get and set atime with python.

-- 
Chris Green

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

Re: DigitalSigner in Python

[Marco Bizzarri]

On Fri, Apr 24, 2009 at 7:57 AM, Good Z  wrote:
> Hello All,
>
> I need to digitally sign a document in python. Is there any equivalent
> directory in Python like the DigitalSigner we have in Java.
>
> Best Regards,
> Mike
>
>


Maybe you could take a look at M2Crypto?

http://chandlerproject.org/Projects/MeTooCrypto

Regards
Marco


-- 
Marco Bizzarri
http://notenotturne.blogspot.com/
http://iliveinpisa.blogspot.com/
--
http://mail.python.org/mailman/listinfo/python-list

Re: mailbox.mbox.add() sets access time as well as modification time

[tinnews]

MRAB  wrote:
> tinn...@isbd.co.uk wrote:
> > It seems to me that mailbox.mbox.add() sets the access time of a mbox
> > file as well as the modification time.  This is not good for MUAs that
> > detect new mail by looking to see if the access time is before the
> > modification time.
> > 
> > Have I done something wrong somewhere or is mailbox.mbox.add() really
> > as broken as it would appear?
> > 
> [snip]
> The access time is the time it was last accessed, ie read or modified.
> 
> The modification time is the time it was last modified.
> 
> The access time can never be before the modification time because it
> must be accessed in order to be modified!

Well in that case very MUA that I have ever come across is broken!
Access time *can* be before modification time, that's how most MUAs
work with mbox files.

-- 
Chris Green

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

Re: Python not importing mysqldb

[Marco Bizzarri]

On Fri, Apr 24, 2009 at 10:04 PM, 83nini <83n...@gmail.com> wrote:
> hi guys,
>
> i've been sweating the whole day trying to make python work with mysql
> but in vain!
> i'm doing the following:
> 1. visiting http://sourceforge.net/projects/mysql-python
> 2. dowloading mysql-python-test-1.2.3c1
> 3. extracting the files to C:\Python26\Lib\site-packages
> 4. writing "import MySQLdb" in the python prompt
>
> getting
>
> Traceback (most recent call last):
>  File "", line 1, in 
>  File "C:\Python26\lib\site-packages\MySQLdb\__init__.py", line 19,
> in 
>
>    import _mysql
> ImportError: No module named _mysql
>
> WHY Y
> why does it have to be so complicated what am i doing wrong for
> god's sake?



Suggestion: install python2.5 for windows, and then download this one:

http://sourceforge.net/project/downloading.php?group_id=22307&filename=MySQL-python-1.2.2.win32-py2.5.exe&a=71602382

I'm sure you'll save yourself a lot of time.

Regards
Marco





-- 
Marco Bizzarri
http://notenotturne.blogspot.com/
http://iliveinpisa.blogspot.com/
--
http://mail.python.org/mailman/listinfo/python-list

Re: pythonCE GetSystemPowerState windows api

[Thomas Heller]

lorenzo.mentas...@yahoo.it schrieb:
> Hi all,
> I need to call GetSystemPowerState windows api from pythonCE, because
> I need to know if a windows ce 5 device is in sleep/off status.
> I can find this api in ctypes.windll.coredll, but I cannot figure out
> how to pass parameters to this procedure: msdn giude (
> http://msdn.microsoft.com/en-us/library/ms899319.aspx ) speaks about 3
> parameters, of wich 2 are output: a "LPWSTR pBuffer" and a "PDWORD
> pFlags". Returned value of the call is an exit status code
> rappresenting if call succeded or failed.
> 
> I tried to call this api in several ways, but obtained always exit
> code 87 (meaning that parameters are wrong) or 122 (meaning "pBuffer"
> variable is too small, in this case I passed None as pBuffer, since
> I'm interested only in pFlags result).
> 
> Have you any idea? Maybe another api or way to perform this simple
> task?

Python 2.5 (release25-maint, Dec 19 2006, 23:22:00) [MSC v.1201 32 bit (ARM)] 
on win32
>>> from ctypes import *
>>> d=windll.coredll
>>> d.GetSystemPowerState
<_FuncPtr object at 0x0016EC60>
>>> p=create_unicode_buffer(256)
>>> flags=c_ulong()
>>> f=d.GetSystemPowerState
>>> f(p,256,byref(flags))
0
>>> p.value
u'on'
>>> flags
c_ulong(268500992L)
>>> hex(flags.value)
'0x1001L'
>>>


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

Re: New at Python, some trouble with examples

[Kevin Forbes VK3KUF]

"MRAB"  wrote in message 
news:mailman.4563.1240669629.11746.python-l...@python.org...
> Kevin Forbes VK3KUF wrote:
>> Hello folks, my name is Kevin, HAM call vk3ukf, site www.vk3ukf.com
>>
>> I am brand new to Python and having the big learn at the moment.
>> Running Windows XP pro SP3 with Delphi 7 free version
>> I installed Python 2.6 and the 1.1.6 PIL to go with it
>> Now, because I am running the free version of Delphi 7.
>>
>> I had to remove the vcldb and maybe some other reference in 
>> PythonForDelphi installation files.
>> They were removed to allow me to fix the Delphi Python installation *.dpk 
>> files in the C:\Program
>>
>> Files\PythonForDelphi\Components directory, for Delphi to accept and 
>> compile them.
>>
>> Oh, and I had to rename the Python26.dll to Python25.dll for Delphi to 
>> operate. ???
>>
> [snip]
> The fact that you had to rename to Python25.dll suggests that Delphi is
> expecting Python 2.5. You might want to download Python 2.5 (actually
> Python 2.5.4) instead to see whether that works better.

Hello, thanks for your reply,

I have gotten Delphi to successfuly run some scripts,
but not one including import image.

e.g.

# Python Code Test File

FILENAME = PythonDelphiVar1.Value
BLIMEY = PythonDelphiVar2.Value

infile = ''
outfile = ''

class MakeJpgFromPgm:
  def __init__(MakeJpgFromPgm, FileName=''):
MakeJpgFromPgm.FileName = FILENAME

  def RunReport(MakeJpgFromPgm):
print 'FileName ' + MakeJpgFromPgm.FileName
print  ' Yada Yada.'
print  MakeJpgFromPgm.FileName
print  'PD1 ' + PythonDelphiVar1.Value

class MakeJpgFromPgm2:
  def __init__(MakeJpgFromPgm2, ImageTest=''):
MakeJpgFromPgm2.ImageTest = BLIMEY

if PythonDelphiVar2.Value == 1:
print  'PD2 ' + 'True'
if PythonDelphiVar2.Value == 0:
print  'PD2 ' + 'False'

# end py code

The above showed me that I could pass values from variables back and forth.


I'll try your suggestion MRAB, let you know what happens.



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

Re: PEP 383: Non-decodable Bytes in System Character Interfaces

[Zooko O'Whielacronx]

Thanks for writing this PEP 383, MvL.  I recently ran into this  
problem in Python 2.x in the Tahoe project [1].  The Tahoe project  
should be considered a good use case showing what some people need.   
For example, the assumption that a file will later be written back  
into the same local filesystem (and thus luckily use the same  
encoding) from which it originally came doesn't hold for us, because  
Tahoe is used for file-sharing as well as for backup-and-restore.


One of my first conclusions in pursuing this issue is that we can  
never use the Python 2.x unicode APIs on Linux, just as we can never  
use the Python 2.x str APIs on Windows [2].  (You mentioned this  
ugliness in your PEP.)  My next conclusion was that the Linux way of  
doing encoding of filenames really sucks compared to, for example,  
the Mac OS X way.  I'm heartened to see what David Wheeler is trying  
to persuade the maintainers of Linux filesystems to improve some of  
this: [3].


My final conclusion was that we needed to have two kinds of  
workaround for the Linux suckage: first, if decoding using the  
suggested filesystem encoding fails, then we fall back to mojibake  
[4] by decoding with iso-8859-1 (or else with windows-1252 -- I'm not  
sure if it matters and I haven't yet understood if utf-8b offers  
another alternative for this case).  Second, if decoding succeeds  
using the suggested filesystem encoding on Linux, then write down the  
encoding that we used and include that with the filename.  This  
expands the size of our filenames significantly, but it is the only  
way to allow some future programmer to undo the damage of a falsely- 
successful decoding.  Here's our whole plan: [5].


Regards,

Zooko

[1] http://allmydata.org
[2] http://allmydata.org/pipermail/tahoe-dev/2009-March/001379.html #  
see the footnote of this message

[3] http://www.dwheeler.com/essays/fixing-unix-linux-filenames.html
[4] http://en.wikipedia.org/wiki/Mojibake
[5] http://allmydata.org/trac/tahoe/ticket/534#comment:47
--
http://mail.python.org/mailman/listinfo/python-list

Re: and [True,True] --> [True, True]?????

[jazbees]

I'm surprised to see that the use of min and max for element-wise
comparison with lists has not been mentioned.  When fed lists of True/
False values, max will return True if there is at least one True in
the list, while min will return False if there is at least one False.
Going back to the OP's initial example, one could wrap a min check on
each list inside another min.

>>> A = [False, True]
>>> B = [True, True]
>>> min(A)
False
>>> min(B)
True
>>> min(min(A), min(B))
False

In a recent work project, I made use of this behavior to condense the
code required to test whether any item in a list of strings could be
found in another string.  Here's a variation on that concept that
checks to see if a string contains any vowels:

>>> hasvowels = lambda x:max([y in x for y in "aeiou"])
>>> hasvowels("parsnips")
True
>>> hasvowels("sfwdkj")
False

If using Python 2.5 or later, this could be combined with Python's
version of the ternary operator if your code is such that the source
list may be empty, which is what I ended up using for my project.

>>> foo = ["green", "orange"]
>>> bar = ["blue", "green", "red", "yellow"]
>>> found = lambda x,y:max([z in y for z in x] if x else [False])
>>> found(foo, bar)
True
>>> foo = []
>>> found(foo, bar)
False
--
http://mail.python.org/mailman/listinfo/python-list

Re: Lisp mentality vs. Python mentality

[Hrvoje Niksic]

Paul Rubin  writes:

> "Ciprian Dorin, Craciun"  writes:
>> A practical example: I have lists that contain strings, but I want
>> to compare them in an case-insensitive way... Should I update the
>> __eq__ method (for str class) and break almost everything? Can I write
>> now a == b? Nop... I need the loop you've just mentioned in all the
>> places where the comparison changes just in the operator, not in the
>> algorithm... (I would say this is bad coding practice...)
>
> In Lisp I think you'd use (equal (mapcar upcase a) (mapcar upcase
> b))

Or simply (equalp a b), since equalp comparisons happen to compare
strings case-insensitively.  But that's Common Lisp... overflowing
kitchen sink.

> or something like that.  In Python, a.upper() == b.upper().

I guess you meant map(a, str.upper) == map(b, str.upper)?  a and b are
lists of strings.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Learning Python the quick way

[Esmail]

Thanks Tim,

Esmail

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

Re: New at Python, some trouble with examples

[MRAB]

Kevin Forbes VK3KUF wrote:

Hello folks, my name is Kevin, HAM call vk3ukf, site www.vk3ukf.com

I am brand new to Python and having the big learn at the moment.
Running Windows XP pro SP3 with Delphi 7 free version
I installed Python 2.6 and the 1.1.6 PIL to go with it
Now, because I am running the free version of Delphi 7.

I had to remove the vcldb and maybe some other reference in PythonForDelphi 
installation files.
They were removed to allow me to fix the Delphi Python installation *.dpk 
files in the C:\Program


Files\PythonForDelphi\Components directory, for Delphi to accept and compile 
them.


Oh, and I had to rename the Python26.dll to Python25.dll for Delphi to 
operate. ???



[snip]
The fact that you had to rename to Python25.dll suggests that Delphi is
expecting Python 2.5. You might want to download Python 2.5 (actually
Python 2.5.4) instead to see whether that works better.
--
http://mail.python.org/mailman/listinfo/python-list

New at Python, some trouble with examples

[Kevin Forbes VK3KUF]

Hello folks, my name is Kevin, HAM call vk3ukf, site www.vk3ukf.com

I am brand new to Python and having the big learn at the moment.
Running Windows XP pro SP3 with Delphi 7 free version
I installed Python 2.6 and the 1.1.6 PIL to go with it
Now, because I am running the free version of Delphi 7.

I had to remove the vcldb and maybe some other reference in PythonForDelphi 
installation files.
They were removed to allow me to fix the Delphi Python installation *.dpk 
files in the C:\Program

Files\PythonForDelphi\Components directory, for Delphi to accept and compile 
them.

Oh, and I had to rename the Python26.dll to Python25.dll for Delphi to 
operate. ???

I got it going, but it may be crippled in some ways.

I tired an example that executes wonderfully on its own, using the Python in 
my machine.

This will display basic info on the image such as format type and dimensions 
and convert a *.PGM format image with

the filename r9516294.pgm  into a *.JPG format image and then save it as 
.jpg.


# Python Test File - ImageOpen3.py

import os, sys
import Image

infile = "r9516294.pgm"

im = Image.open(infile)
print im.format, im.size, im.mode

outfile = ".jpg"
if infile != outfile:
try:
Image.open(infile).save(outfile)
except IOError:
print "cannot convert", infile

# end of Py code


That works fine when run from IDLE, Pythons own engine and debugger.

It also works fine if I call it from my Delphi app. as an external app. to 
be run using the Delphi code,

procedure TForm1.Button4Click(Sender: TObject);
begin
ShellExecute(Handle, 'open', PChar('ImageOpen3.py'), nil, nil, 
SW_SHOWNORMAL) ;
end;


My problem occurs when I attempt to run this Python script in the following 
way from Delphi

The Delphi form has an AtomPythonEngine1 and a PythonInputOutput1 on it.
The IO property of the AtomPythonEngine1 is set to PythonInputOutput1.


procedure TForm1.Button2Click(Sender: TObject);
begin
PyExeFile('ImageOpen3.py', AtomPythonEngine1);
end;

My Delphi app. crashes, saying the application has requested to terminate in 
an unusual way. Really!!

I also tried,


procedure TForm1.Button5Click(Sender: TObject);
begin
PyExe('ImageOpen3.py', AtomPythonEngine1);
end;

That produces the error,

exceptions.NameError: name 'ImageOpen3' is not defined.

If I include the code,

procedure TForm1.FormCreate(Sender: TObject);
begin
PyExeFile('ImageOpen3.py', AtomPythonEngine1);
end;

The app. crashes upon starting, again with the message about the unusual 
ways.

I tried building the Py code line by line and getting Delphi to run it.

It began to crash as soon as I included the Python code,

import Image.


This line of code is OK though,
import os, sys


This is not very good, as it is images I am trying to manipulate.

I tried this,
from PIL import Image

That also crashed with unusual ways.


I am still wading through the demos and tutorials.

I am obviously perplexed, it doesn't seem to be a lacking in Python, as the 
script runs beaut on its own.
I think Delphi has a problem, possibly me and my current lack of knowledge, 
hoping it's not anything else.

Any help, much appreciated.

Thanks in advance to the list, Kevin. 


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

Re: Learning Python the quick way

[Tim Chase]

Esmail wrote:

Tim Chase wrote:

However the first rule:  profile first!


Do you have a favorite profiling tool? What should someone new
to Python (but not programming) use?


I personally use the cheapo method of dropping in a few "print" 
statements to dump where I currently am in the app, and then see 
where it hangs.  "Hmm, it seems to take a long time to get from 
step J to step K, I better zoom in on that block of code"  I 
usually have a good intuition where to go digging first (such as 
multi-nested loops, network communications, file I/O, or database 
queries) which is fairly close most of the time.


If possible, I'll occasionally comment out the code I suspect (or 
perform a null-op instead of actually executing the block) to 
confirm that this block is the problem.  However, sometimes I 
can't readily do that because it sets up data structures that are 
needed elsewhere.


There are several profiling tools for Python, including the 
cProfile module[1] but I've never gotten to the point where I've 
needed that level of detail.


-tkc

[1] http://docs.python.org/library/profile.html

PS:  this is a trade-off between "what I've always done" and 
"darn, the stdlib provides yet one more battery I could be using 
instead of rolling my own".  I finally switched to using the csv, 
ConfigParser, pdb, and optparse modules because they were faster 
routes to better solutions than my own hacks.  However I still 
tend to just use print statements for profiling & logging instead 
of the logging and cProfile modules.  I guess I just haven't 
experienced enough pain in my own code to switch yet :)



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

Re: Lisp mentality vs. Python mentality

[Ciprian Dorin, Craciun]

On Sat, Apr 25, 2009 at 4:01 PM, "Martin v. Löwis"  wrote:
>>     Indeed the example I've given is purely theoretical. But still, I
>> could find a use case for such a thing: just imagine we are building a
>> small shell-like application that reads one line (the commands),
>> splits it by spaces and always expects to have 4 elements and that
>> each respects a given regular expression, one specific for each index.
>> In this case I could syntactically check for correctness by doing
>> this:
>>
>>     compare (regular_expressions, splitted_line, re.match)
>>
>>     Of course I could have just created a big regular expression for
>> the entire line. But maybe my 4 elements come from variables obtained
>> from a web-server query, or the regular expressions are not static but
>> dynamically generated at run-time.
>
> Ok, in this case I would write a function:
>
> def validate_commandline(rexes, line):
>    if len(rexes) != len(line):
>        raise ValueError("Incorrect number of arguments, expected %d,"
>                         "got %d" % (len(rexes), len(line)))
>    for i in range(len(line)):
>        if not re.match(rexes[i], line[i]):
>            raise ValueError, "Incorrect argument %d" % i
>
> IOW, in this specific case, I would not only want a true/false result,
> but also an indication of the actual error to report to the user.
> Your universal compare function would be no good here.
>
> Regards,
> Martin
>


Well in fact I would have written it like:

def validate_commandline(rexes, line) :
if not compare (rexes, line, re.match) :
if len (rexes) != len (line) :
raise ValueError ("mismatch len")
mismatch = find_index (rexes, line, re.match, negate = True)
raise ValueError ("mismatch at %d" % (mismatch))

Assuming, that I would have the function find_index.

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

Re: Lisp mentality vs. Python mentality

[Martin v. Löwis]

> Indeed the example I've given is purely theoretical. But still, I
> could find a use case for such a thing: just imagine we are building a
> small shell-like application that reads one line (the commands),
> splits it by spaces and always expects to have 4 elements and that
> each respects a given regular expression, one specific for each index.
> In this case I could syntactically check for correctness by doing
> this:
> 
> compare (regular_expressions, splitted_line, re.match)
> 
> Of course I could have just created a big regular expression for
> the entire line. But maybe my 4 elements come from variables obtained
> from a web-server query, or the regular expressions are not static but
> dynamically generated at run-time.

Ok, in this case I would write a function:

def validate_commandline(rexes, line):
if len(rexes) != len(line):
raise ValueError("Incorrect number of arguments, expected %d,"
 "got %d" % (len(rexes), len(line)))
for i in range(len(line)):
if not re.match(rexes[i], line[i]):
raise ValueError, "Incorrect argument %d" % i

IOW, in this specific case, I would not only want a true/false result,
but also an indication of the actual error to report to the user.
Your universal compare function would be no good here.

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

PyCon Italy 2009: Late Bird Deadline

[Alan Franzoni]

The late-bird registration deadline for PyCon Tre (PyCon Italy 2009) is 
May 4th.

The conference will take place in Florence from May 8th till May 10th 2009, 
and features guests like Guido Van Rossum, Alex Martelli, Raymond 
Hettinger, Fredrik Lundh and Antonio Cangiano.

Feel free to take a look at the schedule:
http://www.pycon.it/pycon3/schedule/

A simultaneous interpretation service is available for the main track:

http://www.pycon.it/pycon3/non-italians

See you in Florence!


-- 
Alan Franzoni 
-
Remove .xyzz from my email in order to contact me.
-
GPG Key Fingerprint:
5C77 9DC3 BD5B 3A28 E7BC 921A 0255 42AA FE06 8F3E
--
http://mail.python.org/mailman/listinfo/python-list

Re: [Python-Dev] PEP 383: Non-decodable Bytes in System Character Interfaces

[Martin v. Löwis]

> If the bytes are mapped to single half surrogate codes instead of the
> normal pairs (low+high), then I can see that decoding could never be
> ambiguous and encoding could produce the original bytes.

I was confused by Markus Kuhn's original UTF-8b specification. I have
now changed the PEP to avoid using PUA characters at all.

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

Re: Learning Python the quick way

[Esmail]

Tim Chase wrote:



2) if it's slow, profile it and check your algorithm(s), recoding if 
you're using some algorithm with a bad big-oh profile



<..>


However the first rule:  profile first!



Tim,

Do you have a favorite profiling tool? What should someone new
to Python (but not programming) use?

Thanks,
Esmail

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

pythonCE GetSystemPowerState windows api

[lorenzo . mentaschi]

Hi all,
I need to call GetSystemPowerState windows api from pythonCE, because
I need to know if a windows ce 5 device is in sleep/off status.
I can find this api in ctypes.windll.coredll, but I cannot figure out
how to pass parameters to this procedure: msdn giude (
http://msdn.microsoft.com/en-us/library/ms899319.aspx ) speaks about 3
parameters, of wich 2 are output: a "LPWSTR pBuffer" and a "PDWORD
pFlags". Returned value of the call is an exit status code
rappresenting if call succeded or failed.

I tried to call this api in several ways, but obtained always exit
code 87 (meaning that parameters are wrong) or 122 (meaning "pBuffer"
variable is too small, in this case I passed None as pBuffer, since
I'm interested only in pFlags result).

Have you any idea? Maybe another api or way to perform this simple
task?

Thank you all, Lorenzo
--
http://mail.python.org/mailman/listinfo/python-list

Re: Lisp mentality vs. Python mentality

[Ciprian Dorin, Craciun]

On Sat, Apr 25, 2009 at 1:55 PM, "Martin v. Löwis"  wrote:
>>     A practical example: I have lists that contain strings, but I want
>> to compare them in an case-insensitive way...
>
> I'd claim that this is still theoretical: what are these strings, and
> why do you have lists of them that you want to compare?
>
> Why don't you try to lower-case the strings in the list as you
> add them?
>
> Also, are you sure a list is the best data structure for your problem?
> Perhaps using a set would be better?

Indeed the example I've given is purely theoretical. But still, I
could find a use case for such a thing: just imagine we are building a
small shell-like application that reads one line (the commands),
splits it by spaces and always expects to have 4 elements and that
each respects a given regular expression, one specific for each index.
In this case I could syntactically check for correctness by doing
this:

compare (regular_expressions, splitted_line, re.match)

Of course I could have just created a big regular expression for
the entire line. But maybe my 4 elements come from variables obtained
from a web-server query, or the regular expressions are not static but
dynamically generated at run-time.


>> Should I update the
>> __eq__ method (for str class) and break almost everything? Can I write
>> now a == b? Nop... I need the loop you've just mentioned in all the
>> places where the comparison changes just in the operator, not in the
>> algorithm... (I would say this is bad coding practice...)
>
> If you want to compare the same lists in many places, this is indeed
> bad coding practice. You should try to centralize whatever reasons
> you have for comparing the lists into a few methods of the objects
> holding the lists.
>
> Regards,
> Martin

I like object oriented programming, but most of the times we are
just throwing together code and data even when the data has no
behavior and the code is in fact just one possible processing
algorithm. Like in the case you are mentioning, if I tie the
comparison code to the actual data structure, then I'll never be able
to reuse it... But if I leave the code as a standalone function, and
just use the data (or any data that resembles the original structure)
then maybe I'll be able to reuse it...

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

Re: [Python-Dev] PEP 383: Non-decodable Bytes in System Character Interfaces

[Martin v. Löwis]

Cameron Simpson wrote:
> On 22Apr2009 08:50, Martin v. Löwis  wrote:
> | File names, environment variables, and command line arguments are
> | defined as being character data in POSIX;
> 
> Specific citation please? I'd like to check the specifics of this.

For example, on environment variables:

http://opengroup.org/onlinepubs/007908799/xbd/envvar.html

# For values to be portable across XSI-conformant systems, the value
# must be composed of characters from the portable character set (except
# NUL and as indicated below).

# Environment variable names used by the utilities in the XCU
# specification consist solely of upper-case letters, digits and the "_"
# (underscore) from the characters defined in Portable Character Set .
# Other characters may be permitted by an implementation;

Or, on command line arguments:

http://opengroup.org/onlinepubs/007908799/xsh/execve.html

# The arguments represented by arg0, ... are pointers to null-terminated
# character strings

where a character string is "A contiguous sequence of characters
terminated by and including the first null byte.", and a character
is

# A sequence of one or more bytes representing a single graphic symbol
# or control code. This term corresponds to the ISO C standard term
# multibyte character (multi-byte character), where a single-byte
# character is a special case of a multi-byte character. Unlike the
# usage in the ISO C standard, character here has no necessary
# relationship with storage space, and byte is used when storage space
# is discussed.

> So you're proposing that all POSIX OS interfaces (which use byte strings)
> interpret those byte strings into Python3 str objects, with a codec
> that will accept arbitrary byte sequences losslessly and is totally
> reversible, yes?

Correct.

> And, I hope, that the os.* interfaces silently use it by default.

Correct.

> | Applications that need to process the original byte
> | strings can obtain them by encoding the character strings with the
> | file system encoding, passing "python-escape" as the error handler
> | name.
> 
> -1
> 
> This last sentence kills the idea for me, unless I'm missing something.
> Which I may be, of course.
> 
> POSIX filesystems _do_not_ have a file system encoding.

Why is that a problem for the PEP?

> If I'm writing a general purpose UNIX tool like chmod or find, I expect
> it to work reliably on _any_ UNIX pathname. It must be totally encoding
> blind. If I speak to the os.* interface to open a file, I expect to hand
> it bytes and have it behave.

See the other messages. If you want to do that, you can continue to.

> I'm very much in favour of being able to work in strings for most
> purposes, but if I use the os.* interfaces on a UNIX system it is
> necessary to be _able_ to work in bytes, because UNIX file pathnames
> are bytes.

Please re-read the PEP. It provides a way of being able to access any
POSIX file name correctly, and still pass strings.

> If there isn't a byte-safe os.* facility in Python3, it will simply be
> unsuitable for writing low level UNIX tools.

Why is that? The mechanism in the PEP is precisely defined to allow
writing low level UNIX tools.

> Finally, I have a small python program whose whole purpose in life
> is to transcode UNIX filenames before transfer to a MacOSX HFS
> directory, because of HFS's enforced particular encoding. What approach
> should a Python app take to transcode UNIX pathnames under your scheme?

Compute the corresponding character strings, and use them.

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

ANN: Shed Skin 0.1.1

[Mark Dufour]

Hi all,

I have recently released version 0.1.1 of Shed Skin, an experimental
(restricted-)Python-to-C++ compiler.

This version comes with 5 new example programs (for a total of 35
examples, at over 10,000 lines in total). The most interesting new
example is Minilight (http://www.hxa.name/minilight/), a global
illumination renderer (or raytracer), that uses triangle primitives
and an octree spatial index. According to the Minilight homepage, it
becomes up to 100 times faster. Another interesting new example is
Peter Norvig's sudoku solver (http://norvig.com/sudoku.html), which
unfortunately doesn't become faster but is cool anyway.

Please see my blog for more information about the new release:

http://shed-skin.blogspot.com

The project homepage can be found here:

http://code.google.com/p/shedskin/

As I don't get much help, please consider joining the project. See my
blog for some ideas on how to help out. More test cases and bug
reports would also be very welcome.


Thanks,
Mark Dufour.
-- 
"One of my most productive days was throwing away 1000 lines of code"
- Ken Thompson
--
http://mail.python.org/mailman/listinfo/python-list

Re: Lisp mentality vs. Python mentality

[Martin v. Löwis]

> A practical example: I have lists that contain strings, but I want
> to compare them in an case-insensitive way...

I'd claim that this is still theoretical: what are these strings, and
why do you have lists of them that you want to compare?

Why don't you try to lower-case the strings in the list as you
add them?

Also, are you sure a list is the best data structure for your problem?
Perhaps using a set would be better?

> Should I update the
> __eq__ method (for str class) and break almost everything? Can I write
> now a == b? Nop... I need the loop you've just mentioned in all the
> places where the comparison changes just in the operator, not in the
> algorithm... (I would say this is bad coding practice...)

If you want to compare the same lists in many places, this is indeed
bad coding practice. You should try to centralize whatever reasons
you have for comparing the lists into a few methods of the objects
holding the lists.

Regards,
Martin



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

Re: Learning Python the quick way

[Lie]

On Apr 25, 11:13 am, mercur...@googlemail.com wrote:
> Hi guys,
>
> I have decided to learn Python a little more than I already do. But I
> found few problems,
>
> I am not sure what will happen if I do the programing in python the
> find the program
> doesn't deliver the desired performance due to lack of a good
> compiler.

For most program python is fast enough, given it uses the appropriate
algorithm for the problem (bad algorithm suffers in any language).

For the minority of program where speed is extremely important, there
are tools and libraries to make python runs even faster.

For a swindle of program where it still isn't even enough, writing the
prototype in python will make it easier when rewriting it in other
language.

> So I wanted to learn more about the projects that people are working
> on using Python
> to get the feel of the languages application.

Projects that uses Python? Google and NASA are two big ones. Many
major Linux distributions relies heavily on Python (e.g. Ubuntu). One
of OpenOffice.org's scripting/macro language is Python. Blender 3D
CAD, Scribus, GIMP (with extension), etc uses python for scripting
langauge. There is a major MMORPG game that use python as their
scripting language (forgot the name). Some universities taught python
both as first-language and second language. There are lots of people
that uses python to solve day-to-day problems. On some days, I used
python to solve puzzles and games and stuffs and programming/math
challenges. There are also "success stories" here: 
http://www.python.org/about/success/

In short, python is pretty much everywhere from outerspace to
supercomputers to garage programmer
--
http://mail.python.org/mailman/listinfo/python-list

Re: confused with so many python package locations for imports

[Ben Finney]

Krishnakant  writes:

> So now if I say for example choose ubuntu and debian for my testing
> purpose, should I put all the packages I make into
> /usr/local/lib/python2.6/site-packages? Will this be a safe choice for
> at least debian and Ubuntu?

No, for Debian and/or Ubuntu, you should avoid moving files around
manually and instead use the developer tools available. You should use
the latest ‘debhelper’ for many of the general and specific low-level
tasks needed while building a package, and you should use the latest
‘python-support’ (which works in concert with ‘debhelper’) for a conduit
between your ‘setup.py’ and the Debian packaging system.

For more information, read the Debian Developer's Reference (for general
instructions on making packages for Debian), and the documentation for
the ‘python-support’ package.

-- 
 \   “If [a technology company] has confidence in their future |
  `\  ability to innovate, the importance they place on protecting |
_o__) their past innovations really should decline.” —Gary Barnett |
Ben Finney
--
http://mail.python.org/mailman/listinfo/python-list

Re: confused with so many python package locations for imports

[Krishnakant]

On Sat, 2009-04-25 at 18:31 +1000, Ben Finney wrote:
> Python has a habit of generating, and expecting to find,
> platform-specific files (‘foo.pyo’ extension modules), compiled bytecode
> files (‘foo.pyc’), and module source files (‘foo.py’) necessarily in the
> same directory for purpose of locating them at import time.
> 
Thanks a lot for this information.
So now if I say for example choose ubuntu and debian for my testing
purpose, should I put all the packages I make
into /usr/local/lib/python2.6/site-packages?  Will this be a safe choice
for at least debian and Ubuntu?

I will later on think of fedora etc.

happy hacking.
Krishnakant.
 


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

Re: Lisp mentality vs. Python mentality

[Paul Rubin]

"Ciprian Dorin, Craciun"  writes:
> P.P.S.: I'm just trying to see why is Python better than Lisp or
> vice-versa... I would say they are almost the same: both usable for
> day-to-day real world applications...

Python tries to be simple and pragmatic while not aiming for as
heavy-duty applications as Common Lisp.  Scheme is more of a research
language that's way past its prime.  If you like Scheme, you should
try Haskell.  Python has the motto "practicality beats purity".
With Haskell, it's exactly the opposite ;-).
--
http://mail.python.org/mailman/listinfo/python-list

Re: Lisp mentality vs. Python mentality

[Paul Rubin]

"Ciprian Dorin, Craciun"  writes:
> A practical example: I have lists that contain strings, but I want
> to compare them in an case-insensitive way... Should I update the
> __eq__ method (for str class) and break almost everything? Can I write
> now a == b? Nop... I need the loop you've just mentioned in all the
> places where the comparison changes just in the operator, not in the
> algorithm... (I would say this is bad coding practice...)

In Lisp I think you'd use (equal (mapcar upcase a) (mapcar upcase b))
or something like that.  In Python, a.upper() == b.upper().

Really, Python uses its object system more heavily than old-school
Lisp did, but in other regards (despite the howls of partisans on both
sides) they are really not that different from each other.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Lisp mentality vs. Python mentality

[Paul Rubin]

"Ciprian Dorin, Craciun"  writes:
> > Use the builtin a==b, similar to (equal a b)
> But how about extensibility?

"a==b" is like (equal a b).  "a is b" is like (eq a b).
--
http://mail.python.org/mailman/listinfo/python-list

Re: Lisp mentality vs. Python mentality

[Ciprian Dorin, Craciun]

On Sat, Apr 25, 2009 at 11:36 AM, "Martin v. Löwis"  wrote:
>> I don't get that impression from Lisp programmers.
>
> I observe a phenomenon on language fanatics, no matter what language,
> but in particular for the less-than-mainstream language: the desire
> to formulate trivial algorithms over and over again, just to enjoy the
> beauty of the result (and sometimes the mere fact of being able to do
> so).
>
> I suppose people writing real applications in LISP have better things
> to spend time on.
>
> Regards,
> Martin

Yes, you're right, Lisp people have better things to do, because
these algorithms are already implemented for them: just see ormap and
andmap functions that do just what we wanted...

http://download.plt-scheme.org/doc/html/reference/pairs.html#(def._((quote._~23~25kernel)._ormap))

http://download.plt-scheme.org/doc/html/reference/pairs.html#(def._((lib._scheme/private/map..ss)._andmap))

Ciprian.

P.S.: I'm not a language fanatic... I programmed both in Python
and Scheme (mostly in Python)...

P.P.S.: I'm just trying to see why is Python better than Lisp or
vice-versa... I would say they are almost the same: both usable for
day-to-day real world applications...
--
http://mail.python.org/mailman/listinfo/python-list

Re: Lisp mentality vs. Python mentality

[marek . rocki]

Ciprian Dorin, Craciun napisał(a):
> Python way:
> def compare (a, b, comp = eq) :
>  if len (a) != len (b) :
>   return False
>  for i in xrange (len (a)) :
>   if not comp (a[i], b[i]) :
>return False
>  return True
This is shorter, but I'm not sure if more pythonic:
def compare(a, b, compfunc=eq):
 return all(compfunc(aelem, belem) for aelem, belem in zip_longest
(a, b, fillvalue=object()))

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

Re: Lisp mentality vs. Python mentality

[Ciprian Dorin, Craciun]

On Sat, Apr 25, 2009 at 11:30 AM, "Martin v. Löwis"  wrote:
     Ok... Then what's pythonic? Please give a pythonic implementation...
>>> Use the builtin a==b, similar to (equal a b)
>>
>>     But how about extensibility?
> [...]
>
> I see that you allow for a different comparison function. I do wonder
> what the use case for this is - in what application do you have to
> compare two lists for equality, and the item's __eq__ is inappropriate?
> What would break if you fix the item's __eq__, instead of writing
> your own comparison algorithm?
>
> [...]

A practical example: I have lists that contain strings, but I want
to compare them in an case-insensitive way... Should I update the
__eq__ method (for str class) and break almost everything? Can I write
now a == b? Nop... I need the loop you've just mentioned in all the
places where the comparison changes just in the operator, not in the
algorithm... (I would say this is bad coding practice...)
--
http://mail.python.org/mailman/listinfo/python-list