On May 02, 2013, at 10:57 PM, Antoine Pitrou wrote:
>On Thu, 2 May 2013 13:48:24 -0700
>> The problem with (5) is this: you use some library that exports an
>> enumeration, and you want to use pickling. Now you depend on the way the
>> library implemented - if it used the convenience API, you can'
On May 03, 2013, at 09:14 AM, Nick Coghlan wrote:
>> The other issue is your proposal to have a class-based convenience syntax
>akin to (correct me if I got this wrong):
>>
>> class Animal(Enum):
>> __values__ = 'cat dog'
>
>I would suggest moving the field names into the class header for a clas
On May 03, 2013, at 11:06 AM, Nick Coghlan wrote:
>> User input should qualify, and using getattr(EnumClass, user_input) will get
>> you an AttributeError instead of a ValueError if user_input is not valid,
>> but surely you don't mind that small difference. ;)
>
int(getattr(C(), "__str__"))
On May 03, 2013, at 07:40 PM, Steven D'Aprano wrote:
>The problem is that this is not an expression, it is a statement. The
>advantage of the convenience function is not just that it is shorter, but
>that it is an expression.
Exactly right, but let's stop calling it the "convenience API" and inst
On May 05, 2013, at 03:43 PM, Guido van Rossum wrote:
>I'll let Eli or Ethan respond to this. It sounds fine to me to support
>you with some kind of hook in the spec, even though I personally would
>rather assign my enum values explicitly (I'm old-fashioned that way
>:-).
Assuming the picklabilit
On May 06, 2013, at 02:51 PM, Nick Coghlan wrote:
>Enums are the same - they carve out a subtree in the type hierarchy
>that *doesn't* behave the same as the standard tree anchored directly
>on type. This *is* going to cause conflicts with meta-tools that only
>handle ordinary types - the trick is
On May 05, 2013, at 06:44 AM, Ethan Furman wrote:
> to easily create enums when prototyping or at the interactive prompt (I'll
> use it all the time -- it's convenient! ;)
+1billion
(That's literally the number of times I've used the functional API when
discussion various aspects of enum behavio
On May 09, 2013, at 09:24 AM, Guido van Rossum wrote:
>+1. This is a good one. While adding module=__name__ is actually more
>typing than passing __name__ + '.Color' as the class name, the current
>proposal (parsing for dots) makes it very attractive to do the wrong thing
>and hardcode the module
On May 09, 2013, at 04:01 PM, Guido van Rossum wrote:
>I have reviewed the latest version of PEP 435 and I see that it is
>very good. I hereby declare PEP 435 as Accepted. Congratulations go to
>Barry, Eli and Ethan for pulling it through one of the most thorough
>reviewing and bikeshedding proces
On May 10, 2013, at 05:14 PM, Nick Coghlan wrote:
> I 396 Module Version Numbers Warsaw
I do want to eventually return to this PEP, but I probably won't any time
soon.
-Barry
___
Python-Dev mailing list
Python-Dev@py
On May 10, 2013, at 09:19 AM, Guido van Rossum wrote:
>>> S 3142 Add a "while" clause to generator expressions Britton
>>
>> I had the impression that this had more or less been rejected. I suppose I
>> could try to dig up the discussion.
>
>I didn't know there was a PEP for that. I
On May 12, 2013, at 04:49 PM, Raymond Hettinger wrote:
>After the long design effort for the enum module, I'm sure there will be a
>forthcoming effort to apply them pervasively throughout the standard library.
We usually, explicitly, try not to do such wholesale adoptions in the stdlib
when new f
I am looking into a particularly vexing Python problem on Ubuntu that
manifests in several different ways. I think the problem is the same one
described in http://bugs.python.org/issue13146 and I sent a message on the
subject to the ubuntu-devel list:
https://lists.ubuntu.com/archives/ubuntu-devel
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On May 15, 2013, at 06:06 PM, Tres Seaver wrote:
>On 05/15/2013 04:58 PM, Barry Warsaw wrote:
>> This leads me to hypothesize that the bug is due to an as yet
>> unidentified race condition during installation of Python source co
On May 16, 2013, at 08:33 AM, Nick Coghlan wrote:
>Personally, I would be suspicious of developmental web services doing
>auto-reloading while an installer is recompiling the world. I don't have
>enough context to be sure how plausible that is as a possible explanation,
>though.
It's possible tha
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On May 16, 2013, at 06:22 PM, Christian Heimes wrote:
>Are you able to reproduce the issue? Perhaps you could use inotify to
>track down file activity. It shouldn't affect timing much and you can
>track if more than one process it writing to the sam
On May 16, 2013, at 09:44 AM, Ethan Furman wrote:
>Is it happening on the same machines? If so, perhaps a daemon to monitor
>those files and then scream and shout when one changes. Might help track
>down what's going on at the time. (Yeah, that does sound like saying
>'inotify' but with more wo
On May 16, 2013, at 02:19 PM, Guido van Rossum wrote:
>Now consider the following scenario. It involves *three* processes.
>
>- Two unrelated processes both start and want to import the same module.
>- They both see the .pyc file is missing/corrupt and decide to write it.
>- The first process fini
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On May 16, 2013, at 11:48 PM, Tres Seaver wrote:
>I can confirm at least that I have seen this problem within the last two
>weeks on Ubuntu boxes unrelated to the thw Debian / Ubuntu build
>infrastruction.
Hi Tres. If you see this happen, *please*
On May 17, 2013, at 12:10 AM, Thomas Wouters wrote:
>The 'unknown type codes' can also be explained if the two processes writing
>to the .pyc files are *different Python versions*. As you may recall, at
>Google we used to use modified Python interpreters that used '.pyc-2.2',
>'.pyc-2.4', etc, for
On May 16, 2013, at 05:30 PM, Brett Cannon wrote:
>Just so people know, this is how we used to do it. In importlib we
>write the entire file to a temp file and then to an atomic rename.
Yep, and I suspect that our fix, even if we don't completely identify the root
cause, will be to change py_comp
On May 16, 2013, at 04:52 PM, Terry Jan Reedy wrote:
>If the corruption only happens on Ubuntu, that would constitute 'rhyme'
>;-). I realize that asking for reports on other systems is part of the reason
>you posted, but I don't remember seeing any others yet.
Right. :) It's harder to dig out s
On May 17, 2013, at 01:19 PM, David Malcolm wrote:
>Fedora/RH pregenerate the .pyc files during rpm creation, and they exist
>as part of the rpm payload.
Good to know, thanks. Do you use `$PYTHON -m py_compile` to generate the pyc
files at build time?
-Barry
signature.asc
Description: PGP sig
On May 17, 2013, at 03:02 PM, Terry Jan Reedy wrote:
>What I mean is, is the corruption (not the detection of corruption) only
>happening during mass compilation of the stdlib? When user imports a single
>non-stdlib file he has written the first time, does that ever get corrupted.
It's not limite
On May 20, 2013, at 02:30 PM, Armin Rigo wrote:
>Just checking: in view of Raymond's proposal, is there a good reason
>against having all dicts be systematically ordered? It would
>definitely improve the debugging experience, by making multiple runs
>of the same program more like each other, ins
On May 18, 2013, at 11:41 PM, Raymond Hettinger wrote:
>I'm hoping that core developers don't get caught-up in the "doctests are bad
>meme".
Thanks for your message Raymond. I know that doctests are controversial, but
I do firmly believe that when used correctly, they have value and should not
b
On May 19, 2013, at 07:28 PM, Tim Peters wrote:
>But more than just one ;-) Another great use has nothing to do with
>docstrings: using an entire file as "a doctest". This encourages
>writing lots of text explaining what you're doing,. with snippets of
>code interspersed to illustrate that the
On May 19, 2013, at 04:27 PM, Gregory P. Smith wrote:
>Idea: I don't believe anybody has written a fixer for lib2to3 that applies
>fixers to doctests. That'd be an interesting project for someone.
I'm not sure that's true. I don't use 2to3 anymore if I can help it, but I'm
pretty sure you can 2
I don't think a python-dev discussion about the value of doctests is going to
change minds one way or the other, but I just *had* to respond to this one
point:
On May 20, 2013, at 11:26 PM, Michael Foord wrote:
>* Doctests practically beg you to write your code first and then copy and
>* paste te
Here's something that seems to come up from time to time in Debian.
Take a Python application like tox, nose, or pyflakes. Their executables work
with both Python 2 and 3, but require a #! line to choose which interpreter to
invoke.
When we add Python 3 support in Debian for such a script, all t
On May 28, 2013, at 10:15 PM, Nick Coghlan wrote:
>Would anyone object if I went ahead and posted patches for making
>these changes to the main repo?
When you say "post[ed] patches", do you mean you want to put them some place
for us to review? If so, sure, go ahead of course.
-Barry
__
On May 26, 2013, at 08:34 PM, Nick Coghlan wrote:
>As far as I am aware, there's nothing to clarify: new code should use
>underscores as word separators, code added to an existing module or
>based on existing API should follow the conventions of that module or
>API. This is what PEP 8 already says
On May 24, 2013, at 04:23 PM, R. David Murray wrote:
>Gentoo has a (fairly complex) driver script that is symlinked to all
>of these bin scripts. The system then has the concept of the
>"current python", which can be set to python2 or python3. The default
>bin then calls the current default inte
On May 25, 2013, at 05:57 PM, Nick Coghlan wrote:
>It seems to me the existing recommendation to use ``#!/usr/bin/env
>python`` instead of referencing a particular binary already covers the
>general case. The challenge for the distros is that we want a solution
>that *ignores* user level virtual e
On May 25, 2013, at 06:17 AM, Chris McDonough wrote:
>I'm curious if folks have other concrete examples of global bindir
>executables other than nosetests and pydoc that need to be disambiguated
>by Python version. I'd hate to see it become standard practice to
>append "3" to scripts generated by
On May 27, 2013, at 11:38 AM, Toshio Kuratomi wrote:
>Fedora is a bit of a mess... we try to work with upstream's intent when
>upstream has realized this problem exists and have a single standard when
>upstream does not. The full guidelines are here:
>
>http://fedoraproject.org/wiki/Packaging:Pyt
On May 25, 2013, at 09:53 AM, Antoine Pitrou wrote:
>How about always running the version specific targets, e.g.
>nosetests-2.7?
We have nosetests-2.7 and nosetests3 in /usr/bin, but we generally recommend
folks not use these, especially for things like (build time) package tests.
It's harder to
On May 25, 2013, at 03:12 AM, Chris McDonough wrote:
>You probably already know this, but I'll mention it anyway. This
>probably matters a lot for nose and pyflakes, but I'd say that for tox
>it should not, it basically just scripts execution of shell commands.
>I'd think maybe in cases like tox
On May 28, 2013, at 01:57 PM, Daniel Holth wrote:
>Wheel has no mechanism for renaming scripts (or any file) based on the
>Python version used to install. Instead you would have to build
>python-version-specific packages for each desired script name.
Note that I'm not trying to borrow any impleme
On May 28, 2013, at 08:02 PM, Antoine Pitrou wrote:
>On Tue, 28 May 2013 13:27:18 -0400
>Barry Warsaw wrote:
>> On May 25, 2013, at 09:53 AM, Antoine Pitrou wrote:
>>
>> >How about always running the version specific targets, e.g.
>> >nosetests-2.7?
>>
On May 28, 2013, at 12:23 PM, Toshio Kuratomi wrote:
>> Note that the Gentoo example also takes into account versions that might act
>> differently based on the interpreter's implementation. So a -python3 suffix
>> may not be enough. Maybe now we're getting into PEP 425 compatibility tag
>> terr
On May 29, 2013, at 01:01 PM, Nick Coghlan wrote:
>PEP 432 is also related, as it includes the "pysystem" proposal [1]
>(an alternate Python CLI that will default to -Es behaviour, but is
>otherwise similar to the standard "python" interpreter).
I *knew* this was being specified somewhere, but I
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. This is what most people are going to expect when using a
>https url (Especia
On Jun 03, 2013, at 09:05 AM, Ben Darnell wrote:
>The data is analogous to the time zone database (PEP 431) in that it may
>need to be updated independently of Python's own release schedule, so we
>may want to use similar techniques to manage both. Also see certifi (
>https://pypi.python.org/pypi
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) that it would ideally take affect for Python as well.
This reminds me of one o
On Jun 03, 2013, at 02:21 PM, Donald Stufft wrote:
>The other additional comment I'd like to throw in here is that if we don't
>bundle SSL certs I think we should still verify by default (which means HTTPS
>urls will throw an error by default if we can't locate a certificate store)
>because I thin
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 being there if they are only there on linux.
I think we agree on that.
>
On Jun 07, 2013, at 09:06 AM, Ethan Furman wrote:
>Oh, and I just realized this is probably why the flufl.enum docs import from
>a preexisting module instead of creating a new class on the spot.
Exactly. ;)
-Barry
___
Python-Dev mailing list
Python-Dev
On Jun 07, 2013, at 02:30 PM, PJ Eby wrote:
>I don't know if enums *actually* preserve this invariant, but my
>default expectation of the One Obvious Way would be that enums, being
>uniquely-named objects that know their name and container, should be
>considered global objects in the same fashion
On Jun 15, 2013, at 12:46 PM, Ethan Furman wrote:
>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.
>
>Would it be inappropriate to call it `stdlib.enum`?
The last upload was
On Jun 15, 2013, at 11:53 PM, Ethan Furman wrote:
>Note that while flufl.enum was the inspiration, it is not the version that
>went into 3.4.
I haven't yet decided whether to continue with development of flufl.enum or
not. I think there's a lot of value in promoting a standard enum library and
h
On Jun 16, 2013, at 01:13 PM, Eli Bendersky wrote:
>If you write down the process of porting mailmain from flufl to stdlib.enum
>in some place, it can make the process much easier for others, and even
>encourage them to follow the same path.
Let's write it down here! It was mostly mechanical, an
On Jun 26, 2013, at 09:04 AM, Eric V. Smith wrote:
>I run 'make distclean' fairly often, but maybe it's just out of habit.
>If I'm adding/deleting modules, I want to make sure there are no build
>artifacts. And since I have modified files, a clean checkout won't help
>(easily, at least).
As do I.
On Jun 28, 2013, at 01:07 PM, Jim J. Jewett wrote:
>> Switching from getitem syntax to call syntax for looking up an
>> enum member by value, e.g.
>
>>-return self._enum[value]
>>+return self._enum(value)
>
>> Interesting that these two were exactly opposite from flufl.enum
On Jun 28, 2013, at 02:11 PM, Guido van Rossum wrote:
>I have no idea why it was the other way around in flufl.enum, but
>admittedly neither of these rules are absolute, and it's possible that
>flufl.enum just evolved that way without conscious decisions, or that
>it came from taking a different p
On Jul 14, 2013, at 06:11 PM, Nick Coghlan wrote:
>Private interfaces
PEP 8 does say:
_single_leading_underscore: weak "internal use" indicator. E.g. from M
import * does not import objects whose name starts with an underscore.
I'm in favor of making this a stronger recommendation, but
On Jul 15, 2013, at 09:56 PM, Antoine Pitrou wrote:
>If you really want another word (I am personally fine with "private"),
>"internal" it should be.
I would be fine with "internal", since that's how PEP 8 already classifies
such names. :)
-Barry
___
P
Working from what I think is the latest version.
In general, i'd rather be prescriptive of future conventions than descriptive
of current conventions. It's okay to exempt existing code, and as a general
rule we've never been fond of rewriting existing code to update it to new
standards or APIs.
On Jul 15, 2013, at 08:23 PM, Chris McDonough wrote:
>On Mon, 2013-07-15 at 18:40 -0400, Barry Warsaw wrote:
>> Working from what I think is the latest version.
>>
>> In general, i'd rather be prescriptive of future conventions than
>> descriptive of current c
On Jul 16, 2013, at 02:02 PM, Thomas Wouters wrote:
>In my experience changing the name of a package is problematic for more
>reasons than just 'import'. We used to do the put-in-a-package thing for
>third-party packages at Google, and we quit doing it because it was just
>too painful: it's hard t
On Jul 15, 2013, at 11:02 PM, Chris McDonough wrote:
>Given that misunderstanding, is there a way to divorce stdlib-centric
>guidelines like the one being discussed now from "PEP8"-ness? I don't
>think any amount of marketing effort or reasoned explanation is going to
>separate "PEP8" from "corre
On Jul 16, 2013, at 11:28 AM, Richard Oudkerk wrote:
>BTW, how does the use of __all__ effect things? Somewhere I got the idea
>that if a module uses __all__ then anything not listed is internal. I take
>it that is wrong?
Purely technically, __all__ is there to affect how from-import-* works.
On Jul 16, 2013, at 11:48 PM, Nick Coghlan wrote:
>For the general case, the patch I posted to the issue tracker sets the
>precedence as docs -> __all__ -> leading underscore.
+1
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.pyth
On Jul 16, 2013, at 04:10 PM, Nick Coghlan wrote:
>Yeah, we should probably be a bit more vocal in pointing out that PEP
>8 is something to be applied judiciously, *not* treated as "sacred
>writ, never to be questioned". It's very tempting to just sigh and
>ignore it, instead of explicitly pointin
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Jul 16, 2013, at 07:34 PM, Tres Seaver wrote:
>On 07/16/2013 07:09 AM, Nick Coghlan wrote:
>
>> I did find it interesting that we *don't* explicitly advise against
>> the use of "import *" for anything other than optional accelerator
>> modules
On Jul 17, 2013, at 09:35 AM, Brett Cannon wrote:
>Or how about dropping the whole ``from ... import ...`` format entirely?
><0.5 wink; seriously, it's implementation is a pain and it has wonky
>semantics>
Yes, let's break *everything* :)
-Barry
signature.asc
Description: PGP signature
___
On Jul 24, 2013, at 05:12 AM, Bohuslav Kabrda wrote:
>in recent days, there has been a discussion on fedora-devel (see thread [1])
>about moving to Python 3 as a default.
I've been lurking via Gmane. :)
>- Should we point /usr/bin/python to Python 3 when we make the move?
Over in Debian (inheri
On Jul 24, 2013, at 08:26 AM, Toshio Kuratomi wrote:
> I think bkabrda is looking for some clarification on PEP-394. My
>reading and participation in the previous discussions lead me to believe
>that while PEP-394 wants to be diplomatic, the message it wants to get
>across is:
>
>1) warn distrib
On Jul 25, 2013, at 01:41 AM, Nick Coghlan wrote:
>How's this for an updated wording in the abstract:
>
> * for the time being, all distributions should ensure that python
>refers to the same target as python2
> * however, users should be aware that python refers to python3 on at
>least Arch Lin
On Aug 01, 2013, at 11:05 AM, Alexander Belopolsky wrote:
>I will start experimenting with 100-char limit, but I think it is still too
>wide for auto-wrapped text. Maybe we should have a stronger
>recommendation to keep 80-char limit for docstrings and other embedded
>text. It is OK to have an
On Aug 01, 2013, at 11:52 AM, R. David Murray wrote:
>So as we edit the docs, we re-wrap. Just like we do with the legacy
>code :)
+1!
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscr
On Aug 06, 2013, at 02:36 PM, Eli Bendersky wrote:
>Personally, I dislike all non-simple uses of Enums. One such use is adding
>behavior to them. This can always be split to separate behavior from the
>Enum itself, and I would prefer that. We went to great lengths to ensure
>that things work in ex
On Aug 20, 2013, at 07:33 PM, Tim Peters wrote:
>So let's try a different question ;-) Would anyone _object_ to
>completing the process described in the docs: merge 3.2 into 3.3,
>then merge 3.3 into default? I'd be happy to do that. I'd throw away
>all the merge changes except for adding the
Hello Pythonistas,
Python 2.6.9 is the last planned release of the 2.6.x series. This will be a
security-only source-only release. It is currently scheduled for October
2013, and after this Python 2.6 will have reached its end-of-life and the
branch will be retired.
http://www.python.org/dev/pe
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Sep 05, 2013, at 07:31 PM, Jesus Cea wrote:
>I just received an email from my OpenID provider, "myOpenID", saying
>that they drop OpenID service next February. I wonder what other
>OpenID providers are used by other python-dev fellows.
>
>What ar
On Sep 05, 2013, at 11:33 AM, Toshio Kuratomi wrote:
>Sortof The way OAuth looks to me, it's designed to prove that a given
>client is authorized to perform an action. It's not designed to prove that
>the given client is a specific person. In some cases, you really want to
>know the latter a
On Sep 05, 2013, at 09:07 PM, Antoine Pitrou wrote:
>Which sites exactly? I can login to BitBucket and *.python.org using
>OpenID, not Persona.
I think Persona is just too new to see it around much yet. Or maybe Mozilla
needs better PR.
-Barry
___
Pyt
On Sep 06, 2013, at 01:09 AM, Oleg Broytman wrote:
>I will change my mind when Google and GitHub start using them.
Neither Google nor GitHub are free or open. Bitbucket and Facebook aren't
either. I'm not saying they're bad services because of that of course, but I
don't want to have to rely on
On Sep 06, 2013, at 12:36 AM, Oleg Broytman wrote:
> You cannot login using OpenID to most interesting popular sites.
>GMail? No. Twitter? No. Facebook? FriendFeed? identi.ca? No, no, no.
I'd be surprised if you ever saw the big social networking sites support
OpenID or Persona. They want to o
On Sep 10, 2013, at 12:04 PM, Victor Stinner wrote:
>The http.client and email.message modules convert headers to lower
>case, but keep the original case.
As RDM pointed out on the tracker, email headers aren't a great use case for
this because they aren't really dictionaries. They're lists with
On Sep 10, 2013, at 03:57 PM, Antoine Pitrou wrote:
>Le Tue, 10 Sep 2013 09:49:28 -0400,
>Barry Warsaw a écrit :
>> On Sep 10, 2013, at 12:04 PM, Victor Stinner wrote:
>>
>> >The http.client and email.message modules convert headers to lower
>> >case, but k
On Sep 10, 2013, at 08:08 AM, Guido van Rossum 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.)
This is way off topic, but I suspect your original response didn't trim your
lit
On Sep 11, 2013, at 01:09 PM, Serhiy Storchaka wrote:
>In ideal it should be one high-quality (float64?) multichannel (5+1?) but
>short master file and it's lower-quality copies made by third-party tools. In
>ideal the content should be related to Python.
I have some pro-audio recording capabilit
On Sep 18, 2013, at 10:04 AM, Skip Montanaro wrote:
>As a MacBook Pro user running Snow Leopard/10.6.8, I would find the
>lack of a binary release problematic, were it not for the fact that I
>routinely build from source (and don't do anything Mac-specific with
>Python). For those not familiar wit
On Sep 18, 2013, at 03:00 PM, r.david.murray wrote:
>http://hg.python.org/cpython/rev/fb3ad8a749c8
>changeset: 85749:fb3ad8a749c8
>branch: 2.6
>parent: 85735:1b673e0fd8f3
>user:R David Murray
>date:Wed Sep 18 08:49:25 2013 -0400
>summary:
> #14984: only import pwd on
On Sep 22, 2013, at 10:34 AM, Brett Cannon wrote:
>The rule of thumb I go by is the docstring should be enough to answer the
>question "what args does this thing take and what does it do in general to
>know it's the function I want and another one in the same module?" quickly
>and succinctly; i.e.
On Sep 23, 2013, at 09:15 PM, Nick Coghlan wrote:
>With the last round of updates, I believe PEP 453 is ready for
>Martin's pronouncement.
I want to raise an objection to PEP's proposal to add this as a new feature to
Python 2.7 and 3.3. I understand the rationale as stated here:
http://www.pyt
On Sep 25, 2013, at 05:33 PM, Donald Stufft wrote:
>I think it should be placed in the source tree for the stable releases. The
>reasoning is that 2.7 is going to stick around for a long time. Immediately
>this won't be ubiquitous but as time goes on you'll be able to be ensured
>that a ``python -
On Sep 26, 2013, at 07:14 AM, Nick Coghlan wrote:
>On 26 Sep 2013 06:53, "Barry Warsaw" wrote:
>>
>> Why does it have to be added to the source tree for stable releases?
>
>If it can get into the installers another way, it doesn't, really. It only
>needs t
On Sep 25, 2013, at 06:15 PM, Donald Stufft wrote:
>Well I don't think many scripts will be executing ensurepip, maybe i'm wrong,
>but yes it does mean that not all Python 2.7's are alike. Most likely though
>at some point 2.7.XXX is going to be near standard as the 2.7 hold outs stay
>on it and t
On Sep 26, 2013, at 09:01 AM, Nick Coghlan wrote:
>Would a leading underscore in the module name make you more comfortable
>with the idea? It's really intended mostly as a hidden implementation
>detail of the installers and pyvenv anyway, so calling it "_ensurepip"
>would help make that explicit w
On Sep 25, 2013, at 07:08 PM, Donald Stufft wrote:
>On Sep 25, 2013, at 7:04 PM, Barry Warsaw wrote:
>
>> So, why shouldn't we add enum to the Python 2.7 stdlib?
>Because with PEP453 you can just ``pip install enum34`` it :)
Of course, pip messing with global Python state
On Sep 26, 2013, at 02:30 PM, Nick Coghlan wrote:
>- the module name should be "_ensurepip" in all versions
>- the PEP should explicitly state that the "don't remove _ensurepip
>and it's wheel files" caveat for redistributors applies only in 3.4+
>(where removing it will break pyvenv)
I'm sorry t
On Sep 27, 2013, at 09:14 PM, Brett Cannon wrote:
>I don't see any issue with redirecting the discussion. python-tulip@ is
>acting like a SIG for the module, so no real precedent beyond it not being
>hosted as a mail.python.org list.
The PEP process even allows for this formally. Please add a D
On Sep 28, 2013, at 12:48 PM, Stephen J. Turnbull wrote:
>*shrug* I just think the risks are higher than acknowledged (just
>because you have so far failed to imagine a problem doesn't mean it
>won't appear), and that the meta effect that "Even Guido admits that
>Python 3 isn't ready for prime ti
Just a quick reminder that I intend to cut 2.6.9rc1 tomorrow.
Here are the open issues still on my list:
- 16040 - nntplib: unlimited readline() from connection
This one is waiting for a patch, but TBH if it doesn't make it into 2.6.9 I
won't care too much. I also don't mind reviewing and a
On Sep 30, 2013, at 11:07 PM, Nick Coghlan wrote:
>My plan now is to split the PEP in two, so the 3.4 changes can be accepted
>as non-controversial, including the offer of core dev assistance in
>creating and maintaining a Windows installer for pip to better support
>earlier versions. The backport
Hello Pythoneers and Pythonistas,
I'm happy to announce the availability of Python 2.6.9 release candidate 1.
Python 2.6.9rc1 is a security-fix source-only release for Python 2.6. This
means that general bug maintenance has ended, and only critical security
issues are being fixed. It also means
On Oct 03, 2013, at 02:08 PM, Eric Snow wrote:
>On Thu, Oct 3, 2013 at 1:57 PM, A.M. Kuchling wrote:
>> On Thu, Oct 03, 2013 at 08:48:47PM +0200, eric.snow wrote:
>>> -- Issue #19951: Fix docstring and use of _get_suppported_file_loaders() to
>>> +- Issue #19151: Fix docstring and use of _get_sup
On Oct 06, 2013, at 11:41 AM, Benjamin Peterson wrote:
>What is the usecase for minimizing the memory usage of Python in the
>middle of a program?
There are environments where Python is being actively discouraged in part due
to its memory footprint. For example, we can't use Python on Ubuntu Tou
601 - 700 of 2704 matches
Mail list logo
