Off Topic: Is the use of supererogatory supererogatory?

[Paddy]

On May 13, 12:13 am, [EMAIL PROTECTED] (Alex Martelli) wrote:

> As somebody else alredy pointed out, the lambda is supererogatory (to
> say the least).

What a wonderful new word!
I did not know what supererogatory meant, and hoped it had nothing to
do with Eros :-)
Answers.com gave me a meaning synonymous with superfluous, which
I think is what was meant here, but Chambers gave a wonderful
definition where they say it is from the RC Church practice of doing
more
devotions than are necessary  so they can be 'banked' for distribution
to others (I suspect, that in the past it may have been for a fee or
a
favour).

Supererogatory, my word of the day.

- Paddy

P.S; 
http://www.chambersharrap.co.uk/chambers/features/chref/chref.py/main?query=supererogatory+&title=21st


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

Re: Change serial timeout per read

[James T. Dennis]

[EMAIL PROTECTED] wrote:
> I'm writing a driver in Python for an old fashioned piece of serial
> equipment. Currently I'm using the USPP serial module. From what I can
> see all the serial modules seem to set the timeout when you open a
> serial port. This is not what I want to do. I need to change the
> timeout each time  I do a "read" on the serial port, depending on
> which part of the protocol I've got to. Sometimes a return character
> is expected within half a second, sometimes within 2 seconds, and
> sometimes within 20 seconds. How do I do this in USPP, or Pyserial, or
> anything else? Currently I'm working in Windows, but I'd prefer a
> platform independent solution if possible...

> Thanks - Rowan

 I'm not familiar with the USPP serial module.  However, I used
 the PySerial package successfully for several months on one job
 to write a full regression testing framework and suite for testing
 a series of different VOIP/SIP phone models (little embedded Linux
 systems) via their diagnostics/JTAG serial headers.

 It had timeout and writeTimeout settings which I recall were fully 
 configurable to fractions of a second, None, and 0 (non-blocking).

 Under Debian it's available as a simple:

 apt-get -f install python-serial.

 ... and I seem to recall that it worked fine under MS Windows, too.
 (In fact it was written in pure Python, no C-lib or .so/.DLL under it).

 Ahh ... here's the URL:

http://pyserial.sourceforge.net/

 ... with backends for CPython (Windows and Linux/UNIX/Posix), and Jython.

 Under Python just use:

>>> import serial 

 ... then use something like:

>>> s0 = serial.Serial(0)  # Open first serial port: default settings

 ... or:

>>> s0 = serial.Serial('/dev/ttyS0', 38400, timeout=None) \
# port by device node/name, setting speed and no timeout
>>> s1 = serial.Serial(3, 19200, timeout=0) \
# another by number, non-blocking

 Then use:

>>> s0.read()  # or s0.readline() for '\n' terminated

 ... and various other methods on these ports.

 BTW: you can change the timeouts on these connection objects
 simply by using s0.timeout=X ... and you can set them to floating
 point values --- so you can use tenths of a second.

 I remember I was also able to adapt my framework classes to add
 support for telnetlib in about an hour of spare time one evening; so
 we could use the serial port to manage testing on one block of phones
 and we could enable the optional telnet port access built-into a
 bank of the other phones and use almost all the same test code with
 them.  (The only difference was that we couldn't capture reboot
 output over the telnet interface; while I could capture and log it
 via the serial ports --- in other words it was a natural limitation of
 the hardware --- and their embedded system didn't enable something like
 a dmesg to capture that after the fact).

 The reason I mention the telnetlib angle serves some purpose other than
 mere rambling and bragging ... I seem to recall that the methods
 supported by the two modules were very closely matched ... so my
 adaptation was extremely straightforward.

 I see that USPP (univ. serial port for Python) is available at:

