Re: Convert all images to JPEG

[Fredrik Lundh]

"Thomas" <[EMAIL PROTECTED]> wrote:

> I got a bunch of different images of different types ( bmp, gif, png,
> tiff etc ) and I want to convert them all to JPEGs using PIL. Is this
> possible? When I try I get all sorts of errors, doing something like :
>
> im = Image.open(srcImage) # might be png, gif etc, for instance
> test1.png
> im.thumbnail(size, Image.ANTIALIAS) # size is 640x480
> im.save(targetName, "JPEG") # targetname is test1.jpg
>
> produces an exception. Any clues?

the exception contains a pretty strong clue:

"IOError: cannot write mode P as JPEG"

adding

if im.mode != "RGB":
im = im.convert("RGB")

between the open and thumbnail calls fixes this.

 



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

Problem in threading

[Gurpreet Sachdeva]

I have written a code to figure out the difference in excecution time
of a func before and after using threading...

[CODE]
#!/usr/bin/env python

import threading
import time
loops = [5000,5000]

def loop(self, nsec):
for i in range(1,nsec):
t=i*5000
s=t/10*1

def main():
threads = []
nloops = [0,1]
for i in nloops:
print '\nSpawning Thread',i,' value: ',loops[i]
t = threading.Thread(target=loop,args=(i, loops[i]))
threads.append(t)

for i in nloops: # start threads
threads[i].start()

for i in nloops: # wait for all
threads[i].join

if __name__ == '__main__':
start = time.clock()
loop(1,5000)
print 'Time Taken: ', time.clock()-start
start = time.clock()
main()
print 'Time Taken: ', time.clock()-start
[/CODE]

Some times this code executes and some times it hangs to death :o(
Am I am doing something wrong?? Also the difference of time is not much...
How do we best optimize our task by using threads... please help...

Thanks and Regards,
Gurpreet Singh
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Problem in threading

[Fredrik Lundh]

Gurpreet Sachdeva wrote:

>for i in nloops: # wait for all
>threads[i].join

threads[i].join()

 



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

Re: Problem in threading

[Alex Martelli]

Gurpreet Sachdeva <[EMAIL PROTECTED]> wrote:

> for i in nloops: # wait for all
> threads[i].join

Missing () after 'join'.


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

Re: Problem in threading

[Gurpreet Sachdeva]

>threads[i].join()

Oh thanks I corrected that but still the time taken after using thread
is more without using them

Please Advice...
Thanks,
Gurpreet Singh
-- 
http://mail.python.org/mailman/listinfo/python-list

MDaemon Warning - virus found: Python-list@python.org

[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.zip   I-Worm.Mydoom.m  Removed


**


Your message was not delivered due to the following reason:

Your message could not be delivered because the destination server 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:
Mail server 216.135.199.86 is not responding.

The following recipients could 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: built-in 'property'

[Alex Martelli]

Steven Bethard <[EMAIL PROTECTED]> wrote:

> For this reason, I usually suggest declaring properties like[1]:
> 
> py> class E(object):
> ... def x():
> ... def get(self):
> ... return float(self._x)
> ... def set(self, x):
> ... self._x = x**2
> ... return dict(fget=get, fset=set)
> ... x = property(**x())
> ... def __init__(self, x):
> ... self._x = x
> ...
> py> e = E(42)
> py> e.x
> 42.0
> py> e.x = 3
> py> e.x
> 9.0
> 
> Note that by using the x = property(**x()) idiom, I don't pollute my 
> class namespace with get/set/del methods that aren't really useful to
> instances of the class.  It also makes it clear to subclasses that if
> they want different behavior from the x property that they'll need to
> redefine the entire property, not just a get/set/del method.
> 
> Steve
> 
> [1] Thanks to whoever originally suggested this! Sorry, I've forgotten
> who...

In the Cookbook 2nd ed, I credited Sean Ross, the author of the CB
recipe proposing this (with credit also to David Niegard and Holger
Krekel for important comments whose contents I merged into the recipe).

Of course there are several possible variations, such as
return locals()
instead of return dict(&c)...


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

Re: Problem in threading

[Binu K S]

You haven't split the task between the threads here.
loops should be set to [2500,2500] for a correct comparison.

On a single processor system, a tight loop like the one you are
testing will at best show the same time as the non-threaded case. Most
likely the threaded version will take more time on single processor
systems due to the thread context switching overhead.

On a multi-processor system too, you are likely to see the same
figures since what you are measuring with time.clock is the amount of
CPU time taken. That will be the same in the threaded and non-threaded
case. On the multi-processor system you will see a difference in
actual time taken by both. You could use time.time to measure that.

On Wed, 29 Dec 2004 14:33:12 +0530, Gurpreet Sachdeva
<[EMAIL PROTECTED]> wrote:
> >threads[i].join()
> 
> Oh thanks I corrected that but still the time taken after using thread
> is more without using them
> 
> Please Advice...
> Thanks,
> Gurpreet Singh
> --
> http://mail.python.org/mailman/listinfo/python-list
>
-- 
http://mail.python.org/mailman/listinfo/python-list

portable text user interface

[Maxim Kasimov]

Hi.
Are there widely used and recommended Python libraries that will
let me makes a portable text user interface?
--
Best regards,
Maxim
--
http://mail.python.org/mailman/listinfo/python-list

what would you like to see in a 2nd edition Nutshell?

[Alex Martelli]

I'm considering proposing to O'Reilly a 2nd edition of "Python in a
Nutshell", that I'd write in 2005, essentially to cover Python 2.3 and
2.4 (the current 1st edition only covers Python up to 2.2).

What I have in mind is not as complete a rewrite as for the 2nd vs 1st
edition of the Cookbook -- Python hasn't changed drastically between 2.2
and 2.4, just incrementally.  Language and built-ins additions I'd of
course cover -- decorators, custom descriptors (already in 2.2 but not
well covered in the 1st edition), importing from zipfiles, extended
slicing of built-in sequences, sets, genexps, ... and also major new
standard library modules such as (in no special order) optparse,
tarfile, bsddb's new stuff, logging, Decimal, cookielib, datetime,
email... and new capabilities of existing modules, such as thread-local
storage.  Outside of the standard library, I was thinking of expanding
the coverage of Twisted and adding just a few things (numarray --
perhaps premature to have it _instead_ of Numeric, though; dateutils,
paramiko, py2app...).  Since the book's size can't change much, I'll
also have to snip some stuff (the pre-email ways to deal with mail, for
example; modules asyncore and asynchat, probably) to make space for all
of the additions.

I haven't take any real decisions about it, yet, except one: I'll keep
covering Tkinter, rather than moving to, say, wxPython (no space to
_add_ wx coverage while leaving Tk intact - having to choose, I still
believe Tkinter coverage is going to help more readers).  Just about
everything else is still to be finalized in my mind...

So, if there's any advice or request about a 2nd edition of the
Nutshell, this is the right time for y'all to let me know.  Feedback is
welcome, either privately or right here.  Thanks in advance -- _and_
apologies in advance because I know I just won't be able to accomodate
all the requests/advice, given the constraints on book size &c.


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

Re: Why tuples use parentheses ()'s instead of something else like <>'s?

[Brian Beck]

[EMAIL PROTECTED] wrote:
Wouldn't it have been better to define tuples with <>'s or {}'s or
something else to avoid this confusion??
Well, to comment on the part that nobody else did...
< and > are binary operators, a la 3 > 1, "one" < "two"
and {}'s are clearly already used for dictionaries.
--
Brian Beck
Adventurer of the First Order
--
http://mail.python.org/mailman/listinfo/python-list

Re: Tkinter vs wxPython

[Alejandro Weinstein]

> Sure wxGlade/Boa/etc can help speed design and layout up, but what
> happens when you want to do non standard things or just get stuck
> because some thing just isn't working.

Then you add the necesary hand crafted code to the automatic 
generated code. At least is what I did when I needed.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Problem in threading

[Duncan Booth]

Gurpreet Sachdeva wrote:

> Also the difference of time is not much...
> How do we best optimize our task by using threads... please help...
> 

For most tasks splitting the processing into separate threads will result 
in an increase in the total time to complete the task. The only times when 
it may result in a decrease in the running time are when the time the task 
takes does not entirely depend on the time taken by the CPU, or when 
multiple CPU's are involved.

Unfortunately the latter case isn't handled well by Python, so don't expect 
multiple CPU's to help speed up a multi-threaded Python program by very 
much. That leaves the former case: if your task has to stop and wait for 
something else to happen (e.g. data to be read from a network, or to be 
read from a disc file), then splitting it into multiple threads may allow 
the waits to be overlapped with useful processing which could result in an 
overall decrease in processing time.

A good use of threads is to improve responsiveness of a system. For example 
if you ensure that GUI processing happens on a separate thread from some 
CPU intensive computation then you can ensure that the GUI remains 
responsive while the computation is running. It won't make the computation 
complete any faster (in fact it will probably be slower), but the user will 
remain happier. Similarly network applications are usually multi-threaded 
so that all requests get a fair chance to complete instead of having to 
wait for the slowest to complete before others can run.

If you do have multiple processors available and want to speed up a Python 
program then you probably have to look at multiple processes rather than 
multiple threads. Alternatively you could move parts of the processing out 
of the Python environment by rewriting inner loops in C and releasing the 
interpreter lock, but that isn't usually the best option.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: what would you like to see in a 2nd edition Nutshell?

[TZOTZIOY]

On Wed, 29 Dec 2004 11:35:18 +0100, rumours say that [EMAIL PROTECTED]
(Alex Martelli) might have written:

[snip: things to cover in a tentative 2nd edition of the nutshell]

>and new capabilities of existing modules, such as thread-local
>storage.

...which I most surely missed learning about it.  Sometimes it's hard
following all the changes, and amk's _What's New_ didn't mention it too
(I'm sending a copy of this post to amk).  In case others didn't know
too, Google's first hit using the obvious query points to:

http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/302088

which is providing code and hints how to find out more about
threading.local .

Yes, Alex, I am sure a second version of the Nutshell would be much
needed; now and then there are discussions about good Python books, and
I believe recently someone proposed the Nutshell among others, only to
get the reply "but it only covers up to 2.2".
-- 
TZOTZIOY, I speak England very best.
"Be strict when sending and tolerant when receiving." (from RFC1958)
I really should keep that in mind when talking with people, actually...
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Unicode entries on sys.path

[Thomas Heller]

"Martin v. Löwis" <[EMAIL PROTECTED]> writes:

> Thomas Heller wrote:
>> How should these patches be approached?
>
> Please have a look as to how posixmodule.c and fileobject.c deal with
> this issue.
>
>> On windows, it would probably
>> be easiest to use the MS generic text routines: _tcslen instead of
>> strlen, for example, and to rely on the _UNICODE preprocessor symbol to
>> map this function to strlen or wcslen.
>
> No. This fails for two reasons:
> 1. We don't compile Python with _UNICODE, and never will do so. This
> macro is only a mechanism to simplify porting code from ANSI APIs
> to Unicode APIs, so you don't have to reformulate all the API calls.
> For new code, it is better to use the Unicode APIs directly if you
> plan to use them.
> 2. On Win9x, the Unicode APIs don't work (*). So you need to chose at
> run-time whether you want to use wide or narrow API. Unless
> a) we ship two binaries in the future, one for W9x, one for NT+
>(I hope this won't happen), or
> b) we drop support for W9x. I'm in favour of doing so sooner or
>later, but perhaps not for Python 2.5.

I wasn't asking about the *W functions, I'm asking about string/unicode
handling in Python source files. Looking into Python/import.c, wouldn't
it be required to change the signature of a lot of functions to receive
PyObject* arguments, instead of char* ?
For example, find_module should change from
  static struct filedescr *find_module(char *, char *, PyObject *,
   char *, size_t, FILE **, PyObject **);

to 

  static struct filedescr *find_module(char *, char *, PyObject *,
   PyObject **, FILE **, PyObject **);

where the fourth argument would now be either a PyString or PyUnicode
object pointer?

> (*) Can somebody please report whether the *W file APIs fail on W9x
> because the entry points are not there (so you can't even run the
> binary), or because they fail with an error when called?

I always thought that the *W apis would not be there in win98, but it
seems that is wrong.  Fortunately, how could Python, which links to the
FindFirstFileW exported function for example, run on win98 otherwise...

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

Re: Mutable objects which define __hash__ (was Re: Why are tuples immutable?)

[Nick Coghlan]

Bengt Richter wrote:
A second time a key may be hashed is when it is used as a lookup key. This can 
be a reference to
the identical key object first used, or it can be a new object. A new object 
has to be hashed in order
to have a hash value to use in finding candidate keys to compare to. If _this_ 
object
is used as a key again, it must be hashed again -- unless it is an object that 
caches its own
hash and invalidates it when mutated so it can rehash itself if its __hash__ 
method is subsequently
called.
Thus re-use of a different lookup key than the original provides an opportunity 
for a performance
gain in the lookup if the key object caches it hash value for return by 
__hash__.
That's what I meant by "why not?" in response to your assertion that the 
constant hash restriction
doesn't (ok, I took that as a "can't" ;-) provide any performance gain.
I'm not sure I'm following here. . . for the case of an object caching its own 
hash, that seems to be a performance gain that is independent of the dictionary 
implementation. From the dictionary's point of view, it just calls hash() and 
works with the result, exactly as it does now.

I agree hash caching gives good optimisation - my point was that hash caching 
can be just as effective in the presence of mutable keys, so long as there is 
some way to invalidate the cached hash values when a mutation occurs.

Given that you assume you know when "rehashing" is going to be necessary -- 
meaning you
know when keys mutate.
Well, yes. Antoon's original complaint was that mutable objects could not be 
used as keys in dictionary, even if the application guaranteed key stability for 
the lifetime of the relevant dictionary entry.

I gave dict.rehash as a method equivalent to list.sort when working with 
mutables keys or list entries, respectively.

Or resist the temptation to guess, and have rehash() raise an exception :)
Easy out ;-)
I certainly thought so }:>
The identity keyed dict was based on Antoon's posted use case: he wanted to 
classify mutable objects, and then check for membership in those groups.
I thought he just wanted to use mutables as if they were immutable, so that
equal mutable keys would look up the same value in a dict.
That was in the original post, yes. Later, he gave an example that ran something 
like:

  for node in graph:
