RE: Picking a license

[Delaney, Timothy (Tim)]

From: Ben Finney

> This thread is already off-topic and too long. I'm conflicted about my
role in that;
> I have endeavoured only to address falsehoods that IMO were not
otherwise being addressed.
>
> So I'll try to keep this brief.
>
> Ethan Furman  writes:
>
>> This doesn't make sense to me, but I'm willing to learn -- how do you

>> do this in practice? Are you really selling the software
>
> Perhaps in private email we can discuss what you mean by "really
selling the software";
> it's too off-topic here. By my understanding of that term, yes, I am
selling software.
>
>> or rather selling things like setup, support, new code (or time to 
>> code), etc?
>
>All of the above, depending on the project.

Considering that's one of the only two interesting things that have come
out of this
discussion, if you're willing to discuss that in public (in another
thread) I'd be very
interested in reading it.

BTW, the other interesting thing is the inadvertent license violations
where I tend to
think Pat has the right interpretation, but am not sure.

For the record, I tend to be in favour of permissive licenses both for
releasing my own
code and using others' (not least because I am employed by a company and
it makes my work
easier), but there are good reasons for using any license so long as you
understand the
consequences of your decision.

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

RE: Re: Super() function

[Delaney, Timothy (Tim)]

Gabriel Genellina write:

> En Sun, 28 Mar 2010 21:58:07 -0300, Delaney, Timothy (Tim) 
>  escribió:
>>> Gabriel Genellina wrote:
>>>> Alan Harris-Reid  escribió:
>>>>
>>>>> Using Python 3.1, I sometimes use the super() function to call the 
>>>>> equivalent method from a parent class, for example
>>>>>
>>>>> def mymethod(self):
>>>>> super().mymethod()
>>>>> some more code...
>>>>
>>>> This recipe does what you want:
>>>> http://code.activestate.com/recipes/286195-selfsuper/
>> If you think the pure-python version of the recipe is complicated, you 
>> should have a look at the performance-optimised Pyrex version ;)
>
> Where can we look at it? The link in the activestate recipe does not work 
> anymore :(

You're right - I've changed ISPs. I'll have to find somewhere else to upload it 
and change the link. Can't do it today unfortunately.

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

RE: Re: Super() function

[Delaney, Timothy (Tim)]

> Gabriel Genellina wrote:
>> Alan Harris-Reid  escribió:
>>
>>> Using Python 3.1, I sometimes use the super() function to call the 
>>> equivalent method from a parent class, for example
>>>
>>> def mymethod(self):
>>> super().mymethod()
>>> some more code...
>>>
>>> Is there any way of writing the code so that the super() call is 
>>> generic and automatically recognises the name of the current method 
>>> (ie. something like super().thismethod()) or do I always have to 
>>> repeat the method name after super()?
>>
>> This recipe does what you want:
>> http://code.activestate.com/recipes/286195-selfsuper/
>> (but requires a bit of black magic...)
>>
> Hi Gabriel - thanks for the reply.
>
> Goodness me - that's a mighty complicated recipe for what I want to achieve!
> I think I'll stick with repeating the method name - it's a small price to pay.

I wrote that recipe back before Python 3.x supported super() without parameters,
and near equivalent functionality was part of the new super PEP as an option.
However, Guido decided to go with the much simpler super().attr with no 
shortcutting.

If you think the pure-python version of the recipe is complicated, you should 
have
a look at the performance-optimised Pyrex version ;)

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

RE: missing 'xor' Boolean operator

[Delaney, Timothy (Tim)]

Mark Dickinson wrote:

>> Since the 'and' and 'or' already return objects (and objects
>> evaluate to true or false), then 'xor' should behave likewise, IMO.
>> I expect that would be the case if it were ever added to the
>> language. 
> 
> I'm not so sure.  Did you ever wonder why the any() and all()
> functions introduced in 2.5 return a boolean rather than returning
> one of their arguments?  (I did, and I'm still not sure what the
> answer is.)

Consider the case of any() and all() operating on an empty iterable.
What type should they return?

It is impossible in the case of any() and all() to always return one of
the elements due to this edge case. Similarly, it is impossible in all
cases for a boolean xor to return one of the arguments - if both
arguments evaluate to a true (Something) value, xor must return a false
(Nothing) result.

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

RE: with open('com1', 'r') as f:

[Delaney, Timothy (Tim)]

Lawrence D'Oliveiro wrote:

> In message ,
> Terry Reedy wrote:
> 
>> Lawrence D'Oliveiro wrote:
>> 
>>> All Python objects are reference-counted.
>> 
>> Nope.  Only in CPython, and even that could change.
> 
> Why should it?

Because Guido has said it might some time in the future.

>>> Once the file object becomes
>>> inaccessible, it is automatically closed. Simple.
>> 
>> Even in CPython, that would not be true now is the object became
>> involved in or became a dependent of a reference cycle.
> 
> And how exactly would that happen with a file object?

Create a cycle of objects, and have one of them reference a file object.

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

RE: Python Goes Mercurial

[Delaney, Timothy (Tim)]

Sorry - it's early and I didn't force Outlook to not top-post.
Unfortunately, I get asked to top-post here at work ...

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

RE: Python Goes Mercurial

[Delaney, Timothy (Tim)]

As someone who has to use ClearCase UCM at work (damned politics!) I can
tell you that I very much prefer creating a separate view (directory)
for each branch as I used to do in Base ClearCase.
 
All too often you end up having to deliver multiple activities together
because someone else made a change that touched files that you have
modified in separate activities, and because you can't deliver without
rebasing you end up forced to deliver both changes together (because the
rebase creates a dependency between the files).
 
Now, I don't know if git has a similar problem, but it makes me wary of
any VCS which purports to work with multiple branches, etc in a single
directory.
 
Tim Delaney



From: python-list-bounces+tdelaney=avaya@python.org
[mailto:python-list-bounces+tdelaney=avaya@python.org] On Behalf Of
Jeremiah Dodds
Sent: Thursday, 2 April 2009 11:19 PM
To: python-list@python.org
Subject: Re: Python Goes Mercurial


The one thing that makes me want to use git more than any other dvcs is
that you don't have to create a new directory for branches. This may be
possible in other dvcs's , but git is the only one I've seen advertise
the capability.

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

RE: Introducing Python to others

[Delaney, Timothy (Tim)]

Rhodri James wrote:

> On Thu, 26 Mar 2009 09:35:55 -, Paddy O'Loughlin
>  wrote:
> 
>> Because of this, I was thinking of making sure I included exceptions
>> and handling, the richness of the python library and a pointing out
>> how many modules there were out there to do almost anything one could
>> think of.
> 
> Once you've shown them exceptions, show them context managers briefly.
> It's amazing how much they can simplify some types of exception
> handling. 

I would second this. Basically, write something in idiomatic PHP or
Java, and write the direct translation to Python. Then show them the
idiomatic Python.

Of course, you need to be upfront that this may in some cases work in
reverse, but that in your experience idiomatic Python code that has the
same effect tends to be considerably clearer and shorter.

try/finally -> with is an excellent example of idiomatic python. I'd
suggest IO would be the best candidate - something along the lines of:

f = open('path', 'w')

try:
f.write('Hello, world!')
finally:
f.close()

to:

with open('path', 'w') as f:
f.write('Hello, world!')

Mention that locks (threading) are also context managers, there's a
built-in "closing" context manager (and what it does), and explain how
you can write any context manager you like.

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

RE: Is python worth learning as a second language?

[Delaney, Timothy (Tim)]

Aahz wrote:

> In article <49b58b35$0$3548$426a7...@news.free.fr>,
> Bruno Desthuilliers   wrote:
>> Tomasz Rola a écrit :
>>> 
>>> I may not be objective (tried Java, hated it after 6 years).
>> 
>> Arf - only took me 6 months !-)
> 
> That long?  It only took me six minutes.

I was young and foolish - I actually thought Java was a decent language for a 
few months - until I had to maintain a program written by outside contractors. 
This was back in the Java 1.1 days ...

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

RE: Is python worth learning as a second language?

[Delaney, Timothy (Tim)]

ZikO wrote:

> I am a C++ programmer and I am thinking of learning something else
> because I know second language might be very helpful somehow. I have
> heard a few positive things about Python but I have never writen any
> single line in python so I do not know this language at all.
>
> Do you think python would be good complementary language for C++? Do
> you think it's worth learning it or let's say try Java? and how
> difficult it would be for me if I know C++ pretty well I would say?

Python is an excellent first, second or 20th programming language. It's
a lot easier to interface Python with C++ than it is to interface Java
with C++ (but both are possible).

I tend to use multiple languages daily (at any time usually 4-5 in
regular use) and I've "forgotten" at least 20 languages (i.e. they're no
longer in regular use - but I could probably pick them up again
quickly). The more programming languages you learn, the easier it is to
learn new ones.