http://ibarona.googlepages.com/uspp

 ... and it's supposed to have most of the same features (from a
 quick glance at the web page).  However, there's much more info
 available at the PySerial page ... and PySerial seems to be far
 more recently maintained (with 2.2 "slots' support, for example).

 In addition PySerial seems to be linked to a PyParallel package
 that's "under development" (presumably by the same author).
 (I'm guessing that this latter development can't be done in pure
 Python, though).
 
-- 
Jim Dennis,
Starshine: Signed, Sealed, Delivered

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

Re: Dynamic subclassing ?

[manatlan]

On 13 mai, 01:24, [EMAIL PROTECTED] (Alex Martelli) wrote:
> manatlan <[EMAIL PROTECTED]> wrote:
> > I've got an instance of a class, ex :
>
> > b=gtk.Button()
>
> > I'd like to add methods and attributes to my instance "b".
> > I know it's possible by hacking "b" with setattr() methods. But i'd
> > like to do it with inheritance, a kind of "dynamic subclassing",
> > without subclassing the class, only this instance "b" !
>
> > In fact, i've got my instance "b", and another class "MoreMethods"
>
> > class MoreMethods:
> > def  sayHello(self):
> >   print "hello"
>
> > How could i write ...
>
> > "b = b + MoreMethods"
>
> > so "b" will continue to be a gtk.Button, + methods/attributs of
> > MoreMethods (it's what i call "dynamic inheritance") ...so, things
> > like this should work :
>
> > - b.set_label("k")
> > - b.sayHello()
>
> > I can't find the trick, but i'm pretty sure it's possible in an easy
> > way.
>
> I think what you're asking for is totally weird, and with just about
> zero advantages compared with several saner alternatives that have
> already been proposed in this thread and that you have rejects, but
> sure, it's possible:
>
> def addaclass(aninst, onemoreclass):
> aninst.__class__ = type(aninst.__aclass__.__name__,
> (aninst.__aclass__, onemoreclass), {})
>
> Alex

I know it's weird ... and solutions given here are a lot saner. But i
can't do that at the creation of the instance, because it's not me who
has the creation process ... the only things i've got, it's the
instance

i tried :

class MoreMethods:
def  sayHello(self):
print "hello"

def addaclass(aninst, onemoreclass):
aninst.__class__ = type(aninst.__class__.__name__,
(aninst.__class__, onemoreclass), {})

b=gtk.Button("the_label")
addaclass(b,MoreMethods)
print b.get_label()
print b.hello()

but got :
"TypeError: __class__ assignment: only for heap types"
on the last line ...

I begin to think that the only solution is to use the module new like
Karlo said ...

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

Re: Dynamic subclassing ?

[manatlan]

On 12 mai, 18:57, Karlo Lozovina <[EMAIL PROTECTED]> wrote:
> manatlan wrote:
> > I can't find the trick, but i'm pretty sure it's possible in an easy
> > way.
>
> It's somewhat easy, boot looks ugly to me. Maybe someone has a more
> elegant solution:
>
> In [6]: import new
>
> In [13]: class Button:
> : def buttonFunc(self):
> : pass
>
> In [14]: class ExtensionClass:
> : def extendedMethod(self):
> : pass
>
> In [15]: hybrid = new.instance(Button,
> Button.__dict__.update(ExtensionClass.__dict__))
>
> In [17]: dir(hybrid)
> Out[17]: ['__doc__', '__module__', 'buttonFunc', 'extendedMethod']
>
> Seems to do what you want it to do.
>
> HTH,
> Karlo.

yes, i think it's the only solution ... it's weird
but it seems to be the only one ...
i will try that ...

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

Re: Popen and wget, problems

[Jesse]

Thx Rob!

Your solution works perfect!


"Rob Wolfe" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
> "Jesse" <[EMAIL PROTECTED]> writes:
>
>> Hi all, I have a problem using wget and Popen. I hope someone can help.
>>
>>
>> -- Problem --
>> I want to use the command:
>> wget -nv -O "dir/cpan.txt" "http://search.cpan.org";
>> and capture all it's stdout+stderr.
>> (Note that option -O requires 'dir' to be existing before wget is 
>> executed)
>>
>> Popen doesn't work, while os.system and shell do. Popen will give the 
>> error:
>> dir/cpan.txt: No such file or directory
>>
>> While os.system and shell will give the correct result:
>> 06:52:40 URL:http://search.cpan.org/ [3657/3657] -> "dir1/cpan.txt" [1]
>
> [...]
>
>> -- Python Code using Popen with cmd arg list --
>> # imports
>> import os
>> from subprocess import Popen, PIPE
>>
>> # vars and create dir
>> cmd_set = ['wget', '-nv', '-O dir/cpan.txt', 'http://search.span.org']
>> cmd = ' '.join(cmd_set)
>> print "cmd: " + cmd
>> try:
>> os.makedirs('dir')
>> except:
>> print 'dir already exists'
>>
>>
>> # execute using Popen (does NOT work)
>> proc = Popen(cmd_set, stdout=PIPE, stderr=PIPE)
>> return_code = proc.wait()
>> if return_code == 0:
>> print "Success:\n%s" % (proc.stdout.read() + proc.stderr.read())
>> else:
>> print "Failure %s:\n%s" % (return_code, proc.stderr.read() +
>> proc.stdout.read())
>>
>>
>> # execute using os.system (does work)
>> os.system(cmd)
>>
>>
>> -- Python code output of Popen --
>> Failure 1:
>> dir/cpan.txt: No such file or directory
>>
>>
>> -- Question --
>> Why is Popen unable to correctly execute the wget, while os.system can?
>
> I don't know exactly why in this case Popen doesn't work,
> but the counterpart of os.system is Popen with option shell=True
> and the first parameter should be a string instead of list.
> That seems to work:
> proc = Popen("wget -nv -O dir/cpan.txt http://search.span.org";,
>  shell=True, stdout=PIPE, stderr=PIPE)
>
> and this variant seems to work too:
> cmd_set = ['wget', '-nv', '-O', 'dir/cpan.txt', 'http://search.span.org']
>
> -- 
> HTH,
> Rob 

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

Re: Dynamic subclassing ?

[manatlan]

On 12 mai, 20:47, Steven Bethard <[EMAIL PROTECTED]> wrote:
> manatlan wrote:
> > I've got an instance of a class, ex :
>
> > b=gtk.Button()
>
> > I'd like to add methods and attributes to my instance "b".
> > I know it's possible by hacking "b" with setattr() methods. But i'd
> > like to do it with inheritance, a kind of "dynamic subclassing",
> > without subclassing the class, only this instance "b" !
>
> > In fact, i've got my instance "b", and another class "MoreMethods"
>
> > class MoreMethods:
> > def  sayHello(self):
> >   print "hello"
>
> > How could i write ...
>
> > "b = b + MoreMethods"
>
> You can simply bind the methods you want to add to the Button instance.
> That means doing the equivalent of ``b.sayHello = sayHello.__get__(b)``.
> For example::
>
>  >>> class Button(object):
>  ... def set_label(self, label):
>  ... print 'setting label:', label
>  ...
>  >>> def add_methods(obj, cls):
>  ... for name, value in cls.__dict__.items():
>  ... if callable(value) and hasattr(value, '__get__'):
>  ... setattr(obj, name, value.__get__(obj, type(obj)))
>  ...
>  >>> b = Button()
>  >>> b.set_label('k')
>  setting label: k
>  >>> b.say_hello()
>  Traceback (most recent call last):
>File "", line 1, in 
>  AttributeError: 'Button' object has no attribute 'say_hello'
>  >>> class MoreMethods(object):
>  ... def say_hello(self):
>  ... print 'hello'
>  ...
>  >>> add_methods(b, MoreMethods)
>  >>> b.set_label('m')
>  setting label: m
>  >>> b.say_hello()
>  hello
>
> HTH,
>
> STeVe

Yes ! it seems very good ...
I will try that too
thanks a lot ...

class MoreMethods:
val=12
def hello(self):
self.val=13
return self.get_label()

def add_methods(obj, cls):
for name, value in cls.__dict__.items():
   if callable(value) and hasattr(value, '__get__'):
   setattr(obj, name, value.__get__(obj, type(obj)))
   else:
   setattr(obj, name, value)

b=gtk.Button("the_label")
add_methods(b,MoreMethods)
print b.get_label()
print b.val
print b.hello()
print b.val

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

Re: Dynamic subclassing ?

[manatlan]

On 13 mai, 10:04, manatlan <[EMAIL PROTECTED]> wrote:
> On 12 mai, 18:57, Karlo Lozovina <[EMAIL PROTECTED]> wrote:
>
>
>
> > manatlan wrote:
> > > I can't find the trick, but i'm pretty sure it's possible in an easy
> > > way.
>
> > It's somewhat easy, boot looks ugly to me. Maybe someone has a more
> > elegant solution:
>
> > In [6]: import new
>
> > In [13]: class Button:
> > : def buttonFunc(self):
> > : pass
>
> > In [14]: class ExtensionClass:
> > : def extendedMethod(self):
> > : pass
>
> > In [15]: hybrid = new.instance(Button,
> > Button.__dict__.update(ExtensionClass.__dict__))
>
> > In [17]: dir(hybrid)
> > Out[17]: ['__doc__', '__module__', 'buttonFunc', 'extendedMethod']
>
> > Seems to do what you want it to do.
>
> > HTH,
> > Karlo.
>
> yes, i think it's the only solution ... it's weird
> but it seems to be the only one ...
> i will try that ...

in fact, the "new" solution adds methods to all "gtk.Button" and not a
specific instance ... it's not good for me
but thanks (i always forget the use of the "new" module for this kind
of things)

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

Re: Setting thread priorities

[Gerald Kaszuba]

Hi John

On May 13, 4:46 pm, John Nagle <[EMAIL PROTECTED]> wrote:
>There's no way to set thread priorities within Python, is there?

Not exactly. You can however use the ctypes module to access the o/s
methods of pthread_setschedparam() for UNIX and SetThreadPriority()
for Windows.

I'm not sure why this hasn't been implemented in Python.

Gerald
http://geraldkaszuba.com/

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

Real globals inside a module

[Jorgen Bodde]

Hi All,

I am wrestling with some architecture inside my app. Let's say I have
a tunings collection, which contains e.g. 23 types of guitar tunings.
In my song object I want to restore a relation between one of the
tuning objects inside the tunings module.

I already figured out I need somethign like a global collection inside
the tunings module,. but how global is it? When I am inside my app
object, and import the tunings module, can I access the same global
class as when I am inside my songs module and load the tunings module?

So for some pseudo code:

--- songs.py

import tunings

class Song(object):
  def __init__(self, tuning_id):
# create relation with tuning object
self._tuning = tunings.GetTuningById(tuning_id)

-- app.py

import tunings

# get list of tunings

for t in tunings._tuningCollection:
  print 'Tuning:', t._name



So basically I want to access the same global list in both modules,
but not re-create the list in every module since it should be restored
by the database layer once.

Is this as simple as defining a global variable in the module tunings
which is available on both imports, or should I do it different, and
then my next question ofcourse is, how ? :-)

Thanks for any advice, I do not want to make a global manager object
that I need to pass around all the time, that would be silly..

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

Re: Popen and wget, problems

[js]

Hi Jesse.

> cmd_set = ['wget', '-nv', '-O dir/cpan.txt', 'http://search.span.org']
[snip]
>proc = Popen(cmd_set, stdout=PIPE, stderr=PIPE)

wget will treat this as
$ wget -nv '-O dir/cpan.txt' "http://search.cpan.org";

And will emit the following error because there's no pathname ' dir/cpan.txt'.
(Note the pathname has a trailing space.)

 dir/cpan.txt: No such file or directory

Replace '-O dir/cpan.txt" with '-Odir/cpan.txt' or '-O', 'dir/cpan.txt'
and it should work.

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

Re: __dict__ for instances?

[Ivan Voras]

[EMAIL PROTECTED] wrote:

> I think you want "dir(instance)"  __dict__ returns the instance

Part of the problem is that dir(instance) returns a list of strings, so
iterating the dir(instance) gets me strings, not methods. Alternatively,
is there a way to get a "bound" instance by its name - some
introspection function perhaps?

> variables and values as a dictionary, but doesn't return methods.

It does on a Class :(

-- 
(\__/)
(O.o)
(> < )

This is Bunny.
Copy Bunny into your signature to help him on his way to world domination!



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

Re: Real globals inside a module

[Christoph Haas]

On Sun, May 13, 2007 at 11:41:12AM +0200, Jorgen Bodde wrote:
> I am wrestling with some architecture inside my app. Let's say I have
> a tunings collection, which contains e.g. 23 types of guitar tunings.
> In my song object I want to restore a relation between one of the
> tuning objects inside the tunings module.
> 
> I already figured out I need somethign like a global collection inside
> the tunings module,. but how global is it? When I am inside my app
> object, and import the tunings module, can I access the same global
> class as when I am inside my songs module and load the tunings module?

You are on the right way. If you import the same module a second time in
another place of your application you get access to the exact same data.
That is called a "singleton". I often use such a singleton for global
configuration data.

> So basically I want to access the same global list in both modules,
> but not re-create the list in every module since it should be restored
> by the database layer once.

Import your global module and just run the initalisation once. That
should do it.

> Thanks for any advice, I do not want to make a global manager object
> that I need to pass around all the time, that would be silly..

Indeed. That would suck.

 Christoph

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

Re: Real globals inside a module

[Jorgen Bodde]

great! Thanks it makes perfect sense, but before attempting some code
rewrite I just wanted to be sure ;-)

Regards,
- Jorgen

On 5/13/07, Christoph Haas <[EMAIL PROTECTED]> wrote:
> On Sun, May 13, 2007 at 11:41:12AM +0200, Jorgen Bodde wrote:
> > I am wrestling with some architecture inside my app. Let's say I have
> > a tunings collection, which contains e.g. 23 types of guitar tunings.
> > In my song object I want to restore a relation between one of the
> > tuning objects inside the tunings module.
> >
> > I already figured out I need somethign like a global collection inside
> > the tunings module,. but how global is it? When I am inside my app
> > object, and import the tunings module, can I access the same global
> > class as when I am inside my songs module and load the tunings module?
>
> You are on the right way. If you import the same module a second time in
> another place of your application you get access to the exact same data.
> That is called a "singleton". I often use such a singleton for global
> configuration data.
>
> > So basically I want to access the same global list in both modules,
> > but not re-create the list in every module since it should be restored
> > by the database layer once.
>
> Import your global module and just run the initalisation once. That
> should do it.
>
> > Thanks for any advice, I do not want to make a global manager object
> > that I need to pass around all the time, that would be silly..
>
> Indeed. That would suck.
>
>  Christoph
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: __dict__ for instances?

[Bruno Desthuilliers]

Ivan Voras a écrit :
> [EMAIL PROTECTED] wrote:
> 
> 
>>I think you want "dir(instance)"  __dict__ returns the instance
> 
> 
> Part of the problem is that dir(instance) returns a list of strings, so
> iterating the dir(instance) gets me strings, not methods. Alternatively,
> is there a way to get a "bound" instance by its name - some
> introspection function perhaps?

getattr(obj, name)

> 
>>variables and values as a dictionary, but doesn't return methods.
> 
> 
> It does on a Class :(
> 
Usually, methods are attributes of the class, not of the instance.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: __dict__ for instances?

[Bruno Desthuilliers]

Ivan Voras a écrit :
> While using PyGTK, I want to try and define signal handlers
> automagically, without explicitly writing the long dictionary (i.e. I
> want to use signal_autoconnect()).
> 
> To do this, I need something that will inspect the current "self" and
> return a dictionary that looks like:
> 
> {
>   "method_name" : self.method_name
> }
> 
> Class.__dict__ does something very similar, but when I use it, either
> I'm doing something wrong or it doesn't return methods bound to "self",
> and python complains a wrong number of arguments is being passed to the
> methods (one instead of two).

You're not doing anything wrong, that's just how Python works. "methods" 
are wrapper objects around function objects attributes. The wrapping 
only happens at lookup time, and returns different kind of "method" 
wrapper (resp. unbound or bound methods) if the attribute is looked up 
on an instance or a class (there are also the staticmethod/classmethod 
things, but that's not your problem here).

You can build the dict you're looking for using dir() and getattr():

from types import MethodType

autoconnect_dict = {}
for name in dir(self):
   attr = getattr(self, name)
   if isinstance(attr, MethodType):
 autoconnect_dict[name] = attr
return autoconnect_dict


> instance.__dict__ on the other hand returns an empty dictionary.

the instance's __dict__ only stores per-instance attributes. While it's 
technically possible to attach methods per-instance, it's definitively a 
corner case.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Dynamic subclassing ?

[Bruno Desthuilliers]

manatlan a écrit :
> On 12 mai, 17:00, Bruno Desthuilliers
> <[EMAIL PROTECTED]> wrote:
> 
>>manatlan a écrit :
>>
>>
>>>I've got an instance of a class, ex :
>>
>>>b=gtk.Button()
>>
>>>I'd like to add methods and attributes to my instance "b".
>>>I know it's possible by hacking "b" with setattr() methods.
>>
>>You don't even need setattr() here, you can set the attributes directly.
>>
>>
>>
>>
>>>But i'd
>>>like to do it with inheritance, a kind of "dynamic subclassing",
>>>without subclassing the class, only this instance "b" !
>>
>>>In fact, i've got my instance "b", and another class "MoreMethods"
>>
>>>class MoreMethods:
>>>def  sayHello(self):
>>>  print "hello"
>>
>>You don't necessarily need subclassing here. What you want is a typical
>>use case of the Decorator pattern:
>>
>>class MoreMethods(object):
>>   def __init__(self, button):
>> self._button = button
>>
>>   def  sayHello(self):
>> print "hello"
>>
>>   def __getattr__(self, name):
>> return getattr(self._button, name)
>>
>>   def __setattr__(self, name, value):
>> if name in dir(self._button):
>>   setattr(self._button, name, value)
>> else:
>>   object.__setattr__(self, name, value)
>>
>>b = MoreMethods(gtk.Button())
>>b.set_label("k")
>>b.say_hello()
> 
> 
> except that "b" is not anymore a "gtk.Button", but a "MoreMethods"
> instance ...
> i'd like that "b" stay a "gtk.Button" ...
> 

I don't understand why, but... Then write a function that "inject" all 
the additionnal methods to your gtk.Button. Or do the 
composition/delegation the other way round, and monkeypatch gtk.Button's 
__getattr__.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Interesting list Validity (True/False)

[Steven D'Aprano]

On Sat, 12 May 2007 21:50:12 -0700, [EMAIL PROTECTED] wrote:

>> > Actually, it's this statement that's non-sensical.
>>
>> > 
>> > "if arg==True" tests whether the object known as arg is equal to the
>> > object known as True.
>> > 
>>
>> Not at all, it makes perfect sense. X == Y always tests whether the
>> argument X is equal to the object Y regardless of what X and Y are.
> 
> Except for the exceptions, that's why the statement is wrong.

But there are no exceptions. X == Y tests for equality. If it returns
True, then the objects are equal by definition. That's what equal means in
Python.

One can abuse the technology to give nonsensical results:

class EqualToEverything(object):
def __eq__(self, other):
return True

>>> x = EqualToEverything()
>>> x == 1.0
True
>>> x == [2.9, "hello world"]
True

but that's no different from any language that allows you to override
operators.



>> > None of these four examples are "equal" to any other.
>>
>> That's actually wrong, as you show further down.
> 
> No, it's not, as I show further down.

But you show no such thing.

Or, to put it another way:

Did! Did not! Did! Did not! Did! Did not! ...


>>  a = 1
>>  b = (1,)
>>  c = [1]
>>  d = gmpy.mpz(1)

[snip]

>>  a==d
>> > True
>>
>> See, a and d are equal.
> 
> No, they are not "equal". 

Of course they are. It says so right there: "a equals d" is true.


> Ints and mpzs should NEVER
> be used together in loops, even though it's legal.

Why ever not? If you need an mpz value in order to do something, and no
other data type will do, what would you suggest? Just give up and say
"Don't do this, because it is Bad, m'kay?"

> The ints
> ALWAYS have to be coerced to mpzs to perform arithmetic
> and this takes time...LOTS of it.

Really? Just how much time?

timeit.Timer("x == y", "import gmpy; x = 1; y = gmpy.mpz(1)").repeat()
timeit.Timer("x == y", "x = 1; y = 1").repeat()

I don't have gmpy installed here, so I can't time it, but I look forward
to seeing the results, if you would be so kind.

Even if it is terribly slow, that's just an implementation detail. What
happens when Python 2.7 comes out (or Python 3.0 or Python 99.78) and
coercion from int to mpz is lightning fast? Would you then say "Well,
int(1) and mpz(1) used to be unequal, but now they are equal?".

Me, I'd say they always were equal, but previously it used to be slow to
coerce one to the other.


> The absolute stupidest
> thing you can do (assuming n is an mpz) is:
> 
> while n >1:
> if n % 2 == 0:
> n = n/2
> else:
> n = 3*n + 1

Oh, I can think of much stupider things to do.

while len([math.sin(random.random()) for i in range(n)[:]][:]) > 1:
if len( "+" * \
int(len([math.cos(time.time()) for i in \
range(1000, n+1000)[:]][:])/2.0)) == 0:
n = len([math.pi**100/i for i in range(n) if i % 2 == 1][:])
else:
s = '+'
for i in range(n - 1):
s += '+'
s += s[:] + ''.join(reversed(s[:]))
s += s[:].replace('+', '-')[0:1]
n = s[:].count('+') + s[:].count('-')



> You should ALWAYS do:
> 
> ZED = gmpy.mpz(0)
> ONE = gmpy.mpz(1)
> TWO = gmpy.mpz(2)
> TWE = gmpy.mpz(3)
> 
> while n >ONE:
> if n % TWO == ZED:
> n = n/TWO
> else:
> n = TWE*n + ONE
> 
> This way, no coercion is performed.

I know that algorithm, but I don't remember what it is called...

In any case, what you describe is a local optimization. Its probably a
good optimization, but in no way, shape or form does it imply that mpz(1)
is not equal to 1.


>> > And yet a==d returns True. So why doesn't b==c
>> > also return True, they both have a 1 at index position 0?
>>
>> Why should they return true just because the contents are the same?
> 
> Why should the int 1 return True when compared to mpz(1)?

Because they both represent the same mathematical number, where as a list
containing 1 and a tuple containing 1 are different containers. Even if
the contents are the same, lists aren't equal to tuples.


> a = [1]
> b = [1]
> 
> returns True for a==b?

That's because both are the same kind of container, and they both have the
same contents.


> After all, it returns false if b is [2],
> so it looks at the content in this case. So for numerics,
> it's the value that matters, not the type. And this creates
> a false sense of "equality" when a==d returns True.

There's nothing false about it. Ask any mathematician, does 1 equal 1.0,
and they will say "of course". 


>> A bag
>> of shoes is not the same as a box of shoes, even if they are the same
>> shoes.
> 
> Exactly. For the very reason I show above. The fact that the int
> has the same shoes as the mpz doesn't mean the int should be
> used, it has to be coerced.

Ints are not containers. An int doesn't contain values, an int is the
value.

Numeric values are automatically coerced because that's more practical.
That's a design decision, and it works well.

As for gmpy.mpz, since equality tests ar

Re: Video: Professor of Physics Phd at Cal Tech says: 911 Inside Job

[Jim]

On Apr 29, 4:19 pm, Mitchell Jones <[EMAIL PROTECTED]> wrote:
> In article <[EMAIL PROTECTED]>,
>  War Office <[EMAIL PROTECTED]> wrote:
>
> > On 28 abr, 14:15, Eric Gisse <[EMAIL PROTECTED]> wrote:
> > > On Apr 24, 6:13 pm, [EMAIL PROTECTED] wrote:
>
> [snip]
>
> > > I love how folks like you ask for intellectual honesty when every
> > > effort is made to ignore evidence that doesn't agree with your
> > > presupposed findings.
>
> > Which evidence would that be?
>
> ***{I'm not a fan of the Bush administration, and would not put it past
> them to carry out an event such as 911, to create an excuse to jettison
> the Constitution and Bill of Rights. What is certain in any case is
> that, in fact, the Bush administration has used the events of 911 as an
> excuse to toss out the Constitution and Bill of Rights. There are,
> however, at least three possible scenarios regarding 911 itself:
>
> (1) The plane crashes were planned and executed by terrorists. The
> towers fell because of the impacts. Building 7 fell because of the
> impact of debris from the north tower.
>
> (2) The plane crashes were planned and executed by the Bush
> administration. The towers fell because of the impacts. Building 7 fell
> because of the impact of debris from the north tower.
>
> (3) The plane crashes were planned and executed by the Bush
> administration. The towers fell because of the impacts, plus the effects
> of pre-planted demolition charges. Building 7 fell because of the impact
> of debris from the north tower, plus the effects of pre-planted
> explosive charges.
>
> I analyzed (3), above, in great detail a month or so back, in a
> sci.physics thread entitled "The amazing denial of what "conspiracy
> kooks" really means" If you are really interested in a reasoned
> response to those arguments, you can probably still find that thread on
> Google.
>
> My conclusion at the time was that possibility (3), above, fails because
> pre-planted explosives are not needed to explain why the towers fell, or
> why building 7 fell. Possibilities (1) and (2), therefore, are all that
> remains.
>
> This post is for informational purposes only, and is not to be taken as
> an indication that I am interesting in slogging my way through all this
> stuff again. Once is more than enough, and so I am killfiling this
> thread after making this post.
>
> --Mitchell Jones}***
>
> *
> If I seem to be ignoring you, consider the possibility
> that you are in my killfile. --MJ

What has all this got to do with Python?

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

Re: design question

[Bruno Desthuilliers]

[EMAIL PROTECTED] a écrit :
> On May 12, 9:34 pm, Bjoern Schliessmann  [EMAIL PROTECTED]> wrote:
> 
> 
>>In principle, this is legal.
>>
>>But OTOH, how could a ShoppingCart "buy" something? In my world,
>>Buyers "buy" when using ShoppingCarts.
> 
> 
> Yes, I don't know either.  I got this assignment for my homework, and
> in UML diagram class ShoppingCart has method buy(), and the class
> Buyer doesn't have any methods, only attribute ShoppingCart, and I
> must simulate/implement online shopping.  In my world buyers buy too,
> just wanna check with somebody with more experience.  :)

It's alas pretty common to see OO taught by persons who'd rather do some 
other job - preferably not related to computers.

> Thank you both.
> 
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Interesting list Validity (True/False)

[Carsten Haese]

On Sat, 2007-05-12 at 18:43 -0700, [EMAIL PROTECTED] wrote:
> > That doesn't explain what you mean. How does "if arg==True" test whether
> > "a list is a boolean"?
> 
> >>> type(sys.argv)
> 
> >>> type(True)
> 

All right, so what you meant was "Assuming that arg is a list, 'if
arg==True' will always fail because lists never compare equal to any
boolean."

> Actually, it's this statement that's non-sensical.
> 
> 
> "if arg==True" tests whether the object known as arg is equal to the
> object known as True.
> 
>
> [snip examples of "surprising" equality tests...]

The statement I made is simply the meaning of "if arg==True" by
definition, so I don't see how it can be nonsensical.

The problem is that you consider equality tests in Python to be
nonsensical because they don't fit with your opinion of what equality
should mean.

Regards,

-- 
Carsten Haese
http://informixdb.sourceforge.net


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

Re: Setting thread priorities

[Grant Edwards]

On 2007-05-13, Gerald Kaszuba <[EMAIL PROTECTED]> wrote:
> Hi John
>
> On May 13, 4:46 pm, John Nagle <[EMAIL PROTECTED]> wrote:
>>There's no way to set thread priorities within Python, is there?
>
> Not exactly. You can however use the ctypes module to access the o/s
> methods of pthread_setschedparam() for UNIX and SetThreadPriority()
> for Windows.
>
> I'm not sure why this hasn't been implemented in Python.

AFAICT, Python's threading paradigm seems to be based on the
assumption that alls threads spend most of their time blocking
on I/O or some other event.  In that case priorities don't
matter. Priorities only matter if multiple threads are ready to
run.

-- 
Grant Edwards
[EMAIL PROTECTED]
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: __dict__ for instances?

[Marc Christiansen]

Ivan Voras <[EMAIL PROTECTED]> scribis:
> While using PyGTK, I want to try and define signal handlers
> automagically, without explicitly writing the long dictionary (i.e. I
> want to use signal_autoconnect()).
> 
> To do this, I need something that will inspect the current "self" and
> return a dictionary that looks like:
> 
> {
>  "method_name" : self.method_name
> }

Nope, at least for PyGTK 2 :) See below.

[...]
> This looks like it should be easy, but I can't find the solution :(

Use the doc, Luke, oops, Ivan :)
Citing the gtk.glade.XML.signal_autoconnect documentation: 
  def signal_autoconnect(dict)
  dict: a mapping or an instance

  
  The signal_autoconnect() method is a variation of the
  gtk.glade.XML.signal_connect method. It uses Python's introspective
  features to look at the keys (if dict is a mapping) or attributes (if
 ^^
  dict is an instance) and tries to match them with the signal handler
  ^^^
  names given in the interface description. The callbacks referenced by
  each matched key or attribute are connected to their matching signals.
  The argument is called dict due to compatibility reasons since
  originally only the mapping interface was supported. The instance
  variant was introduced in PyGTK 2.0.

So simply using signal_autoconnect(self) should work.

Adiaŭ, Marc
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: need help with python

[adamurbas]

On May 12, 11:55 am, BartlebyScrivener <[EMAIL PROTECTED]> wrote:
> I'm not sure how you installed Python, or how you are using it, but I
> made something last year to help Windows XP users who are brand new to
> Python and can't get things to run, etc.
>
> You might try either jumping into somewhere midway, or if you keep
> having trouble, uninstall whatever you installed and start over using
> this:
>
> http://www.richarddooling.com/index.php/2006/03/14/python-on-xp-7-min...
>
> If that link breaks, use this:
>
> http://tinyurl.com/w7wgp
>
> Good luck.
>
> rd

That is one of my problems, I don't know exactly how the whole command
line thing works.  The other day, I got it to open python by itself,
but I accidentally closed the window and couldn't get it to work
again.  I know how to do file paths and stuff but I'm not sure what to
put directly after it says C:\Documents and Settings\HP_Owner>.  Do I
leave it like that and then put the next location in the line?  Like
this:
C:\Documents and Settings\HP_Owner> Python 2.5.1\Python area.py
Or is that wrong.  I've already uninstalled and reinstalled because I
couldn't copy and paste it to another location, so I just reinstalled
it to HP_Owner.  I'll try that link.
Thanks.

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

PEP 3131: Supporting Non-ASCII Identifiers

[Martin v. Löwis]

PEP 1 specifies that PEP authors need to collect feedback from the
community. As the author of PEP 3131, I'd like to encourage comments
to the PEP included below, either here (comp.lang.python), or to
[EMAIL PROTECTED]

In summary, this PEP proposes to allow non-ASCII letters as
identifiers in Python. If the PEP is accepted, the following
identifiers would also become valid as class, function, or
variable names: Löffelstiel, changé, ошибка, or 売り場
(hoping that the latter one means "counter").

I believe this PEP differs from other Py3k PEPs in that it really
requires feedback from people with different cultural background
to evaluate it fully - most other PEPs are culture-neutral.

So, please provide feedback, e.g. perhaps by answering these
questions:
- should non-ASCII identifiers be supported? why?
- would you use them if it was possible to do so? in what cases?

Regards,
Martin


PEP: 3131
Title: Supporting Non-ASCII Identifiers
Version: $Revision: 55059 $
Last-Modified: $Date: 2007-05-01 22:34:25 +0200 (Di, 01 Mai 2007) $
Author: Martin v. Löwis <[EMAIL PROTECTED]>
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 1-May-2007
Python-Version: 3.0
Post-History:


Abstract


This PEP suggests to support non-ASCII letters (such as accented
characters, Cyrillic, Greek, Kanji, etc.) in Python identifiers.

Rationale
=

Python code is written by many people in the world who are not familiar
with the English language, or even well-acquainted with the Latin
writing system.  Such developers often desire to define classes and
functions with names in their native languages, rather than having to
come up with an (often incorrect) English translation of the concept
they want to name.

For some languages, common transliteration systems exist (in particular,
for the Latin-based writing systems).  For other languages, users have
larger difficulties to use Latin to write their native words.

Common Objections
=

Some objections are often raised against proposals similar to this one.

People claim that they will not be able to use a library if to do so
they have to use characters they cannot type on their keyboards.
However, it is the choice of the designer of the library to decide on
various constraints for using the library: people may not be able to use
the library because they cannot get physical access to the source code
(because it is not published), or because licensing prohibits usage, or
because the documentation is in a language they cannot understand.  A
developer wishing to make a library widely available needs to make a
number of explicit choices (such as publication, licensing, language
of documentation, and language of identifiers).  It should always be the
choice of the author to make these decisions - not the choice of the
language designers.

In particular, projects wishing to have wide usage probably might want
to establish a policy that all identifiers, comments, and documentation
is written in English (see the GNU coding style guide for an example of
such a policy). Restricting the language to ASCII-only identifiers does
not enforce comments and documentation to be English, or the identifiers
actually to be English words, so an additional policy is necessary,
anyway.

Specification of Language Changes
=

The syntax of identifiers in Python will be based on the Unicode
standard annex UAX-31 [1]_, with elaboration and changes as defined
below.

Within the ASCII range (U+0001..U+007F), the valid characters for
identifiers are the same as in Python 2.5.  This specification only
introduces additional characters from outside the ASCII range.  For
other characters, the classification uses the version of the Unicode
Character Database as included in the ``unicodedata`` module.

The identifier syntax is `` *``.

``ID_Start`` is defined as all characters having one of the general
categories uppercase letters (Lu), lowercase letters (Ll), titlecase
letters (Lt), modifier letters (Lm), other letters (Lo), letter numbers
(Nl), plus the underscore (XXX what are "stability extensions" listed in
UAX 31).

``ID_Continue`` is defined as all characters in ``ID_Start``, plus
nonspacing marks (Mn), spacing combining marks (Mc), decimal number
(Nd), and connector punctuations (Pc).

All identifiers are converted into the normal form NFC while parsing;
comparison of identifiers is based on NFC.

Policy Specification


As an addition to the Python Coding style, the following policy is
prescribed: All identifiers in the Python standard library MUST use
ASCII-only identifiers, and SHOULD use English words wherever feasible.

As an option, this specification can be applied to Python 2.x.  In that
case, ASCII-only identifiers would continue to be represented as byte
string objects in namespace dictionaries; identifiers with non-ASCII
characters would be represented as Unicode strings.

Implementation
==

The follo

Re: PEP 3131: Supporting Non-ASCII Identifiers

[dustin]

On Sun, May 13, 2007 at 05:44:39PM +0200, "Martin v. L??wis" wrote:
> - should non-ASCII identifiers be supported? why?

The only objection that comes to mind is that adding such support may
make some distinct identifiers visually indistinguishable.  IIRC the DNS
system has had this problem, leading to much phishing abuse.

I don't necessarily think that the objection is strong enough to reject
the idea -- programmers using non-ASCII symbols would be responsible for
the consequences of their character choice.

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

Re: PEP 3131: Supporting Non-ASCII Identifiers

[Martin v. Löwis]

> The only objection that comes to mind is that adding such support may
> make some distinct identifiers visually indistinguishable.  IIRC the DNS
> system has had this problem, leading to much phishing abuse.

This is a commonly-raised objection, but I don't understand why people
see it as a problem. The phishing issue surely won't apply, as you
normally don't "click" on identifiers, but rather type them. In a
phishing case, it is normally difficult to type the fake character
(because the phishing relies on you mistaking the character for another
one, so you would type the wrong identifier).

People have mentioned that this could be used to obscure your code - but
there are so many ways to write obscure code that I don't see a problem
in adding yet another way.

People also mentioned that they might mistake identifiers in a regular,
non-phishing, non-joking scenario, because they can't tell whether the
second letter of MAXLINESIZE is a Latin A or Greek Alpha. I find that
hard to believe - if the rest of the identifier is Latin, the A surely
also is Latin, and if the rest is Greek, it's likely an Alpha. The issue
is only with single-letter identifiers, and those are most common
as local variables. Then, it's an Alpha if there is also a Beta and
a Gamma as a local variable - if you have B and C also, it's likely A.

> I don't necessarily think that the objection is strong enough to reject
> the idea -- programmers using non-ASCII symbols would be responsible for
> the consequences of their character choice.

Indeed.

Martin

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

Re: How to installo????

[RonV]

On 10 May 2007 13:54:04 -0700, [EMAIL PROTECTED] wrote:


>I would recommend using the command line. Open that up and then type
>something like this:
>
>python pathToWinExt\setup.py
>
>That should run it and when it's done, your command window should stay
>open. Hopefully it will tell you what happened.
>
>Since I don't have Vista and don't know if it will recognize the name
>"python", you may need to specify a path to it too.
>
>Good luck!
>
>Mike

Thanks, Mike.  I'd forgotten about the command line technique, having
used point & click in XP.   I found it was actually:
setup.py install

However, I'm getting the message that setup cannot find an installed
platform SDK,  '

I have VB6 installed, so that should have done it.  It's like the
script cannot locate the SDK, any ideas??

Ron

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

Re: OMG BRITNEYS AT IT AGAIN AGAIN!!!!!! You stupid fucks! Can't you figger out why we white boys ain't fucking these white trash bitches?

[MMM]

On 11 May 2007 14:57:21 -0700, [EMAIL PROTECTED] wrote:

>http://britneyboobs.blogspot.com/2007/05/britney-spears-slips-up-again-exposes.html
>- Exclusive pics of Britney Spears..
Stoopid dog fuckers!We crackers went to school with these bitches for
at least 6 grades and decided they are so ignorant that they do not
need to reproduce because of their offsprings damage to the social
order of the working class.
   Now here you come and think you have found hidden "gold" and give
these dumbass whores your shit and they get preg and spew out a dozen
kids like a bitch dog. 
  Leave them bitches alone you dumbass!Take a hint..don't breed the
trash hoes dude! Get it now?
-- 
http://mail.python.org/mailman/listinfo/python-list

elementtree and entities

[Daniel Nogradi]

Hi list,

How does one prevent elementtree converting & to & (and similarly
for other entities)?

>>> from xml.etree import ElementTree as et
>>> x = et.Element( 'test' )
>>> x.text = '&'
>>> et.tostring( x )
'&'

Sometimes I would like to have the output '&'

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

Re: Interesting list Validity (True/False)

[[EMAIL PROTECTED]]

On May 13, 8:57?am, Carsten Haese <[EMAIL PROTECTED]> wrote:
> On Sat, 2007-05-12 at 18:43 -0700, [EMAIL PROTECTED] wrote:
> > > That doesn't explain what you mean. How does "if arg==True" test whether
> > > "a list is a boolean"?
>
> > >>> type(sys.argv)
> > 
> > >>> type(True)
> > 
>
> All right, so what you meant was "Assuming that arg is a list, 'if
> arg==True' will always fail because lists never compare equal to any
> boolean."
>
> > Actually, it's this statement that's non-sensical.
>
> > 
> > "if arg==True" tests whether the object known as arg is equal to the
> > object known as True.
> > 
>
> > [snip examples of "surprising" equality tests...]
>
> The statement I made is simply the meaning of "if arg==True" by
> definition, so I don't see how it can be nonsensical.

Because you didn't allow for exceptions, which are
prominently pointed out in the Python docs.

>
> The problem is that you consider equality tests in Python to be
> nonsensical because they don't fit with your opinion of what equality
> should mean.

No, it has nothing to do with what it means. 1, [1], (1,)
and mpz(1) are all different types and all mathmatically
the same. Yet 1 and mpz(1) compare equal but (1,) and
[1] do not. The later fails due to type mis-match, the
former does not despite type mis-match due to the fact
they are the same mathematically.

I'm not saying the situation is wrong, what I'm saying
is that somone who doesn't understand why arg==True
is failing should be told ALL the rules, not just the easy
ones.

>
> Regards,
>
> --
> Carsten Haesehttp://informixdb.sourceforge.net


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

Using "subprocess" without lists. . .?

[Michael Williams]

Hi All,

I've recently seen the "subprocess" module and am rather confused by  
it's requirements.  Is it not possible to execute an entire string  
without having to break them up into a list of arguments?  For  
instance, I'd much rather do the following:


subprocess.call("ls -al | grep -i test")


. . .than to have to:


list = ["ls", "-a", "-l" ]  . . . . . . and so on and so forth.
subprocess.call(list. . .)


What is the best way to go about executing a massively complex single  
line command?


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

Re: PEP 3131: Supporting Non-ASCII Identifiers

[André]

On May 13, 12:44 pm, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> PEP 1 specifies that PEP authors need to collect feedback from the
> community. As the author of PEP 3131, I'd like to encourage comments
> to the PEP included below, either here (comp.lang.python), or to
> [EMAIL PROTECTED]
>
> In summary, this PEP proposes to allow non-ASCII letters as
> identifiers in Python. If the PEP is accepted, the following
> identifiers would also become valid as class, function, or
> variable names: Löffelstiel, changé, ошибка, or 売り場
> (hoping that the latter one means "counter").
>
> I believe this PEP differs from other Py3k PEPs in that it really
> requires feedback from people with different cultural background
> to evaluate it fully - most other PEPs are culture-neutral.
>
> So, please provide feedback, e.g. perhaps by answering these
> questions:
> - should non-ASCII identifiers be supported? why?

I use to think differently.  However, I would say a strong YES.  They
would be extremely useful when teaching programming.

> - would you use them if it was possible to do so? in what cases?

Only if I was teaching native French speakers.

> Policy Specification
> 
>
> As an addition to the Python Coding style, the following policy is
> prescribed: All identifiers in the Python standard library MUST use
> ASCII-only identifiers, and SHOULD use English words wherever feasible.
>

I would add something like:

Any module released for general use SHOULD use ASCII-only identifiers
in the public API.

Thanks for this initiative.

André

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

Re: elementtree and entities

[Duncan Booth]

"Daniel Nogradi" <[EMAIL PROTECTED]> wrote:

> Hi list,
> 
> How does one prevent elementtree converting & to & (and similarly
> for other entities)?
> 
 from xml.etree import ElementTree as et
 x = et.Element( 'test' )
 x.text = '&'
 et.tostring( x )
> '&'
> 
> Sometimes I would like to have the output '&'
> 
> Daniel
> 

elementtree is for processing xml. If you want to output something which 
isn't xml then you'll have to use a different library or mess about with 
the xml after it has been generated:

   et.tostring(x).replace('&', '&')

does what you want, but you won't be able to parse it again with anything 
which expects xml.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: need help with python

[Paul McGuire]

On May 13, 10:10 am, [EMAIL PROTECTED] wrote:
> On May 12, 11:55 am, BartlebyScrivener <[EMAIL PROTECTED]> wrote:
>
>
>
>
>
> > I'm not sure how you installed Python, or how you are using it, but I
> > made something last year to help Windows XP users who are brand new to
> > Python and can't get things to run, etc.
>
> > You might try either jumping into somewhere midway, or if you keep
> > having trouble, uninstall whatever you installed and start over using
> > this:
>
> >http://www.richarddooling.com/index.php/2006/03/14/python-on-xp-7-min...
>
> > If that link breaks, use this:
>
> >http://tinyurl.com/w7wgp
>
> > Good luck.
>
> > rd
>
> That is one of my problems, I don't know exactly how the whole command
> line thing works.  The other day, I got it to open python by itself,
> but I accidentally closed the window and couldn't get it to work
> again.  I know how to do file paths and stuff but I'm not sure what to
> put directly after it says C:\Documents and Settings\HP_Owner>.  Do I
> leave it like that and then put the next location in the line?  Like
> this:
> C:\Documents and Settings\HP_Owner> Python 2.5.1\Python area.py
> Or is that wrong.  I've already uninstalled and reinstalled because I
> couldn't copy and paste it to another location, so I just reinstalled
> it to HP_Owner.  I'll try that link.
> Thanks.- Hide quoted text -
>
> - Show quoted text -

cd 

will change your current directory to .  Type "help"
after the "C:\Documents and Settings\HP_Owner>" (which is called the
'prompt') to get a summarized list of commands, or "help " to
get help on that particular command.  For instance try typing this at
the command line prompt:

help cd

and you'll get a lot more info on the cd command.

It sounds like a Windows tutorial would not be wasted time for you,
especially one that helps with the whole command line thing.  You'll
learn about files, directories, deleting, renaming, and so on.

-- Paul

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

Re: __dict__ for instances?

[half . italian]

On May 13, 4:30 am, Ivan Voras <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> > I think you want "dir(instance)"  __dict__ returns the instance
>
> Part of the problem is that dir(instance) returns a list of strings, so
> iterating the dir(instance) gets me strings, not methods. Alternatively,
> is there a way to get a "bound" instance by its name - some
> introspection function perhaps?
>
> > variables and values as a dictionary, but doesn't return methods.
>
> It does on a Class :(
>
> --
> (\__/)
> (O.o)
> (> < )
>
> This is Bunny.
> Copy Bunny into your signature to help him on his way to world domination!
>
>  signature.asc
> 1KDownload

I tried.

~Sean

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

Re: package rating system for the Cheese Shop

[Steven Bethard]

[EMAIL PROTECTED] wrote:
> On May 12, 2:49 pm, Steven Bethard <[EMAIL PROTECTED]> wrote:
>> [EMAIL PROTECTED] wrote:
>>> Is there a package rating system for the Cheese Shop, like how Perl
>>> has cpanratings (http://cpanratings.perl.org/)?
>> I don't know CPAN, but maybe this is what you're looking for:
>>
>>  http://www.cheeserater.com/
>>
>> ?
>>
>> STeVe
> 
> Thanks for the link STeVe. Yes, this is the sort of thing I was
> looking for. Looks like there's no way to actually leave comments on a
> package though; just a (+) or (-) rating. No way to say something
> like, "I like x, y, and z about this package, but n, m, and especially
> o need to get fixed" though.
> 
> One strength of cpanratings is you can leave those comments. A well-
> written review comment, like "I used this package, and here's how it
> worked out ... If you need , you might try  y> instead of this one." is much more valuable than a thumbs-up or
> thumbs-down.

It might be worth sending those comments to whoever maintains that site. 
  Looks like either "Jacob Kaplan-Moss" (http://www.jacobian.org/) or 
"Jeff Croft" (http://www.jeffcroft.com/)

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

Re: elementtree and entities

[Daniel Nogradi]

> > How does one prevent elementtree converting & to & (and similarly
> > for other entities)?
> >
>  from xml.etree import ElementTree as et
>  x = et.Element( 'test' )
>  x.text = '&'
>  et.tostring( x )
> > '&'
> >
> > Sometimes I would like to have the output '&'
> >
>
> elementtree is for processing xml. If you want to output something which
> isn't xml then you'll have to use a different library or mess about with
> the xml after it has been generated:
>
>et.tostring(x).replace('&', '&')
>
> does what you want, but you won't be able to parse it again with anything
> which expects xml.

Thanks for the reply, I'll just live with replace then.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Using "subprocess" without lists. . .?

[Steven Bethard]

Michael Williams wrote:
> Hi All,
> 
> I've recently seen the "subprocess" module and am rather confused by 
> it's requirements.  Is it not possible to execute an entire string 
> without having to break them up into a list of arguments?  For instance, 
> I'd much rather do the following:
> 
> 
> subprocess.call("ls -al | grep -i test")
> 
> 
> . . .than to have to:
> 
> 
> list = ["ls", "-a", "-l" ]  . . . . . . and so on and so forth.
> subprocess.call(list. . .)
> 
> 
> What is the best way to go about executing a massively complex single 
> line command?


You could always call "ls -al | grep -i test".split().

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

Re: __dict__ for instances?

[Ivan Voras]

Marc Christiansen wrote:

> Nope, at least for PyGTK 2 :) See below.

Aaah, but!

> [...]
>> This looks like it should be easy, but I can't find the solution :(
> 
> Use the doc, Luke, oops, Ivan :)
> Citing the gtk.glade.XML.signal_autoconnect documentation: 
>   def signal_autoconnect(dict)
>   dict: a mapping or an instance
> 

I should have mentioned - I tried it already and it didn't work. The
specific error I get is:

"WARNING: "on_button_clicked" not callable or a tuple"

once for each handler when I call autoconnect. And I've got a recent
version of pyGTK (2.10.4) so it should.


-- 
(\__/)
(O.o)
(> < )

This is Bunny.
Copy Bunny into your signature to help him on his way to world domination!



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

Re: __dict__ for instances?

[Ivan Voras]

Bruno Desthuilliers wrote:

> You're not doing anything wrong, that's just how Python works. "methods"
> are wrapper objects around function objects attributes. The wrapping
> only happens at lookup time, and returns different kind of "method"
> wrapper (resp. unbound or bound methods) if the attribute is looked up
> on an instance or a class (there are also the staticmethod/classmethod
> things, but that's not your problem here).

Got it, thanks for the explanation!



-- 
(\__/)
(O.o)
(> < )

This is Bunny.
Copy Bunny into your signature to help him on his way to world domination!



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

Re: PEP 3131: Supporting Non-ASCII Identifiers

[John Nagle]

Martin v. Löwis wrote:
> PEP 1 specifies that PEP authors need to collect feedback from the
> community. As the author of PEP 3131, I'd like to encourage comments
> to the PEP included below, either here (comp.lang.python), or to
> [EMAIL PROTECTED]
> 
> In summary, this PEP proposes to allow non-ASCII letters as
> identifiers in Python. If the PEP is accepted, the following
> identifiers would also become valid as class, function, or
> variable names: Löffelstiel, changé, ошибка, or 売り場
> (hoping that the latter one means "counter").


> All identifiers are converted into the normal form NFC while parsing;
> comparison of identifiers is based on NFC.

 That may not be restrictive enough, because it permits multiple
different lexical representations of the same identifier in the same
text.  Search and replace operations on source text might not find
all instances of the same identifier.  Identifiers should be required
to be written in source text with a unique source text representation,
probably NFC, or be considered a syntax error.

 I'd suggest restricting identifiers under the rules of UTS-39,
profile 2, "Highly Restrictive".  This limits mixing of scripts
in a single identifier; you can't mix Hebrew and ASCII, for example,
which prevents problems with mixing right to left and left to right
scripts.  Domain names have similar restrictions.

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

Re: PEP 3131: Supporting Non-ASCII Identifiers

[Paul Rubin]

"Martin v. Löwis" <[EMAIL PROTECTED]> writes:
> So, please provide feedback, e.g. perhaps by answering these
> questions:
> - should non-ASCII identifiers be supported? why?

No, and especially no without mandatory declarations of all variables.
Look at the problems of non-ascii characters in domain names and the
subsequent invention of Punycode.  Maintaining code that uses those
identifiers in good faith will already be a big enough hassle, since
it will require installing and getting familiar with keyboard setups
and editing tools needed to enter those characters.  Then there's the
issue of what happens when someone tries to slip a malicious patch
through a code review on purpose, by using homoglyphic characters
similar to the way domain name phishing works.  Those tricks have also
been used to re-insert bogus articles into Wikipedia, circumventing
administrative blocks on the article names.

> - would you use them if it was possible to do so? in what cases?

I would never insert them into a program.  In existing programs where
they were used, I would remove them everywhere I could.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Using "subprocess" without lists. . .?

[Peter Otten]

Michael Williams wrote:

> I've recently seen the "subprocess" module and am rather confused by
> it's requirements.  Is it not possible to execute an entire string
> without having to break them up into a list of arguments?  For
> instance, I'd much rather do the following:
> 
> 
> subprocess.call("ls -al | grep -i test")

Try

subprocess.call("ls -al | grep -i test", shell=True)

> 
> 
> . . .than to have to:
> 
> 
> list = ["ls", "-a", "-l" ]  . . . . . . and so on and so forth.
> subprocess.call(list. . .)

which avoids a lot of problems with shell quoting.

Peter


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

Re: Using "subprocess" without lists. . .?

[Peter Otten]

Steven Bethard wrote:

> You could always call "ls -al | grep -i test".split().

Or better, shlex.split().

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

Re: PEP 3131: Supporting Non-ASCII Identifiers

[André]

On May 13, 2:30 pm, John Nagle <[EMAIL PROTECTED]> wrote:
> Martin v. Löwis wrote:
> > PEP 1 specifies that PEP authors need to collect feedback from the
> > community. As the author of PEP 3131, I'd like to encourage comments
> > to the PEP included below, either here (comp.lang.python), or to
> > [EMAIL PROTECTED]
>
> > In summary, this PEP proposes to allow non-ASCII letters as
> > identifiers in Python. If the PEP is accepted, the following
> > identifiers would also become valid as class, function, or
> > variable names: Löffelstiel, changé, ошибка, or 売り場
> > (hoping that the latter one means "counter").
> > All identifiers are converted into the normal form NFC while parsing;
> > comparison of identifiers is based on NFC.
>
>  That may not be restrictive enough, because it permits multiple
> different lexical representations of the same identifier in the same
> text.  Search and replace operations on source text might not find
> all instances of the same identifier.  Identifiers should be required
> to be written in source text with a unique source text representation,
> probably NFC, or be considered a syntax error.
>
>  I'd suggest restricting identifiers under the rules of UTS-39,
> profile 2, "Highly Restrictive".  This limits mixing of scripts
> in a single identifier; you can't mix Hebrew and ASCII, for example,
> which prevents problems with mixing right to left and left to right
> scripts.  Domain names have similar restrictions.
>
> John Nagle

Python keywords MUST be in ASCII ... so the above restriction can't
work.  Unless the restriction is removed (which would be a separate
PEP).

André

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

Re: PEP 3131: Supporting Non-ASCII Identifiers

[Paul Rubin]

"Martin v. Löwis" <[EMAIL PROTECTED]> writes:
> This is a commonly-raised objection, but I don't understand why people
> see it as a problem. The phishing issue surely won't apply, as you
> normally don't "click" on identifiers, but rather type them. In a
> phishing case, it is normally difficult to type the fake character
> (because the phishing relies on you mistaking the character for another
> one, so you would type the wrong identifier).

It certainly does apply, if you're maintaining a program and someone
submits a patch.  In that case you neither click nor type the
character.  You'd normally just make sure the patched program passes
the existing test suite, and examine the patch on the screen to make
sure it looks reasonable.  The phishing possibilities are obvious.
-- 
http://mail.python.org/mailman/listinfo/python-list

GUI tutorial

[John K Masters]

Can someone point me in the direction of a good tutorial on programming
python with a GUI? I'm just starting out with python and have written a
few scripts successfully but would like to add a graphical front end to
them to make it easier for my work colleagues, most of whom have never
used a command line, to use.

Regards, John
-- 
War is God's way of teaching Americans geography
Ambrose Bierce (1842 - 1914)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: need help with python

[BartlebyScrivener]

On May 13, 10:10 am, [EMAIL PROTECTED] wrote:
>
> That is one of my problems, I don't know exactly how the whole command
> line thing works.

That's why I pointed you to the link. The ActiveState distribution
will automatically add the correct paths to your environment and tell
Windows that .py files are executable Python files and so on.

Get ActiveState installed. Get comfortable with the Python IDE.

Then follow the instructions in Alan Gauld's tutorial.

http://www.freenetpages.co.uk/hp/alan.gauld/

Especially, in your case, the GETTING STARTED section, which includes
a subsection called "The Windows Command Prompt"

rd

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

Re: Using "subprocess" without lists. . .?

[Steven Howe]

Michael Williams wrote:

Hi All,

I've recently seen the "subprocess" module and am rather confused by  
it's requirements.  Is it not possible to execute an entire string  
without having to break them up into a list of arguments?  For  
instance, I'd much rather do the following:



subprocess.call("ls -al | grep -i test")


. . .than to have to:


list = ["ls", "-a", "-l" ]  . . . . . . and so on and so forth.
subprocess.call(list. . .)


What is the best way to go about executing a massively complex single  
line command?



Thanks,
Michael
  

How about a hybrid solution?:

   from subprocess import Popen, PIPE
   from string import strip
   (stdout, stderr) = Popen(['ls','-al'], stdout=PIPE,
   stderr=PIPE).communicate()
   /# process spins off. Ideally, you should wait for it to complete,
   or assign the resulting object of Popen
   # to a variable and inquire if it's completed via the 'poll()'
   operator or wait on it via the 'wait()'
   # operator.
   # then query the stderr via communicate()[1]; if good, i.e.
   len(stderr) == 0, inspect the resulting
   # stdout string (via communicate()[0]) for your 'test' result. But
   I'm being lazy. I assume the call to
   # ls -al will be faster then my next statement./
   res = []
   for line in stdout.strip():
   if 'test' in line:
  res.append( line )


Do the work you need done at the shell prompt, do the rest in Python. 
Also I wonder if, you were looking for the word 'test' in the filename,  
glob.glob wouldn't have been a bit more efficient? But if you were 
looking for a 'test' owner or group then using:


   glob.glob(): get the _list_ of  files, with directory. Example: 
   *glob.glob('/bin/*') *

   os.stat(): get an _object_ of stats on a file. Example:*
   os.stat('/bin/ls')*
   stat.ST_UID: get just the group id, as an _integer_ from the object
   returned by os.stat. Example: *os.stat('/bin/ls')[stat.ST_UID]
   *pwd.getpwgid(): get the _string_ translation of a UID. Example:
   *pwd.getpwgid( os.stat('/bin/ls')[stat.ST_UID] )*
   stat.ST_GID: get the group id, as an _integer_ from the object
   returned os.stat. Example:
   *os.stat('/bin/ls')[stat.ST_GID]*
   grp.getgrgid(): get the _string_ translation of a UID. Example:
   *grp.getgrgid( os.stat('/bin/ls')[stat.ST_UID] )*

Now I have a list, which I iterate over, getting the UID and GID, as 
strings, that I can compare to. I never had to use a subprocess and 
having to build up a 'wait on done loop'.  Note, grp and pwd, I think, 
are Python/Unix functions. What one does on Windows I don't know, but 
I'll bet there are similar functions under Python/Windows. Don't get me 
wrong, Subprocess is a fast and damn useful tool. I often use it to 
verify a program is in my path, before creating a subprocess to run some 
task python isn't built for (like mencoder functionality).


You see, the issue is: _shell,_ _python & shell_ or _python alone_. When 
transitioning from one language to another, say C/C++/Java to Python, it 
is often easier to use your knowledge of the shell command (bash/Bourne 
for example) to get things done. But it's only a transitional issue. The 
need to use the shell is a good demonstrator that either the Interpretor 
is weak, or that you haven't fully explored it's abilities. With the 
Python Interpretor at v2.4 going onto v2.5, it's very likely that the 
desired feature exists; you have but to do some clever research to find 
it. As to clever research ... I find Google a good place to start.


I had some familiarity with os.stat and glob. But the grp and pwd 
functions were things I discovered from 
http://docs.python.org/modindex.html and about two minutes of searching 
for 'python uid to name' @ Google.


Also, os.listdir and os.path.join would have worked just as well as 
glob.glob('dirname/*'). But glob.glob was faster to write. Even a better 
choice would have been to use the 'os.walk' to iterate over the 
directory tree.


sph.

--
HEX: 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0

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

Re: PEP 3131: Supporting Non-ASCII Identifiers

[André]

On May 13, 12:44 pm, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> PEP 1 specifies that PEP authors need to collect feedback from the
> community. As the author of PEP 3131, I'd like to encourage comments
> to the PEP included below, either here (comp.lang.python), or to
> [EMAIL PROTECTED]
>

It should be noted that the Python community may use other forums, in
other languages.  They would likely be a lot more enthusiastic about
this PEP than the usual crowd here (comp.lang.python).

André


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

Re: PEP 3131: Supporting Non-ASCII Identifiers

[Anton Vredegoor]

Martin v. Löwis wrote:

> In summary, this PEP proposes to allow non-ASCII letters as
> identifiers in Python. If the PEP is accepted, the following
> identifiers would also become valid as class, function, or
> variable names: Löffelstiel, changé, ошибка, or 売り場
> (hoping that the latter one means "counter").

I am against this PEP for the following reasons:

It will split up the Python user community into different language or 
interest groups without having any benefit as to making the language 
more expressive in an algorithmic way.

Some time ago there was a discussion about introducing macros into the 
language. Among the reasons why macros were excluded was precisely 
because anyone could start writing their own kind of dialect of Python 
code, resulting in less people being able to read what other programmers 
wrote. And that last thing: 'Being able to easily read what other people 
wrote' (sometimes that 'other people' is yourself half a year later, but 
that isn't relevant in this specific case) is one of the main virtues in 
the Python programming community. Correct me if I'm wrong please.

At that time I was considering to give up some user conformity because 
the very powerful syntax extensions would make Python rival Lisp. It's 
worth sacrificing something if one gets some other thing in return.

However since then we have gained metaclasses, iterators and generators 
and even a C-like 'if' construct. Personally I'd also like to have a 
'repeat-until'. These things are enough to keep us busy for a long time 
and in some respects this new syntax is even more powerful/dangerous 
than macros. But most importantly these extra burdens on the ease with 
which one is to read code are offset by gaining more expressiveness in 
the *coding* of scripts.

While I have little doubt that in the end some stubborn mathematician or 
Frenchman will succeed in writing a preprocessor that would enable him 
to indoctrinate his students into his specific version of reality, I see 
little reason to actively endorse such foolishness.

The last argument I'd like to make is about the very possibly reality 
that in a few years the Internet will be dominated by the Chinese 
language instead of by the English language. As a Dutchman I have no 
special interest in English being the language of the Internet but 
-given the status quo- I can see the advantages of everyone speaking the 
*same* language. If it be Chinese, Chinese I will start to learn, 
however inept I might be at it at first.

That doesn't mean however that one should actively open up to a kind of 
contest as to which language will become the main language! On the 
contrary one should hold out as long as possible to the united group one 
has instead of dispersing into all kinds of experimental directions.

Do we harm the Chinese in this way one might ask by making it harder for 
them to gain access to the net? Do we harm ourselves by not opening up 
in time to the new status quo? Yes, in a way these are valid points, but 
one should not forget that more advanced countries also have a 
responsibility to lead the way by providing an example, one should not 
think too lightly about that.

Anyway, I feel that it will not be possible to hold off these 
developments in the long run, but great beneficial effects can still be 
attained by keeping the language as simple and expressive as possible 
and to adjust to new realities as soon as one of them becomes undeniably 
apparent (which is something entirely different than enthusiastically 
inviting them in and let them fight it out against each other in your 
own house) all the time taking responsibility to lead the way as long as 
one has any consensus left.

A.




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

Re: GUI tutorial

[Paul Rubin]

John K Masters <[EMAIL PROTECTED]> writes:
> Can someone point me in the direction of a good tutorial on programming
> python with a GUI? I'm just starting out with python and have written a
> few scripts successfully but would like to add a graphical front end to
> them to make it easier for my work colleagues, most of whom have never
> used a command line, to use.

http://infohost.nmt.edu/tcc/help/pubs/tkinter/ is pretty good.  You
could alternatively consider writing your script as a web server or
web app, so the gui would be a browser.  That puts some limitations on
the gui design but it makes development and deployment both simpler.
Develoment is simpler because you just use regular HTML instead of
weird libraries and callbacks and threads and all that crap.
Deployment is simpler because you can install and run the program on
one machine, send the url to your colleagues, and update the program
as needed without having to get your colleagues constantly installing
new versions.  For security reasons, be careful to not expose the web
interface to the public internet until you know what you're doing.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: GUI tutorial

[vasudevram]

On May 13, 10:51 pm, John K Masters <[EMAIL PROTECTED]>
wrote:
> Can someone point me in the direction of a good tutorial on programming
> python with a GUI? I'm just starting out with python and have written a
> few scripts successfully but would like to add a graphical front end to
> them to make it easier for my work colleagues, most of whom have never
> used a command line, to use.
>
> Regards, John
> --
> War is God's way of teaching Americans geography
> Ambrose Bierce (1842 - 1914)


That depends on which GUI toolkit you want to use.

There are at least one or two good online tutorials on the Web for
Tkinter (the Python interface to the Tk toolkit).
One is by Fredrik Lundh (a.k.a the effbot, a leading Python
contributor). Google for suitable keywords, e.g. Tkinter tutorial.

Tkinter comes with Python by default on Windows, so that helps. But
wxPython is not a bad toolkit either.
(You'll have to download and install it, also the demos (see below)
are often a separate download.)
I've used it some, and like it. I don't know of any tutorials for it,
though there may be some - again, Google for info.
But if you already have some GUI programming background, its not too
difficult to pick up it up. It comes with a big set of demos with
source code, and I was able to learn enough wxPython to write some
simple apps just by looking at the demos source code and reading some
of the reference documentation. Those apps are here:

http://www.packtpub.com/article/Using_xtopdf

Check the last part of the article for links to the source code.

PyQt is another option, recommended by some people. Haven't tried it
myself but have used Qt (the C++ GUI toolkit to which PyQt is a
binding) a little, and like it a lot. Qt again is supposed to be of
very high quality, according to some people. I am currently reading a
book Programming Qt and found most of it pretty straightforward
(though not simple :-) to understand (you do need to understand the
concept of signals and slots, as that is fundamental to Qt
programming).

HTH
Vasudev Ram
Dancing Bison Enterprises
http://www.dancingbison.com


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

Re: Off Topic: Is the use of supererogatory supererogatory?

[Alex Martelli]

Paddy <[EMAIL PROTECTED]> wrote:

> On May 13, 12:13 am, [EMAIL PROTECTED] (Alex Martelli) wrote:
> 
> > As somebody else alredy pointed out, the lambda is supererogatory (to
> > say the least).
> 
> What a wonderful new word!
> I did not know what supererogatory meant, and hoped it had nothing to
> do with Eros :-)
> Answers.com gave me a meaning synonymous with superfluous, which
> I think is what was meant here,

Kind of, yes, cfr  .

> but Chambers gave a wonderful
> definition where they say it is from the RC Church practice of doing
> more
> devotions than are necessary  so they can be 'banked' for distribution
> to others (I suspect, that in the past it may have been for a fee or
> a favour).

"Doing more than necessary" may be wonderful in a devotional context,
but not necessarily in an engineering one (cfr also, for a slightly
different slant on "do just what's needed",
).

> Supererogatory, my word of the day.

Glad you liked it!-)


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

Re: Dynamic subclassing ?

[Alex Martelli]

manatlan <[EMAIL PROTECTED]> wrote:
   ...
> > def addaclass(aninst, onemoreclass):
> > aninst.__class__ = type(aninst.__aclass__.__name__,
> > (aninst.__aclass__, onemoreclass), {})
   ...
> b=gtk.Button("the_label")
> addaclass(b,MoreMethods)
   ...
> "TypeError: __class__ assignment: only for heap types"
> on the last line ...

Ah, yes, a type can be coded in such a way that you simply can't
reassign the __class__ of its instances, and apparently gtk.Button is
coded that way.

If you're keen on __class__ reassigning, you'll have to wrap such
classes before instance creation time, e.g.:

class weirdGtkButton(gtk.Button): pass

and use

b = weirdGtkButton("the label")

to generate the instances.  That, of course, assumes that gtk.Button
isn't ALSO coded in ways that impede subclassing (as for all I know it
might be -- I don't have GTK around to check), in which case instead of
subclassing it you need a trickier wrap-and-hold approach (and you can
never pass isinstance checks, which subclassing would let you pass).


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

Re: PEP 3131: Supporting Non-ASCII Identifiers

[Stefan Behnel]

Anton Vredegoor wrote:
>> In summary, this PEP proposes to allow non-ASCII letters as
>> identifiers in Python. If the PEP is accepted, the following
>> identifiers would also become valid as class, function, or
>> variable names: Löffelstiel, changé, ошибка, or 売り場
>> (hoping that the latter one means "counter").
> 
> I am against this PEP for the following reasons:
> 
> It will split up the Python user community into different language or
> interest groups without having any benefit as to making the language
> more expressive in an algorithmic way.


We must distinguish between "identifiers named in a non-english language" and
"identifiers written with non-ASCII characters".

While the first is already allowed as long as the transcription uses only
ASCII characters, the second is currently forbidden and is what this PEP is 
about.

So, nothing currently keeps you from giving names to identifiers that are
impossible to understand by, say, Americans (ok, that's easy anyway).

For example, I could write

  def zieheDreiAbVon(wert):
  return zieheAb(wert, 3)

and most people on earth would not have a clue what this is good for. However,
someone who is fluent enough in German could guess from the names what this 
does.

I do not think non-ASCII characters make this 'problem' any worse. So I must
ask people to restrict their comments to the actual problem that this PEP is
trying to solve.

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

Re: Interesting list Validity (True/False)

[Carsten Haese]

On Sun, 2007-05-13 at 09:26 -0700, [EMAIL PROTECTED] wrote:
> > The statement I made is simply the meaning of "if arg==True" by
> > definition, so I don't see how it can be nonsensical.
> 
> Because you didn't allow for exceptions, which are
> prominently pointed out in the Python docs.

I said: "if arg==True" tests whether the object known as arg is equal to
the object known as True. There are no exceptions. "==" means "equal",
period! Your problem is that Python's notion of "equal" is different
from your notion of "equal".

> > The problem is that you consider equality tests in Python to be
> > nonsensical because they don't fit with your opinion of what equality
> > should mean.
> 
> No, it has nothing to do with what it means. 1, [1], (1,)
> and mpz(1) are all different types and all mathmatically
> the same. Yet 1 and mpz(1) compare equal but (1,) and
> [1] do not.

And that just proves my point. You insist on the notion that equality
means "mathematically the same". Python's equality tests sometimes work
out that way, but that's not how equality actually works, nor how it is
actually defined in Python.

Regards,

-- 
Carsten Haese
http://informixdb.sourceforge.net


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

Re: PEP 3131: Supporting Non-ASCII Identifiers

[Jarek Zgoda]

Martin v. Löwis napisał(a):

> So, please provide feedback, e.g. perhaps by answering these
> questions:
> - should non-ASCII identifiers be supported? why?

No, because "programs must be written for people to read, and only
incidentally for machines to execute". Using anything other than "lowest
common denominator" (ASCII) will restrict accessibility of code. This is
not a literature, that requires qualified translators to get the text
from Hindi (or Persian, or Chinese, or Georgian, or...) to Polish.

While I can read the code with Hebrew, Russian or Greek names
transliterated to ASCII, I would not be able to read such code in native.

> For some languages, common transliteration systems exist (in particular,
> for the Latin-based writing systems).  For other languages, users have
> larger difficulties to use Latin to write their native words.

This is one of least disturbing difficulties when it comes to programming.

-- 
Jarek Zgoda
http://jpa.berlios.de/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[Stefan Behnel]

Martin v. Löwis schrieb:
> PEP 1 specifies that PEP authors need to collect feedback from the
> community. As the author of PEP 3131, I'd like to encourage comments
> to the PEP included below, either here (comp.lang.python), or to
> [EMAIL PROTECTED]
> 
> In summary, this PEP proposes to allow non-ASCII letters as
> identifiers in Python. If the PEP is accepted, the following
> identifiers would also become valid as class, function, or
> variable names: Löffelstiel, changé, ошибка, or 売り場
> (hoping that the latter one means "counter").
> 
> I believe this PEP differs from other Py3k PEPs in that it really
> requires feedback from people with different cultural background
> to evaluate it fully - most other PEPs are culture-neutral.
> 
> So, please provide feedback, e.g. perhaps by answering these
> questions:
> - should non-ASCII identifiers be supported? why?
> - would you use them if it was possible to do so? in what cases?


To make it clear: this PEP considers "identifiers written with non-ASCII
characters", not "identifiers named in a non-english language".

While the first is already allowed as long as the transcription uses only
ASCII characters, the second is currently forbidden and is what this PEP is 
about.

Now, I am not a strong supporter (most public code will use English
identifiers anyway) but we should not forget that Python supports encoding
declarations in source files and thus has much cleaner support for non-ASCII
source code than, say, Java. So, introducing non-ASCII identifiers is just a
small step further. Disallowing this does *not* guarantee in any way that
identifiers are understandable for English native speakers. It only guarantees
that identifiers are always *typable* by people who have access to latin
characters on their keyboard. A rather small advantage, I'd say.

The capability of a Unicode-aware language to express non-English identifiers
in a non-ASCII encoding totally makes sense to me.

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

Re: PEP 3131: Supporting Non-ASCII Identifiers

[Stefan Behnel]

Paul Rubin wrote:
> "Martin v. Löwis" <[EMAIL PROTECTED]> writes:
>> - would you use them if it was possible to do so? in what cases?
> 
> I would never insert them into a program.  In existing programs where
> they were used, I would remove them everywhere I could.

Luckily, you will never be able to touch every program in the world.

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

Re: Basic question

[Cesar G. Miguel]

On May 12, 8:13 pm, [EMAIL PROTECTED] (Alex Martelli) wrote:
> Cesar G. Miguel <[EMAIL PROTECTED]> wrote:
>
> > On May 12, 3:40 pm, Dmitry Dzhus <[EMAIL PROTECTED]> wrote:
> > > > Actually I'm trying to convert a string to a list of float numbers:
> > > > str = '53,20,4,2' to L = [53.0, 20.0, 4.0, 2.0]
>
> > > str="53,20,4,2"
> > > map(lambda s: float(s), str.split(','))
>
> > > Last expression returns: [53.0, 20.0, 4.0, 2.0]
> > > --
> > > Happy Hacking.
>
> > > Dmitry "Sphinx" Dzhushttp://sphinx.net.ru
>
> > Nice!
>
> As somebody else alredy pointed out, the lambda is supererogatory (to
> say the least).
>
> > The following also works using split and list comprehension (as
> > suggested in a brazilian python forum):
>
> > ---
> > L = []
> > file = ['5,1378,1,9', '2,1,4,5']
> > str=''
> > for item in file:
> >   L.append([float(n) for n in item.split(',')])
>
> The assignment to str is useless (in fact potentially damaging because
> you're hiding a built-in name).
>
> L = [float(n) for item in file for n in item.split(',')]
>
> is what I'd call Pythonic, personally (yes, the two for clauses need to
> be in this order, that of their nesting).
>
> Alex

Yes, 'str' is unnecessary. I just forgot to remove it from the code.

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

Re: PEP 3131: Supporting Non-ASCII Identifiers

[Stefan Behnel]

Jarek Zgoda schrieb:
> Martin v. Löwis napisał(a):

Uuups, is that a non-ASCII character in there? Why don't you keep them out of
an English speaking newsgroup?


>> So, please provide feedback, e.g. perhaps by answering these
>> questions:
>> - should non-ASCII identifiers be supported? why?
> 
> No, because "programs must be written for people to read, and only
> incidentally for machines to execute". Using anything other than "lowest
> common denominator" (ASCII) will restrict accessibility of code.

No, but it would make it a lot easier for a lot of people to use descriptive
names. Remember: we're all adults here, right?


> While I can read the code with Hebrew, Russian or Greek names
> transliterated to ASCII, I would not be able to read such code in native.

Then maybe it was code that was not meant to be read by you?

In the (not so small) place where I work, we tend to use descriptive names *in
German* for the code we write, mainly for reasons of domain clarity. The
*only* reason why we still use the (simple but ugly) ASCII-transcription
(ü->ue etc.) for identifiers is that we program in Java and Java lacks a
/reliable/ way to support non-ASCII characters in source code. Thanks to PEP
263 and 3120, Python does not suffer from this problem, but it suffers from
the bigger problem of not *allowing* non-ASCII characters in identifiers. And
I believe that's a rather arbitrary decision.

The more I think about it, the more I believe that this restriction should be
lifted. 'Any' non-ASCII identifier should be allowed where developers decide
that it makes sense.

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

Re: Simulating simple electric circuits

[Bjoern Schliessmann]

Arnaud Delobelle wrote:
> I'm interested! I was tempted to have a go at it after your
> initial post, it sounded like a nice little project :)

Please stand by a day. I'm momentarily facing problems with currents
that never end (going in a circle). And my code doesn't look that
beatiful and/or clean to me, as is using this framework. But judge
yourself (soonest tomorrow). I'm already looking forward to
comments and suggestions. :)

Regards,


Björn

-- 
BOFH excuse #198:

Post-it Note Sludge leaked into the monitor.

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

Re: PEP 3131: Supporting Non-ASCII Identifiers

[Josiah Carlson]

Stefan Behnel wrote:
> Anton Vredegoor wrote:
>>> In summary, this PEP proposes to allow non-ASCII letters as
>>> identifiers in Python. If the PEP is accepted, the following
>>> identifiers would also become valid as class, function, or
>>> variable names: Löffelstiel, changé, ошибка, or 売り場
>>> (hoping that the latter one means "counter").
>> I am against this PEP for the following reasons:
>>
>> It will split up the Python user community into different language or
>> interest groups without having any benefit as to making the language
>> more expressive in an algorithmic way.
> 
> We must distinguish between "identifiers named in a non-english language" and
> "identifiers written with non-ASCII characters".
[snip]
> I do not think non-ASCII characters make this 'problem' any worse. So I must
> ask people to restrict their comments to the actual problem that this PEP is
> trying to solve.

Really?  Because when I am reading source code, even if a particular 
variable *name* is a sequence of characters that I cannot identify as a 
word that I know, I can at least spell it out using Latin characters, or 
perhaps even attempt to pronounce it (verbalization of a word, even if 
it is an incorrect verbalization, I find helps me to remember a variable 
and use it later).

On the other hand, the introduction of some 60k+ valid unicode glyphs 
into the set of characters that can be seen as a name in Python would 
make any such attempts by anyone who is not a native speaker (and even 
native speakers in the case of the more obscure Kanji glyphs) an 
exercise in futility.

As it stands, people who use Python (and the vast majority of other 
programming languages) learn the 52 upper/lowercase variants of the 
latin alphabet (and sometimes the 0-9 number characters for some parts 
of the world).  That's it.  62 glyphs at the worst.  But a huge portion 
of these people have already been exposed to these characters through 
school, the internet, etc., and this isn't likely to change (regardless 
of the 'impending' Chinese population dominance on the internet).