if node in some_dict:
  # Do NOT mutate this node
  # Possibly do other things
  continue
# Do something that mutates the (non-key) node
You can use lists for this, but the lookup is slow. Conventional dictionaries 
and sets give a fast lookup, but require that the items in use be hashable.

A constant hash works. But since it clogs a single bucket and gives no clue
of value mismatch, we'd have to time it to see how it compares with list.index.
Did the Timbot do both?
Write them both? I don't know.
However, list.index is a simple linear search of the array of objects (I was 
reading that code recently for unrelated reasons).

The dict hash collision resolution was almost certainly written by Tim - he 
definitely wrote the comments at the top of the file trying to explain how the 
heck it works. I have no real clue as to the performance of the lookup algorithm 
in the degenerate case of a large number of distinct keys having the same hash 
value, but reading the code suggests it would perform worse than the simple 
integer increment that list.index uses (as the dict lookup requires multiple 
if-tests and so forth on each iteration).

An identity dictionary (or set) solves the 'object classification' problem 
perfectly.
I missed the definition of those terms I'm afraid ;-)
It was in some other part of this rambling thread. It's easier to repeat the 
idea than it is to go find where that was :)

An 'identity dictionary' is just a dict that looks up keys based on identity 
rather than value. It ignores the keys' actual hash and comparison operations, 
and forces use of the default hash for hashing, and identity comparison for 
equality testing. It maps from key _objects_ to values, rather than from key 
values to other values.

An 'identity set' is simply the same idea applied to a set instead of a 
dictionary. Conceptually, it stores sets of arbitrary objects, rather than sets 
of values.

The 'object classification' problem is simply the situation where you have an 
existing collection of objects (e.g. graphs of a node), and you want to classify 
them according to some criteria. Dictionaries or sets are a nice way to do that, 
but the standard types are a pain if your original objects are mutable (this 
inconvenience being the basis of Antoon's original complaint).

For a classification problem, though, we're likely only interested in what 
categories each of the original objects falls into - so identity-based storage 
will usually be entirely adequate (and, in some cases, actually better then 
value-based storage, since we can avoid irrelevant comparisons of potentially 
complex objects). And the 

Re: what would you like to see in a 2nd edition Nutshell?

[Arthur]

On Wed, 29 Dec 2004 11:35:18 +0100, [EMAIL PROTECTED] (Alex Martelli)
wrote:

>So, if there's any advice or request about a 2nd edition of the
>Nutshell, this is the right time for y'all to let me know.  Feedback is
>welcome, either privately or right here.  Thanks in advance -- _and_
>apologies in advance because I know I just won't be able to accomodate
>all the requests/advice, given the constraints on book size &c.

I understand in advance that my comments are not fully practical:

The gap in the "market" against which I am currently bumpiong up
against a wall is in gaining an understanding of threads,
sub-processes, sockets, signals and such in Python - having no
background in these concepts from outside of Python.

Programming concepts up to this level can all (or mostly all)
succesfully be learned and understood from materials out there
speaking in Python. As to these concepts, the implicit point of view
seems to be to leave Python to learn the concepts, and return to
Python to understand its implementation of the details, once the
concepts are well grasped.

It seems to me important that this gap be filled. somehow at some
point.  The advice of "go learn threads in Java" and come back then
seems a pity. Some of the other concepts which I am confronting I
understand to be basic for the C programmer.  "This is how Python
implements these C concepts, which we of course all understand".
My hand has been held nicely, too this point then

Learn C and come back?  Love to. Don't have the time.  I am a
practicing Python programmer, hoping that can be enough.  

If I want to no more than be able to follow, say, the current Idle
code of the PyShell module, I can find very little guidance from
within the canon of Python literature.

Help?

Art

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

Re: Are tuple really immutable?

[Chris]

I'm suing Google Groups (beta) which has a treeview and my thanks were
a reply to Fredrik Lundh. In fact I simply clicked a "reply" link below
his post.
Of course you all helped me to better understand the
"mutable/immutable" concept but Fredrik Lundh deserves more thanks
since he replied to all my questions ;-)

Chris

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

Python + Lisp integration?

[Simo Melenius]

Hi,

I'm wondering (after a bit of googling) whether there exists a Python
binding to any open source Lisp environment (like librep or some
Scheme or Common Lisp implementation) that could be recommended for
non-toy use?

My intention would be to use the Lisp environment to augment and help
my Python programming (and/or conversely: have access to the wealth of
Python libraries and Python code from a lispy language), which yields
at least the following requirements:

- the type and runtime environment system would need to be quite
  transparently integrated, e.g. being able to use (pass, call,
  set/get attr) Python objects in Lisp and vice versa with minimum
  hassle

- the performance should match at least that of Python's. That
  probably requires a native interpreter, although the ability to
  compile Lisp to Python bytecode could do (if the lispy language
  could be efficiently implemented in the Python bytecode)

There are many Scheme/Lisp interpreters written in Python, but those
I've found and looked at I consider to be more of proof of concepts.
Nesting different interpreters costs probably an order of magnitude in
speed.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Unicode entries on sys.path

["Martin v. Löwis"]

Thomas Heller wrote:
I wasn't asking about the *W functions, I'm asking about string/unicode
handling in Python source files. Looking into Python/import.c, wouldn't
it be required to change the signature of a lot of functions to receive
PyObject* arguments, instead of char* ?
Yes, that would be one solution. Another solution would be to provide an
additional Py_UNICODE*, and to allow that pointer to be NULL. Most
systems would ignore that pointer (and it would be NULL most of the
time), except on NT+, which would use the Py_UNICODE* if available,
and the char* otherwise.
I always thought that the *W apis would not be there in win98, but it
seems that is wrong.  Fortunately, how could Python, which links to the
FindFirstFileW exported function for example, run on win98 otherwise...
Thanks, that is convincing.
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list

Re: objects as mutable dictionary keys

[Nick Coghlan]

Yeah, that looks like a pretty decent summary to me.  I wonder if this 
would be worth posting on the Wiki somewhere?  Maybe:

http://www.python.org/moin/DictionaryKeys
That makes it easy to point to when this issue comes up again.
The page may also want to mention an extant bug with new-style classes.
The behaviour is *meant* to be:
1. Class defines none of __cmp__, __eq__ or __hash__:
  Default behaviour allows the class to be used as an identity-based dictionary 
key.

2. Class defines __hash__ and __cmp__ (or __eq__):
  Class is usable as a dictionary key, with semantics governed by developer 
supplied methods.

3. Class defines __cmp__ or __eq__, but NOT __hash__:
  Class cannot be used as a dictionary key, as the default hash may not be 
valid for the developer supplied comparison operation.

For classic classes, this works as expected. For new-style classes, case 3 
doesn't work properly - the default hash is inherited from object anyway.

This *is* a bug (since Guido called it such), but one not yet fixed as the 
obvious solution (removing object.__hash__) causes problems for Jython, and a 
non-obvious solution has not been identified.

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

Re: Python + Lisp integration?

[Arthur]

On 29 Dec 2004 14:50:53 +0200, Simo Melenius
<[EMAIL PROTECTED]> wrote:

>
>Hi,
>
>I'm wondering (after a bit of googling) whether there exists a Python
>binding to any open source Lisp environment (like librep or some
>Scheme or Common Lisp implementation) that could be recommended for
>non-toy use?

Not sure this is going to help much,

but Lush - Lisp Universal Shell - is mature and has bindings to the
Python C API.

http://lush.sourceforge.net/lush-manual/f0288067.html

The bindings are specific to Python22.  I had trouble getting all the
demos working against Python23.

Art

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

Re: portable text user interface

[Miki Tebeka]

Hello Maxim,

> Are there widely used and recommended Python libraries that will
> let me makes a portable text user interface?
If you just need a text-like interface you can use Tkinter.
See (shameless plug) http://developer.berlios.de/projects/bcd/ and
http://developer.berlios.de/dbimage.php?id=1112 for example.

If you need something that runs through telnet/ssh ... than curses is what
your looking for. There's a win32 port to it somewhere.

Bye.
--

Miki Tebeka <[EMAIL PROTECTED]>
http://tebeka.bizhat.com
The only difference between children and adults is the price of the toys
-- 
http://mail.python.org/mailman/listinfo/python-list

RE: Other notes

[Batista, Facundo]

Title: RE: Other notes





[EMAIL PROTECTED]


#- Here are some questions and suggestions of mine that I've 
#- collected in
#- the last weeks on the language (please note that some (most?) of them
#- are probably wrong/useless/silly, but I've seen that such 
#- notes help me
#- understand a lot of things and to find my weak spots.)


It's a *very* good idea to address each subject in a different thread.


Personally, maybe there's a point that interest me and where I can participate, but i don't have time to go through the rest of the mails.


.    Facundo


Bitácora De Vuelo: http://www.taniquetil.com.ar/plog
PyAr - Python Argentina: http://pyar.decode.com.ar/



  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

ADVERTENCIA.


La información contenida en este mensaje y cualquier archivo anexo al mismo, son para uso exclusivo del destinatario y pueden contener información confidencial o propietaria, cuya divulgación es sancionada por la ley.

Si Ud. No es uno de los destinatarios consignados o la persona responsable de hacer llegar este mensaje a los destinatarios consignados, no está autorizado a divulgar, copiar, distribuir o retener información (o parte de ella) contenida en este mensaje. Por favor notifíquenos respondiendo al remitente, borre el mensaje original y borre las copias (impresas o grabadas en cualquier medio magnético) que pueda haber realizado del mismo.

Todas las opiniones contenidas en este mail son propias del autor del mensaje y no necesariamente coinciden con las de Telefónica Comunicaciones Personales S.A. o alguna empresa asociada.

Los mensajes electrónicos pueden ser alterados, motivo por el cual Telefónica Comunicaciones Personales S.A. no aceptará ninguna obligación cualquiera sea el resultante de este mensaje.

Muchas Gracias.



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

Santa Clause like you have never seen him before

[joshz]

Santa Clause like you have never seen him before, this is a must see for 
everyone http://paddy.home.comcast.net/


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

Re: Python + Lisp integration?

[Fuzzyman]