The first thing to do when learning a new language is to drop any habits
you learned with the language you're currently using. If you find
yourself asking "How do I implement  in Python?", stop and
instead ask "What problem am I trying to solve?". Quite often idioms
from other languages result in much more verbose and much slower code.

The same thing happens going the other way - so often in Java I get
frustrated because there's so much more boilerplate to implement what
are simple idioms in Python. Unfortunately in Java, usually there isn't
a simpler alternative available ...

Eventually you should learn both Java and Python, if only to be exposed
to different approaches to doing things.

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

RE: Peculiar swap behavior

[Delaney, Timothy (Tim)]

Tim Chase wrote:

> # swap list contents...not so much...
>  >>> m,n = [1,2,3],[4,5,6]
>  >>> m[:],n[:] = n,m
>  >>> m,n
> ([4, 5, 6], [4, 5, 6])
> 
> 
> The first two work as expected but the 3rd seems to leak some
> internal abstraction.  It seems to work if I force content-copying:
> 
>  >>> m[:],n[:] = n[:],m[:]
> 
> or even just
> 
>  >>> m[:],n[:] = n,m[:]
> 
> but not
> 
>  >>> m[:],n[:] = n[:],m
> 
> Is this a bug, something Python should smack the programmer for
> trying, or just me pushing the wrong edges? :)

For these types of things, it's best to expand the code out. The
appropriate expansion of:

m,n = [1,2,3],[4,5,6]
m[:],n[:] = n,m

is:

m = [1,2,3]
n = [4,5,6]
m[:] = n
n[:] = m

After the third line, m == n, giving the behaviour you see. OTOH, for:

m,n = [1,2,3],[4,5,6]
m[:],n[:] = n[:],m[:]

the expansion is more like:

m = [1,2,3]
n = [4,5,6]
rhs1 = n[:]
rhs2 = m[:]
m[:] = rhs1
n[:] = rhs2

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

RE: Python binaries with VC++ 8.0?

[Delaney, Timothy (Tim)]

bearophileh...@lycos.com wrote:

> Paul Rubin:
>> Gideon Smeding of the University of
>> Utrecht has written a masters' thesis titled "An executable
>> operational semantics for Python".
> 
> A significant part of Computer Science is a waste of time and money.

The same can be said for any research. Can you predict ahead of time
which research will be useful, and which won't? If so (and you can prove
it) why aren't you making unbelievable amounts of money?

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

RE: Ordered dict by default

[Delaney, Timothy (Tim)]

bearophileh...@lycos.com wrote:

> I have missed another example: It may be possible to create a sorting
> routine that's not stable but is faster than the current stable
> timsort (for example in C++ STL you have both sorting routines, and
> the unstable one is a variant of introsort that is faster than the
> stable version). I think Python will keep the stable one, because even
> if (in theory. In practice it may be quite difficult to write such
> unstable sorter faster than timsort) it can be slower, it's safer and
> more useful than an unstable sort.

Python mandates a stable sort, so this will not change. Note that this
used to not be the case - timsort was introduced in Python 2.3, and
*because* it was *both* stable and blazingly fast, the requirement for a
stable sort was back-dated to Python 2.3.

If timsort had not been so overwhelmingly superior to every other option
at the time (and in particular, without any known worst-case scenarios)
then Python would likely still not be requiring a stable sort. But
because it is so good, the extra performance gain from any future
non-stable sort was considered unlikely to offset the benefits of a
stable sort.

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

RE: spam on the list - how are things now?

[Delaney, Timothy (Tim)]

s...@pobox.com wrote:

> We've been running SpamBayes on the news-to-mail gateway on
> mail.python.org for a couple weeks now.  To me it seems like the
> level of spam leaking onto the list has dropped way down but I'd like
> some feedback from people who read the python-list@python.org mailing
> list on the topic. 

Sorry Skip - looks like it's not working. The Xah Lee spam is still
getting through ;)

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

RE: Does Python really follow its philosophy of "Readability counts"?

[Delaney, Timothy (Tim)]

Terry Reedy wrote:

>> The compiled code differs.
> 
> I *strongly* doubt that.  Properties are designed to be transparent to
> user code that access atrributes through the usual dotted name
> notation precisely so that class code can be changed from
>x = ob
> to
>x = property(get_x, set_x, del_x)
> without changing user code.

He was talking about C# with that statement. In C#, the compiled code
differs depending on whether you use a property or an attribute. Or at
least that's how I interpreted it.

You are of course correct as to how Python does it.

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

RE: Commercial Products in Python

[Delaney, Timothy (Tim)]

Paulo J. Matos wrote:

> Question cleared:
> http://wiki.python.org/moin/DistributionUtilities

Another option that we've used in the past was to write the "sensitive"
bits in Pyrex/Cython. These get compiled to executable code (a .pyd/DLL
on Windows, .so on Unix-like systems). They are tied to the (major)
version of Python of course.

You can of course write the entire program like this, then either use
py2exe to give a stub .exe, or just use python -m. Chances are pretty
good that you will only need minimal changes to your python code to make
it work.

As a side benefit, some things get a speedup ;)

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

RE: I want to release the GIL

[Delaney, Timothy (Tim)]

Piotr Sobolewski wrote:

> Hello,
> I have such program:
> 
> import time
> import thread
> def f():
>     global lock
>     while True:
>         lock.acquire()
>         print thread.get_ident()
>         time.sleep(1)
>         lock.release()
> lock=thread.allocate_lock()
> thread.start_new_thread(f,())
> thread.start_new_thread(f,())
> time.sleep(60)

1. You should use the threading module.

2. No need for the "global lock" statement here - you're not rebinding the name 
"lock".

3. These aren't daemon threads, so your program will never exit. You will need 
to set a flag or something after the time.sleep(60).

> As you can see, I start two threads. Each one works in an infinite
> loop.
> Inside that loop it acquires lock, prints its own id, sleeps a bit and
> then
> releases lock.

4. Because you are holding the lock while sleeping, the other thread does not 
get the chance to run. Sleeping does not release any locks held.

Instead try something like:

while True:
with lock:
print thread.get_ident()
time.sleep(1)

Note that to use the "with lock:" idiom, you need to be using Python 2.6, or 
Python 2.5 with a "from __future__ import with_statement".

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

RE: Numeric literal syntax

[Delaney, Timothy (Tim)]

Steven D'Aprano wrote:

> On Thu, 04 Sep 2008 01:22:22 +0100, Alexander Schmolck wrote:
> 
>> It seems to me that the right choice for thousands seperator is the
>> apostrophe.
> 
> You mean the character already used as a string delimiter?

Hey - I just found a new use for the backtick!

123`456`7890
0b`1001`0110

Note: Guido has stated that the backtick will *not* be given a new
meaning in any future version of Python ...

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

RE: exception handling in complex Python programs

[Delaney, Timothy (Tim)]

Lie wrote:

> Ah... now I understand what the Zen is talking about when it said:
> "Now is better then never, although never is often better than *right*
> now." If you don't have all the necessary resources to fix an
> exception right now, don't try to fix it, instead let it propagate,
> and allow it to be handled in a level where there is enough
> information how to fix it.

Well, I believe the original intent was more along the lines of adding
features, etc to Python, but it's apropos here as well.

> I think we should change except: into expect:, it would confuse less,
> would it? It signifies that the program expects so and so kinds of
> exceptional situations.

Whilst the connotations are good, and I think create the right mindset,
it ain't gonna happen.

Cheers,

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

RE: Psycho question

[Delaney, Timothy (Tim)]

David C. Ullrich wrote:

> f: 0.0158488750458
> g: 0.000610113143921
> h: 0.00200295448303
> f: 0.0184948444366
> g: 0.000257015228271
> h: 0.00116610527039

I suspect you're hitting the point of diminishing returns with g, and
any further investigations into optimisation are purely for fun and
learning ;)

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

RE: Execution speed question

[Delaney, Timothy (Tim)]

Diez B. Roggisch wrote:

>> For sets, I presume they are built on top of or like dicts, and
>> there is nothing crazy in the low level implementation so that I can
>> be guaranteed that if I don't alter the set, then the order,
>> although arbitrary, will be maintained in successive iterations over
>> the contents? 
> 
> It is currently that way, but relying on it is certainly to be
> considered an implementation detail that might disappear without
> warning. 

Fortunately, that's incorrect - it is a documented feature that *so long
as the set is not modified in any way*, iterating over the set will
return the elements in the same order each time.

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

RE: Getting python 2.4 dll

[Delaney, Timothy (Tim)]

Guillermo wrote:

> Hi there,
> 
> Is it possible to get a 2.4 dll of python for Windows easily? I need
> it to use python as scripting language for Vim.

