On Tue, 08 Aug 2006 12:04:16 -0400, "Phillip J. Eby" <[EMAIL PROTECTED]> wrote:
>
>PEP 302 doesn't need to be changed, since Python now conforms to it again.
>That is, every object in sys.path_importer_cache is either an importer or
>None. It's just that there is an additional type of importer t
At 11:11 AM 8/8/2006 -0400, Jean-Paul Calderone wrote:
>On Fri, 28 Jul 2006 18:00:36 -0400, "Phillip J. Eby"
><[EMAIL PROTECTED]> wrote:
>>At 10:55 PM 7/28/2006 +0200, Martin v. Löwis wrote:
>>>Phillip J. Eby wrote:
>>> > The issue is that a proper fix that caches existence requires adding new
>>
On Fri, 28 Jul 2006 18:00:36 -0400, "Phillip J. Eby" <[EMAIL PROTECTED]> wrote:
>At 10:55 PM 7/28/2006 +0200, Martin v. Löwis wrote:
>>Phillip J. Eby wrote:
>> > The issue is that a proper fix that caches existence requires adding new
>> > types to import.c and thus might appear to be more of a fea
At 10:55 PM 7/28/2006 +0200, Martin v. Löwis wrote:
>Phillip J. Eby wrote:
> > The issue is that a proper fix that caches existence requires adding new
> > types to import.c and thus might appear to be more of a feature. I was
> > therefore reluctant to embark upon the work without some assurance
Phillip J. Eby wrote:
> The issue is that a proper fix that caches existence requires adding new
> types to import.c and thus might appear to be more of a feature. I was
> therefore reluctant to embark upon the work without some assurance that it
> wouldn't be rejected as adding a last-minute f
At 04:07 PM 7/28/2006 -0400, Fred L. Drake, Jr. wrote:
>On Friday 28 July 2006 00:49, Neal Norwitz wrote:
> > Based on this comment, is it really acceptable to just document a
> > behaviour change? ISTM there should really only be 2 choices: fix
> > 2.5 properly or revert the change. This see
On Friday 28 July 2006 00:49, Neal Norwitz wrote:
> Based on this comment, is it really acceptable to just document a
> behaviour change? ISTM there should really only be 2 choices: fix
> 2.5 properly or revert the change. This seemed to be Armin's
> position.
I agree those are the only rea
At 07:33 AM 7/28/2006 +0200, Martin v. Löwis wrote:
>Phillip J. Eby wrote:
> > I'm willing to write code that makes it PEP 302 compliant, if the release
> > manager will bless such an addition. But if that's not acceptable, then
> > somebody needs to produce the necessary documentation updates or
Phillip J. Eby wrote:
> I'm willing to write code that makes it PEP 302 compliant, if the release
> manager will bless such an addition. But if that's not acceptable, then
> somebody needs to produce the necessary documentation updates or revert the
> patch. It absolutely should not be allowed
At 09:49 PM 7/27/2006 -0700, Neal Norwitz wrote:
>On 7/27/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
>>
>>Personally, I would prefer to see it properly fixed in 2.5 rather than
>>having to rip it out. It's more work for me to create the proper fix than
>>it is to just work around it in my code,
On 7/27/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
>
> Personally, I would prefer to see it properly fixed in 2.5 rather than
> having to rip it out. It's more work for me to create the proper fix than
> it is to just work around it in my code, but it seems a more righteous
> labor, if you know
At 12:52 PM 7/27/2006 +0200, Georg Brandl wrote:
>Though beta1 and beta2 shipped with this change nobody reported any bug that
>could be linked to it
Actually, that's no longer true. See: http://python.org/sf/1529871
This is a user-reported bug against 2.5b2, and I have just confirmed that
it
Bob Ippolito wrote:
> Just because it's obscure doesn't mean we should go change how things
> work in a way that's not consistent with the documentation. The
> documentation should change to match the code or vice versa, though I
> really don't have any strong feelings one way or the other.
On Jul 27, 2006, at 3:52 AM, Georg Brandl wrote:
> Armin Rigo wrote:
>> Hi Phillip,
>>
>> On Wed, Jul 26, 2006 at 02:40:27PM -0400, Phillip J. Eby wrote:
>>> If we don't revert it, there are two ways to fix it. One is to
>>> just change
>>> PEP 302 so that the behavior is unbroken by definitio
Phillip J. Eby wrote:
>>sys.path_importer_cache is quite an internal thing
>
> Whose behavior is documented in a PEP.
Correct.
>> and
>>most code, even import hooks, shouldn't have to deal with it.
>
> That doesn't make it unimportant. It's a visible change in specified
> behavior between P
At 12:52 PM 7/27/2006 +0200, Georg Brandl wrote:
>Armin Rigo wrote:
> > Hi Phillip,
> >
> > On Wed, Jul 26, 2006 at 02:40:27PM -0400, Phillip J. Eby wrote:
> >> If we don't revert it, there are two ways to fix it. One is to just
> change
> >> PEP 302 so that the behavior is unbroken by definition
Armin Rigo wrote:
> Hi Phillip,
>
> On Wed, Jul 26, 2006 at 02:40:27PM -0400, Phillip J. Eby wrote:
>> If we don't revert it, there are two ways to fix it. One is to just change
>> PEP 302 so that the behavior is unbroken by definition. :) The other is
>> to actually go ahead and fix it by ad
Hi Phillip,
On Wed, Jul 26, 2006 at 02:40:27PM -0400, Phillip J. Eby wrote:
> If we don't revert it, there are two ways to fix it. One is to just change
> PEP 302 so that the behavior is unbroken by definition. :) The other is
> to actually go ahead and fix it by adding PathImporter and NullI
Neal Norwitz wrote:
> What is the behaviour that was added which broke compliance? What is
> the benefit of the behaviour?
sys.path_importer_cache is now used to cache if a real directory
exists on the filesystem. Previously, a value of None for a given
sys.path entry told find_module that no imp
What is the behaviour that was added which broke compliance? What is
the benefit of the behaviour?
>From your description of fixing the problem, it seems there's some
risk invovled as it's modiyfing import.c, plus adding new features.
What is your recommendation?
n
--
On 7/26/06, Phillip J. Eby
20 matches
Mail list logo