Simo Melenius wrote:
> Hi,
>
> I'm wondering (after a bit of googling) whether there exists a Python
> binding to any open source Lisp environment (like librep or some
> Scheme or Common Lisp implementation) that could be recommended for
> non-toy use?
>
> My intention would be to use the Lisp environment to augment and help
> my Python programming (and/or conversely: have access to the wealth
of
> Python libraries and Python code from a lispy language), which yields
> at least the following requirements:
>
> - the type and runtime environment system would need to be quite
>   transparently integrated, e.g. being able to use (pass, call,
>   set/get attr) Python objects in Lisp and vice versa with minimum
>   hassle
>
> - the performance should match at least that of Python's. That
>   probably requires a native interpreter, although the ability to
>   compile Lisp to Python bytecode could do (if the lispy language
>   could be efficiently implemented in the Python bytecode)
>
> There are many Scheme/Lisp interpreters written in Python, but those
> I've found and looked at I consider to be more of proof of concepts.
> Nesting different interpreters costs probably an order of magnitude
in
> speed.


When I looked for one I oculdn't find one. As Common Lisp generally
runs *considerably* faster than Python it could be a useful thing to
have. (Writing python extensions in CLISP would be more 'Pythonic' than
writing them in C ?). A two way binding to GNU CLISP would seem a
sensible one to implement.

Don't think it's already been done though.
Regards,


Fuzzy
http://www.voidspace.org.uk/python/index.shtml

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

Re: Using python to deploy software

[secun]

Sounds interesting.

Do you know if he/she would be willing to share the code?


Anand wrote:
> I haven't but one of my friends have used Pyro (Python Remote
Objects)
> to do so.
>
> You basically need to write a custom Pyro server and run it on a
> central machine. Your pyro clients can be installed on the machines
> where the software need to be installed.
>
> For more details and similar ideas refer the project page of pyro at
> http://pyro.sourceforge.net/projects.html .
> 
> -Anand

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

Re: ANN: GallerPy 0.6.0

[Fuzzyman]

Nice one Freddie. You beat me to it - I had adding a 'header_file' type
thingy to gallerpy on my list of things to do. gallerpy will be
replacing my static galleries on voidspace 'soon'.
Regards,

Fuzzy
http://www.voidspace.org.uk/python/index.shtml

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

MySQLdb Windows Installer (2.4) published [was: Problems installing MySQLdb on Windows [newbie]]

[Steve Holden]

Alex Meier wrote:
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
http://pydish.holdenweb.com/pwp/MySQL-python.exe-1.0.0.win32-py2.4.exe
That's a ready-to-go no-compilation-required installer for Windows 
Python 2.4, and will get you going straight away.

Thanx a lot, Steve! This worked without a hitch.
Great. I don't know what Andy Dustman's situation is right now, but he's 
clearly not got time to maintain MySQLdb. Since it's likely other people 
will want this I've added it to the Holden Web public domain Python page 
at http://www.holdenweb.com/Python/index.html -- that way Google might 
pick it up, who knows.

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: Why tuples use parentheses ()'s instead of something else like <>'s?

[Steve Holden]

Marius Bernklev wrote:
* [EMAIL PROTECTED]

Perhaps ()'s are a good idea for some other reason I don't know?

One-element tuples are written as (4,).
And, even there, the parenthesis is only required when it would 
otherwise be embiguous:

 >>> x = 4,
 >>> x
(4,)
 >>> print 4,
4
 >>>
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

[Poll] Frameworks for Web Development

[Antonio Cangiano]

Dear all,
I want to propose a small "poll" about frameworks & tools that you 
use to develop web applications in Python. I think it would be 
interesting if you could list your favourite tools as well as explain the 
reasons for your choice. 
 
Thanks in advance,
Antonio--My programming blog: http://antoniocangiano.com

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

Re: Tkinter vs wxPython

[Steve Holden]

Alejandro Weinstein wrote:
Sure wxGlade/Boa/etc can help speed design and layout up, but what
happens when you want to do non standard things or just get stuck
because some thing just isn't working.

Then you add the necesary hand crafted code to the automatic 
generated code. At least is what I did when I needed.
I've tried a number of these tools, including BlackAdder, wxDesigner, 
wxGlade and BoaConstructor. I even paid money for some of them. They all 
have their problems, and I keep coming back to good old PythonCard. It's 
kinda clunky (though I have most experience with the 0.7 prototype, and 
the newer releases are improving), but it's definitely the most usable 
of all the ones I've tried. Dammit, you can actually *do stuff* with it 
rather than spend all your time fighting the tool.

The only complaint I have is the need to add components from a menu 
rather than a tool, but I patched 0.7 to fix that, and I believe it will 
be possible to patch the 0.8 series to operate the same way.

Whether I'll ever persuade Kevin Altis to include the patch in a live 
release is, of course, a question for another day :-)

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: Why tuples use parentheses ()'s instead of something else like <>'s?

[John Roth]

<[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
Tuples are defined with regards to parentheses ()'s as everyone knows.
To expand on what Alex Martelli said:
Tuples don't use parentheses except for the special case of the
empty tuple. Those are expression parentheses. The two most
obvious cases of this are in the return statement and sequence
unpacking in assignment statements.
Grouping syntax is used for both unary operators and operands.
Parentheses are used for expressions (operands) and
function/method parameter lists (operators). Brackets ([])
are used for lists (operands) and subscripts/slices (operators).
Braces ({}) are used for dictionarys (operands). They aren't
currently used for unary operators.
John Roth
Please enlighten me as I really want to know.
Chris
P.S. I love Python!
--
http://mail.python.org/mailman/listinfo/python-list

Re: portable text user interface

[Fuzzyman]

Miki Tebeka wrote:
> Hello Maxim,
>
> > Are there widely used and recommended Python libraries that will
> > let me makes a portable text user interface?
> If you just need a text-like interface you can use Tkinter.
> See (shameless plug) http://developer.berlios.de/projects/bcd/ and
> http://developer.berlios.de/dbimage.php?id=1112 for example.
>

Hello Miki,

Your project looks very interesting. It would be better if it displayed
an error message if it can't find the '_bcdrc' file. If you run it from
windoze it just appears and disapears.

How about allowing the '_bcdrc' file to be in the same directory as the
script as well.

Any chance of you releasing the Tkinter text interface as a separate
library, with a less restrictive license ? It looks very good - but I
can't use it in my projects if it is GPL.

Regards,

Fuzzy
http://www.voidspace.org.uk/python/index.shtml

> If you need something that runs through telnet/ssh ... than curses is
what
> your looking for. There's a win32 port to it somewhere.
>
> Bye.
> --
>

> Miki Tebeka <[EMAIL PROTECTED]>
> http://tebeka.bizhat.com
> The only difference between children and adults is the price of the
toys

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

Re: what would you like to see in a 2nd edition Nutshell?

[TZOTZIOY]

On Wed, 29 Dec 2004 14:05:18 +0200, rumours say that Christos "TZOTZIOY"
Georgiou <[EMAIL PROTECTED]> might have written:

>[snip: things to cover in a tentative 2nd edition of the nutshell]

[Alex]
>>and new capabilities of existing modules, such as thread-local
>>storage.

[I]
>...which I most surely missed learning about it.  Sometimes it's hard
>following all the changes, and amk's _What's New_ didn't mention it too
>(I'm sending a copy of this post to amk)

...and most promptly amk replied by pointing to 

http://docs.python.org/whatsnew/node13.html

where it is indeed mentioned.  So I stand corrected, mea culpa etc :)
-- 
TZOTZIOY, I speak England very best.
"Be strict when sending and tolerant when receiving." (from RFC1958)
I really should keep that in mind when talking with people, actually...
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Why tuples use parentheses ()'s instead of something else like <>'s?

[Grant Edwards]

On 2004-12-29, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:

> Tuples are defined with regards to parentheses ()'s as everyone knows.

Except they're not.  

>>> x = 1,2,3,4
>>> type(x)

>>> 

Tuples are defined by the infix comma "operator".

-- 
Grant Edwards   grante Yow!  I'm working under
  at   the direct orders of WAYNE
   visi.comNEWTON to deport consenting
   adults!
-- 
http://mail.python.org/mailman/listinfo/python-list

learning about threads and processes (was Re: what would you like to see in a 2nd edition Nutshell?)

[Alex Martelli]

Arthur <[EMAIL PROTECTED]> wrote:
   ...
> speaking in Python. As to these concepts, the implicit point of view
> seems to be to leave Python to learn the concepts, and return to
> Python to understand its implementation of the details, once the
> concepts are well grasped.

Hmmm, well, the concepts are reasonably independent of the programming
language involved.  If anything, threads and processes may be more tied
to whatever _operating system_ you're using.  A very fundamental but
good introduction to processes (and other such basics) is for example at
, but it
will be only partially applicable if you need to understand in depth the
process-model of Windows.  But of course this is about the concepts, not
the practice of programming to interact with them.


> If I want to no more than be able to follow, say, the current Idle
> code of the PyShell module, I can find very little guidance from
> within the canon of Python literature.
> 
> Help?

Hmmm - have you looked at Deitel, Deitel, Liperi, Wiedermann, "Python
how to program", chapters 18 (Process Management) and 19
(Multithreading), pages 613-687?  They seem to do a rather workmanlike
job -- of course, they can't do full justice to the subjects in 75
pages; and if you don't want to buy a vast, costly 1300-pages tome for
the sake of those 75 pages, I can't really blame you, either.  Still,
without some clarification of how (if at all) those 75 pages fail to
meet your learning needs, it's hard to know what else to suggest.  And
what about Norman Matloff's
, the first
google hit if you're looking for
python threads
?  I haven't looked into it, but, again, without some specific
explanation of how it fails to meet your needs, it's hard to offer
alternatives.

It is, of course, out of the question that the Nutshell can get into the
tutorial business -- MY space budget for the whole "Threads and
processes" chapter is around 20 small pages, and I personally consider
it quite a feat to have managed to fit within that compass 4 pages of
advice on threaded program architecture as well as a down-to-the-bone
reference to modules threading, Queue, os (process-related subset) _and_
mmap;-).  Still, others _are_ writing Python tutorials, and it does seem
that books such as "Learning Python" and even "Dive into Python" are
(understandably, I guess) avoiding the subject... so, pinpointing what's
being looked for by learners, which Deitel et al, Matloff, etc, are
missing, might help future editions and versions of such books...


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

Re: what would you like to see in a 2nd edition Nutshell?

[Thomas Heller]

[EMAIL PROTECTED] (Alex Martelli) writes:

> I'm considering proposing to O'Reilly a 2nd edition of "Python in a
> Nutshell", that I'd write in 2005, essentially to cover Python 2.3 and
> 2.4 (the current 1st edition only covers Python up to 2.2).
>
> What I have in mind is not as complete a rewrite as for the 2nd vs 1st
> edition of the Cookbook -- Python hasn't changed drastically between 2.2
> and 2.4, just incrementally.  Language and built-ins additions I'd of
> course cover -- decorators, custom descriptors (already in 2.2 but not
> well covered in the 1st edition), importing from zipfiles, extended
> slicing of built-in sequences, sets, genexps, ... and also major new
> standard library modules such as (in no special order) optparse,
> tarfile, bsddb's new stuff, logging, Decimal, cookielib, datetime,
> email... and new capabilities of existing modules, such as thread-local
> storage.  Outside of the standard library, I was thinking of expanding
> the coverage of Twisted and adding just a few things (numarray --
> perhaps premature to have it _instead_ of Numeric, though; dateutils,
> paramiko, py2app...).  Since the book's size can't change much, I'll
> also have to snip some stuff (the pre-email ways to deal with mail, for
> example; modules asyncore and asynchat, probably) to make space for all
> of the additions.
>
> I haven't take any real decisions about it, yet, except one: I'll keep
> covering Tkinter, rather than moving to, say, wxPython (no space to
> _add_ wx coverage while leaving Tk intact - having to choose, I still
> believe Tkinter coverage is going to help more readers).  Just about
> everything else is still to be finalized in my mind...
>
> So, if there's any advice or request about a 2nd edition of the
> Nutshell, this is the right time for y'all to let me know.  Feedback is
> welcome, either privately or right here.  Thanks in advance -- _and_
> apologies in advance because I know I just won't be able to accomodate
> all the requests/advice, given the constraints on book size &c.

I found the discussion of unicode, in any python book I have, insufficient.

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

Re: what would you like to see in a 2nd edition Nutshell?

[djw]

I found the discussion of unicode, in any python book I have, insufficient.
Thomas