http://www.python.org/

which leads you to:
http://www.python.org/download/

which leads you to:
http://www.python.org/download/releases/2.4.5/

which leads you to (for a binary release):
http://www.python.org/download/releases/2.4.4/

Further questions along this line should be directed to:
http://www.catb.org/~esr/faqs/smart-questions.html#before

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

RE: Python Written in C?

[Delaney, Timothy (Tim)]

Fredrik Lundh wrote:

> rynt wrote:
> 
>> You're either ---
>> A.  A Troll
>> B.  A young, immature programmer trying to show off or
>> C.  A total idiot.
> 
> you forgot the "All of the above" choice.

I read it as an inclusive "or".

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

RE: how are strings immutable in python?

[Delaney, Timothy (Tim)]

ssecorp wrote:

> so why would you ever want mutability?
> 
> 
> seems very counterintuitive and unreliable.

Because immutability imposes a lot of restrictions and performance
characteristics that mutable objects don't have. For example, compare
building up a list and a tuple element-by-element (using the most
appropriate methods for each):

a = []
b = ()

for i in range(10):
a.append(i)
b += (i,)

The list can simply grow its memory space and assign the new element.
OTOH, we need to create two new tuples each time (the one containing the
new element, and the one which is a concatenation of the old elements
plus the new element). The old tuple and the temporary tuple then get
thrown away.

Even if you optimise away the temporary 1-tuple (which python doesn't)
the need to allocate a new tuple every time and copy the old elements to
it results in much worse time and memory usage.

There are optimisations that can be done if the compiler/runtime system
can determine that there is only one reference to the immutable object
(python now does this in some cases for string concatenation), but in
general you cannot rely on this and have to assume that the worst case
applies.

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

RE: Use of the "is" statement

[Delaney, Timothy (Tim)]

Maric Michaud wrote:

> Le Friday 27 June 2008 18:26:45 Christian Heimes, vous avez écrit :
>> Ask yourself if you are interested if f.tell() returns exactly the
>> same 0 object ("is") or a number that is equal to 0 ("==").
> 
> That said, "f.tell() == 0" and "f.tell() != 0" should be written
> "f.tell()" and "not f.tell()" in python.
> 
> if not f.tell() :
> print 'at the beginning of the file"

No, because semantically you're not using the result of f.tell() as a boolean 
value. tell() returns a *position*, and he is checking for a particular 
position.

If he'd instead been testing for f.tell() == 2, would you have advisd that he 
use "if f.tell()"?

Ignoring the triviality of the below code, would you suggest refactoring:

for i, v in enumerate(iterable):
if i == 0:
doSomethingSpecial()
else:
print i

as:

for i, v in enumerate(iterable):
if not i:
doSomethingSpecial()
else:
print -i

?

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

RE: multiprocessing module (PEP 371)

[Delaney, Timothy (Tim)]

Christian Heimes wrote:

> Can you provide a C implementation that compiles under VS 2008? Python
> 2.6 and 3.0 are using my new VS 2008 build system and we have dropped
> support for 9x, ME and NT4. If you can provide us with an
> implementation we *might* consider using it.

You'd have to at least consider whether to consider using it ;)

BTW, something like adding a windows fork() that is not publically
exposed might be considered a bug/performance fix only (and thus
suitable for 3.0.1) if you don't get it into 3.0 (to be exposed to
Python code in 3.1) - but check first whether it would be accepted as
such. Definitely best to try to get it into 3.0.

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

RE: Misuse of list comprehensions?

[Delaney, Timothy (Tim)]

Ian Kelly wrote:

> It sounds like the wasteful list creation is the biggest objection to
> using a list comprehension.  I'm curious what people think of this
> alternative, which avoids populating the list by using a generator
> expression instead (apart from the fact that this is still quadratic,
> which I'm aware of).
> 
> def compress(s):
>new = []
>filter(None, (new.append(c) for c in s if c not in new))
>return ''.join(new)

Are you aware that filter() returns a list populated from its arguments?

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

RE: do you fail at FizzBuzz? simple prog test

[Delaney, Timothy (Tim)]

Mensanator wrote:

> Ok, I agree with 101, but I wouldn't necessarily
> say the others were unfortunate. You might be
> surprised at how often such fixations discover
> bugs, something that I have a gift for.

The discovering, the making, or both? ;)

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

RE: troll poll

[Delaney, Timothy (Tim)]

George Sakkis wrote:

> On Mar 31, 1:46 pm, Marc 'BlackJack' Rintsch <[EMAIL PROTECTED]> wrote:
> 
>>> More specifically, who can create a bigger mess on c.l.py? (check
>>> one) 
>> 
>>> [ ] - Xah Lee
>>> [X] - castironpi
>> 
>> Xah Lee's postings might be trolls but sometimes they spark some
>> really interesting and serious subthreads, while the nonsense of
>> castironpi is just irritating noise.
> 
> Which is exactly why there are rarely any replies to his random
> gibberish, so I would say that he/she/it has almost no effect on
> c.l.py. Yet I wish plonking was possible through Google groups.

I find classifying all their posts as spam works fairly well.

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

RE: Do any of you recommend Python as a first programming language?

[Delaney, Timothy (Tim)]

Steven D'Aprano wrote:

> On Sat, 22 Mar 2008 21:11:51 -0700, sturlamolden wrote:
> 
>> Yes. And because Python is a "scripting language"
> 
> 
> Python is a programming language. It can be used for scripting, but
> that's not all it can do. Describing it as a "scripting language" is
> like describing a fully-equipped professional kitchen as "a left-over
> warming room".

I'm putting words in sturlamolden's mouth here, but I think he was
implying that Python has all the advantages of a "scripting language",
hence has a much gentler introduction than many fully-fledged
programming languages (and indeed, many scripting languages).

Cheers,

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

RE: Prototype OO

[Delaney, Timothy (Tim)]

John Machin wrote:

> On Mar 23, 12:32 am, "Diez B. Roggisch" <[EMAIL PROTECTED]> wrote:
>> John Machin schrieb:
>> 
>>> On Mar 21, 11:48 pm, "Diez B. Roggisch" <[EMAIL PROTECTED]> wrote:
>> 
 [1] Just one example:http://docs.mootools.net/Class/Class.js
>> 
>>> Mootools being something a coworker might use?
>> 
>> I don't understand the question.
>> 
>> Diez
> 
> It presupposes that the reader on first seeing "coworker" has mentally
> decomposed it as "cow-ork-er".

As an aside, having lived much of my early life on a hobby farm, I've
often wondered to myself just what cow-orking involves ... ;)

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

RE: Failed saving throw

[Delaney, Timothy (Tim)]

Aahz wrote:

> For anyone who hasn't heard, E. Gary Gygax died yesterday.  Some
> people think we should build a tomb in his honor.  ;-)

Well, you sure wouldn't get a saving throw there ;)

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

RE: Looping through the gmail dot trick

[Delaney, Timothy (Tim)]

Steven D'Aprano wrote:

> Postfix, I think, interpets "foo+bar" the same as "foo".

Gmail does the same. It's quite useful - apart from using it to
determine which site I signed up to has sent me mail, I also use it so I
can have multiple Guild Wars accounts using the same email account e.g.

[EMAIL PROTECTED]
[EMAIL PROTECTED]

All resolve to @gmail.com. I have a couple of spare accounts so when
friends or relative visit we can all play together ...

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

RE: plz help how to print python variable using os.system()

[Delaney, Timothy (Tim)]

Grant Edwards wrote:

> On 2008-01-16, Lutz Horn <[EMAIL PROTECTED]> wrote:
>> Hi,
>> 
>> On Wed, 16 Jan 2008 05:29:08 -0800 (PST), [EMAIL PROTECTED]
>> said: 
>>> var = "/home/anonymous"
>>> os.system("echo $var)
>> 
>> os.system("echo %s" % var)
> 
> Though one wonders why one would do that instead of simply doing
> 
> print var

Only reason I can think of is to learn how to use os.system before doing
something larger. But the OP should be using subprocess or popen in most
cases anyway ...

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

RE: ISO Python example projects (like in Perl Cookbook)

[Delaney, Timothy (Tim)]

You know you've been working at a large company for too long when you
see that subject and think "ISO-certified Python?"

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

RE: Don't use __slots__ (was Re: Why custom objects take so much memory?)

[Delaney, Timothy (Tim)]

Aahz wrote:

> In article <[EMAIL PROTECTED]>,
> Chris Mellon <[EMAIL PROTECTED]> wrote:
>> 
>> You can reduce the size of new-style classes (inherit from object) by
>> quite a bit if you use __slots__ to eliminate the class dictionary.
> 
> You can also reduce your functionality quite a bit by using __slots__.
> Someday I'll have time to write up a proper page about why you
> shouldn't use __slots__

Although admittedly this *is* one of the cases where __slots__ is being
suggested for it's intended use - where memory issues require smaller
objects.

Of course, a better result can probably be achieved by using a different
algorithm or technology (database?).

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

RE: Is a "real" C-Python possible?

[Delaney, Timothy (Tim)]

Aahz wrote:

>> Unless it's a new style class with __slots__
> 
> []
> 
> Naw, I'll skip the rant this time.  ;-)

Wuss! I was looking forward to it :)

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

