Re: Fuzzy matching of postal addresses

[Aaron Bingham]

Andrew McLean wrote:
Thanks for all the suggestions. There were some really useful pointers.
A few random points:
[snip]
4. You need to be careful doing an endswith search. It was actually my 
first approach to the house name issue. The problem is you end up 
matching "12 Acacia Avenue, ..." with "2 Acacia Avenue, ...".
Is that really a problem?  That looks like a likely typo to me.  I guess 
it depends on your data set.  In my case, the addresses were scattered 
all over the place, with relatively few in a given city, so the 
likelyhood of two addresses on the same street in the same town was very 
low.  We /wanted/ to check for this kind of 'duplication'.

Note that endswith will not deal with 'Avenue' vs. 'Ave.', but I supose 
a normalization phase could take care of this for you.  The Monge 
algorithm I pointed you to takes care of this pretty nicely.

--

Aaron Bingham
Application Developer
Cenix BioScience GmbH

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

MDaemon Warning - virus found: Delivery reports about your e-mail

[Mail Administrator]

*** WARNING **
Este mensaje ha sido analizado por MDaemon AntiVirus y ha encontrado 
un fichero anexo(s) infectado(s).  Por favor revise el reporte de abajo.

AttachmentVirus name   Action taken
--
message.pif   I-Worm.Mydoom.m  Removed


**


This message was undeliverable due to the following reason:

Your message could not be delivered because the destination computer was
unreachable within the allowed queue period. The amount of time
a message is queued before it is returned depends on local configura-
tion parameters.

Most likely there is a network problem that prevented delivery, but
it is also possible that the computer is turned off, or does not
have a mail system running right now.

Your message could not be delivered within 3 days:
Server 127.15.40.10 is not responding.

The following recipients did not receive this message:


Please reply to [EMAIL PROTECTED]
if you feel this message to be in error.

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

RE: Print to Windows default Printer

[Tim Golden]

[Samantha]
| I am new to Python and I am having considerable trouble 
| trying to print 
| (using a simple script) to the default printer rather than the screen.
| Thanks for any help.
| S 

It may be that something here will help you:

http://tgolden.sc.sabren.com/python/win32_how_do_i/print.html

Specifically, I think that the section print raw text is
closest to what you're asking (although not necessarily
to what you'll eventually want):

http://tgolden.sc.sabren.com/python/win32_how_do_i/print.html#win32print

TJG


This e-mail has been scanned for all viruses by Star. The
service is powered by MessageLabs. For more information on a proactive
anti-virus service working around the clock, around the globe, visit:
http://www.star.net.uk

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

RE: Solutions for data storage?

[Robert Brewer]

Leif K-Brooks wrote:
> My ideal solution would be an object database (or object-relational 
> mapper, I guess) which provided total transparency in all but a few 
> places, built-in indexing, built-in features for handling schema 
> changes, the ability to create attributes which are required to be 
> unique among other instances, and built-in querying with 
> pretty syntax.

Thanks; I'll add unique indexing to the feature list for Dejavu. Should
be about 15 lines of code. :)

Try svn://casadeamor.com/dejavu/trunk if you want a truly Pythonic query
syntax. Wait a couple of days, and I'll have version 1.3 ready and
online at http://www.aminus.org/rbre/python -- lots of changes from
1.2.6 which is there now, but at least you can read old docs online now
without svn.


Robert Brewer
MIS
Amor Ministries
[EMAIL PROTECTED]
--
http://mail.python.org/mailman/listinfo/python-list

problem with import pylab from a website

[jean . rossier]

Hello All,
I am facing a problem while importing pylab library(in a .py program file) via
web browser however the same program works when I execute it from the command
prompt.


my configuration :

Fedora Core 3
Apache 2.0
python 2.3.4
postgresql 7.3.4
mod_python-3.1.3-5

Error message we get:

[Wed Jan 19 09:43:58 2005] [error] [client 128.178.156.101] Traceback (most
recent call last):, referer: http://128.178.156.101/sensor_data/readings.php
[Wed Jan 19 09:43:58 2005] [error] [client 128.178.156.101]   File
"/var/www/html/sensor_data/get_graph.py", line 15, in ?, referer:
http://128.178.156.101/sensor_data/readings.php
[Wed Jan 19 09:43:58 2005] [error] [client 128.178.156.101] , referer:
http://128.178.156.101/sensor_data/readings.php
[Wed Jan 19 09:43:58 2005] [error] [client 128.178.156.101] import pylab,
referer: http://128.178.156.101/sensor_data/readings.php
[Wed Jan 19 09:43:58 2005] [error] [client 128.178.156.101]   File
"/usr/lib/python2.3/site-packages/pylab.py", line 1, in ?, referer:
http://128.178.156.101/sensor_data/readings.php
[Wed Jan 19 09:43:58 2005] [error] [client 128.178.156.101] , referer:
http://128.178.156.101/sensor_data/readings.php
[Wed Jan 19 09:43:58 2005] [error] [client 128.178.156.101] from
matplotlib.pylab import *, referer:
http://128.178.156.101/sensor_data/readings.php
[Wed Jan 19 09:43:58 2005] [error] [client 128.178.156.101]   File
"/usr/lib/python2.3/site-packages/matplotlib/pylab.py", line 184, in ?, referer:
http://128.178.156.101/sensor_data/readings.php
[Wed Jan 19 09:43:58 2005] [error] [client 128.178.156.101] , referer:
http://128.178.156.101/sensor_data/readings.php
[Wed Jan 19 09:43:58 2005] [error] [client 128.178.156.101] from axes import
Axes, PolarAxes, referer: http://128.178.156.101/sensor_data/readings.php
[Wed Jan 19 09:43:58 2005] [error] [client 128.178.156.101]   File
"/usr/lib/python2.3/site-packages/matplotlib/axes.py", line 14, in ?, referer:
http://128.178.156.101/sensor_data/readings.php
[Wed Jan 19 09:43:58 2005] [error] [client 128.178.156.101] , referer:
http://128.178.156.101/sensor_data/readings.php
[Wed Jan 19 09:43:58 2005] [error] [client 128.178.156.101] from axis import
XAxis, YAxis, referer: http://128.178.156.101/sensor_data/readings.php
[Wed Jan 19 09:43:58 2005] [error] [client 128.178.156.101]   File
"/usr/lib/python2.3/site-packages/matplotlib/axis.py", line 20, in ?, referer:
http://128.178.156.101/sensor_data/readings.php
[Wed Jan 19 09:43:58 2005] [error] [client 128.178.156.101] , referer:
http://128.178.156.101/sensor_data/readings.php
[Wed Jan 19 09:43:58 2005] [error] [client 128.178.156.101] from font_manager
import FontProperties, referer: http://128.178.156.101/sensor_data/readings.php
[Wed Jan 19 09:43:58 2005] [error] [client 128.178.156.101]   File
"/usr/lib/python2.3/site-packages/matplotlib/font_manager.py", line 942, in ?,
referer: http://128.178.156.101/sensor_data/readings.php
[Wed Jan 19 09:43:58 2005] [error] [client 128.178.156.101] , referer:
http://128.178.156.101/sensor_data/readings.php
[Wed Jan 19 09:43:58 2005] [error] [client 128.178.156.101] fontManager =
FontManager(), referer: http://128.178.156.101/sensor_data/readings.php
[Wed Jan 19 09:43:58 2005] [error] [client 128.178.156.101]   File
"/usr/lib/python2.3/site-packages/matplotlib/font_manager.py", line 786, in
__init__, referer: http://128.178.156.101/sensor_data/readings.php
[Wed Jan 19 09:43:58 2005] [error] [client 128.178.156.101] , referer:
http://128.178.156.101/sensor_data/readings.php
[Wed Jan 19 09:43:58 2005] [error] [client 128.178.156.101] rebuild(), referer:
http://128.178.156.101/sensor_data/readings.php
[Wed Jan 19 09:43:58 2005] [error] [client 128.178.156.101]   File
"/usr/lib/python2.3/site-packages/matplotlib/font_manager.py", line 780, in
rebuild, referer: http://128.178.156.101/sensor_data/readings.php
[Wed Jan 19 09:43:58 2005] [error] [client 128.178.156.101] , referer:
http://128.178.156.101/sensor_data/readings.php
[Wed Jan 19 09:43:58 2005] [error] [client 128.178.156.101]
pickle.dump(self.ttfdict, file(ttfcache, 'w')), referer:
http://128.178.156.101/sensor_data/readings.php
[Wed Jan 19 09:43:58 2005] [error] [client 128.178.156.101] IOError, referer:
http://128.178.156.101/sensor_data/readings.php
[Wed Jan 19 09:43:58 2005] [error] [client 128.178.156.101] : , referer:
http://128.178.156.101/sensor_data/readings.php
[Wed Jan 19 09:43:58 2005] [error] [client 128.178.156.101] [Errno 13]
Permission denied: '/usr/share/matplotlib/.ttffont.cache', referer:
http://128.178.156.101/sensor_data/readings.php
[Wed Jan 19 09:43:58 2005] [error] [client 128.178.156.101] , referer:
http://128.178.156.101/sensor_data/readings.php
[Wed Jan 19 09:43:58 2005] [error] [client 128.178.156.101] Premature end of
script headers: get_graph.py, referer:
http://128.178.156.101/sensor_data/readings.php



Thanks in advance.

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

Dictionary keys (again) (was Re: lambda)

[Nick Coghlan]

Antoon Pardon wrote:
A rule of thumb is context sensitive. If circumstances change,
so do the rules of thumb. Principles have a broader field
of application.
IMO there is nothing principally wrong with using a mutable object
as a dictionary key. But avoiding doing so is a good rule of
thumb if you have a python-like implementation of a dictionary.
For a 'mutable key' to make sense, the following:
lst = []
dct = {l: "Hi!"}
print dct[[]]
print dct[lst]
lst.append(1)
print dct[[1]]
print dct[lst]
Should print:
Hi
Hi
Hi
Hi
That's completely impractical though - for any sane implementation, at least one 
of the above print statements will throw a KeyError.

Your example of a 'safe_dict' that copies mutable keys means that the final 
print statement is the one that fails.

My suggestion of an "identity_dict" means that both of the same-value based 
lookups would fail.

Notice that both of these approaches take a mutable key and make it immutable 
(either by holding the sole reference to a copy, or retrieving an immutable 
property of the mutable object).

There's also your solution of "I promise not to mutate the key while it is in 
the dictionary". Workable, but opens the door to some entertaining bug hunts 
when the promise is broken.

Which solution is the best default behaviour?
Well, the Zen of Python states "In the face of ambiguity, refuse the temptation 
to guess".

So that's the policy the builtin dict follows - it doesn't try to guess when to 
make a copy, or whether or not to use identity based semantics in the face of 
mutability. Instead, it raises an exception at key entry time, asking the 
programmer to clarify their intent.

The principle is *certainly* that hash tables should contain immutable keys. 
Your own 'safe_dict' example implicitly concedes this point by making copies 
'when required'. 'When required' for what? When required to preserve 
immutability, perhaps?

In short, sane hash tables require immutable keys, and how mutable keys acquire 
the requisite immutability is going to be application dependent.

Provision of a safe_dict or identity_dict would merely allow a programmer to 
state their intent at the time the container is created, rather than having to 
state it whenever keys are generated or referenced.

Cheers,
Nick.
--
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
http://boredomandlaziness.skystorm.net
--
http://mail.python.org/mailman/listinfo/python-list

python & iges (nurbs file format)