+1
Don
--
http://mail.python.org/mailman/listinfo/python-list

Re: Why tuples use parentheses ()'s instead of something else like <>'s?

[Roy Smith]

In article <[EMAIL PROTECTED]>,
 Grant Edwards <[EMAIL PROTECTED]> wrote:

> On 2004-12-29, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> 
> > Tuples are defined with regards to parentheses ()'s as everyone knows.
> 
> Except they're not.  
> 
> >>> x = 1,2,3,4
> >>> type(x)
> 
> >>> 
> 
> Tuples are defined by the infix comma "operator".

Well, the syntax is a little more complicated than that.  Commas don't 
form tuples in a lot of places:

f (1, 2, 3)# function call gets three scalar arguments
[1, 2, 3]  # list of three integers, not list of tuple
[x, 1 for x in blah]   # syntax error, needs to be [(x, 1) for ...]

I'm sure there are others.  The meaning of "," depends on the context in 
which it appears.  In most cases, the parens around tuples are optional 
except when necessary to disambiguate, but there's one degenerate 
special case, the empty tuple (zerople?), where the parens are always 
required.  It's just one of those little warts you have to live with.

If Python had originally been invented in a unicode world, I suppose we 
wouldn't have this problem.  We'd just be using guillemots for tuples 
(and have keyboards which made it easy to type them).
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: what would you like to see in a 2nd edition Nutshell?

[terraplane]

As an already-experienced programmer, I came to Python via this book
and still use it as my primary reference.

As a Python beginner, I had a difficult time with the section on
"Slicing a sequence" (p. 47).  In particular, a better explanation and
examples of negative indicies would be helpful.

This is nitpicking in what I consider to be a very good book.  I hope
the second edition flies.

Cheers,
  Steve

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

Re: extract news article from web

[Simon Brunning]

On 22 Dec 2004 09:22:15 -0800, Zhang Le <[EMAIL PROTECTED]> wrote:
> Hello,
> I'm writing a little Tkinter application to retrieve news from
> various news websites such as http://news.bbc.co.uk/, and display them
> in a TK listbox. All I want are news title and url information. 

Well, the BBC publishes an RSS feed[1], as do most sites like it. You
can read RSS feed with Mark Pilgrim's Feed Parser[2].

Granted, you can't read *every* site like this. But I daresay that
*most* news related sites publish feeds of some kind these days. Where
they do, using the feed is a *far* better idea than trying to parse
the HTML.

-- 
Cheers,
Simon B,
[EMAIL PROTECTED],
http://www.brunningonline.net/simon/blog/
[1] http://news.bbc.co.uk/2/hi/help/3223484.stm
[2] http://feedparser.org/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: what would you like to see in a 2nd edition Nutshell?

[Scott David Daniels]

Alex Martelli wrote:
I'm considering proposing to O'Reilly a 2nd edition of "Python in a
Nutshell", that I'd write in 2005, essentially to cover Python 2.3 and
2.4 (the current 1st edition only covers Python up to 2.2).
So, if there's any advice or request about a 2nd edition of the
Nutshell, this is the right time for y'all to let me know.  Feedback is
welcome, either privately or right here.  Thanks in advance -- _and_
apologies in advance because I know I just won't be able to accomodate
all the requests/advice, given the constraints on book size &c.
 * code coverage tools for python code (testing your tests).
 * new-style classes forward and old-style shrunk.  "best practices"
   such as "always super(class, self).__init__(...)" and why even if
   why is only a forward reference.  Using Left(object), Right(object),
   Top(Left, Right) would be good for the example.
   ** Fix the examples in "Inheritance in new-style object model", the
  diagram, and the following example in "cooperative superclass
  method calling" to use the same hierarchy.  I personally prefer
  the A(object), B(A), C(A), D(B,C) hierarchy, but they should
  match.
 * implementing types/classes in C -- a checklist w/ advice on testing.
--Scott David Daniels
[EMAIL PROTECTED]
--
http://mail.python.org/mailman/listinfo/python-list

Re: what would you like to see in a 2nd edition Nutshell?

[Fuzzyman]

I second that
Regards,

Fuzzy
http://www.voidspace.org.uk/python/index.shtml

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

Re: what would you like to see in a 2nd edition Nutshell?

[beliavsky]

I like the current edition. Since it is a reference work, I would like
to see it in a CD-ROM as well as in print, either packaged with a book
or as part of a Python CD Bookshelf, analogous to the other CD
bookshelves O'Reilly offers.

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

Re: Why are tuples immutable?

[Scott David Daniels]

Antoon Pardon wrote:
Op 2004-12-23, Scott David Daniels schreef <[EMAIL PROTECTED]>:
This is half the problem.  In the period where an element is in the
wrong hash bucket, a new entry for the same value can be created in
the proper hash bucket.  Then the code will have to determine how to
merge two entries at rehash time.
But similar problems can happen in a sorted list, where the sort
is done on a "key" of the data and where you don't want duplicate
"keys".
If you then mutate a "key", it may be possible to insert a duplicate
"key" in the sorted list because the list isn't sorted anymore. If
you then resort your list you also have to determine how to merge
the two items with the same "key"
I'd say this is a stretch.  The "key" argument to sort is very new, and
it is a function from data to a value.  The "key" can be mutated only if
the key function is picking out a mutable part of a data element.
This just to show that repairing sorted lists can be just as
troublesome as repairing dictionaries. People who think 
sorted lists of mutable objects is less bothersome as dictionaries
with mutable keys, haven't thought things through IMO.
But Python has no "sorted list" data type, so it is perfectly reasonable
to expect such lists to go through transitional representations.  A set
should not briefly have duplicate elements, a list should not vary in 
length when elements are replaced, an integer being continuously
incremented should not be viewable from a separate thread as anything
but monotonicly increasing; dictionaries are primitives and should not
have observable transitional states.

--Scott David Daniels
[EMAIL PROTECTED]
--
http://mail.python.org/mailman/listinfo/python-list

Re: learning about threads and processes (was Re: what would you like to see in a 2nd edition Nutshell?)

[Aahz]

In article <[EMAIL PROTECTED]>,
Alex Martelli <[EMAIL PROTECTED]> wrote:
>
>Hmmm - have you looked at Deitel, Deitel, Liperi, Wiedermann, "Python
>how to program", chapters 18 (Process Management) and 19
>(Multithreading), pages 613-687?  They seem to do a rather workmanlike
>job -- of course, they can't do full justice to the subjects in 75
>pages; and if you don't want to buy a vast, costly 1300-pages tome for
>the sake of those 75 pages, I can't really blame you, either.  

Except that it's a really, really piss-poor book.  That's an opinion
which I believe you've agreed with previously.

>And what about Norman Matloff's
>, the first
>google hit if you're looking for
>python threads
>?  I haven't looked into it, but, again, without some specific
>explanation of how it fails to meet your needs, it's hard to offer
>alternatives.

That's actually pretty good.
-- 
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

Re: objects as mutable dictionary keys

[Stian Søiland]

On 2004-12-29 14:04:19, Nick Coghlan wrote:

> This *is* a bug (since Guido called it such), but one not yet fixed as the 
> obvious solution (removing object.__hash__) causes problems for Jython, and 
> a non-obvious solution has not been identified.

class object:
def __hash__(self):
# Need to check if our instance has defined some other
# comparison functions without overloading __hash__ 
for f in "__cmp__ __eq__".split():
if not hasattr(self, f):
continue
# It has the function, but is it the same as in
# object?
f1 = getattr(self, f)
f2 = getattr(object, f)
if f1.im_func != f2.im_func:
raise TypeError, "unhashable instance"

 return id(self)
(..)

Of course this won't work, as self.__cmp__ and it's like are so-called 
method-wrapper objects, and I can't immediately see a way to retrieve
the original function behind this.

Also, it might be possible that someone does something like this:

class A(object):
def __init__(self, use_id=True):
self.use_id = use_id

def __eq__(self, other):
if self.use_id:
return super(A, self).__eq__(other)
else:
return something_else

def __hash__(self, other):
if self.use_id:
return super(A, self).__hash__(other)
else:
return something_else

This will break the object.__hash__  shown above..  What about checking
if __hash__ has been overridden as well, and if so, always return id()?
 

-- 
Stian Søiland   Work toward win-win situation. Win-lose
Trondheim, Norway   is where you win and the other lose.
http://soiland.no/  Lose-lose and lose-win are left as an
exercise to the reader.  [Limoncelli/Hogan]
Og dette er en ekstra linje 
--
http://mail.python.org/mailman/listinfo/python-list

Re: Why tuples use parentheses ()'s instead of something else like <>'s?

[John Roth]

"Roy Smith" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
In article <[EMAIL PROTECTED]>,
Grant Edwards <[EMAIL PROTECTED]> wrote:
On 2004-12-29, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Tuples are defined with regards to parentheses ()'s as everyone knows.
Except they're not.
>>> x = 1,2,3,4
>>> type(x)

>>>
Tuples are defined by the infix comma "operator".
Well, the syntax is a little more complicated than that.  Commas don't
form tuples in a lot of places:
f (1, 2, 3)# function call gets three scalar arguments
[1, 2, 3]  # list of three integers, not list of tuple
[x, 1 for x in blah]   # syntax error, needs to be [(x, 1) for ...]
I'm sure there are others.  The meaning of "," depends on the context in
which it appears.
This is true, however all three cases you mention are part
of the grammar. In any case, the function call syntax isn't
dependent on it following a function name; it's dependent
on it appearing where an operator is expected in the
expression syntax.
In most cases, the parens around tuples are optional
except when necessary to disambiguate, but there's one degenerate
special case, the empty tuple (zerople?), where the parens are always
required.  It's just one of those little warts you have to live with.
That one doesn't require the comma, either. It's a very definite
special case.
If Python had originally been invented in a unicode world, I suppose we
wouldn't have this problem.  We'd just be using guillemots for tuples
(and have keyboards which made it easy to type them).
I suppose the forces of darkness will forever keep Python from
requiring utf-8 as the source encoding. If I didn't make a fetish
of trying to see the good in everybody's position, I could really
work up a dislike of the notion that you should be able to use
any old text editor for Python source.
There are a lot of Unicode characters that would be quite
helpful as operators. A left pointing arrow would be a vast
improvement over the equal sign for assignment, for example.
There wouldn't be any chance of mixing it up with the double
equal for comparisons. The same thing goes for multiplication
and division. We've allowed ourselves to be limited by the
ASCII character set for so long that improving that seems to be
outside of most people's boxes.
John Roth 

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

calling functions across threads

[Steven Bethard]

I'm playing around with some threading stuff right now, and I'm having a 
little trouble calling a function from one thread that affects another. 
 Here's my setup:

py> import os, threading, time
py> def write(file_in, input_lines):
... for line in input_lines:
... time.sleep(0.5)
... file_in.write(line)
... file_in.flush()
... file_in.close()
...
py> def read(file_out, output_list):
... while True:
... line = file_out.readline()
... if not line:
... break
... output_list.append(line)
...
py> def runthreads(lst):
... file_in, file_out, file_err = os.popen3('cat')
... write_thread = threading.Thread(
... target=write, args=(file_in,
... ['%s\n' % x for x in range(10)]))
... read_thread = threading.Thread(target=read,
...args=(file_out, lst))
... write_thread.start()
... read_thread.start()
... write_thread.join()
... read_thread.join()
...
Basically, I start one thread to read and one thread to write (from a 
os.pipe).  This all works fine for me:

py> lst = []
py> runthreads(lst)
py> lst
['0\n', '1\n', '2\n', '3\n', '4\n', '5\n', '6\n', '7\n', '8\n', '9\n']
I run into a problem though when I try to call an update method every 
time I read a line:

py> class updatinglist(list):
... def __init__(self, updater):
... super(updatinglist, self).__init__()
... self.updater = updater
... def append(self, item):
... super(updatinglist, self).append(item)
... self.updater(len(self))
...
py> def update(i):
... print i
...
py> lst = updatinglist(update)
py> runthreads(lst)
1
2
3
4
5
6
7
8
9
10
py> lst
['0\n', '1\n', '2\n', '3\n', '4\n', '5\n', '6\n', '7\n', '8\n', '9\n']
I get the correct output, but if you run this yourself, you'll see that 
the numbers 1 through 10 aren't printed in sync with the writes (i.e. 
every half second); they're all printed at the end.  Could someone 
explain to me why this happens, and how (if possible) I can get the 
numbers printed in sync with the appends to the list?

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

