Hi all,
This issue: http://bugs.python.org/issue9807 from a couple of years ago
seems to have changed the LIBPL build variable from pointing to a directory
inside EPREFIX, to a directory in PREFIX.
This doesn't seem ideal as LIBPL is populated with platform specific files
such as libpython.a.
On 01/14/2013 01:44 PM, Greg Ewing wrote:
I think protect is *far* too vague. We don't want something
so neutral that it gives no clue at all about its meaning.
My shoot-from-the-hip name suggestion: sterile. (Does not produce
offspring.)
When a process and a file descriptor love each
OK, here is the third major incarnation of PEP-431.
I think it addresses all the concerns brought to light so far.
https://raw.github.com/regebro/tz-pep/master/pep-04tz.txt
Is there a simpler way of doing this than thus cut and paste
updating? Is there a way to make pull requests to
On Tue, Jan 15, 2013 at 4:07 PM, Lennart Regebro rege...@gmail.com wrote:
OK, here is the third major incarnation of PEP-431.
I think it addresses all the concerns brought to light so far.
https://raw.github.com/regebro/tz-pep/master/pep-04tz.txt
Is there a simpler way of doing this than
Hi!
I'm curious how dlls from the DLLs folder on Windows are being loaded? As they
are not placed in the same folder where python.exe resides I guess they must be
loaded by giving the path explicitly but I'm not sure. I'm asking because
there's no DLLs folder being created when creating
On 1/15/2013 6:21 PM, Piotr Dobrogost wrote:
I'm curious how dlls from the DLLs folder on Windows are being loaded? As they
are not placed in the same folder where python.exe resides I guess they must be
loaded by giving the path explicitly but I'm not sure.
They are in .../DLLs, which is in
