Automatic setup of meta path hooks?

2012-07-11 Thread jwp
Hi,

I'm working on a meta path hook that performs compilation of C extension 
modules on import ( github.com/jwp/py-c ; pip install c ). It mostly works, but 
I'm having a hard time finding a standard way to automatically install the hook 
upon interpreter startup.

I've thought about just having depending projects install the loader 
themselves, but I was hoping to make it seamless...Not to mention, there's the 
possibility of the case where the extension module is compiled and installed 
with setup.py. In which case, the loader isn't necessary, so it seems 
inappropriate to reference and install the meta path hook in an outer package 
module.

Am I missing something? Is there some setuptools/distribute magicalawesome that 
I can use?
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: How to represent dates BC

2012-07-28 Thread jwp
On Tuesday, July 24, 2012 2:55:29 AM UTC-7, Laszlo Nagy wrote:
>  >>> conn.getqueryvalue("select '1311-03-14 BC'::date")
> What is the good representation here? Should I implement my own date 

Do your datetime formatting in postgres: "select '1311-03-14 BC'::date::text"

PG does have a have a reasonable set of functions for working with datetime.
If you need something more complicated than a simple cast to text, I'd suggest 
creating a function:

CREATE OR REPLACE FUNCTION fmt_my_dates(date) RETURNS text LANGUAGE SQL AS
$$
SELECT EXTRACT(.. FROM $1)::text || ...
$$;
-- 
http://mail.python.org/mailman/listinfo/python-list


ANN: visage (interfaces)

2012-07-29 Thread jwp
Hi,

I just pushed this up to pypi/github, and I hoped to acquire some c.l.py 
opinions.
It's experimental at this point, and might get scrapped.

visage is a loosely coupled interface registry. weakrefs make it cake to 
implement.

Basically, zope.interface, but where the interfaces are referenced by an 
identifier instead of the defining Interface class. Also, ABC registration is 
performed when the Interface becomes available so that isinstance/issubclass 
checks can be performed on Implementation instances/classes.

FWICT, pyprotocols allows for something like this, but while introducing many 
"interesting concepts". (;

Currently, visage has no concept of adaption, but I'm suspecting that it could 
be built *on top* of the existing foundation.

Personally, I'd prefer to reference interfaces by an identifier. Notably, the 
idea of having to pull in a dependency in order to perform local tests that 
have no need for the formal Interface class is reason enough for me to use 
something like this instead of the existing solutions. Sure, to each their own.?

What's c.l.py's perspective on managing interfaces and implementations?

Fuck it, ship it? =)
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: ANN: visage (interfaces)

2012-07-29 Thread jwp
On Sunday, July 29, 2012 10:18:23 PM UTC-7, jwp wrote:
> I just pushed this up to pypi/github, and I hoped to acquire some c.l.py 
> opinions.

http://github.com/jwp/py-visage
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: ANN: visage (interfaces)

2012-07-30 Thread jwp
On Monday, July 30, 2012 6:09:10 PM UTC-7, alex23 wrote:
> a side project, so I may have some more concrete feedback soon :)

=)

> BTW I think if you rename the ReStructured Text docs to .rst github
> 
> will automatically render them.

Did not know that. Gonna go do a lot of git mv's now.

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


Re: ANN: visage (interfaces)

2012-07-30 Thread jwp
On Monday, July 30, 2012 7:09:03 PM UTC-7, Steven D'Aprano wrote:
> Do *one* and see if github actually does render it. Then do the rest.

Did it for one project. It does render it. =)

Naturally, sphinx autodoc links don't work. =( Come-on github, use dat fundin'
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: On-topic: alternate Python implementations

2012-08-04 Thread jwp
On Friday, August 3, 2012 11:15:20 PM UTC-7, Steven D'Aprano wrote:
> WPython - another optimizing version of Python with wordcodes instead of 
> bytecodes.
> 
> http://code.google.com/p/wpython/

I remember reading about this a while ago. I thought this was eventually going 
to be committed to CPython... =\
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: ANN: visage (interfaces)

2012-08-12 Thread jwp
On Sunday, July 29, 2012 10:18:23 PM UTC-7, jwp wrote:
> What's c.l.py's perspective on managing interfaces and implementations?

I pushed another version with support for IID references, so you can refer to 
implementations in annotations. The ultimate point of this is to give registry 
queries the ability to check for implementations with particular features:

@visage.lib.implementation('foo')
class Imp(object):
 def meth(self) -> visage.lib.reference('bar'):
  ...

Imp.meth making a statement that a 'bar' implementation will be returned.

That is, consider code that is not aware of the modules that "Imp" is stored in 
but wants a 'foo' implementation whose "meth" method returns a 'bar' instance. 
Registry queries pave the way for supporting IID based implementation 
resolution. There is also the potential that registry information could be 
extracted on package installation for the purpose of an implementation index. 
Implementations could be imported on demand by modules that have no knowledge 
of the implementation.
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Async client for PostgreSQL?

2012-09-01 Thread jwp
On Friday, August 31, 2012 10:17:18 PM UTC-7, Laszlo Nagy wrote:
> Is there any extension for Python that can do async I/O for PostgreSQL 

As others point out, the easiest route is using one of the blocking drivers 
with threads and "emulate" async operations.

However, the low-level parts of py-postgresql (python.projects.postgresql.org) 
were designed with arbitrary modes in mind. That is, the protocol code is 
independent of the transport so that it could be used with frameworks like 
twisted given some effort. Much of the work that will go into py-postgresql 
over the next couple years will be to make it easier to integrate into 
arbitrary frameworks. Currently, I suspect it would require some "heavy 
lifting".. =\

cheers,

github.com/jwp
-- 
http://mail.python.org/mailman/listinfo/python-list