Re: Other notes

[Mike Meyer]

[EMAIL PROTECTED] writes:

> @infix
> def interval(x, y): return range(x, y+1) # 2 parameters needed
>
> This may allow:
> assert 5 interval 9 == interval(5,9)

I don't like the idea of turning words into operators. I'd much rather
see something like:

@infix('..')
def interval(x, y):
return range(x, y + 1)

assert 5 .. 9 == interval(5, 10)

This would also allow us to start working on doing away with the magic
method names for current operators, which I think would be an
improvement.

As others have pointed out, you do need to do something about operator
precedence. For existing operators, that's easy - they keep their
precedence. For new operators, it's harder.

You also need to worry about binding order. At the very least, you
can specify that all new operators bind left to right. But that might
not be what you want.

  http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
-- 
http://mail.python.org/mailman/listinfo/python-list

RE: Best GUI for small-scale accounting app?

[Gabriel Cosentino de Barros]

Title: RE: Best GUI for small-scale accounting app?






From: Paul Rubin [mailto:"http://phr.cx"@NOSPAM.invalid]
> This still seems way too complicated.  Why execute a bunch of separate
> statements when what you're trying to set up is a single structure?


IMHO, i think that the code to create elements is the less important one. I put myself to learn python toolkits in one day. I picked up gtk, tk and wxWindow.

I learned how to create the elements in seconds. all have a fairly good documentation on that. But when it cames down to position stuff... that was hell.

Or you have a easy way to position things, but are limited for text direction (important in multi-locale programs), limited in font size (important for multiple resolutions) and mainly limited in window resizing (you have to write code for resize). Or you have to add two hundred panes and invisible elements to have flexibility on the above issues.

What i'm doing now, is to learn very all Tk, and make a xml scheme for UI.




    
        
            
        
        
            
            
        
    



Easy to visualize. I'm just struggling with the best way to deal with runtime modifications of the GUI... apreciate any comments (this will be up on sourceforce soon)

Gabriel



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

RE: Best GUI for small-scale accounting app?

[Gabriel Cosentino de Barros]

Title: RE: Best GUI for small-scale accounting app?





> But even then, if DaBo ever becomes as easy to use as Delphi/VB for this 
> type of applications, while remaining cross-platform, that might easily 
> double the number of Python developers.  ;-)


VB/delphi are ridiculous. dont' aim to that direction. the ONLY reason both are "sucessful" is that they're widely deployed. There's thousands of college professors that only got their positions because they have M$certs or are in the institution long enough to know people who can keep their positions and never minded learning something else then pascal and cobol.

Then, they show VB/delphi to the newcomers, how  get a pirated copy and start wasting time over it.



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

RE: Best GUI for small-scale accounting app?

[Gabriel Cosentino de Barros]

Title: RE: Best GUI for small-scale accounting app?






> > - speed where it matters (ie. no 20s load time)
>
>   Load what? The app, or the data? Users don't care how long the app 
> takes to start up, since they usually run it all day long. Data 
> response is a whole 'nother matter, and Dabo is extremely fast in that 
> regard. After all, a data set is nothing more than lists of lists, and 
> Python is wicked fast with list handling.


 as a jEdit, mozilla, and bloated games user i can assure you that you're right at some point, but as a openoffice hater, you can see it's not the lawn even with one single user.

So, to be more direct: If you create one app that opens one window with one button in wxWindow and exit (exit, so that 'time' can canculate it for you), and then the same thing in Dabo, what's the time diference?

Thanks,
Gabriel



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

Re: Other notes

[Steve Holden]

Mike Meyer wrote:
[EMAIL PROTECTED] writes:

@infix
def interval(x, y): return range(x, y+1) # 2 parameters needed
This may allow:
assert 5 interval 9 == interval(5,9)

I don't like the idea of turning words into operators. I'd much rather
see something like:
@infix('..')
def interval(x, y):
return range(x, y + 1)
assert 5 .. 9 == interval(5, 10)
This would also allow us to start working on doing away with the magic
method names for current operators, which I think would be an
improvement.
Well, perhaps you can explain how a change that's made at run time 
(calling the decorator) can affect the parser's compile time behavior, 
then. At the moment, IIRC, the only way Python code can affect the 
parser's behavior is in the __future__ module, which must be imported at 
the very head of a module.

As others have pointed out, you do need to do something about operator
precedence. For existing operators, that's easy - they keep their
precedence. For new operators, it's harder.
Clearly you'd need some mechanism to specify preference, either 
relatively or absolutely. I seem to remember Algol 68 allowed this.

You also need to worry about binding order. At the very least, you
can specify that all new operators bind left to right. But that might
not be what you want.
Associativity and precedence will also have to affect the parsing of the 
code, of course. Overall this would be a very ambitious change.

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

Re: Other notes

[Jp Calderone]

On Wed, 29 Dec 2004 11:42:00 -0600, Mike Meyer <[EMAIL PROTECTED]> wrote:
>[EMAIL PROTECTED] writes:
> 
> > @infix
> > def interval(x, y): return range(x, y+1) # 2 parameters needed
> >
> > This may allow:
> > assert 5 interval 9 == interval(5,9)
> 
> I don't like the idea of turning words into operators. I'd much rather
> see something like:
> 

  Really?  I like "not", "and", "or", "is", and "in".  It would not be nice 
if they were replaced with punctuation.

  This aside, not even Python 3.0 will be flexible enough to let you define
an infix decorator.  The language developers are strongly against supporting 
macros, which is what an infix decorator would amount to.

  Now, they might be convinced to add a new syntax that makes a function 
into an infix operator.  Perhaps something like this:

def &(..)(x, y):
return range(x, y + 1)

  This is much better than supporting macros because it will lead to a 6 
month long debate over the exact syntax and adds exactly zero other 
features to the language (whereas macros let you pick your own syntax 
and give you essentially unlimited other abilities).

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

copying classes?

[harold fellermann]

Hi all,
In the documentation of module 'copy' it is said that "This version 
does not copy types like module, class, function, method, stack trace, 
stack frame, file, socket, window, array, or any similar types."

Does anyone know another way to (deep)copy objects of type class? What 
is special about the objects of these types that they cannot be easily 
copied?

Any help appreciated,
- harold -
--
I like pigs. Dogs look up to us. Cats look down to us.
Pigs treat us as equal.
-- Winston Churchill
--
http://mail.python.org/mailman/listinfo/python-list

RE: A scoping question

[Gabriel Cosentino de Barros]

Title: RE: A scoping question





> myBaseClass.AddChild(file2.NextClass())
> [snip]
> class NextClass:
> def __init__(self):
> for eachChild in myBaseClass.MyChilds:  # <- ERROR
> ...



I never assumes globals in my classes. always pass them as parameters. it's safer and better to understand later. Also, makes it easier to reuse the code later on.

myBaseClass.AddChild( file2.NextClass( myBaseClass ) )



Gabriel



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

Re: Python + Lisp integration?

[Erno Kuusela]

hello,

you might want to look at  .

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

Re: Using python to deploy software

[secun]

Would the pyro client need to be installed as a service on the machine
so it could run the installer as the system acct? Otherwise, it would
run with the current user's credentials.

Anand wrote:
> I haven't but one of my friends have used Pyro (Python Remote
Objects)
> to do so.
>
> You basically need to write a custom Pyro server and run it on a
> central machine. Your pyro clients can be installed on the machines
> where the software need to be installed.
>
> For more details and similar ideas refer the project page of pyro at
> http://pyro.sourceforge.net/projects.html .
> 
> -Anand

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

Re: Other notes

[Mike Meyer]

Jp Calderone <[EMAIL PROTECTED]> writes:

> On Wed, 29 Dec 2004 11:42:00 -0600, Mike Meyer <[EMAIL PROTECTED]> wrote:
>>[EMAIL PROTECTED] writes:
>> 
>> > @infix
>> > def interval(x, y): return range(x, y+1) # 2 parameters needed
>> >
>> > This may allow:
>> > assert 5 interval 9 == interval(5,9)
>> 
>> I don't like the idea of turning words into operators. I'd much rather
>> see something like:
>
>   Really?  I like "not", "and", "or", "is", and "in".  It would not be nice 
> if they were replaced with punctuation.

They can't be turned into operators - they already are.

>   This aside, not even Python 3.0 will be flexible enough to let you define
> an infix decorator.  The language developers are strongly against supporting 
> macros, which is what an infix decorator would amount to.

Could you please explain how allowing new infix operators amount to
supporting macros?

>   Now, they might be convinced to add a new syntax that makes a function 
> into an infix operator.  Perhaps something like this:
>
> def &(..)(x, y):
> return range(x, y + 1)

And while you're at it, explain how this method of defining new infix
operators differs from using decorators in such a way that it doesn't
amount to supporting macros.

 http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Other notes

[Mike Meyer]

Steve Holden <[EMAIL PROTECTED]> writes:

> Mike Meyer wrote:
>
>> [EMAIL PROTECTED] writes:
>>
>>>@infix
>>>def interval(x, y): return range(x, y+1) # 2 parameters needed
>>>
>>>This may allow:
>>>assert 5 interval 9 == interval(5,9)
>> I don't like the idea of turning words into operators. I'd much
>> rather
>> see something like:
>> @infix('..')
>> def interval(x, y):
>> return range(x, y + 1)
>> assert 5 .. 9 == interval(5, 10)
>> This would also allow us to start working on doing away with the
>> magic
>> method names for current operators, which I think would be an
>> improvement.
>>
> Well, perhaps you can explain how a change that's made at run time
> (calling the decorator) can affect the parser's compile time behavior,
> then. At the moment, IIRC, the only way Python code can affect the
> parser's behavior is in the __future__ module, which must be imported
> at the very head of a module.

By modifying the parsers grammer at runtime. After all, it's just a
data structure that's internal to the compiler.

http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: copying classes?

[Bob Van Zant]

copy.deepcopy() should do the trick. This URL answers a little bit of
your question about the difficulties in copying "complex" data
structures.

http://pydoc.org/2.3/copy.html

-Bob

On Wed, 2004-12-29 at 19:29 +0100, harold fellermann wrote:
> Hi all,
> 
> In the documentation of module 'copy' it is said that "This version 
> does not copy types like module, class, function, method, stack trace, 
> stack frame, file, socket, window, array, or any similar types."
> 
> Does anyone know another way to (deep)copy objects of type class? What 
> is special about the objects of these types that they cannot be easily 
> copied?
> 
> Any help appreciated,
> 
> - harold -
> 
> 
> --
> I like pigs. Dogs look up to us. Cats look down to us.
> Pigs treat us as equal.
> -- Winston Churchill
> 

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

Re: Problem in threading

[Mike Meyer]

Duncan Booth <[EMAIL PROTECTED]> writes:

> That leaves the former case: if your task has to stop and wait for
> something else to happen (e.g. data to be read from a network, or to
> be read from a disc file), then splitting it into multiple threads
> may allow the waits to be overlapped with useful processing which
> could result in an overall decrease in processing time.

If you're on a Unix-like system, you'll use less aspirin if you do
this kind of thing with async I/O and the select module. If you're on
Windows, the restrictions on what you can select on make it much less
useful. Python's threading models is pretty primitive. You get the C
model (which is error-prone), the Java model (in 2.4, and also
error-prone), or Queues. Queues aren't error-prone, but result in the
same kind of behavior as you get with select: start I/O, do computing
while I/O is going on, block until I/O is complete.

http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Best GUI for small-scale accounting app?

[Ed Leafe]

On Dec 29, 2004, at 1:06 PM, Gabriel Cosentino de Barros wrote:
So, to be more direct: If you create one app that opens one window 
with one button in wxWindow and exit (exit, so that 'time' can 
canculate it for you), and then the same thing in Dabo, what's the 
time diference?
	I used the timeit module to run the programs you suggested 10 times 
apiece, and the average times for each were:

plain wxPython: 0.57768230438
Dabo: 0.6913671494
	When you consider that the main app in Dabo also sets up a number of 
things that the wx.PySimpleApp doesn't, this is better than I imagined. 
Thanks for the impetus to run this test.

 ___/
/
   __/
  /
 /
 Ed Leafe
 http://leafe.com/
 http://dabodev.com/
