Hi all,
Currently, Parser/parsetok.c has a dependency on graminit.h. This can
cause headaches when rebuilding after adding new syntax to
Grammar/Grammar because parsetok.c is part of pgen, which is responsible
for *generating* graminit.h.
This circular dependency can result in parsetok.c us
Alex Martelli wrote:
> I wonder if there's some desiderata left for future Python versions to
> make this standard behavior easier (for C-coded, Python-coded, and
> Cython-coded classes, ones made by SWIG, etc) without too much black
> magic...
I think the standard exception hierarchy should grow
> The OEM ready program required that the installed force to program
> files. But as we preinstalled we use your msi with a normal
> parameter: python-2.5.2.msi TARGETDIR=c:\program files\python"
I think the debate was about whether it can be "OEM ready",
even though you still need to pass the TAR
Alex Martelli wrote:
> I wonder if there's some desiderata left for future Python versions to
> make this standard behavior easier (for C-coded, Python-coded, and
> Cython-coded classes, ones made by SWIG, etc) without too much black
> magic...
Perhaps adding something like the following to the C
Mark,
We do not install that on first boot.
I can not tell how it is install but on first boot python is already there and
installed properly
Gerald
-Original Message-
From: Koenig, Gerald
Sent: Monday, December 01, 2008 11:05 AM
To: '"Martin v. Löwis"'; [EMAIL PROTECTED]
Cc: 'Nick C
Hi all,
I didn't look at the thread until this morning.
The OEM ready program required that the installed force to program files.
But as we preinstalled we use your msi with a normal parameter:
python-2.5.2.msi TARGETDIR=c:\program files\python"
That why I didn't ask you about that.
WE have do
Dino Viehland wrote:
Yep, after the thanksgiving delay I've opened bug #4482
(http://bugs.python.org/issue4482).
Thanks!
I either don't know how to or don't have the power to change who a bug is
assigned to so it appears to be currently unassigned.
I'll take care of it.
Eric.
-Orig
Yep, after the thanksgiving delay I've opened bug #4482
(http://bugs.python.org/issue4482).
I either don't know how to or don't have the power to change who a bug is
assigned to so it appears to be currently unassigned.
-Original Message-
From: Eric Smith [mailto:[EMAIL PROTECTED]
Sent:
I wonder if there's some desiderata left for future Python versions to
make this standard behavior easier (for C-coded, Python-coded, and
Cython-coded classes, ones made by SWIG, etc) without too much black
magic...
Alex
On Mon, Dec 1, 2008 at 1:30 AM, Filip Gruszczyński <[EMAIL PROTECTED]> wrote
Probably because of the object memory allocator. It reads the start of memory
pages to see if a block belongs tot the obmalloc system or not.
You want to remove the following line:
#define WITH_PYMALLOC 1
>From pyconfig.h if you intend to run using valgrind or say, purify.
K
-Original Messag
> Yes, but he should be able to change it in one place (in sip, the C++
> to Python wrapper generator he's also authored and uses for PyQt) AND
> it would make sip even better, so he may want to put it on his
> backlog.
He does. It is supposed to appear in 4.8. So I guess that's it, thanks
a lot f
11 matches
Mail list logo
