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
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?
>
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 m
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
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 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 suggest
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
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 hav
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
> htt
> 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 al
> 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
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
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 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:
> 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 co
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
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
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 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 refere
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
Explici
Amaury Forgeot d'Arc wrote:
Did you use the suppressions file as suggested in Misc/README.valgrind?
Thanks for the suggestion (as well as to Gustavo and Victor), but my
question wasn't about how to suppress the messages, but about why the
messages appear in the first place. I think my last p
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 suggeste
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 supp
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
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 .
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 cert
I get 404 object not found.
On Thu, Nov 27, 2008 at 11:57 PM, Nicole King <[EMAIL PROTECTED]> wrote:
> Dear All,
>
> Apologies that web site was not working earlier. I believe that I've now fixed
> it. The patch can still be found at
> http://www.cats-muvva.net/software/Python-taint-diff-3.0rc3.ta
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
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 tha
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 "importin
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.
>
>
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
sy
32 matches
Mail list logo