Milan Krcmar schrieb:
> Can you give me any information to start with? I would prefer stripping
> current version of Python rather than returning to a years-old (but
> smaller) version and remembering what of the new syntax/functionality to
> avoid.
I would start with dropping support for dynamic
Milan Krcmar <[EMAIL PROTECTED]> writes:
> I would like to run Python scripts on an embedded MIPS Linux platform
> having only 2 MiB of flash ROM and 16 MiB of RAM for everything.
>
> Current (2.5) stripped and gzipped (I am going to use a compressed
> filesystem) CPython binary, compiled with def
Marcin 'Qrczak' Kowalczyk wrote:
>> 1) There's a way to destruct the handle BEFORE __del__ is called,
>> which would require killing the weakref / deregistering the
>> finalization hook.
>
> Weakrefs should have a method which runs their callback and
> unregisters them.
>
>> 2) The objects require
Milan Krcmar wrote:
> Current (2.5) stripped and gzipped (I am going to use a compressed
> filesystem) CPython binary, compiled with defaults on a i386/glibc
> Linux, results in 500 KiB of "flash". How to make the Python
> interpreter even smaller?
In my experience, the biggest gain can be obtain
Armin Rigo wrote:
> This doesn't match my experience, which is that sys.path hackery is
> required in any project that is larger than one directory, but is not
> itself a library. [...]
>myapp/
> main.py
> a/
> __init__.py
> b.py
> test_b.py
> c/
I would like to run Python scripts on an embedded MIPS Linux platform
having only 2 MiB of flash ROM and 16 MiB of RAM for everything.
Current (2.5) stripped and gzipped (I am going to use a compressed
filesystem) CPython binary, compiled with defaults on a i386/glibc
Linux, results in 500 KiB of
Hi Guido,
On Thu, Sep 21, 2006 at 07:22:04AM -0700, Guido van Rossum wrote:
> sys.path exists to stitch together the toplevel module/package
> namespace from diverse sources.
>
> Import hooks and sys.path hackery exist so that module/package sources
> don't have to be restricted to the filesystem
David Hopwood schrieb:
>>> (C++ allows restating of typedefs; if C allows it, that should be
>>> something like):
>> C also allows this; [...]
>
> This is nitpicking, since you agreed the change to the PEP, but are you
> sure that C allows this?
I was sure, but I was also wrong. Thanks for pointi
Jeremy Kloth schrieb:
> GCC's symbol visibility is supposed to address this exact problem. It would
> be nice if -fvisibility=hidden was used to build Python (and its extensions)
> by default on supported platforms/compilers. It shouldn't be much of an
> issue wrt. exported symbols as they alr
Gerhard Häring schrieb:
> Apparently at least gcc on Linux exports all symbols by default that are
> not static.
Correct. Various factors influence run-time symbol binding, though.
> This creates problems with Python extensions that export
> symbols that are also used in other contexts. For examp
Martin v. Löwis wrote:
> David Abrahams schrieb:
>
>>(C++ allows restating of typedefs; if C allows it, that should be
>>something like):
>
> C also allows this; [...]
This is nitpicking, since you agreed the change to the PEP, but are you
sure that C allows this?
>From C99 + TC1 + TC2 (http://
On 9/23/06, Anthony Baxter <[EMAIL PROTECTED]> wrote:
I'd like to propose that the AST format returned by passing PyCF_ONLY_AST tocompile() get the same guarantee in maintenance branches as the bytecodeformat - that is, unless it's absolutely necessary, we'll keep it the same.
Otherwise anyone tryi
On Saturday, September 23, 2006 11:31 am, Gerhard Häring wrote:
> Looks like I don't know C so well after all ...
>
> Apparently at least gcc on Linux exports all symbols by default that are
> not static. This creates problems with Python extensions that export
> symbols that are also used in other
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Looks like I don't know C so well after all ...
Apparently at least gcc on Linux exports all symbols by default that are
not static. This creates problems with Python extensions that export
symbols that are also used in other contexts. For example som
Anthony Baxter <[EMAIL PROTECTED]> writes:
> I'd like to propose that the AST format returned by passing PyCF_ONLY_AST to
> compile() get the same guarantee in maintenance branches as the bytecode
> format - that is, unless it's absolutely necessary, we'll keep it the same.
> Otherwise anyone t
[EMAIL PROTECTED] schrieb:
> Martin> The problem you have is specific to Solaris, and specific to
> Martin> using GCC on Solaris.
>
> So can we fix this in pyport.h or with suitable Configure script
> machinations? Even though the current patch we're using is trivial I'd
> really like to
Martin> The problem you have is specific to Solaris, and specific to
Martin> using GCC on Solaris.
So can we fix this in pyport.h or with suitable Configure script
machinations? Even though the current patch we're using is trivial I'd
really like to avoid patching the Python distributio
In Python 2.4, traceback.print_exc() and traceback.format_exc() silently
do nothing if there is no active exception; in Python 2.5, they raise an
exception. Not too difficult to handle, but unexpected (and a pain if
you use it in a lot of places). I assume it was an unintentional change?
Mike
Greg> Or maybe remove() should just do nothing if the item is not
Greg> found.
If that's the case, I'd argue that dict.remove and set.remove should behave
the same way, making .discard unnecessary. OTOH, perhaps lists should grow
a .discard method.
Skip
"Martin v. Löwis" <[EMAIL PROTECTED]> writes:
>> c. anyway you'll get a nasty warning, which for some people will be
>> just as bad as an error
>
> Try for yourself. You get the warning only if the redefinition is not
> identical to the original definition (or an object-like macro is
> redefined
[EMAIL PROTECTED] schrieb:
> One of our C++ gurus (that's definitely not me!) patched the Python source
> to include at the top of Python.h. That seems to have solved our
> problems, but seems to be a symptomatic fix.
Indeed. The right fix is likely different, and relates to the question
what AP
On Sep 13, 2006, at 18:46, [EMAIL PROTECTED] wrote:
>
> Building Python with C and then linking in extensions written in or
> wrapped
> with C++ can present problems, at least in some situations. I
> don't know if
> it's kosher to build that way, but folks do. We're bumping into such
> prob
I'd like to propose that the AST format returned by passing PyCF_ONLY_AST to
compile() get the same guarantee in maintenance branches as the bytecode
format - that is, unless it's absolutely necessary, we'll keep it the same.
Otherwise anyone trying to write tools to manipulate the AST is in for
23 matches
Mail list logo
