Re: Basic Boost.Python Question

[Pierre Barbier de Reuille]

Hoop wrote:
> Hi,
> 
> I have been working in getting Boost.Python running on my PC, seems to
> work now.
> I have what I believe is somewhat of basic question here.
> I am starting on an application that will developed in VS2005, probably
> using C++/CLI.
>  I want to be able to exchange data in between Python and C++. The user
> when running the  C++ app will be able to call a python script, set
> some values, that will then be communicated to running application, it
> will have to run the python code, and send some data to the
> applicationfrom Python to vary the performance. And probably the C++
> end will have to call a python script and pass some data to it.
> So, is Boost.Python the way to go here or is there something else that
> will accomplish this?

Boost.Python is certainly a (good) way to do it ! I go as far as
including a Python shell to allow two-way interactions with the objects
loaded in the C++ GUI of my app ... Look at the tutorial, mostly here:

http://www.boost.org/libs/python/doc/tutorial/doc/html/python/embedding.html

To know how to use Python from a C++ application. But I warn you: it is
much simpler the other way around, i.e. having a Python app' calling
some C++ code to make some parts quicker (or call already existing libs).

Pierre

> 
> Thanks for your help
> Jeff
> 
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Nested if and expected an indent block

[Pierre Barbier de Reuille]

[EMAIL PROTECTED] wrote:
> Simon Forman wrote:
>>> I got rid of the triple quote string at the start of the function, and
>>> that cleared up the problem, though I don't know why.
>>>
>> Ah, yes. The docstring for a function (or at least its first
>> triple-quote) must be indented to the same degree as its statements.
>> (If you're using IDLE it should have indented it for you when you hit
>> return after the def statement.)
>>
>> HTH,
>> ~Simon
> 
> Hi Simon:
> 
> Thanks. I code in VB / VBA, and use indented structure, but it's not
> enforced they way it is in Python - still getting used to that. Also, I
> got goofed up editing some of the code in VIM, indenting with tabs, and
> then switching to IDLE, with space indentation. Whoops...
> 
> Thanks for all the help everyone, my first Python program is now
> working!
> 
> Keith
> 

Tips: if you're coding with VIM, put "set expandtab" in your config
file. That way, each tab will be expanded into the corresponding number
of spaces ... Whatever the language, I find it always a bad idea to mix
spaces and tabs, and I prefer spaces ...

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

Re: do people really complain about significant whitespace?

[Pierre Barbier de Reuille]

Carl Banks wrote:
> Michiel Sikma wrote:
>> Op 8-aug-2006, om 1:49 heeft Ben Finney het volgende geschreven:
>>
>>> As others have pointed out, these people really do exist, and they
>>> each believe their preconception -- that significant whitespace is
>>> intrinsically wrong -- is valid, and automatically makes Python a
>>> lesser language.
>> Well, I most certainly disagree with that, of course, but you gotta
>> admit that there's something really charming about running an auto-
>> formatting script on a large piece of C code, turning it from an
>> unreadable mess into a beautifully indented and organized document.
> 
> The only time I get that satisfaction is when I run the formatter to
> format some C code I'm asked to debug.  Quite often the problem was
> something that could have been easily spotted if the coder had used
> good indentation in the first place.  Though they probably wouldn't
> have seen it anyways, considering the poor programming skills of most
> engineers (the classical definition, not computer engineers).
> 
> The very fact the code formatters exist should tell you that grouping
> by indentation is superior.
> 
> 
> Carl Banks
> 

Problem being : grouping by indentation do *not* imply good indentation.
For example, I had to read a piece of (almost working) code which looked
like that :


  if cond1 : stmt1
 stmt2
 stmt3
  if cond2:  stmt4
 stmt5
  elif cond3:stmt6
 stmt7
  else:  stmt8
 stmt9
 stmt10
 stmt11



So you can tell what you want, but this code is valid but impossible to
read and impossible to reindent correctly. So although I personnaly like
Python, I still don't think meaningful indentation is good.

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

Re: How do you implement this Python idiom in C++

[Pierre Barbier de Reuille]

[EMAIL PROTECTED] wrote:
> Pierre Barbier de Reuille wrote:
[...]
> 
> I thank you for your response. The equivalent of your solution is
> posted hereunder:
> class cA(object):
> count=0
> def __init__(self):
> self.__class__.count +=1
> @classmethod
> def getcount(cls):
> return cls.count
>   def __del__(self):
>   self.__class__.count -=1
> class cB(cA):
> count=0
> def __init__(self):
>   super(cB,self).__init__()
>   for klass in self.__class__.__bases__:
>   klass.count +=1
> 
> a=cA() ; b=cA(); c= cA()
> d=cB() ; e=cB(); f= cB()
> a.a=1;b.a=1;c.a=1;d.a=1;e.a=1;f.a=1
> g=cA()
> g.a=1
> print  '#cA=',cA.getcount()  # 7
> print '#cB=',cB.getcount() #  3
> del g
> print  '#cA=',cA.getcount()  # 6
> print '#cB=',cB.getcount() #  3
> 
> There is nothing impossible in Python ;-)
> 
> Alain
> 

Well, nothing is impossible, but it is now much much more complex ! As a
proof of that, your version does not work completely :P (try deleting d
for example).

I add a working version, but you will also notice that I have to
*explicitly* walk over all the classes of the hierarchy, testing for the
one who have a "count" attribute, hoping that this attribute is indeed
for counting the number of objects and not anything else ... so the
solution is quite fragile and very slow.

class cA(object):
count=0
def __init__(self):
self.__class__.count +=1
for klass in self.__class__.__bases__:
if hasattr( klass, "count" ):
klass.count += 1

@classmethod
def getcount(cls):
return cls.count
def __del__(self):
self.__class__.count -=1
for klass in self.__class__.__bases__:
if hasattr( klass, "count" ):
klass.count -= 1
class cB(cA):
count=0

a=cA() ; b=cA(); c= cA()
d=cB() ; e=cB(); f= cB()
a.a=1;b.a=1;c.a=1;d.a=1;e.a=1;f.a=1
g=cA()
g.a=1
print  '#cA=',cA.getcount()  # 7
print '#cB=',cB.getcount() #  3
del g
del d
print  '#cA=',cA.getcount()  # 5
print '#cB=',cB.getcount() #  2

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

Re: Using iterators to write in the structure being iterated through?

[Pierre Barbier de Reuille]

Pierre Thibault wrote:
> On Wed, 26 Jul 2006 18:54:39 +0200, Peter Otten wrote:
> 
>> Pierre Thibault wrote:
>>
[...]
> 
> Now, I want to do simple math operations on the data in C. Doing a loop
> from 0 to 49 would loop twice through the actual data. In this
> context, an iterator is perfect since it can take care internally of going
> through the data only once, so it would be great to access _AND MODIFY_
> data over which I iterate.
> 

The biggest problem I think is that numbers are immutable in Python.
Thus you cannot modify a number if you have a variable on it! All you
can do is modify the content of the variable.

IMHO, the way to go is to iterate on the indices and not on the values
(not much slower in Python). For example you can do something like:

lst1 = [1,2,3,4]
lst2 = [4,3,4,5]

for i in xrange(len(lst1)):
  lst1[i] += lst2[i]

If you *really* want to iterate (for example to support something else
that lists), then you will need to create a new structure like that:

from itertool import izip

lst1 = MyList1()
lst2 = MyList2()

result = [0]*len(lst1) # If possible

for i,(e1,e2) in enumerate(izip(lst1, lst2)):
  result[i] = e1+e2

lst1[:] = result # If you really need it

An intermediate possibility would be (if lst1 is indexable):

for i,e2 in enumerate(lst2):
  lst1[i] += e2

But it all depend on the kind of structure you get.

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

Re: How do you implement this Python idiom in C++

[Pierre Barbier de Reuille]