Indeed, the lack of the 60k+ glyphs as valid name characters can make 
the teaching of Python to groups of people that haven't been exposed to 
the Latin alphabet more difficult, but those people who are exposed to 
programming are also typically exposed to the internet, on which Latin 
alphabets dominate (never mind that html tags are Latin characters, as 
are just about every daemon configuration file, etc.).  Exposure to the 
Latin alphabet isn't going to go away, and Python is very unlikely to be 
the first exposure programmers have to the Latin alphabet (except for 
OLPC, but this PEP is about a year late to the game to change that). 
And even if Python *is* the first time children or adults are exposed to 
the Latin alphabet, one would hope that 62 characters to learn to 'speak 
the language of Python' is a small price to pay to use it.

Regarding different characters sharing the same glyphs, it is a problem. 
  Say that you are importing a module written by a mathematician that 
uses an actual capital Greek alpha for a name.  When a user sits down to 
use it, they could certainly get NameErrors, AttributeErrors, etc., and 
never understand why it is the case.  Their fancy-schmancy unicode 
enabled terminal will show them what looks like the Latin A, but it will 
in fact be the Greek Α.  Until they copy/paste, check its ord(), etc., 
they will be baffled.  It isn't a problem now because A = Α is a syntax 
error, but it can and will become a problem if it is allowed to.

