On Thu, 24 Dec 2009 10:31:09 +0900, "Stephen J. Turnbull"
wrote:
> Martin's point is that the PEP process doesn't *have* "reference"
> implementations. It has *sample* implementations. It may be useful
> to refer to a sample implementation as an example..
Fair enough. But otoh, asking for samp
David Lyon writes:
> > I am just describing the needs and the end user PoV with the reference
> > implementation that happens to be used by *all* tools out there.
>
> That's good. That's what we need right now.
Martin's point is that the PEP process doesn't *have* "reference"
implementations
Martin,
As an application developer, I really stand with Tarek here.
On Wed, 23 Dec 2009 20:07:30 +0100, Tarek Ziadé
wrote:
> 2009/12/23 "Martin v. Löwis" :
>>> I think we want something stronger than that since they were not really
>>> used by
>>> the community and removed and replaced by some
> So that will happen in the code of course, but we need the PEP to state
> clearly
> wether metadata 1.0 and 1.1 should be dropped by implementations or not.
Ok. We should recommend that implementations support these versions
indefinitely. I see no point in dropping them.
But then, this is real
2009/12/23 "Martin v. Löwis" :
>> I think we want something stronger than that since they were not really used
>> by
>> the community and removed and replaced by something better. Using them
>> should raise a warning so developers abandon them, so it would be
>> "don't use 1.1 anymore"
>
> I think
> I think we want something stronger than that since they were not really used
> by
> the community and removed and replaced by something better. Using them
> should raise a warning so developers abandon them, so it would be
> "don't use 1.1 anymore"
I think you are mixing the distutils implement
2009/12/23 "Martin v. Löwis" :
>> The deprecation of the existing Requires/Provides/Obsoletes fields
>> should be more prominent - tucked away below the examples, I missed
>> these notices on the first read through (I only noticed that they
>> actually had been formally deprecated when I got to the
On Dec 23, 2009, at 10:00 AM, Frank Wierzbicki wrote:
> On Mon, Dec 14, 2009 at 5:58 PM, Tarek Ziadé wrote:
>> and for Linux and al, I am not sure but maybe a prefix for
>> Jython/etc.. could be used
>> for all paths.
>>
>> ~/.locale/lib/python/2.6/site-packages/...
>> ~/.locale/jython/lib/pyth
On Mon, Dec 14, 2009 at 5:58 PM, Tarek Ziadé wrote:
> and for Linux and al, I am not sure but maybe a prefix for
> Jython/etc.. could be used
> for all paths.
>
> ~/.locale/lib/python/2.6/site-packages/...
> ~/.locale/jython/lib/python/2.6/site-packages/...
>
> (I didn't digg on how Jython organiz
> The deprecation of the existing Requires/Provides/Obsoletes fields
> should be more prominent - tucked away below the examples, I missed
> these notices on the first read through (I only noticed that they
> actually had been formally deprecated when I got to the summary of
> differences at the en
On Wed, Dec 23, 2009 at 11:18 AM, Tarek Ziadé wrote:
[..]
>
> if a "1.2" field is found and no "1.1" field is found:
> metadata 1.2 is used
> if a "1.1" field is found and no "1.2" field is found:
> metadata 1.1 is used + a warning is displayed
> if a "1.1" field is found and a "1.2" field i
On Wed, Dec 23, 2009 at 3:31 AM, Tres Seaver wrote:
[..]
>>
>> The deprecation of the existing Requires/Provides/Obsoletes fields
>> should be more prominent - tucked away below the examples, I missed
>> these notices on the first read through (I only noticed that they
>> actually had been formall
12 matches
Mail list logo
