On Sep 19, 2013, at 9:36 AM, Paul Tagliamonte paul...@debian.org wrote:
On Thu, Sep 19, 2013 at 09:27:24AM -0400, Donald Stufft wrote:
Rationale
=
Currently, on systems without a platform package manager and repository,
installing a third-party Python package into a freshly
On Sep 19, 2013, at 9:43 AM, Paul Moore p.f.mo...@gmail.com wrote:
On 19 September 2013 14:27, Donald Stufft don...@stufft.io wrote:
Major changes:
* Removal of the option to fetch pip from PyPI in order not to modify the
trust model of the Python installers
* Consequently rename
On Sep 19, 2013, at 9:50 AM, Antoine Pitrou solip...@pitrou.net wrote:
Le Thu, 19 Sep 2013 09:27:24 -0400,
Donald Stufft don...@stufft.io a écrit :
We've updated PEP453 based on some of the early feedback we've gotten
from -dev and Martin.
Major changes:
* Removal of the option
packages to simply document installing as ``pip install package`` and if it's
not
installed by default on Debian they'll get a good message telling them what they
need to do.
-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
package when a user executes ``pip`` without
+it being installed. Systems that choose this option should ensure that
+the ``pyvenv`` command still installs pip into the virtual environment
+by default.
* Do not remove the bundled copy of pip.
-
Donald Stufft
PGP
/mailman/options/python-dev/donald%40stufft.io
-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Python-Dev mailing list
On Sep 10, 2013, at 11:08 AM, Guido van Rossum gu...@python.org wrote:
Why do several posts in this thread have an Unsubscribe link that tries to
unsubscribe me from the list? (I saw one by Glen, and another one by Donald
Stufft.)
(Come to think of it, what's the point of having an Unbub
in
the news a lot lately :)
If I recall Persona doesn't leak this data like OpenID does, but perhaps Dan
can speak to that better than I can.
-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
signature.asc
Description: Message signed
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/donald%40stufft.io
-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA
On Sep 6, 2013, at 3:34 PM, R. David Murray rdmur...@bitdance.com wrote:
On Fri, 06 Sep 2013 15:17:12 -0400, Donald Stufft don...@stufft.io wrote:
On Sep 6, 2013, at 3:11 PM, R. David Murray rdmur...@bitdance.com wrote:
IMO, single signon is overrated. Especially if one prefers not to make
.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/donald%40stufft.io
-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F
On Sep 5, 2013, at 2:25 PM, Oleg Broytman p...@phdru.name wrote:
On Thu, Sep 05, 2013 at 02:16:29PM -0400, Donald Stufft don...@stufft.io
wrote:
On Sep 5, 2013, at 2:12 PM, Oleg Broytman p...@phdru.name wrote:
I used to use myOpenID and became my own provider using poit[1].
These days I
On Sep 5, 2013, at 2:43 PM, Oleg Broytman p...@phdru.name wrote:
On Thu, Sep 05, 2013 at 02:35:16PM -0400, Donald Stufft don...@stufft.io
wrote:
Persona is the logical successor to OpenID.
OpenID lived a short life and died a quiet death. I'm afraid Persona
wouldn't live even that much
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/donald%40stufft.io
-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9
%40stufft.io
-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Python-Dev mailing list
Python-Dev@python.org
https
On Jun 16, 2013, at 1:52 AM, Ben Finney ben+pyt...@benfinney.id.au wrote:
Donald Stufft don...@stufft.io writes:
On Jun 15, 2013, at 10:45 PM, Ben Finney ben+pyt...@benfinney.id.au wrote:
Is there anything I can do to keep the ‘enum’ package online for
continuity but make it clear
I never want to iterate, but I love slice syntax and indexing. Don't think you
can have that w/o being able to loop over it can you? Maybe I'm just thinking
slow since I just woke up.
On Jun 15, 2013, at 8:53 AM, Tres Seaver tsea...@palladion.com wrote:
-BEGIN PGP SIGNED MESSAGE-
under that name anyways.
-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Python-Dev mailing list
Python-Dev@python.org
On Jun 15, 2013, at 10:45 PM, Ben Finney ben+pyt...@benfinney.id.au wrote:
Ethan Furman et...@stoneleaf.us writes:
So I have the stdlb 3.4 Enum backported for both earlier 3.x and back
to 2.4 in the 2.x series.
I would like to put this on PyPI, but the `enum` name is already
taken.
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/donald%40stufft.io
This is probably more appropriate for distutils-sig, but does it happen every
time? or did it just happen once?
-
Donald
On Jun 3, 2013, at 1:58 AM, Benjamin Peterson benja...@python.org wrote:
2013/6/2 Donald Stufft don...@stufft.io:
As of right now, as far as I can tell, Python does not validate HTTPS
certificates by default. As far as I can tell this is because there is no
guaranteed certificates available
released Pythons so we'd just need to watch them for blacklisting
certs and roll that into a security update.
-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
signature.asc
Description: Message signed with OpenPGP using GPGMail
On Jun 3, 2013, at 12:52 PM, Ethan Furman et...@stoneleaf.us wrote:
On 06/03/2013 09:43 AM, Donald Stufft wrote:
On Jun 3, 2013, at 5:51 AM, Antoine Pitrou wrote:
The problem with a slightly outdated CA store is that it can be a
security risk.
Tracking the Mozilla store isn't difficult
On Jun 3, 2013, at 12:36 PM, Barry Warsaw ba...@python.org wrote:
On Jun 03, 2013, at 01:20 AM, Donald Stufft wrote:
So I would like to propose that CPython adopt the Mozilla SSL certificate
list and include it in core, and switch over the API's so that they verify
HTTPS by default
On Jun 3, 2013, at 12:52 PM, Barry Warsaw ba...@python.org wrote:
On Jun 03, 2013, at 03:12 AM, Donald Stufft wrote:
That's fine with me too. My only reason for wanting to use the system certs
first is so if someone has modified their system certs (say to include a
corporate cert
package that does it.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/donald%40stufft.io
-
Donald Stufft
PGP
On Jun 3, 2013, at 1:07 PM, Barry Warsaw ba...@python.org wrote:
On Jun 03, 2013, at 02:17 PM, Donald Stufft wrote:
I'd actually prefer for Linux to not use the bundled certs when installed
from a package manager because it should use the system certs, but people
can't depend on certs
:
http://mail.python.org/mailman/options/python-dev/donald%40stufft.io
What about OSX?
-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
signature.asc
Description: Message signed with OpenPGP using GPGMail
/options/python-dev/donald%40stufft.io
-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Python-Dev mailing list
Python-Dev
/python-dev/donald%40stufft.io
-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Python-Dev mailing list
Python-Dev
On Jun 3, 2013, at 5:51 PM, Antoine Pitrou solip...@pitrou.net wrote:
On Mon, 3 Jun 2013 17:47:31 -0400
Donald Stufft don...@stufft.io wrote:
On Jun 3, 2013, at 5:41 PM, Antoine Pitrou solip...@pitrou.net wrote:
On Mon, 3 Jun 2013 22:31:40 +0100
Paul Moore p.f.mo...@gmail.com wrote
On Jun 3, 2013, at 6:01 PM, Paul Moore p.f.mo...@gmail.com wrote:
On 3 June 2013 22:46, Donald Stufft don...@stufft.io wrote:
Also, we should consider the issue for application users. Suppose I'm using
a Python application that downloads something from the web. I upgrade to
3.4
if possible, and if that doesn't work falling back to the
bundled certificates. That way the various Linux distros can easily have their
copies of Python depend soley on their built in certs, but Windows, OSX, Source
compiles etc will all still have a fallback value.
-
Donald Stufft
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/donald%40stufft.io
-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B
://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/donald%40stufft.io
-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
signature.asc
Description: Message signed with OpenPGP
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Barry Warsaw wrote:
On Mar 05, 2013, at 02:11 AM, Donald Stufft wrote:
Doesn't setuptools/distribute already have a setup.py test command?
That seems like the easiest way forward?
Yes, and in theory it can make `python setup.py test` work well
On Tuesday, March 5, 2013 at 2:02 AM, Lennart Regebro wrote:
On Tue, Mar 5, 2013 at 1:41 AM, Robert Collins
robe...@robertcollins.net (mailto:robe...@robertcollins.net) wrote:
So that is interesting, but its not sufficient to meet the automation
need Barry is calling out, unless all test
On Wednesday, February 20, 2013 at 6:08 PM, Antoine Pitrou wrote:
It's not a distributed DoS issue, it's a severe DoS vulnerabilities. A
single 1 kB XML document can kill virtually any machine, even servers
with more than hundred GB RAM.
Assuming an attacker can inject arbitrary XML.
On Wednesday, February 20, 2013 at 6:23 PM, Christian Heimes wrote:
We can add a function to the XML package tree that enables all restrictions:
* limit expansion depths of nested entities
* limit total amount of expanded chars
* disable external entity expansion
* optionally force expat to
On Wednesday, February 20, 2013 at 6:22 PM, Antoine Pitrou wrote:
On Wed, 20 Feb 2013 18:21:22 -0500
Donald Stufft donald.stu...@gmail.com (mailto:donald.stu...@gmail.com)
wrote:
On Wednesday, February 20, 2013 at 6:08 PM, Antoine Pitrou wrote:
It's not a distributed DoS issue, it's
On Tuesday, February 19, 2013 at 3:25 PM, Paul Moore wrote:
On 19 February 2013 13:40, Nick Coghlan ncogh...@gmail.com
(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
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 Wednesday, February 20, 2013 at 2:48 AM, Chris Jerdonek wrote:
On Tue, Feb 19, 2013 at 3:16 PM, Daniel Holth dho...@gmail.com
(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
On Friday, February 8, 2013 at 10:39 AM, Chris Withers wrote:
Hi All,
Just had a bit of an embarrassing incident in some code where I did:
sometotal =+ somevalue
I'm guessing this gets parsed as sometotal = +somevalue
I'm curious why this syntax is allowed? I'm sure there are good
On Tuesday, December 11, 2012 at 3:31 PM, Barry Warsaw wrote:
On Dec 11, 2012, at 04:23 PM, Lennart Regebro wrote:
This PEP is also available on github:
https://github.com/regebro/tz-pep/blob/master/pep-04tz.txt
wget returns some html gobbledygook. Why-oh-why github?!'
wget
On Saturday, December 8, 2012 at 9:11 PM, Steven D'Aprano wrote:
Why would a software package called Spam install a top-level module called
Jam rather than Spam? Isn't the whole point of Python packages to solve
this namespace problem?
Conflicts doesn't really solve file based conflicts as PJ
On Friday, December 7, 2012 at 8:33 PM, Nick Coghlan wrote:
That's not what a Conflicts field is for. It's to allow a project to say
*they don't support* installing in parallel with another package. It doesn't
matter why it's unsupported, it's making a conflict perceived by the project
On Thursday, December 6, 2012 at 6:28 AM, Vinay Sajip wrote:
Donald Stufft donald.stufft at gmail.com (http://gmail.com) writes:
Never mind the Obsoletes information - even the more useful Requires-Dist
information is not exposed via PyPI, even though it appears to be stored
On Wednesday, December 5, 2012 at 4:10 PM, PJ Eby wrote:
My point is that this can only work if the obsoleting is effectively
just a rename, in which case the field should be renames, or better
still, renamed-to on the originating package.
Arguing over Obsoletes vs Renames is a massive
On Wednesday, December 5, 2012 at 6:18 PM, Barry Warsaw wrote:
On Dec 05, 2012, at 06:07 PM, Donald Stufft wrote:
If you're installing B you've prescribed trust to that author. If you don't
trust the author then why are you installing (and then executing) code
they wrote.
What
On Wednesday, December 5, 2012 at 2:13 AM, PJ Eby wrote:
On Mon, Dec 3, 2012 at 2:43 PM, Daniel Holth dho...@gmail.com
(mailto:dho...@gmail.com) wrote:
How to use Obsoletes:
The author of B decides A is obsolete.
A releases an empty version of itself that Requires: B
B
On Tuesday, November 20, 2012 at 4:48 PM, PJ Eby wrote:
Words
I agree that obsoletes is terrible, it's very specific and not something we
particularly require. I'd much rather just have a generic conflicts. ___
Python-Dev mailing list
On Monday, November 19, 2012 at 7:37 PM, PJ Eby wrote:
Can we maybe kill Provides-Dist and its associated baggage first, though?
I would love to kill Provides-Dist. The biggest question there is how do you
handle it's
functionality? If someone needs setuptools but they have distribute
Other languages seem to get along fine without it. Even the OS
managers which have it don't allow it to be used to masquerade
as another project, only to make generic virtual packages (e.g. email).
On Monday, November 19, 2012 at 7:43 PM, Daniel Holth wrote:
Does it really have baggage? I
On Monday, November 19, 2012 at 8:08 PM, Daniel Holth wrote:
The distro repos are centrally managed, too. Try getting setuptools to
provide a virtual package just because you want to fork.. and then update the
dependent packages?
Daniel Holth
Sorry didn't mean to make it sound like I
it alone.
Daniel Holth
On Nov 19, 2012, at 7:49 PM, Donald Stufft donald.stu...@gmail.com
(mailto:donald.stu...@gmail.com) wrote:
Other languages seem to get along fine without it. Even the OS
managers which have it don't allow it to be used to masquerade
as another project, only
On Monday, November 19, 2012 at 8:35 PM, Toshio Kuratomi wrote:
On Mon, Nov 19, 2012 at 07:49:41PM -0500, Donald Stufft wrote:
Other languages seem to get along fine without it. Even the OS
managers which have it don't allow it to be used to masquerade
as another project, only to make
On Monday, November 19, 2012 at 9:01 PM, Nick Coghlan wrote:
Look more closely at the docs for Obsoletes in RPM, not just those for
Provides. Being able to transparently replace an existing package with a
renamed one that installs files with the same names is certainly part of the
On Monday, November 19, 2012 at 9:24 PM, Daniel Holth wrote:
Mostly it seems a bit silly to have so much conversations about parts of the
pep that remain unchanged from previously accepted versions...
Well, I think the PEP should describe what we expect to be implemented *shrug*.
Either we
$ pypy -m timeit 'dict()'
10 loops, best of 3: 0.000811 usec per loop
$ pypy -m timeit '{}'
10 loops, best of 3: 0.000809 usec per loop
$ pypy -m timeit 'def md(**kw): return kw; md()'
1 loops, best of 3: 0.0182 usec per loop
$ pypy -m timeit -s 'def md(**kw): return
Distutils is not good enough for the vast majority of people. Even for what it
does, it does not do it well. It is a library that is user hostile and buggy.
It was
a fine first revision of packaging, but the Python community needs something
better.
On Tuesday, November 13, 2012 at 11:31 AM,
On Friday, September 14, 2012 at 12:30 PM, Daniel Holth wrote:
Description: is the only multi-line field in the metadata. It is
almost never needed at runtime. It would be great for performance and
simplify the parser to just put it in another file.
License also can be multiline I believe,
On Thursday, September 13, 2012 at 5:38 AM, Antoine Pitrou wrote:
Most people use distutils / packaging as
an application, not a library. If you provide only a subset of
the necessary features, people won't use packaging.
Not that I think current usage patterns matter since moving from
On Thursday, September 13, 2012 at 7:32 AM, Tarek Ziadé wrote:
Yeah but we've been too ambitious.
Here's my proposal - actually it's Nick's proposal but I want to make
sure we're on the same
page wrt steps, and I think that addresses Antoine concerns
1. create a new package, called
On Friday, August 31, 2012 at 6:48 AM, Martin v. Löwis wrote:
3. There should be a specification of how collisions between extension
fields and standard fields are resolved. E.g. if I have
Extension: Home
Home-page: http://www.python.org
is Home-page the extension field or the PEP 345
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
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 it
On Tuesday, August 28, 2012 at 9:09 AM, Nick Coghlan wrote:
On Tue, Aug 28, 2012 at 10:57 PM, Daniel Holth dho...@gmail.com
(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
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 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 further
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
On Tuesday, August 28, 2012 at 11:05 AM, Nick Coghlan wrote:
On Wed, Aug 29, 2012 at 12:53 AM, Donald Stufft donald.stu...@gmail.com
(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
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 later about not
I think json probably makes the most sense, it's already part of the stdlib for
2.6+
and while it has some issues with human editablity, there's no reason why this
json
file couldn't be auto generated from another data structure by the package
creation tool
that exists outside of the stdlib (or
On Friday, June 22, 2012 at 5:22 AM, Dag Sverre Seljebotn wrote:
What Bento does is have one metadata file for the source-package, and
another metadata file (manifest) for the built-package. The latter is
normally generated by the build process (but follows a standard
nevertheless). Then
On Friday, June 22, 2012 at 5:52 AM, Dag Sverre Seljebotn wrote:
The reason PyPI isn't one big security risk is that packages are built
from source, and so you can have some confidence that backdoors would be
noticed and highlighted by somebody.
Having a common standards for binary
On Friday, June 22, 2012 at 6:20 AM, David Cournapeau wrote:
If by manifest you mean the build manifest, then that's not desirable:
the manifest contains the explicit filenames, and those are
platform/environment specific. You don't want this to be user-facing.
It appears I misunderstood the
Ideally authors will be signing their packages (using gpg keys). Of course
how to distribute keys is an exercise left to the reader.
On Friday, June 22, 2012 at 11:48 AM, Vinay Sajip wrote:
martin at v.loewis.de (http://v.loewis.de) writes:
See above. Also notice that such signing is
On Friday, June 22, 2012 at 12:54 PM, Alexandre Zani wrote:
Key distribution is the real issue though. If there isn't a key
distribution infrastructure in place, we might as well not bother with
signatures. PyPI could issue x509 certs to packagers. You wouldn't be
able to verify that the
Not at the moment, but I could gather them up and make them public later today.
They
are very rough draft at the moment.
On Friday, June 22, 2012 at 1:09 PM, Alexandre Zani wrote:
On Fri, Jun 22, 2012 at 9:56 AM, Donald Stufft donald.stu...@gmail.com
(mailto:donald.stu...@gmail.com) wrote
On Friday, June 22, 2012 at 4:55 PM, Terry Reedy wrote:
Every time windows users download and install a binary, they are taking
a chance. I try to use a bit more sense than some people, but I know it
is not risk free. There *is* a third party site that builds installers,
but should I
On Thursday, June 21, 2012 at 4:01 PM, Paul Moore wrote:
End users should not need packaging tools on their machines.
Sort of riffing on this idea, I cannot seem to find a specification for what a
Python
package actually is. Maybe the first effort should focus on this instead of
arguing one
On Thursday, June 21, 2012 at 7:34 PM, Alex Clark wrote:
Hi,
On 6/21/12 5:38 PM, Donald Stufft wrote:
On Thursday, June 21, 2012 at 4:01 PM, Paul Moore wrote:
End users should not need packaging tools on their machines.
Sort of riffing on this idea, I cannot seem to find
On Friday, June 22, 2012 at 1:05 AM, Nick Coghlan wrote:
- I reject setup.cfg, as I believe ini-style configuration files are
not appropriate for a metadata format that needs to include file
listings and code fragments
- I reject bento.info (http://bento.info), as I think if we accept
On Wednesday, June 20, 2012 at 2:36 AM, Victor Stinner wrote:
What is the status of the third party module on PyPI (distutils2)?
Does it contain all fixes done in the packaging module? Does it have
exactly the same API? Does it support Python 2.5 to 3.3, or maybe also
2.4?
How is the
On Tuesday, March 13, 2012 at 9:31 AM, Paul Moore wrote:
On 13 March 2012 03:48, C. Titus Brown c...@msu.edu (mailto:c...@msu.edu)
wrote:
I feel like there's a middle ground where stable, long-term go-to modules
could
be mentioned, though. I don't spend a lot of time browsing PyPI, but
Even if a MemoryException is raised I believe that is still a fundamental
change in the documented contract of dictionary API. I don't believe there is a
way to fix this without breaking someones application. The major differences I
see between the two solutions is that counting will break
On Friday, January 20, 2012 at 2:36 PM, Tres Seaver wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/20/2012 02:04 PM, Donald Stufft wrote:
Even if a MemoryException is raised I believe that is still a
fundamental change in the documented contract of dictionary API
20, 2012 at 5:11 PM, Terry Reedy wrote:
On 1/20/2012 2:51 PM, Donald Stufft wrote:
I think the counting collision is at best a bandaid and not a proper fix
stemmed from a desire to not break existing applications on a bugfix
release ...
My opinion of counting is better than yours
I don't always post to python-dev, but when I do I ask for braces.
On Friday, December 9, 2011 at 4:43 PM, Antoine Pitrou wrote:
Dear Cedric,
I'm guessing you drank too much (perhaps you are training for New Year's
Eve), ate some bad sausages or are simply very self-complacent.
401 - 490 of 490 matches
Mail list logo