But this issue isn't limited to different characters sharing glyphs! 
It's also about being able to type names to use them in your own code 
(generally very difficult if not impossible for many non-Latin 
characters), or even be able to display them.  And no number of 
guidelines, suggestions, etc., against distributing libraries with 
non-Latin identifiers will stop it from happening, and *will* fragment 
the community as Anton (and others) have stated.

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

Re: PEP 3131: Supporting Non-ASCII Identifiers

[Michael Torrie]

On Sun, 2007-05-13 at 21:01 +0200, Stefan Behnel wrote:

> For example, I could write
> 
>   def zieheDreiAbVon(wert):
>   return zieheAb(wert, 3)
> 
> and most people on earth would not have a clue what this is good for. However,
> someone who is fluent enough in German could guess from the names what this 
> does.
> 
> I do not think non-ASCII characters make this 'problem' any worse. So I must
> ask people to restrict their comments to the actual problem that this PEP is
> trying to solve.

I think non-ASCII characters makes the problem far far worse.  While I
may not understand what the function is by it's name in your example,
allowing non-ASCII characters makes it works by forcing all would-be
code readers have to have all kinds of necessary fonts just to view the
source code.  Things like reporting exceptions too.  At least in your
example I know the exception occurred in zieheDreiAbVon.  But if that
identifier is some UTF-8 string, how do I go about finding it in my text
editor, or even reporting the message to the developers?  I don't happen
to have that particular keymap installed in my linux system, so I can't
even type the letters!

