Re: Lisp mentality vs. Python mentality

[Steven D'Aprano]

On Sun, 26 Apr 2009 08:52:30 +0300, Ciprian Dorin, Craciun 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);

If you look closely, there is no list comprehension. The argument to 
all() is a generator expression, which does not construct an intermediary 
list.

However, you are right that zip produces a list, at least in Python 2.x. 
In Python 3 it produces a generator-like object.



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

No, all() uses short-cut evaluation. It will return as soon as it hits a 
False element.



> So, could you overcome these problems?

In Python 2.4 or better, I can remove the intermediate list produced by 
zip with one line:

from itertools import izip as zip

(This may even work in 2.3, but I don't have 2.3 to test it.)


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

Re: python list handling and Lisp list handling

[Steven D'Aprano]

On Sat, 25 Apr 2009 23:51:18 -0700, namekuseijin wrote:

> On Apr 26, 1:31 am, Steven D'Aprano  cybersource.com.au> 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...

Well, Lisp was invented in 1958, before anyone knew how to program *wink*.

Seriously though, linked lists are not the only sort of list. That was my 
point: first define what is a list, and then we can debate what is or 
isn't a list. Even within linked lists, there are various different 
types, all with their own strengths and weaknesses: singly-linked lists, 
doubly-linked lists, circular lists, open lists, xor-lists, lists with or 
without sentinels, lists with internal and external storage, unrolled 
linked lists, and combinations of all of the above.



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

Re: Minimal binary diff & version control in Python?

[Raymond Hettinger]

[Kevin Ar18]
> Has anyone ever tried to implement some form of version control in Python (if 
> so, where)?

Yes.  Here's the code I use to read and write my old version control
files (originally created with TLIB):

http://code.activestate.com/recipes/576729/

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

Re: Lisp mentality vs. Python mentality

[Paul Rubin]

namekuseijin  writes:
> ... return (len(a) == len(b)) and not any(not comp(a,b) for (a,b)
> in (zip(a, b)))

If I'm reading that correctly, I think I'd write it as:
   
 from itertools import imap, izip
 return (len(a) == len(b)) and all(imap(comp, izip(a, b)))

That is more concise and avoids building an intermediate list with zip.

Maybe we need something like zipWith ...
--
http://mail.python.org/mailman/listinfo/python-list

Re: Lisp mentality vs. Python mentality

[Paul Rubin]

namekuseijin  writes:
>   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.

zip in python 2.x always makes a list.  You want itertools.izip.
You could also use itertools.starmap.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Lisp mentality vs. Python mentality

[Arnaud Delobelle]

namekuseijin  writes:

> 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);

No, it only constructs one list (the zip() one) and only in Python 2.x -
in Python 3.x, zip return a special 'zip object'.  There is no list
comprehension.  It's a generator expression [1].

To avoid the list created by zip in python 2.x (for x large enough!),
just do:

from itertools import izip as zip

Another way to define the function that may appeal to you, as a lisper.

def compare(a, b, comp=operator.eq):
return len(a) == len(b) and all(map(comp, a, b))

The same remark applies to map() here as to zip() above.

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

It does not [2].

> 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.

not any(not i for i in iterable) is not an optimisation of
all(iterable).  Refer to [2].  Moreover, putting a list in parenthesis
does not magically turn it into a generator.

-- 
Arnaud

[1] http://www.python.org/dev/peps/pep-0289/
[2] http://docs.python.org/library/functions.html
--
http://mail.python.org/mailman/listinfo/python-list

Re: Lisp mentality vs. Python mentality

[Arnaud Delobelle]

Paul Rubin  writes:

> namekuseijin  writes:
>> ... return (len(a) == len(b)) and not any(not comp(a,b) for (a,b)
>> in (zip(a, b)))
>
> If I'm reading that correctly, I think I'd write it as:
>
>  from itertools import imap, izip
>  return (len(a) == len(b)) and all(imap(comp, izip(a, b)))

Do you mean imap(comp, a, b)?

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

Re: Minimal binary diff & version control in Python?

[Lawrence D'Oliveiro]

In message , Kevin 
Ar18 wrote:

> I was just wonder about creating something small to handle version control
> on binary files -- maybe something in Python.  :)

Why not just use what's available? For example: 
.

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

Re: Lisp mentality vs. Python mentality

[Martin v. Löwis]

> From your comments I understand that the only problem with my code
> proposal are the function names...

No, the problem is that you are using way too many functions, that do
too little. The problem with that is then that you have to give names
to all the functions, which then find people difficult to read because
they don't just need to the code in question itself; they also need to
dozen of helper functions that it relies on.

> 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. 

Or you could avoid introducing the function altogether, to make it more
readable. This makes it more pythonic, also: readability counts (from
the Zen of Python).

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

Re: Help AIX 5.3 build on Python-3.1a2

[Jeroen Ruigrok van der Werven]

-On [20090425 19:17], Aahz (a...@pythoncraft.com) wrote:
>In article ,
>  wrote:
>>"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.
>
>Can you try trimming down the compilation to a small reproducible case?

I thought it was already clear from what was provided?

Include/token.h has a #define for TILDE and apparently AIX has a #define for
TILDE in /usr/include/sys/ioctl.h as well. So you can a redefinition.

One way around it, depending how AIX protects headers might be to change
Include/token.h to either:

#if defined(_SYS_IOCTL_H_)
#undef TILDE
#define TILDE   32
#endif

or

#if defined(aix)
#undef TILDE
#define TILDE   32
#endif

-- 
Jeroen Ruigrok van der Werven  / asmodai
イェルーン ラウフロック ヴァン デル ウェルヴェン
http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B
A rose is a rose is a rose is a rose...
--
http://mail.python.org/mailman/listinfo/python-list

Re: Lisp mentality vs. Python mentality

[Paul Rubin]

Arnaud Delobelle  writes:
> >  return (len(a) == len(b)) and all(imap(comp, izip(a, b)))
> Do you mean imap(comp, a, b)?

Oh yes, I forgot you can do that.  Thanks.
--
http://mail.python.org/mailman/listinfo/python-list

ANN: PyGUI 2.0.5

[Greg Ewing]

PyGUI 2.0.5 is available:

  http://www.cosc.canterbury.ac.nz/greg.ewing/python_gui/

More bug fixes for various platforms.

Still no idea what's causing the "object has been destroyed"
error on Windows XP, though. Does this happen for everyone?
Is there anyone who *has* got 12-scroll.py working for them
on XP?


What is PyGUI?
--

PyGUI is a cross-platform GUI toolkit designed to be lightweight
and have a highly Pythonic API.

--
Gregory Ewing
greg.ew...@canterbury.ac.nz
http://www.cosc.canterbury.ac.nz/greg.ewing/
--
http://mail.python.org/mailman/listinfo/python-list

Re: Lisp mentality vs. Python mentality

[Ciprian Dorin, Craciun]

On Sun, Apr 26, 2009 at 12:08 PM, "Martin v. Löwis"  wrote:
>>     From your comments I understand that the only problem with my code
>> proposal are the function names...
>
> No, the problem is that you are using way too many functions, that do
> too little. The problem with that is then that you have to give names
> to all the functions, which then find people difficult to read because
> they don't just need to the code in question itself; they also need to
> dozen of helper functions that it relies on.
>
>>     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.
>
> Or you could avoid introducing the function altogether, to make it more
> readable. This makes it more pythonic, also: readability counts (from
> the Zen of Python).
>
> Regards,
> Martin


So if I'm reading right you are saying something in the lines:
"using too many functions is bad just because it is unreadable and
non-understandable to average (could I say mediocre?) programmers"...
Unfortunately I thought that delegating responsibilities to other
functions, and thus writing small chunks of code, is what good
software engineering is... Well my bad...

(As a side-note, maybe this is a reason why some of my students
find it hard to understand functional programming -- too many
functions that is -- I shall have to revise my teaching, and tell the
students to inline everything, maybe they'll understand it like this
:) )

Although you have a point -- that of being hard to comprehend by
average programmers -- but this doesn't mean it is a wrong (as in
ugly) solution... Also, with respects, but the "pythonic" solution
involving generators (or iterators) and "zip" or "all" function --
although I appreciate it as it comes close to FP -- is not what I
would call readable and understandable by non-guru programmers...

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

Re: __import__ function broken in 2.6

[Frank Millman]

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

I did not study your code in detail, so I may have missed something,
but can't you use the 'imp' module for this? That still works in 2.6,
and seems to be present in 3.1 as well.

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

Re: relation class

[Aaron Brady]

On Apr 24, 1:18 am, Aaron Brady  wrote:
> On Apr 22, 11:34 pm, Aaron Brady  wrote:
>
> > On Apr 22, 11:52 am, Aaron Brady  wrote:
>
> > > On Apr 22, 12:09 am, Chris Rebert  wrote:
>
> > > > On Tue, Apr 21, 2009 at 5:51 PM, Aaron Brady  
> > > > wrote:
> > > > > Hi all,
>
> > > > > I think Python should have a relation class in the standard library.
> > > > > Fat chance.
>
> > > > Perhaps I'm not understanding "relation" correctly, but are you not
> > > > aware ofhttp://docs.python.org/library/sqlite3.html?
>
> > > > Cheers,
> > > > Chris
> > > > --
> > > > I have a blog:http://blog.rebertia.com
> > snip
> > > It only supports numbers and strings.
>
> > snip
>
> > My point is that in undirected relations, it's redundant to maintain
> > reciprocal membership.
> snip
> > Here is another sample:
>
> > Tree= Relation( ( "parent", "child", "direction" ) )
> > nodes= [ object( ) for _ in range( 10 ) ]
> > Tree( ( nodes[ 0 ], nodes[ 1 ], "left" ) )
> > Tree( ( nodes[ 0 ], nodes[ 2 ], "right" ) )
> snip
> > 'select' would need the context
> > of its caller, which isn't available.
>
> snip
>
> Or, pass 'locals()'.
snip
>
> > I think some kind of markers would have to replace any identifiers it
> > would use:
>
> > recordset= Tree.select( [ "child" ],
> >     "parent is %var and direction=='left'", nodes[0] )
>
> snip
snip
> class TreeNode:
>     relation= Tree
>     left= Relation.getter(
>         "child", "parent is ? and direction=='left'" )
snip
> It only allows one '?' in the
> definition, since getter functions only take one argument: self!

This isn't true.  The query could have multiple parameter arguments.
Since 'self' isn't defined when calling the property creation
function, the question mark will need a special flag, or an argument
will have to be a sentinel object.

left= Tree.getter(
"child", "parent is ?self and direction==?", "left" )

Or:

left= Tree.getter(
"child", "parent is ? and direction==?", self_mark, "left" )

On doing my homework, I find parameters can be named as well:

left= Tree.getter(
"child", "parent is :self and direction==:dir",
{ 'dir': "left" } )

'self' would be reserved.

snip
> You might want 'getter', 'getiter', and 'getone' methods, which return
> a set of, an iterator over, and just the field of an arbitrary one of
> the matching records respectively.
snip

> > > > I want to return an
> > > > iterator from the following function calls.

It isn't clear that a bare iterator is the proper tool.  Taking
'columns' to be fields, and 'rows' to be records, we have four cases
of the return from a select statement.

- One row, one column.  'getter' and 'setter' can take a single-object
value.  'deller' merely deletes the record.
- One row, multiple columns.  'getter' and 'setter' return and accept
dictionaries which specify the values of the columns in the given
record.  'deller' deletes the record.  It's possible to create nested
properties which correspond to the unspecified fields, but you may
lose identifier fidelity.  Is a dictionary prohibitively inconvenient?
- Multiple rows, one column.  The return from 'SELECT' should have
iterator semantics, as well as set operations.  'getter' returns the
object, but no 'setter' or 'deller' descriptors are meaningful.  The
'add' method on the iterator/set should insert a new record that
fulfills the rest of the statement along with the value added; there
is one degree of freedom in the query.  'discard', 'remove', 'pop',
etc., should all do analogous things.  The methods may have to be
implemented from scratch, due to the fact that they are short-hand for
operations on the relation with larger tuples, as well as
corresponding entries in the hashes and trees.
- Multiple rows, multiple columns.  The return from 'SELECT' should be
an iterator/set.  Arguments to the set operations should be
dictionaries as above.

