On Wed, Aug 29, 2012 at 2:45 PM, Guido van Rossum wrote:
> Hm. I would be fine with the edits proposed, no need to bother others. But
> please do use the Hg repo. :-)
Indeed :)
(Also, as described in PEP 1, any core committer can act as a PEP
editor - the p...@python.org address is most useful w
Hm. I would be fine with the edits proposed, no need to bother others. But
please do use the Hg repo. :-)
On Tuesday, August 28, 2012, Chris Angelico wrote:
> On Wed, Aug 29, 2012 at 2:36 PM, Nick Coghlan
> >
> wrote:
> > Sending a patch to the PEP editors (p...@python.org ) or
> posting it to
>
On Wed, Aug 29, 2012 at 2:36 PM, Nick Coghlan wrote:
> Sending a patch to the PEP editors (p...@python.org) or posting it to
> the tracker is likely the best option. However, in the general case,
> we don't worry too much about minor errors in accepted and final PEPs
> - once the PEP is implemente
On Wed, Aug 29, 2012 at 2:03 PM, Chris Angelico wrote:
> What's the procedure for making trivial edits to a PEP? I was
> (re)reading PEP 393 and found a couple of typos (PyCompactObject s/be
> PyCompactUnicodeObject and "differs form length" s/be "from"). Can I
> edit them directly in the web site
On Wed, Aug 29, 2012 at 1:58 PM, Chris Jerdonek
wrote:
> Is there a list somewhere of the IRC nicks of the core developers that
> use IRC (and who wish to be listed) alongside their real names? If
> there is no such list, has there ever been discussion on python-dev of
> creating such a list?
No
On Tue, Aug 28, 2012 at 10:58 PM, Chris Jerdonek
wrote:
> Is there a list somewhere of the IRC nicks of the core developers that
> use IRC (and who wish to be listed) alongside their real names? If
> there is no such list, has there ever been discussion on python-dev of
> creating such a list?
I
What's the procedure for making trivial edits to a PEP? I was
(re)reading PEP 393 and found a couple of typos (PyCompactObject s/be
PyCompactUnicodeObject and "differs form length" s/be "from"). Can I
edit them directly in the web site's SVN repo, or should a patch be
submitted?
Apologies for the
Is there a list somewhere of the IRC nicks of the core developers that
use IRC (and who wish to be listed) alongside their real names? If
there is no such list, has there ever been discussion on python-dev of
creating such a list?
--Chris
___
Python-Dev
On Tue, 28 Aug 2012 15:00:57 -0400
Brett Cannon wrote:
> Should there be a Misc/NEWS entry since we are in rc mode?
Well, I didn't ask for 3.3.0 inclusion, since this is a very minor fix.
Regards
Antoine.
--
Software development and contracting: http://pro.pitrou.net
___
Should there be a Misc/NEWS entry since we are in rc mode?
On Tue, Aug 28, 2012 at 2:13 PM, antoine.pitrou
wrote:
> http://hg.python.org/cpython/rev/454dceb5fd56
> changeset: 78790:454dceb5fd56
> parent: 78788:06497bbdf4fe
> user:Antoine Pitrou
> date:Tue Aug 28 20:10:18 2
On Tue, Aug 28, 2012 at 08:19:08PM +0200, "\"Martin v. L?wis\""
wrote:
> Am 28.08.12 19:15, schrieb Oleg Broytman:
> >> The RFC database itself has expiration dates on specifications,
> >> namely on I-D documents (internet drafts). The expire 6 months
> >> after their initial publication, unless
Am 28.08.12 19:15, schrieb Oleg Broytman:
>> The RFC database itself has expiration dates on specifications,
>> namely on I-D documents (internet drafts). The expire 6 months
>> after their initial publication, unless renewed.
>
> Does that expiration mean something?
It's explained in RFC 202
On Tue, Aug 28, 2012 at 06:36:40PM +0200, "\"Martin v. L?wis\""
wrote:
> Am 28.08.12 17:38, schrieb R. David Murray:
> >I don't recall any RFC registries that have expiration dates for
> >entries. Are there any?
>
> The RFC database itself has expiration dates on specifications,
> namely on I-D
On Tue, 28 Aug 2012 18:47:16 +0200, =?ISO-8859-15?Q?=22Martin_v=2E_L=F6wis=22?=
wrote:
> Am 28.08.12 18:27, schrieb R. David Murray:
> > The problem Donald is asking about is: the old registration expires,
> > and a *new* registration is entered with a different meaning, but
> > packages stil
Am 28.08.12 17:30, schrieb Daniel Holth:
> Are you really willing to unpack and validate PKG-INFO on every
> archive that is uploaded to pypi?
Users should run the "register" command, which will provide the
metadata information. Also, the UI needs to be extended to allow
to fill out and edit meta
Am 28.08.12 18:27, schrieb R. David Murray:
> The problem Donald is asking about is: the old registration expires,
> and a *new* registration is entered with a different meaning, but
> packages still exist on PyPI that have the key with the old meaning.
> That seems likely to happen in practice.
Am 28.08.12 17:38, schrieb R. David Murray:
I don't recall any RFC registries that have expiration dates for
entries. Are there any?
The RFC database itself has expiration dates on specifications,
namely on I-D documents (internet drafts). The expire 6 months
after their initial publication, u
On Tue, 28 Aug 2012 18:08:51 +0200, =?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=
wrote:
> Am 28.08.12 17:17, schrieb Donald Stufft:
> > If the point of a registry is
> > to remove ambiguity from what any particular key means, won't expiring
> > and allowing reregistration of an in use name (even if it's
Am 28.08.12 17:17, schrieb Donald Stufft:
What do you do with packages that have already been uploaded with
requires-unicode-version once it expires?
Who is "I" in this case? The PyPI installation? Mark the keys in the
database as expired, and stop displaying them. If the key is restored,
and t
On Tue, 28 Aug 2012 11:17:08 -0400, Donald Stufft
wrote:
> On Tuesday, August 28, 2012 at 11:07 AM, "Martin v. Löwis" wrote:
>
> > > What happens when it expires? Is that name freed up for future use?
> >
> >
> > Yes, exactly.
> >
> > > I
> > > think that freeing up the name is likely to
On Tue, Aug 28, 2012 at 10:47 AM, "Martin v. Löwis" wrote:
>>> Prepare for a ten-year period of acceptance - so it
>>> would be good to be sure that no further additions are desired within
>>> the next ten years before seeking approval for the PEP.
>>
>>
>> However, this point I really don't agree
On Tuesday, August 28, 2012 at 11:07 AM, "Martin v. Löwis" wrote:
> > What happens when it expires? Is that name freed up for future use?
>
>
> Yes, exactly.
>
> > I
> > think that freeing up the name is likely to be a bad idea since we can't go
> > backwards in time (as you alluded to lat
On Tuesday, August 28, 2012 at 11:05 AM, Nick Coghlan wrote:
> On Wed, Aug 29, 2012 at 12:53 AM, Donald Stufft (mailto:donald.stu...@gmail.com)> wrote:
>
> Please, don't. The software and infrastructure to run PyPI exists.
> Some level of namespacing makes sense to separate out extension
> manage
Am 28.08.12 16:53, schrieb Donald Stufft:
On Tuesday, August 28, 2012 at 10:43 AM, "Martin v. Löwis" wrote:
I'm happy for PyPI to host such a registry. A specificaion for the
registry should be part of the PEP for the 1.3 format, but I would
propose this structure (without having researched in
On Wed, Aug 29, 2012 at 12:53 AM, Donald Stufft wrote:
> On Tuesday, August 28, 2012 at 10:43 AM, "Martin v. Löwis" wrote:
>
> I'm happy for PyPI to host such a registry. A specificaion for the
> registry should be part of the PEP for the 1.3 format, but I would
> propose this structure (without h
And if changes like this are added now, they will be included in 3.2.4
but not in 3.3.0. Is this bad?
This is the standard for any security fix: such a fix would be added to
3.1.6, 3.2.4, 3.3.1, and 3.4.0, but not to 3.2.3 or 3.3.0.
So
version(A) > version(B)
does not imply
has_fix(A, F)
On Tuesday, August 28, 2012 at 10:43 AM, "Martin v. Löwis" wrote:
>
> I'm happy for PyPI to host such a registry. A specificaion for the
> registry should be part of the PEP for the 1.3 format, but I would
> propose this structure (without having researched in detail what
> other registries f
Prepare for a ten-year period of acceptance - so it
would be good to be sure that no further additions are desired within
the next ten years before seeking approval for the PEP.
However, this point I really don't agree with. The packaging ecosystem
is currently evolving outside the standard libr
But note that the RFC also says that the preferred solution to the
problem that X-fields are intended to solve is an easily accessible
name registry and a simple registration procedure. If Martin's "be
prepared for a ten-year period to acceptance" is serious, what should
be done about such a regi
Am 28.08.12 14:28, schrieb Daniel Holth:
On Tue, Aug 28, 2012 at 8:07 AM, Donald Stufft wrote:
I personally think that at a minimum we should have X-Fields that
get moved into the normal METADATA file, and personally I would
prefer to just drop the X- prefix completely.
That is my preference
On Tue, Aug 28, 2012 at 11:48 PM, Donald Stufft wrote:
> On Tuesday, August 28, 2012 at 9:41 AM, Nick Coghlan wrote:
>
> The only thing I really care about is the namespacing, for the same
> reasons the IETF wrote RFC 6648, as Petri linked earlier [1].
> Establishing proper name registration rules
On Tuesday, August 28, 2012 at 9:41 AM, Nick Coghlan wrote:
>
> The only thing I really care about is the namespacing, for the same
> reasons the IETF wrote RFC 6648, as Petri linked earlier [1].
> Establishing proper name registration rules can categorically
> eliminate a bunch of problems furthe
On Tue, Aug 28, 2012 at 11:23 PM, Donald Stufft wrote:
> To be more specific, there is setup.cfg (which I dislike for other reasons),
> and
> then there is METADATA. setup.cfg is an ini file but METADATA is a simple
> key: value file with a flat namespace so any namespacing you want to do in
> MET
On Tue, Aug 28, 2012 at 11:20 PM, Daniel Holth wrote:
> Wheel is a little different because once it's installed it is no
> longer a wheel, but it makes a decent example. That's not even
> repetition, it's just longer tag names. Repetition is having one
> Classifier: line for every trove classifier
On Tuesday, August 28, 2012 at 9:09 AM, Nick Coghlan wrote:
>
> It does have the advantage that tools for manipulating the format can
> remain dumber, but that doesn't seem like *that* much of an advantage,
> especially since any such benefit could be eliminated completely by
> just switching to a
On Tue, Aug 28, 2012 at 9:09 AM, Nick Coghlan wrote:
> On Tue, Aug 28, 2012 at 10:57 PM, Daniel Holth wrote:
>> How about
>>
>> Extensions are fields that start with a pypi-registered name followed
>> by a hyphen. A file that contains extension fields declares them with
>> Extension: name :
>>
>>
On Tuesday, August 28, 2012 at 9:09 AM, Nick Coghlan wrote:
> On Tue, Aug 28, 2012 at 10:57 PM, Daniel Holth (mailto:dho...@gmail.com)> wrote:
> > How about
> >
> > Extensions are fields that start with a pypi-registered name followed
> > by a hyphen. A file that contains extension fields declare
On Tuesday, August 28, 2012 at 8:28 AM, Nick Coghlan wrote:
>
> Agreed, and this is the kind of thing a v1.3 metadata PEP could
> define. It just needs to be properly namespaced, and the obvious
> namespacing mechanism is PyPI project names.
The biggest reason I have against namespacing them is i
On Tue, Aug 28, 2012 at 10:57 PM, Daniel Holth wrote:
> How about
>
> Extensions are fields that start with a pypi-registered name followed
> by a hyphen. A file that contains extension fields declares them with
> Extension: name :
>
> Extension: pypiname
> pypiname-Field: value
The repetition se
On Tue, Aug 28, 2012 at 10:33 PM, Daniel Holth wrote:
> Wheel deals with this somewhat by including a
>
> Packager: bdist_wheel
>
> line in WHEEL so that you can deal with packager-specific bugs.
Right, but the problem with that is it's defining a couple of *new*
namespaces to manage:
- the filen
How about
Extensions are fields that start with a pypi-registered name followed
by a hyphen. A file that contains extension fields declares them with
Extension: name :
Extension: pypiname
pypiname-Field: value
___
Python-Dev mailing list
Python-Dev@pyth
On Tue, Aug 28, 2012 at 10:28 PM, Daniel Holth wrote:
> That is my preference as well. The standard library basically ignores
> every metadata field or metadata file inside or outside of metadata
> currently, so where is the harm changing the official document to read
> "you may add new metadata f
On Tue, Aug 28, 2012 at 8:28 AM, Nick Coghlan wrote:
> On Tue, Aug 28, 2012 at 10:07 PM, Donald Stufft
> wrote:
>> I personally think that at a minimum we should have X-Fields that
>> get moved into the normal METADATA file, and personally I would
>> prefer to just drop the X- prefix completely.
On Tue, Aug 28, 2012 at 10:07 PM, Donald Stufft wrote:
> I personally think that at a minimum we should have X-Fields that
> get moved into the normal METADATA file, and personally I would
> prefer to just drop the X- prefix completely.
Hell no. We've been down this road with setuptools and it *s
On Tue, Aug 28, 2012 at 8:07 AM, Donald Stufft wrote:
> I personally think that at a minimum we should have X-Fields that
> get moved into the normal METADATA file, and personally I would
> prefer to just drop the X- prefix completely.
That is my preference as well. The standard library basically
I personally think that at a minimum we should have X-Fields that
get moved into the normal METADATA file, and personally I would
prefer to just drop the X- prefix completely.
I think any spec which doesn't include first class support for
extending it with new metadata is going to essentially kic
On Tue, Aug 28, 2012 at 9:04 PM, Daniel Holth wrote:
> Setuptools just uses path.exists() when it needs a particular file and will
> not bother parsing pkg-info at all if it can help it. The metadata edits for
> 1.2 fold some of those files into metadata.
You can't use path.exists() on metadata
On Aug 28, 2012, at 1:20 AM, Nick Coghlan wrote:
> On Tue, Aug 28, 2012 at 6:29 AM, "Martin v. Löwis" wrote:
>> Am 27.08.12 16:56, schrieb Daniel Holth:
>>> Metadata 1.2 is nearly 8 years old and it's Accepted but not Final. Is
>>> it better to continue editing it, or create a new PEP for Metada
48 matches
Mail list logo