So given that people can already transliterate their language for use as
identifiers, I think avoiding non-ASCII character sets is a good idea.
ASCII is simply the lowest denominator and is support by *all*
configurations and locales on all developers' systems.

> 
> Stefan

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

Re: PEP 3131: Supporting Non-ASCII Identifiers

[Jarek Zgoda]

Stefan Behnel napisał(a):

>> While I can read the code with Hebrew, Russian or Greek names
>> transliterated to ASCII, I would not be able to read such code in native.
> 
> Then maybe it was code that was not meant to be read by you?

OK, then. As a code obfuscation measure this would fit perfectly.

-- 
Jarek Zgoda
http://jpa.berlios.de/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[Stefan Behnel]

Josiah Carlson wrote:
> It's also about being able to type names to use them in your own code
> (generally very difficult if not impossible for many non-Latin
> characters), or even be able to display them.  And no number of
> guidelines, suggestions, etc., against distributing libraries with
> non-Latin identifiers will stop it from happening, and *will* fragment
> the community as Anton (and others) have stated.

Ever noticed how the community is already fragmented into people working on
project A and people not working on project A? Why shouldn't the people
working on project A agree what language they write and spell their
identifiers in? And don't forget about project B, C, and all the others.

I agree that code posted to comp.lang.python should use english identifiers
and that it is worth considering to use english identifiers in open source
code that is posted to a public OS project site. Note that I didn't say "ASCII
identifiers" but plain english identifiers. All other code should use the
language and encoding that fits its environment best.

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