The 'children' descriptor of the 'Tree' relation corresponds to the
last case:

class TreeNode:
children= Tree.getter(
"child", "parent is ?self" )

A call to 'list( nodeA.children )' would return (simulated,
formatted):
[
  { 'child': nodeB, 'direction': 'left' },
  { 'child': nodeC, 'direction': 'right' }
]

'nodeA.children' would be a non-hashing set, which set's members would
be dictionaries.  The dictionaries would either have to be read-only,
or specialized to pass changes to them on to the structure.  Two
sample operations on the 'children' iterator/sets:

nodeA.children.discard( { 'child': nodeB, 'direction': 'left' } )

To merely discard the left node or the 'nodeB' node would be better
suited to a different property or query ('del nodeA.left').  I don't
expect that the set operations would be used much in the 'multi-
column, multi-row' case; they could be susceptible to abuse, and may
be better omitted.

nodeA.children.clear( )

This removes both children from 'nodeA'.  It may be eliminated from
the relation by now, though the get descriptor 'nodeA.children' will
still

Re: Lisp mentality vs. Python mentality

[Travis]

On Apr 24, 11:06 pm, 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.

I've noticed that every one of you is wrong about programming.
Since I can't say it effectively, here's someone who can:
http://www.youtube.com/watch?v=XHosLhPEN3k

That's the answer.
--
http://mail.python.org/mailman/listinfo/python-list

Re: PyQt4 - widget signal trouble

[Joacim Thomassen]

Den Sat, 25 Apr 2009 23:47:57 +0200, skrev Marco Bizzarri:

> 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


Hello Marco,

python's fcntl() call the regular C fcntl() function and as stated in the 
manual pages for C fcntl:

--- Snippet from fcntl man pages 

File and directory change notification (dnotify)
   F_NOTIFY (long)
  (Linux  2.4 onwards) Provide notification when the 
  directory referred to by fd or any of the files that it 
  contains is changed.  The  events  to  be  notified  are
  specified in arg, which is a bit mask specified by ORing 
  together zero or more of the following bits:

  DN_MODIFY   A file was modified (write, pwrite, writev, 
   truncate, ftruncate).
- End snippet of fcntl man pages ---

The fact that my program actually trigger a signal as the monitored 
directoy's image.jpg file change confirm that this part of the code do 
work. I do get "Change happened!" as i manually do a "cp another.jpg 
image.jpg", but this action is first seen after I close my application 
window. (I do not get "Change happened!" if I don't do my manual cp 
command. :-) )

Personaly I believe this has something to do with the GUI/Qt4 part that I 
have not understood. Something about how a widget repaint itself or 
something in that direction.

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

Get item from set

[Johannes Bauer]

Hi group,

I have a very simple about sets. This is a minimal example:

#!/usr/bin/python
class x():
def __init__(self, y):
self.__y = y
def __eq__(self, other):
return self.__y == other.__y
def __hash__(self):
return hash(self.__y)

a = x("foo")
s = set([x("bar"), x("moo"), a])
z = x("foo")
print("z = ", z)
print(s)
for i in s:
print(i, i == a, i is a, i == z, i is z)

The problem is: two instances of x() are equal (__eq__ returns true),
but they are not identical. I have an equal element ("z"), but want to
get the *actual* element ("a") in the set. I.d. in the above example,
i'd like something like:

print(s.getelement(z) is a)
True

Is there something like the "getelement" function? How can I do what I want?

Kind regards,
Johannes

-- 
"Meine Gegenklage gegen dich lautet dann auf bewusste Verlogenheit,
verlästerung von Gott, Bibel und mir und bewusster Blasphemie."
 -- Prophet und Visionär Hans Joss aka HJP in de.sci.physik
 <48d8bf1d$0$7510$54022...@news.sunrise.ch>
--
http://mail.python.org/mailman/listinfo/python-list

Re: Lisp mentality vs. Python mentality

[bearophileHUGS]

Paul Rubin:
> Arnaud Delobelle:
> > Do you mean imap(comp, a, b)?
>
> Oh yes, I forgot you can do that.  Thanks.

That works and is nice and readable:


import operator
from itertools import imap

def equal_sequences(a, b, comp=operator.eq):
"""
a and b must have __len__

>>> equal_sequences([1, 2, 3], [1, 2, 3])
True
>>> L1, L2 = [1, 2, 3], [1, -2, 3]
>>> equal_sequences(L1, L2)
False
>>> equal_sequences(L1, L2, lambda x,y: abs(x) == abs(y))
True
>>> L3, L4 = ["hello", "HALLO"], ["hello", "hallo"]
>>> equal_sequences(L3, L4)
False
>>> equal_sequences(L3, L4, lambda x,y: x.lower() == y.lower())
True
"""
return len(a) == len(b) and all(imap(comp, a, b))


if __name__ == "__main__":
import doctest
doctest.testmod()
print "Doctests finished.\n"



But both sequences must have a len. Otherwise you may use (if you
don't have izip_longest the folllowing code gets longer):


"""
>>> equal_items([1, 2], [1, 2, 3])
False
>>> equal_items([1, 2, 3], [1, 2, 3])
True
>>> equal_items([1, 2, 3], [1, -2, 3])
False
>>> equal_items([1, 2, 3], [1, -2, 3], abs)
True
>>> equal_items([1, 2, 3], [1, -2, 4], abs)
False
>>> L1, L2 = ["hello", "HALLO"], ["hello", "hallo"]
>>> equal_items(L1, L2)
False
>>> equal_items(L1, L2, str.lower)
True
>>> equal_items(xrange(3), (i for i in xrange(3)))
True
>>> equal_items([0, 1, 2], (i for i in xrange(3)))
True
>>> equal_items([0, 1, 2, 3], (i for i in xrange(3)))
False
>>> equal_items([-0, -1, -2], (i for i in xrange(3)), key=abs)
True
>>> equal_items([-0, -1, -2, -3], (i for i in xrange(3)), key=abs)
False
>>> x = []
>>> equal_items( (x for i in range(3)), (x for i in range(3)) )
True
>>> equal_items( (x for i in range(3)), (x for i in range(4)) )
False
>>> equal_items( (x for i in range(3)), (x for i in range(3)), key=id)
True
>>> equal_items( (x for i in range(3)), (x for i in range(4)), key=id)
False
>>> equal_items( (x for i in range(3)), (x for i in range(3)), key=lambda x:x)
True
>>> equal_items( (x for i in range(3)), (x for i in range(4)), key=lambda x:x)
False
"""

from itertools import izip_longest


def equal_items(iter1, iter2, key=None):
try:
len_iter1 = len(iter1)
len_iter2 = len(iter2)
except TypeError:
pass
else:
if len_iter1 != len_iter2:
return False

class Guard(object): pass

if key is None:
for x, y in izip_longest(iter1, iter2, fillvalue=Guard()):
if x != y:
return False
else:
try:
for x, y in izip_longest(iter1, iter2, fillvalue=Guard()):
if key(x) != key(y):
return False
except TypeError: # intercepts key(guard)
return False

return True


if __name__ == "__main__":
import doctest
doctest.testmod()
print "Doctests finished.\n"

You can write hairy code in Python too, not just in CLisp :-)


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

Re: Lisp mentality vs. Python mentality

[Tim Chase]

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?


The solution would be to use itertools.izip() instead of the 
stock zip().  The all() function short-circuits at the first 
non-True value.  Thus, using izip() instead will (1) not create 
any new lists (it's a generator, not a list) and (2) the all() 
will only look until it fails.


Just make sure that your comp() function returns equality for 
this to work, or otherwise use "not comp()" (which is germane if 
you use a __cmp__ function that returns 0 for equality)


-tkc


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

Re: Lisp mentality vs. Python mentality

[bearophileHUGS]

You can also use quite less code, but this is less efficient:

def equal_items(iter1, iter2, key=lambda x: x):
class Guard(object): pass
try:
for x, y in izip_longest(iter1, iter2, fillvalue=Guard()):
if key(x) != key(y):
return False
except TypeError: # intercepts key(guard)
return False
return True

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

Re: Get item from set

[Peter Otten]

Johannes Bauer wrote:

> I have a very simple about sets. This is a minimal example:

> The problem is: two instances of x() are equal (__eq__ returns true),
> but they are not identical. I have an equal element ("z"), but want to
> get the *actual* element ("a") in the set. I.d. in the above example,
> i'd like something like:
> 
> print(s.getelement(z) is a)
> True
> 
> Is there something like the "getelement" function? How can I do what I
> want?

Here's a trick to find the actual element. I think Raymond Hettinger posted
an implementation of this idea recently, but I can't find it at the moment.

class X:
def __init__(self, y):
self.__y = y
def __eq__(self, other):
try:
return self.__y == other.__y
except AttributeError:
return NotImplemented
def __hash__(self):
return hash(self.__y)

a = X("foo")
s = set([X("bar"), X("moo"), a])
z = X("foo")

class Grab:
def __init__(self, value):
self.search_value = value
def __hash__(self):
return hash(self.search_value)
def __eq__(self, other):
if self.search_value == other:
self.actual_value = other
return True
return False

assert a == z
assert a is not z
grab = Grab(z)
grab in s
assert grab.actual_value is a

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

Re: ANN: PyGUI 2.0.5

[David Robinow]

On Sun, Apr 26, 2009 at 5:21 AM, Greg Ewing  wrote:
> PyGUI 2.0.5 is available:
> Still no idea what's causing the "object has been destroyed"
> error on Windows XP, though. Does this happen for everyone?
> Is there anyone who *has* got 12-scroll.py working for them
> on XP?

Works fine for me. XP Pro Service Pack 3.  Python 2.5.4 and Python
2.6.2 both work.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Lisp mentality vs. Python mentality

[Vsevolod]

On Apr 25, 9: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.

I think you're exaggerating. Go ask this question in c.l.l and the
first answer you'll get is mismatch.
But, from the other point of view your exaggeration makes sense: Lisp
unlike Python, IMO, is the language, where it's pleasant to program
not only applications, but the internals as well. So some people may
find interest in reprogramming what's already there. In lisp
programmer's mentality it's good to know, that you have that ability.

And let's look at my recent experience with Python: I wanted to
implement a daemon process and stumbled at a simplest problem with
threading: neither Thread, nor Threading module provides thread-
killing possibility. Surely, I'm not so experienced in Python as in
Lisp (in which I'd definitely be able to solve this problem by
extending the library), but I don't see an obvious solution, which
will stay inside the language: I have to either use the shell or stick
to the limited set of provided options and skew my program design to
work with them. Any other suggestions?

P.S. Btw the other issue with CL's mismatch is that it provides a
possibility to use any test and keyword extraction function.

Best regards,
Vsevolod Dyomkin
--
http://mail.python.org/mailman/listinfo/python-list

survey: cool but not so well-known python apps

[Alia Khouri]

This mini-survey's purpose is to raise awareness of certain apps that
perhaps don't have the marketing profile/momentum of some of the
better known python apps out there, but are cool and interesting
nonetheless.

To this end, please post 3-5+ apps that you think deserve more
attention:

Here's my list (unordered):

- leo-editor (a literate programming and outlining editor)
http://webpages.charter.net/edreamleo/front.html

- nodebox (the python programmer as artist) http://nodebox.net

- orange (makes datamining/machine learning fun and accessible)
http://www.ailab.si/Orange/

- functional (for the inner functional programmer in you)
http://pypi.python.org/pypi/functional

- ubigraph (dynamic graph visualization) http://ubietylab.net/ubigraph/

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

Re: PyQt4 - widget signal trouble

[Marco Bizzarri]

On Sun, Apr 26, 2009 at 12:38 PM, Joacim Thomassen
 wrote:
> Den Sat, 25 Apr 2009 23:47:57 +0200, skrev Marco Bizzarri:
>
>
> Hello Marco,
>
> python's fcntl() call the regular C fcntl() function and as stated in the
> manual pages for C fcntl:
>
> --- Snippet from fcntl man pages 
>
> File and directory change notification (dnotify)
>       F_NOTIFY (long)
>              (Linux  2.4 onwards) Provide notification when the
>                      directory referred to by fd or any of the files that it
>                      contains is changed.  The  events  to  be  notified  are
>              specified in arg, which is a bit mask specified by ORing
>                      together zero or more of the following bits:
>
>              DN_MODIFY   A file was modified (write, pwrite, writev,
>                                                       truncate, ftruncate).
> - End snippet of fcntl man pages ---
>
> The fact that my program actually trigger a signal as the monitored
> directoy's image.jpg file change confirm that this part of the code do
> work. I do get "Change happened!" as i manually do a "cp another.jpg
> image.jpg", but this action is first seen after I close my application
> window. (I do not get "Change happened!" if I don't do my manual cp
> command. :-) )
>
> Personaly I believe this has something to do with the GUI/Qt4 part that I
> have not understood. Something about how a widget repaint itself or
> something in that direction.
>
> Best regards,
> Joacim
> --
> http://mail.python.org/mailman/listinfo/python-list
>