--
http://mail.python.org/mailman/listinfo/python-list

Re: calling functions across threads

[Thomas Rast]

Steven Bethard <[EMAIL PROTECTED]> writes:

> I get the correct output, but if you run this yourself, you'll see
> that the numbers 1 through 10 aren't printed in sync with the writes
> (i.e. every half second); they're all printed at the end.  Could
> someone explain to me why this happens, and how (if possible) I can
> get the numbers printed in sync with the appends to the list?

I tried your code, and got the expected behaviour, i.e. the numbers
are printed every half second.  Maybe you have a buffering problem?

$ python2.4 -V
Python 2.4
$ uname -a
Linux thomas 2.6.9 #6 Sun Dec 19 17:45:53 CET 2004 i686 GNU/Linux

- Thomas

-- 
If you want to reply by mail, substitute my first and last name for
'foo' and 'bar', respectively, and remove '.invalid'.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: copying classes?

[Bob Van Zant]

Ha. I just read down to the bottom of pyDoc page.

"This version does not copy types like module, class, function, method,
nor stack trace, stack frame, nor file, socket, window, nor array, nor
any similar types."

However, I actually tried it and it worked at least in the simple case:
>>> class x:
...   def __init__(self):
... self.y = 1
...
>>> obj = x()
>>> obj.y
1
>>>
>>> import copy
>>> z = copy.deepcopy(obj)
>>> z.y
1
>>> obj.y = 4
>>> obj.y
4
>>> z = copy.deepcopy(obj)
>>> z.y
4

-Bob

On Wed, 2004-12-29 at 10:42 -0800, Bob Van Zant wrote:
> copy.deepcopy() should do the trick. This URL answers a little bit of
> your question about the difficulties in copying "complex" data
> structures.
> 
> http://pydoc.org/2.3/copy.html
> 
> -Bob
> 
> On Wed, 2004-12-29 at 19:29 +0100, harold fellermann wrote:
> > Hi all,
> > 
> > In the documentation of module 'copy' it is said that "This version 
> > does not copy types like module, class, function, method, stack trace, 
> > stack frame, file, socket, window, array, or any similar types."
> > 
> > Does anyone know another way to (deep)copy objects of type class? What 
> > is special about the objects of these types that they cannot be easily 
> > copied?
> > 
> > Any help appreciated,
> > 
> > - harold -
> > 
> > 
> > --
> > I like pigs. Dogs look up to us. Cats look down to us.
> > Pigs treat us as equal.
> > -- Winston Churchill
> > 
> 

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

Re: Other notes

[Jp Calderone]

On Wed, 29 Dec 2004 12:38:02 -0600, Mike Meyer <[EMAIL PROTECTED]> wrote:
>Jp Calderone <[EMAIL PROTECTED]> writes:
> 
> > On Wed, 29 Dec 2004 11:42:00 -0600, Mike Meyer <[EMAIL PROTECTED]> wrote:
> >>[EMAIL PROTECTED] writes:
> >> 
> >> > @infix
> >> > def interval(x, y): return range(x, y+1) # 2 parameters needed
> >> >
> >> > This may allow:
> >> > assert 5 interval 9 == interval(5,9)
> >> 
> >> I don't like the idea of turning words into operators. I'd much rather
> >> see something like:
> >
> >   Really?  I like "not", "and", "or", "is", and "in".  It would not be nice 
> > if they were replaced with punctuation.
> 
> They can't be turned into operators - they already are.
> 

  They weren't operators at some point (if necessary, select this point 
prior to the creation of the first programming language).  Later, they 
were.  Presumably in the interim someone turned them into operators.

> >   This aside, not even Python 3.0 will be flexible enough to let you define
> > an infix decorator.  The language developers are strongly against 
> > supporting 
> > macros, which is what an infix decorator would amount to.
> 
> Could you please explain how allowing new infix operators amount to
> supporting macros?

  You misread - I said "what an infix decorator would amount to".  Adding 
new infix operators is fine and in no way equivalent to macros.

  As you said in your reply to Steve Holden in this thread, one way support 
for @infix could be done is to allow the decorator to modify the parser's 
grammar.  Doesn't this sound like a macro to you?

> 
> >   Now, they might be convinced to add a new syntax that makes a function 
> > into an infix operator.  Perhaps something like this:
> >
> > def &(..)(x, y):
> > return range(x, y + 1)
> 
> And while you're at it, explain how this method of defining new infix
> operators differs from using decorators in such a way that it doesn't
> amount to supporting macros.

  Simple.  You can't do anything except define a new infix operator with 
the hypothetical "def &(  )" syntax.  With real macros, you can 
define new infix operators, along with any other syntactic construct your
heart desires.

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

Re: calling functions across threads

[Steven Bethard]

Thomas Rast wrote:
Steven Bethard <[EMAIL PROTECTED]> writes:
I get the correct output, but if you run this yourself, you'll see
that the numbers 1 through 10 aren't printed in sync with the writes
(i.e. every half second); they're all printed at the end.  Could
someone explain to me why this happens, and how (if possible) I can
get the numbers printed in sync with the appends to the list?

I tried your code, and got the expected behaviour, i.e. the numbers
are printed every half second.  Maybe you have a buffering problem?
$ python2.4 -V
Python 2.4
$ uname -a
Linux thomas 2.6.9 #6 Sun Dec 19 17:45:53 CET 2004 i686 GNU/Linux
FWIW, I'm using Python 2.4 on a Windows XP box.  But it looks like my 
problems were due to using PythonWin.  When I tried the same code at the 
command prompt python, it worked just fine.

Anyone know why PythonWin would do this?  I originally ran into this 
problem using simliar code in a module that I used with the Ellogon 
(www.ellogon.org) framework.  Maybe if I can solve the problem for 
PythonWin, I can translate that into a solution for Ellogon too...

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

Re: what would you like to see in a 2nd edition Nutshell?

[Fernando Perez]

Alex Martelli wrote:

> the coverage of Twisted and adding just a few things (numarray --
> perhaps premature to have it _instead_ of Numeric, though; dateutils,

You might want to keep in touch with the scipy/numarray gang on this particular
topic.  An effort is currently under way to make scipy work with numarray, and
matplotlib already works with numarray out of the box.  These two facts will,
I think, greatly accelerate the adoption of numarray and the transition away
from Numeric.  There are a few people (like me, unfortunately), who can simply
not use numarray because of the small array instatiation overhead.  But that
subcommunity tends to know enough to be able to deal with the problems by
itself.  Since numarray is indeed the long-term array core for Python, I think
the book would be better off by covering it.  Numarray is actively developed,
and vastly better documented than Numeric.

A mention of the particular problems with numarray might be a good idea, so
that readers are aware of Numeric and where it may still be preferable to
numarray, but with the understanding that it's a (shrinking) niche.  Hopefully
one day that niche will shrink to zero, but that is going to take time and
work.

Finally, I think in this section a mention of the overall scipy project would
be a good idea.  Scipy is the central meeting point for most scientific
computing projects in python, and therefore a natural reference for most users
of numarray/numeric.  Amongst other useful things at the scipy site, there's a
community maintained wiki of links to python-based projects of scientific
interest:

http://www.scipy.org/wikis/topical_software/TopicalSoftware

Regards,

f

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

Re: what would you like to see in a 2nd edition Nutshell?

[Craig Ringer]

On Wed, 2004-12-29 at 23:54, Thomas Heller wrote:

> I found the discussion of unicode, in any python book I have, insufficient.

I couldn't agree more. I think explicit treatment of implicit
conversion, the role of sysdefaultencoding, the u'' constructor and
unicode() built in, etc would be helpful to many. 

A clear explanation of why Python strings, despite being assumed to be
ASCII, can contain any 8-bit data in any text encoding (or no text
encoding at all) may also help newbies.

I spent a while fighting to understand the way python handles encodings
a while ago and benefited significantly from it - but there really needs
to be a good explanation. The relationship between 'str' and 'unicode'
objects, the way implicit conversion works with sysdefaultencoding, and
how explicit conversions between encodings and to/from unicode, in
particular, need attention.

It'd also be REALLY good to mention the role of, and importance of, the
coding: line. An explanation of its relationship with the interpretation
of strings in the script, and with the sysdefaultencoding, would also be
helpful, as IMO the script encodings PEP only really makes sense once
you already understand it.

It wouldn't hurt to point C extension authors at things like the 'es'
encoded string format for PyArg_ParseTuple to help them make their code
better behaved with non-ascii text.

--
Craig Ringer 

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

Re: calling functions across threads

[Fernando Perez]

Steven Bethard wrote:

> I get the correct output, but if you run this yourself, you'll see that
> the numbers 1 through 10 aren't printed in sync with the writes (i.e.
> every half second); they're all printed at the end.  Could someone
> explain to me why this happens, and how (if possible) I can get the
> numbers printed in sync with the appends to the list?

This is just a shot in the dark, as I'm quite ignorant of threading details. 
But what happens if you try adding a sys.stdout.flush() call after the print
statement in your custom update() method?  It may just be a flushing problem
what makes the output appear out of sync...

Cheers,

f

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

Re: copying classes?

[Jeff Epler]

You copied an instance, not a class.

Here's an example of attempting to deepcopy a class:
>>> class X: pass
... 
>>> import copy
>>> X is copy.deepcopy(X)
Traceback (most recent call last):
  File "", line 1, in ?
  File "/usr/lib/python2.2/copy.py", line 179, in deepcopy
raise error, \
copy.Error: un-deep-copyable object of type 

In theory, one could provide a metaclass that allows copying of
instances of that metaclass.  I'll leave this as an exercise to the
reader.

Jeff


pgpjJrXN93ruF.pgp
Description: PGP signature
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: objects as mutable dictionary keys

[Terry Reedy]

"Nick Coghlan" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
> This *is* a bug (since Guido called it such), but one not yet fixed as 
> the obvious solution (removing object.__hash__) causes problems for 
> Jython,
> and a non-obvious solution has not been identified.

Since object was added in 2.2 and the most recently released Jython I know 
about is 2.1, are you referring to a newer version in development?

tjr




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

Re: calling functions across threads

[Steven Bethard]

Fernando Perez wrote:
Steven Bethard wrote:

I get the correct output, but if you run this yourself, you'll see that
the numbers 1 through 10 aren't printed in sync with the writes (i.e.
every half second); they're all printed at the end.  Could someone
explain to me why this happens, and how (if possible) I can get the
numbers printed in sync with the appends to the list?

This is just a shot in the dark, as I'm quite ignorant of threading details. 
But what happens if you try adding a sys.stdout.flush() call after the print
statement in your custom update() method?  It may just be a flushing problem
what makes the output appear out of sync...
Strangely enough, that causes PythonWin to hang...  Why that would be 
true, I have no idea...

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

Re: Why tuples use parentheses ()'s instead of something else like <>'s?

[Roy Smith]

"John Roth" <[EMAIL PROTECTED]> wrote:
> > If Python had originally been invented in a unicode world, I suppose we
> > wouldn't have this problem.  We'd just be using guillemots for tuples
> > (and have keyboards which made it easy to type them).
> 
> I suppose the forces of darkness will forever keep Python from
> requiring utf-8 as the source encoding. If I didn't make a fetish
> of trying to see the good in everybody's position, I could really
> work up a dislike of the notion that you should be able to use
> any old text editor for Python source.

You can't use "any old text editor" for Python source.  You can only use 
a hardware/software combination which supports the required character 
set (which AFAICT means ASCII, including *both* cases of the alphabet).  
You would probably find it difficult to enter Python code on a 029 
keypunch, or an ASR-33, or even an IBM-3270.  

Granted, those are all dinosaurs these days, but 30 years ago, they 
represented the norm.  At that time, C was just hitting the streets, and 
it was a pain to edit on many systems because it used weird characters 
like { and }, which weren't in EBCDIC, or RAD-50, or SIXBIT, or whatever 
character set your system used.  ASCII was supposed to solve that 
nonsense once and for all, except of course for the minor problem that 
it didn't let most people in the world spell their names properly (if at 
all).

In any case, it's a good thing that Python can be edited with "any old 
text editor", because that lowers the price of entry.  I like emacs, the 
next guy likes vi, or vim, or notepad, or whatever.  Nothing is keeping 
folks who like IDEs from inventing and using them, but I would have been 
a lot less likely to experiment with Python the first time if it meant 
getting one of them going just so I could run "Hello, world".