RE: Problem of Readability of Python

[Delaney, Timothy (Tim)]

Licheng Fang wrote:

> This is enlightening. Surely I shouldn't have worried too much about
> performance before doing some measurement.

And with that statement you have truly achieved enlightenment.

Or to put it another way ... performance tuning without profiling is a
waste of time.

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

RE: Fwd: NUCULAR fielded text searchable indexing

[Delaney, Timothy (Tim)]

[EMAIL PROTECTED] wrote:

>> From: Grant Edwards
>> 
>> Anyway, I apologize for my attempt at humor, since it appears
>> to have somehow offended.
> 
> Why apologize?  If someone doesn't like the name given to a piece of
> software by its author(s), screw them.  If I find the software useful,
> I'll use it.  Even if its called 'bouncingBetty'.  Actually, I might
> try it, just because of the name, but you get my point.

I agree entirely (being the person who started this). There is a
difference between using a word though that has existing connotations
for a lot of people, and one that doesn't.

In the case of "nucular", it's a mispronunciation that has been widely
ridiculed all over the world. There are people (including myself) who so
associate it as an object of ridicule that it's an immediate turn-off.

If you want to keep using the name, so be it - no skin off my nose. But
I couldn't mention NUCULAR here at work (Australia) for oh so many
reasons ... 

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

RE: NUCULAR fielded text searchable indexing

[Delaney, Timothy (Tim)]

[EMAIL PROTECTED] wrote:

> ANNOUNCE:
>   NUCULAR fielded text searchable indexing

Does "NUCULAR" stand for anything? The (apparent) misspelling of
"nuclear" has already turned me off wanting to find out more about it.

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

RE: Python 3.0 migration plans?

[Delaney, Timothy (Tim)]

TheFlyingDutchman wrote:

> On Sep 28, 1:09 pm, Steve Holden <[EMAIL PROTECTED]> wrote:
> 
>> That's because the tutor list doesn't offer a newsgroup. He was
>> probably just trying to get rid of you.
>> 
>> Now at 98.75% ...
> 
> Not sure if that's the reading on your trollmeter or on the meter that
> measures what percentage of your posts you get huffy.

I would imagine it's the SpamBayes score your posts are currently
getting on Steve's machine.

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

RE: sorting a list numbers stored as strings

[Delaney, Timothy (Tim)]

Hrvoje Niksic wrote:

> "Delaney, Timothy (Tim)" <[EMAIL PROTECTED]> writes:
> 
>> Yep - appears I must have been misremembering from another language
>> (dunno which)
> 
> Tcl

Not bloody likely - only used Tcl for expect, and then only very
minimally. I'm sure there's at least one language though among the 20+
I've forgotten over the years that has significant leading zeroes in its
default string->int parsing.

Actually, I think Java does ...

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

RE: sorting a list numbers stored as strings

[Delaney, Timothy (Tim)]

ZeD wrote:

> thebjorn wrote:
> 
>> int("020")
>>> 20
>> 020
>>> 16
>> 
>> You can get the latter behavior using eval:
> 
> why using eval when int has the "base" optional parameter?
> 
 int("020")
> 20
 int("020", 8)
> 16
 int("09", 8)
> Traceback (most recent call last):
>   File "", line 1, in 
> ValueError: invalid literal for int() with base 8: '09'

The whole point of this was I misremembered what the base/radix optional
parameter of int() defaulted to - I thought it was 0, then when I
checked in Python 2.5 I thought it must have been 0 in an earlier
version.

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

RE: sorting a list numbers stored as strings

[Delaney, Timothy (Tim)]

Carsten Haese wrote:

> On Mon, 2007-09-24 at 19:58 +0800, Delaney, Timothy (Tim) wrote:
>> I'm sure that in some version of Python it would have given a
>> ValueError (due to the default radix being 0) but it appears to have
>> changed to a default radix of 10 somewhere along the way.
> 
> Not even Python 1.5.2 seems to have a problem with leading zeroes:
> 
> Python 1.5.2 (#1, Nov  6 1999, 14:53:40) [C] on sco_sv3
> Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>>> int("08")
> 8

Yep - appears I must have been misremembering from another language
(dunno which) or I misinterpreted the docs.

In any case, the docs have been made explicit about the situation now.

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

RE: Almost There - os.kill()

[Delaney, Timothy (Tim)]

Delaney, Timothy (Tim) wrote:

> Nope - pretty sure that an earlier version of Python defaulted to a
> radix of 0, but it appears to default to a radix of 10 in Python 2.5.
> 
> In any case, I've submitted a bug report and suggested new text for
> the documentation of int() to make it clear what happens when a radix
> is not specified.

Hmm - looks like I must have been misremembering from another language -
it appears Python always used a default radix of 10.

Anyway, the docs have been updated.

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

RE: Almost There - os.kill()

[Delaney, Timothy (Tim)]

Carsten Haese wrote:

> On Mon, 2007-09-24 at 19:48 +0800, Delaney, Timothy (Tim) wrote:
>> Always be careful with int() incase any of the values have a leading
>> zero - check the documentation for int() carefully.
> 
> Why would leading zeroes be a problem?
> 
>>>> int("10")
> 10
>>>> int("010")
> 10
>>>> int("0010")
> 10
>>>> int("00010")
> 10
> 
> Maybe you're thinking of "evil eval?"
> 
>>>> eval("10")
> 10
>>>> eval("010")
> 8

Nope - pretty sure that an earlier version of Python defaulted to a
radix of 0, but it appears to default to a radix of 10 in Python 2.5.

In any case, I've submitted a bug report and suggested new text for the
documentation of int() to make it clear what happens when a radix is not
specified.

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

RE: sorting a list numbers stored as strings

[Delaney, Timothy (Tim)]

Carsten Haese wrote:

> That interpreter session is a work of fiction, since sorted returns
> the sorted list instead of sorting the list in place. Also, it's
> better (i.e. more readable and likely faster) to use a sort key
> function instead of a comparison function whenever possible. In this
> case, the sort key function is particularly trivial:
> 
 l = ["1", "11", "2", "22"]
 sorted(l, key=int)
> ['1', '2', '11', '22']

It does appear trivial in this case, but need to be careful with using
int() if any of the strings could have leading zeros. In this case, the
fix is almost as trivial:

 l = ["01", "11", "08", "22"]
 sorted(l, key=lambda x: int(x, 10))
> ['01', '08', '11', '22']

Although I just tried the above using just sorted(l, key=int) and it
succeeded. I'm sure that in some version of Python it would have given a
ValueError (due to the default radix being 0) but it appears to have
changed to a default radix of 10 somewhere along the way. The docs don't
specify what the default radix is (I should probably raise a bug report
for this).

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

RE: Almost There - os.kill()

[Delaney, Timothy (Tim)]

Always be careful with int() incase any of the values have a leading
zero - check the documentation for int() carefully.
 
Cheers,
 
Tim Delaney



From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Robert Rawlins - Think Blue
Sent: Monday, 24 September 2007 5:10 PM
To: 'Robert Rawlins - Think Blue'; python-list@python.org
Subject: RE: Almost There - os.kill()



Woops,

 

Spoke too soon, just wrapped them in int() and it works a charm :-D

 

Rob

 

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
rg] On Behalf Of Robert Rawlins - Think Blue
Sent: 24 September 2007 12:23
To: python-list@python.org
Subject: Almost There - os.kill()

 

Hello Guys,

 

Finally got around to sitting down to tidy up this script this morning
but I'm having a small syntax problem with os.kill() to kill a process
on my system. Here is the code:

 

def killApplication():

 

   pid = file('/var/lock/MyApplication.lock').read().strip()

   

   logging.info('Killing Application Process: %s' % pid)

 

   os.kill(pid, 15)

 

   logging.info('Application %s Killed' % pid)

 

As you can see if rips the PID from the lock file, which works fine as I
get log data which says 'Killing Application Process: 3079' exactly as I
would expect it too. However when I run this script I get the following
error:

 

Traceback (most recent call last):

  File "/pblue/new/Alive.py", line 50, in ?

main()

  File "/pblue/new/Alive.py", line 47, in main

doCheck()

  File "/pblue/new/Alive.py", line 43, in doCheck

