[Python-Dev] AST structure and maintenance branches
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 a massive world of hurt. Anyone have any problems with this, or can it be added to PEP 6? Anthony ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Maybe we should have a C++ extension for testing...
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 problems at work using Solaris 10 and Python 2.4 (building matplotlib, which is largely written in C++), and it appears others have similar problems: http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6395191 http://mail.python.org/pipermail/patches/2005-June/017820.html http://mail.python.org/pipermail/python-bugs-list/2005-November/ 030900.html I attached a comment to the third item yesterday (even though it was closed). One of our C++ gurus (that's definitely not me!) patched the Python source to include wchar.h at the top of Python.h. That seems to have solved our problems, but seems to be a symptomatic fix. I got to thinking, should we a) encourage people to compile Python with a C++ compiler if most/ all of their extensions are written in C++ anyway (does that even work if one or more extensions are written in C?), or b) should the standard distribution maybe include a toy extension written in C++ whose sole purpose is to test for cross-language problems? Mixing of C and C++ code is fully supported by the compilers and linkers. There is no need to compile the python core as C++ code, indeed if you did only C++ extension could use it! In the distent past there had been problems with some unix distributions linking python in such a way that C++ code would not initialise. The major distributions seem to have sort these problems out. But clearly Solaris has a problem. It would be worth finding out out why it was necessary to include wchar.h to fix the problems. If you do add a C++ test extension it will need to do what ever it was that wchar.h fixes. From what I can remember attempts to use std::cout would fail and I think static object initialisation would fail. The test code would need to do all these things and verify they are working. Barry (PyCXX cxx.sourceforge.net) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Maybe we should have a C++ extension for testing...
[EMAIL PROTECTED] schrieb: One of our C++ gurus (that's definitely not me!) patched the Python source to include wchar.h 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 API Sun defines in its header files, and which of these which gcc version uses. I got to thinking, should we a) encourage people to compile Python with a C++ compiler if most/all of their extensions are written in C++ anyway (does that even work if one or more extensions are written in C?) I can't see how this could help. The problem you have is specific to Solaris, and specific to using GCC on Solaris. This is just a tiny fraction of Python users. Without further investigation, it might be even depending on the specific version of GCC being used (and the specific Solaris version). or b) should the standard distribution maybe include a toy extension written in C++ whose sole purpose is to test for cross-language problems? Again, this isn't likely to help. If such a problem exist, it is only found if somebody builds Python on that platform. You are perhaps the first one to do in this specific combination, so you would have encountered the problem first. Would that have helped you? Either/or/neither/something else? Something else. Find and understand all platform quirks on platforms we encounter, and come up with a solution. Fix them one by one, as we encounter them, and document all work-arounds being made, so we can take them out when the system disappears (or subsequent releases fixed the platform bugs). Doing so requires a good understanding of C and C++, of course. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pep 353: Py_ssize_t advice
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 as a function-like macro or vice versa). I'm confident that whether you get the warning otherwise is dependent both on the compiler and the compiler-flags you use. But this question is academic now, I think, since you accepted my suggestion. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] list.discard? (Re: dict.discard)
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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Python 2.5 bug? Changes in behavior of traceback module
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 In Python 2.4: import traceback traceback.print_exc() None traceback.format_exc() 'None\n' In Python 2.5: import traceback traceback.print_exc() Traceback (most recent call last): File stdin, line 1, in module File /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/traceback.py, line 227, in print_exc print_exception(etype, value, tb, limit, file) File /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/traceback.py, line 126, in print_exception lines = format_exception_only(etype, value) File /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/traceback.py, line 176, in format_exception_only stype = etype.__name__ AttributeError: 'NoneType' object has no attribute '__name__' traceback.format_exc() Traceback (most recent call last): File stdin, line 1, in module File /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/traceback.py, line 236, in format_exc return ''.join(format_exception(etype, value, tb, limit)) File /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/traceback.py, line 145, in format_exception list = list + format_exception_only(etype, value) File /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/traceback.py, line 176, in format_exception_only stype = etype.__name__ AttributeError: 'NoneType' object has no attribute '__name__' ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Maybe we should have a C++ extension for testing...
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 distribution when we install it. Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Maybe we should have a C++ extension for testing...
[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 avoid patching the Python distribution when we install it. Yes. However, to do so, somebody would have to understand the problem in detail first. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] AST structure and maintenance branches
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 trying to write tools to manipulate the AST is in for a massive world of hurt. Anyone have any problems with this, or can it be added to PEP 6? Sounds like a good idea. Cheers, mwh -- Reading Slashdot can [...] often be worse than useless, especially to young and budding programmers: it can give you exactly the wrong idea about the technical issues it raises. -- http://www.cs.washington.edu/homes/klee/misc/slashdot.html#reasons ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Need help with C - problem in sqlite3 module
-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 some people use Python and the sqlite3 module under Apache, and the sqlite3 module exports a symbol cache_init, but cache_init is also used by Apache's mod_cache module. Thus there are crashes when using the sqlite3 module that only occur in the mod_python context. Can somebody with more knowledge about C tell me how to fix the sqlite3 module or compiler settings for distutils so that this does not happen? Of course this only happens because the sqlite3 module is distributed among multiple .c files and thus I couldn't make everything static. Thanks in advance. - -- Gerhard -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFFW9UdIO4ozGCH14RApFQAKC+BJd8mGlCXJa89swOcMvASoj6GgCfZxf+ tZ/iVO8xTEV7qNeXBcDT0WU= =lX07 -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Need help with C - problem in sqlite3 module
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 contexts. For example some people use Python and the sqlite3 module under Apache, and the sqlite3 module exports a symbol cache_init, but cache_init is also used by Apache's mod_cache module. Thus there are crashes when using the sqlite3 module that only occur in the mod_python context. Can somebody with more knowledge about C tell me how to fix the sqlite3 module or compiler settings for distutils so that this does not happen? Of course this only happens because the sqlite3 module is distributed among multiple .c files and thus I couldn't make everything static. 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 already need to be tracked for Windows where symbols are hidden by default (unlike traditional *nix). -- Jeremy Kloth http://4suite.org/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] AST structure and maintenance branches
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 trying to write tools to manipulate the AST is in for amassive world of hurt.Anyone have any problems with this, or can it be added to PEP 6?Works for me.-Bett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pep 353: Py_ssize_t advice
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://www.open-std.org/JTC1/SC22/WG14/www/standards): # 6.2.2 Linkages of identifiers # # 6 The following identifiers have no linkage: an identifier declared #to be anything other than an object or a function; [...] (i.e. typedef identifiers have no linkage) # 6.7 Declarations # # Constraints # 3 If an identifier has no linkage, there shall be no more than one #declaration of the identifier (in a declarator or type specifier) #with the same scope and in the same name space, except for tags as #specified in 6.7.2.3. # 6.7.2.3 Tags # # Constraints # 1 A specific type shall have its content defined at most once. (There is nothing else in 6.7.2.3 that applies to typedefs.) Since 6.7 (3) and 6.7.2.3 (1) are constraints, I read this as saying that a C99 implementation must produce a diagnostic if a typedef is redeclared in the same scope. If the program is run despite the diagnostic, its behaviour is undefined. Several C compilers I've used in the past have needed the idempotence guard on typedefs, in any case. -- David Hopwood [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Need help with C - problem in sqlite3 module
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 example some people use Python and the sqlite3 module under Apache, and the sqlite3 module exports a symbol cache_init, but cache_init is also used by Apache's mod_cache module. Thus there are crashes when using the sqlite3 module that only occur in the mod_python context. Can somebody with more knowledge about C tell me how to fix the sqlite3 module or compiler settings for distutils so that this does not happen? The only reliable way is to do renaming. This was one of the primary reasons of the grand renaming in Python, where the Py prefix was introduced. Of course this only happens because the sqlite3 module is distributed among multiple .c files and thus I couldn't make everything static. In the specific case, I can't understand that reason. cache_init is declared in cache.c, and only used in cache.c (to fill a tp_init slot). So just make the symbol static. As a lesson learned, you should go through the module and make all functions static, then see what functions really need to be extern. You should then rename these functions, say by adding a PySQLite prefix. All dynamic symbols remaining should then either have the PySQLite prefix, except for init_sqlite3. In fact, since most operations in Python go through function pointers, there is typically very little need for extern functions in a Python extension module, even if that module consists of multiple C files. Regards, Martin P.S. Currently, on my system, the following symbols are extern in this module 5890 T _authorizer_callback dec0 A __bss_start 7600 T _build_column_name 5df0 T _build_py_params 7ee0 T build_row_cast_map 4880 T cache_dealloc 4990 T cache_display 4b90 T cache_get 4da0 T cache_init 4930 T cache_setup_types d4a0 D CacheType 4e80 T check_connection 9f60 T check_remaining_sql 5420 T check_thread 6430 T _connection_begin 5cb0 T connection_call 68d0 T connection_close 61c0 T connection_commit 59b0 T connection_create_aggregate 5ab0 T connection_create_function 57a0 T connection_cursor 6530 T connection_dealloc 5320 T connection_execute 5220 T connection_executemany 5120 T connection_executescript 6970 T connection_init 6700 T connection_rollback 56d0 T connection_set_authorizer 50e0 T connection_setup_types d5e0 D ConnectionType ded8 B converters 94d0 T converters_init 7110 T cursor_close 7190 T cursor_dealloc 8d90 T cursor_execute 8d50 T cursor_executemany 72e0 T cursor_executescript 7c90 T cursor_fetchall 7d30 T cursor_fetchmany 7e10 T cursor_fetchone 70b0 T cursor_getiter 7530 T cursor_init 7b50 T cursor_iternext 70e0 T cursor_setup_types d980 D CursorType decc B DatabaseError ded4 B DataError 5bb0 T _drop_unused_statement_references dec0 A _edata def0 B _enable_callback_tracebacks defc A _end dee8 B Error 7710 T _fetch_one_row 6cb0 T _final_callback aac4 T _fini 6830 T flush_statement_cache 6fa0 T _func_callback 7e60 T _get_converter 3bd4 T _init 9520 T init_sqlite3 deec B IntegrityError ded0 B InterfaceError dedc B InternalError 8dd0 T microprotocols_adapt 9040 T microprotocols_add 90e0 T microprotocols_init 47a0 T new_node 4810 T node_dealloc d3e0 D NodeType def8 B NotSupportedError dee4 B OperationalError dee0 B OptimizedUnicode 9ae0 T prepare_protocol_dealloc 9ac0 T prepare_protocol_init 9b10 T prepare_protocol_setup_types dec8 B ProgrammingError dec4 B psyco_adapters 8fc0 T psyco_microprotocols_adapt 70c0 T pysqlite_noop 8110 T _query_execute 6690 T reset_all_statements dd20 D row_as_mapping 9b50 T row_dealloc 9e40 T row_init 9bd0 T row_length 9c40 T row_setup_types 9c80 T row_subscript dd40 D RowType a910 T _seterror 5fc0 T _set_result 6c70 T _sqlite3_result_error dc60 D SQLitePrepareProtocolType aa30 T _sqlite_step_with_busyhandler a2a0 T statement_bind_parameter a530 T statement_bind_parameters a7f0 T statement_create a0f0 T statement_dealloc a080 T statement_finalize 9f30 T statement_mark_dirty a210 T statement_recompile a190 T statement_reset a040 T statement_setup_types de00 D StatementType 76a0 T unicode_from_string def4 B Warning ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Need help with C - problem in sqlite3 module
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 already need to be tracked for Windows where symbols are hidden by default (unlike traditional *nix). Of course, this doesn't help on systems where gcc isn't used. So for Python itself, we should always look for a solution that works across compilers. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New relative import issue
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 (as well as to allow unbridled experimentation by those so inclined :-). 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. The basic assumption is that I don't want to put whole applications in 'site-packages' or in my $PYTHONPATH; I would like them to work in a self-contained, zero-installation way, much like they do if they are built from several modules in a single directory. For example, consider an application with the following structure: myapp/ main.py a/ __init__.py b.py test_b.py c/ __init__.py This theoretical example shows main.py (the main entry point) at the root of the package directories - it is the only place where it can be if it needs to import the packages a and c. The module a.b can import c, too (and this is not bad design - think about c as a package regrouping utilities that make sense for the whole application). But then the testing script test_b.py cannot import the whole application any more. Imports of a or c will fail, and even a relative import of b will crash when b tries to import c. The only way I can think of is to insert the root directory in sys.path from within test_b.py, and then use absolute imports. (For example, to support this way of organizing applications, the 'py' lib provides a call py.magic.autopath() that can be dropped at the start of test_b.py. It hacks sys.path by guessing the real root according to how many levels of __init__.py there are...) A bientot, Armin. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Minipython
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 flash. How to make the Python interpreter even smaller? - can I completely drop out lexical analysis of sourcecode and compilation to bytecode? is it relevant enough to the size of interpreter? - should I drop useless compiled-in modules? (what I need is a replacement for advanced bash scripting, being able to write more complex scripts and avoid forking tens of processes for things like searching filesystem, formating dates etc.) I don't want to re-invent the wheel, but all my attempts at finding Python for embedded systems ended in instructions for embedding Python in another program :-) 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. TIA, Milan ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New relative import issue
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/ __init__.py This theoretical example shows main.py (the main entry point) at the root of the package directories - it is the only place where it can be if it needs to import the packages a and c. The module a.b can import c, too (and this is not bad design - think about c as a package regrouping utilities that make sense for the whole application). But then the testing script test_b.py cannot import the whole application any more. Imports of a or c will fail, and even a relative import of b will crash when b tries to import c. The only way I can think of is to insert the root directory in sys.path from within test_b.py, and then use absolute imports. This also matches my experience, but I never used sys.path hackery for this kind of things. I either set PYTHONPATH while I work on myapp (which I consider not such a big trouble after all, and surely much less invasive than adding specific Python code tweaking sys.path into all the tests), or, even more simply, I run the test from myapp main directory (manually typing myapp/b/test_b.py). There is also another possibility, which is having a smarter test framework where you can specify substrings of test names: I don't know py.test in detail, but in my own framework I can say something like ./run_tests.py PAT, which basically means recursively discover and run all files named test_NAME, and where PAT is a substring of NAME). (For example, to support this way of organizing applications, the 'py' lib provides a call py.magic.autopath() that can be dropped at the start of test_b.py. It hacks sys.path by guessing the real root according to how many levels of __init__.py there are...) Since I consider this more of an environmental problem, I would not find satisfying any kind of solution at the single module level (and even less so one requiring so much guess-work as this one). Giovanni Bajo ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Minipython
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 obtained by dropping the rarely-used CJK codecs (for Asian languages). That should sum up to almost 800K (uncompressed), IIRC. After that, I once had to strip down the binary even more, and found out (by guesswork and inspection of map files) that there is no other low hanging fruit. By carefully selecting which modules to link in, I was able to reduce of another 300K or so, but nothing really incredible. I would also suggest -ffunction-sections in these cases, but you might already know that. Giovanni Bajo ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Removing __del__
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 required in the destructor can be mutated / changed during the lifetime of the instance. For instance, a class that wraps Win32 FindFirstFirst/FindFirstNext and support transparent directory recursion needs something similar. Listing files with transparent directory recursion can be implemented in terms of listing files of a given directory, such that a finalizer is only used with the low level object. Another example is a class which creates named temporary files and needs to remove them on finalization. It might need to create several different temporary files (say, self.handle is the filename in that case)[1], so the filename needed in the destructor changes during the lifetime of the instance. Again: move the finalizer to a single temporary file object, and refer to such object instead of a raw handle. Yes, I know Python is turing-complete even without __del__, but that is not my point. The fact that we can enhance weakrefs and find a very complicated way to solve problems which __del__ solves right now easily does not make things different. People are still propsing to drop a feature which is perceived as easy by users, and replace it with a complicated set of workarounds, which are prone to mistakes, more verbose, hard to learn and to maintain. I'm totally in favor of the general idea of dropping rarely used features (like __var in the other thread). I just can't see how dropping __del__ makes things easier, while it surely makes life a lot harder for the legitimate users of it. Giovanni Bajo ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Minipython
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 defaults on a i386/glibc Linux, results in 500 KiB of flash. How to make the Python interpreter even smaller? - can I completely drop out lexical analysis of sourcecode and compilation to bytecode? is it relevant enough to the size of interpreter? I don't think there's an configure flag for this or anything, and it might be a bit hairy to do it, but it's possible and it would probably save a bit. There is a configure option to remove unicode support. It's not terribly well supported and stops working every now and again, but it's probably much easier to start with. There was at one point and may still be an option to not include the complex type. - should I drop useless compiled-in modules? (what I need is a replacement for advanced bash scripting, being able to write more complex scripts and avoid forking tens of processes for things like searching filesystem, formating dates etc.) Yes, definitely. I don't want to re-invent the wheel, but all my attempts at finding Python for embedded systems ended in instructions for embedding Python in another program :-) 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. Well, I would start by looking at what is taking up the space... Cheers, mwh -- C++ is a siren song. It *looks* like a HLL in which you ought to be able to write an application, but it really isn't. -- Alain Picard, comp.lang.lisp ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Minipython
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 loading of extension modules, and link all necessary modules statically. Then, do what Michael Hudson says: find out what is taking up space. size */*.o|sort -n should give a good starting point; on my system, I get [...] 293561416 156 3092878d0 Objects/classobject.o 30663 0 0 3066377c7 Objects/unicodectype.o 33530 480 536 3454686f2 Python/Python-ast.o 336241792 616 360328cc0 Objects/longobject.o 36603 16 288 36907902b Python/ceval.o 367102532 0 39242994a Modules/_sre.o 3916994731032 49674c20a Objects/stringobject.o 52965 0 36 53001cf09 Python/compile.o 661974592 436 71225 11639 Objects/typeobject.o 7411197791160 85050 14c3a Objects/unicodeobject.o Michael already mentioned you can drop unicodeobject if you want to. compile.o would also offer savings, but stripping it might not be easy. Dropping _sre is quite easy. If you manage to drop compile.o, then dropping Python-ast.o (along with the rest of the compiler) should also be possible. unicodectype will go away if the Unicode type goes, but can probably be removed separately. And so on. When you come to a solution that satisfies your needs, don't forget to document it somewhere. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