[EMAIL PROTECTED] wrote:
> Rob Williscroft wrote:
> 
>> If this is more than idle curiosity I strongly suggest you post
>> a version of the python code you need to translate to C++.
> 
> For the moment this is just healthy curiosity but i will still post the
> code i would like to see translated:
> 
> class Parent:
>   count=0
>   def __init__(self):
>   self.__class__.count +=1
>   @classmethod
>   def getcount(cls):
>   return cls.count
> 
> class Child(Parent):
>   count=0 # replace this line by a 'pass'  statement if you don't want
> to reinitialise the count
> 
> a=Parent()
> b=Parent()
> print Parent.getcount()  # you get 2
> c=Child()
> d=Child()
> e=Child()
> print Child.getcount() # you get 3 (you could get 5 if you don't
> reinitialise the count)
> 
> This is as simple as it can get. I just derive from Parent and i get my
> proper count (added to my parent's if i wish so).
> I wish i could achieve such a code purity in C++.

Well, I hope you understand that this code "purity" is possible only
because of the *dynamic* lookup of the variable name ... Thus, the same
function, once compiled, will be able to determine, at runtime, where
the current variable lies ... At the same time, tries, in Python, to
achieve the count of *all* the instances of a class, meaning that you want :

a = Parent()
b = Child()
c = Parent()
d = Child()
print Child.getcount() # 2
print Parent.getcount() # 4

That time, the automatic name lookup will come in the way as you cannot
have two "count" variables accessible from the same class.
For C++ the problem is inverse, you have a way to obtain the second
thing (using templates or macro), but the first is harder.

Pierre

PS: here is my solution in C++


#include 
using namespace std;

template 
struct Counted
{
  Counted() { ++count; }
  Counted( Counted const& ) { ++count; }
  virtual ~Counted() { --count; }
  static size_t getCount() { return count; }
protected:
  static size_t count;
};

template 
size_t Counted::count = 0;

struct cA : public Counted
{
  int a;
};

struct cB : public Counted, public cA
{
  // Needed to be sure of which getCount is called in cB
  using Counted::getCount;
};

int main()
{
  cA a,b,c;
  cB d,e,f;
  a.a = 1;
  b.a = 1;
  c.a = 1;
  d.a = 1;
  e.a = 1;
  f.a = 1;
{
cA g;
g.a = 1;
cout << "#cA = " << cA::getCount() << endl; // 7
cout << "#cB = " << cB::getCount() << endl; // 3
}
  cout << "#cA = " << cA::getCount() << endl; // 6
  cout << "#cB = " << cB::getCount() << endl; // 3
  return 0;
}
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How do you implement this Python idiom in C++

[Pierre Barbier de Reuille]

[EMAIL PROTECTED] wrote:
> Hello,
> 
> I have the need to write the equivalent of Python class methods in C++.
> 
> Chuck Allison proposes the following
> (http://www.artima.com/cppsource/simple.html):
> #include 
> using namespace std;
> 
> // A base class that provides counting
> template class Counted {
>   static int count;
> public:
>   Counted() { ++count; }
>   Counted(const Counted&) { ++count; }
>   ~Counted() { --count; }
>   static int getCount() { return count; }
> 
> };
> 
> template int Counted::count = 0;
> 
> // Curious class definitions
> class CountedClass : public Counted {};
> class CountedClass2 : public Counted {};
> 
> It apparently works but in fact it doesn't:
> If you derive from such a class, you get the count of the parent class,
> 
> not of the derived class.
> class CountedClass3 : public CountedClass {};
> 
> int main() {
>   CountedClass a;
>   cout << CountedClass::getCount() << endl;// 1
>   CountedClass b;
>   cout << CountedClass::getCount() << endl;// 2
>   CountedClass3 c;
>   cout << CountedClass3::getCount() << endl;   // 3 and should be 1
>   cout << CountedClass::getCount() << endl;// 3 and should be 2
> 
> }
> 
> I am no C++ expert but i guess there might be some in the Python and
> C++ newsgroups. 
> 
> Alain
> 

Why don't you post the Python code you want to "translate" ? Here, I
just don't know what you want to achieve !!

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

Re: Trying to generate a list of the subclasses of C

[Pierre Barbier de Reuille]

Charles Krug a écrit :
> List:
> 
> I have this:
> 
> # classC.py
> 
> class C(object): pass
> 
> class D(C): pass
> 
> class E(C): pass
> 
> def CSubclasses():
> for name in dir(): pass
> 
> I'm trying to create a list of all of C's subclasses:
> 
> import classC
> 
> print C
> aList = []
> for name in dir(classC):
> print name,
> try:
> if issubclass(classC.__dict__[name], C):
> print classC.__dict__[name]
> else:
> print
> except TypeError:
> print
> 

Where is C defined ?

>>> import classC

does not define the name C in the current scope ... thus, you should write :

for name in dir(classC):
print name,
try:
if issubclass(classC.__dict__[name], classC.C):
print classC.__dict__[name]
else:
print
except TypeError:
print

and it gives :

C 
CSubclasses
D 
E 
__builtins__
__doc__
__file__
__name__

... which is exactly what you want !

Pierre

> Which gives me this:
> 
> 
> C
> CSubclasses
> D
> E
> __builtins__
> __doc__
> __file__
> __name__
> 
> However when I do this from the command line:
> 
> 
issubclass(D,C)
> 
> True
> 
> but
> 
> 
issubclass(classC.__dict__['D'], C)
> 
> False
> 
> So my approach is flawed.
> 
> The end result I'm after is an automatically generated dictionary
> containing instaces of the subclasses keyed by the subclass names:
> 
> {'D':D(), 'E':E(), . . . }
> 
> I can see the information I need in the module's __dict__ and by using
> the dir() method, but I'm not having much success extracting it.
> 
> 
> 
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: boost.python on Debian

[Pierre Barbier de Reuille]

Joe bloggs a écrit :
> Can anyone tell me how to get boost.python to work on Debian Sarge?
> When I try to build the tutorial hello world example bjam reports:
> 
> /usr/share/doc/libboost-doc/examples/libs/python/example/boost-build.jam
> attempted to load the build system by invoking
> 
> 'boost-build ../../../tools/build/v1 ;'
> 
> but we were unable to find "bootstrap.jam" in the specified directory or
> in BOOST_BUILD_PATH (searching 
> /usr/share/doc/libboost-doc/examples/libs/python/example/../../../tools/build/v1,
> /usr/share/boost-build).
> 
> I have looked for 'bootstrap.jam' but it doesn't exist on my system. 
> I suppose that the Debian boost package doesn't have the same structure as
> the official one, and is missing some files. 
> Can anyone tell me how to fix this?

Well, is :

$ apt-get install libboost-python-dev

a valid answer ? Because the Boost project itself maintains the debian
packages, they are always very up-to-date ...

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

Re: Inheritance problem?

[Pierre Barbier de Reuille]

KraftDiner a écrit :
> So ok I've written a piece of code that demonstrates the problem.
> Can you suggest how I change the Square class init?
> 
> class Shape(object):
>   def __init__(self):
>   print 'MyBaseClass __init__'
> 
> class Rectangle(Shape):
>   def __init__(self):
>   super(self.__class__, self).__init__()
>   self.type = Rectangle
>   print 'Rectangle'
> 
> class Square(Rectangle):
>   def __init__(self):
>   super(self.__class__, self).__init__()
>   self.type = Square
>   print 'Square'
> 
> r = Rectangle()
> s = Square()
> 

I suggest you have a look at the link I gave before :
http://fuhm.org/super-harmful/

It gives a good explanation about what happens with "super".

At least, if you *really* want to use it, change your code like that :

class Shape(object):
  def __init__(self):
super(Shape, self).__init__()
print 'Shape __init__'

class Rectangle(Shape):
  def __init__(self):
super(Rectangle, self).__init__()
self.type = Rectangle
print 'Rectangle'

class Square(Rectangle):
  def __init__(self):
super(Square, self).__init__()
self.type = Square
print "Square"

r = Rectangle()
s = Square()


But, once more, I would recommand to use direct method call 

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

Re: Inheritance problem?

[Pierre Barbier de Reuille]

Xavier Morel a écrit :
> Pierre Barbier de Reuille wrote:
> 
>> Well, I would even add : don't use super !
>> Just call the superclass method :
>>
>> MyClass.__init__(self)
>>
>>
>>
>> Simon Percivall a écrit :
>>
>>> Don't use self.__class__, use the name of the class.
>>>
> Bad idea if you're using new-style classes with a complex inheritance
> hierarchy and multiple inheritance.

As a reference :

http://fuhm.org/super-harmful/

I may say this is the only place I ever saw what "super" *really* is
for. The behavior is far too complex and misthought. All I can say is :
don't use it ! It solves *nothing* and creates too many bugs in the long
run.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Inheritance problem?

[Pierre Barbier de Reuille]

Well, I would even add : don't use super !
Just call the superclass method :

MyClass.__init__(self)



Simon Percivall a écrit :
> Don't use self.__class__, use the name of the class.
> 
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Proposal for adding symbols within Python

[Pierre Barbier de Reuille]

Rocco Moretti a écrit :
[...]
> 
> 
> I did, but I still don't see why it is an argument against using
> strings. The point you may not appreciate is that (C)Python already uses
> strings to represent names, as an important part of its introspective
> abilities.
> 

Well, I'm well aware of that, but I'm also well aware that's (as you
said yourself) specific to C-Python, so can just *cannot* rely on
strings being used as symbols in the language. What I would like to see
in Python is "names" (or "symbols", as you prefer) defined within the
language so that you'll get something similar in whatever Python
implementation.

Then, in CPython, names may well be just strings are they already are
implemented to be efficient as such, but other implementation may just
choose something completly different.

The point is, why don't provide the programmer to express just what he
needs (that is, some symbolic value like "opened", "blocked", ...) and
let the interpreter use whatever he think is more efficient for him ?

That's the whole points for "names" ... being able to handle symbolic
values within the language, that's what made LISP so successful. That's
what makes dynamic languages possible ! But why say a name is a
*string* when it is just an implementation detail ??? Isn't Python
mainly about allowing the programmer to concentrate on important stuff ?

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

Re: Not enough arguments for format string

[Pierre Barbier de Reuille]

Kevin Walzer a écrit :
> I'm getting an error in a Python script I'm writing: "not enough
> arguments for format string." The error comes at the end of the
> os.system command, referenced below. Any ideas?
> 
> ---
> 
> import EasyDialogs
> import os
> import sys
> 
> 
> password = EasyDialogs.AskPassword("To launch Ethereal, please enter
> your password:")
> binpath = os.path.join(os.path.dirname(sys.argv[0]),
> '/opt/local/bin/ethereal')   
> 
> os.system('open -a X11.app; cd ~/; printenv; DISPLAY=:0.0; export
> DISPLAY;  echo %s | sudo -S %s; sudo -k' %password %binpath)
> 
> TypeError: not enough arguments for format string
> 
> 

Well, just try :
os.system('open -a X11.app; cd ~/; printenv; DISPLAY=:0.0; export
DISPLAY;  echo %s | sudo -S %s; sudo -k' % (password, binpath) )

The reason is, you have 2 "%s" in yor string, thus after the "%"
operator, you need a 2-element tuple ! If you have either more or less
element, you'll get a TypeError ! In your code above you put a single
element ...

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

Re: Proposal for adding symbols within Python

[Pierre Barbier de Reuille]

Ben Finney a écrit :
> Michael <[EMAIL PROTECTED]> wrote:
> 
>>Ben Finney wrote:
>>
>>>I've yet to see a convincing argument against simply assigning
>>>values to names, then using those names.
>>
>>If you have a name, you can redefine a name, therefore the value a
>>name refers to is mutable.
> 
> 
> Since there are mutable and immutable values, it might be clearer to
> say "the binding of a name to a value can be changed". Yes?
> 
> In that case, I don't see why someone who wants such a binding to be
> unchanging can't simply avoid changing it. Where's the case for having
> Python enforce this?
> 

The problem is not about having something constant !
The main point with symbols is to get human-readable values.
Let say you have a symbol "opened" and a symbol "closed". The state of a
file may be one of the two.

If you have these symbols, you can ask for the state at any point and
get something readable. If you use constants valued, typically, to
integers, the state of your file will we 0 or 1, which does not mean
anything.

Now, if you're using an object with more than two states, and moreover
if the number of states is likely to increase during developpement, it's
much more convenient to directly get the *meaning* of the value rather
than the value itself (which does not mean anything).

The key point that, I think, you misunderstand is that symbols are not
*variables* they are *values*.

> 
>>Conversely consider "NAME" to be a symbol. I can't modify "NAME". It
>>always means the same as "NAME" and "NAME", but is never the same as
>>"FRED". What's tricky is I can't have namespaceOne."NAME" [1] and
>>namespaceTwo."NAME" as different "NAME"s even though logically
>>there's no reason I couldn't treat "NAME" differently inside each.
> 
> 
> So you want to mark such objects as being in a namespace, where they
> compare the same within that namespace but not outside. Why is
> separate syntax necessary for this? A data type that is informed of
> its "space", and refuses comparison with values from other spaces,
> would suffice.
> 
> class Xenophobe(object):
> def __init__(self, space, value):
> self.__space = space
> self.__value = value
> 
> def __str__(self):
> return str(self.__value)
> 
> def __cmp__(self, other):
> if not isinstance(other, Xenophobe):
> raise AssertionError, \
> "Can only compare Xenophobes to each other"
> if not other.__space == self.__space:
> raise AssertionError, \
> "Can only compare Xenophobes from the same space"
> return cmp(self.__value, other.__value)
> 
> With the bonus that you could pass such values around between
> different names, and they'd *still* compare, or not, as you choose
> when you first create them.
> 
> Replace the AssertionError with some appropriate return value, if you
> want such comparisons to succeed.
> 

Well, I think a new syntax will promote the use of symbols. And as I
think they are good practice (much better than meaningless constants)
they should be promoted. Needless to say that in every language I know
implementing symbols (or something close to symbols), there is an
easy-to-use syntax associated.

> 
>>However it might be useful to note that these two values (or
>>symbols) are actually different, even if you remove their
>>namespaces.
> 
> 
> The above Xenophobe implementation creates objects that know their
> "space" forever.
> 
> 
>>To me, the use of a symbol implies a desire for a constant, and then
>>to only use that constant rather than the value. In certain
>>situations it's the fact that constant A is not the same as constant
>>B that's important (eg modelling state machines).
> 
> 
> Since the actual value can't be easily accessed, the only purpose of a
> Xenophobe is too be created and compared to others.
> 
> 
>>Often you can use strings for that sort of thing, but unfortunately
>>even python's strings can't be used as symbols that are always the
>>same thing in all ways. For example, we can force the id of
>>identical strings to be different:
> 
> 
> Hold up -- what in your stated use case requires *identity* to be the
> same? You said you just wanted to compare them to each other.
> 
> Besides, Python *does* preserve identity for short strings...
> 
> 
>s = "h"*1
>x = "h"*1
>id(s), id(x)
>>
>>(135049832, 135059864)
> 
> 
> ... which is sufficient for unique values, if you're not actively
> fighting the system as above. If the use case is for brief, identical
> values, we have those: short strings.

Well, one *big* difference between short string and symbols is that the
identity between short strings are implementation dependant, while
between symbols it has to be in all implementations as you will rely on
this identity. Then, once more, strings are just one possible
implementation for symbols and I wouldn't like to tie that much symbols
to strings

Re: Proposal for adding symbols within Python

[Pierre Barbier de Reuille]

Björn Lindström a écrit :
> Ben Finney <[EMAIL PROTECTED]> writes:
> 
> 
>>I've yet to see a convincing argument against simply assigning values
>>to names, then using those names.
> 
> 
> The problem with that is that you can't pass around the names of objects
> that are used for other things. Obviously they make enums unnecessary,
> but only people damaged by non-dynamic languages could think that's the
> main point. ;-)
> 
> Being able to do that precludes the need for converting going back and
> forth between strings and method names when you need to do things like
> keeping a list of function names, even when you need to be able to
> change what those function names point to.
> 
> Python doesn't really need to introduce a new type to do this. It's
> already there, as what we usually just call names. Probably this
> discussion would benefit from talking about names rather than symbols,
> as that seems to confuse some people.
> 
> So, Python already has symbols. What we need is a way to refer to these
> symbols explicitly. I would suggest to do it like in Lisp:
> 
> quote(spam)
> 
> Of course, this would preferably be implemented so that it doesn't just
> work on simple names:
> 
> quote(spam(eggs))
> 
> I syntactic sugar, like ' in Lisp, could be introduced later, but I
> don't think that would be strictly necessary.
> 

Well, if this already exists in Python's internals, then, it would be
great just to expose them. Now, just being able to write :

>>> quote(spam)
quote(spam)

requires a new syntax so that spam is not resolved *before* calling the
quote method.

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

Re: Proposal for adding symbols within Python

[Pierre Barbier de Reuille]

Steven D'Aprano a écrit :
> On Sun, 13 Nov 2005 12:33:48 +0100, Pierre Barbier de Reuille wrote:
> 
> 
>>Steven D'Aprano a écrit :
>>[...]
> 
> 
> If you want to be technical, Python doesn't have variables. It has names
> and objects.
> 
> If I want a name x to be bound to an object 1, I have to define it
> (actually bind the name to the object):
> 
> x = 1
> 
> If I want a symbol $x$ (horrible syntax!!!) with a value 1, why shouldn't
> I define it using:
> 
> $x$ = 1
> 
> instead of expecting Python to somehow magically know that I wanted it?
> What if somebody else wanted the symbol $x$ to have the value 2 instead?
> 

Well, as stated, I don't care about the actual value of symbols. They
*are* values. A trivial implementation of symbols are strings :

$x$ <=> "x"

However, that won't fit because of the scope, because it would be great
to use "is" instead of "==" (even if not necessary), and as said Mike,
you might want something else than a string. That's why `x` would be a
good wawy to write that.

> 
> 
>>>[snip]
> 
> 
> I've read the discussion, and I am no wiser.
> 
> You haven't explained why enums are not suitable to be used for symbols.
> You gave two "problems", one of which was "easy to fix", as you said
> yourself, and the other reason was that you don't want to define enums as
> symbols. 
> 
> If you don't want to define something manually, that can only mean that
> you expect them to be predefined. Or am I misunderstanding something?
> 

Well, I suspect Python will know them, exactly as it know "without
defining it" that "foo" is the string with chars f, o, o, that 3 is the
number 3, that [1,2] is the list with 1 and 2, ... However, to get
quicker, symbols could be created at compile-time when possible (like
variables). The fact is, symbols allow compilation optimisations that
you cannot get with regular types, because the language is completely
free about their representations. Then, to the programmer it is a good
way to have a meaningful value without caring about how to represent it
in the computer. That way, while debugging, if I ask the value of
file.state I will get something I can read instead of some meaningless
integer or other anonymous object.

So I gain in readability of my code and in debugging capacity.

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

Re: Proposal for adding symbols within Python

[Pierre Barbier de Reuille]

Ben Finney a écrit :
> Pierre Barbier de Reuille <[EMAIL PROTECTED]> wrote:
> 
>>Mike Meyer a écrit :
>>
>>>Hmm. You know, $symbol$ doesn't seem nearly as bad as $symbol. It
>>>tickles TeX, not P***. I could live with that.
>>
>>Yep, I like this $symbol$ notation !
> 
> 
> Gets a big -1 here.
> 
> I've yet to see a convincing argument against simply assigning values
> to names, then using those names.
> 

I can see three interests :
1 - ensure values are unique (i.e. a bit like using instances of object)
2 - values are meaningful (i.e. with introspection on the values you get
a human-readable value, unlike with instances of object)
3 - getting an *easy* access to those two properties

1 and 2 require a new type, 3 a new syntax (IMO).

Here's a try for the symbol class :

class symbol(object):
  def __init__(self, value):
self._value = value
  def _get_value(self):
return self._value
  value = property(_get_value)
  def __eq__(self, other):
return self.value == other.value
  def __str__(self):
return str(self.value)
  def __repr__(self):
return "symbol(%s)" % (repr(self.value),)

One thing to do would be to return the same object for symbols with the
same value (when possible ...).

For example, if we limit symbol to hashable types, we can implement
something which can be tested with "is" instead of "==":

class symbol(object):
  _cache = {}
  def __new__(cls, value):
if value in symbol._cache:
  return symbol._cache[value]
self = object.__new__(cls)
self._value = value
symbol._cache[value] = self
return self
  def _get_value(self):
return self._value
  value = property(_get_value)
  def __eq__(self, other):
return self.value == other.value
  def __str__(self):
return str(self.value)
  def __repr__(self):
return "symbol(%s)" % (repr(self.value),)

Then, as I suggested, you can do something like :

a = symbol((file, "opened"))

But it's less readable than $file.opened$ (or something similar).

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

Re: Proposal for adding symbols within Python

[Pierre Barbier de Reuille]

Steven D'Aprano a écrit :
> On Sun, 13 Nov 2005 10:11:04 +0100, Pierre Barbier de Reuille wrote:
> 
> 
>>The problem, IMHO, is that way you need to declare "symbols"
>>beforehands, that's what I was trying to avoid by requiring a new syntax.
> 
> 
> ???
> 
> If you don't declare your symbols, how will you get the ones that you want?
> 
> I don't understand why it is a problem to declare them first, and if it is
> a problem, what your solution would be.
> 

Well, just as Python do not need variable declaration, you can just
*use* them ... in dynamic languages using symbols, they just get created
when used (i.e. have a look at LISP or Ruby).

> [snip]
> 
> 
>>Well, I don't think enumarated objects ARE symbols. I can see two
>>"problems" :
>> 1 - in the implementation, trying to compare values from different
>>groups raises an error instead of simply returning "False" (easy to fix ...)
> 
> 
> As you say, that's easy to fix.
> 
> 
>> 2 - You have to declare these enumerable variables, which is not
>>pythonic IMO (impossible to fix ... needs complete redesign)
> 
> 
> Are you suggesting that the Python language designers should somehow
> predict every possible symbol that anyone in the world might ever need,
> and build them into the language as predefined things?
> 
> If that is not what you mean, can you explain please, because I'm confused.
> 

Well, the best I can propose is for you to read the discussion with Mike
Meyer.
He pointer out the flaws in my proposal and we're trying to precise things.

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

Re: Proposal for adding symbols within Python

[Pierre Barbier de Reuille]

Mike Meyer a écrit :
> Pierre Barbier de Reuille <[EMAIL PROTECTED]> writes:
> 
>>>While you don't make it clear, it seems obvious that you intend that
>>>if $open occurs twice in the same scope, it should refer to the same
>>>symbol. So you're using the syntax for a dual purpose. $name checks to
>>>see if the symbol name exists, and references that if so. If not, it
>>>creates a new symbol and with that name. Having something that looks
>>>like a variables that instantiates upon reference instead of raising
>>>an exception seems like a bad idea.
>>
>>Well, that's why symbols are absolutely not variables.
> 
> 
> If they aren't variables, they probably shouldn't *look* like
> variables.

Yes, that's why we should find some way to express that.

>>>Provide a solid definition for the proposed builtin type "symbol".
>>>Something like:
>>>
>>>  symbol objects support two operations: is and equality
>>>  comparison. Two symbol objects compare equal if and only if
>>>  they are the same object, and symbol objects never compare
>>>  equal to any other type of object. The result of other
>>>  operations on a symbol object is undefined, and should raise
>>>  a TypeError exception.
>>>
>>>  symbol([value]) - creates a symbol object. Two distinct
>>>  calls to symbol will return two different symbol objects
>>>  unless the values passed to them as arguments are equal, in
>>>  which case they return the same symbol object. If symbol is
>>>  called without an argument, it returns a unique symbol.
>>
>>Good definition to me !
> 
> 
> Note that this definition doesn't capture the name-space semantics you
> asked for - symbol(value) is defined to return the same symbol
> everywhere it's called, so long as value is equal. This is probably a
> good thing. Using the ability to have non-strings for value means you
> can get this behavior by passing in something that's unique to the
> namespace as part of value. Said something probably depends on the the
> flavor of the namespace in question. This allows you to tailor the
> namespace choice to your needs.

Very interesting ... that way we could get global AND local symbols ...
I like it !

> 
> Also, since I'm allowing non-strings for value, just invoking str on
> the symbol isn't really sufficient. Let's add an attribute 'value',
> such that symbol(stuff).value is identical to stuff. I you want,
> define symbol.__str__ as str(symbol.value) so that str(symbol("foo"))
> returns "foo".
> 
> 
>>Well, maybe we should find some other way to express symbols. The only
>>thing I wanted was a way easy to write, avoiding the need to declare
>>symbols, and allowing the specification of the scope of the symbol. My
>>prefered syntax would be something like :
>>'opened, `opened or `opened`
>>However, none are usable in current Python.
> 
> 
> Well, symbol('opened') solves the declaration issue, but it's not as
> easy as you'd like.
> 
> 
>>>Personally, I think that the LISP quote mechanism would be a better
>>>addition as a new syntax, as it would handle needs that have caused a
>>>number of different proposals to be raised.  It would require that
>>>symbol know about the internals of the implementation so that ?name
>>>and symbol("name") return the same object, and possibly exposing said
>>>object to the programmer. And this is why the distinction about how
>>>LISP acts is important.
>>
>>Maybe, although I may say I cannot see clearly how LISP quote mechanism
>>translates into Python.
> 
> 
> It compiles the quoted expression and returns a code object.  I'd love
> to recycle backquotes so that `expr` means
> compile(expr, 'quoted-expr', 'eval'), but that won't happen anytime soon.
> 
> Hmm. You know, $symbol$ doesn't seem nearly as bad as $symbol. It
> tickles TeX, not P***. I could live with that.

Yep, I like this $symbol$ notation ! It could me equivalent to :

symbol( "symbol" )

And $object.symbol$ could translate into :

symbol( (object, "symbol") )

> 
> Like I said, the tricky part of doing this is getting `symbol` to have
> the semantics you want. If you compile the same string twice, you get
> two different code objects, though they compare equal, and the
> variable names in co_names are the same strings. Maybe equality is
> sufficient, and you don't need identity.
> 
>  http://mail.python.org/mailman/listinfo/python-list

Re: Proposal for adding symbols within Python

[Pierre Barbier de Reuille]

Mike Meyer a écrit :
> Pierre Barbier de Reuille <[EMAIL PROTECTED]> writes:
> 
>>Please, note that I am entirely open for every points on this proposal
>>(which I do not dare yet to call PEP).
>>
>>Abstract
>>
>>
[...]
> 
> 
>>Symbols are objects whose representation within the code is more
>>important than their actual value. Two symbols needs only to be
>>equally-comparable. Also, symbols need to be hashable to use as keys of
>>dictionary (symbols are immutable objects).
> 
> 
> The values returned by object() meet this criteria. You could write
> LISPs gensym as:
> 
>   gensym = object
> 
> As you've indicated, there are a number of ways to get such
> objects. If all you want is symbols, all that really needs to happen
> is that one of those ways be blessed by including an implementation in
> the distribution.

Well, I may rewrite the proposal, but one good thing to have is the
hability to go from symbol to string and the opposite (as written below)
and that is not really allowed by this implementation of symbols.

> 
> 
>>In LISP : Symbols are introduced by "'". "'open" is a symbol.
> 
> 
> No, they're not. "'(a b c)" is *not* a symbol, it's a list. Symbols in
> LISP are just names. "open" is a symbol, but it's normally evaluated.
> The "'" is syntax that keeps the next expression from being evaluated,
> so that "'open" gets you the symbol rather than it's value. Since
> you're trying to introduce syntax, I think it's important to get
> existing practice in other languages right.

You're right ! I was a bit quick here ... "'" is a way to stop
evaluation and you may also write "(quote open)" for "'open".

> 
> 
>>Proposal
>>
>>
>>First, I think it would be best to have a syntax to represent symbols.
> 
> 
> That's half the proposal.
> 
> 
>>Adding some special char before the name is probably a good way to
>>achieve that : $open, $close, ... are $ymbols.
> 
> 
> $ has bad associations for me - and for others that came from an
> earlier P-language. Also, I feel that using a magic character to
> introduce type information doesn't feel very Pythonic.
> 
> While you don't make it clear, it seems obvious that you intend that
> if $open occurs twice in the same scope, it should refer to the same
> symbol. So you're using the syntax for a dual purpose. $name checks to
> see if the symbol name exists, and references that if so. If not, it
> creates a new symbol and with that name. Having something that looks
> like a variables that instantiates upon reference instead of raising
> an exception seems like a bad idea.
> 

Well, that's why symbols are absolutely not variables. One good model
(IMO) is LISP symbols. Symbols are *values* and equality is not
depending on the way you obtained the symbol :

(eq (quote opened) 'opened)

> 
>>On the range of symbols, I think they should be local to name space
>>(this point should be discussed as I see advantages and drawbacks for
>>both local and global symbols).
> 
> 
> Agreed. Having one type that has different scoping rules than
> everything else is definitely a bad idea.
> 
> 
>>There should be a way to go from strings to symbols and the other way
>>around. For that purpose, I propose:
>>
>>
>>>>>assert symbol("opened") == $opened
>>>>>assert str($opened) == "opened"
> 
> 
> So the heart of your proposal seems to be twofold: The addition of
> "symbol" as a type, and the syntax that has the lookup/create behavior
> I described above.
> 

Indeed !

> 
>>Implementation
>>==
>>
>>One possible way to implement symbols is simply with integers resolved
>>as much as possible at compile time.
> 
> 
> What exactly are you proposing be "resolved" at compile time? How is
> this better than using object, as illustratd above?
> 
> Suggested changes:
> 
> Provide a solid definition for the proposed builtin type "symbol".
> Something like:
> 
>   symbol objects support two operations: is and equality
>   comparison. Two symbol objects compare equal if and only if
>   they are the same object, and symbol objects never compare
>   equal to any other type of object. The result of other
>   operations on a symbol object is undefined, and should raise
>   a TypeError exception.
> 
>   symbol([value]) - creates a symbol obje

Re: Proposal for adding symbols within Python

[Pierre Barbier de Reuille]

Ben Finney a écrit :
> Pierre Barbier de Reuille <[EMAIL PROTECTED]> wrote:
> 
>>This proposal suggests to add symbols into Python.
> 
> 
> I still don't think "symbol" is particularly descriptive as a name;
> there are too many other things already in the language that might
> also be called a "symbol".

Well, that's the name in many languages. Then, probably all the things
already in the language that might be called "symbol" may be implemented
using the symbols in this proposal ... or maybe I don't see what you
mean here ?

> 
[...]
>>First, I think it would be best to have a syntax to represent
>>symbols.
> 
> 
> I disagree. Namespaces would be fine, and would also make clear which
> values were related to each other; e.g. for your "state of an object"
> use case, it's useful to have all the states in one namespace,
> separate from unrelated states of other classes of objects.
> 
> 
>>Adding some special char before the name is probably a good way to
>>achieve that : $open, $close, ... are $ymbols.
> 
> 
> Counterproposal:
> 
> FileState = SomeTypeDefiningStates( 'open', 'closed' )
> 
> thefile.state = FileState.open
> if thefile.state == FileState.closed:
> print "File is closed"
> 
> So all that's needed here is the type SomeTypeDefiningStates, not a
> new syntax.

The problem, IMHO, is that way you need to declare "symbols"
beforehands, that's what I was trying to avoid by requiring a new syntax.

>>One possible way to implement symbols is simply with integers
>>resolved as much as possible at compile time.
> 
> 
> I believe all your requirements and motivations could be met with an
> Enum type in the language. Here's an implementation using a sequence
> of integers for the underlying values:
> 
> "First Class Enums in Python"
> http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/413486>
> 
> An enumerated type would also allow values from that type to be
> compared with cmp() if their sequence was considered important. e.g.
> for object state, the "normal" sequence of states could be represented
> in the enumeration, and individual states compared to see if they are
> "later" that each other. If sequence was not considered important, of
> course, this feature would not get in the way.
> 

Well, I don't think enumarated objects ARE symbols. I can see two
"problems" :
 1 - in the implementation, trying to compare values from different
groups raises an error instead of simply returning "False" (easy to fix ...)
 2 - You have to declare these enumerable variables, which is not
pythonic IMO (impossible to fix ... needs complete redesign)

In the end, I really think symbols and enum are of different use, one of
the interest un symbols being to let the compiler does what he wants
(i.e. probably what is the most efficient).

Thanks for your reply,

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

Proposal for adding symbols within Python

[Pierre Barbier de Reuille]

Please, note that I am entirely open for every points on this proposal
(which I do not dare yet to call PEP).

Abstract


This proposal suggests to add symbols into Python.

Symbols are objects whose representation within the code is more
important than their actual value. Two symbols needs only to be
equally-comparable. Also, symbols need to be hashable to use as keys of
dictionary (symbols are immutable objects).

Motivations
===

Currently, there is no obvious way to define constants or states or
whatever would be best represented by symbols. Discussions on
comp.lang.python shows at least half a dozen way to replace symbols.

Some use cases for symbols are : state of an object (i.e. for a file
opened/closed/error) and unique objects (i.e. attributes names could be
represented as symbols).

Many languages propose symbols or obvious ways to define symbol-like
values. For examples in common languages:

In C/C++ : Symbols are emulated using Enums.
In Haskell/OCaml : Symbols are defined by union types with empty
constructors. Symbols are local to modules.
In Prolog : Symbols are called atoms ... they are local to modules (at
least in swi-prolog)
In Ruby : Symbols are introduced be the ":" notation. ":open" is a
symbol. Symbols are global.
In LISP : Symbols are introduced by "'". "'open" is a symbol. Symbols
are local to modules.

Proposal


First, I think it would be best to have a syntax to represent symbols.
Adding some special char before the name is probably a good way to
achieve that : $open, $close, ... are $ymbols.

On the range of symbols, I think they should be local to name space
(this point should be discussed as I see advantages and drawbacks for
both local and global symbols). For example, for the state of the file
object I would write :

>>> file.$open, file.$close, file.$error

Then, given some other objects (say some other device which also may be
opened) :

>>> assert f.state != dev.state

would always hold if both objects use locally-defined symbols. The only
way for these states to be equal would be, for example, for the device
object to explicitly assign the file symbols :

>>> dev.state = file.$open

By default, symbols should be local to the current module. Then, being
in the module "device_manager", this would hold:

>>> assert $opened == device_manager.$opened

There should be a way to go from strings to symbols and the other way
around. For that purpose, I propose:

>>> assert symbol("opened") == $opened
>>> assert str($opened) == "opened"

Implementation
==

One possible way to implement symbols is simply with integers resolved
as much as possible at compile time.

The End
===

Thanks to those who read entirely this proposal and I hope this proposal
will gather enough interests to become a PEP and someday be implemented,
maybe (probably?) in a completely different way ;)

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

Re: What do you use as symbols for Python ?

[Pierre Barbier de Reuille]

Well, thank you all !

I still feel it could be good for Python to have some kind of symbols
built in, and I will try to expose that to the python-dev list, to see
their reaction.

But in the different solutions proposed, the one I prefer is probably
the definitions of contants in a class to group them. Simple and
organized, I like it.

Thanks,

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

What do you use as symbols for Python ?

[Pierre Barbier de Reuille]

When you need some symbols in your program, what do you use in Python ?

For example, an object get a state. This state is more readable if
expressed as a symbols, for example "opened", "closed", "error".
Typically, in C or C++, I would use an enum for that:
enum OBJECT_STATE
{
  opened, closed, error
}

In CAML or Haskell I would use the union types:

type ObjectState = Opened | Closed | Error

In Ruby I would use the symbols :

object.state = :opened
object.state = :closed
object.state = :error

... but I don't know what to use in Python !

Thanks,

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

Re: "no variable or argument declarations are necessary."

[Pierre Barbier de Reuille]

Mike Meyer a écrit :
> Antoon Pardon <[EMAIL PROTECTED]> writes:
> 
>>Op 2005-10-03, Steven D'Aprano schreef <[EMAIL PROTECTED]>:
>>
>>>On Mon, 03 Oct 2005 13:58:33 +, Antoon Pardon wrote:
>>
>>Declarations also allow easier writable closures. Since the declaration
>>happens at a certain scope, the run time can easily find the correct
>>scope when a variable is rebound.
> 
> 
> If it happens at runtime, then you can do it without declarations:
> they're gone by then. Come to think of it, most functional languages -
> which are the languages that make the heaviest use of closures - don't
> require variable declarations.

Well, can you give a single example of such language ? Because all the
functionnal language I know but one do need variable declaration : lisp,
scheme, ocaml, haskell do need variable declaration ! Erlang do not ...

> 
> 
[...]
> 
> 
> Only in a few cases. Type inferencing is a well-understood
> technology, and will produce code as efficient as a statically type
> language in most cases.
> 

Type inferencing only works for statically typed languages AFAIK ! In a
dynamically typed languages, typing a variable is simply impossible as
any function may return a value of any type !

> 
>>I think language matters shouldn't be setlled by personal preferences.
> 
> 
> I have to agree with that. For whether or not a feature should be
> included, there should either be a solid reason dealing with the
> functionality of the language - meaning you should have a set of use
> cases showing what a feature enables in the language that couldn't be
> done at all, or could only be done clumsily, without the feature.

Wrong argument ... with that kind of things, you would just stick with
plain Turing machine ... every single computation can be done with it !

> 
> Except declarations don't add functionality to the language. They
> effect the programing process. And we have conflicting claims about
> whether that's a good effect or not, all apparently based on nothing
> solider than personal experience. Which means the arguments are just
> personal preferences.
> 

Well, so why not *allow* for variable declaration ? Languages like Perl
does that successfully ... you don't like : you don't do ! you like :
you do ! A simple option at the beginning of the file tell the compilor
if variable declaration is mandatory or not !

> Until someone does the research to provide hard evidence one way or
> another, that's all we've got to work with. Which means that languages
> should exist both with and with those features, and if one sides
> experiences generalize to the population at large, they alternative
> languages will die out. Which hasn't happened yet.
> 
> 
>>But we should decide what language features are usefull and which are
>>not by what some individual can or can't live without.
> 
> 
> Um - that's just personal preference (though I may have misparsed your
> sentence). What one person can't live without, another may not be able
> to live with. All that means is that they aren't likely to be happy
> with the same programming language. Which is fine - just as no
> programming language can do everything, no programming language can
> please everyone.
> 
> Antoon, at a guess I'd say that Python is the first time you've
> encountered a dynamnic language. Being "horrified" at not having
> variable declarations, which is a standard feature of such languages
> dating back to the 1950s, is one such indication.

Dynamic language and variable declaration are non-related issues ! You
can have statically-typed language without variable declaration (i.e.
BASIC) and dynamically-typed language with (i.e. Lisp) ! Please, when
you says something about languages, at least give 1 name of language
asserting what you're saying !

> Dynamic languages tend to express a much wider range of programming
> paradigms than languages that are designed to be statically
> compiled. Some of these paradigms do away with - or relegate to the
> level of "ugly performance hack" - features that someone only
> experienced with something like Pascal would consider
> essential. Assignment statements are a good example of that.

Well, could you be more specific once more ? I can't that many paradigm
only available on dynamically typed languages ... beside duck-typing
(which is basically a synonym for dynamically-typed)

> Given these kinds of differences, prior experience is *not* a valid
> reason for thinking that some difference must be wrong. Until you have
> experience with the language in question, you can't really decide that
> some feature being missing is intolerable. You're in the same position
> as the guy who told me that a language without a goto would be
> unusable based on his experience with old BASIC, FORTRAN IV and
> assembler.

After more than two years of Python programming, I still fill the need
for variable declarations. It would remove tons of bugs for little works
and would also clarify the scope of any single variable.

> P

Re: how to debug when "Segmentation fault"

[Pierre Barbier de Reuille]

Maksim Kasimov a écrit :
> 
> yes, to generete core dump is the best way,
> 
> but the command "$ ulimit -c 50" don't make python to generete core
> dump in the time of crush.
> 
> I would like to know how to run python script so if it crushes than core
> dump will be genereted.
> 
> Thanks
> 
> 

If it does not, that probably means the core file is larger ... try a
larger value or even "unlimited" :

$ ulimit -c unlimited

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

Re: how to debug when "Segmentation fault"

[Pierre Barbier de Reuille]

Maksim Kasimov a écrit :
> 
> Hello,
> 
> my programm sometime gives "Segmentation fault" message (no matter how
> long the programm had run (1 day or 2 weeks). And there is nothing in
> log-files that can points the problem.
> My question is how it possible to find out where is the problem in the
> code? Thanks for any help.
> 
> Python 2.2.3
> FreeBSD
> 

Well, your best bet is to generate a core file !
To do so, in the shell launching the program, you need to accept core
files. The command is :

$ ulimit -c 

For example:
$ ulimit -c 50

For a 500MB max file.

Then, if your program crash, you should see a file named "core."
where  is the PID of the process. You can know exactly where the
program crashed using gbd :

$ gdb --core=core.

Then, depending on the debug information you have in your executables
you may (or may not) be able to know what happened :)

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

Re: User-defined augmented assignment

[Pierre Barbier de Reuille]

Reinhold Birkenfeld a écrit :
> Pierre Barbier de Reuille wrote:
> 
> 
>>So, what I would suggest is to drop the user-defined augmented
>>assignment and to ensure this equivalence :
>>
>>a X= b <=> a = a X b
>>
>>with 'X' begin one of the operators.
> 
> 
> It can be done, but it's unnecessary for mutable objects like
> sets or lists. A new object must be created in these cases where
> one would suffice.

Well, my point is: the benefit is too small compared to the
disadvantage. If you really have a mutable (let say a list with +=) then
you do:

>>> a.extend(b)

and there is no interpretation error possible. BTW, that's what's done
in the standard library ...

Pierre

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

User-defined augmented assignment

[Pierre Barbier de Reuille]

Hello,

a discussion began on python-dev about this. It began by a bug report,
but is shifted and it now belongs to this discussion group.

The problem I find with augmented assignment is it's too complex, it's
badly explained, it's error-prone. And most of all, I don't see any
use-case for it !

The most common error is to consider that :

 a += b <==> a.__iadd__(b)

when the truth is :

 a += b <==> a = a.__iadd__(b)

which can be very confusing, as the two "a" are not necessarily the
same. It then leads to subtle errors like:

>>> class A(object):
>>>   a = 0

>>> a = A()
>>> b = A()
>>> a.a += 1
>>> A.a += 2
>>> print a.a
1
>>> print b.a
2

Also, the following behavior is pretty confusing :

>>> a = [1]
>>> b = [a]
>>> c = (a,)
>>> b[0] += [2] # Ok, no pb
>>> print a
[1,2]
>>> c[0] += [3]
Traceback (most recent call last):
  File "", line 1, in ?
TypeError: object doesn't support item assignment
>>> print a
[1,2,3]

Then, in the standard library, there is no use-case of user-defined
augmented assignment I could find. Of course, I find the augmented
assignement itself very useful ! I use it a lot with immutable objects
(strings, numbers, tuples, ...) but I tend to avoid it with mutables,
and so it seems in the standard library that uses extensively the
"extend" method of lists and very seldom the "+=" operator with lists.
And even where the "a+=b" is used, it could be replaced with either
"a.extend(b)" or "a = a+b" without bugs.

So, what I would suggest is to drop the user-defined augmented
assignment and to ensure this equivalence :

a X= b <=> a = a X b

with 'X' begin one of the operators.

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

Re: Parametric Polymorphism

[Pierre Barbier de Reuille]

Kay Schluehr a écrit :
> Catalin Marinas wrote:
> 
>>Hi,
>>
>>Sorry if this was previously discussed but it's something I miss in
>>Python. I get around this using isinstance() but it would be cleaner
>>to have separate functions with the same name but different argument
>>types. I think the idea gets quite close to the Lisp/CLOS
>>implementation of methods.
> 
> 
> Guido himself addressed multimethods in his Artima blog:
> 
> http://www.artima.com/weblogs/viewpost.jsp?thread=101605
> 
> See also the subsequent discussion about subtyping problems. 
> 
> Kay
> 

Well, as said in the comments, what he propose is *not* working !
You cannot look for the type of the argument using a dictionnary of
definition types, it just doesn't work because of polymorphism.

Now suppose you have two classes A and B, B subclassing A.
If you define :

@method(A)
def myfct(f):
  do_something_with_f

Then, you want it to work with any object of type B ... but with either
Guido's or this implementation, it won't ! The problem is much more
complex and cannot be solved in constant (or even linear) time. What I
read concerning Lisp is they use a cache to optimize method resolution.

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

Re: Brute force sudoku cracker

[Pierre Barbier de Reuille]

Tom Anderson a écrit :
> On Fri, 16 Sep 2005, Bas wrote:
> 
>> -any ideas how to easily incorporate advanced solving strategies?
>> solve(problem1) and solve(problem2) give solutions, but
>> solve(problem3) gets stuck...
> 
> 
> the only way to solve arbitrary sudoku problems is to guess.

Well, that's true, but most of the sudoku puzzles can be solved in
linear time ! And also having a linear time solving algorithm allows you
to really reduce the time used when you need backtracking.

BTW, the three given examples can be solved without backtracking.

I made one very recently (mmhh ... first complete version made
yesterday, still need a little bit of debug on the backtracking part),
and it's pretty quick (made in Ruby but well, I suppose timing are
similar), it never get stuck for long even if it fails, it fails quickly ...

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

Re: which is more 'pythonic' / 'better' ?

[Pierre Barbier de Reuille]

Will McGugan a écrit :
> gabor wrote:
> 
>> hi,
>>
>> there are 2 versions of a simple code.
>> which is preferred?
>>
>>
>> ===
>> if len(line) >= (n+1):
>> text = line[n]
>> else:
>> text = 'nothing'
>> ===
>>
>>
>> ===
>> try:
>> text = line[n]
>> except IndexError:
>> text = 'nothing'
>> ===
>>
>>
>> which is the one you would use?
> 
> 
> I would actualy use the following for this particular case..
> 
> text = line[n:n+1] or 'nothing'

... and you would get either a list of one element or a string ...
I think you wanted to write :

text = (line[n:n+1] or ['nothing'])[0]

However, I wouldn't use that because it is hard to read ... you have to
know Python in great detail to know that:

 1 - is the expressions "line[i:j]", i and j are replaced with
"len(line)" if they are greater than "len(line)"
 2 - so if n > len(line), then line[n:n+1]" == len[len(line):len(line)]
== []
(it is not evident that line[n:n+1] can give an empty list ...)
 3 - empty list evaluate to "False"
 4 - the "or" operator returns the first argument evaluating to "true"

So, in the end, you use 3 side-effects of Python in the same small
expression ... (1, 2 and 4)

> 
> But in general I think it is best to use exceptions like that only where
>  you expect the code to _not_ throw the exception the majority of times.
> Otherwise the simple condition is better. Although I expect there is not
> much difference either way..
> 
> 
> Will McGugan
> -- 
> http://www.kelpiesoft.com

What I would do is the following:
 - if this happen in a loop, I would, if possible, remove any test and
catch the exception outside the loop !
 - otherwise, I would go for the test, as it is more straitforward to read.

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

Re: GIL, threads and scheduling - performance cost

[Pierre Barbier de Reuille]

[EMAIL PROTECTED] a écrit :
> Merci Pierre,
> 
> Yes I agree and plan to move more to C/C++ and releasing the GIL when
> entering C/C++.
> 
> I also need to understand my original question re GIL and rescheduling.
> I fear that lock/unlock too often is also causing delays due to context
> switching.

Well, concerning GIL and rescheduling, releasing a lock is very likely
to induce rescheduling and context switch, but it won't if the system
considers it worthless. But this is true that lock/unlock has a cost and
so, doing it too much will slow down your app.

> 
> BTW do you have any hints/comments on SWIG/BOOST etc to glue PY and
> C/C++ ?

Well, for C I would recommand SWIG. For C++, I personnaly use
Boost.Python. However, you must know that SWIG did not support C++ well
when I had to choose between the two, so there was no question for me.
Then, somehow it depends on how you feel with the tools: SWIG depends on
a specific language and has its own tools while Boost is entirely
written in C++ and uses heavily templates. For performances, Boost
generate better code that SWIG, mainly because SWIG relies on Python
code that encapsulate the actual C functions while Boost does everything
in C++. Also, at least with G++, compiling Boost extension is very time-
and memory-consuming due to its heavy use of templates. As I don't use
SWIG, I don't know about the community, but at least for Boost.Python it
is quite active and questions on the mailing list are answered quickly
enough. Well, this is very quick but if you need more detailed
information, I recommend you to visit both websites.

> 
> 
> Alan
> 

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

Re: GIL, threads and scheduling - performance cost

[Pierre Barbier de Reuille]

[EMAIL PROTECTED] a écrit :
> Hi all,
> 
> Wondering if a GIL lock/unlock causes a re-schedule/contect swap when
> embedding Python in a multi-threaded C/C++ app on Unix ?
> 
> If so, do I have any control or influence on this re-scheduling ?
> 
> The app suffers from serious performance degradation (compared to pure
> c/C++) and high context switches that I suspect the GIL unlocking may
> be aggravating ?

Well, where do you observe this degradation ? When replacing part of the
C++ code by Python's code ? Or on C++ code running parallel to your
Python code ?

Because in the first case, well, this is just something natural ! Python
runtime overhead is much greater than C++ because of its dynamic nature
(it has to resolve all the symbols at runtime ...). And given the policy
for locking/releasing the GIL, I doubt it has serious performance issues
compared to the Python interpreter itself. If current performance is an
issue, consider implementing more in C/C++ ! This will be mainly true if
you currently have some heavy looping in Python. Python is very neat to
put together processor-intensive functions written in other languages,
but not to implement them. (as an exemple looh at that:
http://www.python.org/doc/essays/list2str.html )

> 
> Thanks for any help.
> 
> Alan
> 

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

Re: using common lisp with python.

[Pierre Barbier de Reuille]

[EMAIL PROTECTED] a écrit :
> is there a way to embed common lisp programs in python?
> 
It depends on what you call "embedding" ... can you be more specifiv
about what you want ?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: can I delete one of *.py *.pyc *.pyo in /usr/lib/python2.3 ?

[Pierre Barbier de Reuille]

Lucas Raab a écrit :
> Miernik wrote:
> 
[...]
> 
> You can delete any two of the three and you shouldn't run into any
> problems. However, the .py files are the source code and .pyc and .pyo
> are compiled Python files. The .pyc and .pyo files will load faster
> because they are compiled. Also, if you keep the .py files and then
> execute them, .pyc files will be generated. In short, I would keep the
> .pyc files and delete the others.
> 

As I said in my other post, if you ever run python using the "-O" and
have neither the .py nor the .pyo file, it won't load the module (even
if the .pyc is present ...)

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

Re: can I delete one of *.py *.pyc *.pyo in /usr/lib/python2.3 ?

[Pierre Barbier de Reuille]

Miernik a écrit :
> On my Debian GNU/Linux system I have Python 2.3 installed in
[...]
> 
> I noticed that all those files come in three "flavours":
> *.py *.pyc *.pyo
> 
> Is it possible that only one "flavour" of these files is needed, and I can
> delete the remaining two, any my Python installation will still work?

Well, I would greatly discourage that ! First, if you erase the *.py,
you won't be able to get detailed information on the traceback (like
actual code causing throwing the exception) as only the filename/line is
kept in the .pyc or .pyo. Then, if you erase the .pyo that means you
don't want to use the optimized version of the modules (why not ... but
it will be at the cost of performances). At last, if you keep only the
.pyo you won't be able to run programs without the optimization.