[Jelle Feringa // EZCT / Paris]

Is anyone aware of a module allowing you to read / write .iges data?

Currently I’m trying to figure a way of writing out my
nurbs data generated in python, but if such a package
exists, that would be great, haven’t been able to find anything so far…

 

Cheers,

 

Jelle.






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

Re: lambda

[Antoon Pardon]

Op 2005-01-18, David Bolen schreef <[EMAIL PROTECTED]>:
> Antoon Pardon <[EMAIL PROTECTED]> writes:
>
>> Op 2005-01-18, Simon Brunning schreef <[EMAIL PROTECTED]>:
>> > On 18 Jan 2005 07:51:00 GMT, Antoon Pardon <[EMAIL PROTECTED]> wrote:
>> >> 3 mutating an item in a sorted list *does* *always* cause problems
>> >
>> > No, it doesn't. It might cause the list no longer to be sorted, but
>> > that might or might no be a problem.
>> 
>> Than in the same vain I can say that mutating a key in a dictionary
>> doesn't always cause problems either. Sure it may probably make a
>> key unaccessible directly, but that might or might not be a problem.
>
> Well, I'd definitely consider an inaccessible key as constituting a
> problem, but I don't think that's a good analogy to the list case.
>
> With the dictionary, the change can (though I do agree it does not
> have to) interfere with proper operation of the dictionary, while a
> list that is no longer sorted still functions perfectly well as a
> list.

I think we are talking past each other. I'm talking about the concept
the programmer has in his mind. If the prgrammer has a sorted list in
his mind and an element in that list gets mutated that *does* *always*
cause problems. I'm not talking about a list in which the elements
happen to be in a particular order, but about a list that will be given
to algorithms that depend on the list being ordered.

> That is, I feel "problems" are more guaranteed with a
> dictionary since we have affected base object behavior, whereas sorted
> is not an inherent attribute of the base list type but something the
> application is imposing at a higher level.

But if the program uses one of the buildin sorts, isn't it then obvious
that this is an inherent attribute we want to impose? So is sorting
a list with mutable object not also more guaranteed to cause problems.
So shouldn't we limit the sort algorithms to containers with immutable
elements?

> For example, I may choose to have an object type that is mutable (and
> not worthy for use as a dictionary key) but maintains a logical
> ordering so is sortable.  I see no problem with sorting a list of such
> objects, and then walking that list to perform some mutation to each
> of the objects, even if along the way the mutation I am doing results
> in the items so touched no longer being in sorted order.  The act of
> sorting was to provide me with a particular sequence of objects,

Personnaly I don't see what the sorting was good for in this case.
And I think such programming might be slightly dangerous if you
cooperate with other people. They may not understand the particular
nature of your mutation and rely on the fact that your list has been
sorted to conclude that it still is sorted.

> but
> aside from that fact, the list continues to perform perfectly well as
> a list even after the mutations - just no longer delivering objects in
> sorted order.

Which may be a problem for those who rely on it.

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

Re: Dictionary keys (again) (was Re: lambda)

[Just]

In article <[EMAIL PROTECTED]>,
 Nick Coghlan <[EMAIL PROTECTED]> wrote:

> Antoon Pardon wrote:
> > A rule of thumb is context sensitive. If circumstances change,
> > so do the rules of thumb. Principles have a broader field
> > of application.
> > 
> > IMO there is nothing principally wrong with using a mutable object
> > as a dictionary key. But avoiding doing so is a good rule of
> > thumb if you have a python-like implementation of a dictionary.
> 
> For a 'mutable key' to make sense, the following:
> 
> lst = []
> dct = {l: "Hi!"}
> print dct[[]]
> print dct[lst]
> lst.append(1)
> print dct[[1]]
> print dct[lst]
> 
> Should print:
> Hi
> Hi
> Hi
> Hi
> 
> That's completely impractical though - for any sane implementation, at least 
> one 
> of the above print statements will throw a KeyError.
> 
> Your example of a 'safe_dict' that copies mutable keys means that the final 
> print statement is the one that fails.
> 
> My suggestion of an "identity_dict" means that both of the same-value based 
> lookups would fail.
> 
> Notice that both of these approaches take a mutable key and make it immutable 
> (either by holding the sole reference to a copy, or retrieving an immutable 
> property of the mutable object).
> 
> There's also your solution of "I promise not to mutate the key while it is in 
> the dictionary". Workable, but opens the door to some entertaining bug hunts 
> when the promise is broken.
> 
> Which solution is the best default behaviour?
> 
> Well, the Zen of Python states "In the face of ambiguity, refuse the 
> temptation 
> to guess".
> 
> So that's the policy the builtin dict follows - it doesn't try to guess when 
> to 
> make a copy, or whether or not to use identity based semantics in the face of 
> mutability. Instead, it raises an exception at key entry time, asking the 
> programmer to clarify their intent.
> 
> The principle is *certainly* that hash tables should contain immutable keys. 
> Your own 'safe_dict' example implicitly concedes this point by making copies 
> 'when required'. 'When required' for what? When required to preserve 
> immutability, perhaps?
> 
> In short, sane hash tables require immutable keys, and how mutable keys 
> acquire 
> the requisite immutability is going to be application dependent.
> 
> Provision of a safe_dict or identity_dict would merely allow a programmer to 
> state their intent at the time the container is created, rather than having 
> to 
> state it whenever keys are generated or referenced.

FWIW, the Cocoa framework on OSX supports mutable objects as keys. 
However, it makes an immutable copy. This is cheap for immutable objects 
-- Cocoa has both a mutable array as well as an immutable array, 
likewise for dicts -- since the "copy" will then simply be the same 
object. Thanks to PyObjC we can explore this from Python:

  Python 2.3 (#1, Sep 13 2003, 00:49:11) 
  [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin
  Type "help", "copyright", "credits" or "license" for more information.
  >>> from Foundation import *
  >>> lst = []
  >>> dct = NSMutableDictionary.alloc().init()
  >>> dct
  {}
  >>> dct[lst] = "Hi!"
  >>> dct
  {(1) = "Hi!"; }

(Note that Python lists get wrapped as native Cocoa arrays. '(1)' is 
Cocoa's repr for the wrapped array.)

  >>> dct[lst]
  u'Hi!'
  >>> lst.append(1)
  >>> dct[lst]
  Traceback (most recent call last):
   File "", line 1, in ?
   File 
"build/lib.darwin-7.6.0-Power_Macintosh-2.3/objc/_convenience.py", line 
77, in __getitem__objectForKey
  KeyError: [1, 1]
  >>> dct.keys()
  ((1))
  >>> dct[[1]]
  u'Hi!'
  >>> k = dct.keys()[0]
  >>> k
  (1)
  >>> k.append(2)
  Traceback (most recent call last):
   File "", line 1, in ?
   File 
"build/lib.darwin-7.6.0-Power_Macintosh-2.3/objc/_convenience.py", line 
205, in 
  objc.error: NSInternalInconsistencyException - *** -[NSCFArray 
addObject:]: mutating method sent to immutable object
  >>> 

This is not all that different from Python actually, in that Cocoa tries 
very hard to make it impossible to mutate dict keys.

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

Re: extension module, thread safety?

[Pierre Barbier de Reuille]

David Bolen a écrit :
Nick Coghlan <[EMAIL PROTECTED]> writes:
And even before that it was certainly possible to call into the Python
interpreter from a native thread using existing functions, albeit the
newer functions are more convenient (and perhaps more robust, I don't
know).
My earliest interaction with Python (~1999, while writing a module
that extended and embedded Python 1.5.2) used PyEval_AcquireThread()
and PyEval_ReleaseThread() to get access to a thread state from a
native C application thread (not initiated by the Python interpreter)
to allow me to call safely into an executing Python script upon
asynchronous data reception by the C code.
-- David
Yes, now you mention this I remember trying to use these functions ! But 
there is two problems with them (and only one is solved by the new 
functions) ! The first problem is the dead lock is you try to acquire 
the same thread twice. This implies a very low level use of these 
function, and it can be a real pain to find where to put them without 
risking this dead lock. This is no more a problem with the new 
functions. But the second (and not solved) problem is: these functions 
block the current thread when you try to get the GIL ! This is an issue 
if you don't want your GUI thread to be blocked when a buggy module does 
not release the GIL during long computations. I didn't find any function 
like "test the state of the GIL and if it's free, then acquire it" ! 
And, IMO, it's missing ... Then, if python goes to a model where 
critical sections are identified and the GIL acquired only there, all 
these problems will disappear ! That's why I really hope Python 3 will 
include this kind of thread support ...

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

Re: safest way to kill a thread

[martinnitram]

Great thank for your helping.
Should the 'daemonic' flag at setDaemon() function set to 1/TRUE or
0/FALSE to do such action?

limodou wrote:
>I think only those threads which invoked with setDaemon() method will
>exit, and others will not,  as the main program exit.

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

Re: lambda

[Antoon Pardon]

Op 2005-01-18, Bengt Richter schreef <[EMAIL PROTECTED]>:
> On 18 Jan 2005 13:28:00 GMT, Antoon Pardon <[EMAIL PROTECTED]> wrote:
>
>>I have implemented a hash table when I was a student and its
>>implementation allowed the use of 'mutable' objects as a key
>>without a problem. It simply always made copies when appropiate
>>and didn't allow external access to the keys. So although the
>>key objects were 'mutable' there was no way a user could accidently
>>mutate a key.
> This is word play IMO. What you describe is effectively using the mutables
> to construct immutable keys for actual use, not using immutable keys.

No it is not wordplay. There is a difference between inaccessible and
immutable. The difference is that the user can mutate his own objects
which he wants to use as a key, which wouldn't be the case if he was
using immutables as keys.

> Having
> the immutable (because of access restriction) constructed keys allows
> you to check on their consistency with their source any time you want,
> but that doesn't change the fact that you have created an alternative 
> dictionary
> implementation with immutable keys made immutable by copying and access 
> restriction.
> If you update your dictionary when a key no longer matches its source data, 
> you
> are just deleting an immutable-by-special-means key and entering the 
> associated
> value in association with a new immutable-by-special-means key.

The immutable vs mutable as keys IMO refers to the class the key belongs
to. Not the accessibiliy of individual instances.

>>So don't use a mutable as a dictionary key isn't so much a dictionary
>>limitation in general but a specific limitation of the python implementation.
>>
>>And yes I understand, the current implenatation is the result of the
>>fact that the same dictionaries are used internally for variables in
>>scopes and attributes in objects and the fact that no copies are
>>involved gives a boost to performance. But it could be argued that
>>providing these same dictionaries with those semantics to the users
>>was a premature optimisation.
>
> If you see a sign like
>
>+->
>| WILD GOOSE CHASE THIS WAY->
>+->
>||
>||\|/
>||=o=
>||/|\
> .`.||,..__|_,.
>
> Do you feel that you must make sure?

Talk to my wife. She regularly complains that I don't accept
her word often enough on what she says. :-)

> The sign painter may only be indicating what his own experience was, after 
> all.
> But if it was a core developer's experience, it may be prudent to bet on 
> another trail
> -- unless you have an extremely interesting hunch. Then you should follow 
> your passion
> and have your own experience, and you may wind up being able to contribute 
> something
> (even if only an exclamation point on the sign ;-)
>
>>  
>>> When stating useful general principles, it is never, ever worth it to get 
>>> into 
>>> the quibbly little details about exceptions to the principle. If students 
>>> ask, 
>>> admit that they exist, but point out that the exceptions are rare, and not 
>>> worth 
>>> worrying about at that point in their learning.
>>
>>But don't use mutable keys is not a general principle. It is a principle
>>introduced by the limitations of the python implementations.
> That is so in your mind, and it is so given certain interpretations of the 
> words
> you are using,

As far as I understand I using them in a standard python interpretation.

> but to others "mutable keys" may be a contradiction in terms, because
> they do not use the words in the same sense as you.

I don't think so. I have seen defenders of only immutables as keys, use
the argument that using mutables as keys would require a copy of the key.
Therefore using only immutables allows for optimisations in the implementation.
I saw nothing in there discourse that implied they saw this copy as
immutable.

> If you can't see alternative conceptual
> constructs you are stuck, and if we can't agree on the meaning of words for a 
> given dialog,
> we won't be communicating very well. The difficulty is getting people to 
> recognize their
> implicit assumptions and definitions ;-)

I can be wrong, but until now I have seen no indication that I was
using mutable and immutable differently than other people. AFAICT
we all refer to whether an object belongs to a mutable or immutable
class.

>>I don't like it when a good rule of thumb because of implementation
>>limitations is sold as a general principle.
> People take short cuts in expressing themselves, just as you do.
> E.g., you say "mutable key" when you really mean a value that will
> remain constant while you are using it as a dictionary key.

What I mean is a key that belongs to a mutable class. Whether I
actually mutate it in certain circumstances or not doesn't change
that.

I also don't want my values to change when I have sorted a list
and still need to apply a number of algorithms that rel

Re: File objects? - under the hood question

[Jeremy Bowers]

On Tue, 18 Jan 2005 22:53:10 -0800, Eric Pederson wrote:
> Perhaps I've answered my question and the under-the-hood mechanics are
> handled on the OS side, and Python is just making requests of the OS...

Almost by definition, the only correct way to read a file is to use the
file system, which on current operating systems means going the the OS
kernel.

> My brain-teaser:  What I'd like to do is read the last ~2K of a large
> number of large files on arbitrary servers across the net, without having
> to read each file from the beginning (which would be slow and resource
> inefficient)...

"Across the net" is not specific enough. There are generally ways to do
that, subject to the support of the various relevant servers, but what
protocol are you talking about using? HTTP? FTP? NFS? Generally you issue
some sort of command to get the length, then some sort of "seek" or
"continuation" command to get to the end, but the details are different
for each protocol. (Unless someone has a convenient flattening library
around? I have something almost like that in my personal collection except
I have no intention of supporting "seek" behavior for various technical
reasons.)

And note that with the possible exception of that last one, there is no
relationship between these two questions. (Maybe you know that, maybe you
don't. :-) ) There is no argument you can pass to file() that will read an
HTTP file. (Pedants may note this isn't an absolute truth but it's "true
enough" that it's not worth sweating the details if you're still working
out what "file()" does.)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python/cgi/html bug

[Dfenestr8]

On Tue, 18 Jan 2005 21:50:58 -0800, Dan Bishop wrote:

> 
> Dfenestr8 wrote:
>> Hi.
>>
>> I've written a cgi messageboard script in python, for an irc chan I
> happen
>> to frequent.
>>
>> Bear with me, it's hard for me to describe what the bug is. So I've
>> divided this post into two sections: HOW MY SCRIPTS WORKS, and WHAT
> THE
>> BUG IS.
>> ...
>> The problem is when someone posts a new topic, and that topic happens
> to
>> have "" double quotes, or any other strange character, some strange
>> glitches occur.
> 
> Use cgi.escape(topic, True) to convert HTML special characters to the
> equivalent ampersand escape sequences.

Thanx.

Seems to work now. :)

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

Re: generator expressions: performance anomaly?

[Steven Bethard]

Stephen Thorne wrote:
On Tue, 18 Jan 2005 23:09:57 -0700, Steven Bethard
<[EMAIL PROTECTED]> wrote:
@with_consts(i=1, deftime=time.ctime())
def foo(x, y=123, *args, **kw):
return x*y, kw.get('which_time')=='now' and time.ctime() or deftime
Then you don't have to mix parameter declarations with locals definitions.
[1] I have no idea how implementable such a decorator would be.  I'd
just like to see function constants declared separate from arguments
since they mean such different things.

(untested)
def with_constant(**constants_kwargs):  
  def decorator(f)
def closure(*arg, **kwargs):
  kwargs.update(constants_kwargs)
  return f(*arg, **kwargs)
return closure
  return decorator
This doesn't quite work because it still requires that f take the 
constants as parameters:

py> def with_constant(**constants_kwargs):
... def decorator(f):
... def closure(*arg, **kwargs):
... kwargs.update(constants_kwargs)
... return f(*arg, **kwargs)
... return closure
... return decorator
...
py> @with_constant(x=1)
... def f(y):
... return x + y
...
py> f(1)
Traceback (most recent call last):
  File "", line 1, in ?
  File "", line 5, in closure
TypeError: f() got an unexpected keyword argument 'x'
I screwed around for a while with:
ctypes.pythonapi.PyFrame_LocalsToFast(ctypes.py_object(frame), 0)
which will let you propagate updates made to frame.f_locals, but only if 
you don't *add* any locals to the frame, as far as I can tell:

py> def f(x=1):
... frame = sys._getframe()
... frame.f_locals["x"] = 2
... print x
...
py> f()
1
py> def f(x=1):
... frame = sys._getframe()
... frame.f_locals["x"] = 2
... ctypes.pythonapi.PyFrame_LocalsToFast(
... ctypes.py_object(frame), 0)
... print x
...
py> f()
2
py> def f(x=1):
... frame = sys._getframe()
... frame.f_locals["y"] = 2
... ctypes.pythonapi.PyFrame_LocalsToFast(
... ctypes.py_object(frame), 0)
... print y
...
py> f()
Traceback (most recent call last):
  File "", line 1, in ?
  File "", line 6, in f
NameError: global name 'y' is not defined
Steve
--
http://mail.python.org/mailman/listinfo/python-list

IronPython, Boo and ASP.NET (web service)

[JZ]

Is there any way for preparing a simple web service (ASP.NET) using
IronPython or Boo (http://boo.codehaus.org/)? I cannot find any example. C#
uses [WebMethod] attribute for marking remote methods. I do not know how
IronPython or Boo deals with it.

-- 
JZ ICQ:6712522
http://zabiello.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: generator expressions: performance anomaly?

[Antoon Pardon]

Op 2005-01-18, Jeremy Bowers schreef <[EMAIL PROTECTED]>:
> On Tue, 18 Jan 2005 14:05:15 +, Antoon Pardon wrote:
>> I don't see how generating byte code for a = 9; when seeing the
>> expression a = 3 + 6, would be a problem for non-functional
>> languages.
>
> To answer nearly every post you've made to this thread, "because Python
> doesn't have the resources to program to special cases".

I was countering an argument that seemed to state doing something
like that was impossible on principle in python.

I was not argueing people should put any effort in this, just countering
it would change python beyond recognition.

> Ultimately, the use is fairly limited; I can't imagine the execution time
> saved would reach the time of implementation for weeks after a release,
> even aggregating across all Python use in the world, and "real time
> gained" (i.e., time useful to a human) would probably never add up to the
> implementation time. So why bother? That's a horrid trade off when there
> are so many other real gains to be had.

Well if it isn't worth the bother, so be it. I can still dream about it.

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

Re: lambda

[Nick Coghlan]

Antoon Pardon wrote:
> I can be wrong, but until now I have seen no indication that I was
using mutable and immutable differently than other people. AFAICT
we all refer to whether an object belongs to a mutable or immutable
class.
The difference is that when you take a copy of the key and stick it in the 
dictionary, such that the dictionary now holds the *sole* reference to that key, 
you have made that key *effectively* immutable.

This is why no-one really batted an eyelid when you mentioned that mutable keys 
can be used safely by making a copy - doing so makes the key *effectively* 
immutable, and means that modifying the original key object (i.e. the 
application's copy, not the dict's copy), and reusing it to look up in the 
dictionary is likely to give a KeyError.

These semantics would be understandably surprising to many users, and hence, are 
not supplied by default.

Additionally, a dictionary's keys are accessible via its API. Accordingly, to 
preserve this 'effective immutability', making a copy on key input is 
insufficient - keys must be copied on *output* as well (that is, dict.keys, 
dict.items etc must return *copies* of the key objects, not the key objects 
themselves).

Since there is no reliable way in Python to tell if an object is mutable or not 
(the closest equivalent is the presence of __hash__, which clearly can't be used 
in this example), this copying would need to be done for *every* object.

Alternately, the dictionary can say to the API clients, "make an immutable copy 
and supply that instead. It is left to API clients to decide how best to make 
the immutable version". The API client copies the key once (to make the 
immutable version), and everyone lives happily ever after.

For example:
Py> class mylist(list):
...   def __init__(self, arg):
... super(mylist, self).__init__(arg)
... self._tuple = None
...   def frozen(self):
... if self._tuple is None:
...   self._tuple = tuple(self)
... return self._tuple
...   def unfreeze(self):
... self._tuple = None
...
Py> x = mylist(range(10))
Py> x
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
Py> x.frozen()
(0, 1, 2, 3, 4, 5, 6, 7, 8, 9)
Py> x.append(10)
Py> x.frozen()
(0, 1, 2, 3, 4, 5, 6, 7, 8, 9)
Py> x.unfreeze()
Py> x.frozen()
(0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10)
This is much safer than having a list subclass that implements __hash__, and 
still lets you avoid redundant copy operations.

Nicely, so long as you don't unfreeze the object you used to key the dictionary, 
 reusing the same object will always get you the correct dictionary entry, and 
two lists that compare equal at the time they are frozen will also get you the 
same dictionary entry. The equivalent tuples can be used for the lookup, too.

I also don't want my values to change when I have sorted a list
and still need to apply a number of algorithms that rely on
that. Nobody seems to have problems with the possibility that
the list items are mutable (and called such).
OK, to make this comparison of sorted lists and dictionaries fair:
Write a sorted_list class that is like a regular Python list, but maintains as 
an invariant that the list contents will stay sorted.

See how well you go maintaining that invariant while allowing mutable objects in 
the list. The only way would be to copy them in when they're supplied, and copy 
them out again when you're done. Otherwise, there is no way the class can keep 
its promise. The performance will be lousy, since __setitem__ and __getitem__ 
will be making copies all the time.

Alternatively, the class could declare itself to work reliably only with 
immutable objects. Performance will improve, since copies need only be made when 
an object *actually* changes (and the old immutable copy is deleted and the new 
version inserted in its place).

Cheers,
Nick.
--
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
http://boredomandlaziness.skystorm.net
--
http://mail.python.org/mailman/listinfo/python-list

Re: generator expressions: performance anomaly?

[Antoon Pardon]

Op 2005-01-18, Steve Holden schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>
>> Op 2005-01-18, Steve Holden schreef <[EMAIL PROTECTED]>:
>> 
>> 
>>>Python is *designed* as a dynamic language. I wish you would embrace 
>>>this aspect rather than continually trying to shoehorn it into a static 
>>>straitjacket. Efficiency is good. Flexibility is better.
>> 
>> 
>> Flexibility is better? IMO flexibilty implies more than one way to do
>> things. But that is a big no no here in c.l.py.
>> 
> Become one with the language.

That is difficult if I hear so many contradictionary things about
it. Sometimes I have the feeling that the Zen of python is more
for poet like people, not for the extreme analytical kind, like
me.

>> I also see a lot of remarks that go: "Don't do this!" when some of
>> the more dynamic aspects are talked about, because there are 
>> security risks involved. One of the results was that I ended up
>> writing a parser for some kind of game instead of just dumping the
>> structure in textual form and doing an eval of the file when reading
>> it in. But if I need a parser I could just as well used a static
>> language.
>> 
> Wow, you mean you actually *took* some advice? :-) Perhaps this whole 
> thing has arisen because you feel you were badly advised. It looks as 
> though your programming skill level might have been underestimated. Your 
> ability to wring an argument to a merciless death could never be.

Again the problem is the many contradictionary arguments I get from
this group. My impression is that any time I do a suggestion here
or make a remark sooner or later someone will quote one of the rules
of python and will consider the matter closed by that. But those
rules can be used to support or reject any proposition.

If someone proposes to introduce an exception, the rule quoted
is: No exception is so importan to break the rule.

If someone proposes to make python more consistent, the rule
quoted is: practicallity beats purity.

So in the end I get the feelings that the strengths of arguments
doesn't matter here. If someone doesn't like a proposition, he
just looks for the rule it will break (and since the rules contradict
each other he will find one) and produce it as the final argument
for why the proposal won't work.

>> I'm beginning to guess the dynamic aspect of python is overrated.
>> 
> You shouldn't have to guess, and it isn't.
>
> Certain of its dynamic aspects do demand a certain care rather than 
> casual usage, however, which leads to rules of thumb like "don't use 
> mutables as dictionary keys". Yes, of course you can, but to a newbie 
> your behavior (it seems to me) is a bit like this:

But I am not talking to newbees. I am talking about documentation that
is in the language reference and things that I'm told.

If it would just be the tutorial and like wise documents that stated
to not use mutables as dictionary keys I could live with that. But
if the language reference suggest the same you can no longer claim
it is for the newbee's sake.

> Me (to newbie): "... And, of course, you want to be careful not to shoot 
> yourself in the foot."

> You: ":Well, actually, if you use a .22 and aim very carefully between 
> the big toe and its neighbor there's a 96% chance that you will only 
> suffer serious burns".
>
> So, please understand, I'm not trying to say that (most of) your 
> utterances are untrue, or question your knowledge of the Python 
> environment. I'm just trying to bring the day closer when you will be 
> able to watch me write something that's only 99% true and happily walk 
> away without writing a thousand-word essay on the remaining 1% case.

Well the problem may be I don't consider the person you are talking
to as a newbee. Just the fact that he asks a question that marks
him as a newbee in python doesn't mean he is a newbee programmer.

But you do have a point that I have a tendency to put salt on
any snail. I'll try to restrain myself a bit more in the future.

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

Re: rotor replacement

[Gerd Woetzel]

Robin Becker <[EMAIL PROTECTED]> writes:
>Paul Rubin wrote:
>.I'm also missing the rotor module and regret that something useful
>was warned about and now removed with no plugin replacement.

Hm, yes. Here is a (rather slow) replacement:

"""This module is derived from Modules/rotormodule.c and translated
   into Python. I have appended the Copyright by Lance Ellinghouse
   below. The rotor module has been removed from the Python 2.4
   distribution because

  the rotor module uses an insecure algorithm and is deprecated.
  ==

   Of course, this does still hold. However, I think this module might
   be used and adapted for demonstration purposes and might help some
   poor users who have encrypted (or obfuscated) some old stuff with
   the rotor module and have no access to older Python versions any
   more.

   Documentation can be found in

   Python Library Reference,  Guido van Rossum, Fred L. Drake, Jr., editor,
   PythonLabs, Release 2.3.4 May 20, 2004
   

   #
   Copyright 1994 by Lance Ellinghouse,
   Cathedral City, California Republic, United States of America.

All Rights Reserved

   Permission to use, copy, modify, and distribute this software and its
   documentation for any purpose and without fee is hereby granted,
   provided that the above copyright notice appear in all copies and that
   both that copyright notice and this permission notice appear in
   supporting documentation, and that the name of Lance Ellinghouse
   not be used in advertising or publicity pertaining to distribution
   of the software without specific, written prior permission.

   LANCE ELLINGHOUSE DISCLAIMS ALL WARRANTIES WITH REGARD TO
   THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND
   FITNESS, IN NO EVENT SHALL LANCE ELLINGHOUSE BE LIABLE FOR ANY SPECIAL,
   INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING
   FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT,
   NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION
   WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
   #
"""

class newrotor(object):

def __init__(self, key, n_rotors=6):
self.n_rotors = n_rotors
self.setkey(key)

def setkey(self, key):
self.key = key
self.rotors = None
self.positions = [None, None]

def encrypt(self, buf):
# Reset (encrypt) positions and encryptmore
self.positions[0] = None
return self.cryptmore(buf, 0)

def encryptmore(self, buf):
return self.cryptmore(buf, 0)

def decrypt(self, buf):
# Reset decrypt positions and decryptmore
self.positions[1] = None
return self.cryptmore(buf, 1)

def decryptmore(self, buf):
return self.cryptmore(buf, 1)

def cryptmore(self, buf, do_decrypt):
size, nr, rotors, pos = self.get_rotors(do_decrypt)
outbuf = []
append = outbuf.append
for c in map(ord, buf):
if do_decrypt:
# Apply decrypt rotors and xor in reverse order
for i in xrange(nr-1,-1,-1):
c = pos[i] ^ rotors[i][c]
else:
# Apply xor and ecrypt rotors
for i in xrange(nr):
c = rotors[i][c ^ pos[i]]
append(c)

# Advance rotors, i.e. add the (fixed) rotor increments to the
# variable rotor positions with carry.
# Note:  In the C-implementation, the result of the carry addition
#was stored to an "unsigned char". Hence the next carry
#is lost if pos[i] == size-1 and pnew >= size.
#Masking with 0xff simulates this behavior.
#
pnew = 0 # (pnew >= size) works as "carry bit"
for i in xrange(nr):
pnew = ((pos[i] + (pnew >= size)) & 0xff) + rotors[i][size]
pos[i] = pnew % size

return ''.join(map(chr, outbuf))

def get_rotors(self, do_decrypt):
# Return a tuple (size, nr, rotors, positions) where
# - size is the rotor size (== 256, because of 8-bit bytes)
# - nr is the number of rotors.
# - rotors is a tuple of nr encrypt or nr decrypt rotors
# for do_decrypt == 0 or do_decrypt == 1 respectively.
# - postions is a list of nr "rotor positions".
#
# The rotors represent the static aspect of the rotor machine which
# is initially computed from key and fixed during en/decryption.
# A rotor is a random permutation of range(size) extended
# by an "increment value" in range(size).
#
# The followng statements hold for a tuple of 

Re: rotor replacement

[Robin Becker]

Paul Rubin wrote:
"Reed L. O'Brien" <[EMAIL PROTECTED]> writes:
I see rotor was removed for 2.4 and the docs say use an AES module
provided separately...  Is there a standard module that works alike or
an AES module that works alike but with better encryption?

If you mean a module in the distribution, the answer is no, for
political reasons.
.I'm also missing the rotor module and regret that something useful 
was warned about and now removed with no plugin replacement.

I had understood that this was because rotor was insecure, but you 
mention politics. Are other useful modules to suffer from politics?

What exactly are/were the political reasons for rotor removal?
I might add that the source for rotormodule is still easily obtainable 
and can be compiled trivially as an extension for Python-2.4. Does the 
Python community take a position on the sources of removed modules?
--
Robin Becker
--
http://mail.python.org/mailman/listinfo/python-list

delay and force in Python

[Will Stuyvesant]

Here is a question for people who are more comfortable than
I am with new Python stuff like generators.

I am having fun implementing things from the Wizard book
(Abelson, Sussman, "Structure and Interpretation of Computer
Programs") in Python.  In chapter 3.5 it is about streams as
delayed lists.

Streams are interesting because they are to lists like
xrange is to range.  Could save a lot on memory and
computations.

Below is my straight translation from Scheme code in the
Wizard book to Python.  It works, but now I want to rewrite
the delay and force functions using Python's new stuff,
generators or iterators or what-have-you.  I have the
feeling that that is possible, can you do it?

The program below creates a stream with the numbers 1..995
and then filters the stream, keeping only the even numbers,
and then prints the second number in the stream (implemented
as the first number of the tail, just like in the 3.5
Section in the Wizard book).


. # file: teststreams.py
.
. def delay(exp): return lambda: exp
.
. def force(o): return o()
.
. def cons_stream(a,b): return [a, delay(b)]
.
. def stream_hd(s): return s[0]
.
. # we use tl for cdr
. def tl(x):
. if len(x) == 2: return x[1]
. else: return x[1:]
.
. def stream_tl(s): return force(tl(s))
.
. def stream_enumerate_interval(low, high):
. if low > high:
. return None
. else:
. return cons_stream(
.  low,
.  stream_enumerate_interval(low+1, high))
.
. def stream_filter(pred, s):
. if s is None:
. return None
. elif pred(stream_hd(s)):
. return cons_stream(
.  stream_hd(s),
.  stream_filter(pred, stream_tl(s)))
. else:
. return stream_filter(pred, stream_tl(s))
.
. def isEven(n): return n % 2 == 0
.
. print stream_hd(stream_tl(stream_filter(
.   isEven,
.   stream_enumerate_interval(1,995
. # 4



Something else: this crashes with a "maximum recursion reached"
. print stream_enumerate_interval(1,998)

while this does not crash
. print stream_enumerate_interval(1,900)
this means Python has a maximum of something like 900
recursions?

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

Re: delay and force in Python

[Benji York]

Will Stuyvesant wrote:
Streams are interesting because they are to lists like
xrange is to range.  Could save a lot on memory and
computations.
I think you're looking for generators.
Below is my straight translation from Scheme code in the
Wizard book to Python.

Something else: this crashes with a "maximum recursion reached"
. print stream_enumerate_interval(1,998)
Unlike Scheme, Python isn't designed for heavily recursive algorithms. 
Here's a more Pythonic equivalent of your code:

def count(start, stop):
i = start
while i < stop:
yield i
i += 1
def even(gen):
for x in gen:
if x % 2 == 0:
yield x
numbers = even(count(1, 999))
first = numbers.next()
second = numbers.next()
print second
--
Benji York
[EMAIL PROTECTED]
--
http://mail.python.org/mailman/listinfo/python-list

Re: delay and force in Python

[Nick Coghlan]

Will Stuyvesant wrote:
The program below creates a stream with the numbers 1..995
and then filters the stream, keeping only the even numbers,
and then prints the second number in the stream (implemented
as the first number of the tail, just like in the 3.5
Section in the Wizard book).
How's this:
Py> from itertools import islice
Py> print islice((x for x in xrange(1, 996) if x % 2 == 0), 1, 2).next()
4
Breaking it into pieces:
Py> from itertools import islice
Py> stream = (x for x in xrange(1, 996) if x % 2 == 0)
Py> second_item = islice(stream, 1, 2).next()
Py> print second_item
4
And most of the stream hasn't been consumed yet:
Py> print stream.next()
6
Py> unconsumed = list(stream)
Py> len(unconsumed)
494
And this version has no problem with recursion limits:
Py> print islice((x for x in xrange(1, sys.maxint) if x % 2 == 0), 1, 2).next()
4
(xrange can't handle Python longs, unfortunately, so we *are* constrained by 
sys.maxint. However, since my machine only has half a gig of RAM, the above is 
still a damn sight quicker than the equivalent list comprehension would be!)

Something else: this crashes with a "maximum recursion reached"
. print stream_enumerate_interval(1,998)
while this does not crash
. print stream_enumerate_interval(1,900)
this means Python has a maximum of something like 900
recursions?
The CPython implementation is limited by the stack size allocated by the C 
runtime library. The exact recursion limit is platform dependent, but something 
around 1000 sounds fairly normal.

Cheers,
Nick.
--
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
http://boredomandlaziness.skystorm.net
--
http://mail.python.org/mailman/listinfo/python-list

Re: rotor replacement

[Paul Rubin]

Robin Becker <[EMAIL PROTECTED]> writes:
> What exactly are/were the political reasons for rotor removal?

Some countries have laws about cryptography software (against some
combination of export, import, or use).  The Python maintainers didn't
want to deal with imagined legal hassles that might develop from
including good crypto functions in the distribution.  Then it became
obvious that the same imagined hassles could also befall the rotor
module, so that was removed.

> I might add that the source for rotormodule is still easily obtainable
> and can be compiled trivially as an extension for Python-2.4. Does the
> Python community take a position on the sources of removed modules?

Those are still free to distribute, but I'd advise against doing so
with the rotor module unless you absolutely need it for some
interoperability purpose.  Otherwise, it's insecure and should not be
used.  The routine I posted was intended as a straightforward
replacement for the rotor module that doesn't depend on C compilers
and is reasonably secure.  If you don't mind using C extensions,
there's various AES modules available, plus fancier packages like
mxCrypto.

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

Re: simultaneous multiple requests to very simple database

[John Lenton]

On Tue, Jan 18, 2005 at 11:26:46AM -0500, Eric S. Johansson wrote:
> I have an application where I need a very simple database, effectively a 
> very large dictionary.  The very large dictionary must be accessed from 
> multiple processes simultaneously.  I need to be able to lock records 
> within the very large dictionary when records are written to.  Estimated 
> number of records will be in the ballpark of 50,000 to 100,000 in his 
> early phase and 10 times that in the future.  Each record will run about 
> 100 to 150 bytes.
> 
> speed is not a huge concern although I must complete processing in less 
> than 90 seconds.  The longer the delay however the greater number of 
> processes must be running parallel in order to keep the throughput up. 
> It's the usual trade-off we have all come to know and love.
> 
> it is not necessary for the dictionary to persist beyond the life of the 
> parent process although I have another project coming up in which this 
> would be a good idea.
> 
> at this point, I know they will be some kind souls suggesting various 
> SQL solutions.  While I appreciate the idea, unfortunately I do not have 
> time to puzzle out yet another component.  Someday I will figure it out 
> because I really liked what I see with SQL lite but unfortunately, today 
> is not that day (unless they will give me their work, home and cell 
> phone numbers so I can call when I am stuck. ;-)

I'm sure we could agree on a fee for me to do so :)

> So the solutions that come to mind are some form of dictionary in shared 
> memory with locking semaphore scoreboard or a multithreaded process 
> containing a single database (Python native dictionary, metakit, gdbm??) 
> and have all of my processes speak to it using xmlrpc which leaves me 
> with the question of how to make a multithreaded server using stock xmlrpc.

berkley db (at least version 3, http://pybsddb.sourceforge.net/)
supports multiple readers and writers, with fine-grained locking, it
looks like a dictionary, and it isn't sql. The use you have in mind is a
bit more complicated than the simple create-me-a-dictionary-in-a-file,
but is pretty straightforward. The documentation mostly refers you to
the C API, but fortunately it (the C API) is clear and well written.

HTH

-- 
John Lenton ([EMAIL PROTECTED]) -- Random fortune:
Today is National Existential Ennui Awareness Day.


signature.asc
Description: Digital signature
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: rotor replacement

[Nick Craig-Wood]

Robin Becker <[EMAIL PROTECTED]> wrote:
>  Paul Rubin wrote:
> > "Reed L. O'Brien" <[EMAIL PROTECTED]> writes:
> > 
> >>I see rotor was removed for 2.4 and the docs say use an AES module
> >>provided separately...  Is there a standard module that works alike or
> >>an AES module that works alike but with better encryption?
> > 
> > 
> > If you mean a module in the distribution, the answer is no, for
> > political reasons.
> > 
>  .I'm also missing the rotor module and regret that something useful 
>  was warned about and now removed with no plugin replacement.
> 
>  I had understood that this was because rotor was insecure, but you 
>  mention politics. Are other useful modules to suffer from politics?
> 
>  What exactly are/were the political reasons for rotor removal?

Presumably he is talking about crypo-export rules.  In the past strong
cryptography has been treated as munitions, and as such exporting it
(especially from the USA) could have got you into very serious
trouble.

However I believe those restrictions have been lifted (the cat having
been let out of the bag somewhat ;-), and its easy to do this for open
source encryption software.  A wade through

  http://www.bxa.doc.gov/Encryption/enc.htm

Might be interesting.

A case in point: the linux 2.6 kernel is chock full of crypo and comes
with implementations of AES, ARC4, Blowfish, Cast5+6, DES, Serpent,
Twofish, TEA, etc.  The linux kernel+source surely goes everywhere
python does so I don't think adding strong crypto modules to python is
a problem now-a-days.

AES in the core python library would be very useful and it would
discourage people from writing their own crypto routines (looks easy
but isn't!)

-- 
Nick Craig-Wood <[EMAIL PROTECTED]> -- http://www.craig-wood.com/nick
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: how to find site-packages path (Michael Hoffman) - use distutils

[David Fraser]

Philippe C. Martin wrote:
I actually target Unix and windows so pyexe won't cut it I'm afraid -
same issue with Inno.
As far as the site-package target, I don't fully understand your
relunctancy. Just as my potential users might not own a compiler, they
might not be computer proficient enough to easily understand how to
change the sys.path. So until I have found a clean cross platform
solution I'm going to have to stick to site-packages.
Hi Philippe
You may want to have a look at 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=793070&group_id=5470

This was originally a patch to distutils which enabled removing the 
source (i.e. only distributing compiled files). I have now attached a 
file there which enables you to do the same thing, but without patching 
distutils - it just wraps functions etc from outside.

Basically you call allow_distutils_remove_source in the module and it 
does the neccessary changes. Then you get a --remove-source options to 
most of the commands. You can also selectively override what gets 
removed if you want by changing the is_removable function

I hope this is useful for what you're wanting to do
David
--
http://mail.python.org/mailman/listinfo/python-list

mod_python friendly isps in europe

[paulo . jpinto]

Hello everybody

I'm thinking about improving my web site scripts
and would like to use Python instead of PHP/Perl.

Does anyone know of mod_python friendly ISPs in
europe? With prices around 10€ ?

Thanks in advance,
Paulo

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

Re: wxPython and PyGame - do they play well together?

[Erik Bethke]

After a touch more of exploration... actually from the wxPython demo's
startup tips lead me over to the wxPython Wiki

Here I found this gem:

http://wiki.wxpython.org./index.cgi/IntegratingPyGame

Awesome.  There is in fact some very tricky timing of the import
statement for pygame

-Erik

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

Re: Dictionary keys (again) (was Re: lambda)

[Antoon Pardon]

Op 2005-01-19, Nick Coghlan schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>> A rule of thumb is context sensitive. If circumstances change,
>> so do the rules of thumb. Principles have a broader field
>> of application.
>> 
>> IMO there is nothing principally wrong with using a mutable object
>> as a dictionary key. But avoiding doing so is a good rule of
>> thumb if you have a python-like implementation of a dictionary.
>
> For a 'mutable key' to make sense, the following:

As you said yourself, people use shortcuts when they express themselves.
With 'mutable key' I mean a mutable object that is used as a key.
That doesn't contradict that the key itself can't change because
it is inaccessible.

> lst = []
> dct = {l: "Hi!"}
> print dct[[]]
> print dct[lst]
> lst.append(1)
> print dct[[1]]
> print dct[lst]
>
> Should print:
> Hi
> Hi
> Hi
> Hi

> That's completely impractical though - for any sane implementation, at least 
> one 
> of the above print statements will throw a KeyError.
>
> Your example of a 'safe_dict' that copies mutable keys means that the final 
> print statement is the one that fails.
>
> My suggestion of an "identity_dict" means that both of the same-value based 
> lookups would fail.
>
> Notice that both of these approaches take a mutable key and make it immutable 
> (either by holding the sole reference to a copy, or retrieving an immutable 
> property of the mutable object).
>
> There's also your solution of "I promise not to mutate the key while it is in 
> the dictionary". Workable, but opens the door to some entertaining bug hunts 
> when the promise is broken.

That is usually the case when promisses are broken. To mention something
different, I guess a number of equally entertaining bug hunts can be
caused by the fact that the value in the dictionary is changed.

> Which solution is the best default behaviour?

IMO a dictionary establisches a relationship between values. The most
general implementation that protects this relationship from external
tampering is copying the key and value for use in the dictionary.

> Well, the Zen of Python states "In the face of ambiguity, refuse the 
> temptation 
> to guess".

But python does guess in the case of the value. If I want to establish a
relationship between "foo" and [3, 5, 8] then I can be in big trouble
if that list gets mutated in something else.

> So that's the policy the builtin dict follows - it doesn't try to guess when 
> to 
> make a copy, or whether or not to use identity based semantics in the face of 
> mutability. Instead, it raises an exception at key entry time, asking the 
> programmer to clarify their intent.
>
> The principle is *certainly* that hash tables should contain immutable keys. 
> Your own 'safe_dict' example implicitly concedes this point by making copies 
> 'when required'. 'When required' for what? When required to preserve 
> immutability, perhaps?

But they don't have to be immutable within the dictionary itself, that
is just an implementation detail. The only thing that matters is that
the dictionary can reproduce the relationship. How that is done is
immaterial. 

> In short, sane hash tables require immutable keys, and how mutable keys 
> acquire 
> the requisite immutability is going to be application dependent.

No they don't, that is just the most easy implementation. If some
implementation would constantly change the internal objects but 
consulting the dictionary wouldn't show any different effect then
that would be fine too. And even in this case a mutation
from the outside would probably cause havoc because it would ruin
the sanity of the internal structure.

> Provision of a safe_dict or identity_dict would merely allow a programmer to 
> state their intent at the time the container is created, rather than having 
> to 
> state it whenever keys are generated or referenced.

Well that would be a good thing IMO. Good enough in any case for me to
spend some time analyzing the requirements. Whether I'll actually
implement something depends on how much time I have and how often I
need it.

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

Automatic response to your mail (Error)

[Webmaster]

The automatic reply to this e-mail which you should have
received in response to your e-mail to [EMAIL PROTECTED] has not been defined.

Please contact [EMAIL PROTECTED] for assistance.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: how to find site-packages path (Michael Hoffman) - use distutils/modified

[Philippe C. Martin]

Thanks David.

Philippe



>>Hi Philippe

>>You may want to have a look at 
>>https://sourceforge.net/tracker/?func=detail&atid=305470&aid=793070&group_id=5470

>>This was originally a patch to distutils which enabled removing the 
>>source (i.e. only distributing compiled files). I have now attached a 
>>file there which enables you to do the same thing, but without
patching 
>>distutils - it just wraps functions etc from outside.

>>Basically you call allow_distutils_remove_source in the module and it 
>>does the neccessary changes. Then you get a --remove-source options
to 
>>most of the commands. You can also selectively override what gets 
>>removed if you want by changing the is_removable function

>>I hope this is useful for what you're wanting to do

>>David
-- 
***
Philippe C. Martin
SnakeCard LLC
www.snakecard.com
***

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

Re: generator expressions: performance anomaly?

[Steve Holden]

Paul Rubin wrote:
Steve Holden <[EMAIL PROTECTED]> writes:
You probably already know that sensible compiled language systems have
used constant folding since time immemorial, but Python has always
eschewed it. That's what comes of being a pragmatist's language: if
such optimizations really are required the programmer is expected to
perform them.

You mean the lack is deliberate?  I just figured it was an artifact of
the implementation and that PyPy had some reasonable chance of fixing it.
No, it's not been deliberately omitted, it's just not a development 
priority. Pragmatic Python programmers are prepared to do the folding 
themselves in the (exceptionally rare) cases where it has a significant 
effect on performance.

PyPy may or may not fix it. And, of course, a dynamic language has 
rather less ability to take advantage of more advanced optimizations 
since it's much harder to guarantee functional behavior for any given 
subexpression. Once side effects rear their ugly heads all bets are off.

regards
 Steve
--
Steve Holden   http://www.holdenweb.com/
Python Web Programming  http://pydish.holdenweb.com/
Holden Web LLC  +1 703 861 4237  +1 800 494 3119
--
http://mail.python.org/mailman/listinfo/python-list

Re: lambda

[Antoon Pardon]

Op 2005-01-19, Nick Coghlan schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>   > I can be wrong, but until now I have seen no indication that I was
>> using mutable and immutable differently than other people. AFAICT
>> we all refer to whether an object belongs to a mutable or immutable
>> class.
>
> The difference is that when you take a copy of the key and stick it in the 
> dictionary, such that the dictionary now holds the *sole* reference to that 
> key, 
> you have made that key *effectively* immutable.
>
> This is why no-one really batted an eyelid when you mentioned that mutable 
> keys 
> can be used safely by making a copy - doing so makes the key *effectively* 
> immutable, and means that modifying the original key object (i.e. the 
> application's copy, not the dict's copy), and reusing it to look up in the 
> dictionary is likely to give a KeyError.
>
> These semantics would be understandably surprising to many users, and hence, 
> are 
> not supplied by default.

This seems like circle reasoning. The reason why these semantics would
be surprising is that those are not the semantics supplied.

> Additionally, a dictionary's keys are accessible via its API. Accordingly, to 
> preserve this 'effective immutability', making a copy on key input is 
> insufficient - keys must be copied on *output* as well (that is, dict.keys, 
> dict.items etc must return *copies* of the key objects, not the key objects 
> themselves).

Yes I haven been thinking about this too. I also think not making a copy
on output is less dangerous than not making a copy on input.

> Since there is no reliable way in Python to tell if an object is mutable or 
> not 
> (the closest equivalent is the presence of __hash__, which clearly can't be 
> used 
> in this example), this copying would need to be done for *every* object.
>
> Alternately, the dictionary can say to the API clients, "make an immutable 
> copy 
> and supply that instead. It is left to API clients to decide how best to make 
> the immutable version". The API client copies the key once (to make the 
> immutable version), and everyone lives happily ever after.
>
> For example:
>
> Py> class mylist(list):
> ...   def __init__(self, arg):
> ... super(mylist, self).__init__(arg)
> ... self._tuple = None
> ...   def frozen(self):
> ... if self._tuple is None:
> ...   self._tuple = tuple(self)
> ... return self._tuple
> ...   def unfreeze(self):
> ... self._tuple = None
> ...
> Py> x = mylist(range(10))
> Py> x
> [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
> Py> x.frozen()
> (0, 1, 2, 3, 4, 5, 6, 7, 8, 9)
> Py> x.append(10)
> Py> x.frozen()
> (0, 1, 2, 3, 4, 5, 6, 7, 8, 9)
> Py> x.unfreeze()
> Py> x.frozen()
> (0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10)
>
> This is much safer than having a list subclass that implements __hash__, and 
> still lets you avoid redundant copy operations.
>
> Nicely, so long as you don't unfreeze the object you used to key the 
> dictionary, 
>   reusing the same object will always get you the correct dictionary entry, 
> and 
> two lists that compare equal at the time they are frozen will also get you 
> the 
> same dictionary entry. The equivalent tuples can be used for the lookup, too.

Interesting idea. But I think you are wrong when you say that two lists
that compare equal at the time they are frozen, will get the same
dictionary entry. The problem is an object must compare equal to
the key in the dictionary to get at the same entry. So if you freeze
a list and its copy but then mutate them differently, they no longer
are equal and so wont get you at the same entry.

[ Rest snipped, this is getting into a semantic debate on what
  'mutable' means. This may be interesting enough on its own
  but I feel it detracts too much from what I consider the
  more important issue. ]

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

Re: safest way to kill a thread

[hoxide]

To Catch the "SystemExit"

import thread
from time import sleep
import sys

def t1():
try:
i=0
while 1:
print i+1
i += 1
sleep(1)
except SystemExit:
pass

thread.start_new_thread(t1, ())
sleep(3)


This Question was also asked in Python-chinese .

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

Zen of Python

[Timothy Fitz]

While I agree that the Zen of Python is an amazingly concise list of
truisms, I do not see any meaning in:

Flat is better than nested.

I strive for balance between flat and nested. Does anyone have a good
example of where this is applied? (specifically to python, or in
general)
-- 
http://mail.python.org/mailman/listinfo/python-list

Accessing MDB files on Windows

[Jorge Luiz Godoy Filho]

Hi,


What is the best way to deal with MDB files?  I was thinking on using
ODBC...  I'll need to read and write some information to it.  The load
won't be so high, but there might be a lot of data. 

Any advices?  Will my approach work?  I'm not a Windows guy... :-)

-- 
Godoy. <[EMAIL PROTECTED]>

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

Automatic Windows printer creation?

[GMane Python]

Anyone know if there's a module which will allow me to 'create' windows
printer definitions?  Not from a Windows domain network, but just to add a
printer that sends to a jet-direct-attached printer.

Thanks!
Dave



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

Re: Zen of Python

[Bill Mill]

The example that occurs to me is that "import smtplib" is better than
"import stdlib.inet.services.smtp".

Peace
Bill Mill
bill.mill at gmail.com 


On Wed, 19 Jan 2005 14:13:47 -0500, Timothy Fitz <[EMAIL PROTECTED]> wrote:
> While I agree that the Zen of Python is an amazingly concise list of
> truisms, I do not see any meaning in:
> 
> Flat is better than nested.
> 
> I strive for balance between flat and nested. Does anyone have a good
> example of where this is applied? (specifically to python, or in
> general)
> --
> http://mail.python.org/mailman/listinfo/python-list
>
-- 
http://mail.python.org/mailman/listinfo/python-list

ElementTree cannot parse UTF-8 Unicode?

[Erik Bethke]

Hello All,

I am getting an error of not well-formed at the beginning of the Korean
text in the second example.  I am doing something wrong with how I am
encoding my Korean?  Do I need more of a wrapper about it than simple
quotes?  Is there some sort of XML syntax for indicating a Unicode
string, or does the Elementree library just not support reading of
Unicode?

here is my test snippet:

from elementtree import ElementTree
vocabXML = ElementTree.parse('test2.xml').getroot()

where I have two data files:

this one works:





this one fails:





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

Re: Zen of Python

[Skip Montanaro]

Bill> The example that occurs to me is that "import smtplib" is better
Bill> than "import stdlib.inet.services.smtp".

Sure.  There is a balance to be achieved however.  "import std.smtplib"
might be better than "import smtplib", simply because making the standard
library a package reduces the possibility of namespace collisions.

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

Re: Accessing MDB files on Windows

[Jorge Luiz Godoy Filho]

Larry Bates, Quarta 19 Janeiro 2005 14:01, wrote:

> I'm assuming the application will be run on Windows.

You're right.  It will be run on Windows.  I discarded some other platform
due to the difficulty of supporting this file format.
 
> You can use ODBC or DAO.
> 
> An DAO solution that I wrote (and use) can be found
> at:
> 
> http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/303349

Thanks!  I'm looking at it. 

> For ODBC you would just use the standard library module.

Thanks.  I'll be trying the DAO first.

-- 
Godoy. <[EMAIL PROTECTED]>

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

Re: generator expressions: performance anomaly?

[Steve Holden]

Antoon Pardon wrote:
Op 2005-01-18, Steve Holden schreef <[EMAIL PROTECTED]>:
[...]
But you do have a point that I have a tendency to put salt on
any snail. I'll try to restrain myself a bit more in the future.
Finally! :-)
I find I like you much better after this reflective response. Thanks for 
taking the time to read my snarking and respond to it.

"A tendency to put salt on any snail" is a nice phrase I've never come 
across before. Is it specifically Belgian?

regards
 Steve
--
Steve Holden   http://www.holdenweb.com/
Python Web Programming  http://pydish.holdenweb.com/
Holden Web LLC  +1 703 861 4237  +1 800 494 3119
--
http://mail.python.org/mailman/listinfo/python-list

a question

[Nader Emami]

L.S.,
I have a long command in Unix and I have to use os.system(cmd) 
statement. I do the following:

cmd = '%s/mos user wmarch, cd /fa/wm/%s/%s, mkdir %s, put %s, chmod 644 
%s' % (mosbin, jaar, filetype, filetype)
status = os.system(cmd)

This is not very clear, and I have to break this long line in two 
segment by means of the next character '\' :
cmd = '%s/mos user wmarch, cd /fa/wm/%s/%s, mkdir %s, put %s, \
   chmod 644 %s' % (mosbin, jaar, filetype, filetype)

But in this case I get a syntax error! I don't know how I can solve this 
problem. Could somebody tell me about this?

With regards,
Nader
 (this
--
http://mail.python.org/mailman/listinfo/python-list

Re: Print to Windows default Printer

[Samantha]

Thanks Tim. I didn't realize it would be so difficult.
S

"Tim Golden" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED] 


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

RuntimeError: dictionary changed size during iteration

[Roman Suzi]

I think, the behaviour below is misfeature:

>>> [e for e in vars()]
Traceback (most recent call last):
  File "", line 1, in ?
RuntimeError: dictionary changed size during iteration
>>> e = None
>>> [e for e in vars()]
['e', '__builtins__', 'rlcompleter', '__file__', '_[1]', 'atexit', '__name__',
'readline', '__doc__']


Sincerely yours, Roman Suzi
-- 
[EMAIL PROTECTED] =\= My AI powered by GNU/Linux RedHat 7.3
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: ElementTree cannot parse UTF-8 Unicode?

[Fredrik Lundh]

Erik Bethke wrote:

> I am getting an error of not well-formed at the beginning of the Korean
> text in the second example.  I am doing something wrong with how I am
> encoding my Korean?  Do I need more of a wrapper about it than simple
> quotes?  Is there some sort of XML syntax for indicating a Unicode
> string, or does the Elementree library just not support reading of
> Unicode?

XML is Unicode, and ElementTree supports all common encodings just
fine (including UTF-8).

> this one fails:
> 
> 
>
> 

this works just fine on my machine.

what's the exact error message?

what does

print repr(open("test2.xml").read())

print on your machine?

what happens if you attempt to parse





?

 



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

Re: a question

[Bill Mill]

Nader,

You've got a couple problems. First, you need to end the string before
putting a continuation in. Secondly, you have 6 variables to be
substituted and only provide 4. Here's some code, edited to show how
to use continutations to join strings:

>>> mosbin, jaar, filetype = (1,1,1)
>>> cmd = '%s/mos user wmarch, cd /fa/wm/%s/%s, mkdir %s, put %s'\
... '%s' % (mosbin, jaar, filetype, filetype, filetype, filetype)
>>> cmd
'1/mos user wmarch, cd /fa/wm/1/1, mkdir 1, put 1, chmod 6441'

Peace
Bill Mill
bill.mill at gmail.com

On Wed, 19 Jan 2005 16:16:32 +, Nader Emami <[EMAIL PROTECTED]> wrote:
> L.S.,
> 
> I have a long command in Unix and I have to use os.system(cmd)
> statement. I do the following:
> 
> cmd = '%s/mos user wmarch, cd /fa/wm/%s/%s, mkdir %s, put %s, chmod 644
> %s' % (mosbin, jaar, filetype, filetype)
>  status = os.system(cmd)
> 
> This is not very clear, and I have to break this long line in two
> segment by means of the next character '\' :
> cmd = '%s/mos user wmarch, cd /fa/wm/%s/%s, mkdir %s, put %s, \
> chmod 644 %s' % (mosbin, jaar, filetype, filetype)
> 
> But in this case I get a syntax error! I don't know how I can solve this
> problem. Could somebody tell me about this?
> 
> With regards,
> Nader
> 
>   (this
> --
> http://mail.python.org/mailman/listinfo/python-list
>
-- 
http://mail.python.org/mailman/listinfo/python-list

RE: a question

[Sells, Fred]

I would use something like
cmd = '%s/mos user wmarch, ' % mosbin
cmd += 'cd /fa/wm/%s/%s, ' % (jaar, filetype)
cmd += ...
which reveals that you don't have enough args to satisfy all the %s's

-Original Message-
From: Nader Emami [mailto:[EMAIL PROTECTED]
--snip--
I have a long command in Unix and I have to use os.system(cmd) 
statement. I do the following:

cmd = '%s/mos user wmarch, cd /fa/wm/%s/%s, mkdir %s, put %s, chmod 644 
%s' % (mosbin, jaar, filetype, filetype)
 status = os.system(cmd)


This is not very clear, and I have to break this long line in two 
segment by means of the next character '\' :
cmd = '%s/mos user wmarch, cd /fa/wm/%s/%s, mkdir %s, put %s, \
chmod 644 %s' % (mosbin, jaar, filetype, filetype)

But in this case I get a syntax error! I don't know how I can solve this 
problem. Could somebody tell me about this?

With regards,
Nader


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

Re: RuntimeError: dictionary changed size during iteration

[Jack Diederich]

On Wed, Jan 19, 2005 at 11:45:15PM +0300, Roman Suzi wrote:
> 
> I think, the behaviour below is misfeature:
> 
> >>> [e for e in vars()]
> Traceback (most recent call last):
>   File "", line 1, in ?
> RuntimeError: dictionary changed size during iteration
> >>> e = None
> >>> [e for e in vars()]
> ['e', '__builtins__', 'rlcompleter', '__file__', '_[1]', 'atexit', '__name__',
> 'readline', '__doc__']
> 

Chalk it up as a lesson in the slightly different behavior of genexps

Python 2.4 (#2, Jan  8 2005, 20:18:03) 
[GCC 3.3.5 (Debian 1:3.3.5-5)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> list(e for e in vars())
['__builtins__', '__name__', '__doc__']
>>> [e for e in vars()]
Traceback (most recent call last):
  File "", line 1, in ?
RuntimeError: dictionary changed size during iteration

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

Re: Has apparent 2.4b1 bug been fixed? flatten in Lib\compiler\ast.py overloads 'list' name

[Larry Bates]

You have name clashing between Python's built in list function
and the variable called list that you pass into the function.
Change the passed in variable name to something else.
Larry Bates
Try something like (not tested):
def flatten(seq):
l = []
for elt in seq:
if isinstance(elt, (list, tuple):
for elt2 in flatten(elt):
l.append(elt2)
else:
l.append(elt)
return l

Bengt Richter wrote:
What am I missing? (this is from 2.4b1, so probably it has been fixed?)
def flatten(list):
l = []
for elt in list:
   --must be expecting list instance or other sequence
t = type(elt)
if t is tuple or t is list:
  --looks like it expects to refer to the type, 
not the arg
for elt2 in flatten(elt):
l.append(elt2)
else:
l.append(elt)
return l
Regards,
Bengt Richter
--
http://mail.python.org/mailman/listinfo/python-list

Re: a question

[Fredrik Lundh]

Bill Mill wrote:

> You've got a couple problems. First, you need to end the string before
> putting a continuation in.

>>> "no\
... pe"
'nope'

>>> "however\
  File "", line 1
"however\
 ^
SyntaxError: EOL while scanning single-quoted string

(in the second case, the ^ is trying to point out that I added
some whitespace after the backslash)

 



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

Re: a question

[Bill Mill]

You are correct, sir. Didn't know you could do that. Neato.

Peace
Bill Mill
bill.mill at gmail.com

On Wed, 19 Jan 2005 22:10:05 +0100, Fredrik Lundh
<[EMAIL PROTECTED]> wrote:
> Bill Mill wrote:
> 
> > You've got a couple problems. First, you need to end the string before
> > putting a continuation in.
> 
> >>> "no\
> ... pe"
> 'nope'
> 
> >>> "however\
>   File "", line 1
> "however\
>  ^
> SyntaxError: EOL while scanning single-quoted string
> 
> (in the second case, the ^ is trying to point out that I added
> some whitespace after the backslash)
> 
> 
> 
> --
> http://mail.python.org/mailman/listinfo/python-list
>
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Zen of Python

[Mark McEahern]

Timothy Fitz wrote:
While I agree that the Zen of Python is an amazingly concise list of
truisms, I do not see any meaning in:
Flat is better than nested.
I strive for balance between flat and nested. Does anyone have a good
example of where this is applied? (specifically to python, or in
general)
One example would be using a function instead of a class when a function 
does the job at the module level.  Using the appropriate degree of 
abstraction/indirection.

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

RE: Accessing MDB files on Windows

[Robert Brewer]

Jorge Luiz Godoy Filho wrote:
> What is the best way to deal with MDB files?  I was thinking on using
> ODBC...  I'll need to read and write some information to it.  The load
> won't be so high, but there might be a lot of data. 
> 
> Any advices?  Will my approach work?  I'm not a Windows guy... :-)

Use ADO unless you need to support older versions of Windows. It'll be a
lot faster and cleaner than ODBC.


Robert Brewer
MIS
Amor Ministries
[EMAIL PROTECTED]
--
http://mail.python.org/mailman/listinfo/python-list

RE: RuntimeError: dictionary changed size during iteration

[Robert Brewer]

Roman Suzi wrote:
> I think, the behaviour below is misfeature:
> 
> >>> [e for e in vars()]
> Traceback (most recent call last):
>   File "", line 1, in ?
> RuntimeError: dictionary changed size during iteration
> >>> e = None
> >>> [e for e in vars()]
> ['e', '__builtins__', 'rlcompleter', '__file__', '_[1]', 
> 'atexit', '__name__',
> 'readline', '__doc__']

But not unexpected, since vars() returns a dictionary, and binding 'e'
changes that dictionary while you are iterating over it. Try either:

[e for e in vars().keys()]

or

e = None
[e for e in vars()]

or the generator expression if you have Python 2.4.


Robert Brewer
MIS
Amor Ministries
[EMAIL PROTECTED]
--
http://mail.python.org/mailman/listinfo/python-list

Re: generator expressions: performance anomaly?

[Antoon Pardon]

Op 2005-01-19, Steve Holden schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>
>> Op 2005-01-18, Steve Holden schreef <[EMAIL PROTECTED]>:
> [...]
>> 
>> But you do have a point that I have a tendency to put salt on
>> any snail. I'll try to restrain myself a bit more in the future.
>> 
> Finally! :-)
>
> I find I like you much better after this reflective response. Thanks for 
> taking the time to read my snarking and respond to it.
>
> "A tendency to put salt on any snail" is a nice phrase I've never come 
> across before. Is it specifically Belgian?

It is a literal translation of a dutch idiom: "Op alle slakken zout
leggen". Most people in Belgium speak dutch although foreigner often
seem to think we all speak native French.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: simultaneous multiple requests to very simple database

[Tim Jarman]

Olaf Zetanien wrote:


> 
> Use Firebird as sql backend. Is designed as you request (readers not lock
> writers and writers not lock readers). Google for "firebird optimistic
> lock".
> 
> Off course, you have python driver: http://kinterbasdb.sf.net and can
> deploy on windows and linux with a very little footprint.
> 

And OS X. But it fails the OP's "no SQL" test.

-- 
Website: www DOT jarmania FULLSTOP com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: [OT] Good C++ book for a Python programmer

[Philippe C. Martin]

I suggest you google 'C++ tutorial'

Regards,

Philippe



On Wed, 19 Jan 2005 04:08:16 -0800, [EMAIL PROTECTED] wrote:

> I'm picking up C++ again after years of using almost nothing but
> Python. I'm frankly enjoying the experience, and it's certainly
> deepening my appreciation of Python (which you can read however you
> like).
> 
> I was wondering whether anyone could recommend a good C++ book, with
> "good" being defined from the perspective of a Python programmer. I
> realize that there isn't a book titled "C++ for Python Programmers",
> but has anyone found one that they think goes particularly well with
> the Python way?
> 
> I'm asking this because evidently the C++ standard has changed a bit
> since 1994, when I bought my books. Who knew that fstream was
> deprecated?
> 
> Thanks in advance...

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

Re: [OT] Good C++ book for a Python programmer

[John Hunter]

> "Philippe" == Philippe C Martin <[EMAIL PROTECTED]> writes:

Philippe> I suggest you google 'C++ tutorial' Regards,

Stroustup's "The C++ Programming Language" is the best C++ book I've
read.  It is at a fairly high level, and I already had read several
C++ books before reading it, so it may be tough sledding.  But I would
try this first since you are an experienced programmer and know OO
concepts, and if it fails to satisfy try something lighter.
Unfortunately, I didn't like any of the other kinder, gentler overview
books I read on C++, so can't really recommend anything along those
lines, though I'm sure they are out there.

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

Re: delay and force in Python

[Dave Benjamin]

Will Stuyvesant wrote:
. def delay(exp): return lambda: exp
If you look at the definition of "delay" in SICP, you'll notice that 
it's defined as "syntax sugar", in other words, a macro. Since Python 
does not have macros, you'll have to just use "lambda", because by 
defining "delay" as a function, you're forcing the expression "exp" to 
evaluate immediately. In other words, theres a crucial difference between::

  delay(sys.stdout.write('evaluated\n'))
and::
  lambda: sys.stdout.write('evaluated\n')
If you type in those two snippets, you'll see what I mean.
Coincidentally, I attempted a similar experiment just a couple of days 
ago, and here's what I came up with::

   # Stream.py - Stream class inspired by SICP
class Stream(object):
pass
class EndOfStream(Exception):
pass
class Item(Stream):
def __init__(self, current, nextf):
self.current = current
self.nextf = nextf
next = property(lambda self: self.nextf())
def fold(self, f, init):
return f(self.current, self.next.fold(f, init))
def __getitem__(self, n):
if n == 0:
return self.current
else:
return self.next[n - 1]
def __str__(self):
return '' % self.current
__repr__ = __str__
class End(Stream):
def fold(self, f, init):
return init
def __getitem__(self, n):
raise EndOfStream()
def _fail(self):
raise EndOfStream()
current = property(_fail)
next = property(_fail)
def __str__(self):
return ''
__repr__ = __str__
Here's how it works::
Python 2.4 (#1, Dec  4 2004, 20:10:33)
[GCC 3.3.3 (cygwin special)] on cygwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import Stream
>>> s = Stream.Item(1, lambda: Stream.Item(2, lambda: Stream.End()))
>>> s

>>> s.current
1
>>> s.next

>>> s.next.current
2
>>> s.next.next

>>> s.next.next.next
Traceback (most recent call last):
  File "", line 1, in ?
  File "Stream.py", line 37, in _fail
raise EndOfStream()
Stream.EndOfStream
>>> def evens(n=0):
... return Stream.Item(n, lambda: evens(n + 2))
...
>>> s = evens()
>>> s.current
0
>>> s.next.current
2
>>> s.next.next.current
4
I don't know if this is useful or not, but it was an interesting 
exercise nonetheless.

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

[ANN] XPN - X Python Newsreader 0.4.0 released

[Nemesis]

XPN is a multiplatform newsreader written in Python+GTK2. It is unicode
compliant and has features like scoring/action rules, configurable
attribution lines and random taglines, search facilities and filtered
views, import/export newsrc ...

You can find it on:

http://xpn.altervista.org/index-en.html
or
http://sf.net/projects/xpn

I'd really appreciate every type of feedback.

Changes in this release:

* v0.4.0: added off-line reading. Now you can download the whole bodies, or 
mark
  some article and download their bodies.
* v0.4.0: added Keep Article and Watch/Ignore SubThread
* v0.4.0: added actions rule, now you can !keep, !watch, !ignore (and so 
on) your
  article through rules
* v0.4.0: now XPN stores the position and the size of Main Window and Edit 
Window
* v0.4.0: now you can customize the charsets list XPN use to encode your 
outgoing
  articles
* v0.4.0: improved speed when loading groups list in Groups Window.
* v0.4.0: fixed a bug in the binary version that caused a crash trying to 
subscribe
  a group
* v0.4.0: added Oriental Charsets support (thanks to Python2.4)
* v0.4.0: added Global Search, you can search the whole groups and put the 
results
  in a virtual group
* v0.4.0: added filtered views
* v0.4.0: moved to GTK2.4 and Python2.4
* v0.4.0: added a TraceBack viewer and an error logger
* v0.4.0: reorganized some menus
* v0.4.0: now the background color is changed also on Groups Pane and 
Headers pane
* v0.4.0: added a lot of little features/enhancements
* v0.4.0: fixed a lot of bugs
-- 
I'm not a complete idiot - several parts are missing.
 
 |\ |   |HomePage   : http://nem01.altervista.org
 | \|emesis |XPN (my nr): http://xpn.altervista.org

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

Re: Accessing MDB files on Windows

[Larry Bates]

I'm assuming the application will be run on Windows.
You can use ODBC or DAO.
An DAO solution that I wrote (and use) can be found
at:
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/303349
For ODBC you would just use the standard library module.
Larry Bates
Syscon, Inc.
Jorge Luiz Godoy Filho wrote:
Hi,
What is the best way to deal with MDB files?  I was thinking on using
ODBC...  I'll need to read and write some information to it.  The load
won't be so high, but there might be a lot of data. 

Any advices?  Will my approach work?  I'm not a Windows guy... :-)
--
http://mail.python.org/mailman/listinfo/python-list

Re: a question

[Steve Holden]

Nader Emami wrote:
L.S.,
I have a long command in Unix and I have to use os.system(cmd) 
statement. I do the following:

cmd = '%s/mos user wmarch, cd /fa/wm/%s/%s, mkdir %s, put %s, chmod 644 
%s' % (mosbin, jaar, filetype, filetype)
status = os.system(cmd)

This is not very clear, and I have to break this long line in two 
segment by means of the next character '\' :
cmd = '%s/mos user wmarch, cd /fa/wm/%s/%s, mkdir %s, put %s, \
   chmod 644 %s' % (mosbin, jaar, filetype, filetype)

But in this case I get a syntax error! I don't know how I can solve this 
problem. Could somebody tell me about this?

The error you get is NOT a syntax error:
 >>> cmd = '%s format %s \
 ... over %d lines' % ('my', 'string', 2)
 >>> cmd
'my format string over 2 lines'
 >>>
The interpreter is probably complaining because it needs six values to 
fill out the format and you only provided four.

In future, by the way, always include the error message in such posts!
regards
 Steve
--
Steve Holden   http://www.holdenweb.com/
Python Web Programming  http://pydish.holdenweb.com/
Holden Web LLC  +1 703 861 4237  +1 800 494 3119
--
http://mail.python.org/mailman/listinfo/python-list

Re: Solutions for data storage?

[Pat]

Leif K-Brooks wrote:
> I'm writing a relatively simple multi-user public Web application
with
> Python. It's a rewrite of a similar application which used PHP+MySQL
> (not particularly clean code, either). My opinions on various Web
> frameworks tends to vary with the phase of the moon, but currently,
I'm
> planning to use Quixote.
>
> Needless to say, my application will need some kind of persistent
data
> storage. The previous PHP+MySQL application uses around 1.1GB of
> storage, so something like PyPerSyst where everything is kept in
memory
> is out.

You might want to look at Schevo (http://schevo.org), an ODBMS and
application development framework.  Schevo builds on some of the
concepts introduced in Pypersyst, and can use Pypersyst as its backend
storage, but it can also use ZODB and Durus (and it is easy to switch
between backends).  Schevo provides schema evolution and migration
features, enforces referential integrity and field constraints,
enforces unique indexes (whether single field or multiple field keys),
etc.  All you have to do is describe your objects using a simple syntax
such as this snippet from a weblog application that we are putting
together as an example:

class Author:
"""Authors write posts."""

name = f.string()
password = f.hashedValue()
email = f.string()

_key(name)

_icon('.apps.kuser')

def __str__(self):
return self.name


class Post:
"""Posts contain content posted to the weblog."""

slug = f.string(doc='The short name that appears in the URL.')
title = f.string()
published = f.datetime()
author = f.entity(allow=Author)
excerpt = f.memo()
content = f.memo()

_key(slug)

_icon('.filesystems.desktop')

def __str__(self):
return self.slug


Schevo might not be quite ready for your particular needs, but the
situation you describe is the target for Schevo.  While most of our UI
work has been with Qt, our next focus is on Nevow, which we have used
in the past on a predecessor to what is now Schevo.  I've used Quixote
in the past, but I'm not sure how easy it would be to use it as the UI
for a Schevo app.  Most of our short-term efforts are going to be
concentrated on Nevow and Plone for web applications, and Qt for GUI
apps (and hopefully wxPython at some point).

Matthew Scott and I will be giving a Schevo presentation at PyCon on
the subject of "Developing Database Applications With Schevo".  You can
read our outline at http://schevo.org/doc/pycon2005/proposal.

Good luck with your project.

--
Patrick K. O'Brien
Orbtechhttp://www.orbtech.com
Schevo http://www.schevo.org
Pypersyst  http://www.pypersyst.org

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

Re: python/cgi/html bug

[Dfenestr8]

On Wed, 19 Jan 2005 04:32:04 -0800, Fuzzyman wrote:

> This looks very good.
> I've been looking for a python messageboard CGI for a long time.
> 

Thanx!

No glaring security holes that you noticed? Other than being able to hide
things in html tags?

> If you wanted to add user accounts/login/admin etc. you could use 'Login
> Tools'. This is a python module built especially to do that. It also
> provides a convenient way of saving user preferences etc.
> 
> http://www.voidspace.org.uk/python/logintools.html
> 
> If you want any help using it then feel free to ask.
> 
> Regards,

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

Re: Accessing MDB files on Windows

[Jorge Luiz Godoy Filho]

Steve Holden, Quarta 19 Janeiro 2005 14:38, wrote:

> Note that DAO is a very old library, and nowadays ADO would probably be
> the preferred method in the Windows environment (can DAO even *use*
> oledb providers?). ADO libraries are available - see
> 
>http://www.markcarter.me.uk/computing/python/ado.html
> 
> for example, or Google for "python ado". Bottom line, there are many
> ways to skin this particular cat.

Hmmm...   I see.  I'm trying to avoid having to install external modules at
my client's server.  Should I use, given that both DAO and ODBC are
available with the win32all extensions, DAO or ODBC?

Or would ADO give me so much more performance that I should really use it?

-- 
Godoy. <[EMAIL PROTECTED]>

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

Re: Accessing MDB files on Windows

[Steve Holden]

Jorge Luiz Godoy Filho wrote:
Larry Bates, Quarta 19 Janeiro 2005 14:01, wrote:

I'm assuming the application will be run on Windows.

You're right.  It will be run on Windows.  I discarded some other platform
due to the difficulty of supporting this file format.
 

You can use ODBC or DAO.
An DAO solution that I wrote (and use) can be found
at:
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/303349

Thanks!  I'm looking at it. 


For ODBC you would just use the standard library module.

Thanks.  I'll be trying the DAO first.
Note that DAO is a very old library, and nowadays ADO would probably be 
the preferred method in the Windows environment (can DAO even *use* 
oledb providers?). ADO libraries are available - see

  http://www.markcarter.me.uk/computing/python/ado.html
for example, or Google for "python ado". Bottom line, there are many 
ways to skin this particular cat.

regards
 Steve
--
Steve Holden   http://www.holdenweb.com/
Python Web Programming  http://pydish.holdenweb.com/
Holden Web LLC  +1 703 861 4237  +1 800 494 3119
--
http://mail.python.org/mailman/listinfo/python-list

Re: Solutions for data storage?

[Pat]

Posting using Google Groups messed up the formatting of those class
definition examples.  Assume that they contain the usual indentation of
typical class definitions.  ;-)

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

Re: a question

[Steve Holden]

Will Stuyvesant wrote:
Andrew Koenig wrote:
how about writing this instead?
   ('this is a '
'long string')

Yes, nice.  And to make that possible we have to write
('one-string-item',) instead of ('one-string-item') if we want a tuple
with one string inside.  Sometimes that feels like a wart to me, but
now I know it, sometimes not.
That has very little to do with tuples. You could just as easily write
'this is a '\
'long string'
It's the dangling comma that's required to specify a tuple:
 >>> 1,
(1,)
 >>>
regards
 Steve
--
Steve Holden   http://www.holdenweb.com/
Python Web Programming  http://pydish.holdenweb.com/
Holden Web LLC  +1 703 861 4237  +1 800 494 3119
--
http://mail.python.org/mailman/listinfo/python-list

Re: Accessing MDB files on Windows

[Jorge Luiz Godoy Filho]

Jorge Luiz Godoy Filho, Quarta 19 Janeiro 2005 14:25, wrote:

> Thanks!  I'm looking at it.

Worked like a charm!  And just now I noticed who's the author of the
recipe ;-)


Thanks!
-- 
Godoy. <[EMAIL PROTECTED]>

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

Re: [OT] Good C++ book for a Python programmer

[beliavsky]

Rick Muller wrote:
>I was wondering whether anyone could recommend a good C++ book, with
>"good" being defined from the perspective of a Python programmer.

The STL and the template feature of C++ gives the programmer some of
the functionality of Python (using templates instead of duck typing,
vectors instead of lists etc.), so a book that introduces these
features early, such as "Accelerated C++" by Koenig and Moo, could be a
good start for a Pythonner. The 4th edition of the well-known "C++
Primer", with Moo as a new co-author, will soon be published. It is a
more comprehensive and much longer book.

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

Re: [OT] Good C++ book for a Python programmer

[Thomas Bartkus]

<[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> I'm picking up C++ again after years of using almost nothing but
> Python. I'm frankly enjoying the experience, and it's certainly
> deepening my appreciation of Python (which you can read however you
> like).
>
Gad!  After Python, how can you stand it (C++) ?
Adding object oriented utility to the C language was an atrocity, albeit
perhaps a necessary one given the state of the art when that particular
atrocity was committed. Aren't we past this?

If it is fast, fully compiled code you seek - couldn't you just C a few slow
functions and use them in your Python?

Thomas Bartkus


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

Re: simultaneous multiple requests to very simple database

[Olaf Zetanien]

On Tue, 18 Jan 2005 12:57:21 -0500, Eric S. Johansson <[EMAIL PROTECTED]>  
wrote:

Robert Brewer wrote:
Eric S. Johansson wrote:
I have an application where I need a very simple database, effectively  
a very large dictionary.  The very large
dictionary must be accessed from multiple processes
simultaneously.  I need to be able to lock records within
the very large dictionary when records are written to.
  Just to clarify, you want shared-read until a write, at which point  
you
want to lock just the item being written? Or would page or table locking
be acceptable at that point?
just the item/record.  I'm doing arrival rate calculations.  each record  
contains a set of arrival times and I am rewriting the record every time  
a new entry arrives.  complete page or table locking will work in the  
sense that it will prevent collisions but it will have an increasing  
impact as load and simultaneous table but not record accesses increase.

---eric
Use Firebird as sql backend. Is designed as you request (readers not lock  
writers and writers not lock readers). Google for "firebird optimistic  
lock".

Off course, you have python driver: http://kinterbasdb.sf.net and can  
deploy on windows and linux with a very little footprint.

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

Re: How to fill available screen size then scroll

[Mudcat]

bump

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

Re: simultaneous multiple requests to very simple database

[Jeremy Sanders]

On Tue, 18 Jan 2005 11:26:46 -0500, Eric S. Johansson wrote:

> So the solutions that come to mind are some form of dictionary in shared
> memory with locking semaphore scoreboard or a multithreaded process
> containing a single database (Python native dictionary, metakit, gdbm??)
> and have all of my processes speak to it using xmlrpc which leaves me
> with the question of how to make a multithreaded server using stock
> xmlrpc.

Another solution might be to store the records as files in a directory,
and use file locking to control access to the files (careful over NFS!).

You might also consider berkeley db, which is a simple database to add to
an application, (and which I believe supports locks), but I must admit I'm
not a fan of the library.

I assume that the bottleneck is processing the records, otherwise this all
seems a bit academic.

Jeremy

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

Re: Dictionary keys (again) (was Re: lambda)

[Steven Bethard]

David Eppstein wrote:
In article <[EMAIL PROTECTED]>,
 Nick Coghlan <[EMAIL PROTECTED]> wrote:

For a 'mutable key' to make sense, the following:
lst = []
dct = {l: "Hi!"}
print dct[[]]
print dct[lst]
lst.append(1)
print dct[[1]]
print dct[lst]
Should print:
Hi
Hi
Hi
Hi

Yes, and what should the following do?
lst1 = [1]
lst2 = [2]
dct = {lst1: "1", lst2: "2"}
lst2[0]=1
lst1[0]=2
print dct[[1]]
print dct[[2]]
Depends on when you want the updates done.  Since my implementation only 
rehashes when the dict is accessed, neither key gets overwritten in this 
case:

py> class sillylist(list):
... def __hash__(self):
... return hash(tuple(self))
...
py> class sillydict(dict):
... def _rehash(self):
... items = self.items()
... self.clear()
... self.update(items)
... def __getitem__(self, key):
... self._rehash()
... return super(sillydict, self).__getitem__(key)
... def __setitem__(self, key, value):
... self._rehash()
... return super(sillydict, self).__setitem__(key, value)
...
py> lst1 = sillylist([1])
py> lst2 = sillylist([2])
py> dct = sillydict({lst1:"1", lst2:"2"})
py> lst2[0] = 1
py> lst1[0] = 2
py> print dct[sillylist([1])]
2
py> print dct[sillylist([2])]
1
The nastier question is, what should the following code do:
lst1 = [1]
lst2 = [2]
dct = {lst1: "1", lst2: "2"}
lst2[0]=1
print dct[[1]]
print dct[[2]]
My implementation does the following:
py> lst1 = sillylist([1])
py> lst2 = sillylist([2])
py> dct = sillydict({lst1:"1", lst2:"2"})
py> lst2[0] = 1
py> print dct[sillylist([1])]
1
py> print dct[sillylist([2])]
Traceback (most recent call last):
  File "", line 1, in ?
  File "", line 8, in __getitem__
KeyError: [2]
which is even sillier when you compare to what happens with the original 
code you posted. ;)

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

Re: a question

[Andrew Koenig]

"Steve Holden" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]

> The error you get is NOT a syntax error:
>
>  >>> cmd = '%s format %s \
>  ... over %d lines' % ('my', 'string', 2)
>  >>> cmd
> 'my format string over 2 lines'
>  >>>
>
> The interpreter is probably complaining because it needs six values to 
> fill out the format and you only provided four.

Also, I'm dubious about the idea of splitting a string literal across 
multiple lines, as it's impossible to indent such a literal nicely without 
putting stray spaces into its contents.  So instead of writing

'this is a\
 long string'

and not making it clear how many spaces you intend between 'a' and 'long', 
how about writing this instead?

('this is a '
 'long string')

in which the contents are not in doubt.  This code takes advantage of two 
properties of Python:

1) Multiple string literals with only whitespace between them are 
automatically concatenated;

2) Ending a line inside unbalanced parentheses implicitly makes the next 
line part of the same statement.


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

Re: delay and force in Python

[Will Stuyvesant]

Yes you are right, if you just want to carry an expression
around then lambda does it; but delay was not intended as a
top-level function.  Perhaps you think that my silly stream
implementation in the original post builds the whole list,
but it does not:

>>> o = stream_enumerate_interval(11,121)
>>> print o
[11,  at 0x00BA8670>]
>>> f = o[1]
>>> r = f()
>>> print r
[12,  at 0x00BA86B0>]

instead it builds a list of lambda's, and that is so
desirable 


Others suggested generators indeed, and I can imagine now a
usage pattern like

>>> s = stream_generator(initValue, next, stop, other_params)
>>> stream_hd(stream_tl(stream_filter(isEven,s)))

where the idea is to pass a generator to a function all the
time.  What I don't like though is that I then, as I
understand it, have to code some for-loop inside that
function, I try to avoid for-loops.  But a functional form
defined with a for-loop does not seem all that bad.  Anyway
I have some reading-up to do, about things some posters use
and I forgot to keep up with since I have been coding Python
1.5.2 style for ages now: properties, itertools, ...printed
some stuff already, thanks!

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

Re: [OT] Good C++ book for a Python programmer

[Paul Rubin]

"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> writes:
> I was wondering whether anyone could recommend a good C++ book, with
> "good" being defined from the perspective of a Python programmer. I
> realize that there isn't a book titled "C++ for Python Programmers",
> but has anyone found one that they think goes particularly well with
> the Python way?

I think it's not possible to really grok C++ without having worked on
large multi-person C projects and understood what problems C++ tried
to solve.  The only good book I know about C++ is by Stroustrup, "The
C++ Programming Language" or something like that; it's not an easy
book though.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Has apparent 2.4b1 bug been fixed? flatten in Lib\compiler\ast.py overloads 'list' name

[Steve Holden]

Larry Bates wrote:
You have name clashing between Python's built in list function
and the variable called list that you pass into the function.
Change the passed in variable name to something else.
I believe Bengt was merely seeking confirmation that this was indeed a 
bug in a distributed library (which he then provided himself by finding 
a bug report). Hence his use of the phrase "overloads 'list' name" in 
the subject line!

regards
 Steve
--
Steve Holden   http://www.holdenweb.com/
Python Web Programming  http://pydish.holdenweb.com/
Holden Web LLC  +1 703 861 4237  +1 800 494 3119
--
http://mail.python.org/mailman/listinfo/python-list

Re: generator expressions: performance anomaly?

[Raymond Hettinger]

[Steve Holden]
> Since it doesn't yet optimize 2+5 to a constant-folded 7 you should
> realize that you are suggesting a large increase in the compiler's
> analytical powers.

FWIW, limited constant folding is already in CVS for Py2.5.



Raymond Hettinger


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

Re: finding/replacing a long binary pattern in a .bin file

[yaipa]

Thanks Francois,

It worked as expected.
---
source_data  = open("source_data.bin", 'rb').read()
search_data  = open("search_data.bin", 'rb').read()
replace_data = open("replace_data.bin", 'rb').read()
outFile  = open("mod.bin", 'wb')

file_offset = source_data.find(search_data)
print "file_offset:", file_offset

outData = source_data.replace(search_data, replace_data)
outFile.write(outData)
outFile.close
print ""

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

Re: finding/replacing a long binary pattern in a .bin file

[yaipa]

Bengt,

Thanks for the input, sorry, your diff threw me the first time I looked
at it, but then I went back and tried it later.  Yes it works fine and
I've tucked it away for later use.  For this particular Use Case
String.replace seems to get the job done in short order and the tool
needs to be maintained by folks not familiar /w Python so I went a head
and used that. But, I image I will use this bit of code when I need a
finer grained tool.

Thanks again.
Cheers,

  --Alan

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

Re: Dictionary keys (again) (was Re: lambda)

[Steven Bethard]

Nick Coghlan wrote:
For a 'mutable key' to make sense, the following:
lst = []
dct = {l: "Hi!"}
print dct[[]]
print dct[lst]
lst.append(1)
print dct[[1]]
print dct[lst]
Should print:
Hi
Hi
Hi
Hi
And here's an implementation that does so:
py> class sillydict(dict):
... def __getitem__(self, key):
... items = self.items()
... self.clear()
... self.update(items)
... return super(sillydict, self).__getitem__(key)
...
py> class sillylist(list):
... def __hash__(self):
... return hash(tuple(self))
...
py> lst = sillylist([])
py> dct = sillydict({lst: "Hi!"})
py> print dct[sillylist([])]
Hi!
py> print dct[lst]
Hi!
py> lst.append(1)
py> print dct[sillylist([1])]
Hi!
py> print dct[lst]
Hi!
Of course, as noted by the classes themselves, they're silly. ;)  But as 
long as you don't mind rehashing the dict each time the dict is accessed 
;) you can get sane behavior even in the presence of mutable keys.

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

ANN: Free Trac/Subversion hosting at Python-Hosting.com

[Remi Delon]

Hello everyone,

To celebrate its second anniversary,
Python-Hosting.com is happy to announce
that it is now offering free Trac/Subversion hosting.
This offer is limited to open-source, python projects.

Trac and Subversion make a great combination for project
management. More information about Trac can be found
here: http://www.edgewall.com/trac

The free offer includes:
- Your own Trac site with HTTP and HTTPS access
- Your own Subversion repository with HTTP and HTTPS access
- Access to trac-admin through a web interface
- Access to Trac and Subversion user configuration through a web interface
- Web usage statistics of your Trac site
- Nightly backups of your data to external servers

If you want to know more about this offer and find out how to sign up,
check out the following page: http://www.python-hosting.com/freetrac

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

Re: Zen of Python

[Steve Holden]

Peter Hansen wrote:
Timothy Fitz wrote:
While I agree that the Zen of Python is an amazingly concise list of
truisms, I do not see any meaning in:
Flat is better than nested.
[incrdeibly secret PSU facts blurted out]
And with that out of the way, one is left with "there's a balance
along the flat/nested dimension which is appropriate to any
given situation, so nest with moderation and only when necessary".
They'd probably been talking to Antoon Pardon :-)
But that didn't fit in the list so they went with the shorter version...
regards
 Steve
--
Steve Holden   http://www.holdenweb.com/
Python Web Programming  http://pydish.holdenweb.com/
Holden Web LLC  +1 703 861 4237  +1 800 494 3119
--
http://mail.python.org/mailman/listinfo/python-list

Re: finding/replacing a long binary pattern in a .bin file

[yaipa]

John,

Thanks for reminding me of the mmap module.  The following worked as
expected.
#
import mmap

source_data = open("source_file.bin", 'rb').read()
search_data = open("search_data.bin", 'rb').read()
replace_data = open("replace_data.bin", 'rb').read()

# copy source.bin to modified.bin
open("modified.bin", 'wb').write(open("source_file.bin", 'rb').read())

fp = open("modified.bin", 'r+')
mm = mmap.mmap(fp.fileno(), 0)

start_addr = mm.find(search_data)
end_addr =  start_addr + len(replace_data)
mm[start_addr:end_addr] = replace_data

mm.close()
#

Although, I choose impliment string method approach in the build tool
because there are two occurances of *Pattern* in the .bin file to be
updated and the string method did both in one shot.

Cheers,

--Alan


John Lenton wrote:
> On Wed, Jan 12, 2005 at 10:36:54PM -0800, yaipa wrote:
> > What would be the common sense way of finding a binary pattern in a
> > .bin file, say some 200 bytes, and replacing it with an updated
pattern
> > of the same length at the same offset?
> >
> > Also, the pattern can occur on any byte boundary in the file, so
> > chunking through the code at 16 bytes a frame maybe a problem.  The
> > file itself isn't so large, maybe 32 kbytes is all and the need for
> > speed is not so great, but the need for accuracy in the
> > search/replacement is very important.
>
> ok, after having read the answers, I feel I must, once again, bring
> mmap into the discussion. It's not that I'm any kind of mmap expert,
> that I twirl mmaps for a living; in fact I barely have cause to use
it
> in my work, but give me a break!  this is the kind of thing mmap
> *shines* at!
>
> Let's say m is your mmap handle, a is the pattern you want to find,
> b is the pattern you want to replace, and n is the size of both a and
> b.
>
> You do this:
>
>   p = m.find(a)
>   m[p:p+n] = b
>
> and that is *it*. Ok, so getting m to be a mmap handle takes more
work
> than open() (*) A *lot* more work, in fact, so maybe you're justified
> in not using it; some people can't afford the extra
>
>   s = os.stat(fn).st_size
>   m = mmap.mmap(f.fileno(), s)
>
> and now I'm all out of single-letter variables.
>
> *) why isn't mmap easier to use? I've never used it with something
> other than the file size as its second argument, and with its access
> argument in sync with open()'s second arg.
>
> --
> John Lenton ([EMAIL PROTECTED]) -- Random fortune:
> If the aborigine drafted an IQ test, all of Western civilization
would
> presumably flunk it.
>   -- Stanley Garn

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

Re: Accessing MDB files on Windows

[Jorge Luiz Godoy Filho]

Jorge Luiz Godoy Filho, Quarta 19 Janeiro 2005 15:17, wrote:

> Hmmm...   I see.  I'm trying to avoid having to install external modules
> at
> my client's server.  Should I use, given that both DAO and ODBC are
> available with the win32all extensions, DAO or ODBC?
> 
> Or would ADO give me so much more performance that I should really use it?

I've also made it work with ADO...  It doesn't require me to use the
'makepy' on it, so this might be a better choice if I have to deploy for
more machines.

I think I'll go with ADO.


Thanks Larry and Steve.

-- 
Godoy. <[EMAIL PROTECTED]>

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

Re: Dictionary keys (again) (was Re: lambda)

[David Eppstein]

In article <[EMAIL PROTECTED]>,
 Nick Coghlan <[EMAIL PROTECTED]> wrote:

> For a 'mutable key' to make sense, the following:
> 
> lst = []
> dct = {l: "Hi!"}
> print dct[[]]
> print dct[lst]
> lst.append(1)
> print dct[[1]]
> print dct[lst]
> 
> Should print:
> Hi
> Hi
> Hi
> Hi

Yes, and what should the following do?

lst1 = [1]
lst2 = [2]
dct = {lst1: "1", lst2: "2"}
lst2[0]=1
lst1[0]=2
print dct[[1]]
print dct[[2]]

-- 
David Eppstein
Computer Science Dept., Univ. of California, Irvine
http://www.ics.uci.edu/~eppstein/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: [OT] Good C++ book for a Python programmer

[Andrew Koenig]

<[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]

> The 4th edition of the well-known "C++ Primer", with Moo as a new 
> co-author, will soon be published. It is a
> more comprehensive and much longer book.

It is also organized more traditionally than "Accelerated C++."

"Accelerated C++" is mostly example-driven: It presents problems, shows how 
to solve them, and introduces language and library features as needed for 
particular parts of the solutions.  Of course the problems are carefully 
chosen so that the solutions cover the most important parts of the language 
and library, but that fact is not immediately obvious from the nature of the 
problems themselves.

"C++ Primer" follows the classical approach of treating each part of the 
language and library separately in a single place.  For example, there are 
chapters on expressions, statements, functions, templates, object-oriented 
programming, and so on.  It is also much more systematic than "Accelerated 
C++."  It is also nearly three times the size.

Which of these books you prefer will depend on your learning style more than 
anything else.  If you are willing to read the entire book sequentially, you 
will probably learn C++ faster from "Accelerated C++" than from "C++ 
Primer."  On the other hand, if you want to see in one place what all the 
different kinds of statements are, so that you can learn about them all at 
once, then you will be more comfortable with "C++ Primer."

I'm biased, of course, but I believe that either of these books is a better 
starting point for someone unfamiliar with C than any other book I can think 
of.



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

FTPLIB & FTPS or SFTP?

[Peter A.Schott]

Does the ftplib support SFTP or FTPS?  Is that part of a different module?  We
have a handful of partners who use FTPS or SFTP and I need to pull/push files
to/from them.


Thank you for all of your help.

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

Re: [OT] Good C++ book for a Python programmer

[Scott David Daniels]

John Hunter wrote:
"Philippe" == Philippe C Martin <[EMAIL PROTECTED]> writes:

Philippe> I suggest you google 'C++ tutorial' Regards,
Stroustup's "The C++ Programming Language" is the best C++ book I've
read.  It is at a fairly high level, and I already had read several
C++ books before reading it, so it may be tough sledding.  But I would
try this first since you are an experienced programmer and know OO
concepts, and if it fails to satisfy try something lighter.
Unfortunately, I didn't like any of the other kinder, gentler overview
books I read on C++, so can't really recommend anything along those
lines, though I'm sure they are out there.
JDH
For a rationale as to why the language developed the way it did, you
can read Stroustrup's "The Design and Evolution of C++".  This is no
good for learning the language, but it might be a good library borrow
to find out why the language is the way it is.
-Scott David Daniels
[EMAIL PROTECTED]
--
http://mail.python.org/mailman/listinfo/python-list

Re: rotor replacement

[Paul Rubin]

Scott David Daniels <[EMAIL PROTECTED]> writes:
> I understand this to be true.  Since I am trying to address encryption
> in the zipfile module, and I know you actually follow a bit of the
> encryption stuff, can you answer a question or two for me?

Sure, I can try, so go ahead.  There's more crypto expertise in
sci.crypt though.

Zipfile encryption is totally incompatible with the rotor module, by
the way, and traditionally it didn't use AES.  There are a couple of
replacements for the traditional method that do use AES but that I
think are somewhat incompatible with each other.

>  > The Python maintainers didn't want to deal with imagined legal hassles
>  > that might develop from including good crypto functions in the
>  > distribution.  Then it became obvious that the same imagined hassles
> > could also befall the rotor module, so that was removed.
> 
> Are you saying these hassles are, in fact, imaginary rather than real?

Well, I didn't want to say that the hassles were real, but I wasn't
trying to insinuate quite as much as it may have sounded.  Like, I
don't drive my car at 100 mph on Main Street because I can imagine
what would happen and it's not pretty.  The imagined carnage is a good
enough reason not to drive that way.  However, I do feel that the
Python distributors are being over-cautious, see below.

> Is this because you feel python is over-cautious about the USA, or is
> this an opinion on "essentially all countries?"  This is not a quibble
> or a kvetch; I would like your understanding about the world legal
> state of dealing with encryption (which, I assure you, I won't take as
> definitive).  I would hate to think someone in, for example, the UAE,
> was busted for downloading or republishing python "out-of-the-box."

I think the Python maintainers were more concerned about that UAE
situation.  However, the most widely deployed encryption software is
the SSL stack in just about every web browser (MSIE, Firefox, etc.)
and I'm sure lots of people are using those browsers in the UAE.  The
Mozilla foundation isn't hestitating to ship the encryption as far as
I can tell.

See http://www.bxa.doc.gov/Encryption for the USA rules.  Basically
for a free encryption program on the web, you're supposed to notify
the Dept. of Commerce by sending them an email when you publish it,
telling them where they can get it (address is on that site).  As far
as anyone can tell, the DOC never does anything with those emails.
The rules are more complicated for nonpublished commercial programs,
crypto hardware, etc.

> Don't get me wrong, I'd love the answer to be "sure its fine," but my
> current plans are to provide a way to connect a crypto package to
> zipfile without providing any such package myself.

I'd say provide a package if you can, unless you have realistic
concern about getting in trouble.
-- 
http://mail.python.org/mailman/listinfo/python-list

shelve to DB conversion?

[Aahz]

I'd like to hear some experiences about converting a shelf with pickles
to database with pickles, particularly if someone has handy code for
proxying shelve code.  We're using PostgreSQL if that makes any
difference.
-- 
Aahz ([EMAIL PROTECTED])   <*> http://www.pythoncraft.com/

"19. A language that doesn't affect the way you think about programming,
is not worth knowing."  --Alan Perlis
-- 
http://mail.python.org/mailman/listinfo/python-list

xml parsing escape characters

[Luis P. Mendes]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
I only know a little bit of xml and I'm trying to parse a xml document
in order to save its elements in a file (dictionaries inside a list).
When I access a url from python 2.3.3 running in Linux with the
following lines:
resposta = urllib.urlopen(url)
xmldoc = minidom.parse(resposta)
resposta.close()
I get the following result:

http://www..";>
~  
~439
(... others ...)
~  

_
In the lines below, I try to get all the child nodes from string, first
by counting them, and then ignoring the /n ones:
stringNode = xmldoc.childNodes[0]
print stringNode.toxml()
dataSetNode = stringNode.childNodes[0]
numNos = len(dataSetNode.childNodes)
todosNos={}
for no in range(numNos):
todosNos[no] = dataSetNode.childNodes[no].toxml()
posicaoXml = [no for no in todosNos.keys() if len(todosNos[no])>4]
print posicaoXml
(I'm almost sure there's a simpler way to do this...)
_
I don't get any elements.  But, if I access the same url via a browser,
the result in the browser window is something like:
http://www..";>
~  
~
~  439
(... others ...)
~
~  

and the lines I posted work as intended.
I already browsed the web, I know it's about the escape characters, but
I didn't find a simple solution for this.
I tried to use LL2XML.py and unescape function with a simple replace
text = text.replace("<", "<")
but I had to convert the xml document to string and then I could not (or
don't know) how to convert it back to xml object.
How can I solve this?  Please, explain it having in mind that I'm just
beggining with Xml and I'm not very experienced in Python, too.
Luis
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFB7rzKHn4UHCY8rB8RAhnlAKCYA6t0gd8rRDhIvZ5sdmNJlEPSeQCgteB3
XUtZ0JoHeTavBOCYi6YYnNo=
=VORM
-END PGP SIGNATURE-
--
http://mail.python.org/mailman/listinfo/python-list

Re: delay and force in Python

[infidel]

It took me a while to figure out what the "translated" code was trying
to do.  Here's a quick example that I think accomplishes the same
thing:

>>> for i, n in enumerate(x for x in xrange(998) if x % 2 == 0):
... if i == 1:
... print n
... 
2

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

Re: python/cgi/html bug

[Paul Rubin]

Dfenestr8 <[EMAIL PROTECTED]> writes:
> No glaring security holes that you noticed? Other than being able to hide
> things in html tags?

Looks like you can also embed arbitrary javascript (I just tried it).
I haven't looked at the script itself yet.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: a question

[Will Stuyvesant]

Andrew Koenig wrote:
> how about writing this instead?
>
> ('this is a '
>  'long string')

Yes, nice.  And to make that possible we have to write
('one-string-item',) instead of ('one-string-item') if we want a tuple
with one string inside.  Sometimes that feels like a wart to me, but
now I know it, sometimes not.

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