Re: operator module isSequenceType with builtin set produces False
On 19 Dec, 05:24, Gabriel Genellina [EMAIL PROTECTED] wrote: En Tue, 18 Dec 2007 09:15:12 -0300, English, Mark [EMAIL PROTECTED] escribió: try: set except NameError: from sets import Set as set class myset_fails(set): pass class myset_works(set): def __getitem__(self): pass s = set() fails = myset_fails() works = myset_works() import operator operator.isSequenceType(s) #Not what I expected False operator.isSequenceType(fails) #Not what I expected either False operator.isSequenceType(works) #A hint at what isSequenceType does ? True Are sets not sequences ? I didn't think the isSequenceDisclaimer gave false negatives. No, sets aren't sequences, as they have no order. Same as dicts, which aren't sequences either. Oops. I was under the misapprehension that they were sequences in that they were sequential but of unknown ordering e.g. for x in set([someobject, someotherobject, ...]) always iterates in the same order Anywho, now I know. Thanks. Is there a short Pythonic way to determine whether an object is iterable (iteratable ??) that I haven't thought of (getattr(obj, '__iter__') ?). Would operator.isIterable() be at all a useful addition ? (And what did I do wrong when I posted my original post that I can't see it in groups.google) -- http://mail.python.org/mailman/listinfo/python-list
Re: operator module isSequenceType with builtin set produces False
On 19 Dec, 10:03, MarkE [EMAIL PROTECTED] wrote: No, sets aren't sequences, as they have no order. Same as dicts, which aren't sequences either. Oops. I was under the misapprehension that they were sequences I realise now that this is even explicitly documented: http://docs.python.org/lib/typesseq.html There are six sequence types: strings, Unicode strings, lists, tuples, buffers, and xrange objects. Is there a short Pythonic way to determine whether an object is iterable (iteratable ??) that I haven't thought of (getattr(obj, '__iter__') ?). Would operator.isIterable() be at all a useful addition ? And here I probably meant container (although the url says sequence when the article meant container, bit like me): http://docs.python.org/ref/sequence-types.html Containers usually are sequences (such as lists or tuples) or mappings (like dictionaries), but can represent other containers as well So same question, but perhaps isContainer() rather than isIterable() -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Class Best Practice
On 4 Dec, 23:18, Rod Person [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I've been doing python programming for about 2 years as a hobby and now I'm finally able to use it at work in an enterprise environment. Since I will be creating the base classes and libraries I wondering which why is consider best when creating python classes: 1: class Foo(object): member1='' member2=0 def __init__(self,member1='',member2=0): self.member1 = member1 self.member2 = member2 2: class Foo(object): def __init(self,member1='',member2=0): self.member1 = member1 self.member2 = member2 Don't forget to call the base class __init__ function -- http://mail.python.org/mailman/listinfo/python-list
Re: Python is not a good name, should rename to Athon
Ithon -- http://mail.python.org/mailman/listinfo/python-list
Re: Global variables within classes.
Kevac Marko [EMAIL PROTECTED] writes:
When changing default value, is there any way to change class
attribute and all referenced attributes too?
class M:
name = uMarko
a, b = M(), M()
a.name = uKevac
print M.name, a.name, b.name
- Marko Kevac Marko
Is there any way to get here - Kevac Kevac Kevac ?
Or what is the right way of keeping global variables in classes?
I suppose this works, but I agree with Hrvoje Niksic that you're
fighting the language, since by forcing such low level features to
behave differently you're going to end up confusing potentially
yourself, and definitely other Python programmers in the long term.
I've probably skipped lots of edge cases which will catch you out in
exciting, fun ways but other than that good luck...
import types
class Meta(type):
def __new__(metacls, name, bases, dictionary):
newClass = super(Meta, metacls).__new__(metacls, name, bases,
dictionary)
def getInstanceAttribute(self, key):
typeSelf = type(self)
if not key.startswith('__'): #If normal key
try: #To get from class
return getattr(typeSelf, key)
except AttributeError: #Not in class
#Get from instance
return super(typeSelf, self).__getattribute__(key)
else: #Else special key
#Get from instance
return super(typeSelf, self).__getattribute__(key)
newClass.__getattribute__ =
types.MethodType(getInstanceAttribute,
None,
newClass)
def setInstanceAttribute(self, key, val):
typeSelf = type(self)
if not key.startswith('__'): #If normal key
if hasattr(typeSelf, key): #If in class
return setattr(typeSelf, key, val)
else: #Else not in class
#Set in instance
return super(typeSelf, self).__setattr__(key, val)
else: #Else special key
return super(typeSelf, self).__setattr__(key, val)
newClass.__setattr__ = types.MethodType(setInstanceAttribute,
None,
newClass)
return newClass
class M(object):
__metaclass__ = Meta
name = uMarko
a, b = M(), M()
a.name = uKevac
print M.name, a.name, b.name
--
http://mail.python.org/mailman/listinfo/python-list
Handling exception thrown by Boost.Python c-extension in Python code
I'm just getting started on Boost Python and may have missed this obvious looking problem somewhere. Given a c-extension testext written using Boost Python containing a base class Base, a derived class Derived, and a function doSomething which expects a Derived parameter, if I pass it a Base parameter an exception is thrown. This is a Boost.Python.ArgumentError. My question is how do I catch this error ? I tried the following bit of investigation: #Start code import testext b = testext.Base() try: testext.doSomething(b) except Exception, e: pass help(e.__class__) #End code which produces #Start output Help on class ArgumentError: class ArgumentError(exceptions.TypeError) | Method resolution order: | ArgumentError | exceptions.TypeError | exceptions.StandardError | exceptions.Exception | | Methods inherited from exceptions.Exception: | | __getitem__(...) | | __init__(...) | | __str__(...) #End output print e produces Boost.Python.ArgumentError instance So I could handle this by writing an except clause for TypeError. Boost.Python doesn't exist as a module i.e. it's not in sys.modules, and I don't know how to import it - should there be a Boost.Python module somewhere on my PythonPath that I've forgotten to setup ? Is there a standard way of catching these errors by their actual type ? Is there an easy way to export the exception classes from my c- extension (testext) so that I can use that ? Thus except testext.ArgumentError would catch the Boost.Python.ArgumentError ? Thanks for any help, Mark -- http://mail.python.org/mailman/listinfo/python-list
Re: Windows command line problem
I'm using getopt. I doubt getopt recognises \x96 as a command line parameter prefix. I suppose I could iterate over sys.argv doing a replace but that seems messy. I'd rather understand the problem. That said, and me not understanding code pages that much, I chcp'd the machines it works on both coming back with 850, chcp'd the machine it wasn't working on which also came back with 850, but then again the machine where it wasn't working now works. So now it's an intermittent bug. Great. I'll try messing with code pages later and report back if I get anywhere. I need more coffee before I can do anything remotely clever. Damn you windows and your lack of a need for coffee -- http://mail.python.org/mailman/listinfo/python-list
Re: Windows command line problem
This was discovered after consultation with a colleague who shall
remain nameless but, well, nailed it basically.
The answer appears to be:
An example command line for running the script was written in a word
document. The Autocorrect (sic) feature in word replaces a normal
dash at least as I know it with the character Jeff Epler showed above,
u'\N{en dash}' which is a nice big long dash in the Arial font.
If you cut and paste that onto the command line, bad things can happen
although when I do this on my machine I actually get a u with an ^
on top. For whatever reason it must have looked ok on my colleagues
machine (or possibly this isn't the answer but I seriously doubt that)
and when he ran the Python script things went awry.
Thanks Jeff (and nameless colleague). And beware Word autocorrection.
--
http://mail.python.org/mailman/listinfo/python-list
Windows command line problem
I'm sure someone else has posted a similar problem but I can't find it, nor the solution... I have a python script which accepts a command line argument. E.g. python.exe myscript.py -n Foo I build this as part of a package using distutils with the bdist_wininst option on a Windows 2K (SP4) machine. I have tested installing and running it fine on a Windows XP (SP2) machine. I build my package-installer with a Python.org 2.4.1 distribution which is source-compiled locally. I have installed my package-installer on a machine running ActiveState Python 2.4.1 installed from a .msi file. That all works fine. I have problems delivering it to the test team (of course). After some investigation, if I install the package on one of our test machines and butcher my installed file to dump the command line and exit (i.e. print 'hi', sys.argv) then I get the following: hi ['c:\\Python24\\Lib\\site-packages\\MyPackage\\myscript.py', '\x96n, 'Foo'] If I run it specifying --name instead of -n I get: hi ['c:\\Python24\\Lib\\site-packages\\MyPackage\\myscript.py', '\x96-name, 'Foo'] The machine in question is also running XP service pack 2 as far as I know, with Python.org's 2.4.1 distribution. Does anyone know why the first character on the command line (here '-') is getting adjusted (to '\x96') in this way ? Is it a Unicode/encodings kind of a problem ? I can make the problem go away by running with quotes like this: python.exe myscript.py -n Foo I'm hoping I can add an entry to my setup.py. Thanks for any and all help. Mark -- http://mail.python.org/mailman/listinfo/python-list
