On 04:11 am, fdrake(a)acm.org wrote:
>On Wednesday 29 November 2006 22:20, glyph(a)divmod.com wrote:
> > GNOME et. al. aren't promoting the concept too hard. It's just the first
> > convention I came across. (Pardon the lack of references here, but it's
> > very hard to google for "~/.local" - I just know that I was looking for a
> > convention when I wrote combinator, and this is the one I found.)
>~/.local/ is described in the "XDG Base Directory Specification":
Thanks for digging that up! Not a whole lot of meat there, but at least it gives me some env vars to set / check...
> > On the "easy_install" naming front, how about "layegg"?
>Actually, why not just "egg"?
That works for me. I assumed there was some other reason the obvious answer hadn't been chosen :).
At 03:20 AM 11/30/2006 +0000, glyph(a)divmod.com wrote:
>One of the things that combinator hacks is where distutils thinks it
>should install to - when *I* type "python setup.py install" nothing tries
>to insert itself into system directories (those are for Ubuntu, not me) -
>~/.local is the *default* install location. I haven't managed to make
>this feature work with eggs yet, but I haven't done a lot of work with
easy_install uses the standard distutils configuration system, which means
that you can do e.g.
prefix = ~/.local
in ./setup.cfg, ~/.pydistutils.cfg, or
/usr/lib/python2.x/distutils/distutils.cfg to set the default installation
prefix. Setuptools (and distutils!) will then install libraries to
~/.local/lib/python2.x/site-packages and scripts to ~/.local/bin.
On 12:34 am, greg.ewing(a)canterbury.ac.nz wrote:
>The whole concept of "hidden" files seems ill-
>considered to me, anyway. It's too easy to forget
>that they're there. Putting infrequently-referenced
>stuff in a non-hidden location such as ~/local
>seems just as good and less magical to me.
Something like "~/.local" is an implementation detail, not something that should be exposed to non-savvy users. It's easy enough for an expert to "show" it if they want to - "ln -s .local local" - but impossible for someone more naive to hide if they don't understand what it is or what it's for. (And if they try, by clicking a checkbox in Nautilus or somesuch, *all* their installed software breaks.) This approach doesn't really work unless you have good support from the OS, so it can warn you you're about to do something crazy.
UI designers tend to get adamant about this sort of thing, but I'll admit they go both ways, some saying that everything should be exposed to the user, some saying that all details should be hidden by default. Still, in the more recent UNIX desktops, the "let's hide the things that the user shouldn't see and just work really hard to make them work right all the time" camp seems to be winning.
[Guido van Rossum]
> This seems a bug. In revision 36714 by Raymond Hettinger,
> the restriction that locals be a dict was relaxed to allow
> any mapping.
> Mea culpa, I thought I reviewed this patch at the time.
> Fixed in r52862-52863.
Armin, thanks for the check-ins. Daniel, thanks for finding one of the cases I missed. Will load a unittest for this one when I get a chance.
I would like to know the definition of the 'locals' object given to
PyEval_EvalCode. Has 'locals' to be a python dictionary or a subtype
of a python dictionary, or is it enough if the object implements the
The python implementation behaves different for the two following code
from modul import symbol
from modul import *
In the case of the first one, it's enough if the object 'locals' implements
the necessary protocols. The second one only works if the object 'locals'
is a type or subtype of dictionary.
The problem lies in Python-2.5/Python/ceval.c:
import_all_from(PyObject *locals, PyObject *v)
4046 value = PyObject_GetAttr(v, name);
4047 if (value == NULL)
4048 err = -1;
>>> 4050 err = PyDict_SetItem(locals, name, value);
Changing PyDict_SetItem in line 4050 with PyObject_SetAttr could fix it.
At 01:05 PM 11/28/2006 -0800, Guido van Rossum wrote:
>On 11/28/06, Barry Warsaw <barry(a)python.org> wrote:
> > There's a related issue that may or may not be in scope for this
> > thread. For distros like Gentoo or Ubuntu that rely heavily on their
> > own system Python for the OS to work properly, I'm quite loathe to
> > install Cheeseshop packages into the system site-packages.
>I wonder if would help if we were to add a vendor-packages directory
>where distros can put their own selection of 3rd party stuff they
>depend on, to be searched before site-packages, and a command-line
>switch that ignores site-package but still searches vendor-package.
>(-S would almost do it but probably suppresses too much.)
They could also use -S and then explicitly insert the vendor-packages
directory into sys.path at the beginning of their scripts. And a .pth in
site-packages could add vendor-packages at the *end* of sys.path, so that
scripts not using -S would pick it up.
This would be backward compatible except for the vendor scripts that want
to use this approach.
On 11:45 pm, barry(a)python.org wrote:
>I keep thinking I'd like to treat the OS as just another application,
>so that there's nothing special about it and the same infrastructure
>could be used for other applications with lots of entry level scripts.
I agree. The motivation here is that the "OS" application keeps itself separate so that incorrect changes to configuration or installation of incompatible versions of dependencies don't break it. There are other applications which also don't want to break.
This is a general problem with Python, one that should be solved with a comprehensive parallel installation or "linker" which explicitly describes dependencies and allows for different versions of packages. I definitely don't think that this sort of problem should be solved during the *standardization* process - that should just describe the existing conventions for packaging Python stuff, and the OS can insulate itself in terms of that. Definitely it shouldn't be changed as part of standardization unless the distributors are asking for it loudly.
I'd like to ask for help with an issue which I do not know
how to solve.
Please see this bug http://python.org/sf/1563807
"ctypes built with GCC on AIX 5.3 fails with ld ffi error"
Apparently this is a powerpc machine, ctypes builds but cannot be imported
because of undefined symbols like 'ffi_call', 'ffi_prep_closure'.
These symbols are defined in file
The whole contents of this file is enclosed within a
block. IIRC, this block has been added by Ronald for the
Mac universal build. Now, it seems that on the AIX machine
the __ppc__ symbols is not defined; removing the #ifdef/#endif
makes the built successful.
We have asked (in the SF bug tracker) for the symbols that are defined;
one guy has executed 'gcc -v -c empty.c' and posted the output, as far as I
see these are the symbols defined in gcc:
-D__GNUC_MINOR__=9 -D_IBMR2 -D_POWER -D_AIX -D_AIX32 -D_AIX41 -D_AIX43
-D_AIX51 -D_LONG_LONG -D_IBMR2 -D_POWER -D_AIX -D_AIX32 -D_AIX41 -D_AIX43
-D_AIX51 -D_LONG_LONG -Asystem(unix) -Asystem(aix) -D__CHAR_UNSIGNED__
What should we do now? Should the conditional be changed to
#if defined(__ppc__) || defined(_POWER)
or should we suggest to add '-D__ppc__' to the CFLAGS env var, or what?
Version 0.10 of the 'processing' package is available at the cheeseshop:
It is intended to make writing programs using processes almost the
same as writing
programs using threads. (By importing from 'processing.dummy' instead
one can use threads with the same API.)
It has been tested on both Windows and Unix.
Shared objects are created on a 'manager' which runs in its own processes.
Communication with it happens using sockets or (on windows) named pipes.
An example where integers are sent through a shared queue from a child
. from processing import Process, Manager
. def f(q):
. for i in range(10):
. if __name__ == '__main__':
. manager = Manager()
. queue = manager.Queue(maxsize=10)
. p = Process(target=f, args=[queue])
. result = None
. while result != 'STOP':
. result = queue.get()
. print result
It has had some changes since the version I posted lasted month:
1) The use of tokens to identify shared objects is now hidden, so now
the API of
'processing' really is very similar to that of 'threading'.
2) It is much faster than before: on both Windows XP and Linux a manager serves
roughly 20,000 requests/second on a 2.5 Ghz Pentium 4. (Though it is
not a fair comparison that is 50-100 times faster than using
3) The manager process just reuses the standard synchronization types from
threading.py, Queue.py and spawns a new thread to serve each process/thread
which owns a proxy. (The old version was single threaded and had a
4) Registering new shared types is straight forward, for instance
. from processing.manager import ProcessBaseManager
. class Foo(object):
. def bar(self):
. print 'BAR'
. class NewManager(ProcessBaseManager):
. NewManager.register('Foo', Foo, exposed=['bar'])
. if __name__ == '__main__':
. manager = NewManager()
. foo = manager.Foo()
. foo.bar() # => prints 'BAR'
Martin v. Löwis wrote:
> Armin Rigo schrieb:
> > I think this list of examples isn't meant to be read that
> > way. Half of them can invoke custom methods, not just the
> > two you mention here.
> Ah, so it's more about Consistency (lists not being corrupted)
> than about Atomicity (operations either succeeding completely
> or failing completely). Perhaps it's also about Isolation (no
> intermediate results visible), but I'm not so sure which of
> these operations are isolated (given the callbacks).
It's not "about" any of those things, because we're not discussing transactional models. The FAQ entry is trying to list statements which can be considered a single operation due to being implemented via a single bytecode. By eliminating statements which use multiple VM instructions, one minimizes overlapping operations; there are other ways, but this is easy and common, and is an important "first step" toward making a container "thread-safe". You're bringing in other, larger issues, which is fine and should be addressed in a larger context. But the FAQ isn't trying to address those.
The confusion arises because transactional theory uses "atomic transaction" in a much narrower sense than language design uses the phrase "atomic operation" (see http://en.wikipedia.org/wiki/Atomic_operation for example--it includes isolation and consistency). And the FAQ entry is only addressing the "isolation" concern; whether or not a given operation can be interrupted/overlapped. Those who design thread-safe containers benefit from such a list. Yes, they must also make sure no Python code (like __del__ or __setattr_, etc) is invoked during the operation; others have already pointed out that by using builtins, this can be minimized. But that "second step" doesn't negate the benefit of the "first step", eliminating statements which require multiple VM instructions.