On Wednesday, February 20, 2013 at 2:48 AM, Chris Jerdonek wrote:
> On Tue, Feb 19, 2013 at 3:16 PM, Daniel Holth (mailto:dho...@gmail.com)> wrote:
> > Sorry, Chris must have meant http://hg.python.org/distlib/ . I was
> > struggling to imagine a world where that is more visible than something on
On Tue, Feb 19, 2013 at 3:16 PM, Daniel Holth wrote:
> Sorry, Chris must have meant http://hg.python.org/distlib/ . I was
> struggling to imagine a world where that is more visible than something on
> bitbucket.
I meant that bringing distlib into http://hg.python.org/cpython/ would
give it more v
On Tue, 19 Feb 2013 20:37:36 -0800
Eli Bendersky wrote:
> On Tue, Feb 19, 2013 at 10:50 AM, Oleg Broytman wrote:
>
> > Hello.
> >
> >This mailing list is to work on developing Python (adding new
> > features to Python itself and fixing bugs); if you're having problems
> > learning, understan
On 2/19/2013 12:33 PM, Demian Brecht wrote:
Comment on patch on issue.
Also, are contributor agreements also required for documentation?
I believe so, especially for substantial patches like yours. Just submit
one and be done with it. You probably should choose the Academic
License. http://
On Tue, Feb 19, 2013 at 10:50 AM, Oleg Broytman wrote:
> Hello.
>
>This mailing list is to work on developing Python (adding new
> features to Python itself and fixing bugs); if you're having problems
> learning, understanding or using Python, please find another forum.
> Probably python-list
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/19/2013 09:37 PM, Paul Moore wrote:
> On 20 February 2013 00:54, Fred Drake wrote:
>> I'd posit that anything successful will no longer need to be added
>> to the standard library, to boot. Packaging hasn't done well
>> there.
>
> distlib may
On 20/02/13 11:54, Fred Drake wrote:
On Tue, Feb 19, 2013 at 6:19 PM, Donald Stufft wrote:
Let's not add anything to the stdlib till it has real world usage. Doing
otherwise is putting the cart before the horse.
I'd posit that anything successful will no longer need to be added to
the standar
On 20 February 2013 00:54, Fred Drake wrote:
> I'd posit that anything successful will no longer need to be added to
> the standard library, to boot. Packaging hasn't done well there.
distlib may be the exception, though. Packaging tools are somewhat
unique because of the chicken and egg issue i
On Tue, Feb 19, 2013 at 6:19 PM, Donald Stufft wrote:
> Let's not add anything to the stdlib till it has real world usage. Doing
> otherwise is putting the cart before the horse.
I'd posit that anything successful will no longer need to be added to
the standard
library, to boot. Packaging hasn't
On Tuesday, February 19, 2013 at 6:16 PM, Daniel Holth wrote:
> Sorry, Chris must have meant http://hg.python.org/distlib/ . I was struggling
> to imagine a world where that is more visible than something on bitbucket.
> Half the comments have been about putting something in stdlib right away,
>
On Tue, Feb 19, 2013 at 5:10 PM, M.-A. Lemburg wrote:
> On 19.02.2013 23:01, Daniel Holth wrote:
> > On Tue, Feb 19, 2013 at 4:34 PM, M.-A. Lemburg wrote:
> >
> >> On 19.02.2013 14:40, Nick Coghlan wrote:
> >>> On Tue, Feb 19, 2013 at 11:23 PM, M.-A. Lemburg
> wrote:
> * PEP 426 doesn't in
On 19.02.2013 23:01, Daniel Holth wrote:
> On Tue, Feb 19, 2013 at 4:34 PM, M.-A. Lemburg wrote:
>
>> On 19.02.2013 14:40, Nick Coghlan wrote:
>>> On Tue, Feb 19, 2013 at 11:23 PM, M.-A. Lemburg wrote:
* PEP 426 doesn't include any mention of the egg distribution format,
even though
On 19.02.2013 14:40, Nick Coghlan wrote:
> On Tue, Feb 19, 2013 at 11:23 PM, M.-A. Lemburg wrote:
>> On 19.02.2013 11:28, Nick Coghlan wrote:
>>> On Tue, Feb 19, 2013 at 7:37 PM, M.-A. Lemburg wrote:
On 17.02.2013 11:11, Nick Coghlan wrote:
I'm not against modernizing the format, but gi
On Tue, Feb 19, 2013 at 4:34 PM, M.-A. Lemburg wrote:
> On 19.02.2013 14:40, Nick Coghlan wrote:
> > On Tue, Feb 19, 2013 at 11:23 PM, M.-A. Lemburg wrote:
> >> * PEP 426 doesn't include any mention of the egg distribution format,
> >> even though it's the most popular distribution format at t
On 19.02.2013 14:40, Nick Coghlan wrote:
> On Tue, Feb 19, 2013 at 11:23 PM, M.-A. Lemburg wrote:
>> * PEP 426 doesn't include any mention of the egg distribution format,
>> even though it's the most popular distribution format at the moment.
>> It should at least include the location of the m
On Tue, Feb 19, 2013 at 2:28 AM, Nick Coghlan wrote:
> On Tue, Feb 19, 2013 at 7:37 PM, M.-A. Lemburg wrote:
>> On 17.02.2013 11:11, Nick Coghlan wrote:
>> I'm not against modernizing the format, but given that version 1.2
>> has been out for around 8 years now, without much following,
>> I think
On Tue, Feb 19, 2013 at 3:25 PM, Paul Moore wrote:
> On 19 February 2013 13:40, Nick Coghlan wrote:
> >> If a tools wants to support metadata 2.0, it has to support all
> >> the complicated stuff as well, i.e. handle the requires fields,
> >> the environment markers and version comparisons/sorti
On 19 February 2013 20:36, Donald Stufft wrote:
> 2. There is currently no code that I am aware of that implements this
> spec. I don't believe distlib does (yet - give Vinay 5 minutes and who
> knows? :-)), pkg_resources as I said implements a different format,
> and distutils2, apart from being
On Tuesday, February 19, 2013 at 3:25 PM, Paul Moore wrote:
> On 19 February 2013 13:40, Nick Coghlan (mailto:ncogh...@gmail.com)> wrote:
> > > If a tools wants to support metadata 2.0, it has to support all
> > > the complicated stuff as well, i.e. handle the requires fields,
> > > the environmen
On 19 February 2013 13:40, Nick Coghlan wrote:
>> If a tools wants to support metadata 2.0, it has to support all
>> the complicated stuff as well, i.e. handle the requires fields,
>> the environment markers and version comparisons/sorting.
>
> Which is what distutils2 can be used for now, and wha
On 2/19/2013 11:06 AM, Daniel Holth wrote:
This feature does something to remedy the setuptools chicken/egg
problem. We have eliminated the egg ;-)
This is the most artfully crafted comment I've seen on topic on this
list for some months! Thanks!
___
On Tue, Feb 19, 2013 at 11:26 AM, Paul Moore wrote:
> On 19 February 2013 13:59, Nick Coghlan wrote:
> > It's OK if people don't want to read the detailed rationale provided
> > for each of the major changes as part of the PEP, or if they want to
> > dispute a particular piece of that rationale.
Hello.
This mailing list is to work on developing Python (adding new
features to Python itself and fixing bugs); if you're having problems
learning, understanding or using Python, please find another forum.
Probably python-list/comp.lang.python mailing list/news group is the
best place; there a
On Tue, Feb 19, 2013 at 12:37 PM, rahul garg wrote:
> Hi.
>
> I downloaded Python 3.3 source, opened up the solution in VS2012 Express for
> Desktop and built the "python" subproject using "Release" and "x64"
> configurations. I now have a "python.exe" in the PCBuild/amd64 subfolder
> that appear
Hi.
I downloaded Python 3.3 source, opened up the solution in VS2012 Express for
Desktop and built the "python" subproject using "Release" and "x64"
configurations. I now have a "python.exe" in the PCBuild/amd64 subfolder that
appears to be working as far as i can see.
I have a few questions:
http://bugs.python.org/issue17145
I'm curious as to whether or not anyone has reviewed the documentation
update I made here.
Context:
Having both memory views and buffers in 2.7 (as well as the C-level API
for each) is confusing. The initial bug report was to implement consistent
behavior for ob
On 19 February 2013 13:59, Nick Coghlan wrote:
> It's OK if people don't want to read the detailed rationale provided
> for each of the major changes as part of the PEP, or if they want to
> dispute a particular piece of that rationale. But merely going "it's
> too complicated!" or "metadata 1.2 f
Hello,
in August 2012 I found a DoS vulnerability in expat and XML libraries in
Python's standard library. Since then I have found several more issues.
I have been working on fixes ever since.
The README of https://pypi.python.org/pypi/defusedxml contains detailed
explanations of my research and
On Tue, Feb 19, 2013 at 9:57 PM, wrote:
>> I've never seen environment markers being used or supported
>> in the wild.
>>
>> I'm not against modernizing the format, but given that version 1.2
>> has been out for around 8 years now, without much following,
>> I think we need to make the implementa
On Tue, Feb 19, 2013 at 11:23 PM, M.-A. Lemburg wrote:
> On 19.02.2013 11:28, Nick Coghlan wrote:
>> On Tue, Feb 19, 2013 at 7:37 PM, M.-A. Lemburg wrote:
>>> On 17.02.2013 11:11, Nick Coghlan wrote:
>>> I'm not against modernizing the format, but given that version 1.2
>>> has been out for aroun
On Feb 19, 2013 6:57 AM, wrote:
> > I've never seen environment markers being used or supported
> > in the wild.
> >
> > I'm not against modernizing the format, but given that version 1.2
> > has been out for around 8 years now, without much following,
> > I think we need to make the implementati
On 19.02.2013 11:28, Nick Coghlan wrote:
> On Tue, Feb 19, 2013 at 7:37 PM, M.-A. Lemburg wrote:
>> On 17.02.2013 11:11, Nick Coghlan wrote:
>> I'm not against modernizing the format, but given that version 1.2
>> has been out for around 8 years now, without much following,
>> I think we need to m
> I've never seen environment markers being used or supported
> in the wild.
>
> I'm not against modernizing the format, but given that version 1.2
> has been out for around 8 years now, without much following,
> I think we need to make the implementation bit a requirement
> before accepting the P
On Tue, Feb 19, 2013 at 8:36 PM, Antoine Pitrou wrote:
> Le Tue, 19 Feb 2013 10:24:15 +,
> Paul Moore a écrit :
>> On Tuesday, 19 February 2013, M.-A. Lemburg wrote:
>>
>> >
>> > The only tool in wide spread use that understands part of the 1.2
>> > data is setuptools/distribute, but it can o
Le Tue, 19 Feb 2013 11:36:09 +0100,
Antoine Pitrou a écrit :
>
> I think Marc-André is right that the acceptability of the standard
> should be judged on the availability of (preferably standard)
> implementations. If the standard isn't implemented, then perhaps it
> means it's too ambitious / to
Le Tue, 19 Feb 2013 10:24:15 +,
Paul Moore a écrit :
> On Tuesday, 19 February 2013, M.-A. Lemburg wrote:
>
> >
> > The only tool in wide spread use that understands part of the 1.2
> > data is setuptools/distribute, but it can only understand the
> > Requires-Dist field of that version of th
On Tue, Feb 19, 2013 at 7:37 PM, M.-A. Lemburg wrote:
> On 17.02.2013 11:11, Nick Coghlan wrote:
> I'm not against modernizing the format, but given that version 1.2
> has been out for around 8 years now, without much following,
> I think we need to make the implementation bit a requirement
> befo
On Tuesday, 19 February 2013, M.-A. Lemburg wrote:
>
> The only tool in wide spread use that understands part of the 1.2 data
> is setuptools/distribute, but it can only understand the Requires-Dist
> field of that version of the spec (only because the 1.1 Requires field was
> deprecated) and inte
On 17.02.2013 11:11, Nick Coghlan wrote:
> FYI
>
>
> -- Forwarded message --
> From: Nick Coghlan
> Date: Sun, Feb 17, 2013 at 8:10 PM
> Subject: PEP 426 is now the draft spec for distribution metadata 2.0
> To: "DistUtils mailing list\"\""
>
>
> The latest draft of PEP 426
39 matches
Mail list logo