You're right: I've found the following answer googling:

http://mail.python.org/pipermail/python-list/2007-February/597617.html


indeed, addind a startTimer() to your code, makes it works ;).


Regards
Marco

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

Re: PyQt4 - widget signal trouble

[Phil Thompson]

On Sun, 26 Apr 2009 14:46:14 +0200, Marco Bizzarri
 wrote:
> On Sun, Apr 26, 2009 at 12:38 PM, Joacim Thomassen
>  wrote:
>> Den Sat, 25 Apr 2009 23:47:57 +0200, skrev Marco Bizzarri:
>>
>>
>> Hello Marco,
>>
>> python's fcntl() call the regular C fcntl() function and as stated in
the
>> manual pages for C fcntl:
>>
>> --- Snippet from fcntl man pages 
>>
>> File and directory change notification (dnotify)
>>       F_NOTIFY (long)
>>              (Linux  2.4 onwards) Provide notification when the
>>                      directory referred to by fd or any of
the
>> files that it
>>                      contains is changed.  The  events  to
>>  be  notified  are
>>              specified in arg, which is a bit mask specified by
>> ORing
>>                      together zero or more of the following
>> bits:
>>
>>              DN_MODIFY   A file was modified (write, pwrite,
>> writev,
>>                                                
>>       truncate, ftruncate).
>> - End snippet of fcntl man pages ---
>>
>> The fact that my program actually trigger a signal as the monitored
>> directoy's image.jpg file change confirm that this part of the code do
>> work. I do get "Change happened!" as i manually do a "cp another.jpg
>> image.jpg", but this action is first seen after I close my application
>> window. (I do not get "Change happened!" if I don't do my manual cp
>> command. :-) )
>>
>> Personaly I believe this has something to do with the GUI/Qt4 part that
I
>> have not understood. Something about how a widget repaint itself or
>> something in that direction.
>>
>> Best regards,
>> Joacim
>> --
>> http://mail.python.org/mailman/listinfo/python-list
>>
> 
> 
> You're right: I've found the following answer googling:
> 
> http://mail.python.org/pipermail/python-list/2007-February/597617.html
> 
> 
> indeed, addind a startTimer() to your code, makes it works ;).

Alternatively, use QFileSystemWatcher instead.

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

Re: Lisp mentality vs. Python mentality

[Arnaud Delobelle]

bearophileh...@lycos.com writes:

> You can also use quite less code, but this is less efficient:
>
> def equal_items(iter1, iter2, key=lambda x: x):
> class Guard(object): pass
> try:
> for x, y in izip_longest(iter1, iter2, fillvalue=Guard()):
> if key(x) != key(y):
> return False
> except TypeError: # intercepts key(guard)
> return False
> return True

You don't want to silence TypeErrors that may arise from with key() when
x or y is not a Guard, as it could hide bugs in key(). So I would write
something like this:

def equal_items(iter1, iter2, key=lambda x: x, _fill = object()):
for x, y in izip_longest(iter1, iter2, fillvalue=_fill):
if x is _fill or y is _fill or key(x) != key(y):
return False
return True

(untested)

Another way would be:

def equal_items(iter1, iter2, key=lambda x: x):
iter1, iter2 = iter(iter1), iter(iter2)
for x, y in izip(iter1, iter2):
if key(x) != key(y):
return False
for x, y in izip_longest(iter1, iter2):
return False
return True

(untested)

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

Re: Lisp mentality vs. Python mentality

[Arnaud Delobelle]

Arnaud Delobelle  writes:

> Another way would be:
>
> def equal_items(iter1, iter2, key=lambda x: x):
> iter1, iter2 = iter(iter1), iter(iter2)
> for x, y in izip(iter1, iter2):
> if key(x) != key(y):
> return False
> for x, y in izip_longest(iter1, iter2):
> return False
> return True
>
> (untested)

Or even:

def equal_items(iter1, iter2, key=lambda x: x):
iter1, iter2 = iter(iter1), iter(iter2)
for x, y in izip(iter1, iter2):
if key(x) != key(y):
return False
return not any(izip_longest(iter1, iter2))

(untested)

Or even:

def equal_items(iter1, iter2, key=lambda x: x):
iter1, iter2 = iter(iter1), iter(iter2)
if any(key(x) != key(y) for x, y in izip(iter1, iter2)):
return False
   return not any(izip_longest(iter1, iter2))

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

Re: Get item from set

[bearophileHUGS]

Peter Otten:
> [...] I think Raymond Hettinger posted
> an implementation of this idea recently, but I can't find it at the moment.
> [...]
> class Grab:
>     def __init__(self, value):
>         self.search_value = value
>     def __hash__(self):
>         return hash(self.search_value)
>     def __eq__(self, other):
>         if self.search_value == other:
>             self.actual_value = other
>             return True
>         return False
>
> assert a == z
> assert a is not z
> grab = Grab(z)
> grab in s
> assert grab.actual_value is a

That's very nice, and I may add to my tricks. Probably Raymond has
more brain than me :-)

But some other times you may accept to change the class and the set/
dict, making it tell apart the keys only when they are different
object:

class Some(object):
def __init__(self, y):
self._y = y
def __eq__(self, other):
return self is other
def __hash__(self):
return hash(self._y)

Now your set/dict keeps all the instances, even when they contain the
same _y.

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

Re: Lisp mentality vs. Python mentality

[Peter Otten]

Arnaud Delobelle wrote:

> def equal_items(iter1, iter2, key=lambda x: x):
>     iter1, iter2 = iter(iter1), iter(iter2)
>     for x, y in izip(iter1, iter2):
>         if key(x) != key(y):
>             return False
>     for x, y in izip_longest(iter1, iter2):
>         return False
>     return True
> 
> (untested)

This will fail when iter1 yields one more item than iter2. izip() then
consumes one extra item:

>>> from itertools import izip
>>> a = iter([1,2])
>>> list(izip(a, "b"))
[(1, 'b')]
>>> a.next()
Traceback (most recent call last):
  File "", line 1, in 
StopIteration

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

Re: Lisp mentality vs. Python mentality

[Piet van Oostrum]

> "Ciprian Dorin, Craciun"  (CDC) wrote:

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


>>> a=[1, 2, 3]
>>> b=[1, 2, 4]
>>> compare (a, b, operator.lt)
False
>>> a < b
True

-- 
Piet van Oostrum 
URL: http://pietvanoostrum.com [PGP 8DAE142BE17999C4]
Private email: p...@vanoostrum.org
--
http://mail.python.org/mailman/listinfo/python-list

Re: Lisp mentality vs. Python mentality

[bearophileHUGS]

Arnaud Delobelle:
> You don't want to silence TypeErrors that may arise from with key() when
> x or y is not a Guard, as it could hide bugs in key(). So I would write
> something like this:
>
> def equal_items(iter1, iter2, key=lambda x: x, _fill = object()):
>     for x, y in izip_longest(iter1, iter2, fillvalue=_fill):
>         if x is _fill or y is _fill or key(x) != key(y):
>             return False
>     return True
>
> (untested)

You are right, thank you. Darn exceptions. You are often able to find
bugs in my code.

Here is a new version then (this is designed to be usable in practice,
that's why it's longer):


from itertools import izip_longest

def equal_iter(iter1, iter2, key=None):
"""
>>> equal_iter([1, 2], [1, 2, 3])
False
>>> equal_iter([1, 2, 3], [1, 2, 3])
True
>>> equal_iter([1, 2, 3], [1, -2, 3])
False
>>> equal_iter([1, 2, 3], [1, -2, 3], abs)
True
>>> equal_iter([1, 2, 3], [1, -2, 4], abs)
False
>>> L1, L2 = ["hello", "HALLO"], ["hello", "hallo"]
>>> equal_iter(L1, L2)
False
>>> equal_iter(L1, L2, str.lower)
True
>>> equal_iter(xrange(3), (i for i in xrange(3)))
True
>>> equal_iter([0, 1, 2], (i for i in xrange(3)))
True
>>> equal_iter([0, 1, 2, 3], (i for i in xrange(3)))
False
>>> equal_iter([-0, -1, -2], (i for i in xrange(3)), key=abs)
True
>>> equal_iter([-0, -1, -2, -3], (i for i in xrange(3)), key=abs)
False
>>> x = []
>>> equal_iter( (x for i in range(3)), (x for i in range(3)) )
True
>>> equal_iter( (x for i in range(3)), (x for i in range(4)) )
False
>>> equal_iter( (x for i in range(3)), (x for i in range(3)),
key=id)
True
>>> equal_iter( (x for i in range(3)), (x for i in range(4)),
key=id)
False
>>> equal_iter( (x for i in range(3)), (x for i in range(3)),
key=lambda x:x)
True
>>> equal_iter( (x for i in range(3)), (x for i in range(4)),
key=lambda x:x)
False
>>> # bug found by Arnaud Delobelle
>>> def k(x): raise TypeError
>>> equal_iter( (x for i in range(3)), (x for i in range(3)),
key=k)
Traceback (most recent call last):
  ...
TypeError
"""
try:
len_iter1 = len(iter1)
len_iter2 = len(iter2)
except TypeError:
pass
else:
if len_iter1 != len_iter2:
return False

class Guard(object): pass
guard = Guard()

if key is None:
for x, y in izip_longest(iter1, iter2, fillvalue=guard):
if x != y:
return False
else:
for x, y in izip_longest(iter1, iter2, fillvalue=guard):
if x is guard or y is guard or key(x) != key(y):
return False

return True


if __name__ == "__main__":
import doctest
doctest.testmod()
print "Doctests finished.\n"

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

Re: ANN: PyGUI 2.0.5

[rzed]

Greg Ewing  wrote in 
news:49f4278a.7010...@canterbury.ac.nz:

> PyGUI 2.0.5 is available:
> 
>http://www.cosc.canterbury.ac.nz/greg.ewing/python_gui/
> 
> More bug fixes for various platforms.
> 
> Still no idea what's causing the "object has been destroyed"
> error on Windows XP, though. Does this happen for everyone?
> Is there anyone who *has* got 12-scroll.py working for them
> on XP?

Works for me. I haven't seen an "object has been destroyed" error.

I note that 2.0.5 comments the WM_MOUSELEAVE event, which wasnt' 
mapped in Events.py. Does that mean there is no way to signal such an 
event? Is that a QT or PyQt limitation?

-- 
rzed
Groping nearsightedly through the MiaSma... 
--
http://mail.python.org/mailman/listinfo/python-list

Re: Lisp mentality vs. Python mentality

[Arnaud Delobelle]

Peter Otten <__pete...@web.de> writes:

> Arnaud Delobelle wrote:
>
>> def equal_items(iter1, iter2, key=lambda x: x):
>>     iter1, iter2 = iter(iter1), iter(iter2)
>>     for x, y in izip(iter1, iter2):
>>         if key(x) != key(y):
>>             return False
>>     for x, y in izip_longest(iter1, iter2):
>>         return False
>>     return True
>> 
>> (untested)
>
> This will fail when iter1 yields one more item than iter2. izip() then
> consumes one extra item:

Ah yes! And this is why I should have tested it.

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

Re: confused with so many python package locations for imports

[Scott David Daniels]

Ben Finney wrote:

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.


But the compiled C extension modules are called ".pyd" files and
they are built separately from the execution time and thus do not
suffer the faults of which you complain.

--Scott David Daniels
scott.dani...@acm.org
--
http://mail.python.org/mailman/listinfo/python-list

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

