Re: [Python-Dev] __import__ problems
Mart Somermaa wrote: The variant proposed by Hrvoje Niksic: __import__(modname) mod = sys.modules[modname] looks more appealing, but comes with the drawback that sys has to be imported for that purpose only. That is not a real drawback, as sys will certainly be present in the system, so the importing boils down to a dict lookup and a variable assignment. Having said that, I'd add that I found the behavior of __import__ counter-intuitive, but assumed there's a good reason for it. If I hadn't known about sys.modules beforehand, I would have probably gone the chained-getattr route as well. ___ 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] Python for windows.
Mark Hammond wrote: Greg writes: Mark Hammond wrote: The only conflict I see here is the requirement to install into \Program Files Doesn't that just mean that if an OEM decides to preinstall it, they need to put it in Program Files? They're at liberty to do that. I'm not very familiar with the OEM process, but I believe the software is automatically installed after the first boot from MSI files supplied by the OEM partner (so technically, its not pre-installed at all). I don't know enough about how that works to know how easy it would be to override that option during installation - hopefully Gerald will fill us in with more details... [Hrm - looking closer at that HTML link I sent before, it says specifically Per-machine installs must install to Program Files by default in order to pass this test case - that seems pretty clear...] Given that the links in Gerald's examples were under Program Files, I had assumed that HP were tweaking the installer at least that much... Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- ___ 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] Python for windows.
On 2008-11-28 00:15, Christian Heimes wrote: Martin v. Löwis wrote: All, and not to start flames, but I still do not understand why applink.c isn't included in python's main (conditionally) instead of expecting users, many of them novices, to do the build. ??? One reason is that I don't know what applink is, and why I should care about it. (I may have known in the past, but then I have forgotten since). Applink is roughly explained at http://www.openssl.org/support/faq.html#PROG2. The matter was discussed about half a year ago but no decision was made. See http://mail.python.org/pipermail/python-dev/2008-March/077424.html applink.c is just a table of integer constants to function pointers. It makes mixing of different CRTs secure. You'll get the idea after reading the file, Martin. A similar approach could be useful for Python, too. So that's why we don't see a problem with pyOpenSSL. From the first link: Your application must link against the same version of the Win32 C-Runtime against which your openssl libraries were linked. The default version for OpenSSL is /MD - Multithreaded DLL. and later on: As per 0.9.8 the above limitation is eliminated for .DLLs. ... Instead of re-compiling OpenSSL toolkit, ...[you have to add] install-root/include/openssl/applink.c ... to your application project or simply #include-d in one [and only one] of your application source files. ... [Note that] it is as important to add CRYPTO_malloc_init prior first call to OpenSSL. In our eGenix pyOpenSSL distribution we ship the Windows DLLs for OpenSSL together with the compiled PYDs for pyOpenSSL - all compiled using the same compiler settings. Python for Windows does the same, so there should be no issue either. From the comment it appears that you only see problems, if you try to use those extensions from a Python executable that was compiled using different settings, e.g. an embedded Python interpreter. Note that neither Python nor pyOpenSSL call the required CRYPTO_malloc_init() prior to using the other SSL APIs, so even including applink.c would not help - you have to add this call to the used extensions as well. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Nov 28 2008) Python/Zope Consulting and Support ...http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ 2008-11-12: Released mxODBC.Connect 0.9.3 http://python.egenix.com/ Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 ___ 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 under valgrind
A friend pointed out that running python under valgrind (simply valgrind python) produces a lot of invalid read errors. Reading up on Misc/README.valgrind only seems to describe why uninitialized reads should occur, not invalid ones. For example: $ valgrind python [... lots of output ...] ==31428== Invalid read of size 4 ==31428==at 0x808EBDF: PyObject_Free (in /usr/bin/python2.5) ==31428==by 0x810DD0A: (within /usr/bin/python2.5) ==31428==by 0x810DD34: PyNode_Free (in /usr/bin/python2.5) ==31428==by 0x80EDAD9: PyRun_InteractiveOneFlags (in /usr/bin/python2.5) ==31428==by 0x80EDDB7: PyRun_InteractiveLoopFlags (in /usr/bin/python2.5) ==31428==by 0x80EE515: PyRun_AnyFileExFlags (in /usr/bin/python2.5) ==31428==by 0x80595E6: Py_Main (in /usr/bin/python2.5) ==31428==by 0x8058961: main (in /usr/bin/python2.5) ==31428== Address 0x43bf010 is 3,112 bytes inside a block of size 6,016 free'd ==31428==at 0x4024B4A: free (vg_replace_malloc.c:323) ==31428==by 0x8059C07: (within /usr/bin/python2.5) ==31428==by 0x80EDAA5: PyRun_InteractiveOneFlags (in /usr/bin/python2.5) ... valgrind claims that Python reads 4 bytes inside a block on which free() has already been called. Is valgrind wrong, or is Python really doing that? Googling revealed previous reports of this, normally answered by a reference to README.valgrind. But README.valgrind justifies reading from ununitialized memory, which doesn't help me understand how reading from the middle of a block of freed memory (more precisely, memory on which the libc free() has already been called) would be okay. I suppose valgrind could be confused by PyFree's pool address validation that intentionally reads the memory just before the allocated block, and incorrectly attributes it to a previously allocated (and hence freed) block, but I can't prove that. Has anyone investigated this kind of valgrind report? ___ 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] Python under valgrind
Le Friday 28 November 2008 13:56:34 Amaury Forgeot d'Arc, vous avez écrit : Hrvoje Niksic wrote: A friend pointed out that running python under valgrind (simply valgrind python) produces a lot of invalid read errors. (...) PyFree (...) Did you use the suppressions file as suggested in Misc/README.valgrind? --suppressions=Misc/valgrind-python.supp To be able to use the suppressions, Python have to be compiled with Py_USING_MEMORY_DEBUGGER. Edit Object/obmalloc.c near line 680. -- Victor Stinner aka haypo http://www.haypocalc.com/blog/ ___ 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] __import__ problems
Mart Somermaa wrote: I meant that you have to import sys only to access sys.modules (i.e. importing sys may not be necessary otherwise). I understand that, but I'm arguing that that's a non-problem. Importing sys is a regular thing in Python, not an exception. You need sys to get to sys.argv, sys.exit, sys.stdout, etc. -- it's not like sys is an infrequently used module. Since sys is always present, importing it is not an efficiency problem, either. mod = __import__(modname, submodule=True) with import sys __import__(modname) mod = sys.modules[modname] import sys is normally located near the beginning of the file (and needed by other things), so the actual code snippet would really contain only those two lines, which don't strike me as bad. Ideally, __import__ would simply return the tail imported module in the first place, but I don't think introducing a boolean keyword argument really improves the design. ___ 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] __import__ problems
Mart Somermaa wrote: The variant proposed by Hrvoje Niksic: __import__(modname) mod = sys.modules[modname] looks more appealing, but comes with the drawback that sys has to be imported for that purpose only. That is not a real drawback, as sys will certainly be present in the system, so the importing boils down to a dict lookup and a variable assignment. I meant that you have to import sys only to access sys.modules (i.e. importing sys may not be necessary otherwise). As Hrvoje has pointed out, 'sys' is part of the internal interpreter machinery - it's there as soon as the interpreter starts. The import call for it just grabs it out of the module cache and creates a reference to it in the current namespace. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- ___ 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] __import__ problems
The variant proposed by Hrvoje Niksic: __import__(modname) mod = sys.modules[modname] looks more appealing, but comes with the drawback that sys has to be imported for that purpose only. That is not a real drawback, as sys will certainly be present in the system, so the importing boils down to a dict lookup and a variable assignment. I meant that you have to import sys only to access sys.modules (i.e. importing sys may not be necessary otherwise). Compare mod = __import__(modname, submodule=True) with import sys __import__(modname) mod = sys.modules[modname] ___ 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] Python under valgrind
2008/11/28 Hrvoje Niksic [EMAIL PROTECTED] A friend pointed out that running python under valgrind (simply valgrind python) produces a lot of invalid read errors. Reading up on Misc/README.valgrind only seems to describe why uninitialized reads should occur, not invalid ones. For example: $ valgrind python [... lots of output ...] ==31428== Invalid read of size 4 ==31428==at 0x808EBDF: PyObject_Free (in /usr/bin/python2.5) ==31428==by 0x810DD0A: (within /usr/bin/python2.5) ==31428==by 0x810DD34: PyNode_Free (in /usr/bin/python2.5) ==31428==by 0x80EDAD9: PyRun_InteractiveOneFlags (in /usr/bin/python2.5) ==31428==by 0x80EDDB7: PyRun_InteractiveLoopFlags (in /usr/bin/python2.5) ==31428==by 0x80EE515: PyRun_AnyFileExFlags (in /usr/bin/python2.5) ==31428==by 0x80595E6: Py_Main (in /usr/bin/python2.5) ==31428==by 0x8058961: main (in /usr/bin/python2.5) ==31428== Address 0x43bf010 is 3,112 bytes inside a block of size 6,016 free'd ==31428==at 0x4024B4A: free (vg_replace_malloc.c:323) ==31428==by 0x8059C07: (within /usr/bin/python2.5) ==31428==by 0x80EDAA5: PyRun_InteractiveOneFlags (in /usr/bin/python2.5) ... valgrind claims that Python reads 4 bytes inside a block on which free() has already been called. Is valgrind wrong, or is Python really doing that? Googling revealed previous reports of this, normally answered by a reference to README.valgrind. But README.valgrind justifies reading from ununitialized memory, which doesn't help me understand how reading from the middle of a block of freed memory (more precisely, memory on which the libc free() has already been called) would be okay. I suppose valgrind could be confused by PyFree's pool address validation that intentionally reads the memory just before the allocated block, and incorrectly attributes it to a previously allocated (and hence freed) block, but I can't prove that. Has anyone investigated this kind of valgrind report? I can't answer your question directly, but I can tell you that whenever I have to debug memory problems with python extensions is usually use my own python compiled with --with-pydebug --without-pymalloc. It really helps with valgrind. -- Gustavo J. A. M. Carneiro INESC Porto, Telecommunications and Multimedia Unit The universe is always one step beyond logic. -- Frank Herbert ___ 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 under valgrind
Hrvoje Niksic wrote: A friend pointed out that running python under valgrind (simply valgrind python) produces a lot of invalid read errors. Reading up on Misc/README.valgrind only seems to describe why uninitialized reads should occur, not invalid ones. For example: [...] I suppose valgrind could be confused by PyFree's pool address validation that intentionally reads the memory just before the allocated block, and incorrectly attributes it to a previously allocated (and hence freed) block, but I can't prove that. Has anyone investigated this kind of valgrind report? Did you use the suppressions file as suggested in Misc/README.valgrind? --suppressions=Misc/valgrind-python.supp -- Amaury Forgeot d'Arc ___ 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] __import__ problems
Nick Coghlan wrote: As Hrvoje has pointed out, 'sys' is part of the internal interpreter machinery - it's there as soon as the interpreter starts. The import call for it just grabs it out of the module cache and creates a reference to it in the current namespace. I understand that, but Explicit is better than implicit. -- non-explicit import sys and __import__(modname) to access sys.modules[modname] Simple is better than complex. -- three lines for a common use case instead of one Readability counts. -- why is sys imported in this WSGI app (that shouldn't generally touch any of the common sys.argv, sys.stdout etc)?! (500 lines later) aha, to access sys.modules There should be one-- and preferably only one --obvious way to do it. -- should I use the 3-line idiom? should I use the getattr() idiom? Ideally, __import__() should support the only obvious way. In short, the three-line version doesn't convey the intent in an obvious way and does more work than is necessary. ___ 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] __import__ problems
On Fri, 28 Nov 2008 11:59:39 pm Mart Somermaa wrote:
Nick Coghlan wrote:
As Hrvoje has pointed out, 'sys' is part of the internal
interpreter machinery - it's there as soon as the interpreter
starts. The import call for it just grabs it out of the module
cache and creates a reference to it in the current namespace.
I understand that, but
Explicit is better than implicit.
-- non-explicit import sys and __import__(modname) to access
sys.modules[modname]
Importing sys is explicit. You actually say import sys -- how much
more explicit can you get?
Simple is better than complex.
-- three lines for a common use case instead of one
Simple doesn't mean shorter. The three line idiom is simple, because
each line is simple and they combine in a simple way.
import sys # does the same thing import sys always does
__import__(modname) # does the same thing __import__ always does
modobj = sys.modules[modname] # just a normal lookup
Readability counts.
-- why is sys imported in this WSGI app (that shouldn't generally
touch any of the common sys.argv, sys.stdout etc)?!
(500 lines later) aha, to access sys.modules
sys is imported for the same reason that any module is imported: because
some functionality provided by the module is needed. I don't want to
import a module is not, on its own, a good enough reason to add extra
complexity to a function.
There's no readability loss by importing a module at the top of the
program and not using that module until some 500 lines later. That's
normal for modules.
There should be one-- and preferably only one --obvious way to do it.
-- should I use the 3-line idiom? should I use the getattr() idiom?
Although that way may not be obvious at first unless you're Dutch.
I would say the three line idiom is obvious. At least, it's obvious now
that I've learnt that there is a sys.modules.
Ideally, __import__() should support the only obvious way.
In short, the three-line version doesn't convey the intent in an
obvious way and does more work than is necessary.
I disagree with both those claims.
However, having disagreed with your arguments, I will say this: I think
a tail argument to __import__ would be more elegant:
z = __import__('x.y.z', tail=True) # or submodule in your initial post
I think that it is unintuitive that __import__(x.y.z) returns module x
instead of z. When I say get me the book inside the box inside the
wardrobe, I expect to get the book, not the entire wardrobe! So even
though I disagree with all your criticisms of the three-line idiom, I
think there is an elegance to your idea that the three-line idiom
doesn't have. I'm +0.5 on the idea of an extra argument that says, no,
really, just give me the book, I don't need the wardrobe.
But I think if you want to convince others, you're going to need to come
up with more positive reasons for preferring the extra argument rather
than rely on dubious criticisms of the three-line idiom: the
three-liner is short, simple, obvious, readable and explicit, but your
solution would be even shorter, more readable, and more explicit. I
think it loses on the obvious and possibly on simple. The advantage is
you've already done the work rather than expecting somebody else to do
it for you.
Good luck.
--
Steven
___
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] __import__ problems
Steven D'Aprano wrote:
However, having disagreed with your arguments, I will say this: I think
a tail argument to __import__ would be more elegant:
z = __import__('x.y.z', tail=True) # or submodule in your initial post
I think that it is unintuitive that __import__(x.y.z) returns module x
instead of z. When I say get me the book inside the box inside the
wardrobe, I expect to get the book, not the entire wardrobe! So even
though I disagree with all your criticisms of the three-line idiom, I
think there is an elegance to your idea that the three-line idiom
doesn't have. I'm +0.5 on the idea of an extra argument that says, no,
really, just give me the book, I don't need the wardrobe.
May I point you to the two leading underscores? The name '__import__'
clearly suggests that the function is part of Python's internals. By
definition all attributes of the form __*__ are not meant to be used
directly. Any suggestion to change the arguments of __import__() are
futile. It's not going to happen unless the feature is required by
Python's internal import system.
However I agree that something should be done here. I suggest to add a
function to the imp module that does what you are trying to archive with
tail=True.
Christian
___
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] Python 2.6/3.0, IEEE 754 floating point semantics and S60
On Thu, Nov 27 08 at 7:27:03PM +, Mark Dickinson wrote: Many thanks for your input! No problem! I don't like hearing folks from Nokia implying that our code is rubbish :) I think IEEE 754 is relevant. :-) Thanks for hunting down all that information! I'm in agreement: we should fix this so that it works for 17 digits. I've had a chat with our team's architect and it's not as awkward as I had assumed: the hardware floating point doesn't actually get in the way as the function in question only uses our software-implemented high precision real class, not float/double types. Whether our implementation is actually *correct* if you ask it for more digits is an interesting question, though. It might be already :) Are you aware of any compliance suite, test vectors, etc we could 'borrow' to verify our implementation? We would certainly like to verify this. I'm going to raise a defect for the binary-decimal conversion issue, and see what we can do about sorting this out for future OS versions. -- Torne Wuff [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
[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (11/21/08 - 11/28/08) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue number. Do NOT respond to this message. 2217 open (+42) / 14059 closed (+33) / 16276 total (+75) Open issues with patches: 735 Average duration of open issues: 710 days. Median duration of open issues: 2108 days. Open Issues Breakdown open 2199 (+42) pending18 ( +0) Issues Created Or Reopened (77) ___ Thread local storage and PyGILState_* mucked up by os.fork() 11/28/08 http://bugs.python.org/issue1683reopened christian.heimes Py_SAFE_DOWNCAST in FILE_TIME_to_time_t_nsec failing 11/21/08 http://bugs.python.org/issue4379created kevinwatters patch Deepcopy of functools.partial gives wierd exception 11/21/08 http://bugs.python.org/issue4380created kfitch Cannot declare multiple classes via exec when inside a function. 11/21/08 CLOSED http://bugs.python.org/issue4381created kfitch test_dbm_dumb fails due to character encoding issue on Mac OS X 11/21/08 CLOSED http://bugs.python.org/issue4382created oefe UnboundLocalError when IDLE cannot connect to its subprocess 11/21/08 CLOSED http://bugs.python.org/issue4383created amaury.forgeotdarc patch, needs review Add a warnings.showwarning replacement for logging 11/21/08 http://bugs.python.org/issue4384created brett.cannon easy Py_Object_HEAD_INIT in Py3k 11/21/08 http://bugs.python.org/issue4385created ncoghlan A binary file should show b in its mode11/22/08 CLOSED http://bugs.python.org/issue4386created amaury.forgeotdarc patch, needs review binascii b2a functions accept strings (unicode) as data 11/22/08 http://bugs.python.org/issue4387created tjreedy test_cmd_line fails on MacOS X 11/22/08 http://bugs.python.org/issue4388created MrJean1 Uninstaller Lacks an Icon11/22/08 http://bugs.python.org/issue4389created Retro Using subprocess.STDOUT causes AttributeError11/22/08 CLOSED http://bugs.python.org/issue4390created nelchael optparse: use proper gettext plurals forms 11/22/08 http://bugs.python.org/issue4391created dwayne patch incorrect parameter name for collections.namedtuple 11/23/08 CLOSED http://bugs.python.org/issue4392created none_00 Portability fixes in longobject.c11/23/08 http://bugs.python.org/issue4393created marketdickinson patch make the storage of the password optional in .pypirc (using the 11/23/08 http://bugs.python.org/issue4394created tarek patch Document auto __ne__ generation; provide a use case for non-triv 11/23/08 http://bugs.python.org/issue4395created tjreedy parser module fails to validate with statements. 11/23/08 CLOSED http://bugs.python.org/issue4396created dbinger patch test_socket fails occassionaly in teardown:
Re: [Python-Dev] Python 2.6/3.0, IEEE 754 floating point semantics and S60
On Fri, Nov 28, 2008 at 4:48 PM, Torne Wuff [EMAIL PROTECTED] wrote: Thanks for hunting down all that information! I'm in agreement: we should fix this so that it works for 17 digits. Cool. I think this should make porting easier (and not just for Python, either). Are you aware of any compliance suite, test vectors, etc we could 'borrow' to verify our implementation? Not really. Some googling turns up a few links, notably this one: http://www.cant.ua.ac.be/ieeecc754.html It looks a little old, and possibly unmaintained, but even if you can't get the C driver to compile then the test vectors might still be usable. Python doesn't require that the platform is IEEE 754 compliant, so there isn't much IEEE 754-specific stuff in the Python test suite. Thank you again for your messages; it's *very* useful to know that (1) IEEE 754 compliance is intended, and (2) there are people at Symbian who care about fixing non-compliance issues. It makes the currently fairly insane activity of trying to write cross-platform floating-point C code that's going to work on any system that Python might ever be run on just that little bit saner. :) Mark ___ 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] __import__ problems
On Sat, 29 Nov 2008 03:30:49 am Christian Heimes wrote: ... May I point you to the two leading underscores? The name '__import__' clearly suggests that the function is part of Python's internals. By definition all attributes of the form __*__ are not meant to be used directly. What about __doc__, __name__ and __slots__, to mention just a few? I believe that __import__() is the recommended way to import a module known only at runtime. The docs also don't seem to agree with your assertion that __import__ is not to be touched. On the contrary: The function is invoked by the import statement. It mainly exists so that you can replace it with another function that has a compatible interface... http://docs.python.org/library/functions.html Far from saying Do Not Touch, the docs say Please, go ahead and replace __import__ if needed. If the OP wants import x.y.z to load module z instead of x, it seems to me that is exactly the problem __import__ is designed to allow him to do. Any suggestion to change the arguments of __import__() are futile. It's not going to happen unless the feature is required by Python's internal import system. That may very well be true, but I don't know why you're dumping on me. It wasn't my suggestion to change __import__. I merely said I could see some advantages to it. I spent most of my post telling the OP why I thought his arguments were wrong! -- Steven ___ 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] Python 2.6/3.0, IEEE 754 floating point semantics and S60
On Fri, Nov 28, 2008 at 4:48 PM, Torne Wuff [EMAIL PROTECTED] wrote: Are you aware of any compliance suite, test vectors, etc we could 'borrow' to verify our implementation? See also the ucbtest package, available from http://www.netlib.org/fp/ ___ 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] __import__ problems
On Fri, Nov 28, 2008 at 9:47 AM, Steven D'Aprano [EMAIL PROTECTED] wrote: On Sat, 29 Nov 2008 03:30:49 am Christian Heimes wrote: ... May I point you to the two leading underscores? The name '__import__' clearly suggests that the function is part of Python's internals. By definition all attributes of the form __*__ are not meant to be used directly. What about __doc__, __name__ and __slots__, to mention just a few? Excellent examples of not meant to be used directly. __slots__, like most other special names (though not all) is meant to be *bound* directly when you need to (which for __slots__ is much more rarely than for many other special names, mostly those of special methods that often need to be overridden); but none of these are meant to be *used* in normal cases -- introspection should normally be done via provided tools such as the help built-in and standard library modules such as pydoc and inspect. It's pretty rare to have to write your own introspection framework, and the dunder-names are internal machinery exposed for those rare use cases. I believe that __import__() is the recommended way to import a module known only at runtime. The docs also don't seem to agree with your assertion that __import__ is not to be touched. On the contrary: The function is invoked by the import statement. It mainly exists so that you can replace it with another function that has a compatible interface... http://docs.python.org/library/functions.html Yes, that documentation predates the current generation of import hooks which almost remove the need for such trickery. Far from saying Do Not Touch, the docs say Please, go ahead and replace __import__ if needed. If the OP wants import x.y.z to load module z instead of x, it seems to me that is exactly the problem __import__ is designed to allow him to do. import x.y.z, the import statement, has well defined semantics relying on __import__'s interface -- it does load z as well as, inevitably, its parent y and grandparent x. If __import__ was replaced with a version with NON compatible interface, import x.y.z would break. Any suggestion to change the arguments of __import__() are futile. It's not going to happen unless the feature is required by Python's internal import system. That may very well be true, but I don't know why you're dumping on me. It wasn't my suggestion to change __import__. I merely said I could see some advantages to it. I spent most of my post telling the OP why I thought his arguments were wrong! And now we're telling you why we think your arguments are also wrong -- what else do you expect from python-dev after all? Alex ___ 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] Python under valgrind
I suppose valgrind could be confused by PyFree's pool address validation that intentionally reads the memory just before the allocated block, and incorrectly attributes it to a previously allocated (and hence freed) block, but I can't prove that. I agree this is the likely cause. To prove it, you will need to find the line number associated with 0x808EBDF. Either you available debug information, or disassemble PyObject_Free to determine what specific read operation is causing the report. Most likely, you find it is inside Py_ADDRESS_IN_RANGE, in the attempt to read pool-arenaindex. 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] __import__ problems
If __import__ was replaced with a version with NON compatible interface,
import x.y.z would break.
But it is not. The proposed __import__(name, submodule=True) has
a compatible interface. All tests pass with
http://bugs.python.org/file12136/issue4438.diff .
As for the imp approach, I've alternatively implemented
imp.import_module() that imports tail modules in
http://bugs.python.org/file12147/imp_import_module.diff
(colour diff in http://dpaste.com/hold/94431/).
IMHO the functionality duplication with __import__ is ugly, but
if it is desired that __import__ does not change (even in
backwards-compatible way), so be it.
The signature and behaviour is as follows:
---
import_module(name, globals, level) - module
Import the tail module, given dotted module hierarchy in 'name'.
'globals' only determines the package context and is not
modified. 'level' specifies whether to use absolute or relative
imports.
from imp import import_module
import_module('foo.bar.baz')
module 'foo.bar.baz' from 'foo/bar/baz/__init__.py'
---
But I'm still +1 for adding 'tail'/'submodule'/'tailmodule'
argument to __import__ instead of providing an almost identical
copy in imp.import_module().
Let me know which of the approaches is desired (if any) and I'll
add tests and update docs.
___
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] __import__ problems
On Fri, Nov 28, 2008 at 11:07, Mart Somermaa [EMAIL PROTECTED] wrote:
If __import__ was replaced with a version with NON compatible interface,
import x.y.z would break.
But it is not. The proposed __import__(name, submodule=True) has
a compatible interface. All tests pass with
http://bugs.python.org/file12136/issue4438.diff .
But as people have pointed out, __import__ is not meant to be used
directly, and so adding keyword arguments just to make it so it can
be used directly is the wrong approach.
As for the imp approach, I've alternatively implemented
imp.import_module() that imports tail modules in
http://bugs.python.org/file12147/imp_import_module.diff
(colour diff in http://dpaste.com/hold/94431/).
IMHO the functionality duplication with __import__ is ugly, but
if it is desired that __import__ does not change (even in
backwards-compatible way), so be it.
The signature and behaviour is as follows:
---
import_module(name, globals, level) - module
Import the tail module, given dotted module hierarchy in 'name'.
'globals' only determines the package context and is not
modified. 'level' specifies whether to use absolute or relative
imports.
from imp import import_module
import_module('foo.bar.baz')
module 'foo.bar.baz' from 'foo/bar/baz/__init__.py'
---
But I'm still +1 for adding 'tail'/'submodule'/'tailmodule'
argument to __import__ instead of providing an almost identical
copy in imp.import_module().
But you are assuming you need to keep those arguments like global and
level, and you really don't if you have the API handle the low-level
details as needed. This could really turn into:
import_module(name, package)
and that gives the machinery everything it needs to do an import,
including relative imports. Then all you need to do is:
import_module('.baz', __package__)
and everything works.
Let me know which of the approaches is desired (if any) and I'll
add tests and update docs.
The old-hands on python-dev know this is where I plug my import
rewrite vaporware. It will be in 3.1, and as part of it there will be
a new API for handling direct imports. Jacob Kaplan-Moss and I have
talked about Django's need for this as PyCon so I am very aware of
needing this API and it will be addressed in the simplest way possible
(heck, the __import__ API might actually become a wrapper around the
simpler API in the end). And since nothing can go into 3.0 anyway,
there is no need to rush into solving this right now.
-Brett
___
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] __import__ problems
Mart Somermaa wrote: But it is not. The proposed __import__(name, submodule=True) has a compatible interface. All tests pass with http://bugs.python.org/file12136/issue4438.diff . Your approach complicates the interface. Every implementation of Python and every replacement __import__ would have to implement the additional argument, too. There is simply no need to make the interface more complex when an additional, trivial function does the same job. As for the imp approach, I've alternatively implemented imp.import_module() that imports tail modules in http://bugs.python.org/file12147/imp_import_module.diff (colour diff in http://dpaste.com/hold/94431/). IMHO the functionality duplication with __import__ is ugly, but if it is desired that __import__ does not change (even in backwards-compatible way), so be it. It's not a duplication of functionality. __import__() implements exactly the functionality that is required by Python's import system. Anything else can be implemented on top of it. We simply prefer divide 'n conquer over mingle 'n mix. :) Christian ___ 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] __import__ problems
Mart Somermaa wrote: But I'm still +1 for adding 'tail'/'submodule'/'tailmodule' argument to __import__ instead of providing an almost identical copy in imp.import_module(). Let me know which of the approaches is desired (if any) and I'll add tests and update docs. Have you considered using runpy.run_module() instead? i.e. do you actually need the resulting module object, or just the global namespace produced by running its code? If the latter, then run_module() is a much better way of going about it as it has (slightly) fewer side effects on the import system's internals. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- ___ 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] __import__ problems
On Sat, 29 Nov 2008 05:20:01 am Alex Martelli wrote: On Fri, Nov 28, 2008 at 9:47 AM, Steven D'Aprano [EMAIL PROTECTED] wrote: On Sat, 29 Nov 2008 03:30:49 am Christian Heimes wrote: ... May I point you to the two leading underscores? The name '__import__' clearly suggests that the function is part of Python's internals. By definition all attributes of the form __*__ are not meant to be used directly. What about __doc__, __name__ and __slots__, to mention just a few? Excellent examples of not meant to be used directly. [snip] We obviously have different ideas about what that means, because I agree with everything you say but disagree with the conclusion. The idiom if __name__ == '__main__' is very common; and I frequently have scripts that print __doc__ if given a --help command line option. And as you say, __slots__ is meant to be bound directly. I believe that __import__() is the recommended way to import a module known only at runtime. The docs also don't seem to agree with your assertion that __import__ is not to be touched. On the contrary: The function is invoked by the import statement. It mainly exists so that you can replace it with another function that has a compatible interface... http://docs.python.org/library/functions.html Yes, that documentation predates the current generation of import hooks which almost remove the need for such trickery. Should this be reported as a documentation bug? Given the new import hooks, would it be fair to say that the main reason for __import__ is to use it to import a module whose name is only known at runtime? -- Steven ___ 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] __import__ problems
Steven D'Aprano wrote: Should this be reported as a documentation bug? Given the new import hooks, would it be fair to say that the main reason for __import__ is to use it to import a module whose name is only known at runtime? Only known at runtime, and for some reason you want an actual module object rather than just the module's global namespace (since you can use runpy.run_module() if you only need the latter). At the very least, the __import__ docs should probably be updated to point to run_module() as an alternative approach, so a doc issue is probably a good idea. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- ___ 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] __import__ problems
On Fri, Nov 28, 2008 at 6:56 PM, Nick Coghlan [EMAIL PROTECTED] wrote: Steven D'Aprano wrote: Should this be reported as a documentation bug? Given the new import hooks, would it be fair to say that the main reason for __import__ is to use it to import a module whose name is only known at runtime? Only known at runtime, and for some reason you want an actual module object rather than just the module's global namespace (since you can use runpy.run_module() if you only need the latter). At the very least, the __import__ docs should probably be updated to point to run_module() as an alternative approach, so a doc issue is probably a good idea. This sounds wrong to me. run_module() runs the module each time it is called. __import__ has all the semantics of the import statement (by definition -- it is almost a tautology :-) in that it first tries to see if the module is already imported. Pointing to run_module() as an alternative just perpetuates the misunderstanding (alas fairly common amongst casual users) about what exactly import does. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] __import__ problems
Guido van Rossum wrote: On Fri, Nov 28, 2008 at 6:56 PM, Nick Coghlan [EMAIL PROTECTED] wrote: Steven D'Aprano wrote: Should this be reported as a documentation bug? Given the new import hooks, would it be fair to say that the main reason for __import__ is to use it to import a module whose name is only known at runtime? Only known at runtime, and for some reason you want an actual module object rather than just the module's global namespace (since you can use runpy.run_module() if you only need the latter). At the very least, the __import__ docs should probably be updated to point to run_module() as an alternative approach, so a doc issue is probably a good idea. This sounds wrong to me. run_module() runs the module each time it is called. __import__ has all the semantics of the import statement (by definition -- it is almost a tautology :-) in that it first tries to see if the module is already imported. Pointing to run_module() as an alternative just perpetuates the misunderstanding (alas fairly common amongst casual users) about what exactly import does. Ah, good point. I guess it depends on the specific use case... Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- ___ 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] __import__ problems
On Sat, 29 Nov 2008 01:56:00 pm Nick Coghlan wrote: Steven D'Aprano wrote: Should this be reported as a documentation bug? Given the new import hooks, would it be fair to say that the main reason for __import__ is to use it to import a module whose name is only known at runtime? Only known at runtime, and for some reason you want an actual module object rather than just the module's global namespace (since you can use runpy.run_module() if you only need the latter). At the very least, the __import__ docs should probably be updated to point to run_module() as an alternative approach, so a doc issue is probably a good idea. Bug report is here: http://bugs.python.org/issue4457 Based on Guido's comments, I haven't mentioned run_module(). -- Steven ___ 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] __import__ problems
Mart Somermaa wrote: But it is not. The proposed __import__(name, submodule=True) has a compatible interface. Actually, it's not. Keep in mind that __import__ isn't a particular function, it's a defined interface to a family of functions. If that interface is extended, any replacement __import__ functions will be required to conform to the new interface, and existing ones will no longer be valid. -- Greg ___ 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