killApplication()

  File "/pblue/new/Alive.py", line 28, in killApplication

os.kill(pid, 15)

TypeError: an integer is required

 

Which would suggest its passing those arguments in as the wrong data
types to the kill command. What is the best way to convert these?

 

Thanks guys,

 

Rob

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

RE: Would Anonymous Functions Help in Learning Programming/Python?

[Delaney, Timothy (Tim)]

Carsten Haese wrote:

>> Where the heck does *this* come from?  Neither Python 2.5.1 nor the
>> 3.0alpha has this in `__builtin__`.
> 
> It comes from the 'new' module:
> 
 import new
 help(new.function)
> Help on class function in module __builtin__:
> ...
> 
> Oddly enough, the help misrepresents which module the function is
> coming from.

Not exactly:

>>> help(type(lambda x: x))
Help on class function in module __builtin__:

The function type is builtin, but it doesn't have an exposed name.
`new.function` is simply a name bound to the function type.

Note the help says *class* function ...

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

RE: I could use some help making this Python code run faster usingonly Python code.

[Delaney, Timothy (Tim)]

Python Maniac wrote:

> Some benchmarks showing the effectiveness of using Psyco:
> 
> scramble:   4.210
> scramble_listcomp:  2.343
> scramble_gencomp:   2.599
> scramble_map:   1.960
> scramble_imap:  2.231
> scramble_dict:  2.387
> scramble_dict_map:  0.535
> scramble_dict_imap: 0.726
> scramble_translate: 0.010
> 
> Now with Psyco...
> psyco.bind(scramble)...
> scramble:   0.121   4.088   34.670x faster
> scramble_listcomp:  0.215   2.128   10.919x faster
> scramble_gencomp:   2.563   0.036   1.014x faster
> scramble_map:   2.002   -0.043  0.979x slower
> scramble_imap:  2.175   0.056   1.026x faster
> scramble_dict:  0.199   2.188   11.983x faster
> scramble_dict_map:  0.505   0.029   1.058x faster
> scramble_dict_imap: 0.728   -0.001  0.998x slower
> scramble_translate: 0.009   0.001   1.111x faster
> 
> Overall, Psyco helped my little process of converting 20 MB worth of
> ASCII into what may not look like the original at 6x faster than
> without Psyco.

One thing you should notice with the above results:

Psyco made your initial, totally unoptimised algorithm the fastest of
all (except for translate, which is in a different league of course -
but is much more limited in what it can do).

The other algorithms are already heavily working in C code (dicts, etc),
but the initial algorithm provided lots of opportunities for Psyco to
hook in and use the runtime behaviour.

So, before trying to optimise, see if Psyco gives you the performance
you need.

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

RE: Python 3K or Python 2.9?

[Delaney, Timothy (Tim)]

Ben Finney wrote:

> The latter two statements are equivalent. The 'instance.method(args)'
> syntax is just sugar for 'Class.method(instance, args)'.

Only in the case that "instance" is an instance of "Class", and not an
instance of a subclass of "Class". For example, the following are not
equivalent:

class A(object):
def func(self):
print 'A'

class B(A):
def func(self):
super(B, self).func()
print 'B'

a = A()
b = B()

A.func(a)
A.func(b)
B.func(b)
a.func()
b.func()

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

RE: creating really big lists

[Delaney, Timothy (Tim)]

Hrvoje Niksic wrote:

> Dr Mephesto <[EMAIL PROTECTED]> writes:
> 
>> I would like to create a pretty big list of lists; a list 3,000,000
>> long, each entry containing 5 empty lists. My application will
>> append data each of the 5 sublists, so they will be of varying
>> lengths (so no arrays!). 
>> 
>> Does anyone know the most efficient way to do this? I have tried:
>> 
>> list = [[[],[],[],[],[]] for _ in xrange(300)]

> If you're building large data structures and don't need to reclaim
> cyclical references, I suggest turning GC off, at least during
> construction.

This is good advice, but another question is whether you really want
such a list. You may well be better off with a database of some kind -
they're designed for manipulating large amounts of data.

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

RE: How to free memory ( ie garbage collect) at run time with Python2.5.1(windows)

[Delaney, Timothy (Tim)]

Alex Martelli wrote:

> rfv-370 <[EMAIL PROTECTED]> wrote:
> 
>> have made the following small test:
>> 
>> Before starting my test my UsedPhysicalMemory(PF): 555Mb
>> 
> tf=range(0,1000)PF: 710Mb ( so 155Mb for my List)
> tf=[0,1,2,3,4,5] PF: 672Mb (Why? Why the remaining
> 117Mb is not freed?) del tfPF: 672Mb
> (unused memory not freed)
> 
> Integer objects that are once generated are kept around in a "free
> list" against the probability that they might be needed again in the
> future (a few other types of objects similarly keep a per-type
> free-list, but I think int is the only one that keeps an unbounded
> amount of memory there).  Like any other kind of "cache", this
> free-list (in normal cases) hoards a bit more memory than needed, but
> results in better runtime performance; anomalous cases like your
> example can however easily "bust" this too-simple heuristic.