[tinnews]

Lawrence D'Oliveiro  wrote:
> 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?
> 
If you're using IMAP then whether the IMAP server uses maildir or mbox
is (or at least should be) completely invisible to you.  I'm referring
to the situation where my mbox files are in my home directory.

> > It's much easier to search
> 
> Thunderbird seems to search maildir files just fine.
> 
Horrible GUI!  I'm running across an ssh connection, that's how I read
my mail remotely, thunderbird is not much use in that situation.

> > 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.
> 
Locking is nearly irrelevant in a single user situation which is what
I'm talking about.


> > It doesn't have silly ways of delimiting directories as do some
> > maildir implementations.
> 
> What do you mean?
> 
Lots of maildir implementations (Courier and its derivatives in
particular) don't use real directories, they use . delimiters in
filenames, e.g.:-

mbox/holidays/2009/France in a real directory structure

becomes:-

Maildir/holidays.2009.France a very long filename in the Maildir directory

I beleive that sometimes it's:-

Maildir/.holidays.2009.France

Either way the format with dots in it is a real pain to manage if you
want to rename/move things.

-- 
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:
> > 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().  ;)
> 
Yes, but I'm not sure that I'm that competant!


> > 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.
> 
Thanks!

-- 
Chris Green

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

Thread-killing, round 666 (was Re: Lisp mentality vs. Python mentality)

[Aahz]

In article ,
Vsevolod   wrote:
>
>And let's look at my recent experience with Python: I wanted to
>implement a daemon process and stumbled at a simplest problem with
>threading: neither Thread, nor Threading module provides thread-
>killing possibility. Surely, I'm not so experienced in Python as in
>Lisp (in which I'd definitely be able to solve this problem by
>extending the library), but I don't see an obvious solution, which
>will stay inside the language: I have to either use the shell or stick
>to the limited set of provided options and skew my program design to
>work with them. Any other suggestions?

The problem is that thread-killing (in the literal sense) doesn't work.
Unlike processes, there's no thread-environment encapsulation at the OS
level, which means that things don't get cleaned up properly.  Even Java
has mostly given up on thread-killing.  The only way to kill threads
safely is to have them terminate themselves.  Your other option is to use
multiple processes.
-- 
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: Python not importing mysqldb

[Ioannis Lalopoulos]

On Apr 25, 11:45 pm, 83nini <83n...@gmail.com> wrote:
> 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- Hide quoted text -
>
> - Show quoted text -

For Windows distributions of MySQL-python (MySQLdb module) which work
with python 2.6 (32 and 64bit) take a look here: 
http://www.codegood.com/archives/4.
Apart from the normal distributions (client) embedded modules (client-
server) are also available.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Lisp mentality vs. Python mentality

[Scott David Daniels]

Travis wrote:

... I've noticed that every one of you is wrong about programming.
Since I can't say it effectively, here's someone who can:
http://www.youtube.com/watch?v=XHosLhPEN3k

That's the answer.


That is a wonderful link.  Thanks for sharing.

--Scott David Daniels
scott.dani...@acm.org
--
http://mail.python.org/mailman/listinfo/python-list

Re: Lisp mentality vs. Python mentality

[Aaron Brady]

On Apr 26, 10:52 am, Scott David Daniels 
wrote:
> Travis wrote:
> > ... I've noticed that every one of you is wrong about programming.
> > Since I can't say it effectively, here's someone who can:
> >http://www.youtube.com/watch?v=XHosLhPEN3k
>
> > That's the answer.
>
> That is a wonderful link.  Thanks for sharing.
>
> --Scott David Daniels
> scott.dani...@acm.org

import mentality?  help( mentality ).
--
http://mail.python.org/mailman/listinfo/python-list

Re: An unexpected visit_decref assertion fail (code works under python 2.4, doesn't under 2.5)

[Aahz]

In article <71ad1c1d-0b11-4c5c-9e97-e22adf480...@d19g2000prh.googlegroups.com>,
Joe Ardent   wrote:
>
>Does anyone have any tips for debugging this?  I'd really like to know
>what exactly is being decref'd.  This has been driving me crazy for a
>while.  Thanks in advance for any insights or tips!

Try capi-sig
-- 
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: Weird lambda behavior (bad for)

[Aahz]

In article ,
namekuseijin   wrote:
>
>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.

Maybe.  Consider this standard Python idiom:

for x in L:
if x == criterion:
break
doSomething(x)

Obviously, this case could be rewritten fairly easily to hoist
doSomething into the loop before the break, but I've seen other cases
less amenable.
-- 
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

Into itertools

[bearophileHUGS]

Some idioms are so common that I think they deserve to be written in C
into the itertools module.

1) leniter(iterator)

It returns the length of a given iterator, consuming it, without
creating a list. I have discussed this twice in the past.
Like itertools.izip_longest don't use it with infinite iterators.

The following code is faster than
sum(1 for _ in iterator)

A Python implementation:

def leniter(iterator):
if hasattr(iterator, "__len__"):
return len(iterator)
nelements = 0
for _ in iterator:
nelements += 1
return nelements

I use it to count the grup items that groupby() gives:

[(h, leniter(g)) for h,g in groupby(iterable)]

And I use it various other situations, like when I want to test the
speed of a lazy generator:

timeit(leniter, xpairwise(xrange(20)))

(Where "timeit" is a function of mine similar to a Mathematica
function that given a function and some data, applies it and returns
the result and the time taken to perform it).



2) xpairwise(iterable)

This is at the the bottom of the itertools docs:

def pairwise(iterable):
a, b = tee(iterable)
for elem in b:
break
return izip(a, b)


The following of mine is faster:

def xpairwise(iterable):
return izip(iterable, islice(iterable, 1, None))

But a C implementation is better (also avoiding copy&paste from the
bottom of the docs page).

This function can be generalized a lot (I also have written a much
more flexible version), but in practice I have seen this basic version
covers most of the common situations.



3) xpairs(seq)

This is a Python implementation:

def xpairs(seq):
"""xpairs(seq): yields all the distinct pairs of the given seq,
inside a pair
the order doesn't matter. No pairs have the same element twice.
This means it yields just the upper triangular half of the pair
matrix.

>>> list( xpairs([]) )
[]
>>> list(xpairs([1,2]))
[(1, 2)]
>>> list( xpairs("abc") )
[('a', 'b'), ('a', 'c'), ('b', 'c')]
>>> list(xpairs(range(5)))
[(0, 1), (0, 2), (0, 3), (0, 4), (1, 2), (1, 3), (1, 4), (2, 3),
(2, 4), (3, 4)]
"""
len_seq = len(seq)
for i, e1 in enumerate(seq):
for j in xrange(i+1, len_seq):
yield e1, seq[j]


A more general implementation can also be written when seq isn't
randomly-addressable, but I think that may become not efficient.

IHMO xpairs and xpairwise may even deserve an interpreter support, to
speed up them when possible. In a modern compiled language (like
Chapel, http://chapel.cs.washington.edu/ ) such idioms (in theory)
produce no slowdown compared to normal loops. I have written generic
xpairs() and xpairwise() for the D language too, but the compiler
isn't able to fully optimize away such constructs.



4) xsubsets(seq)

This is the recipe at the bottom of the docs page (a bit modified, now
it returns lists because in most situations I don't want the results
to be sets):

def subsets(iterable):
# Recipe credited to Eric Raymond
pairs = [(2 ** i, x) for i, x in enumerate(iterable)]
for n in xrange(2 ** len(pairs)):
yield [x for m, x in pairs if m & n]


After starting to use Python 2.6 I now use the following version (this
replaces a longer version I used in the past):

def xsubsets(seq):
seq = list(seq)
yield []
for nitems in xrange(1, len(seq)+1):
for subset in combinations(seq, nitems):
yield subset


Thanks to the very fast combinations() this xsubsets code is faster
than that recipe by Eric Raymond, but it has the disadvantage that it
doesn't yield subsets in the natural "binary" order. So a C
implementation can be done to respect that natural order.

Such "binary" order has a disadvantage, because the lists/tuples it
yields have a different length, so the C code may have troubles in
using the the nice trick it currently use, re-using the same memory
and avoiding a new memory allocation every loop:

/* Copy the previous result tuple or re-use it if available */
if (Py_REFCNT(result) > 1) {
PyObject *old_result = result;
result = PyTuple_New(r);
if (result == NULL)
goto empty;
co->result = result;
for (i=0; ihttp://mail.python.org/mailman/listinfo/python-list

Re: Lisp mentality vs. Python mentality

[Mikael Jansson]

On Apr 25, 9:36 am, John Yeung  wrote:
>
> 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.
>

Oh, you mean Blub?

http://www.paulgraham.com/avg.html

;-)

--
Mikael Jansson
http://mikael.jansson.be
--
http://mail.python.org/mailman/listinfo/python-list

Re: ANN: PyGUI 2.0.5

[Suraj Barkale]

Greg Ewing  canterbury.ac.nz> writes:
> 
> PyGUI 2.0.5 is available:
> 
>http://www.cosc.canterbury.ac.nz/greg.ewing/python_gui/
> 
> More bug fixes for various platforms.

Tested on "Vista Home Premium 64bit" with Python 2.6.2 all tests pass except:
16-model_dialog.py - If the model dialog "Spanish Inqisition" is closed by
pressing ENTER key, it pops up again. However, clicking buttons works fine.

Minor nitpicks:
1. Menu accelerators are not enabled by default i.e. pressing Alt + F does not
open the File menu.
2. Alt + F4 does not close the window.
3. None of the controls (except menus) have _Vista look_ to them
(http://dl.getdropbox.com/u/14797/no_vista_theme.png).

 
> Still no idea what's causing the "object has been destroyed"
> error on Windows XP, though. Does this happen for everyone?
> Is there anyone who *has* got 12-scroll.py working for them
> on XP?
> 
I have never seen this error either on XP or Vista. 12-scroll.py has always
worked for me.

Regards,
Suraj

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

Re: Into itertools

[AggieDan04]

On Apr 26, 11:32 am, bearophileh...@lycos.com wrote:
> Some idioms are so common that I think they deserve to be written in C
> into the itertools module.
>
> 1) leniter(iterator)
...
> 2) xpairwise(iterable)
...
> 3) xpairs(seq)
...
> 4) xsubsets(seq)
...

Good suggestions.  Another useful function I'd like to see in
itertools is the Cartesian product.  This can be implemented as:

def cartesian_product(*args):
"""Iterates over the Cartesian product of args[0], args[1], ..."""
if not args:
return
elif len(args) == 1:
for item in args[0]:
yield (item,)
else:
for item in args[0]:
for item2 in cartesian_product(*args[1:]):
yield (item,) + item2
--
http://mail.python.org/mailman/listinfo/python-list

Re: PyQt4 - widget signal trouble

[Joacim Thomassen]

Thanks a lot!

That's the magic I didn't find in my PyQT4 Programming book. Finally!

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

Re: Into itertools

[Arnaud Delobelle]

AggieDan04  writes:

> Good suggestions.  Another useful function I'd like to see in
> itertools is the Cartesian product.  This can be implemented as:

[snip implementation]

You mean itertools.product?

http://docs.python.org/library/itertools.html#itertools.product

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

Re: PyQt4 - widget signal trouble

[Joacim Thomassen]

Den Sun, 26 Apr 2009 14:04:47 +0100, skrev Phil Thompson:

