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,
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
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
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 ...]
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
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
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,
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
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:
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
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
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
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
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
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
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
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
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/
___
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
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
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
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
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
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
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
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
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
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
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
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
30 matches
Mail list logo