In particular, the *memory* for integer objects is kept around - the
free list will be as big as the total number of integer objects that
exist simultaneously (with a few caveats, but it's close enough). Small
integers are pre-created and cached, and don't use the free list - off
the top of my head, from -5..255 now to cover the entire bytes range,
plus a few negatives, but that depends on the version of python.

When you call range(), you create that number of integer objects
simultaneously, and so you have that amount of memory allocated for use
by other integers for the lifetime of the python process.

If on the other hand you only created one of those integers at a time
(e.g. by iterating over the result from an xrange() call) you would only
be using (continually re-using) a single entry in the free list in total
and the python memory usage would be much smaller.

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

RE: Jython - problem import os

[Delaney, Timothy (Tim)]

[EMAIL PROTECTED] wrote:

> I'm using Jython in combination with Java, webservices and jboss4.0.4.
> 
> The webservice is implemented in java and creates an PythonInterpreter
> object which loads the jython scripts.
> I wrote an jython script which uses a function from another jython
> file called library.py.

...

> ImportError: no module named javaos in library.py.
> 
> Any ideas?

You need to make sure that the Jython Lib directory is on sys.path - the
easiest way it to put it in the same directory as jython.jar e.g. in
your webapp have:

WEB-INF/
lib/
jython.jar
Lib/
...
os.py
...

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

RE: All leading tabs or all leading spaces - why isn't that enforced?

[Delaney, Timothy (Tim)]

John Nagle wrote:

>One can argue over tab vs. space indentation, but mixing the two
> is just wrong.  Why not have CPython report an error if a file has
> both leading tabs and leading spaces?  I know that was proposed at
> some point, but I don't think it ever went in. That would catch a
> common error introduced during maintenance.

To warn about mixed tabs and spaces:
python -t 

RE: Broken MUA interactions

[Delaney, Timothy (Tim)]

Ben Finney wrote:

> If your MUA is not using the information, provided in every message
> from the mailing list, to do what you want, don't ask mailing list
> admmministrators to accomodate your broken MUA.

There would be nothing wrong with an MUA for example, having a "reply"
button where the user could choose if it defaulted to "reply to author",
"reply to all", "reply to all except me" or "reply to list" depending on
the presence of the right headers and number of recipients. I'd like
such an MUA - I'd default it to replying to list when applicable.

But such an MUA should also provide the option for doing any of those
for each individual message as well. They could also have "reply to only
people in the To: header", "reply to only people in the CC: header", etc
if they wanted.

I have a company-mandated use of Outlook, which does *not* give me the
above options (it only has "reply" and "reply to all"). And I still
prefer mailing lists to do the right thing.

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

RE: deleated bios?

[Delaney, Timothy (Tim)]

acprkit wrote:

> Hi
> 
> I have an ibm thinkpad x23, and shut it down about an hour ago. When I
> went to
> reboot , all the lights come on then they go off and only the light
> with the z in a circle stays on. The screen stays blank and the hard
> drive spins. Could I have deleated the bios when I added memory
> (shocked the motherboard?)

http://www.catb.org/~esr/faqs/smart-questions.html#forum

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

RE: Plugging a pseudo-memory leak

[Delaney, Timothy (Tim)]

Adam Atlas wrote:

> I have a program that seemed to be leaking memory, but after
> debugging, it seemed it just wasn't getting around to collecting the
> objects in question often enough. The objects are very long-lived, so
> they probably end up in generation 2, and don't get collected for a
> long time. Is there any way I can force collection of these objects? I
> know in Python 2.5 there's gc.collect(2), but I want to keep it
> compatible with previous versions of Python.

Best way is to not create cycles. See if you can change some strong
references to weakrefs.

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

RE: Probably simple syntax error

[Delaney, Timothy (Tim)]

Dustin MacDonald wrote:

> [code]
> randomizing_counter = 0
> # Put the loop counter for the randomizing to zero.
> until_val = 36
> # Set the "until val" to 36. We'll compare them to make sure we're not
> at the end of our wordlist_both.
> 
> while randomizing_counter < until_val:
>   big_randomized_int = RandRange(0,100)
>   # Make a random value and store it.
>   small_randomized_int = big_randomized_int / 100
>   # Divide that random value and store it in a different variable.
>   small_randomized_int = Round(small_randomized_int, 2)
>   # Round that value to 2 decimal places
>   **weights_array(randomizing_counter) = small_randomized_int
>   # Assign the first randomized value to our first word to be
weighted.
>   randomizing_counter = randomizing_counter + 1
>   # Up the counter and repeat.
> [/code]
> 
> The starred line is the one getting the error message: "SyntaxError:
> can't assign to function call"

You should always copy and paste the exception you receive (including
the stack trace). Anyway, read the exception *carefully*. It says "can't
assign to function *call*". In the line:

   weights_array(randomizing_counter) = small_randomized_int

"weights_array(randomizing_counter)" is a function call. My guess is
that you think you're trying to modify an element of "weights_array"
(your code doesn't show us what weights_array is, but I'm guessing it's
actually a list), but parentheses are not the syntax for element access
(subscripting) in Python.

You should read the python tutorial:
http://docs.python.org/tut/tut.html

especially the sections on lists:
http://docs.python.org/tut/node5.html#SECTION00514

and functions:
http://docs.python.org/tut/node6.html#SECTION00660

Cheers,

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

RE: Q: listsort and dictsort - official equivalents?

[Delaney, Timothy (Tim)]

Steve Howell wrote:

> I think Gabriel was making the point that the *input*
> to sorted() cannot be a generator, even thought
> sorted() itself could in theory be a generator with
> the right underlying implementation (e.g. heapsort).

Actually, the input to sorted() can be any iterable - sorted puts all the 
elements into a new list, sorts the new list, then returns the new (sorted) 
list.

This means you can't return any items until you've exhausted the input iterable 
- which is what Gabriel was really getting at. Because of the documented 
semantics, it also must return the entire list.

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

RE: Python 2.5.1 - sqlite3.dll issue

[Delaney, Timothy (Tim)]

Delaney, Timothy (Tim) wrote:

> Josh Ritter wrote:
> 
>> A number of our Windows customers have an issue with the sqlite3
>> module included with Python 2.5.1
>> 
>> We've tracked the problem down to the sqlite3.dll included with the
>> Python 
>> 2.5.1 distrubtion.  It is stripped and thus cannot be relocated. 
>> This causes the following exception on computers where something is
>> already loaded into the address the sqlite3.dll wants to use:
>> 
>> File "sqlite3\__init__.pyc", line 24, in 
>> File "sqlite3\dbapi2.pyc", line 27, in 
>> ImportError: DLL load failed: Invalid access to memory location.
>> 
>> I downloaded the latest sqlite3.dll from http://www.sqlite.org and
>> this fixes the problem.  (This dll isn't stripped)
> 
> Could you raise a bug report on SourceForge please?
> http://sourceforge.net/tracker/?group_id=5470&atid=105470&func=add

OK - I've raised bug report 1733134 for this. I would strongly encourage
people though to get their own SourceForge account so they can
participate in the Python development process.

Cheers,

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

RE: Python 2.5.1 - sqlite3.dll issue

[Delaney, Timothy (Tim)]

Josh Ritter wrote:

> A number of our Windows customers have an issue with the sqlite3
> module included with Python 2.5.1
> 
> We've tracked the problem down to the sqlite3.dll included with the
> Python 
> 2.5.1 distrubtion.  It is stripped and thus cannot be relocated.  This
> causes the following exception on computers where something is already
> loaded into the address the sqlite3.dll wants to use:
> 
> File "sqlite3\__init__.pyc", line 24, in 
> File "sqlite3\dbapi2.pyc", line 27, in 
> ImportError: DLL load failed: Invalid access to memory location.
> 
> I downloaded the latest sqlite3.dll from http://www.sqlite.org and
> this fixes the problem.  (This dll isn't stripped)

Could you raise a bug report on SourceForge please?
http://sourceforge.net/tracker/?group_id=5470&atid=105470&func=add

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

RE: lists - append - unique and sorted

[Delaney, Timothy (Tim)]

Terry Reedy wrote:

> "Dan Bishop" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>> If you don't need the list to be sorted until you're done building
>> it, you can just use: 
>> 
>> lst = sorted(set(lst))
> 
> ?? looks same as
> lst.sort()

You missed that the OP wants only unique values from the original list.

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

RE: Trying to choose between python and java

[Delaney, Timothy (Tim)]

Duncan Booth wrote:

> "Hamilton, William " <[EMAIL PROTECTED]> wrote:
> 
>> 
>> No, they'll work just fine.  They just won't work with Python 3. 
>> It's not like the Python Liberation Front is going to hack into your
>> computer in the middle of the night and delete you 2.x installation.
> 
> Is that a breakaway group from the PSU?

Splitters!

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

RE: Why NOT only one class per file?

[Delaney, Timothy (Tim)]

Bruno Desthuilliers wrote:

> I came to this conclusion from my own experience, and it seems that
> quite a few other programmers (most of them either better and/or more
> experimented than me) came to the same conclusion. But feel free to

Been more experimented on, or have experimented more on others?

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

RE: tuples, index method, Python's design

[Delaney, Timothy (Tim)]

Carsten Haese wrote:

> assert current_player in p
> opponents = tuple(x for x in p if x is not current_player)

That would perform better as:

opponents = tuple(x for x in p if x is not current_player)
assert opponents

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

RE: RFC: Assignment as expression (pre-PEP)

[Delaney, Timothy (Tim)]

Alex Martelli wrote:

>> As others have mentioned, your particular instance is probably
>> evidence that you need to restructure your code a little bit, but I
>> do agree that "x = y; if x: ..." is a common enough idiom that it
>> warrants a shortcut. And reusing "as", I think, is nice and readable,
>> and it's an advantage that it doesn't require adding any new keywords
>> or symbols.
> 
> Actually, I agree with you.  Unfortunately, I doubt python-dev will,
> but the chance is good enough that it's probably worth proposing there
> (ideally together with a patch to implement it, just to avoid any
> [otherwise likely] whines about this being difficult to implement:-).

This was proposed on python-dev (or maybe it was python-ideas) - I think
the discussion died out though without any resolution.

You should check the archives to see if there was a resolution on it,
and if not I'd suggest putting a PEP together, rather than just raising
it again.

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

RE: how can I clear a dictionary in python

[Delaney, Timothy (Tim)]

Antoon Pardon wrote:

> People are often enough not very exact in their communication and
> that goes double for people who are new in a particular subject.
> So I think it is entirely appropiate to think about the real question
> the person is strugling with that hides between the question
> actually asked.
> 
> Yes sometimes those who try to guess the intentions of the OP
> are going totally off in the wrong direction. But I have also
> seen those people providing very helpfull information, while
> those that would stick to the "actual" question didn'y provide
> very usefull information.

And yet it's giving the *wrong* information if the person was asking
exactly the question they intended to ask.

If you think there is some ambiguity, you should *clarify* the question
before answering. Answering a different question to the one that is
asked just causes problems, and the kind of thread this has degenerated
into.

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

RE: Mocking OpenOffice in python?

[Delaney, Timothy (Tim)]

"Your father was a hamster, and your mother smelled of elderberry."

Oh - unit testing. 

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

RE: Python Source Code Beautifier

[Delaney, Timothy (Tim)]

Alan Franzoni wrote:

> Yeah, that's right, it could have semantic differences, but that
> shouldn't be the case anyway. I mean, if I don't define an __iadd__
> method, writing 
> 
> a += n
> 
> or
> 
> a = a + n
> 
> is just the same, right?
> 
> So, if I bother to define an __iadd__ method, I should make sure it
> works just the same, or I would introduce a very strange and
> hard-to-understand behaviour.

As you've seen, that's not the case. The *whole point* of having
__iadd__ is to perform an *in-place* add i.e. mutate the object you're
assigning to.

So it's the behaviour of *immutable* objects that is the exception. The
other semantics of immutable objects cover that though - you should
never rely on whether two equal immutable objects (like integers) are
the same or different objects.

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

RE: Python Source Code Beautifier

[Delaney, Timothy (Tim)]

Alan Franzoni wrote:

>> self.scriptcount = self.scriptcount + 1 => self.scriptcount += 1
> 
> the += operator is syntactic sugar just to save time... if one
> doesn't use it I don't think it's a matter of beauty.

This change can have semantic differences, and so should not be done for
anything except basic, immutable objects (such as integers). As such, it
can't be done automatically.

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

RE: a=b change b a==b true??

[Delaney, Timothy (Tim)]

[EMAIL PROTECTED] wrote:

> All,
> It works great now.  Thank you for all of your incredibly quick
> replies.
> Rob

You should have a read of these:

http://wiki.python.org/moin/BeginnersGuide
http://effbot.org/zone/python-objects.htm

Cheers,

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

RE: [OT] python notation in new NVIDIA architecture

[Delaney, Timothy (Tim)]

Daniel Nogradi wrote:

>>> Something funny:
>>> 
>>> The new programming model of NVIDIA GPU's is called CUDA and I've
>>> noticed that they use the same __special__ notation for certain
>>> things as does python. For instance their modified C language has
>>> identifiers such as __device__, __global__, __shared__, etc. Is it
>>> a coincidence? Probably it is. :)
>> 
>> Cuda is usually taken as short for "barracuda", a fish. Fish have
>> been known to slither under the right circumstances. Perhaps this is
>> the link? 
> 
> Wow! How is it that I didn't think about this before?! Thanks a
> million! 

Actually, I think it's more likely to be a direct link to the Fish
Slapping Dance ...

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

RE: BeautifulSoup modified to use weak refs and avoid circular links.

[Delaney, Timothy (Tim)]

John Nagle wrote:

> "weakref.proxy()" probably should work that way.
> Weakref proxies are supposed to be transparent, but they're not
> quite transparent enough.

Submit a patch to SourceForge. Please don't use tabs in email/usenet
postings - use 4-space indents. "return" is not a function, and
comparisons with "None" should nearly always use "is".

I've also changed backref() to use isinstance(obj, tuple) (available in
Python 2.2 and later):

def backref(p):
if p is None:
return None

if isinstance(p, (weakref.ProxyType,
weakref.CallableProxyType)):
return p

return weakref.proxy(p)

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

RE: is it possible to remove the ':' symbol in the end of lines startingwith 'if', 'while' etc?

[Delaney, Timothy (Tim)]

[EMAIL PROTECTED] wrote:

> I don't know to which forum should I post the message
> I hope someone related to the Python kernel development will read &
> consider the idea

It has been considered and rejected.

http://www.python.org/doc/faq/general/#why-are-colons-required-for-the-i
f-while-def-class-statements

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

RE: f---ing typechecking

[Delaney, Timothy (Tim)]

Nick Craig-Wood wrote:

> Which appears to support my point, x (and a for that matter) are the
> same for both methods wheter you do x = x + a or x += a.
>
> The mechanism is different certainly, but the result should be the
> same otherwise you are breaking the basic rules of arithmetic the
> programmer expects (the rule of least suprise).

No - for a mutable object, x may be bound to the original, but
*modified* object after augmented assignment. Any name also bound to
that object will therefore refer to the modified object.

For an immutable object, augmented assignment will not ever modify the
original object.

The two operations may have *very* different effects.

>>> a = [1]
>>> b = [2]
>>> c = a
>>> d = a
>>> c = a + b
>>> a, b, c
([1], [2], [1, 2])
>>> id(a), id(b), id(c)
(11082528, 11271104, 11082328)
>>> a += b
>>> a, b, c
([1, 2], [2], [1, 2])
>>> id(a), id(b), id(c), a is d
(11082528, 11271104, 11082328, True)

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

RE: f---ing typechecking

[Delaney, Timothy (Tim)]

Nick Craig-Wood wrote:

> x += a
> 
> does not equal
> 
> x = x + a
> 
> which it really should for all types of x and a

Actually, this will *never* be the case for classes that do in-place
augmented assignment.

a = [1]
b = [2]

c = a + b
print a, b, c

a += b
print a, b, c

You'll note that I didn't rebind 'a' in the non-augmented assignment. If
you do, augmented and non-augmented assignment may look the same, but
they can be very different.

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

RE: Method overloading?

[Delaney, Timothy (Tim)]

Steven D'Aprano wrote:

> This is an example of overloading:
> 
> class Cheese(object):
> def flavour(self):
> return "tasty and scrumptious"
> def colour(self):
> return "yellow"
> 
> Now we define a sub-class which overloads some methods:
> 
> class BlueVein(Cheese):
> def colour(self):
> return "white with blue veins"

Nope - while the term "overloading" is definitely overloaded, the above
is not an example of any use of "overloading".

It is an example of "overriding".

The most common use of "overloading" refers to having multiple methods
on a class with the same name, but different signatures.

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

RE: python not returning true

[Delaney, Timothy (Tim)]

John Machin wrote:

agent-s wrote:
>> btw Steven you are so witty I hope to one day pwn noobs on newsgroups
>> too.
> 
> Wit has nothing to do with it. The fact that you are a Python noob is
> also irrelevant. Your problem statement was unintelligible, as is your
> response. What does "pwn" mean?

Or to put it more succinctly ...
http://www.catb.org/~esr/faqs/smart-questions.html

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

RE: Conditional expressions - PEP 308

[Delaney, Timothy (Tim)]

Colin J. Williams wrote:

> Yes, I agree.  The ternary operator is a step forward.

That's still debateable ;)

Pro: It puts paid to the "python doesn't have a ternary operator" and
and/or abuse.

Con: It shouldn't ever be used.

Cheers,

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

RE: Fall of Roman Empire

[Delaney, Timothy (Tim)]

Hendrik van Rooyen wrote:

> naaah - you don't have to worry - for real control He uses assembler.
> with jump statements.
> so the loops are closed.
> 
> Unfortunately its not open source.  Yet.

People are working hard on reverse-engineering it though. I hope no one
slaps them with a DMCA-style lawsuit ...

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

RE: glibc detected double free or corruption

[Delaney, Timothy (Tim)]

Grant Edwards wrote:

> When I try to run pycadia
>  
> I get the following error message as soon as I click "start game"
> 
> *** glibc detected *** python: double free or corruption (out):
> 0xbff43b10 *** 
> 
> Then the program locks up and has to be killed with a SIGKILL.
> 
> pycadia is a pure-python program that uses pygame, pygtk, and
> gtk.glade. Any ideas on how to troubleshoot this problem?

The most likely thing is that there is indeed a double free - probably a
missing INCREF (or possibly an extra DECREF) in one of the extensions.

For a less likely cause ... was python (or any of the C extensions)
compiled with -Os by any chance? What version of gcc? I've had the same
issue with a C++ program, where changing from -Os to -O2 appears to have
resolved the issue. I was cross-compiling for a different architecture,
so it's possible in my case that alignment optimisations that -Os
doesn't do were causing the problem.

But a missing INCREF or extra DECREF are the most likely causes.

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

RE: trees

[Delaney, Timothy (Tim)]

vertigo wrote:

> Hello
> 
> What library/functions/classes could i use to create trees ?

I would suggest either a horticultural or religious class. I'm sure that
any library will contain functional texts on both.

Or you could just read the following:
http://www.catb.org/~esr/faqs/smart-questions.html

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

RE: merits of Lisp vs Python

[Delaney, Timothy (Tim)]

Ken Tilton wrote:

>> But this is not a case where a function can't handle the job.
> 
> Is, too.

And Ken moves one step closer towards Python ...
http://www.google.com.au/search?q=monty+python+argument+sketch

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

RE: problems caused by very large for-loop

[Delaney, Timothy (Tim)]

sam wrote:

> so far so good, but i was using 'for i in the range(iterations):' a
> for loop over each slice of time, where the number of iterations was
> getting into the tens of millions. up until about 125,000,000 it
> worked, then i got a MemoryError.

Your analysis was correct - range() returns a list containing all the
integers, which in this case would chew up a *very* large chunk of
memory.

Even worse, because all the integers are instantiated at once, that very
large chunk of memory would not be made available for anything except
integers (due to the way Python allocates memory for integers).

The canonical way to deal with this is to use xrange().

for i in xrange(iterations):

This simply maintains an internal counter, rather than instantiating a
list of all the integers.

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

RE: dict.has_key(x) versus 'x in dict'

[Delaney, Timothy (Tim)]

[EMAIL PROTECTED] wrote:

> Hendrik> why? - the main point is actually that the code worked,
> and was Hendrik> stable - that should make you proud, not
> embarrassed.  that Hendrik> there is far too much emphasis on
> doing things the quickest way Hendrik> - as long as it works, and
> is fast enough, its not broken, so Hendrik> don't fix it...
> 
> That's the rub.  It wasn't fast enough.  I only realized that had
> been a problem once I fixed it though.

Yep - it's so often the case that scaling problems don't turn up in
developer testing, but only in the field ... and sometimes in much less
obvious ways than Skip's case. I had one where the particulars of the
data I was using meant that what was meant to be an O(1) HashMap lookup
(yes, Java - boo) was essentially an O(n) lookup much of the time. For a
lot of the data, the key chosen ended up being the same (resulting in
the hashmap having very long chains). By using additional data in the
key as a tie-breaker, I got back my normal-case O(1) behaviour.

In this particular case though ...

dict.has_key(x)
x in dict.keys()

one is obviously clearer than the other, as well as being faster.

Of course (getting back to the original question), in current python:

x in dict

is obviously the clearest, and fastest method, and should always be
preferred over either of the above.

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

RE: syntax error in sum(). Please explicate.

[Delaney, Timothy (Tim)]

John Machin wrote:

> Michael Press wrote:
>> I have not written python codes nor run any. I saw this
>> code posted and decided to try it. It fails. I read the
>> tutorial and the entry for the built in function sum,
>> but still do not see the problem. The code was cut and
>> paste.
> 
> I doubt it -- "none" should be "None"

Not necessarily. He said he cut-and-pasted - I interpreted that to be
from *his* editor. But since he was getting a SyntaxError, he would not
have hit the NameError yet ...

All-in-all, this actually felt like a post from someone who *had* read:
http://www.catb.org/~esr/faqs/smart-questions.html

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

RE: Python development time is faster.

[Delaney, Timothy (Tim)]

Éric Daigneault wrote:

> This being said  after a bit of experience in programming, design
> patterns and other marvels of the modern brains, doing bad code in
> python requires a conscious effort to do.  The bright side is that it
> gives all the justification to reviewers to smack the offenders on
> the head with a hardcover copy of the GoF.

Thankfully that book retains some usefulness as a LART, because about 90% of 
what's not printed on the inside front and rear covers is made redundant by 
using Python .

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

RE: Fatal Python error: deallocating None

[Delaney, Timothy (Tim)]

George Sakkis wrote:

> What makes the problem worse is that it's not deterministic; I can
> restart it from (a little before) the point of crash and it doesn't
> happen again at the same point, but it might happen further down. Now,
> I wouldn't mind restarting it manually every time since the crashes
> are not all that frequent; problem is, it's supposed to be a
> long-running process that will probably take days to finish normally,
> so I want it to run overnight too. Any hints ?

None should *never* be deallocated, so it sounds like it's not being
INCREFed correctly somewhere. Extension module, etc ...

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

RE: Sorting by item_in_another_list

[Delaney, Timothy (Tim)]

Fredrik Lundh wrote:

> Delaney, Timothy (Tim) wrote:
> 
>> This is a requirement for all implementations claiming to be 2.3 or
>> higher.
> 
> the language reference only guarantees this for CPython:
> 
>  The C implementation of Python 2.3 introduced a stable
>  sort() method, but code that intends to be portable across
>  implementations and versions must not rely on stability.

http://docs.python.org/lib/typesseq-mutable.html

(9) Starting with Python 2.3, the sort() method is guaranteed to be
stable. A sort is stable if it guarantees not to change the
relative order of elements that compare equal -- this is helpful
for sorting in multiple passes (for example, sort by department,
then by salary grade).

That says pretty strongly to me that it's part of the language
specification. And I'm pretty sure Guido said as much when he
pronounced.

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

RE: Sorting by item_in_another_list

[Delaney, Timothy (Tim)]

Carsten Haese wrote:

> The current documentation states that "Starting with Python 2.3, the
> sort() method is guaranteed to be stable." However, it's not clear
> whether this specifies language behavior that all implementations must
> adhere to, or whether it simply documents an implementation detail of
> CPython.

This is a requirement for all implementations claiming to be 2.3 or
higher.

The "key" parameter was only introduced in 2.4 ...

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

RE: Sorting by item_in_another_list

[Delaney, Timothy (Tim)]

Cameron Walsh wrote:

> Hi,
> 
> I have two lists, A and B, such that B is a subset of A.
> 
> I wish to sort A such that the elements in B are at the beginning of
> A, and keep the existing order otherwise, i.e. stable sort.  The
> order of elements in B will always be correct.
> 
> for example:
> 
> A = [0,1,2,3,4,5,6,7,8,9,10]
> B = [2,3,7,8]
> 
> desired_result = [2,3,7,8,0,1,4,5,6,9,10]

c = set(B)
a.sort(key=c.__contains__, reverse=True)

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

RE: productivity and long computing delays

[Delaney, Timothy (Tim)]

Paul Rubin wrote:

> Anyone got any suggestions?  How do you deal with this?  It could be
> mitigated with a faster computer (I'm using a 1.2 ghz Pentium M) but
> the overall task isn't large enough to justify going out and buying
> one.  Anyway, I did the same build on a 2 ghz Athlon 64 and was
> surprised that the speedup was only 35% or so.  I'd have to get a
> multiprocessor box to obtain really substantial gains.

Sounds like a typical time/money tradeoff to me. How much is your time
worth to you on this project? If you can reduce the delay by 50%, and do
it 10 times, you could well pay for a new Core 2 Duo machine.

As an alternative, do you have multiple machines you could use? Perhaps
you could use distributed compilation.

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

RE: does anybody earn a living programming in python?

[Delaney, Timothy (Tim)]

walterbyrd wrote:

> If so, I doubt there are many.
> 
> I wonder why that is?

Well, I'm not qualified to analyse the reasons for your doubts, but I'd
guess it's because you have preconceived notions.

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

RE: Python programs always open source?

[Delaney, Timothy (Tim)]

Steve Holden wrote:

> Given that many people distribute (enough of) the interpreter with
> their Python programs I wouldn't like the above to be regarded as a
> blanket statement that the Python license doesn't have to be
> considered when distributing the interpreter with program source.

In practice, such a blanket statement can be made because the Python
Software License is so liberal. However, anyone who is distributing any
part of Python should definitely read the license themselves.

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

RE: Are Python's reserved words reserved in places they dont need tobe?

[Delaney, Timothy (Tim)]

Antoon Pardon wrote:

> This is just an idea of mine, nothing I expect python to adapt.
> But just suppose the language allowed for words in bold. A word
> in bold would be considered a reserved word, a word in non bold
> would be an identifier.

Exactly how am I supposed to use my text editor to make words bold? Is
every text editor supposed to understand a "python format" for code?

Besides, I don't like bold for keywords (or anything in code) - I like
my keywords blue (RGB 0, 0, 255). Of course, with a "python format", I
could make *my* keywords blue. But I can pretty much guarantee that my
preferred editor will not ever understand "python format".

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

RE: python reference counting and exceptions

[Delaney, Timothy (Tim)]

Andreas Huesgen wrote:

> In c++, it is possible to write a locking system similar to the one
> below: 
> 
> 
> void myFunction()
> {
>   # create a resource lock. Locks some resource
>   ResourceLock myLock;
> 
>   # the following line may throw an exception
>   doStuff();
> }

RIIA - Resource Initialisation is Acquisition

Python is adding an RIIA mechanism in 2.5 - look at the "with"
statement.

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

RE: Question about using python as a scripting language

[Delaney, Timothy (Tim)]

Carl Banks wrote:

> Delaney, Timothy (Tim) wrote:
>> Steve Lianoglou wrote:
>> 
>>> So, for instance, you can write:
>>> my_list = eval('[1,2,3,4]')
>> 
>> This is just asking for trouble.
>> 
>> my_list = eval('import shutil; shutil.rmtree('/')')
> 
> Fortunately, that won't work because eval expects an expression.
> Unfortunately, this will:
> 
> my_list = eval('__import__("shutil").rmtree("/")')

Yeah - forgot the specifics in getting the point across ;)

To answer the other question - when should you use eval? When the
risk/reward warrants it. What is the risk of using eval (or exec) on
untrusted code?

Note that you *have* to decide where the line is drawn, because
effectively all .py files run through the same process (not quite, but I
hope you can see where I'm going). For me, the line in nearly every case
is to not use eval/exec - use something else that validates - like
int().

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

RE: Newbie - How to iterate list or scalar ?

[Delaney, Timothy (Tim)]

Bruno Desthuilliers wrote:

> What I wonder here is why __iter__ has been added to lists and tuples
> but not to strings (not that I'm complaining, it's just curiousity...)

Because someone got around to doing it.

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

RE: Question about using python as a scripting language

[Delaney, Timothy (Tim)]

Steve Lianoglou wrote:

> One thing you could do is use the eval or compile methods. These
> functions let you run arbitray code passed into them as a string.
> 
> So, for instance, you can write:
> my_list = eval('[1,2,3,4]')

This is just asking for trouble.

my_list = eval('import shutil; shutil.rmtree('/')')

Terry's approach is much better. Another alternative is to create a
dictionary mapping an action name to a function. Basically the same as
Terry's solution, but the dictionary lookup is explicit (as opposed to
being hidden as method names).

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