> On Sun, 26 Apr 2009 14:46:14 +0200, Marco Bizzarri
>  wrote:
>> On Sun, Apr 26, 2009 at 12:38 PM, Joacim Thomassen
>>  wrote:
>>> Den Sat, 25 Apr 2009 23:47:57 +0200, skrev Marco Bizzarri:
>>>
>>>
>>> Hello Marco,
>>>
>>> python's fcntl() call the regular C fcntl() function and as stated in
> the
>>> manual pages for C fcntl:
>>>
>>> --- Snippet from fcntl man pages 
>>>
>>> File and directory change notification (dnotify)
>>>       F_NOTIFY (long)
>>>              (Linux  2.4 onwards) Provide notification when the
>>>                      directory referred to by fd or any of
> the
>>> files that it
>>>                      contains is changed.  The  events  to
>>>  be  notified  are
>>>              specified in arg, which is a bit mask specified by
>>> ORing
>>>                      together zero or more of the following
>>> bits:
>>>
>>>              DN_MODIFY   A file was modified (write, pwrite,
>>> writev,
>>>                                                
>>>       truncate, ftruncate).
>>> - End snippet of fcntl man pages ---
>>>
>>> The fact that my program actually trigger a signal as the monitored
>>> directoy's image.jpg file change confirm that this part of the code do
>>> work. I do get "Change happened!" as i manually do a "cp another.jpg
>>> image.jpg", but this action is first seen after I close my application
>>> window. (I do not get "Change happened!" if I don't do my manual cp
>>> command. :-) )
>>>
>>> Personaly I believe this has something to do with the GUI/Qt4 part
>>> that
> I
>>> have not understood. Something about how a widget repaint itself or
>>> something in that direction.
>>>
>>> Best regards,
>>> Joacim
>>> --
>>> http://mail.python.org/mailman/listinfo/python-list
>>>
>>>
>> 
>> You're right: I've found the following answer googling:
>> 
>> http://mail.python.org/pipermail/python-list/2007-February/597617.html
>> 
>> 
>> indeed, addind a startTimer() to your code, makes it works ;).
> 
> Alternatively, use QFileSystemWatcher instead.
> 
> Phil

Thanks Phil,

I'll have a look at the QFileSystemWatcher later for a more sound code.

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

Re: pyflakes, pylint, pychecker - and other tools

[Zooko O'Whielacronx]

I like pyflakes.  I haven't tried the others.  I made a setuptools  
plugin named "setuptools_pyflakes".  If you install that package,  
then "python ./setup.py flakes" runs pyflakes on your package.


Regards,

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

Re: Lisp mentality vs. Python mentality

[Martin v. Löwis]

> So if I'm reading right you are saying something in the lines:
> "using too many functions is bad just because it is unreadable and
> non-understandable to average (could I say mediocre?) programmers"...

No, this style is also unreadable to advanced programmers, in
particular when you fail to include the functions you use, and
leave the reader with guesswork.

> Unfortunately I thought that delegating responsibilities to other
> functions, and thus writing small chunks of code, is what good
> software engineering is... Well my bad...

You misunderstood indeed. Splitting a large algorithm into smaller
parts is good if the original algorithm cannot be easily understood
in a single piece. By splitting it, you introduce new abstractions
that can help to simplify the original algorithm. OTOH, adding
these abstractions also requires the reader to familiarize himself
with the abstractions. There is a tradeoff, and the optimum is
somewhere in the middle.

Splitting code into tiny functions certainly is *not* good software
engineering.

> Although you have a point -- that of being hard to comprehend by
> average programmers -- but this doesn't mean it is a wrong (as in
> ugly) solution... Also, with respects, but the "pythonic" solution
> involving generators (or iterators) and "zip" or "all" function --
> although I appreciate it as it comes close to FP -- is not what I
> would call readable and understandable by non-guru programmers...

Please go back to my formulation - it doesn't use any of this, and
I agree that the formulations with zip, generators, etc are indeed
more difficult to read (perhaps *precisely* because they come
closer to FP).

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

Re: Lisp mentality vs. Python mentality

[namekuseijin]

Paul Rubin wrote:

namekuseijin  writes:

  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.


zip in python 2.x always makes a list.  You want itertools.izip.
You could also use itertools.starmap.


hmm, somehow I thought putting any sequence into parenthesis would 
always yield a generator...

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

Re: Lisp mentality vs. Python mentality

[Scott David Daniels]

Ciprian Dorin, Craciun wrote:

On Sun, Apr 26, 2009 at 12:08 PM, "Martin v. Löwis"  wrote:

From your comments I understand that the only problem with my code
proposal are the function names...

No, the problem is that you are using way too many functions, that do
too little. The problem with that is then that you have to give names
to all the functions, which then find people difficult to read because
they don't just need to the code in question itself; they also need to
dozen of helper functions that it relies on.

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.

Or you could avoid introducing the function altogether, to make it more
readable. This makes it more pythonic, also: readability counts (from
the Zen of Python).


So if I'm reading right you are saying something in the lines:
"using too many functions is bad just because it is unreadable and
non-understandable to average (could I say mediocre?) programmers"...
Unfortunately I thought that delegating responsibilities to other
functions, and thus writing small chunks of code, is what good
software engineering is... Well my bad...
(As a side-note, maybe this is a reason why some of my students
find it hard to understand functional programming -- too many
functions that is -- I shall have to revise my teaching, and tell the
students to inline everything, maybe they'll understand it like this
:) )
Although you have a point -- that of being hard to comprehend by
average programmers -- but this doesn't mean it is a wrong (as in
ugly) solution... Also, with respects, but the "pythonic" solution
involving generators (or iterators) and "zip" or "all" function --
although I appreciate it as it comes close to FP -- is not what I
would call readable and understandable by non-guru programmers...


Writing software is writing for a reader: the maintainer or extender
of the code you are writing.  That that person may be you in three
years is incidental.  You should struggle to write clearly, and take
any clues you can get about how to make the code clearer.  This doesn't
mean you must explain the language; you may assume the reader knows
(or can quickly find in manuals) what any particular language feature
means.  What you must explain is how you are solving the problem at
every point in the code where the code itself does not make that clear.

I don't remember who, but something famously said, in effect:
Debugging is hard, maybe twice as hard as writing the code in
the first place.  Unless you are one of those nonexistent few
who always write correct programs from the word go, you will
have to debug your own code before it works fully correctly.
Therefore, you had better write code so simple that you can
know what is going wrong with it.  If your code is too hard
to understand for the average programmer, you are either four
times as brilliant as those "average" programmers or you are
in big trouble.

--Scott David Daniels
scott.dani...@acm.org
--
http://mail.python.org/mailman/listinfo/python-list

Re: Lisp mentality vs. Python mentality

[namekuseijin]

Travis wrote:

I've noticed that every one of you is wrong about programming.
Since I can't say it effectively, here's someone who can:
http://www.youtube.com/watch?v=XHosLhPEN3k

That's the answer.


Hmm, perhaps it was the answer by the time that song was written? ;)

cool anyway... :)
--
http://mail.python.org/mailman/listinfo/python-list

Re: Thread-killing, round 666 (was Re: Lisp mentality vs. Python mentality)

[Vsevolod]

On Apr 26, 6:28 pm, a...@pythoncraft.com (Aahz) wrote:
> The problem is that thread-killing (in the literal sense) doesn't work.
> Unlike processes, there's no thread-environment encapsulation at the OS
> level, which means that things don't get cleaned up properly.  Even Java
> has mostly given up on thread-killing.  The only way to kill threads
> safely is to have them terminate themselves.  Your other option is to use
> multiple processes.
Well, somehow, in Lisp it's not a problem. :)

Cheers,
Vsevolod
--
http://mail.python.org/mailman/listinfo/python-list

Re: Lisp mentality vs. Python mentality

[Aahz]

In article ,
Scott David Daniels   wrote:
>
>I don't remember who, but something famously said, in effect:
> Debugging is hard, maybe twice as hard as writing the code in
> the first place.  Unless you are one of those nonexistent few
> who always write correct programs from the word go, you will
> have to debug your own code before it works fully correctly.
> Therefore, you had better write code so simple that you can
> know what is going wrong with it.  If your code is too hard
> to understand for the average programmer, you are either four
> times as brilliant as those "average" programmers or you are
> in big trouble.

Fom my .sig database:

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are, by
definition, not smart enough to debug it."  --Brian W. Kernighan
-- 
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

How to import modules from specific Python installation?

[kk]

Hi

I know there is a way to import from different Python installation but
I could not find the answer.  I have Python 2.6 and 2.5


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

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

[John Posner]

jazbees wrote:

> 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.

I agree with Duncan Booth that any() is equivalent to -- and better than 
-- max() for handling boolean values. But what boolean-oriented function 
is equivalent to min()? How about this, which returns the negation of 
the min() result:


def at_least_one_false(value_list):
  """
  return True if at least one value in value_list is logically FALSE
  """
  return any( [not val for val in value_list] )

This works, but the short-circuit feature of any() is undermined by the 
process-the-whole-sequence behavior of the list comprehension. So, let's 
delete the square brackets, converting the list comprehension into a 
generator expression:


  return any( not val for val in value_list )

According to timeit.Timer.timeit(), this change improves performance 
from 14.59 seconds to 10.49 seconds, with a long value_list:


  [True]*20 + [False] + [True]*30

But the generator expression produces worse performance with a shorter 
value_list:


  [True]*2 + [False] + [True]*3


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

question about class vs class at

[grocery_stocker]

When I do pexpect.spawn in the following example, I see 