With google as my witness, I predict that in 30 years from now, ASCII 
will be as much a dinosaur as a keypunch is today, and our children and 
grandchildren will both wonder how their ancestors ever managed to write 
programs without guillemots and be annoyed that they actually have to 
type on a keyboard to make the computer understand them.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tkinter vs wxPython

[Thomas Bartkus]

"Jarek Zgoda" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Cameron Laird wrote:
>
> Well, while on Windows "native" look exists, on X11 "native" has other
> meaning. On my wife's desktop it's KDE that is native, GNUStep is native
> on mine and I strongly object calling GTK "native", as one can read on
> SWT/Eclipse website. There's no "universally native" look on X11. Some
> toolkits look better, but this is a matter of personal taste, for
> software developer clean, stable API and suitable widgets are of much
> higher value.
>

What I think people mean by "native" is that it follows the design scheme
selected for the desktop.

When run under Linux, my wxPython programs follow the look and feel of my
Gnome desktop.  When the same program is run on Windows, it follows that
desktop theme. Both Gnome and Windows XP alter the the controls design
according to user preferences.  wxPython GUIs reflect this automatically and
the controls always look and work like the underlying system.

I may be wrong but I don't think you get that with TKinter!
Thomas Bartkus


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

Re: Other notes

[Steve Holden]

Mike Meyer wrote:
Steve Holden <[EMAIL PROTECTED]> writes:
[...]
Well, perhaps you can explain how a change that's made at run time
(calling the decorator) can affect the parser's compile time behavior,
then. At the moment, IIRC, the only way Python code can affect the
parser's behavior is in the __future__ module, which must be imported
at the very head of a module.

By modifying the parsers grammer at runtime. After all, it's just a
data structure that's internal to the compiler.
But the parser executes before the compiled program runs, was my point. 
What strange mixture of compilation and interpretation are you going to 
use so the parser actually understands that ".." (say) is an operator 
before the operator definition has been executed?

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: Tkinter vs wxPython

[Jp Calderone]

On Wed, 29 Dec 2004 13:37:22 -0600, Thomas Bartkus <[EMAIL PROTECTED]> wrote:
>"Jarek Zgoda" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> > Cameron Laird wrote:
> >
> > Well, while on Windows "native" look exists, on X11 "native" has other
> > meaning. On my wife's desktop it's KDE that is native, GNUStep is native
> > on mine and I strongly object calling GTK "native", as one can read on
> > SWT/Eclipse website. There's no "universally native" look on X11. Some
> > toolkits look better, but this is a matter of personal taste, for
> > software developer clean, stable API and suitable widgets are of much
> > higher value.
> >
> 
> What I think people mean by "native" is that it follows the design scheme
> selected for the desktop.
> 
> When run under Linux, my wxPython programs follow the look and feel of my
> Gnome desktop.  When the same program is run on Windows, it follows that
> desktop theme. Both Gnome and Windows XP alter the the controls design
> according to user preferences.  wxPython GUIs reflect this automatically and
> the controls always look and work like the underlying system.

  I think you're right about what "native" means.

> 
> I may be wrong but I don't think you get that with TKinter!

  Tk has native widgets for many platforms.

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

Re: Why tuples use parentheses ()'s instead of something else like <>'s?

[Reinhold Birkenfeld]

Roy Smith wrote:
> "John Roth" <[EMAIL PROTECTED]> wrote:
>> > If Python had originally been invented in a unicode world, I suppose we
>> > wouldn't have this problem.  We'd just be using guillemots for tuples
>> > (and have keyboards which made it easy to type them).
>> 
>> I suppose the forces of darkness will forever keep Python from
>> requiring utf-8 as the source encoding. If I didn't make a fetish
>> of trying to see the good in everybody's position, I could really
>> work up a dislike of the notion that you should be able to use
>> any old text editor for Python source.

> In any case, it's a good thing that Python can be edited with "any old 
> text editor", because that lowers the price of entry.  I like emacs, the 
> next guy likes vi, or vim, or notepad, or whatever.  Nothing is keeping 
> folks who like IDEs from inventing and using them, but I would have been 
> a lot less likely to experiment with Python the first time if it meant 
> getting one of them going just so I could run "Hello, world".

Perl6 experiments with the use of guillemots as part of the syntax. I
shall be curious to see how this is accepted, of course only if Perl6 is
ever going to see the light of day, which is an exciting matter of its
own...

> With google as my witness, I predict that in 30 years from now, ASCII 
> will be as much a dinosaur as a keypunch is today, and our children and 
> grandchildren will both wonder how their ancestors ever managed to write 
> programs without guillemots and be annoyed that they actually have to 
> type on a keyboard to make the computer understand them.

Well, it's not clear if they will still "write" programs...

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

Re: Other notes

[Terry Reedy]

"Steven Bethard" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
> I'll second that.  Please, "Bearophile", do us the courtesy of checking
>
> (1) Google groups archive of the mailing list:
> http://groups-beta.google.com/group/comp.lang.python
>
> and
>
> (2) The Python Enhancement Proposals:
> http://www.python.org/peps/
>
> before posting another such set of questions.  While most of the people 
> on this list are nice enough to answer your questions anyway, the answers 
> are already out there for at least half of your questions, if you would 
> do us the courtesy of checking first.

I also suggest perusing the archived PyDev (Python Development mailing 
list) summaries for the last couple of years (see python.org).  Every two 
weeks, Brett Cannon has condensed everything down to a few pages.  You can 
easily focus on the topics of interest to you.  For instance, there was 
discussion of making lists truly double-ended, but it was decided to settle 
for certain improvements in the list implementation while adding 
collections.deque (sp?) in 2.4.

Terry J. Reedy



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

Re: Python 3000, zip, *args and iterators

[Raymond Hettinger]

[Steven Bethard]  I'm just suggesting that in a function with a
> *args in the def, the args variable be an iterator instead of
> a tuple.

So people would lose the useful abilities to check len(args) or extract
an argument with args[1]?

Besides, if a function really wants an iterator, then its signature
should accept one directly -- no need for the star operator.



> > Likewise, he considers zip(*args) as a
> > transpose function to be an abuse of the *arg protocol.
>
> Ahh, I didn't know that.  Is there another (preferred) way to do
this?

I prefer the abusive approach ;-) however, the Right Way (tm) is
probably nested list comps or just plain for-loops.  And, if you have
numeric, there is an obvious preferred approach.



>  So basically what I've done here is to
> "transpose" (to use your word) the iterators, apply my function, and
> then transpose the iterators back.

If you follow the data movements, you'll find that iterators provide no
advantage here.  To execute transpose(map(f, transpose(iterator)), the
whole iterator necessarily has to be read into memory so that the first
function application will have all of its arguments present -- using
the star operator only obscures that fact.

Realizing that the input has to be in memory anyway, then you might as
well take advantage of the code simplication offered by indexing:

>>> def twistedmap(f, iterable):
... data = list(iterable)
... rows = range(len(data))
... for col in xrange(len(data[0])):
... args = [data[row][col] for rows in rows]
... yield f(*args)



Raymond Hettinger

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

Re: Other notes

[Terry Reedy]

"Mike Meyer" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
> Steve Holden <[EMAIL PROTECTED]> writes:
>> Well, perhaps you can explain how a change that's made at run time
>> (calling the decorator) can affect the parser's compile time behavior,
>> then. At the moment, IIRC, the only way Python code can affect the
>> parser's behavior is in the __future__ module, which must be imported
>> at the very head of a module.
>
> By modifying the parsers grammer at runtime. After all, it's just a
> data structure that's internal to the compiler.

Given that xx.py is parsed in its entirety *before* runtime, that answer is 
no answer at all.  Runtime parser changes (far, far from trivial) could 
only affect the result of exec and eval.

Terry J. Reedy



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

Re: Why tuples use parentheses ()'s instead of something else like <>'s?

[Grant Edwards]

On 2004-12-29, Reinhold Birkenfeld <[EMAIL PROTECTED]> wrote:

> Perl6 experiments with the use of guillemots as part of the syntax.

As if Perl didn't look like bird-tracks already...

http://www.seabird.org/education/animals/guillemot.html
http://www.birdguides.com/html/vidlib/species/Uria_aalge.htm

-- 
Grant Edwards   grante Yow!  There's enough money
  at   here to buy 5000 cans of
   visi.comNoodle-Roni!
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: calling functions across threads

[Fernando Perez]

Steven Bethard wrote:

> Fernando Perez wrote:
>> Steven Bethard wrote:
>> 
>> 
>>>I get the correct output, but if you run this yourself, you'll see that
>>>the numbers 1 through 10 aren't printed in sync with the writes (i.e.
>>>every half second); they're all printed at the end.  Could someone
>>>explain to me why this happens, and how (if possible) I can get the
>>>numbers printed in sync with the appends to the list?
>> 
>> 
>> This is just a shot in the dark, as I'm quite ignorant of threading details.
>> But what happens if you try adding a sys.stdout.flush() call after the print
>> statement in your custom update() method?  It may just be a flushing problem
>> what makes the output appear out of sync...
> 
> Strangely enough, that causes PythonWin to hang...  Why that would be
> true, I have no idea...

Mmh.  I wouldn't be surprised if under pythonwin, sys.stdout is not the true
python sys.stdout.  Check the following:

sys.stdout is sys.__stdout__

The answer is probably false.  In that case, they may have implemented some
incomplete object whose flush method is broken, or something similar.  I can't
confirm, as I don't have windows access, so this is just a guess.

Cheers,

f

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

Re: Why tuples use parentheses ()'s instead of something else like <>'s?

[Rocco Moretti]

[EMAIL PROTECTED] wrote:
Why tuples use parentheses ()'s instead of something else like <>'s?
>
> Please enlighten me as I really want to know.
So to summarize:
Commas define tuples, except when they don't, and parentheses are only 
required when they are necessary.

I hope that clears up any confusion.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python 3000, zip, *args and iterators

[Steven Bethard]

Raymond Hettinger wrote:
[Steven Bethard]  I'm just suggesting that in a function with a
*args in the def, the args variable be an iterator instead of
a tuple.

So people would lose the useful abilities to check len(args) or extract
an argument with args[1]?
No more than you lose these abilities with any other iterators:
def f(x, y, *args):
   args = list(args) # or tuple(args)
   if len(args) == 3:
  print args[0], args[1], args[2]
True, if you do want to check argument counts, this is an extra step of 
work.  I personally find that most of my functions with *args parameters 
look like:

def f(x, y, *args):
do_something1(x)
do_something2(y)
for arg in args:
do_something3(arg)
where having *args be an iterable would not be a problem.
So basically what I've done here is to
"transpose" (to use your word) the iterators, apply my function, and
then transpose the iterators back.
If you follow the data movements, you'll find that iterators provide no
advantage here.  To execute transpose(map(f, transpose(iterator)), the
whole iterator necessarily has to be read into memory so that the first
function application will have all of its arguments present -- using
the star operator only obscures that fact.
I'm not sure I follow you here.  Looking at my code:
labels, feature_dicts = starzip(generator)
for label, feature_window in izip(labels, window(feature_dicts)):
write_instance(label, combine_dicts(feature_widow))
A few points:
(1) starzip uses itertools.tee, so it is not going to read the entire 
contents of the generator in at once as long as the two parallel 
iterators do not run out of sync

(2) window does not exhaust the iterator passed to it; instead, it uses 
the items of that iterator to generate a new iterator in sync with the 
original, so izip(labels, window(feature_dicts)) will keep the labels 
and feature_dicts iterators in sync.

(3) the for loop just iterates over the izip iterator, so it should be 
consuming (label, feature_window) pairs in sync.

I assume you disagree with one of these points or you wouldn't say that 
"iterators provide no advantage here".  Could you explain what doesn't 
work here?

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

Re: Why tuples use parentheses ()'s instead of something else like <>'s?

[Reinhold Birkenfeld]

Grant Edwards wrote:
> On 2004-12-29, Reinhold Birkenfeld <[EMAIL PROTECTED]> wrote:
> 
>> Perl6 experiments with the use of guillemots as part of the syntax.
> 
> As if Perl didn't look like bird-tracks already...
> 
> http://www.seabird.org/education/animals/guillemot.html
> http://www.birdguides.com/html/vidlib/species/Uria_aalge.htm

Well,

  (1,1,2,3,5) »+« (1,2,3,5,8);  # results in (2,3,5,8,13)

(>>+<< being an operator) just isn't something I would like to read in
my code...

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

Re: calling functions across threads

[Steven Bethard]

Fernando Perez wrote:
Steven Bethard wrote:

Fernando Perez wrote:
Steven Bethard wrote:

I get the correct output, but if you run this yourself, you'll see that
the numbers 1 through 10 aren't printed in sync with the writes (i.e.
every half second); they're all printed at the end.  Could someone
explain to me why this happens, and how (if possible) I can get the
numbers printed in sync with the appends to the list?

