Re: Can I make sqlite3 or shelve work reliably on any Win/Linux/Mac?
On Mon, 22 Feb 2010 09:10:38 -0800, Alex Quinn wrote:
> Is there a way to have some kind of database (i.e. sqlite3, bsddb, dbm,
> etc.) that works out of the box on any Win/Linux/Mac machine with Python
> 2.6+ or 3.x? It's okay if the file format is different between machines,
> but I want my script to work without having to install anything.
>
> Problems with current modules:
>
> * Shelve used to do this. Unfortunately, since bsddb was
> deprecated/removed from the standard distro and Windows doesn't have dbm
> or gdbm, the only remaining option on Windows is dumbdbm, which is
> discouraged in the docs.
>
> * Sqlite3 should fill the void now. However, in my experience, nearly
> every Linux Python install I encounter has a broken sqlite3 module
> ("ImportError: No module named _sqlite3"). It's a well-documented issue,
> but it the solution generally requires root access, which I don't have
> on these servers.
>
> Potential solutions:
>
> * Could I somehow bundle with my project the _sqlite3.so file and/or
> whatever else it needs? Or is there an alternate sqlite3 module I could
> use as a fallback that would just interface with the sqlite3 executable
> on the machine (i.e. /usr/local/bin/sqlite3)?
>
> * Is there a way to drop bsddb into my project so it works out of the
> gate (no install) on either Linux, Windows, or Mac?
>
> If you have any ideas, I'd be most appreciative. My objective here is
> just to find a portable and reliable solution that I can use for small
> projects.
>
> Thanks,
> Alex
Hi,
I'm speaking with little experience here, but one thought I had is to try
compiling Pysqlite ( http://pypi.python.org/pypi/pysqlite/2.5.6 ) for
each of your target OS's, probably using GCC cross compilers for the
platforms you aren't compiling on, then sort of "splice" them together so
that _sqlite3 always points to the binary for the current OS.
This snippet might help you get started:
import sys
# Linux binary
if 'linux' in sys.platform.lower():
import _sqlite3_linux as _sqlite3
# Windows binary
elif 'win32' == sys.platform:
import _sqlite3_windows as _sqlite3
# Mac binary
elif 'darwin' == sys.platform:
import _sqlite3_mac as _sqlite3
sys.modules['_sqlite3'] = _sqlite3
I'm not exactly sure when you would run this code. It would have to be
sometime before you import the main sqlite3 module.
--
Brad Harms -- http://alphaios.net
--
http://mail.python.org/mailman/listinfo/python-list
Re: KeyboardInterrupt
On Thu, 10 Dec 2009 00:29:45 +, mattia wrote: > Il Wed, 09 Dec 2009 16:19:24 -0800, Jon Clements ha scritto: > >> On Dec 9, 11:53 pm, mattia wrote: >>> Hi all, can you provide me a simple code snippet to interrupt the >>> execution of my program catching the KeyboardInterrupt signal? >>> >>> Thanks, >>> Mattia >> >> Errr, normally you can just catch the KeyboardInterrupt exception -- is >> that what you mean? >> >> Jon. > > Ouch, so the simplest solution is just insert in the 'main' function a > try/catch? I believed there was the necessity to create a signal and > than attach the KeyboardInterrupt to it... KeyboardInterrupt is just an exception that gets raised when CTLR+C (or the OS's equivalent keyboard combo) gets pressed. It can occur at any point in a script since you never know when the user will press it, which is why you put the try: except KeyboardInterrupt: around as much of your script as possible. The signal that the OS sends to the Python interpreter is irrelevant. -- Brad Harms -- http://alphaios.net -- http://mail.python.org/mailman/listinfo/python-list
Re: Feature request: String-inferred names
On Fri, 04 Dec 2009 09:00:42 +, Steven D'Aprano wrote: > Not all such attributes are actually found in instance.__dict__. ...I hadn't even considered __slots__ yet. Hm... > Or dynamic attributes returned by __getattr__ or __getattribute__. I'm looking for a generic term, because it's too cumbersome to say "properties or dynamic attributes using __getattr__ or __getattribute__" all the time. That will be my last message for a while...good night, c.p.l. -- Brad Harms -- http://alphaios.net -- http://mail.python.org/mailman/listinfo/python-list
Re: Feature request: String-inferred names
On Fri, 04 Dec 2009 18:05:03 +1100, Ben Finney wrote: > Brad Harms writes: > >> Anyway, it looks like the docs agree with you >> (http://docs.python.org/glossary.html#term-attribute), so I'm not going >> to argue. > > That's good, because the terms are quite well established in Python > terminology. I'm just saying, if the official documentation defines the term "attribute" thusly, it would be silly of me to continue using my own made- up term that means pretty much the same thing. > >> However, for the purpose of clean communication, I'd still like to have >> terms that refer specifically to: >> >> 1.) "Regular" attributes, ie. those that are shortcuts to items in the >> directly associated object's __dict__, > > I don't know what you mean by “shortcuts to items”. The names are looked > up in dictionaries; where do shortcuts play a part? > > Try “instance attribute”, as distinct from “class attribute”. > >> 2.) Attributes whose values are determined or assigned dynamically by >> indirectly calling a function (like properties and instancemethods) > > Yes, the term “property” seems to do what you want. I wasn't asking what you call any object or any /kind/ of object. I was asking for a term (noun?) that describes the WAY the object is accessed as an attribute of an instance, with the connotation that the value of the attribute would be calculated dynamically (by calling a function) at the time the attribute was accessed. Note that the value does not have to exist in ANY __dict__ anywhere, it could, for example, be calculated by object.__getattribute__. Example: >>> obj.attr Without knowing what "obj" is or what "attr" is as it pertains to obj, but knowing that "attr" does not actually a key in obj.__dict_,_ and that its value has to be determined by some other means, what do you call the thing on the code line above? That is what I'm trying to find out. (HINT: Don't think about how the Python interpreter parses it or how the value is eventually determined. That's not relevant. Just understand that the value does not come directly from obj.__dict__.) By the way, a "property" is an object of type __builtin__.property. A property with a reference in an attribute of a class /does/ call a function when you try to access that property as an attribute of the class's instances. However, properties are not the only objects that have this behavior, so calling objects that behave in this way is ambiguous. I think the actual, general term for such an object is "data descriptor," or just "descriptor." (http://docs.python.org/glossary.html#term- descriptor) > > The value of an instance method is *not* determined dynamically: its > value is a function, and that value is no more dynamic than any other > attribute of the instance. That is incorrect. Indirectly accessing an instancemethod of a class through an instance of that class will trigger the descriptor behavior of the instancemethod type. This produces a new object, another instancemethod, that is bound to the instance through which it was accessed. It's a mouthful to say, but it is sufficiently accurate. Heck, just look at this: >>> class Foo(object): ... def spam(self): pass ... >>> foo = Foo() >>> foo.spam > >>> Foo.spam >>> foo.spam is Foo.spam False >>> foo.spam == Foo.spam False >>> Foo.spam.__get__(foo, Foo) > >>> Foo.__dict__["spam"].__get__(foo, Foo) > >>> Foo.__dict__["spam"].__get__(foo, Foo) is foo.spam False >>> Foo.__dict__["spam"].__get__(foo, Foo) == foo.spam True Also note the fact that Foo.spam is an _instancemethod_ object and not just a function, even though it was defined as "just a function" in the class body. That's because function objects are descriptors as well; it lets them produce unbound instancemethods. I'm not precisely sure how this works, though. I think it only happens when the metaclass of a class processes the functions in the class block. > >> 3.) Attributes that are read from an object with regular .dot syntax, >> but are actually attributes (in the sense of #1 above) of the __dict__ >> of the object's class. > > This is a “class attribute” as distinct from an “instance attribute”. > I know it's called that, but I was talking more about the fact of it being accessed through an instance of the class rather than > The distinction isn't often worth knowing, though, so you'll probably > still have to explain it when you use it. I beg to differ. For one thing, it affects descriptors. Anyway, these metadiscussions are starting to give me headaches. Let's talk about something more interesting... PS. I'm truly sorry once again for using email addresses and names inconsistently. I really am trying to solve the problem. I'm going to try accessing the list via comp.lang.python and Pan (newsreader for Gnome) for a while. Hopefully it will help. -- Brad Harms -- http://alphaios.net -- http://mail.python.org/mailman/listinfo/python-list
Re: Feature request: String-inferred names
On Tue, 2009-12-01 at 16:58 +0100, Bruno Desthuilliers wrote: > The Music Guy a écrit : > (snip) > > Lie Ryan, I think I see what you're saying about using __dict__ to add > > members > > No "members" in Python - only attributes. > > to a class, but it's not quite the same. __dict__ is only for > > attributes, NOT properties, methods, etc. which all come from the > > class of an object rather than the object's __dict__. > > properties and methods (well, functions actually) ARE attributes... of > the class object. And you can of course access the obj.__class__.__dict__ > > Just for the record... When I say "member" I am using it as a general term that describes any value that can be accessed (get, set, del) through an object. If the object is referenced by a variable named `foo`, then by using `foo.name` or one of the XXXattr functions, one can access the member of `foo` called `name`. What's important to note, though, is that the term "member" does not make any assumption about how `foo.name` is implemented. When I say "attribute," however, I am referring specifically to a member of an object where the member's name is a key in the object's __dict__, and the value is the one that is paired with that key. Example: class Foo(object): def __init__(self): self._x = 5 @property def x(self): return self._x @x.setter def x(self,val): self._x = val def frob(self): print "I've been frobbed!" foo = Foo() foo._x # Each of these is both a member and an attribute. foo.y = 6 foo.x # Each of these is a member, but neither is an attribute. foo.frob To be perfectly precise, foo.y is only an attribute AFTER the assignment has been performed. Before 6 is assigned, foo.y is only a "member" and not an "attribute" because "y" does not yet exist as a key in foo's __dict__. Essentially, I just use "member" as a convenience term. I thought that was the convention among the community, but evidently it isn't as widely used as such as I thought. Anyway, it looks like the docs agree with you (http://docs.python.org/glossary.html#term-attribute), so I'm not going to argue. However, for the purpose of clean communication, I'd still like to have terms that refer specifically to: 1.) "Regular" attributes, ie. those that are shortcuts to items in the directly associated object's __dict__, 2.) Attributes whose values are determined or assigned dynamically by indirectly calling a function (like properties and instancemethods) 3.) Attributes that are read from an object with regular .dot syntax, but are actually attributes (in the sense of #1 above) of the __dict__ of the object's class. -- http://mail.python.org/mailman/listinfo/python-list
Re: Feature request: String-inferred names
On Tue, 2009-12-01 at 14:38 +, Steven D'Aprano wrote: > On Mon, 30 Nov 2009 18:55:46 -0800, The Music Guy wrote: > > > Lie Ryan, I think I see what you're saying about using __dict__ to add > > members to a class, but it's not quite the same. __dict__ is only for > > attributes, NOT properties, methods, etc. which all come from the class > > of an object rather than the object's __dict__. > > Almost but not quite. > > It's just special double-underscore methods like __init__ __add__ etc > that have to be in the class rather than the instance. (To be precise, > you can add such a method to the instance, but it won't be called > automatically.) Likewise staticmethods and classmethods won't work > correctly unless they are in the class. But ordinary methods work fine: > the only tricky bit is creating them in the first place. > > >>> class K(object): > ... pass > ... > >>> k = K() > >>> import types > >>> k.method = types.MethodType(lambda self: "I am %s" % self, k) > >>> k.method() > 'I am <__main__.K object at 0xb7cc7d4c>' ...I'm not sure I follow your logic. Yes, you can create an instancemethod out of a function and assign it to an instance after (or during) its instantiation, which is what Python's class/instance model provides automatically. However, to do so manually in this manner completely disregards the fundamentals of object-oriented programming, not to mention the basic guiding principles of nearly all Python code in existence. It totally breaks inheritance and polymorphism. Maybe I'm missing something, but I can't see how that line of thought helps anything. -- http://mail.python.org/mailman/listinfo/python-list
Re: Feature request: String-inferred names
On Sun, Nov 29, 2009 at 9:59 PM, Carl Banks wrote: > Another thing that can be determined through common sense is that if > you have object that you are calling getattr and setattr on so much > that you think you need special syntax, you should have been using a > dict. > (Re-send; original was sent to the wrong address. I--I mean, Gmail--sent it to the wrong address by mistake. :P ) While you were writing this and your previous reply I was working on a response that kind of covers what you were talking about, but I'm going to say something anyway. Well, yes, the names would have to be determined at run time. That's what getattr and setattr do, except that that do it in the context of an object rather than the local scope. However, I was under the impression that python's mechanism for looking up local names was the same as the mechanism used to look up attributes because names and attributes seem to function pretty much the same way. This I assumed because of the functionality of the locals() and globals() functions, which seem to act like the __dict__ attribute on objects except that the work on the current scope. Also, there is the __builtins__ module, which actually _is_ an object, but its names can be accessed in the same way as locals and globals. I had considered the possibility of a peformance hit, however I didn't anticipate that it would be all that much. Not that it matters, but how much are we talking? 10% ? 50% ? In any case, I'm not really an expert on Python's internal constructions, but because of this discussion I'm considering taking some time to learn them. Python is unique compared to several other languages in that it makes a distinction between "items" and "attributes". Some languages, like JavaScript and Lua, do not make this distinction. They leave it to the programmer to access members of an object either as an item or as an attribute. I don't think there is necessarily anything wrong with this, nor do I think there is anything wrong with Python's separation. That said, just because you can use the proposed syntax to use an object in the same way as a dict does not mean that it works the other way around. I'm not talking about the allowance of any specific object to have any number of pairings between arbitrary keys and values. That's what dicts are for, and that's what indexing syntax implies. Rather, I'm talking about specific, concrete variables which objects are expected (though not technically required) to have bound to them according to how the object is intended to be used. (That's probably not the best definition of an attribute, but it's the best I can think of ATM.) I'm not trying to discard Python's distinction between items and attributes, but I don't want to be limited by it due to mere syntactical constraints, either. May the Penguin in the sky bless your every subroutine, Brad Harms -- http://mail.python.org/mailman/listinfo/python-list
Re: Feature request: String-inferred names
On Sun, Nov 29, 2009 at 7:49 PM, Lie Ryan wrote:
> On 11/29/2009 12:22 PM, The Music Guy wrote:
>
>> When I first started seeing @ show up in Python code, I said "what the
>> heck is that? It looks so weird and _ugly_.I would never try to mess
>> with that." But I started seeing it more and more, so I asked #python
>> what it was. They told me about decorators, so I looked it up in the
>> docs, and I thought the idea was interesting. It took me a while to
>> figure out exactly how they worked--and judging from messages I've
>> seen in #python a number of people have the same trouble understanding
>> them.
>>
>
> And we don't want a second flood of users asking about foo.$bar.
>
>
> My point is that any particular syntax would look ugly to you only
>> because you haven't seen it in use enough, and haven't used it enough
>> yourself.
>>
>
> You're absolutely right, and I have *never needed* to use the plain
> getattr/setattr/delattr enough to even bother considering a syntax that
> already looks ugly at first sight. For @decorators, everyone used it *often
> enough* BEFORE it turned into a syntax that the ugly syntax is justified and
> become "acceptable". If you can find a syntax that doesn't look ugly at
> first sight +0, fine by me; otherwise -1, I don't want to be forced to read
> an ugly syntax for a feature that I don't use often enough. It's not just
> the syntax, the necessity+syntax don't add up well.
>
>
> > But of course you haven't--it's not currently a valid
>
>> syntax. However, the ugliness would seem to go away after the syntax
>> had been in use for a while. And again, the EXACT syntax of the
>> feature can be adjusted until its "just right".
>>
>
> In so far, your definition of adjusting only means something around
> "[a-zA-Z0-9_]+\.[^a-zA-Z0-9_][<{(\[]?[a-zA-Z0-9_]+[>})\]]?"
> that class of syntax is ugly; some are more acceptable (e.g. obj.[arg]) the
> old thread have spawned better alternatives than that class of syntax.
>
> As for my specific use case, it's somewhat difficult to explain.
>>
>
> You know that:
> If the implementation is hard to explain it's a bad idea.
> -- Zen of Python --
>
> right?
>
>
> > The
>
>> general idea was to isolate a pattern that I spotted repeated in
>> several unrelated parts of my project. The pattern manifested itself
>> as a set of 4-5 methods and/or properties on a class whose objects
>> were designed to work in conjunction with other objects that fit a
>> particular behavior. These other objects had methods and properties
>> that were designed to interact with the first type of object in a
>> similar but--how should I say--"inverted" fashion.
>>
>
> Do you mean something like this?
>
> class A(object):
>@property
>def the_b(self):
>return self._b
>@the_b
>def the_b(self, new_b):
>self._b = new_b
>self._b._a = self
>
> class B(object):
>@property
>def the_a(self):
>return self._a
>@the_a
>def the_a(self, new_a):
>self._a = new_a
>self._a._b = self
>
> am I getting you right? If not, please elaborate and give an example of
> what you actually meant.
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>
I understand that in all likelyhood this feature won't be added to Python
anytime soon, if at all. But I'd like to continue this discussion anyway;
it's been enlightening for me. Even though I don't agree with the views of
some of the people who've replied, I like the insight. And anyway, I think
that if the syntax were already present, people would feel a lot more
positively about it; it's the idea of adding it in so late in the game that
people seem to have a problem with for the most part.
It doesn't seem like anybody besides inhahe has actually realized that my
proposition is actually different than PEP 363 in a subtle but crucial way.
It's not _literally_ a shorthand for accessing the *attr functions; that's
just the way I originally assumed it would be used most often. However, I
have since realized that the syntax is more powerful than I originally
thought: ANYWHERE that a name appeared--this includes function names, class
names, function parameters, possibly even module names--could be replaced by
an expression that would be evaluated to the name. That makes the use of any
kind of brackets, except maybe , bad options, as it would
conflict with [lists,] {dicts,} (tuples,) or generic parenthesized
(expressions). There must be a unique indicator of some kind, something that
isn't already in use by the interpreter. That way there is no possible way
that it could get confused with another syntactical construct.
So you could do something like this:
def class_factory(this, that)
get_that = "get_"+that
set_that = "set_"+that
_that = "_" + that
class $this (object):
def __init__(self, $that = None):
self.$_that = $that
def $get_that (self):
return self.$_t