So let's summarize :
 1 - you keep only .py files: everything will work but Python will have
to recompile the modules everytime it's used first
 2 - you keep only .pyc files: two problems: first you won't be able to
launch Python with the "-O" option (i.e. optimize) because it will look
for .py or .pyo files, then if any exception is thrown in one of the
modules, you won't be able to use the very good pdb module with code
information and all.
 3 - you keep only .pyo files: similar to keeping only the .pyc files
but you won't be able to launch Python without the "-O" !

> 
> The whole /usr/lib/python2.3/ directory takes up over 15 MB, deleting
> two "flavours" would save about 10 MB on my system, and that would help
> me much as I am trying to fit my system on a 256 MB SD card, to make it
> quiet (hard disks are noisy).
> 
> Can I just do 
> cd /usr/lib/python2.3/ && rm -rf *.py && rm -rf *.pyc 
> for example, and everything will still work as before?
> 

Well, if you don't care about performances, the best to do is (using zsh
;) ):

cd /usr/lib/python2.3 && rm -f **/*.py{o,c}

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

Re: Multi Threading embedded python

[Pierre Barbier de Reuille]

Well, depends on what you want to achieve :)

First, I don't think you can call Py_Initialize on many threads. You
have special function to initialise different interpreters on per-thread
basis.

However, the main problem is: do you want to share data across your
threads ? If the answer is 'no' then use one interpreter by thread, this
is, by far, the simplest solution (and the most efficient ?).

But if you *do* need to share data, then you are in big trouble man :)
As far as I tried it, multi-threading and Python don't go along very
well ! At least, not with system-threads. Basically, to run some Python
code, you have to hold the GIL (Global Interpreter Lock) and you cannot
*test* it, you have to try holding it, so be prepare to block your
threads that would want to access Python !

What I would recommend (and that's what I do in my own software) is to
use a single thread in which your Python interpreter is running. Then,
use a message system in C++ to send commands and get them evaluated and
sent back (if needed). By doing so, you'll avoid a lot of problems, and
you won't loose significantly performances (or if you care about that,
then Python is definitly not the language you need) nor parrallelism
(you wouldn't be able to run many Python threads at the same time anyways).

Well, I hope that help,

Pierre

amit a écrit :
> Hello,
> 
> I am embedding a python script in a C++ application. The script can be
> called simultaneously from multiple threads.
> 
> What is the correct way to implement this situation:
> 
> 1) Have unique python interpreter instantiations ( Py_Initialize() ) for
> each thread.
> 
> 2) Have one python interpreter, and implement a lock on it so it can't
> be called simultaneously by multiple threads?
> 
> Thanks
>   Amit
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Pre-PEP: Dictionary accumulator methods

[Pierre Barbier de Reuille]

Ivan Van Laningham a écrit :
Hi All--
Maybe I'm not getting it, but I'd think a better name for count would be
add.  As in
d.add(key)
d.add(key,-1)
d.add(key,399)
etc.
>
[...]
There is no existing add() method for dictionaries.  Given the name
change, I'd like to see it.
Metta,
Ivan
I don't think "add" is a good name ... even if it doesn't exist in 
dictionnarie, it exists in sets and, IMHO, this would add confusion ...

Pierre

--
Ivan Van Laningham
God N Locomotive Works
http://www.pauahtun.org/
http://www.andi-holmes.com/
Army Signal Corps:  Cu Chi, Class of '70
Author:  Teach Yourself Python in 24 Hours
--
http://mail.python.org/mailman/listinfo/python-list

Re: GIL release

[Pierre Barbier de Reuille]

Do you mean in Python or in C ?
In C this is described in details in the documentation. In Python, I 
don't think there is a way ! If you want to do so you'll want to use a 
micro sleep ...

Pierre
Alastair Basden a écrit :
Hi,
Does anyone know whether there is a way for a python thread to release 
the global interpreter lock, and let all other threads have a chance at 
running before re-acquiring it?  Does the thread scheduling follow a 
round-robin method?

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

Re: parameter name conflict. How to solve?

[Pierre Barbier de Reuille]

Bo Peng a écrit :
Dear list,
If you ask: why do you choose these names? The answer is: they need to 
be conformable with other functions, parameter names.

I have a function that pretty much like:
def output(output=''):
  print output
and now in another function, I need to call output function, with again 
keyword parameter output

def func(output=''):
  output(output=output)
Naturally, I get 'str' object is not callable. Is there a way to tell 
func that the first output is actually a function? (like in C++, 
::output(output) )

Thanks.
Bo
What I'd suggest is :
def func(output=''):
  gobals()["output"](output=output)
that way, the function resolution is still dynamic, but you explicitly 
ask for a name global and not local ...

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

Re: python -i (interactive environment)

[Pierre Barbier de Reuille]

Very simple is you're on UNIX ...
You juste have to put at the beginnin of your file :
#!/usr/bin/python -i
And it juste does what you want :)
Pierre
Joe a écrit :
When you run "python -i scriptname.py" after the script completes you left 
at the interactive command prompt.

Is there a way to have this occur from a running program?
In other words can I just run scriptname.py (NOT python -i scriptname.py) 
and inside of scriptname.py I decide that I want to fall back to the 
interactive prompt?

I've searched and so far the only thing I've come up with is to use pdb, but 
that is not exactly the same as the interactive prompt.

Is there any way to do it that I have missed?
Thanks. 


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

Re: Controlling Pc From Server?

[Pierre Barbier de Reuille]

[EMAIL PROTECTED] a écrit :
Hello Kartic & NG,
 Thank you for your prompt answer. In effect, I'm trying to work on
a NT network of 6 PC (plus the server). Sorry to not have been clearer.
Ideally, I'm trying to monitor the Internet activity of each client (PC)
on this network (but I'm not a boss trying to control my emplyees, I'm just
curious on it). I would like to know which PC is connected to Internet (by
starting something like a "timer" for every PC, and then periodically check
if a particular PC is connected or not). This should be done from the main
server. 
Did I make myself clear? Do you think it would be a huge task?

Sorry, it may be a very basic question, but thank you for your help.
Andrea.

If what you want is to monitor internet requests, the best place to do 
so is the gateway of your network. If you don't have access to the 
gateway, you can always set your server as the gateway for your machines 
and your server will need to redirect the IP flux to the real gateway. 
That way, you don't need anything on the client side. On the server, 
just look at the fluxes toward the internet and you can do wathever you 
want with it. After that, as I don't know the windows implementation of 
a gateway, I can't help you ...

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

Re: is there a safe marshaler?

[Pierre Barbier de Reuille]

Irmen de Jong a écrit :
Pickle and marshal are not safe. They can do harmful
things if fed maliciously constructed data.
That is a pity, because marshal is fast.
I need a fast and safe (secure) marshaler.
Is xdrlib the only option?
I would expect that it is fast and safe because
it (the xdr spec) has been around for so long.
Or are there better options (perhaps 3rd party libraries)?
Thanks
Irmen.
What exactly do you mean by "safe" ? Do you want to ensure your objects 
cannot receive corrupted data ? Do you want to ensure no code will be 
evaluated during the unmarshalling ?

Please, be more precise,
Pierre
--
http://mail.python.org/mailman/listinfo/python-list

Re: convert list of tuples into several lists

[Pierre Barbier de Reuille]

Oliver Eichler a écrit :
Diez B. Roggisch wrote:

zip(*[(1,4),(2,5),(3,6)])
Thanks :) I knew it must be simple. The asterics - thing was new to me. 

By the way: What is faster?
this:
z = [(1,4),(2,5),(3,6)
a,b = zip(*[(x[0], x[0]-x[1]) for x in z])
or:
a = []
b = []
for x in z:
  a.append(x[0])
  b.append(x[0]-x[1])
I guess first, isn't it?
Oliver
Best answer is : try it :)
use the "timeit" module (in the standard lib) to do so ...
Pierre
--
http://mail.python.org/mailman/listinfo/python-list

Re: multi threading in multi processor (computer)

[Pierre Barbier de Reuille]

[EMAIL PROTECTED] a écrit :
Hello,
Is anyone has experiance in running python code to run multi thread
parallel in multi processor. Is it possible ?
Can python manage which cpu shoud do every thread?
Sincerely Yours,
Pujo
There's just no way you can use Python in a multi-processor environment, 
because the GIL (Global Interpreter Lock) will prevent two threads from 
running concurrently. When I saw this discussed, the Python developper 
were more into multi-process systems when it comes to multi-processors.
I think I even heard some discussion about efficient inter-process 
messaging system, but I can't remember where :o)

Hope it'll help.
Pierre
--
http://mail.python.org/mailman/listinfo/python-list

Re: IDLE history, Python IDE, and Interactive Python with Vim

[Pierre Barbier de Reuille]

Fuzzyman a écrit :
If you use IPython for your interactive mode stuff, you'll have a nice
history...
Regards,
Fuzzy
http://www.voidspace.org.uk/python/index.shtml
Best event : if your "EDITOR" system variable in "vim", using the "ed" 
command in ipython will bring "vim" with (eventually) the code you want 
to edit :)

Now, I wonder if you could embed ipython inside vim ...
Pierre
--
http://mail.python.org/mailman/listinfo/python-list

Re: Redirecting stdout/err under win32 platform

[Pierre Barbier de Reuille]

David Douard a écrit :
Alan,
I did search Google for this problem (not enough, thou).
In fact, I found some kind of solution (by myself, not that much on Google),
but it is not really satisfactory.
I have used win32 pipes to do so (win32api.CreatePipe). I can redirect
stdout/stderr to it from my python code (even redirecting the stdout/stderr
from my C lib). 
But I still have a problem with this solution (well, 2):
- it is *much* more complicated than any solution available on Unix like
systems (not really a problem, but),
- it not synchronous at all. And I'd like it to be so (or almost so).

David

AFAIK, there is no working bidirectionnal pipes on Windows ! The 
functions exists in order for them to claim being POSIX, but they're not 
working properly. Under Windows environment, I suppose you have to find 
your way using their buggy pipes (and by no means their "POSIX" pipes) 
or you have to use another inter-process communication protocol (DDE, 
COM, ...).

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

Re: Is this a contradiction in the docs ?

[Pierre Barbier de Reuille]

Fuzzyman a écrit :

Yes.. but that would mean that eval could only run code objects that
"consist[s] of a single expression".. which I doubt is the reality or
the intention.
Regards,
Fuzzyman
http://www.voidspace.org.uk/python/index.shtml
[Sorry, I deleted the commented lines because they were completely 
unreadable anyway]

It's exactly what eval is for : evaluate a single expression and return 
its result ! Try with strings : you can't even evaluate a statement ! 
You can only evaluate an expression !

And what would be the return result of a sequence of statement ?
If you want to execute a sequence, you want to use exec, not eval ...
Pierre
--
http://mail.python.org/mailman/listinfo/python-list

Re: type of simple object

[Pierre Barbier de Reuille]

Steve Holden a écrit :
Pierre Barbier de Reuille wrote:
[EMAIL PROTECTED] a écrit :
Thank you guys.
My function should multiply every element  of a list, for example
"something"
and "something" can be an integer or another list.
If it deals with integer than it is ok, but
If it deals with list than it become false for example list*2 =
listlist, and what I really want is to mutlitply its member.
That's why I need to know the type of my data in "something".

As stated by another comment, I would do something like :
def multiply(object, factor):
  try:
return [ multiply(i,factor) for i in object ]
  except TypeError:
return object*factor
This function will, recursively multiply a nested list of numbers by 
"factor" ...

As a matter of good practice it's usually considered unwise to shadow 
names of system types like "dict" and "object", though there wouldn't be 
any problems in this case except the infinite recursion. Which 
definitely *would* be a problem.
Oops ... indeed, I usually try not to do so ^_^
That's why I usually use "obj" more than "object" and that most of the 
time I use a name more _on the topic_ ...

Thx for the correction :)
Pierre
regards
 Steve
--
http://mail.python.org/mailman/listinfo/python-list

Re: Is this a contradiction in the docs ?

[Pierre Barbier de Reuille]

Fuzzyman a écrit :
The following two passages from the python documentation *appear* to
contradict each other. Equally possible (or more likely !) is that I
misunderstand it :
eval :
This function can also be used to execute arbitrary code objects (such
as those created by compile()). In this case pass a code object instead
of a string. The code object must have been compiled passing 'eval' as
the kind argument.
compile:
The kind argument specifies what kind of code must be compiled; it can
be 'exec' if string consists of a sequence of statements, 'eval' if it
consists of a single expression, or 'single' if it consists of a single
interactive statement (in the latter case, expression statements that
evaluate to something else than None will be printed).
The docs for compile say that if you are creating a code object from a
sequence of statements you must use the kind argument 'exec'. Eval says
that if you are using the eval function you must use 'eval' as your
kind argument.
In practise I have found that using the eval function with code objects
compiled with 'exec' as the kind argument works fine. Is this a 'bug'
in the docs ?
Regards,
Fuzzy
http://www.voidspace.org.uk/python/index.shtml
IMO, it's just logical the code sent to "eval" was compiled with "eval" 
as the kind argument. But don't forget the documentation is kind of 
"abstract" and that CPython is _just_ an implementation (ok, it's the 
reference implementation) of python. You'd better follow the doc if you 
want your code to work on other Python implementation (ie. JPython, ...).

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

Re: type of simple object

[Pierre Barbier de Reuille]

[EMAIL PROTECTED] a écrit :
Thank you guys.
My function should multiply every element  of a list, for example
"something"
and "something" can be an integer or another list.
If it deals with integer than it is ok, but
If it deals with list than it become false for example list*2 =
listlist, and what I really want is to mutlitply its member.
That's why I need to know the type of my data in "something".
As stated by another comment, I would do something like :
def multiply(object, factor):
  try:
return [ multiply(i,factor) for i in object ]
  except TypeError:
return object*factor
This function will, recursively multiply a nested list of numbers by 
"factor" ...

By the way I am new in python, I heard that it has a MatLab
capabilities, How good is that? Since It would be very nice when we can
do what MatLab do in python.
I think you are referring to the Numeric or the numarray modules. They 
offer matric computations close to chat Matlab offers. "numarray" is the 
newer version of "Numeric", but in case of small matrix, it performs 
slower (for various reasons). Then, you can find lots of information on 
the net concerning these two modules.


Sincerely Yours,
pujo
Pierre
--
http://mail.python.org/mailman/listinfo/python-list

Re: Help with Threading

[Pierre Barbier de Reuille]

Philip Smith a écrit :
Hi
I am fairly new to Python threading and my needs are simple(!)
I want to establish a number of threads each of which work on the same 
computationally intensive problem in different ways.

I am using the thread module rather than the threading module.
My problem is I can't see how (when one thread completes) to ensure that the 
other threads terminate immediately.

Appreciate some simple advice
Phil 


With Python's threads, you have to handle this kindd a feature yourself. 
For example, you can create a single object containing a boolean set to 
False by default. When one of your algorithm finishes, the boolean is 
set to True. All your algorithm should regularly test this boolean and 
exit if it is True ! Note that the boolean has to be inside another 
object because Boolean types is not mutable. Now, if you really want to 
be able to "kill" your threads, you will need another thread interface. 
For example, Qt threads allows that ... and WxPython offers you some 
functions to do exactly what I described.

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

Re: map in Python

[Pierre Barbier de Reuille]

You have three ways to do what you want :
First wayt is to use lambda. Then, you want to write :
>>> map(lambda x: re.sub("[a-z]", "", x), test)
Second is to use regular named function :
>>> def remove_letters( s ):
...   re.sub("[a-z]", "", s)
>>> map(remove_letters, test)
A third way would be to use the "pseudo-currying" described there : 
http://www.python.org/moin/PythonDecoratorLibrary

In fact, you need a small generalisation :
>>> class curried(object):
...   def __init__(self, func, *a, **kw):
... self.func = func
... self.args = a
... self.kwords = kw
...   def __call__(self, *a, **kw):
... args = self.args + a
... kwords = dict(self.kwords)
... kwords.update(kw)
... if len(args)+len(kwords) < self.func.func_code.co_argcount:
...   return curried(self.func, *args, **kwords)
... else:
...   return self.func(*args, **kwords)
The difference is you can handle the kwords with that version !
Then you want to write this :
>>> curried_sub = curried(re.sub)
>>> map(curried_sub("[a-z]", "", count=0), test)
My opinion is : the simplest and best solution more "pythonic" is the 
second one ! The third one is interesting but work only for functions 
written in Python ! (Hopefully the re.sub function is written in 
Python). The biggest problem with the first one is that lambda are 
planned to disappear in future Python versions ...

Pierre
Stu a écrit :
I have recently switched over to Python from Perl. I want to do
something like this in Python:
@test = ("a1", "a2", "a3");
map {s/[a-z]//g} @test;
print @test;
However, I take it there is no equivalent to $_ in Python. But in that
case how does map pass the elements of a sequence to a function? I
tried the following, but it doesn't work because the interpreter
complains about a missing third argument to re.sub.
import re
test = ["a1", "a2", "a3"]
map(re.sub("[a-z]", ""), test)
print test
Thanks in advance.
Regards,
Stuart 
--
http://mail.python.org/mailman/listinfo/python-list

Re: extension module, thread safety?

[Pierre Barbier de Reuille]

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

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

Re: extension module, thread safety?

[Pierre Barbier de Reuille]

Nick Coghlan a écrit :
The Python 2.4 docs claim the functions were added in Python 2.3, even 
though they aren't documented in the 2.3.4 docs.

The 2.3 release PEP (PEP 283) confirms that PEP 311 (which added these 
functions) went in.
Indeed, I just tested it and now it works fine :) Thanks a lot :)
Cheers,
Nick.
--
http://mail.python.org/mailman/listinfo/python-list

Re: extension module, thread safety?

[Pierre Barbier de Reuille]

Nick Coghlan a écrit :
Pierre Barbier de Reuille wrote:
With the current CPython, it's very hard to mix Python and C in a 
multithreading application (with C-threads, not Python-threads). In 
fact I never really succeeded in that task because of that GIL ! I 
have a multi-thread application but every bit of Python code must be 
run into a Python thread. To be more precise, I wanted to be able to 
call Python code in response to some GUI events, and I didn't want to 
instanciate a new interpreter for I wanted to be able to access the 
environment of my main Python interpreter.

I don't understand. This is what PyGILState_Ensure and 
PyGILState_Release are for - so C code can leave the GIL unlocked by 
default, and only grab it when they want to call into the C/Python API.

Regards,
Nick.
Ok, I wondered why I didn't know these functions, but they are new to 
Python 2.4 ( and I didn't take the time to look closely at Python 2.4 as 
some modules I'm working with are still not available for Python 2.4). 
But if it really allows to call Python code outside a Python thread ... 
then I'll surely use that as soon as I can use Python 2.4 :) Thanks for 
the hint :)

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

Re: extension module, thread safety?

[Pierre Barbier de Reuille]

David Bolen a écrit :
If the threads under discussion are all Python threads, then by
default yes, the extension module C functions will appear to be atomic
from the perspective of the Python code.  When the Python code calls
into the extension module, the GIL (global interpreter lock) is still
being held.  Unless the extension module code explicitly releases the
GIL, no other Python threads can execute (even though those threads
are in fact implemented as native platform threads).
Indeed, there is this (so annoying) GIL ... is there any project about 
extracting the (few ?) critical points of the python interpreter to put 
locks around them instead of choosing the opposite strategy (ie. locking 
anythime but when we know the section is not critical) ? Because it 
would made embedding a python interpreter in another language much more 
easy !

With the current CPython, it's very hard to mix Python and C in a 
multithreading application (with C-threads, not Python-threads). In fact 
I never really succeeded in that task because of that GIL ! I have a 
multi-thread application but every bit of Python code must be run into a 
Python thread. To be more precise, I wanted to be able to call Python 
code in response to some GUI events, and I didn't want to instanciate a 
new interpreter for I wanted to be able to access the environment of my 
main Python interpreter.

By the way, if someone succeeded in a similar task, I'll be happy to 
hear about it :)

Pierre
PS: if the main code is in C (in fact C++ ...) and not Python it's for 
historical reasons of course ;)
--
http://mail.python.org/mailman/listinfo/python-list

Re: Unclear On Class Variables

[Pierre Barbier de Reuille]

Pierre Barbier de Reuille a écrit :
Antoon Pardon a écrit :
Well I find this a confusing behaviour on python's part. The fact
that instance.field can mean something different, depending on
where in a statement you find it, makes the behaviour inconsistent.
I know people in general here are against declarations, but declarations
could IMO provide more consistency here and thus more obvious behaviour.

Well just to show how confusing python can be, the following piece of
code.
| class Spam:
|   eggs = [2, 3]
| | | sp1 = Spam()
| sp2 = Spam()
| | print sp1.eggs, id(sp1.eggs)
| print sp2.eggs, id(sp2.eggs)
| print ''
| | sp1.eggs += [4,]
|
| print sp1.eggs, id(sp1.eggs)
| print sp2.eggs, id(sp2.eggs)
| print ''
|
| Spam.eggs = [3,5]
|
| print sp1.eggs, id(sp1.eggs)
| print sp2.eggs, id(sp2.eggs)
| print ''
Which produces:
[2, 3] 1075958860
[2, 3] 1075958860

[2, 3, 4] 1075958860
[2, 3, 4] 1075958860

[2, 3, 4] 1075958860
[3, 5] 1075959084

Well ... and could someone explain this behaviour ?
I don't catch it !
Pierre
Ok, I think I got it ! I speak with friends working with Python too ...
It seems that "a += l" if "a" and "l" are lists is equivalent to :
a.extend(l)
a = a
The second line could seem meaningless but it is not ! Indeed, in the 
example above, the first "sp1.eggs" (the one with the extend) is a class 
variable but, the second "sp1.eggs" (the one before the "=") is an 
instance variable !

So, at the end, we append to get sp1.eggs and Spam.eggs references to 
the same structure. But sp1.eggs is an instance variable of sp1 and no 
more the class variable. To test that, it's possible to modify slightly 
the code with :

|sp1.eggs += [4,]
|del sp1.eggs
Then, sp1.eggs still exists !!! But it's again the class variable ...
Ok, back to the documentation ...
In the doc, there is a special case for the use of "+=" with the class 
members. IMHO, this should not be !!! But, it says that :

ob.a += b
is translated into :
ob.__setattr__( "a", ob.__getattr__("a").__iadd__(b) )
My opinion is : it would be much more simpler to explain than :
a += b <=> a.__iadd__(b); a = a
and not give any special case for class members. In both cases, the 
resulting behaviour is the same, but it would be less confusing.

Then, this change of scope of variables in python is very very annoying. 
Both for new and old programmers (we have both in my lab ...).

Well, I hope I got it write this time ... but this is a feature to fear !!!
Pierre
--
http://mail.python.org/mailman/listinfo/python-list

Re: Unclear On Class Variables

[Pierre Barbier de Reuille]

Antoon Pardon a écrit :
Well I find this a confusing behaviour on python's part. The fact
that instance.field can mean something different, depending on
where in a statement you find it, makes the behaviour inconsistent.
I know people in general here are against declarations, but declarations
could IMO provide more consistency here and thus more obvious behaviour.

Well just to show how confusing python can be, the following piece of
code.
| class Spam:
|   eggs = [2, 3]
| 
| 
| sp1 = Spam()
| sp2 = Spam()
| 
| print sp1.eggs, id(sp1.eggs)
| print sp2.eggs, id(sp2.eggs)
| print ''
| 
| sp1.eggs += [4,]
|
| print sp1.eggs, id(sp1.eggs)
| print sp2.eggs, id(sp2.eggs)
| print ''
|
| Spam.eggs = [3,5]
|
| print sp1.eggs, id(sp1.eggs)
| print sp2.eggs, id(sp2.eggs)
| print ''

Which produces:
[2, 3] 1075958860
[2, 3] 1075958860

[2, 3, 4] 1075958860
[2, 3, 4] 1075958860

[2, 3, 4] 1075958860
[3, 5] 1075959084

Well ... and could someone explain this behaviour ?
I don't catch it !
Pierre
--
http://mail.python.org/mailman/listinfo/python-list

Re: how to visualize symbol table?

[Pierre Barbier de Reuille]

Thomas Korimort a écrit :
Hi,
how can i visualize the content of the symbol table in Python?
Sometimes i want to know which symbols are imported from apackage and 
such kind of things

Greetings, THomas Korimort
Do you mean something like :
dir(module)
???
Pierre
--
http://mail.python.org/mailman/listinfo/python-list

Re: Suggestion for "syntax error": ++i, --i

[Pierre Barbier de Reuille]

Christian Ergh a écrit :
Hmm, i never liked the i++ syntax, because there is a value asignment 
behind it and it does not show - except the case you are already used to 
it.

 >>> i = 1
 >>> i +=1
 >>> i
2
I like this one better, because you see the assignment at once, it is 
easy to read and inuitive usability is given - in my opinion.
Chris

IMO, there is an assignement only for languages like python ! (ie. 
reference languages)

In languages like C or C++ (in which variables correspond to values) it 
makes perfect sens to modify the current value by an operator.

Nevertheless, I agree with you concerning Python ! But not for C++ :)
Pierre
--
http://mail.python.org/mailman/listinfo/python-list

Re: Qt String Question

[Pierre Barbier de Reuille]

Michael McGarry wrote:
Michael McGarry wrote:
Hi,
How do I convert from a qt.QString to a Python string?
Michael
Apparently the ascii() method of QString does this. (I answered my own 
question).

sorry for wasting newsgroup space.
Depending on the kind of string you have, latin1() may be a better 
solution ...
--
http://mail.python.org/mailman/listinfo/python-list

Re: Semaphore or what should I use?

[Pierre Barbier de Reuille]

Sergei Organov a ecrit :
Pierre Barbier de Reuille <[EMAIL PROTECTED]> writes:

Ville Vainio a ecrit :
"Bastian" == Bastian Hammer <[EMAIL PROTECTED]> writes:
   Bastian> Now I have to make sure, that both threads are

   Bastian> synchronal, 1 thread edits something and the other is
   Bastian> blocked until the first thread is ready.
   Bastian> Isn't it a good idea to do this with a semaphore?

Semaphore will do, but this is a classical use case for
threading.Lock.
There should be lots of stuff regarding locks (or more googleably,
"mutexes") on the net.

I don't agree. Mutexes (or locks) are best suited for critical sections (ie.
sections that cannot be run by many thread at the same time).

Please don't add even more confusion to the issue. Mutex conceptually is
designed to be used for MUTual EXclusion of access to a resource (e.g.,
a peace of data). While critical section could be implemented using
mutex, the mutex itself is more general concept. Besides, the rule of
thumb using mutexes is: "protect data, not program code."
My answer to OP's question is: use either lock (mutex) or semaphore.
I'd probably use semaphore as mutexes are usually optimized for the case
when contention probability is low (i.e., they usually shouldn't be locked
for a long time).
My point is : semaphore is more complex than what he needs. Event are 
simpler and just do what he needs : block one thread until another one 
finished some jobs and launchs the event (have a look at my example).

Afterward, I agree that the concept of mutex is the most general : you 
can implement every other kind of lock using just mutexes.

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

Re: Semaphore or what should I use?

[Pierre Barbier de Reuille]

Ville Vainio a écrit :
"Bastian" == Bastian Hammer <[EMAIL PROTECTED]> writes:

Bastian> Now I have to make sure, that both threads are
Bastian> synchronal, 1 thread edits something and the other is
Bastian> blocked until the first thread is ready.
Bastian> Isn´t it a good idea to do this with a semaphore?
Semaphore will do, but this is a classical use case for
threading.Lock.
There should be lots of stuff regarding locks (or more googleably,
"mutexes") on the net.
I don't agree. Mutexes (or locks) are best suited for critical sections 
(ie. sections that cannot be run by many thread at the same time). The 
kind of synchonisation Bastian want is not really semaphore either but 
more event. This python "Event" object is described in the section 7.5.5 
of the documentation of Python 2.3. There is no example, but I think 
Event are quite strait forward : you creates it, then some thread block, 
waiting the event to occure while some other thread execute until it set 
the event, allowing the blocked thread to go on its own execution :)

Here a small working example :
***8<8<***8<**
import threading, time
class MyThread(threading.Thread):
  def __init__(self):
threading.Thread.__init__(self)
self._event = threading.Event()
self._exit = False
  def run(self):
while 1:
  print "Waiting for an event to continue"
  self._event.wait()
  print "Ok, the thread is unblocked now :)"
  if self._exit:
return
  self._event.clear()
  def unblock(self):
self._event.set()
  def exit(self):
self._exit = True
self.unblock()
t = MyThread()
t.start()
time.sleep(1)
t.unblock()
time.sleep(1)
t.unblock()
time.sleep(1)
t.exit()
***8<8<***8<**
Pierre
--
http://mail.python.org/mailman/listinfo/python-list

Re: non blocking read()

[Pierre Barbier de Reuille]

Steve Holden a écrit :
Donn Cave wrote:
In article <[EMAIL PROTECTED]>,
 Gustavo Córdova Avila <[EMAIL PROTECTED]> wrote:

David Bolen wrote:

Jp Calderone <[EMAIL PROTECTED]> writes:

  def nonBlockingReadAll(fileObj):
  bytes = []
  while True:
  b = fileObj.read(1024)
  bytes.append(b)
  if len(b) < 1024:
  break
  return ''.join(bytes)
Wouldn't this still block if the input just happened to end at a
multiple of the read size (1024)?
-- David
No, it'll read up to 1024 bytes or as much as it can, and
then return an apropriatly sized string.

Depends.  I don't believe the original post mentioned
that the file is a pipe, socket or similar, but it's

It did actually specifically mention files.
Read more carrefully and you'll see that it mentionned "file object" and 
, on UNIX systems, that's very different than "file". It even mentions 
"stdin", and stdin (though not always a pipe) always bahaves like a pipe 
when it comes to non-blocking reading.

For an answer, you can modify stdin (or whatever file desciptor you 
have) to have non-blocking reading operations. It can be done using :

*
import fcntl, os
fcntl.fcntl(0, fcntl.F_SETFL, os.O_NONBLOCK)
*
You can replace the "0" by whatever file descriptor you want of course !
After that call stdin is non-blocking.
Pierre
--
http://mail.python.org/mailman/listinfo/python-list

Re: documentation for PyArg_ParseTupleAndKeywords

[Pierre Barbier de Reuille]

Steven Bethard a écrit :
I'm just starting to play around with the Python source.  (Specifically, 
I'm looking at adding a key argument to max/min like sorted has.)  Can 
anyone direct me to the documentation on how 
PyArg_ParseTupleAndKeywords, etc. work?  In particular, I can't figure 
out how the format arg to vgetargskeywords should be specified...

Thanks,
Steve
You have a good documentation about that on the web site ... look at 
"Python/C API" and "Extending and Embedding". The second one is more a 
tutorial when the first one is more a reference. But everything is 
explained there !

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