Re: PEP 3131: Supporting Non-ASCII Identifiers

[Terry Reedy]

"Stefan Behnel" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
| For example, I could write
|
|  def zieheDreiAbVon(wert):
|  return zieheAb(wert, 3)
|
| and most people on earth would not have a clue what this is good for. 
However,
| someone who is fluent enough in German could guess from the names what 
this does.
|
| I do not think non-ASCII characters make this 'problem' any worse.

It is ridiculous claims like this and the consequent refusal to admit, 
address, and ameliorate the 50x worse problems that would be introduced 
that lead me to oppose the PEP in its current form.

Terry Jan Reedy





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

PyRun_String and related functions causing garbage when calling a parsed function from C.

[joeedh]

Hi I'm getting extremely odd behavior.  First of all, why isn't
PyEval_EvalCode documented  anywhere?  Anyway, I'm working on
blender's
python integration (it embeds python, as opposed to python embedding
it).  I have a function that executes a string buffer of python code,
fetches a function from its global dictionary then calls it.

When the function code returns a local variable, PyObject_Call()
appears
to be returning garbage.  Strangely this is only happening with
internal
blender types, yet try however I might I can't find any refcounting
errors to account for this.  The initial implementation used the same
dictionary for the global and local dicts.  I tried using separate
dicts, but then the function wasn't being called at all (or at least I
tested it by putting a "print "bleh"" in there, and it didn't work).
Also, when I printed the refcount of the garbage data, it was garbage
as
well (so the entire piece of memory is bad, not just the data
portion).

I've tested with both python 2.4 and 2.5.   Mostly with 2.4.  This bug
may be cropping up in other experimental blender python code  as well.

Here's the code in the string buffer:
#BPYCONSTRAINT
from Blender import *
from Blender.Mathutils import *
print "d"
def doConstraint(inmat, tarmat, prop):
a = Matrix()
a.identity()
a = a * TranslationMatrix(Vector(0, 0, 0))
print "t"
a = tarmat
return inmat

print doConstraint(Matrix(), Matrix(), 0)

Here's the code that executes the string buffer:

PyObject *RunPython2( Text * text, PyObject * globaldict, PyObject
*localdict )
{
char *buf = NULL;

/* The script text is compiled to Python bytecode and saved at
text->compiled
* to speed-up execution if the user executes the script multiple times
*/

if( !text->compiled ) {// if it wasn't already compiled, do it
now
buf = txt_to_buf( text );

text->compiled =
Py_CompileString( buf, GetName( text ),
  Py_file_input );

MEM_freeN( buf );

if( PyErr_Occurred(  ) ) {
BPY_free_compiled_text( text );
return NULL;
}

}
return PyEval_EvalCode( text->compiled, globaldict, localdict );
}


. . .and heres the (rather long, and somewhat in a debugging state)
function that calls the function in the script's global dictionary:

void BPY_pyconstraint_eval(bPythonConstraint *con, float obmat[][4],
short ownertype, void *ownerdata, float targetmat[][4])
{
PyObject *srcmat, *tarmat, *idprop;
PyObject *globals, *locals;
PyObject *gkey, *gval;
PyObject *retval;
MatrixObject *retmat;
Py_ssize_t ppos = 0;
int row, col;

if ( !con->text ) return;

globals = CreateGlobalDictionary();

srcmat = newMatrixObject( (float*)obmat, 4, 4, Py_NEW );
tarmat = newMatrixObject( (float*)targetmat, 4, 4, Py_NEW );
idprop = BPy_Wrap_IDProperty( NULL, &con->prop, NULL);

/*  since I can't remember what the armature weakrefs do, I'll just
leave this here
commented out.  Since this function was based on pydrivers.
if( !setup_armature_weakrefs()){
fprintf( stderr, "Oops - weakref dict setup\n");
return result;
}
*/
retval = RunPython2( con->text, globals, globals);

if (retval) {Py_XDECREF( retval );}

if ( retval == NULL ) {
BPY_Err_Handle(con->text->id.name);
ReleaseGlobalDictionary( globals );

/*free temp objects*/
Py_XDECREF( idprop );
Py_XDECREF( srcmat );
Py_XDECREF( tarmat );
return;
}

/*Now for the fun part! Try and find the functions we need.*/
while ( PyDict_Next(globals, &ppos, &gkey, &gval) ) {
if ( PyString_Check(gkey) && strcmp(PyString_AsString(gkey),
"doConstraint")==0 ) {
if (PyFunction_Check(gval) ) {
retval = PyObject_CallObject(gval,
Py_BuildValue("OOO",
srcmat, tarmat, idprop));
Py_XDECREF( retval );
} else {
printf("ERROR: doConstraint is supposed to be a
function!\n");
}
break;
}
}

if (!retval) {
BPY_Err_Handle(con->text->id.name);
/*free temp objects*/
ReleaseGlobalDictionary( globals );

Py_XDECREF( idprop );
Py_XDECREF( srcmat );
Py_XDECREF( tarmat );
return;
}

if (!PyObject_TypeCheck(retval, &matrix_Type)) {
printf("Error in pyconstraint: Wrong return type for a
pyconstraint!\n");
ReleaseGlobalDictionary( globals );

Py_XDECREF( idprop );
Py_XDECREF( srcmat );
Py_XDECREF( tarmat );
Py_XDECREF( retval );
return;
}

retmat = (MatrixObject*) retval;
if (retmat->rowSize != 4 || retmat->colSize != 4) {
printf("Error in pyconstraint: Matrix is the wrong size!\n");
ReleaseGlobalDictionary( globals );

Py_XDECREF( idprop );
Py_XDECREF( srcmat );
Py_XDECREF( tarmat );
Py_XDECREF( retval );

Re: __dict__ for instances?

[Bruno Desthuilliers]

Ivan Voras a écrit :
> Marc Christiansen wrote:
> 
> 
>>Nope, at least for PyGTK 2 :) See below.
> 
> 
> Aaah, but!
> 
> 
>>[...]
>>
>>>This looks like it should be easy, but I can't find the solution :(
>>
>>Use the doc, Luke, oops, Ivan :)
>>Citing the gtk.glade.XML.signal_autoconnect documentation: 
>>  def signal_autoconnect(dict)
>>  dict: a mapping or an instance
>>
> 
> 
> I should have mentioned - I tried it already and it didn't work. The
> specific error I get is:
> 
> "WARNING: "on_button_clicked" not callable or a tuple"

Please post the relevant code and the full traceback.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[Bruno Desthuilliers]

Martin v. Löwis a écrit :
> PEP 1 specifies that PEP authors need to collect feedback from the
> community. As the author of PEP 3131, I'd like to encourage comments
> to the PEP included below, either here (comp.lang.python), or to
> [EMAIL PROTECTED]
> 
> In summary, this PEP proposes to allow non-ASCII letters as
> identifiers in Python. If the PEP is accepted, the following
> identifiers would also become valid as class, function, or
> variable names: Löffelstiel, changé, ошибка, or 売り場
> (hoping that the latter one means "counter").
> 
> I believe this PEP differs from other Py3k PEPs in that it really
> requires feedback from people with different cultural background
> to evaluate it fully - most other PEPs are culture-neutral.
> 
> So, please provide feedback, e.g. perhaps by answering these
> questions:
> - should non-ASCII identifiers be supported? 

No.

> why?

Because it will definitivly make code-sharing impossible. Live with it 
or else, but CS is english-speaking, period. I just can't understand 
code with spanish or german (two languages I have notions of) 
identifiers, so let's not talk about other alphabets...

NB : I'm *not* a native english speaker, I do *not* live in an english 
speaking country, and my mother's language requires non-ascii encoding. 
And I don't have special sympathy for the USA. And yes, I do write my 
code - including comments - in english.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[Bruno Desthuilliers]

Stefan Behnel a écrit :
> Anton Vredegoor wrote:
> 
>>>In summary, this PEP proposes to allow non-ASCII letters as
>>>identifiers in Python. If the PEP is accepted, the following
>>>identifiers would also become valid as class, function, or
>>>variable names: Löffelstiel, changé, ошибка, or 売り場
>>>(hoping that the latter one means "counter").
>>
>>I am against this PEP for the following reasons:
>>
>>It will split up the Python user community into different language or
>>interest groups without having any benefit as to making the language
>>more expressive in an algorithmic way.
> 
> 
> 
> We must distinguish between "identifiers named in a non-english language" and
> "identifiers written with non-ASCII characters".
> 
> While the first is already allowed as long as the transcription uses only
> ASCII characters, the second is currently forbidden and is what this PEP is 
> about.
> 
> So, nothing currently keeps you from giving names to identifiers that are
> impossible to understand by, say, Americans (ok, that's easy anyway).
> 
> For example, I could write
> 
>   def zieheDreiAbVon(wert):
>   return zieheAb(wert, 3)
 >
> and most people on earth would not have a clue what this is good for.

Which is exactly why I don't agree with adding support with non-ascii 
identifiers. Using non-english identifiers should be strongly 
discouraged, not openly supported.

> However,
> someone who is fluent enough in German could guess from the names what this 
> does.
> 
> I do not think non-ASCII characters make this 'problem' any worse.

It does, by openly stating that it's ok to write unreadable code and 
offering support for it.

> So I must
> ask people to restrict their comments to the actual problem that this PEP is
> trying to solve.

Sorry, but we can't dismiss the side-effects. Learning enough 
CS-oriented technical english to actually read and write code and 
documentation is not such a big deal - even I managed to to so, and I'm 
a bit impaired when it comes to foreign languages.

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

Re: PEP 3131: Supporting Non-ASCII Identifiers

[MRAB]

On May 13, 8:49 pm, Michael Torrie <[EMAIL PROTECTED]> wrote:
> On Sun, 2007-05-13 at 21:01 +0200, Stefan Behnel wrote:
> > For example, I could write
>
> >   def zieheDreiAbVon(wert):
> >   return zieheAb(wert, 3)
>
> > and most people on earth would not have a clue what this is good for. 
> > However,
> > someone who is fluent enough in German could guess from the names what this 
> > does.
>
> > I do not think non-ASCII characters make this 'problem' any worse. So I must
> > ask people to restrict their comments to the actual problem that this PEP is
> > trying to solve.
>
> I think non-ASCII characters makes the problem far far worse.  While I
> may not understand what the function is by it's name in your example,
> allowing non-ASCII characters makes it works by forcing all would-be
> code readers have to have all kinds of necessary fonts just to view the
> source code.  Things like reporting exceptions too.  At least in your
> example I know the exception occurred in zieheDreiAbVon.  But if that
> identifier is some UTF-8 string, how do I go about finding it in my text
> editor, or even reporting the message to the developers?  I don't happen
> to have that particular keymap installed in my linux system, so I can't
> even type the letters!
>
> So given that people can already transliterate their language for use as
> identifiers, I think avoiding non-ASCII character sets is a good idea.
> ASCII is simply the lowest denominator and is support by *all*
> configurations and locales on all developers' systems.
>
Perhaps there could be the option of typing and showing characters as
\u, eg. \u00FC instead of ü (u-umlaut), or showing them in a
different colour if they're not in a specified set.

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

Re: file uploader

[Sick Monkey]

I never heard a response back concerning my previous question, so I decided
to write my own function.  If anyone has a simpler way of checking to see if
a file already exists (prior to uploading to a server) and renaming it,
please let me know.

Here is the code that I am using (it runs exactly the same as the linux app
'arcgen').

<%
import os,string
filename = "whoa.mp3"
dir_path = "/u01/"
i = 0
while os.path.exists(dir_path+filename):
 #filename=string.replace(filename, ".-0",".-1")
 if i == 0:
filename = "%s.-%s" % (filename,i)
 else:
t = i-1
filename=string.replace(filename,".-%s" % (t),".-%s" % (i))
 i += 1
req.write(filename)
%>

The directory contains the following files: "whoa.mp3" and "whoa.mp3.-0".
This code will output "whoa.mp3.-1".

On 5/9/07, Sick Monkey <[EMAIL PROTECTED]> wrote:


Hey guys.  I wanted to write a little desktop application that would
upload files to an external server, to a specific directory.

The desktop application is running on Mac OS X and I built a .psp script
that is running on a Red Hat server.
NOTE:  This application is written for Python 2.5 (both py and psp)

My code is giving me problems, in that it is overwriting files.  I was
wondering if anyone knew of a module or a method that would overcome this
dilemma.   I can adapt my program to search to see if the file existed
already in the directory and append a random string sequence to keep this
from occurring, but I do not want to reinvent the wheel (if such a thing
exists) and that would clutter up my program.  :)

Here is what I am currently using:

 fname = os.path.basename(uploadFile.filename)
 dir_path = "/u01"
 open(os.path.join(dir_path, fname), 'wb').write(uploadFile.file.read())

As always, any help is greatly appreciated.

.dave

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

Re: PEP 3131: Supporting Non-ASCII Identifiers

[Bruno Desthuilliers]

Stefan Behnel a écrit :
> Martin v. Löwis schrieb:
> 
>>PEP 1 specifies that PEP authors need to collect feedback from the
>>community. As the author of PEP 3131, I'd like to encourage comments
>>to the PEP included below, either here (comp.lang.python), or to
>>[EMAIL PROTECTED]
>>
>>In summary, this PEP proposes to allow non-ASCII letters as
>>identifiers in Python. If the PEP is accepted, the following
>>identifiers would also become valid as class, function, or
>>variable names: Löffelstiel, changé, ошибка, or 売り場
>>(hoping that the latter one means "counter").
>>
>>I believe this PEP differs from other Py3k PEPs in that it really
>>requires feedback from people with different cultural background
>>to evaluate it fully - most other PEPs are culture-neutral.
>>
>>So, please provide feedback, e.g. perhaps by answering these
>>questions:
>>- should non-ASCII identifiers be supported? why?
>>- would you use them if it was possible to do so? in what cases?
> 
> 
> 
> To make it clear: this PEP considers "identifiers written with non-ASCII
> characters", not "identifiers named in a non-english language".

You cannot just claim that these are two totally distinct issues and get 
away with it. The fact is that not only non-english identifiers are a 
bad thing when it comes to sharing and cooperation, and it's obvious 
that non-ascii glyphs can only make things work - since it's obvious 
that people willing to use such a "feature" *wont* do it to spell 
english identifiers anyway.

> While the first is already allowed as long as the transcription uses only
> ASCII characters, the second is currently forbidden and is what this PEP is 
> about.
> 
> Now, I am not a strong supporter (most public code will use English
> identifiers anyway) but we should not forget that Python supports encoding
> declarations in source files and thus has much cleaner support for non-ASCII
> source code than, say, Java. So, introducing non-ASCII identifiers is just a
> small step further.

I would certainly not qualify this as a "small" step.

> Disallowing this does *not* guarantee in any way that
> identifiers are understandable for English native speakers.

I'm not an English native speaker. And there's more than a subtle 
distinction between "not garantying" and "encouraging".

> It only guarantees
> that identifiers are always *typable* by people who have access to latin
> characters on their keyboard. A rather small advantage, I'd say.
> 
> The capability of a Unicode-aware language to express non-English identifiers
> in a non-ASCII encoding totally makes sense to me.

It does of course make sens (at least if you add support for non-english 
non-ascii translation of the *whole* language - keywords, builtins and 
the whole standard lib included). But it's still a very bad idea IMHO.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Towards faster Python implementations - theory

[Robert Brown]

sturlamolden <[EMAIL PROTECTED]> writes:

> On May 10, 7:18 pm, "Terry Reedy" <[EMAIL PROTECTED]> wrote:
>
> CMUCL and SBCL depends on the dominance of the x86 architecture.

CMUCL and SBCL run on a variety of architectures, including x86, 64-bit x86,
PowerPC, Sparc, Alpha, and Mips.  See

http://www.sbcl.org/platform-table.html

for platform support information.

> Or one could translate between Python and Lisp on the fly, and use a
> compiled Lisp (CMUCL, SBCL, Franz, GCL) as runtime backend.

This has been done by Willem Broekema.  PLPython is a Python implementation
that translates Python source into Common Lisp at read time.  Under the
covers, the Lisp is compiled into machine code and then run.  See

http://trac.common-lisp.net/clpython/

Currently, CLPython uses some non-standard Allegro Common Lisp features, so
it does not run on all the free implementations of ANSI Common Lisp.  The
implementation is interesting, in part because it shows how expensive and
complex some Python primitives are.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[Virgil Dupras]

On May 13, 11:44 am, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> PEP 1 specifies that PEP authors need to collect feedback from the
> community. As the author of PEP 3131, I'd like to encourage comments
> to the PEP included below, either here (comp.lang.python), or to
> [EMAIL PROTECTED]
>
> In summary, this PEP proposes to allow non-ASCII letters as
> identifiers in Python. If the PEP is accepted, the following
> identifiers would also become valid as class, function, or
> variable names: Löffelstiel, changé, ошибка, or 売り場
> (hoping that the latter one means "counter").
>
> I believe this PEP differs from other Py3k PEPs in that it really
> requires feedback from people with different cultural background
> to evaluate it fully - most other PEPs are culture-neutral.
>
> So, please provide feedback, e.g. perhaps by answering these
> questions:
> - should non-ASCII identifiers be supported? why?
> - would you use them if it was possible to do so? in what cases?
>
> Regards,
> Martin
>
> PEP: 3131
> Title: Supporting Non-ASCII Identifiers
> Version: $Revision: 55059 $
> Last-Modified: $Date: 2007-05-01 22:34:25 +0200 (Di, 01 Mai 2007) $
> Author: Martin v. Löwis <[EMAIL PROTECTED]>
> Status: Draft
> Type: Standards Track
> Content-Type: text/x-rst
> Created: 1-May-2007
> Python-Version: 3.0
> Post-History:
>
> Abstract
> 
>
> This PEP suggests to support non-ASCII letters (such as accented
> characters, Cyrillic, Greek, Kanji, etc.) in Python identifiers.
>
> Rationale
> =
>
> Python code is written by many people in the world who are not familiar
> with the English language, or even well-acquainted with the Latin
> writing system.  Such developers often desire to define classes and
> functions with names in their native languages, rather than having to
> come up with an (often incorrect) English translation of the concept
> they want to name.
>
> For some languages, common transliteration systems exist (in particular,
> for the Latin-based writing systems).  For other languages, users have
> larger difficulties to use Latin to write their native words.
>
> Common Objections
> =
>
> Some objections are often raised against proposals similar to this one.
>
> People claim that they will not be able to use a library if to do so
> they have to use characters they cannot type on their keyboards.
> However, it is the choice of the designer of the library to decide on
> various constraints for using the library: people may not be able to use
> the library because they cannot get physical access to the source code
> (because it is not published), or because licensing prohibits usage, or
> because the documentation is in a language they cannot understand.  A
> developer wishing to make a library widely available needs to make a
> number of explicit choices (such as publication, licensing, language
> of documentation, and language of identifiers).  It should always be the
> choice of the author to make these decisions - not the choice of the
> language designers.
>
> In particular, projects wishing to have wide usage probably might want
> to establish a policy that all identifiers, comments, and documentation
> is written in English (see the GNU coding style guide for an example of
> such a policy). Restricting the language to ASCII-only identifiers does
> not enforce comments and documentation to be English, or the identifiers
> actually to be English words, so an additional policy is necessary,
> anyway.
>
> Specification of Language Changes
> =
>
> The syntax of identifiers in Python will be based on the Unicode
> standard annex UAX-31 [1]_, with elaboration and changes as defined
> below.
>
> Within the ASCII range (U+0001..U+007F), the valid characters for
> identifiers are the same as in Python 2.5.  This specification only
> introduces additional characters from outside the ASCII range.  For
> other characters, the classification uses the version of the Unicode
> Character Database as included in the ``unicodedata`` module.
>
> The identifier syntax is `` *``.
>
> ``ID_Start`` is defined as all characters having one of the general
> categories uppercase letters (Lu), lowercase letters (Ll), titlecase
> letters (Lt), modifier letters (Lm), other letters (Lo), letter numbers
> (Nl), plus the underscore (XXX what are "stability extensions" listed in
> UAX 31).
>
> ``ID_Continue`` is defined as all characters in ``ID_Start``, plus
> nonspacing marks (Mn), spacing combining marks (Mc), decimal number
> (Nd), and connector punctuations (Pc).
>
> All identifiers are converted into the normal form NFC while parsing;
> comparison of identifiers is based on NFC.
>
> Policy Specification
> 
>
> As an addition to the Python Coding style, the following policy is
> prescribed: All identifiers in the Python standard library MUST use
> ASCII-only identifiers, and SHOULD use English words wherever feasible.
>
> As an option, this specificati

Re: PEP 3131: Supporting Non-ASCII Identifiers

[Alexander Schmolck]

Jarek Zgoda <[EMAIL PROTECTED]> writes:

> Martin v. Löwis napisał(a):
>
>> So, please provide feedback, e.g. perhaps by answering these
>> questions:
>> - should non-ASCII identifiers be supported? why?
>
> No, because "programs must be written for people to read, and only
> incidentally for machines to execute". Using anything other than "lowest
> common denominator" (ASCII) will restrict accessibility of code. This is
> not a literature, that requires qualified translators to get the text
> from Hindi (or Persian, or Chinese, or Georgian, or...) to Polish.
>
> While I can read the code with Hebrew, Russian or Greek names
> transliterated to ASCII, I would not be able to read such code in native.

Who or what would force you to? Do you currently have to deal with hebrew,
russian or greek names transliterated into ASCII? I don't and I suspect this
whole panic about everyone suddenly having to deal with code written in kanji,
klingon and hieroglyphs etc. is unfounded -- such code would drastically
reduce its own "fitness" (much more so than the ASCII-transliterated chinese,
hebrew and greek code I never seem to come across), so I think the chances
that it will be thrust upon you (or anyone else in this thread) are minuscule.


Plenty of programming languages already support unicode identifiers, so if
there is any rational basis for this fear it shouldn't be hard to come up with
-- where is it?

'as

BTW, I'm not sure if you don't underestimate your own intellectual faculties
if you think couldn't cope with greek or russian characters. On the other hand
I wonder if you don't overestimate your ability to reasonably deal with code
written in a completely foreign language, as long as its ASCII -- for anything
of nontrivial length, surely doing anything with such code would already be
orders of magnitude harder?

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

Re: PEP 3131: Supporting Non-ASCII Identifiers

[Anders J. Munch]

Josiah Carlson wrote:
> On the other hand, the introduction of some 60k+ valid unicode glyphs 
> into the set of characters that can be seen as a name in Python would 
> make any such attempts by anyone who is not a native speaker (and even 
> native speakers in the case of the more obscure Kanji glyphs) an 
> exercise in futility.
> 

So you gather up a list of identifiers and and send out for translation.  
Having 
actual Kanji glyphs instead a mix of transliterations and bad English will only 
make that easier.

That won't even cost you anything, since you were already having docstrings 
translated, along with comments and documentation, right?

> But this issue isn't limited to different characters sharing glyphs! 
> It's also about being able to type names to use them in your own code 
> (generally very difficult if not impossible for many non-Latin 
> characters), or even be able to display them.

For display, tell your editor the utf-8 source file is really latin-1.  For 
entry, copy-paste.

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

Re: PEP 3131: Supporting Non-ASCII Identifiers

[Alex Martelli]

Bruno Desthuilliers <[EMAIL PROTECTED]> wrote:

> > Disallowing this does *not* guarantee in any way that
> > identifiers are understandable for English native speakers.
> 
> I'm not an English native speaker. And there's more than a subtle 
> distinction between "not garantying" and "encouraging".

I agree with Bruno and the many others who have expressed disapproval
for this idea -- and I am not an English native speaker, either (and
neither, it seems to me, are many others who dislike this PEP).  The
mild pleasure of using accented letters in code "addressed strictly to
Italian-speaking audiences and never intended to be of any use to
anybody not speaking Italian" (should I ever desire to write such code)
pales in comparison with the disadvantages, many of which have already
been analyzed or at least mentioned.

Homoglyphic characters _introduced by accident_ should not be discounted
as a risk, as, it seems to me, was done early in this thread after the
issue had been mentioned.  In the past, it has happened to me to
erroneously introduce such homoglyphs in a document I was preparing with
a word processor, by a slight error in the use of the system- provided
way for inserting characters not present on the keyboard; I found out
when later I went looking for the name I _thought_ I had input (but I
was looking for it spelled with the "right" glyph, not the one I had
actually used which looked just the same) and just could not find it.

On that occasion, suspecting I had mistyped in some way or other, I
patiently tried looking for "pieces" of the word in question, eventually
locating it with just a mild amount of aggravation when I finally tried
a piece without the offending character.  But when something similar
happens to somebody using a sufficiently fancy text editor to input
source in a programming language allowing arbitrary Unicode letters in
identifiers, the damage (the sheer waste of developer time) can be much
more substantial -- there will be two separate identifiers around, both
looking exactly like each other but actually distinct, and unbounded
amount of programmer time can be spent chasing after this extremely
elusive and tricky bug -- why doesn't a rebinding appear to "take", etc.
With some copy-and-paste during development and attempts at debugging,
several copies of each distinct version of the identifier can be spread
around the code, further hampering attempts at understanding.


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

Re: PEP 3131: Supporting Non-ASCII Identifiers

[Alan Franzoni]

Il Sun, 13 May 2007 17:44:39 +0200, "Martin v. Löwis" ha scritto:

[cut]

I'm from Italy, and I can say that some thoughts by Martin v. Löwis are
quite right. It's pretty easy to see code that uses "English" identifiers
and comments, but they're not really english - many times, they're just
"englishized" versions of the italian word. They might lure a real english
reader into an error rather than help him understand what the name really
stands for. It would be better to let the programmer pick the language he
or she prefers, without restrictions.

The patch problem doesn't seem a real issue to me, because it's the project
admin the one who can pick the encoding, and he could easily refuse any
patch that doesn't conform to the standards he wants.

BTW, there're a couple of issues that should be solved; even though I could
do with iso-8859-1, I usually pick utf-8 as the preferred encoding for my
files, because I found it more portable and more compatible with different
editors and IDE (I don't know if I just found some bugs in some specific
software, but I had problems with accented characters when switching
environment from Win to Linux, especially when reading/writing to and from
non-native FS, e.g. reading files from a ntfs disk from linux, or reading
an ext2 volume from Windows) on various platforms.

By the way, I would highly dislike anybody submitting a patch that contains
identifiers other than ASCII or iso-8859-1. Hence, I think there should be
a way, a kind of directive or sth. like that, to constrain the identifiers
charset to a 'subset' of the 'global' one.

Also, there should be a way to convert source files in any 'exotic'
encoding to a pseudo-intellegibile encoding for any reader, a kind of
translittering (is that a proper english word) system out-of-the-box, not
requiring any other tool that's not included in the Python distro. This
will let people to retain their usual working environments even though
they're dealing with source code with identifiers in a really different
charset.

-- 
Alan Franzoni <[EMAIL PROTECTED]>
-
Togli .xyz dalla mia email per contattarmi.
Remove .xyz from my address in order to contact me.
-
GPG Key Fingerprint (Key ID = FE068F3E):
5C77 9DC3 BD5B 3A28 E7BC 921A 0255 42AA FE06 8F3E 
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: GUI tutorial

[Ivan Voras]

John K Masters wrote:
> Can someone point me in the direction of a good tutorial on programming
> python with a GUI? I'm just starting out with python and have written a
> few scripts successfully but would like to add a graphical front end to
> them to make it easier for my work colleagues, most of whom have never
> used a command line, to use.

If you're using Linux or some other unix-like platform, try PyGTK:
http://www.pygtk.org/pygtk2tutorial/index.html


(Yes, it can run on Windows, but it tends to be more complicated there).

-- 
(\__/)
(O.o)
(> < )

This is Bunny.
Copy Bunny into your signature to help him on his way to world domination!



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

Re: PEP 3131: Supporting Non-ASCII Identifiers

[Alexander Schmolck]

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

> PEP 1 specifies that PEP authors need to collect feedback from the
> community. As the author of PEP 3131, I'd like to encourage comments
> to the PEP included below, either here (comp.lang.python), or to
> [EMAIL PROTECTED]
>
> In summary, this PEP proposes to allow non-ASCII letters as
> identifiers in Python. If the PEP is accepted, the following
> identifiers would also become valid as class, function, or
> variable names: Löffelstiel, changé, ошибка, or 売り場
> (hoping that the latter one means "counter").
>
> I believe this PEP differs from other Py3k PEPs in that it really
> requires feedback from people with different cultural background
> to evaluate it fully - most other PEPs are culture-neutral.
>
> So, please provide feedback, e.g. perhaps by answering these
> questions:
> - should non-ASCII identifiers be supported? 

Yes.

> why?

Because not everyone speaks English, not all languages can losslessly
transliterated ASCII and because it's unreasonable to drastically restrict the
domain of things that can be conveniently expressed for a language that's also
targeted at a non-professional programmer audience.

I'm also not aware of any horror stories from languages which do already allow
unicode identifiers.

> - would you use them if it was possible to do so? 

Possibly.

> in what cases?

Maybe mathematical code (greek letters) or code that is very culture and
domain specific (say code doing Japanese tax forms).

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

Re: __dict__ for instances?

[Ivan Voras]

Bruno Desthuilliers wrote:

>> "WARNING: "on_button_clicked" not callable or a tuple"
> 
> Please post the relevant code and the full traceback.

The code:

Class W:
 def __init__(self):
 self.xml = gtk.glade.XML("glade/mainwin.glade")
 self.window = self.xml.get_widget("mainwin")
 self.xml.signal_autoconnect(self)

w = W()
gtk.main()

The error (not an exception, only the message appears and the handler
doesn't work):

** (finstall.py:7551): WARNING **: handler for 'on_button_next_clicked'
not callable or a tuple

(the file has some 20 lines, not 7551)


-- 
(\__/)
(O.o)
(> < )

This is Bunny.
Copy Bunny into your signature to help him on his way to world domination!



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

Re: PEP 3131: Supporting Non-ASCII Identifiers

[Anders J. Munch]

Michael Torrie wrote:
> 
> So given that people can already transliterate their language for use as
> identifiers, I think avoiding non-ASCII character sets is a good idea.

Transliteration makes people choose bad variable names, I see it all the time 
with Danish programmers.  Say e.g. the most descriptive name for a process is 
"kør forlæns" (run forward).  But "koer_forlaens" is ugly, so instead he'll 
write "run_fremad", combining an English word with a slightly less appropriate 
Danish word.  Sprinkle in some English spelling errors and badly-chosen English 
words, and you have the sorry state of the art that is today.

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

How to do basic CRUD apps with Python

[walterbyrd]

With PHP, libraries, apps, etc. to do basic CRUD are everywhere. Ajax
and non-Ajax solutions abound.

With Python, finding such library, or apps. seems to be much more
difficult to find.

I thought django might be a good way, but I can not seem to get an
answer on that board.

I would like to put together a CRUD grid with editable/deletable/
addable fields, click on the headers to sort. Something that would
sort-of looks like an online  spreadsheet. It would be nice if the
fields could be edited in-line, but it's not entirely necessary.

Are there any Python libraries to do that sort of thing? Can it be
done with django or cherrypy?

Please, don't advertise your PHP/Ajax apps.

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

Re: Using "subprocess" without lists. . .?

[Michael Williams]

I'm not sure you replied entirely to the correct post.  Basically I'm  
interested in encoding video with FFMPEG, but there will be variable  
length commands so I'd rather be able to type a single string for the  
"command" as opposed to having to enter it in the form of a list.   
And there is really no way to properly parse because some options  
have values and others are simply flags.


Thanks,
Michael

On May 13, 2007, at 2:17 PM, Steven Howe wrote:


Michael Williams wrote:

Hi All,

I've recently seen the "subprocess" module and am rather confused by
it's requirements.  Is it not possible to execute an entire string
without having to break them up into a list of arguments?  For
instance, I'd much rather do the following:


subprocess.call("ls -al | grep -i test")


. . .than to have to:


list = ["ls", "-a", "-l" ]  . . . . . . and so on and so forth.
subprocess.call(list. . .)


What is the best way to go about executing a massively complex single
line command?


Thanks,
Michael


How about a hybrid solution?:
from subprocess import Popen, PIPE
from string import strip
(stdout, stderr) = Popen(['ls','-al'], stdout=PIPE,  
stderr=PIPE).communicate()
# process spins off. Ideally, you should wait for it to complete,  
or assign the resulting object of Popen
# to a variable and inquire if it's completed via the 'poll()'  
operator or wait on it via the 'wait()'

# operator.
# then query the stderr via communicate()[1]; if good, i.e. len 
(stderr) == 0, inspect the resulting
# stdout string (via communicate()[0]) for your 'test' result. But  
I'm being lazy. I assume the call to

# ls -al will be faster then my next statement.
res = []
for line in stdout.strip():
if 'test' in line:
   res.append( line )

Do the work you need done at the shell prompt, do the rest in  
Python. Also I wonder if, you were looking for the word 'test' in  
the filename,  glob.glob wouldn't have been a bit more efficient?  
But if you were looking for a 'test' owner or group then using:
glob.glob(): get the list of  files, with directory. Example:   
glob.glob('/bin/*')
os.stat(): get an object of stats on a file. Example: os.stat('/bin/ 
ls')
stat.ST_UID: get just the group id, as an integer from the object  
returned by os.stat. Example: os.stat('/bin/ls')[stat.ST_UID]

pwd.getpwgid(): get the string translation of a UID. Example:
pwd.getpwgid( os.stat('/bin/ls')[stat.ST_UID] )
stat.ST_GID: get the group id, as an integer from the object  
returned os.stat. Example:

os.stat('/bin/ls')[stat.ST_GID]
grp.getgrgid(): get the string translation of a UID. Example:
grp.getgrgid( os.stat('/bin/ls')[stat.ST_UID] )
Now I have a list, which I iterate over, getting the UID and GID,  
as strings, that I can compare to. I never had to use a subprocess  
and having to build up a 'wait on done loop'.  Note, grp and pwd, I  
think, are Python/Unix functions. What one does on Windows I don't  
know, but I'll bet there are similar functions under Python/ 
Windows. Don't get me wrong, Subprocess is a fast and damn useful  
tool. I often use it to verify a program is in my path, before  
creating a subprocess to run some task python isn't built for (like  
mencoder functionality).


You see, the issue is: shell, python & shell or python alone. When  
transitioning from one language to another, say C/C++/Java to  
Python, it is often easier to use your knowledge of the shell  
command (bash/Bourne for example) to get things done. But it's only  
a transitional issue. The need to use the shell is a good  
demonstrator that either the Interpretor is weak, or that you  
haven't fully explored it's abilities. With the Python Interpretor  
at v2.4 going onto v2.5, it's very likely that the desired feature  
exists; you have but to do some clever research to find it. As to  
clever research ... I find Google a good place to start.


I had some familiarity with os.stat and glob. But the grp and pwd  
functions were things I discovered from http://docs.python.org/ 
modindex.html and about two minutes of searching for 'python uid to  
name' @ Google.


Also, os.listdir and os.path.join would have worked just as well as  
glob.glob('dirname/*'). But glob.glob was faster to write. Even a  
better choice would have been to use the 'os.walk' to iterate over  
the directory tree.


sph.

--
HEX: 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0


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

Re: PEP 3131: Supporting Non-ASCII Identifiers

[Steven D'Aprano]

On Sun, 13 May 2007 15:35:15 -0700, Alex Martelli wrote:

> Homoglyphic characters _introduced by accident_ should not be discounted
> as a risk
...
> But when something similar
> happens to somebody using a sufficiently fancy text editor to input
> source in a programming language allowing arbitrary Unicode letters in
> identifiers, the damage (the sheer waste of developer time) can be much
> more substantial -- there will be two separate identifiers around, both
> looking exactly like each other but actually distinct, and unbounded
> amount of programmer time can be spent chasing after this extremely
> elusive and tricky bug -- why doesn't a rebinding appear to "take", etc.
> With some copy-and-paste during development and attempts at debugging,
> several copies of each distinct version of the identifier can be spread
> around the code, further hampering attempts at understanding.


How is that different from misreading "disk_burnt = True" as "disk_bumt =
True"? In the right (or perhaps wrong) font, like the ever-popular Arial,
the two can be visually indistinguishable. Or "call" versus "cal1"?

Surely the correct solution is something like pylint or pychecker? Or
banning the use of lower-case L and digit 1 in identifiers. I'm good with
both.


-- 
Steven.

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

Re: PEP 3131: Supporting Non-ASCII Identifiers

[Anders J. Munch]

Alex Martelli wrote:
> 
> Homoglyphic characters _introduced by accident_ should not be discounted
> as a risk, as, it seems to me, was done early in this thread after the
> issue had been mentioned.  In the past, it has happened to me to
> erroneously introduce such homoglyphs in a document I was preparing with
> a word processor, by a slight error in the use of the system- provided
> way for inserting characters not present on the keyboard; I found out
> when later I went looking for the name I _thought_ I had input (but I
> was looking for it spelled with the "right" glyph, not the one I had
> actually used which looked just the same) and just could not find it.

There's any number of things to be done about that.
1. # -*- encoding: ascii -*-
(I'd like to see you sneak those homoglyphic characters past *that*.)
2. pychecker and pylint - I'm sure you realise what they could do for you.
3. Use a font that doesn't have those characters or deliberately makes them 
distinct (that could help web browsing safety too).

I'm not discounting the problem, I just dont believe it's a big one.  Can we 
chose a codepoint subset that doesn't have these dupes?

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

Re: PEP 3131: Supporting Non-ASCII Identifiers

[Paul Rubin]

Alexander Schmolck <[EMAIL PROTECTED]> writes:
> Plenty of programming languages already support unicode identifiers, 

Could you name a few?  Thanks.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[Steven D'Aprano]

On Sun, 13 May 2007 10:52:12 -0700, Paul Rubin wrote:

> "Martin v. Löwis" <[EMAIL PROTECTED]> writes:
>> This is a commonly-raised objection, but I don't understand why people
>> see it as a problem. The phishing issue surely won't apply, as you
>> normally don't "click" on identifiers, but rather type them. In a
>> phishing case, it is normally difficult to type the fake character
>> (because the phishing relies on you mistaking the character for another
>> one, so you would type the wrong identifier).
> 
> It certainly does apply, if you're maintaining a program and someone
> submits a patch.  In that case you neither click nor type the
> character.  You'd normally just make sure the patched program passes
> the existing test suite, and examine the patch on the screen to make
> sure it looks reasonable.  The phishing possibilities are obvious.

Not to me, I'm afraid. Can you explain how it works? A phisher might be
able to fool a casual reader, but how does he fool the compiler into
executing the wrong code?

As for project maintainers, surely a patch using some unexpected Unicode
locale would fail the "looks reasonable" test? That could even be
automated -- if the patch uses an unexpected "#-*- coding: blah" line, or
includes characters outside of a pre-defined range, ring alarm bells.
("Why is somebody patching my Turkish module in Korean?")



-- 
Steven

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

Re: file uploader

[Gabriel Genellina]

En Sun, 13 May 2007 18:41:16 -0300, Sick Monkey <[EMAIL PROTECTED]>  
escribió:

> If anyone has a simpler way of checking to see if
> a file already exists (prior to uploading to a server) and renaming it,
> please let me know.

I will ignore the "server" part...

> Here is the code that I am using (it runs exactly the same as the linux  
> app
> 'arcgen').
>  [...]
>  t = i-1
>  filename=string.replace(filename,".-%s" % (t),".-%s" % (i))

If the original filename contained .-1 somewhere, you're modifying it.  
This is safer and shorter:

import os,string
filename = "whoa.mp3"
dir_path = "/u01/"
ofilename = filename
i = 0
while os.path.exists(dir_path+filename):
  filename = "%s.-%s" % (ofilename,i)
  i += 1
req.write(filename)

-- 
Gabriel Genellina

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

Re: PEP 3131: Supporting Non-ASCII Identifiers

[Marc 'BlackJack' Rintsch]

In <[EMAIL PROTECTED]>, Michael Torrie
wrote:

> I think non-ASCII characters makes the problem far far worse.  While I
> may not understand what the function is by it's name in your example,
> allowing non-ASCII characters makes it works by forcing all would-be
> code readers have to have all kinds of necessary fonts just to view the
> source code.  Things like reporting exceptions too.  At least in your
> example I know the exception occurred in zieheDreiAbVon.  But if that
> identifier is some UTF-8 string, how do I go about finding it in my text
> editor, or even reporting the message to the developers?  I don't happen
> to have that particular keymap installed in my linux system, so I can't
> even type the letters!

You find it in the sources by the line number from the traceback and the
letters can be copy'n'pasted if you don't know how to input them with your
keymap or keyboard layout.

Ciao,
Marc 'BlackJack' Rintsch
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: GUI tutorial

[Peter Decker]

On 5/13/07, John K Masters <[EMAIL PROTECTED]> wrote:
> Can someone point me in the direction of a good tutorial on programming
> python with a GUI? I'm just starting out with python and have written a
> few scripts successfully but would like to add a graphical front end to
> them to make it easier for my work colleagues, most of whom have never
> used a command line, to use.

Take a look at the Dabo screencasts. They illustrate very well how
easy it is to create GUIs using visual tools instead of in code. Of
course, you can still create them in code if you like, but where's the
fun in that?  :)

http://dabodev.com/documentation

-- 

# p.d.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Finally started on python..

[Gabriel Genellina]

En Sat, 12 May 2007 14:09:06 -0300, Roger Gammans  
<[EMAIL PROTECTED]> escribió:

> Having known about python since around the turn of the century ,
> I finally found a (actually two) reason to learn it.

Welcome!

> Does the python communitity have something like Perl's CPAN and
> is there already something there taht does this or would it
> be something that I could give back? Is there a naming
> convention for such modules in python - I couldn't easly detect
> one looking at the library which whip with python in Debian.

See the Python wiki pages, you can get the answer to these and many more  
questions:
http://wiki.python.org/moin/PublishingPythonModules and
http://wiki.python.org/moin/PythonStyle

-- 
Gabriel Genellina

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

Re: docs patch: dicts and sets

[rurpy]

On May 11, 7:41 pm, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> On May 11, 5:59 pm, "Alan Isaac" <[EMAIL PROTECTED]> wrote:
>
> > This is an attempt to synthesize Bill and Carsten's proposals.
> > (I'm changing the subject line to better match the topic.)
>
> >http://docs.python.org/lib/typesmapping.html:forfootnote (3)
>
> > Keys and values are listed in an arbitrary order.  This order is
> > indeterminate and generally depends on factors outside the scope of
> > the
> > containing program.  However, if items(), keys(), values(),
> > iteritems(), iterkeys(), and itervalues() are called with no
> > intervening modifications to the dictionary, the lists will directly
> > correspond.
>
> >http://docs.python.org/lib/types-set.html:appenda new sentence to 2nd par.
>
> > Iteration over a set returns elements in an indeterminate
> > order,which
> > generally depends on factors outside the scope of the containing
> > program.
>
> This doesn't improve the docs. It suggests some mystic forces at work
> while offering nothing that is actionable or that improves
> understanding.   Adding this kind of muck will only make the docs less
> clear.

I too find the suggested text not very clear and would not
immediately predict from it the effects that started this
thread (or actually, the thread in
http://groups.google.com/group/comp.lang.python/msg/4dc632b476fdc6d3?hl=en&;)

> Recommend dropping this one and moving on to solve some real problems.

Perhaps this attitude helps explain some of the problems
in the current documentation.

Dismissing this as not a "real problem" is both wrong
and offensive to people taking the time to actually
propose improvements.

The current docs are clearly wrong.  To repeat what has
already been pointed out, they say, "Keys and values are
listed in an arbitrary order which is non-random,
varies across Python implementations, and depends on the
dictionary's history of insertions and deletions."

It has been shown that even when the history of insertions
and deletions is the same, the order may be different.
Taking "history" to extend across program invocation
boundaries is unconventional to put it charitably, and
there is no reason to assume that interpretation would
occur to a reasonable reader.  The whole issue can be
cleared up simply by clarifying the documentation; I
really fail to see why this should be at all controversial.

I will offer my own suggestion based on the belief that
documentation should be as explicit as possible:

"Keys and values are listed in an arbitrary but non-random
order which may vary across Python versions, implementations,
and the dictionary's history of insertions and deletions.
When the contents are objects using the default implementation
of __hash__() and __eq__(), the order will depend on the
objects' id() values which may be different even between
different invocations of a program (whether executed from
a .py or a .pyc file for example.)"

Apropos sig...
--
Any software can be broken or fixed simply by changing
the documentation.

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

Re: PEP 3131: Supporting Non-ASCII Identifiers

[Aldo Cortesi]

Thus spake "Martin v. Löwis" ([EMAIL PROTECTED]):

> - should non-ASCII identifiers be supported? why?

No! I believe that:

- The security implications have not been sufficiently explored. I don't
  want to be in a situation where I need to mechanically "clean" code (say,
  from a submitted patch) with a tool because I can't reliably verify it by
  eye.  We should learn from the plethora of Unicode-related security
  problems that have cropped up in the last few years. 
- Non-ASCII identifiers would be a barrier to code exchange. If I know
  Python I should be able to easily read any piece of code written in it,
  regardless of the linguistic origin of the author. If PEP 3131 is
  accepted, this will no longer be the case. A Python project that uses
  Urdu identifiers throughout is just as useless to me, from a
  code-exchange point of view, as one written in Perl.
- Unicode is harder to work with than ASCII in ways that are more important
  in code than in human-language text. Humans eyes don't care if two
  visually indistinguishable characters are used interchangeably.
  Interpreters do. There is no doubt that people will accidentally
  introduce mistakes into their code because of this.


> - would you use them if it was possible to do so? in what cases?

No.




Regards,



Aldo



-- 
Aldo Cortesi
[EMAIL PROTECTED]
http://www.nullcube.com
Mob: 0419 492 863
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Finally started on python..

[John Machin]

On May 13, 3:09 am, Roger Gammans <[EMAIL PROTECTED]> wrote:
> 2)
> I've ended up coding a new wrapper for reading in data structures
> from XML files (it wraps xml.sax) so that ctor are call on each end
> tag with the XML Objects contents.
>

> is there already something there taht does this

Check out ElementTree at http://www.effbot.org/ ... it may be similar

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

Re: design question

[Gabriel Genellina]

En Sun, 13 May 2007 11:40:16 -0300, Bruno Desthuilliers  
<[EMAIL PROTECTED]> escribió:

> It's alas pretty common to see OO taught by persons who'd rather do some
> other job - preferably not related to computers.

If I had to name my worst class at university, it was the first one about  
OO. The teacher really had no idea of what he was talking about - and you  
didn't have to be a genius to notice it. After a few weeks I moved on to  
an alternate class. Next semester there was a different teacher.

-- 
Gabriel Genellina

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

Weekly Python Patch/Bug Summary

[Kurt B. Kaiser]

Patch / Bug Summary
___

Patches :  362 open ( +2) /  3766 closed ( +6) /  4128 total ( +8)
Bugs:  968 open ( -3) /  6692 closed ( +9) /  7660 total ( +6)
RFE :  256 open ( -1) /   286 closed ( +4) /   542 total ( +3)

New / Reopened Patches
__

Fix off-by-one error in Modules/socketmodule.c  (2007-05-06)
CLOSED http://python.org/sf/1713797  opened by  Bryan Østergaard

Patch for PEP 3109  (2007-05-06)
   http://python.org/sf/1713889  opened by  wpy

os.linesep needs clarification  (2007-05-07)
CLOSED http://python.org/sf/1714700  opened by  Gabriel Genellina

x64 clean compile patch for _ctypes  (2007-05-09)
   http://python.org/sf/1715718  opened by  Kristján Valur

"Really  print?" Dialog  (2007-05-11)
   http://python.org/sf/1717170  opened by  Tal Einat

textView code cleanup  (2007-05-13)
   http://python.org/sf/1718043  opened by  Tal Einat

PEP 3123 implementation  (2007-05-13)
   http://python.org/sf/1718153  opened by  Martin v. Löwis

Patches Closed
__

Fix off-by-one error in Modules/socketmodule.c  (2007-05-06)
   http://python.org/sf/1713797  closed by  gbrandl

make range be xrange  (2006-04-18)
   http://python.org/sf/1472639  closed by  nnorwitz

xrange that supports longs, etc  (2006-08-24)
   http://python.org/sf/1546078  closed by  nnorwitz

os.linesep needs clarification  (2007-05-08)
   http://python.org/sf/1714700  closed by  gbrandl

PEP 3132: extended unpacking  (2007-05-02)
   http://python.org/sf/1711529  closed by  gbrandl

Bastion and rexec message out-of-date  (2007-04-12)
   http://python.org/sf/1698951  closed by  gbrandl

New / Reopened Bugs
___

smtplib starttls() didn't do TLS Close Notify when quit()  (2007-05-07)
CLOSED http://python.org/sf/1713993  opened by  AndCycle

Multiple re.compile flags cause error  (2007-05-06)
CLOSED http://python.org/sf/1713999  opened by  Saul Spatz

character set in Japanese on Ubuntu distribution  (2007-05-04)
   http://python.org/sf/1713252  reopened by  cgrell

Universal line ending mode duplicates all line endings  (2007-05-07)
CLOSED http://python.org/sf/1714381  opened by  Geoffrey Bache

subprocess.py problems errors when calling cmd.exe  (2007-05-07)
   http://python.org/sf/1714451  opened by  tzellman

python throws an error when unpacking bz2 file  (2007-05-08)
   http://python.org/sf/1714773  opened by  runnig

datetime.date won't accept 08 or 09 as valid days.  (2007-05-08)
CLOSED http://python.org/sf/1715302  opened by  Erik Wickstrom

Const(None) in compiler.ast.Return.value  (2007-05-09)
   http://python.org/sf/1715581  opened by  Ali Gholami Rudi

Destructor behavior faulty  (2007-05-12)
   http://python.org/sf/1717900  opened by  Wolf Rogner

posixpath and friends have uses that should be documented  (2007-05-13)
   http://python.org/sf/1718017  opened by  Gabriel de Perthuis

Bugs Closed
___

smtplib starttls() didn't do TLS Close Notify when quit()  (2007-05-07)
   http://python.org/sf/1713993  deleted by  andcycle

Multiple re.compile flags cause error  (2007-05-07)
   http://python.org/sf/1713999  closed by  gbrandl

Universal line ending mode duplicates all line endings  (2007-05-07)
   http://python.org/sf/1714381  closed by  gbrandl

datetime.date won't accept 08 or 09 as valid days.  (2007-05-08)
   http://python.org/sf/1715302  closed by  fdrake

Segfaults on memory error  (2007-04-10)
   http://python.org/sf/1697916  closed by  gbrandl

types.InstanceType is missing but used by pydoc  (2007-04-10)
   http://python.org/sf/1697782  closed by  gbrandl

improving distutils swig support - documentation  (2004-10-14)
   http://python.org/sf/1046945  closed by  gbrandl

New / Reopened RFE
__

Expose callback API in readline module  (2007-05-06)
   http://python.org/sf/1713877  opened by  strank

if something as x:  (2007-05-07)
   http://python.org/sf/1714448  opened by  k0wax

RFE Closed
__

commands module  (2007-05-06)
   http://python.org/sf/1713624  closed by  gbrandl

additions to commands lib  (2003-11-11)
   http://python.org/sf/840034  closed by  gbrandl

A large block of commands after an "if" cannot be   (2003-03-28)
   http://python.org/sf/711268  closed by  gbrandl

Please add .bz2 in encodings_map (in the module mimetypes)  (2007-04-25)
   http://python.org/sf/1707693  closed by  gbrandl

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