This is just a shot in the dark, as I'm quite ignorant of threading details.
But what happens if you try adding a sys.stdout.flush() call after the print
statement in your custom update() method?  It may just be a flushing problem
what makes the output appear out of sync...
Strangely enough, that causes PythonWin to hang...  Why that would be
true, I have no idea...

Mmh.  I wouldn't be surprised if under pythonwin, sys.stdout is not the true
python sys.stdout.  Check the following:
sys.stdout is sys.__stdout__
The answer is probably false.  In that case, they may have implemented some
incomplete object whose flush method is broken, or something similar.  I can't
confirm, as I don't have windows access, so this is just a guess.
Just to verify, yes, the answer is False:
py> import sys
py> sys.stdout is sys.__stdout__
False
Is there a list to ask PythonWin specific questions somewhere, or should 
I just wait for a PythonWin expert around here?

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

Re: learning about threads and processes (was Re: what would you like to see in a 2nd edition Nutshell?)

[Arthhur]

On Wed, 29 Dec 2004 16:41:23 +0100, Alex Martelli wrote:
> 
> Hmmm, well, the concepts are reasonably independent of the programming
> language involved.  If anything, threads and processes may be more tied
> to whatever _operating system_ you're using.  A very fundamental but
> good introduction to processes (and other such basics) is for example at
> , but it
> will be only partially applicable if you need to understand in depth the
> process-model of Windows.  But of course this is about the concepts, not
> the practice of programming to interact with them.

Too basic. Doesn't speak to the "intermediate".  

I'll have you know, sir, you are speaking to someone who is
quite intermediate, at least in mediocre way.  Hummph ;)


>> If I want to no more than be able to follow, say, the current Idle code
>> of the PyShell module, I can find very little guidance from within the
>> canon of Python literature.
>> 
>> Help?
> 
> Hmmm - have you looked at Deitel, Deitel, Liperi, Wiedermann, "Python
> how to program", chapters 18 (Process Management) and 19
> (Multithreading), pages 613-687?  They seem to do a rather workmanlike
> job -- of course, they can't do full justice to the subjects in 75
> pages; and if you don't want to buy a vast, costly 1300-pages tome for
> the sake of those 75 pages, I can't really blame you, either.  Still,
> without some clarification of how (if at all) those 75 pages fail to
> meet your learning needs, it's hard to know what else to suggest.  And
> what about Norman Matloff's
> , the first
> google hit if you're looking for
> python threads

I never gotten to page 613 of any book in my life ;)

But the Matloff piece you site is in fact helpful to the intermediate.  

Frankly not sure how I missed it in past searches.  "Python threading" as
a google buries it a bit, but not that deeply.

This also comes up on a fresh search, and is to the point and at the level
of interest. It is also recent:

http://linuxgazette.net/107/pai.html


> ?  I haven't looked into it, but, again, without some specific
> explanation of how it fails to meet your needs, it's hard to offer
> alternatives.

The problem is when one starts off explaining threads by reference to
processes, I already have a practical problem.  Which, under what
circumstances.

Again referring back to the Idle code, class ModifiedInterpreter in the
PyShell module:

Within the space of a simple class, we are spawning 
a subprocess via:

self.rpcpid = os.spawnv(os.P_NOWAIT, sys.executable, args)

and a rpc client listening to a socket via:

self.rpcclt = MyRPCClient(addr)

which can be interrupted via a thread ala:

threading.Thread(target=self.__request_interrupt).start()

And then it gets a little complicated, to an intermediate ;)

Guess I am hoping to get to understand it as architecture, as well as as
code.

This happens to be another piece of code I am trying to digest, which
allows one to experiment with building PyGTK widgets from an interactive
prompt:

http://www.pygtk.org/pygtktutorial/examples/pygtkconsole.py

which uses os.fork and signals in its architecture, but no threads, as
opposed to this CookBook recipe:

http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/65109

which accomplishes a very similar functionality using threads as a
fundamental part of its strategy.

The closest thing I can think of as the kind of book I would love to see
is one similar to Steve Holden's book on web programming, which explained
lower level internet proctocols at the same time as it explained their
Python implementation.

Wonder what Steve's are doing this week? ;) 

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

Re: what would you like to see in a 2nd edition Nutshell?

[Russell E. Owen]

In article <[EMAIL PROTECTED]>,
 [EMAIL PROTECTED] (Alex Martelli) wrote:

>I'm considering proposing to O'Reilly a 2nd edition of "Python in a
>Nutshell", that I'd write in 2005, essentially to cover Python 2.3 and
>2.4 (the current 1st edition only covers Python up to 2.2).
>...

Since you were kind enough to ask...what I'd really like is a better 
better index and better organization, so I can more quickly and easily 
locate info on a particular topic.

Nutshell has some wonderful in-depth discussions of certain topics and 
I'm glad I own it, but I find it too hard to use for everyday questions 
(which was not at all what I expected for a "nutshell" book). I usually 
start with the html help (if I know the module I need or have a firm 
guess as to which other manual to read) or Python Essential Reference 
(other cases), then go to Nutshell if I'm still lost or if I remember it 
has a good section on the topic of interest.

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

Re: Why tuples use parentheses ()'s instead of something else like <>'s?

[Roy Smith]

In article <[EMAIL PROTECTED]>,
 Reinhold Birkenfeld <[EMAIL PROTECTED]> wrote:

> >>+<< being an operator

Looks more like a smiley for "guy wearing a bowtie"
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Why tuples use parentheses ()'s instead of something else like <>'s?

[Grant Edwards]

On 2004-12-29, Reinhold Birkenfeld <[EMAIL PROTECTED]> wrote:

>>> Perl6 experiments with the use of guillemots as part of the syntax.
>> 
>> As if Perl didn't look like bird-tracks already...
>> 
>> http://www.seabird.org/education/animals/guillemot.html
>> http://www.birdguides.com/html/vidlib/species/Uria_aalge.htm
>
> Well,
>
>   (1,1,2,3,5) »+« (1,2,3,5,8);  # results in (2,3,5,8,13)

I was pretty sure that « and » were guillmots, but google sure
preferred the sea bird when I asked it.

-- 
Grant Edwards   grante Yow!  I've been WRITING
  at   to SOPHIA LOREN every 45
   visi.comMINUTES since JANUARY 1ST!!
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: what would you like to see in a 2nd edition Nutshell?

[c d saunter]

Alex Martelli ([EMAIL PROTECTED]) wrote:
: I'm considering proposing to O'Reilly a 2nd edition of "Python in a
: Nutshell", that I'd write in 2005, essentially to cover Python 2.3 and
: 2.4 (the current 1st edition only covers Python up to 2.2).

: So, if there's any advice or request about a 2nd edition of the
: Nutshell, this is the right time for y'all to let me know.  Feedback is
: welcome, either privately or right here.  Thanks in advance -- _and_
: apologies in advance because I know I just won't be able to accomodate
: all the requests/advice, given the constraints on book size &c.

Alex,
Probably not a practical sugestion, but have you considered 
ctypes?  I know it's proved invaluable to our group at university - we 
like to make Python work with so many bits of weird hardware with vendor 
supplied libraries etc ...

Perhaps a more resonable sugestion would be a short section on integration 
with native systems, e.g. an intro/overview to (non exhaustive list):

psyco
scipy.blitz/weave
ctypes
pyrex

A detailed look at these is probably outside the scope of Nutshell, but 
they all represent intreresting areas.  Perhaps the section could end with 
some words on PyPy.

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

Re: calling functions across threads

[Steve Holden]

Steven Bethard wrote:
Fernando Perez wrote:
Steven Bethard wrote:

Fernando Perez wrote:
Steven Bethard wrote:

I get the correct output, but if you run this yourself, you'll see 
that
the numbers 1 through 10 aren't printed in sync with the writes (i.e.
every half second); they're all printed at the end.  Could someone
explain to me why this happens, and how (if possible) I can get the
numbers printed in sync with the appends to the list?

This is just a shot in the dark, as I'm quite ignorant of threading 
details.
But what happens if you try adding a sys.stdout.flush() call after 
the print
statement in your custom update() method?  It may just be a flushing 
problem
what makes the output appear out of sync...

Strangely enough, that causes PythonWin to hang...  Why that would be
true, I have no idea...

Mmh.  I wouldn't be surprised if under pythonwin, sys.stdout is not 
the true
python sys.stdout.  Check the following:

sys.stdout is sys.__stdout__
The answer is probably false.  In that case, they may have implemented 
some
incomplete object whose flush method is broken, or something similar.  
I can't
confirm, as I don't have windows access, so this is just a guess.

Just to verify, yes, the answer is False:
py> import sys
py> sys.stdout is sys.__stdout__
False
Is there a list to ask PythonWin specific questions somewhere, or should 
I just wait for a PythonWin expert around here?

Steve
There's a mailing list at python-win32@python.org - it's listed on 
www.python.org should you choose to subscribe, and the volume isn't 
generally high (maybe 5-10 messages per day).

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: Why tuples use parentheses ()'s instead of something else like <>'s?

[Dan Sommers]

On 29 Dec 2004 21:03:59 GMT,
Grant Edwards <[EMAIL PROTECTED]> wrote:

> On 2004-12-29, Reinhold Birkenfeld <[EMAIL PROTECTED]> wrote:
 Perl6 experiments with the use of guillemots as part of the syntax.
>>> 
>>> As if Perl didn't look like bird-tracks already...
>>> 
>>> http://www.seabird.org/education/animals/guillemot.html
>>> http://www.birdguides.com/html/vidlib/species/Uria_aalge.htm
>> 
>> Well,
>> 
>> (1,1,2,3,5) Â+Â (1,2,3,5,8);  # results in (2,3,5,8,13)

> I was pretty sure that  and  were guillmots, but google sure
> preferred the sea bird when I asked it.

They're guillemets (with an "e"); this is a [relatively] well-known
Adobe SNAFU.  (A quick google search or two failed to find an
authoritative reference, but I know that such references are out there
somewhere.)

Regards,
Dan

-- 
Dan Sommers

Never play leapfrog with a unicorn.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Why tuples use parentheses ()'s instead of something else like <>'s?

[[EMAIL PROTECTED]]

> There just isn't enough
> neat-looking punctuation in the ASCII character set.

Alex

I can't thank you enough for your reply and for everyones' great info
on this thread.  The end of your email gave a rock solid reason why it
is impossible to improve upon ()'s for tuples

*There simply isn't enough good candidates in ASCII.*

Moving to Unicode has pros
and cons but your defense of parens assuming ASCII is perfect.
Thanks again.

Chris

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

vga output

[Gabriel Cosentino de Barros]

Title: vga output





i'm writting an app to display images without X... i'm scared just to think about writting it in C... The hardware won't run X. and the CPU is very humble, around 20Mhz (and it must have fade outs). it run a minimalisc OpenBSD kernel.

Anyone already did something similar and/or have any recomendations?


Thanks,
Gabriel



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

Re: Why tuples use parentheses ()'s instead of something else like <>'s?

[[EMAIL PROTECTED]]

Brian

I am so thankful for your reply and for Alex's and everyone else's on
this thread.  (See my reply to Alex.)  This email may seem minor but it
was bugging me for months.  You just
pointed out what I should have remembered on my own...

*<>'s wouldn't have been a perfect choice because they would have had
their
own unique gotchas involving accidentally interpreting them as binary
shift operators*

I really appreciate it.

Chris

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

Re: what would you like to see in a 2nd edition Nutshell?

[RM]

Alex Martelli wrote:
> I still
> believe Tkinter coverage is going to help more readers.

Alex,

I know this can be a can of worms.  But honestly, I wonder what do you
base that idea on.

-Ruben

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