[cdal...@localhost oakland]$ python
Python 2.4.3 (#1, Oct  1 2006, 18:00:19)
[GCC 4.1.1 20060928 (Red Hat 4.1.1-28)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import pexpect
>>> pexpect.spawn

>>>

But now, when I do telnetlib.Telnet, I see 
>>> import telnetlib
>>> telnetlib.Telnet

>>>

Why do I see  for
telnetlib.Telnet, but I don't see the same for  ? Ie, how come I don't see   ?
--
http://mail.python.org/mailman/listinfo/python-list

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

[Arnaud Delobelle]

John Posner  writes:

> jazbees wrote:
>
>> 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.
>
> I agree with Duncan Booth that any() is equivalent to -- and better
> than -- max() for handling boolean values. But what boolean-oriented
> function is equivalent to min()? How about this, which returns the
> negation of the min() result:
>
> def at_least_one_false(value_list):
>   """
>   return True if at least one value in value_list is logically FALSE
>   """
>   return any( [not val for val in value_list] )
>
> This works, but the short-circuit feature of any() is undermined by
> the process-the-whole-sequence behavior of the list comprehension. So,
> let's delete the square brackets, converting the list comprehension
> into a generator expression:
>
>   return any( not val for val in value_list )

This is the same as:

return not all(value_list)

> According to timeit.Timer.timeit(), this change improves performance
> from 14.59 seconds to 10.49 seconds, with a long value_list:
>
>   [True]*20 + [False] + [True]*30
>
> But the generator expression produces worse performance with a shorter
> value_list:
>
>   [True]*2 + [False] + [True]*3

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

Re: question about class vs class at

[Arnaud Delobelle]

grocery_stocker  writes:

> When I do pexpect.spawn in the following example, I see  'pexpect.spawn'>
>
> [cdal...@localhost oakland]$ python
> Python 2.4.3 (#1, Oct  1 2006, 18:00:19)
> [GCC 4.1.1 20060928 (Red Hat 4.1.1-28)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
 import pexpect
 pexpect.spawn
> 

>
> But now, when I do telnetlib.Telnet, I see  0xb7eded1c>
 import telnetlib
 telnetlib.Telnet
> 

>
> Why do I see  for
> telnetlib.Telnet, but I don't see the same for   'pexpect.spawn'>? Ie, how come I don't see   0xb7eded1c> ?

Because pexpect.spawn is a new-style class whereas telnetlib.Telnet is
an old-style class?

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

Re: writing large dictionaries to file using cPickle

[repi]

Hello,

I'm having the same problem. I'm creating two dictionaries with about
700,000 to 1,600,000 keys each, each key pointing to a smaller structure of
embedded dictionaries. On a 8 x 3.0GHz Xeon Mac Pro with 17GB of RAM,
cPickle is excruciatingly slow. Moreover, it crashes with memory error (12).
I've been looking for alternatives, even thinking of writing up my own file
format and read/write functions. As a last resort I tried dumping the two
lists with the marshal module and it worked great. A 200MB and a 300MB file
are created in a couple of seconds without a crash. 

You should be warned that marshal is not meant as a general data-persistence
module. But as long as you have a rather simple data structure and you are
using it with a specific python version, it seems to run circles around
cPickle.

Hope it helps.

-- 
View this message in context: 
http://www.nabble.com/writing-large-dictionaries-to-file-using-cPickle-tp21708938p23246693.html
Sent from the Python - python-list mailing list archive at Nabble.com.

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

Re: Lisp mentality vs. Python mentality

[Carl Banks]

On Apr 26, 5:40 am, Vsevolod  wrote:
> On Apr 25, 9:06 am, Carl Banks  wrote:
> > Carl Banks, who might be exaggerating
>
> > ...a little.
>
> I think you're exaggerating. Go ask this question in c.l.l and the
> first answer you'll get is mismatch.

What could have made you think I was exaggerating.  Could it be the
line where I said "Carl, Banks who mighe exaggerating"?? :)


> But, from the other point of view your exaggeration makes sense: Lisp
> unlike Python, IMO, is the language, where it's pleasant to program
> not only applications, but the internals as well. So some people may
> find interest in reprogramming what's already there. In lisp
> programmer's mentality it's good to know, that you have that ability.

And yet, the impression I get from Lisp programmers is that they
prefer to program internals.  They will say it's an advantage of Lisp
that their list type is handled with low-level primitives like car,
cdr, and cons, rather than high-level operations like indexing,
appending, etc.  Why would that be an advantage unless they are doing
that kind of stuff all the time?


> And let's look at my recent experience with Python: I wanted to
> implement a daemon process and stumbled at a simplest problem with
> threading: neither Thread, nor Threading module provides thread-
> killing possibility. Surely, I'm not so experienced in Python as in
> Lisp (in which I'd definitely be able to solve this problem by
> extending the library), but I don't see an obvious solution, which
> will stay inside the language: I have to either use the shell or stick
> to the limited set of provided options and skew my program design to
> work with them. Any other suggestions?

Say you are running a thread and you want the power to be able to kill
it at any time.  The thread is either communicating with the rest of
the program periodically, or it isn't.  If it is, then there are ample
opportunities to tell the thread to terminate itself.  If it isn't,
then you might as well use a separate process which you can kill.
Next question.


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

Re: question about class vs class at

[grocery_stocker]

On Apr 26, 2:07 pm, Arnaud Delobelle  wrote:
> grocery_stocker  writes:
> > When I do pexpect.spawn in the following example, I see  > 'pexpect.spawn'>
>
> > [cdal...@localhost oakland]$ python
> > Python 2.4.3 (#1, Oct  1 2006, 18:00:19)
> > [GCC 4.1.1 20060928 (Red Hat 4.1.1-28)] on linux2
> > Type "help", "copyright", "credits" or "license" for more information.
>  import pexpect
>  pexpect.spawn
> > 
>
> > But now, when I do telnetlib.Telnet, I see  > 0xb7eded1c>
>  import telnetlib
>  telnetlib.Telnet
> > 
>
> > Why do I see  for
> > telnetlib.Telnet, but I don't see the same for   > 'pexpect.spawn'>? Ie, how come I don't see   > 0xb7eded1c> ?
>
> Because pexpect.spawn is a new-style class whereas telnetlib.Telnet is
> an old-style class?
>

Maybe. I guess I haven't been around python long enough to realize
that there was a difference in 'output' between the old-style class
and new-style class.

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

Re: Lisp mentality vs. Python mentality

[Paul Rubin]

Carl Banks  writes:
> Say you are running a thread and you want the power to be able to kill
> it at any time.  The thread is either communicating with the rest of
> the program periodically, or it isn't.  If it is, then there are ample
> opportunities to tell the thread to terminate itself.  If it isn't,
> then you might as well use a separate process which you can kill.

That's not so satisfying.  If you use a separate process, it can't
share Python objects with the main process, isn't under the same
memory management, etc.  With the standard modules that comes with
Python, you can't share memory at all (except with mmap, which gives
no synchronization mechanisms).  You can't pass open sockets from one
process to another with the standard library, making it harder to
implement typical multi-threaded servers.  You do get better
scalability, but at the expense of having to serialize all IPC data
and use heavyweight communication mechanisms.  Threads exist because
they are useful.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Lisp mentality vs. Python mentality

[Scott David Daniels]

Paul Rubin wrote:

Carl Banks  writes:

Say you are running a thread and you want the power to be able to kill
it at any time.  The thread is either communicating with the rest of
the program periodically, or it isn't.  If it is, then there are ample
opportunities to tell the thread to terminate itself.  If it isn't,
then you might as well use a separate process which you can kill.


That's not so satisfying.  If you use a separate process, it can't
share Python objects with the main process, isn't under the same
memory management, etc.

But precisely because of that sharing the thread may be in the middle
something that "must complete" -- no with-statement locking will get
unlocked, no "finally:" clauses in code in the standard library, no
... -- there is just too much that goes wrong when a thread is
infinitely starved (which, in effect, is what would happen if you
could kill it).

--Scott David Daniels
scott.dani...@acm.org
--
http://mail.python.org/mailman/listinfo/python-list

Re: Lisp mentality vs. Python mentality

[Paul Rubin]

Scott David Daniels  writes:
> But precisely because of that sharing the thread may be in the middle
> something that "must complete" -- no with-statement locking will get
> unlocked, no "finally:" clauses in code in the standard library, no
> ... -- there is just too much that goes wrong when a thread is
> infinitely starved (which, in effect, is what would happen if you
> could kill it).

Right, it's better to recognize this sort of problem than to brush it
off.  There was a discussion in sourceforge a long time ago about
adding a way to raise exceptions in threads, and I think there is some
way to do it through the C API.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Lisp mentality vs. Python mentality

[Paul Rubin]

Carl Banks  writes:
> Which is "communicating with the rest of the program periodically".
> 
> Presumably you have to protect objects to share them?  There you go:
> anytime you try to acquire a lock have the thread check to see whether
> to abort.

Normally, acquiring a lock doesn't require running code in other
threads, at least in the uncontended case.  If you have to switch
threads twice in order to acquire a lock, your implementation could
use some improvement.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Lisp mentality vs. Python mentality

[Carl Banks]

On Apr 26, 2:38 pm, Paul Rubin  wrote:
> Carl Banks  writes:
> > Say you are running a thread and you want the power to be able to kill
> > it at any time.  The thread is either communicating with the rest of
> > the program periodically, or it isn't.  If it is, then there are ample
> > opportunities to tell the thread to terminate itself.  If it isn't,
> > then you might as well use a separate process which you can kill.
>
> That's not so satisfying.  If you use a separate process, it can't
> share Python objects with the main process,

Which is "communicating with the rest of the program periodically".

Presumably you have to protect objects to share them?  There you go:
anytime you try to acquire a lock have the thread check to see whether
to abort.


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

Re: python list handling and Lisp list handling

[J Kenneth King]

Steven D'Aprano  writes:

> On Sat, 25 Apr 2009 23:51:18 -0700, namekuseijin wrote:
>
>> On Apr 26, 1:31 am, Steven D'Aprano > cybersource.com.au> 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...
>
> Well, Lisp was invented in 1958, before anyone knew how to program *wink*.

And 50+ years of development hasn't taught them anything. :p

Guess you don't know anything about programming unless you're new...

> Seriously though, linked lists are not the only sort of list. That was my 
> point: first define what is a list, and then we can debate what is or 
> isn't a list. Even within linked lists, there are various different 
> types, all with their own strengths and weaknesses: singly-linked lists, 
> doubly-linked lists, circular lists, open lists, xor-lists, lists with or 
> without sentinels, lists with internal and external storage, unrolled 
> linked lists, and combinations of all of the above.

And any sufficiently powerful language would allow the programmer to
adapt to any type they needed. ;)

Interesting topic though.
--
http://mail.python.org/mailman/listinfo/python-list

Re: How to import modules from specific Python installation?

[Dave Angel]

kk wrote:

Hi

I know there is a way to import from different Python installation but
I could not find the answer.  I have Python 2.6 and 2.5


thanks

  
There's always the question of whether it's a good idea.  My opinion is 
that if you want to use python source files from another version, you 
should *copy* them into your present version's syspath, and import them 
as a 3rd party site-package.  So it's a question of putting it in the 
site-packages directory and adding a __init__.py file.


Alternatively, you can modify the sys.path, import it, then restore the 
sys.path.  With that hack, you can do anything.



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

Re: confused with so many python package locations for imports

[Ben Finney]

Scott David Daniels  writes:

> Ben Finney wrote:
> > Thank you for the correction. Please mentally substitute into my
> > argument the files that *are* compiled C extension modules; it
> > remains otherwise unchanged.
> 
> But the compiled C extension modules are called ".pyd" files and
> they are built separately from the execution time and thus do not
> suffer the faults of which you complain.

I didn't discuss build versus execution time at all.

My point was, for those who are still distracted: Whatever they're
named, whenever they're built, the architecture-dependent executable
module files are by default located and searched for in the same place
as architecture-independent executable module files. That is a mismatch
between Python and the FHS.

One which is being actively addressed, if I understand some enthusiastic
reports from PyCon 2009 correctly; but nevertheless, one which impacts
the ideal the original poster is hoping for.

-- 
 \“I saw a sign: ‘Rest Area 25 Miles’. That's pretty big. Some |
  `\  people must be really tired.” —Steven Wright |
_o__)  |
Ben Finney
--
http://mail.python.org/mailman/listinfo/python-list

Re: Lisp mentality vs. Python mentality

[Dan Sommers]

On Sun, 26 Apr 2009 12:30:40 +0300, Ciprian Dorin, Craciun wrote:

> On Sun, Apr 26, 2009 at 12:08 PM, "Martin v. Löwis" 
> wrote:

>> No, the problem is that you are using way too many functions, that do
>> too little. The problem with that is then that you have to give names
>> to all the functions, which then find people difficult to read because
>> they don't just need to the code in question itself; they also need to
>> dozen of helper functions that it relies on.

>> Or you could avoid introducing the function altogether, to make it more
>> readable. This makes it more pythonic, also: readability counts (from
>> the Zen of Python).

> So if I'm reading right you are saying something in the lines:
> "using too many functions is bad just because it is unreadable and
> non-understandable to average (could I say mediocre?) programmers"...
> Unfortunately I thought that delegating responsibilities to other
> functions, and thus writing small chunks of code, is what good software
> engineering is... Well my bad...

Also from the Zen:  flat is better than nested.  One of the aspects of 
flatter call trees and object hierarchies is that I hit the bottom 
(language features or the standard library) sooner, and I "should" 
already have the language and its standard library in my brain.  That 
said, I also tend to break my programs into layers, but I do try to make 
each layer as thin as possible (but no thinner).

> Although you have a point -- that of being hard to comprehend by
> average programmers -- but this doesn't mean it is a wrong (as in ugly)
> solution... Also, with respects, but the "pythonic" solution involving
> generators (or iterators) and "zip" or "all" function -- although I
> appreciate it as it comes close to FP -- is not what I would call
> readable and understandable by non-guru programmers...

I finally got it through my thick head that I've been *doing* functional 
programming with [*nix] shells and pipes for years, well back into my non-
guru days.

Dan

-- 
Dan Sommers   A death spiral goes clock-
   wise north of the equator.
Atoms are not things. -- Werner Heisenberg  -- Dilbert's PHB

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

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

[John Posner]

Arnaud Delobelle wrote:

  return any( not val for val in value_list )



This is the same as:

return not all(value_list)

  

Yes, I should have remembered De Morgan's Theorem. Thanks!

-John

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

Re: Lisp mentality vs. Python mentality

[Steven D'Aprano]

On Sun, 26 Apr 2009 05:07:25 -0700, bearophileHUGS wrote:

> Paul Rubin:
>> Arnaud Delobelle:
>> > Do you mean imap(comp, a, b)?
>>
>> Oh yes, I forgot you can do that.  Thanks.
> 
> That works and is nice and readable:
> 
> 
> import operator
> from itertools import imap
> 
> def equal_sequences(a, b, comp=operator.eq):
[snip]

Sorry, this is worse than unreadable. It is *misleading*. It doesn't test 
for equal sequences except as a special case. What it does is perform a 
generic element-by-element comparison, not necessarily an equality test.

What was wrong with the name compare() used in previous posts in this 
thread?



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

Re: How to import modules from specific Python installation?

[David Lyon]

On Sun, 26 Apr 2009 13:07:24 -0700 (PDT), kk  wrote:
> I know there is a way to import from different Python installation but
> I could not find the answer.  I have Python 2.6 and 2.5

You can probably achieve this by adjusting the pythonpath to
search through the site-packages directory of the other installation.

David

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

Re: Thread-killing, round 666 (was Re: Lisp mentality vs. Python mentality)

[Aahz]

In article <793a5176-ec2d-4ffd-b1e7-762077733...@v35g2000pro.googlegroups.com>,
Vsevolod   wrote:
>On Apr 26, 6:28 pm, a...@pythoncraft.com (Aahz) wrote:
>>
>> The problem is that thread-killing (in the literal sense) doesn't work.
>> Unlike processes, there's no thread-environment encapsulation at the OS
>> level, which means that things don't get cleaned up properly.  Even Java
>> has mostly given up on thread-killing.  The only way to kill threads
>> safely is to have them terminate themselves.  Your other option is to use
>> multiple processes.
>
>Well, somehow, in Lisp it's not a problem. :)

Does Lisp even have OS-level threads?  What Lisp are you using, on what
OS?  Are they perhaps Erlang-style cooperative threads instead?
-- 
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: [Python-Dev] PEP 383: Non-decodable Bytes in System Character Interfaces

[Adrian]

How about another str-like type, a sequence of char-or-bytes? Could be
called strbytes or stringwithinvalidcharacters. It would support
whatever subset of str functionality makes sense / is easy to
implement plus a to_escaped_str() method (that does the escaping the
PEP talks about) for people who want to use regexes or other str-only
stuff.

Here is a description by example:
os.listdir('.') -> [strbytes('normal_file'), strbytes('bad', 128, 'file')]
strbytes('a')[0] -> strbytes('a')
strbytes('bad', 128, 'file')[3] -> strbytes(128)
strbytes('bad', 128, 'file').to_escaped_str() -> 'bad?128file'

Having a separate type is cleaner than a "str that isn't exactly what
it represents". And making the escaping an explicit (but
rarely-needed) step would be less surprising for users. Anyway, I
don't know a whole lot about this issue so there may an obvious reason
this is a bad idea.

On Wed, Apr 22, 2009 at 6:50 AM, "Martin v. Löwis"  wrote:
> I'm proposing the following PEP for inclusion into Python 3.1.
> Please comment.
>
> Regards,
> Martin
>
> PEP: 383
> Title: Non-decodable Bytes in System Character Interfaces
> Version: $Revision: 71793 $
> Last-Modified: $Date: 2009-04-22 08:42:06 +0200 (Mi, 22. Apr 2009) $
> Author: Martin v. Löwis 
> Status: Draft
> Type: Standards Track
> Content-Type: text/x-rst
> Created: 22-Apr-2009
> Python-Version: 3.1
> Post-History:
>
> Abstract
> 
>
> File names, environment variables, and command line arguments are
> defined as being character data in POSIX; the C APIs however allow
> passing arbitrary bytes - whether these conform to a certain encoding
> or not. This PEP proposes a means of dealing with such irregularities
> by embedding the bytes in character strings in such a way that allows
> recreation of the original byte string.
>
> Rationale
> =
>
> The C char type is a data type that is commonly used to represent both
> character data and bytes. Certain POSIX interfaces are specified and
> widely understood as operating on character data, however, the system
> call interfaces make no assumption on the encoding of these data, and
> pass them on as-is. With Python 3, character strings use a
> Unicode-based internal representation, making it difficult to ignore
> the encoding of byte strings in the same way that the C interfaces can
> ignore the encoding.
>
> On the other hand, Microsoft Windows NT has correct the original
> design limitation of Unix, and made it explicit in its system
> interfaces that these data (file names, environment variables, command
> line arguments) are indeed character data, by providing a
> Unicode-based API (keeping a C-char-based one for backwards
> compatibility).
>
> For Python 3, one proposed solution is to provide two sets of APIs: a
> byte-oriented one, and a character-oriented one, where the
> character-oriented one would be limited to not being able to represent
> all data accurately. Unfortunately, for Windows, the situation would
> be exactly the opposite: the byte-oriented interface cannot represent
> all data; only the character-oriented API can. As a consequence,
> libraries and applications that want to support all user data in a
> cross-platform manner have to accept mish-mash of bytes and characters
> exactly in the way that caused endless troubles for Python 2.x.
>
> With this PEP, a uniform treatment of these data as characters becomes
> possible. The uniformity is achieved by using specific encoding
> algorithms, meaning that the data can be converted back to bytes on
> POSIX systems only if the same encoding is used.
>
> Specification
> =
>
> On Windows, Python uses the wide character APIs to access
> character-oriented APIs, allowing direct conversion of the
> environmental data to Python str objects.
>
> On POSIX systems, Python currently applies the locale's encoding to
> convert the byte data to Unicode. If the locale's encoding is UTF-8,
> it can represent the full set of Unicode characters, otherwise, only a
> subset is representable. In the latter case, using private-use
> characters to represent these bytes would be an option. For UTF-8,
> doing so would create an ambiguity, as the private-use characters may
> regularly occur in the input also.
>
> To convert non-decodable bytes, a new error handler "python-escape" is
> introduced, which decodes non-decodable bytes using into a private-use
> character U+F01xx, which is believed to not conflict with private-use
> characters that currently exist in Python codecs.
>
> The error handler interface is extended to allow the encode error
> handler to return byte strings immediately, in addition to returning
> Unicode strings which then get encoded again.
>
> If the locale's encoding is UTF-8, the file system encoding is set to
> a new encoding "utf-8b". The UTF-8b codec decodes non-decodable bytes
> (which must be >= 0x80) into half surrogate codes U+DC80..U+DCFF.
>
> Discussion
> ==
>
> While providing a uniform API to non-decodable bytes, 

Re: Lisp mentality vs. Python mentality

[Carl Banks]

On Apr 26, 3:03 pm, Paul Rubin  wrote:
> Carl Banks  writes:
> > Which is "communicating with the rest of the program periodically".
>
> > Presumably you have to protect objects to share them?  There you go:
> > anytime you try to acquire a lock have the thread check to see whether
> > to abort.
>
> Normally, acquiring a lock doesn't require running code in other
> threads, at least in the uncontended case.  If you have to switch
> threads twice in order to acquire a lock, your implementation could
> use some improvement.

Come on, you're just making stuff up.  How the *hell* do you get
switching threads twice out of that?  I'm saying that if threads have
to synchronize data, then it's no big deal to have the thread check a
flag over whether to terminate when synchronizing.  Take a look at
this recipe for an example:

http://code.activestate.com/recipes/576461/

That concept, I say, can be applied to any thread that shares data
with the main thread, with any sort of regularity, even if it's
doesn't use queues specifically.

The only time it's any trouble to notify a thread to terminate is when
that thread's running code that's not aware it's in a threaded app
(which implies that it's not sharing any data, aside from read-only).
But since it's not communicating with another threads you might as
well run it in another process; communication overhead is not going to
be a big deal in that case.


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

[ANN] pyxser-1.0rc1 --- python xml serialization

[Daniel Molina Wegener]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hello,

I'm pleased to announce pyxser-1.0rc1, a Python-Object to XML
serializer and deserializer. This package it's completly
written in C and licensed under LGPLv3.

The tested Python versions are 2.5.X and 2.7.X.

* home page:
  http://coder.cl/software/pyxser

* hosted at:
  https://sourceforge.net/projects/pyxser/

The current ChangeLog is as follows:

- -8<--8<--8<--8<-
1.0rc1 (2009.04.26):

Daniel Molina Wegener 
* Added both byte string and unicode returning and procesing
functions. This means that we have serialize(),
serialize_c14n(), serialize_c14n_strict(), unserialize(),
validate() and validate_c14n() functions for byte strings
and u_serialize(), u_serialize_c14n(), u_serialize_c14n_strict(),
u_unserialize(), u_validate() and u_validate_c14n() for
unicode strings.
* Removed memory leaks, now it runs over 140 pyxser
operations without crashing (10 cicles testing every
function).
* Removed bugs concerning reference counting that was
crashing when trying to access unserialized objects attributes.
* This is an approach to a production environment release ;)
- -8<--8<--8<--8<-

Feel free to use and test. You can modify test-utf8-prof.py
to use more than 100.000 cicles without crashing.

Best regards,
- -- 
 .O. | Daniel Molina Wegener   | FreeBSD & Linux
 ..O | dmw [at] coder [dot] cl | Open Standards
 OOO | http://coder.cl/| FOSS Developer

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (FreeBSD)

iQIcBAEBCgAGBQJJ9QGNAAoJEHxqfq6Y4O5N/JYP/jT+4O+IPM2tFyGX8dXd5i9K
JF606e0g55twAwsZ2Tmdq/+qJJaNEPL/8tum9wDLzDKIe4RJF2l02ifisIRuR+GW
HfnLdxJFH5N7z4fZd+MN1HWsSmS4Peg5wxzjlyV+Y4Odv0MWUFbKgo3lraH+zPcW
pdmvfQoI6TpxWDWghZEeewpXLXLnFvP0+JyT4XBbjknG8CxB6cptOHQREmTtadMy
n1AFXoyj+00I+bWWoYFCklRZv8Rf6qL4v7gmH5F+fxKx71GUH50nQKGBG4IgUZcQ
9VqgC7z7WNHh5oy1ryp52zfta517mQ0ilMIm54BPrHEigb7v5pDXVhaoWebkgKux
FKr5IGperrjT+GbRcxRiUPO0stqXjBI60qjB54Gh5RR86uF44lqhSzbjaxi/vweF
ZZNzeAu3DZWgAAmusxHQP8mgw1OPcxWTL58kOKxP659rxHZjPfHcqU0rLjSkxZBl
wFbY7cz5j13G0ZlWclY4UglweSwv6vY6DJzJRHC5GpPRq0g0xT7t0n7hy+craSKV
c/hDgrMdrmT7ZPQA6d5UroUVWTmg1GR/RdW7XkUeYwfpICRTnvgtWiF9jWxh5w8g
oI/CLDtKp6aCR5Y8PHRxuZrzRsWFum0HVVD6AilVJnHWxJYgN7aicqpx1uCdsF+w
l5tsm/jqWTayiJDq0Pt8
=3fTt
-END PGP SIGNATURE-
--
http://mail.python.org/mailman/listinfo/python-list

Re: ANN: PyGUI 2.0.5

[greg]

rzed wrote:

I note that 2.0.5 comments the WM_MOUSELEAVE event, which wasnt' 
mapped in Events.py. Does that mean there is no way to signal such an 
event?


I'm no longer promising to provide mouse_enter and
mouse_leave events on any platform for the time being.
It's not straightforward to implement them on Windows
and they never worked consistently between Cocoa and
Gtk anyway, so they weren't very useful.

> Is that a QT or PyQt limitation?

It's a Windows API awkwardness. You don't get
WM_MOUSELEAVE events automatically, you have to ask
for them, and there's no such thing as a WM_MOUSEENTER
event at all.

It's not impossible, just more bother than I want
to go to right now.

I'll reconsider the whole issue in the future if
use cases for these events come up. Right now I
don't have any.

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

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

[jazbees]

On Apr 25, 12:11 pm, Duncan Booth 
wrote:
> 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?

Not at all.  Do you object to my use of lambdas?  I'm not aware of
anything that says it's bad form to define a function using a lambda
when the only thing that a function does is immediately return some
calculated value.

> 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")

I wasn't aware of either "any" or "all".  Thanks for the info!
Unfortunately this recent project where I used "min" and "max" is
running on a system using Python 2.4, so "any" and "all" are not
available.

> 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))

I haven't used sets very much, but I'll definitely keep this in mind.
Thanks!
--
http://mail.python.org/mailman/listinfo/python-list

Re: ANN: PyGUI 2.0.5

[Greg Ewing]

Randy Syring wrote:

Could you tell me briefly how this project differs from something like 
wxPython?


It wraps platform-specific libraries directly, rather than
being a wrapper around another cross-platform library. This
means less bloat and less dependencies. Chances are you
already have the necessary libraries installed.

The API is designed to be very straightforward and Pythonic,
and it's fully documented in its own terms, so you don't
have to consult the documentation for some other library
in some other language and translate into Python.

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

Re: ANN: PyGUI 2.0.5

[greg]

Suraj Barkale wrote:


Minor nitpicks:
1. Menu accelerators are not enabled by default i.e. pressing Alt + F does not
open the File menu.
2. Alt + F4 does not close the window.


I'll see if I can do something about these.


3. None of the controls (except menus) have _Vista look_ to them


I don't know what I need to do in order to get a
Vista look...

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

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

[John Machin]

On Apr 27, 11:43 am, jazbees  wrote:
> On Apr 25, 12:11 pm, Duncan Booth 
> wrote:
>
> > 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?
>
> Not at all.  Do you object to my use of lambdas?  I'm not aware of
> anything that says it's bad form to define a function using a lambda
> when the only thing that a function does is immediately return some
> calculated value.
>
> > 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")
>
> I wasn't aware of either "any" or "all".  Thanks for the info!
> Unfortunately this recent project where I used "min" and "max" is
> running on a system using Python 2.4, so "any" and "all" are not
> available.
>
> > 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))
>
> I haven't used sets very much, but I'll definitely keep this in mind.

Something else worth noting:

dos-prompt>\python24\python -mtimeit -s"hasvowels=lambda x:max([y in x
for y in 'aeiou'])" "hasvowels('parsnips')"
10 loops, best of 3: 3.08 usec per loop

dos-prompt>\python24\python -mtimeit -s"hasvowels=lambda x:max([y in x
for y in 'aeiou'])" "hasvowels('qwrtypsdf')"
10 loops, best of 3: 3.06 usec per loop

dos-prompt>\python24\python -mtimeit -s"import re; hasvowels=re.compile
('[aeiou]').search" "hasvowels('parsnips')"
100 loops, best of 3: 1.32 usec per loop

dos-prompt>\python24\python -mtimeit -s"import re; hasvowels=re.compile
('[aeiou]').search" "hasvowels('qwrtypsdf')"
100 loops, best of 3: 0.934 usec per loop

HTH,
John

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

Is there a maximum size to a Python program?

[Carbon Man]

I have a program that is generated from a generic process. It's job is to 
check to see whether records (replicated from another system) exist in a 
local table, and if it doesn't, to add them. I have 1 of these programs for 
every table in the database. Everything works well until I do the postcode 
table. The generated code is 5MB for a system with no current data. Normally 
the file would not be this big as only the changes are copied over. Python 
just quits, I have tried stepping through the code in the debugger but it 
doesn't even start.
I am thinking that dynamically generating the programs to run might not be 
such a good idea. It would be a shame to drop it because the system needs to 
be generic and it runs from an XML file so the resulting code could be 
pretty complex, and I am new to Python. The program did generate a pyc so it 
was able to compile.
Thoughts anyone? 


--
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-26, Lawrence D'Oliveiro  wrote:
> 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.

Who's "we"?  Are you volunteering to fix all of the MUAs and
MTAs out there that have mbox code in them that do follow the
rules to make them compatible with _one_ broken library module?

It would be a lot simpler to fix Python's library so that _it_
followed the same rules that everybody else does.

For Pete's sake, it's _two_lines_of_code_.

-- 
Grant

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

Re: Cannot find text in *.py files with Windows Explorer?

[John Doe]

John Doe  wrote:

...

> Another file manager, FreeCommander, does find text in Python files.

However... It does not have Undo! Potentially risky.
--
http://mail.python.org/mailman/listinfo/python-list

ActiveState Komodo Edit?

[John Doe]

Having trouble tabifying a section of Python code.
Code -- Tabify Region
Does it work for anyone else?

Thanks.



-- 
Interested in making Windows and games obey your verbal commands? 
Continuous command recognition (much easier than speech recognition) 
can now be enabled using Naturally Speaking and freeware Dragonfly. 
See (comp.lang.beta) for discussion.
--
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-26, tinn...@isbd.co.uk  wrote:
> Grant Edwards  wrote:
>> > 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().  ;)
>> 
> Yes, but I'm not sure that I'm that competant!

I bet you are -- it's Python, not C++.  [1]

 * You understand the problem: both how the current version
   works and how it should work.

 * You know how to test for the problem.

That's the hard part.

The rest is just typing.  And dealing with bugtracking systems
(personally, I find that to be the most difficult part).
Actually, just entering the bug along with a small demo app
showing the problem is probably all you really need to do. I'm
sure the library maintainers would appreciate a patch as well,
but if they're anything like me, me they apprecate a demo app
and test cases a lot more.

>>> All I need to do now is find out how to get and set atime with
>>> python.
>> 
>> You use os.utime().
>
> Thanks!

My apologies: I forgot to tell you how to _get_ atime and
mtime, but I see somebody else already has.  There is one
tricky bit (as explained on a qmail man page).  If the file was
last read less that a second before the message was added, you
could end up with the case where atime==mtail (they only have
1-second granularity).  Apparently there are MUAs that think
that means "no new mail", so qmail's delivery code checks for
that case and sets atime = mtime-1.

[1] Admit it, you thought I couldn't work a shot at C++ into
this thread...

-- 
Grant

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

Re: How to import modules from specific Python installation?

[kk]

Hi


Thank you for the suggestions, I will see what I can from here.
--
http://mail.python.org/mailman/listinfo/python-list

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

[Aahz]

In article ,
Lawrence D'Oliveiro   wrote:
>
>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.

Are you volunteering to maintain trn3.6?
-- 
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: mailbox.mbox.add() also seems to set file permissions

[Aahz]

In article ,
Grant Edwards   wrote:
>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

That's for doc bugs; regular bugs go to bugs.python.org (which is
currently down due to hardware problems).
-- 
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: Is there a maximum size to a Python program?

[Steven D'Aprano]

On Mon, 27 Apr 2009 13:01:22 +1000, Carbon Man wrote:

> I have a program that is generated from a generic process. It's job is
> to check to see whether records (replicated from another system) exist
> in a local table, and if it doesn't, to add them. I have 1 of these
> programs for every table in the database. 


Sounds like a needlessly complicated way of doing things. Surely 
replicating data from a database is a solved problem?


> Everything works well until I
> do the postcode table. The generated code is 5MB for a system with no
> current data. 

I don't understand what you mean by "with no current data". Do you mean 
that you generate 5MG of source code when the original postcode table is 
empty? Or 5MB of source code when the *replicated* table is empty? Or 
something else?


> Normally the file would not be this big as only the
> changes are copied over. Python just quits, I have tried stepping
> through the code in the debugger but it doesn't even start.

That depends on how your generated code looks.

Some years ago, somebody posted here complaining that his generated code 
wasn't working. It turned out that he was generating a single function 
looking something vaguely like this:

def function(alist):
alist[0] = 0
alist[1] = 0
alist[2] = 0
alist[3] = 0
...
alist[2997] = 0
alist[2998] = 0
alist[2999] = 0
return alist

Naturally, Python would need to load all 30 million lines of code into a 
*single* code object, which was too large to load.

After changing the generated code to look something like this:

def function(alist):
for i in xrange(3000):
alist[i] = 0
return alist

it worked perfectly.

(I am a little fuzzy on the precise details, and googling is not helping, 
so please excuse any discrepancies between my memory of the thread and 
the actual reality.)



> I am thinking that dynamically generating the programs to run might not
> be such a good idea. It would be a shame to drop it because the system
> needs to be generic and it runs from an XML file so the resulting code
> could be pretty complex, and I am new to Python. The program did
> generate a pyc so it was able to compile.
> Thoughts anyone?

Perhaps you could explain what the 5MB of code is supposed to do it, and 
how you generate the code, and show a *small* number of sample lines.




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

Re: mod_python form upload: permission denied sometimes...

[Lawrence D'Oliveiro]

In message <0fc15bee-003a-45ca-
b6b6-21ed0645b...@q2g2000vbr.googlegroups.com>, psaff...@googlemail.com 
wrote:

> I have a mod_python application that takes a POST file upload from a
> form. It works fine from my machine, other machines in my office and
> my home machine. It does not work from my bosses machine in a
> different city - he gets "You don't have permission to access this on
> this server".
> 
> In the logs, it's returned 403. I also have this error in error.log:
> 
> Cannot traverse upload in /pythonapps/wiggle/form/upload because
>  is not a traversable object,
> referer: ...

Sounds like a bug in your code. Have you tried uploading a smaller file? 
What's different about the setup on your boss's machine? OS? Browser? 
Addons?

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

Re: Is there a maximum size to a Python program?

[Paul Hemans]

Thanks for the reply,

> Sounds like a needlessly complicated way of doing things. Surely
> replicating data from a database is a solved problem?
The data is coming from a legacy system and going into SQLalchemy to give 
database independence. We will probably update the legacy apps in the future 
but it is a massive job for little benefit.

> I don't understand what you mean by "with no current data". Do you mean
> that you generate 5MG of source code when the original postcode table is
> empty? Or 5MB of source code when the *replicated* table is empty? Or
> something else?
5MB of source code when the replicated table is empty

> Perhaps you could explain what the 5MB of code is supposed to do it, and
> how you generate the code, and show a *small* number of sample lines.
Here is a generated file that works. Other files are essentially the same 
but with more entries. This one only adds if the record does not exist, the 
next stage was to update an existing record with changes.

!/usr/bin/python
# -*- coding: utf-8 -*-
import schema
import time
from datetime import *
from sqlalchemy import *
from sqlalchemy.orm import *
engine = create_engine('sqlite:///tutorial.db', echo=False)
Session = sessionmaker(bind=engine)
session = Session()

entry = schema.BILLS()
exists = session.query(schema.BILLS).filter(schema.BILLS.REFNO==u"1")
if exists.count == 0:
entry.REFNO = u"1"
entry.THRDPTY = u"""C5"""
entry.AMOUNT = 0
entry.TIMESTAMP = 0
entry.ALLOCATED = 0
session.add(entry)

session.commit()
session.close() 


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

Re: Is there a maximum size to a Python program?

[John Machin]

On Apr 27, 1:01 pm, "Carbon Man"  wrote:
> I have a program that is generated from a generic process. It's job is to
> check to see whether records (replicated from another system) exist in a
> local table, and if it doesn't, to add them. I have 1 of these programs for
> every table in the database. Everything works well until I do the postcode
> table. The generated code is 5MB for a system with no current data. Normally
> the file would not be this big as only the changes are copied over. Python
> just quits, I have tried stepping through the code in the debugger but it
> doesn't even start.
> I am thinking that dynamically generating the programs to run might not be
> such a good idea.

I tend to agree with that line of thinking. What you need is:
(a) ONE program. That's not one per table, that's one and only one,
period/full-stop.
(b) Per-table config info like column names and types -- you have this
already.

The idea is that instead of reading a data file and generating SQL per
row, you generate SQL once, with parameter markers for the data
values. Then you read the data file and execute the prepared SQL for
each row

More detail:

At the start, build an INSERT statement that's tailored for the table
that you are updating:

insert_sql = "INSERT INTO table_name VALUES (?,?,?,?)"
or (if you are paranoid)
"INSERT INTO table_name(col1,col2,col3,col4) VALUES (?,?,?,?)"

Notes: (a) assumes four columns as an example (b) Lower-case stuff has
to be replaced with the correct table name and column name(s) (c) "?"
is the parameter marker for the DB module you are using

For each row read from the data file, transform the input into a tuple
of suitable data types, and then do the insert:
import yourdbmodule
# much later:
try:
   cursor.execute(insert_sql, data_tuple)
except yourdbmodule.IntegrityError: #
   if it's the primary key not unique exception:
  pass # ignoring this is part of your requirement
   else:
  raise # probably never happen, but should be checked

> It would be a shame to drop it because the system needs to
> be generic

OTOH it would be a shame to continue with a process where the amount
of code lying around is O(N_update_rows) instead of O(1) and the
number of programs is O(N_tables) instead of O(1).

> and it runs from an XML file so the resulting code could be
> pretty complex, and I am new to Python.

The above advice is in general language-agnostic; I'm just using
Python code because you asked in this newsgroup. The fact that other
languages may give you more rope with which to hang yourself is also
immaterial :-)

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

Re: question about class vs class at

[Tim Roberts]

grocery_stocker  wrote:
>
>Maybe. I guess I haven't been around python long enough to realize
>that there was a difference in 'output' between the old-style class
>and new-style class.

Also remember that a class can define its own string to print there.  What
you see is the output of the __repr__ function of the class.
-- 
Tim Roberts, t...@probo.com
Providenza & Boekelheide, Inc.
--
http://mail.python.org/mailman/listinfo/python-list