Re: [Python-Dev] PEP 453 (pip bootstrapping) ready for pronouncement?

On Sep 24, 2013, at 12:32 AM, Ned Deily wrote: > IANAL, but I think it would be good if, at least, the setuptools license were > clearer and the LGPL reference for the cert bundle was changed. It *might* > be > a good idea to get an opinion from Van Lindberg. But I'm happy to defer to > Ma

Re: [Python-Dev] PEP 453 (pip bootstrapping) ready for pronouncement?

In article <44f4e1f8-5533-45a7-810e-b9c13530e...@stufft.io>, Donald Stufft wrote: > On Sep 23, 2013, at 7:34 PM, Ned Deily wrote: > > [... license implications ...] > > As far as I know the certificate bundle is licensed under either GPL, MPL, > or LGPL. However there is debate about wether a C

Re: [Python-Dev] Best practice for documentation for std lib

Given near-consensus on the "Return ..." form, the following discussion is of academic interest only. On Mon, Sep 23, 2013 at 9:31 PM, Steven D'Aprano wrote: > > I would not mind > > > > def foo(): > > """returns bar""" > > > > which I would read as "Function foo() returns bar," but in this

Re: [Python-Dev] Best practice for documentation for std lib

This is getting off-topic, if you're not interested in English grammar you should stop reading. On Mon, Sep 23, 2013 at 03:18:01PM -0400, Alexander Belopolsky wrote: > I don't think "Returns bar." is a valid English sentence because it lacks > subject. Subjectless sentences are unusual in Engl

Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message

MRAB writes: > > The word doesn't literally mean the exception itself was unraisable. It > > means it was raised, we caught it and we're writing it to stderr because > > we *can't raise it again*. > Ah, you mean "unreraisable". :-) +1 Ugly as sin, but satisfies all other criteria (except fo

Re: [Python-Dev] PEP 453 (pip bootstrapping) ready for pronouncement?

On Sep 23, 2013, at 8:12 PM, Donald Stufft wrote: >> >> >>> A common source of Python installations are through downstream distributors >>> such as the various Linux Distributions [#ubuntu]_ [#debian]_ [#fedora]_, >>> OSX >>> package managers [#homebrew]_, or Python-specific tools [#conda]_.

Re: [Python-Dev] PEP 453 (pip bootstrapping) ready for pronouncement?

On Sep 23, 2013, at 7:34 PM, Ned Deily wrote: > In general, I think this is a very important usability feature and I > am in favor of the general approach. Good work, all! I do have some > comments, primarily about items that are not currently addressed. > >> ``ensurepip`` itself (including t

Re: [Python-Dev] PEP 453 (pip bootstrapping) ready for pronouncement?

On Sep 23, 2013, at 7:34 PM, Ned Deily wrote: > One final comment is that the PEP does not go into any detail on how it > will be implemented. As it stands, there is a fair amount of one-time > work, including implementing ensurepip, changes to the Windows installer, > changes to the OS X insta

Re: [Python-Dev] PEP 453 (pip bootstrapping) ready for pronouncement?

In general, I think this is a very important usability feature and I am in favor of the general approach. Good work, all! I do have some comments, primarily about items that are not currently addressed. > ``ensurepip`` itself (including the private copy of ``pip`` and its > dependencies) will st

Re: [Python-Dev] Enum Eccentricities

On 24 Sep 2013 08:09, "Greg Ewing" wrote: > > Steven D'Aprano wrote: >> >> It might not be a rule, but it's certainly the norm. I reckon that class attributes that aren't accessible from the instance are significantly more surprising than Color.red.blue. > > > There are really two different kinds

Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message

On 23/09/2013 22:19, Nick Coghlan wrote: On 24 Sep 2013 01:24, "Antoine Pitrou" mailto:solip...@pitrou.net>> wrote: > > On Mon, 23 Sep 2013 18:51:04 +1000 > Nick Coghlan mailto:ncogh...@gmail.com>> wrote: > > On 23 September 2013 18:45, Antoine Pitrou mailto:solip...@pitrou.net>> wrote: > >

Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message

On Mon, 23 Sep 2013 14:38:48 -0700 Ethan Furman wrote: > > But that's because you already know what it's supposed to convey. The > > average user doesn't, and only sees "unraisable". > > All the more reason to have text in the error message that is easily > searchable. Then I propose "CA6yuaYV6

Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message

On 09/23/2013 02:35 PM, Antoine Pitrou wrote: On Tue, 24 Sep 2013 07:19:14 +1000 Nick Coghlan wrote: On 24 Sep 2013 01:24, "Antoine Pitrou" wrote: On Mon, 23 Sep 2013 18:51:04 +1000 Nick Coghlan wrote: On 23 September 2013 18:45, Antoine Pitrou wrote: Le Mon, 23 Sep 2013 18:17:51 +1000,

Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message

Antoine Pitrou wrote: Yes, but I agree with Greg that "unraisable" is wrong. After all, it was raised, and it can even be caught by the programmer (inside __del__). How about something like "Uncaught exception in __del__ method ignored"? It explains fairly clearly what has happened, and also in

Re: [Python-Dev] Enum Eccentricities

Steven D'Aprano wrote: It might not be a rule, but it's certainly the norm. I reckon that class attributes that aren't accessible from the instance are significantly more surprising than Color.red.blue. There are really two different kinds of things that we refer to as "class attributes". One

Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message

On 09/23/2013 02:19 PM, Nick Coghlan wrote: The relevant C API function is just called "PyErr_WriteUnraisable", not "PyErr_WriteUnraisableButThatIsTechnicallyWrongSinceItWasAlreadyRaisedAndWeJustCaughtItAndAreNowReportingItToStdErr". Wow. How many legs does that HumptyCamel have, anyway? ;)

Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message

On Tue, 24 Sep 2013 07:19:14 +1000 Nick Coghlan wrote: > On 24 Sep 2013 01:24, "Antoine Pitrou" wrote: > > > > On Mon, 23 Sep 2013 18:51:04 +1000 > > Nick Coghlan wrote: > > > On 23 September 2013 18:45, Antoine Pitrou wrote: > > > > Le Mon, 23 Sep 2013 18:17:51 +1000, > > > > Nick Coghlan a é

Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message

On 24 Sep 2013 01:24, "Antoine Pitrou" wrote: > > On Mon, 23 Sep 2013 18:51:04 +1000 > Nick Coghlan wrote: > > On 23 September 2013 18:45, Antoine Pitrou wrote: > > > Le Mon, 23 Sep 2013 18:17:51 +1000, > > > Nick Coghlan a écrit : > > >> > > >> Here's what I suggest changing that error to: > >

Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message

On Mon, 23 Sep 2013 17:22:45 +0200, Antoine Pitrou wrote: > On Mon, 23 Sep 2013 18:51:04 +1000 > Nick Coghlan wrote: > > On 23 September 2013 18:45, Antoine Pitrou wrote: > > > Le Mon, 23 Sep 2013 18:17:51 +1000, > > > Nick Coghlan a écrit : > > >> > > >> Here's what I suggest changing that er

Re: [Python-Dev] Best practice for documentation for std lib

On Mon, Sep 23, 2013 at 3:01 PM, Terry Reedy wrote: > 'Return' versus 'Returns', exact uppercase word match, is a little over 3 to > 1. I am sure I have seen 'Return' and similiar directive forms ('Print', > 'Store', 'Compare', etc) recommended as current doc style, as prefered by > the current do

Re: [Python-Dev] Best practice for documentation for std lib

On Mon, Sep 23, 2013 at 3:01 PM, Terry Reedy wrote: > > IIRC in the Java world you *have* to > >> use 'Returns', but I don't buy the argument from nit-picky grammarians >> that leads to this rule. (It's something about the documentation not >> being a command. But English is more flexible than th

Re: [Python-Dev] Best practice for documentation for std lib

On 23/09/2013 20:01, Terry Reedy wrote: On 9/22/2013 10:44 PM, Guido van Rossum wrote: Glad you like it. I still do, too, but I've given up hope to convince all core developers to stick to this style. :-( >[me] ('Return' rather than 'Returns' is the current convention.) That's actually a

Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message

On 9/23/2013 12:23 PM, R. David Murray wrote: On Mon, 23 Sep 2013 17:22:45 +0200, Antoine Pitrou wrote: On Mon, 23 Sep 2013 18:51:04 +1000 Nick Coghlan wrote: On 23 September 2013 18:45, Antoine Pitrou wrote: Le Mon, 23 Sep 2013 18:17:51 +1000, Nick Coghlan a écrit : Here's what I sugges

Re: [Python-Dev] Best practice for documentation for std lib

On 9/22/2013 10:44 PM, Guido van Rossum wrote: Glad you like it. I still do, too, but I've given up hope to convince all core developers to stick to this style. :-( >[me] ('Return' rather than 'Returns' is the current convention.) That's actually a religious argument which in the stdlib tak

Re: [Python-Dev] Enum Eccentricities

Guido van Rossum writes: > On Mon, Sep 23, 2013 at 8:17 AM, Zero Piraeus wrote: >> On Mon, Sep 23, 2013 at 09:45:46AM -0400, Chris Lambacher wrote: >>> [...] An example of how this will be used in practice is:> >>>     {% if object.state == object.state.completed %} >>>       some html >>>

Re: [Python-Dev] Best practice for documentation for std lib

On Mon, Sep 23, 2013 at 10:52 AM, Terry Reedy wrote: > On 9/23/2013 10:56 AM, Guido van Rossum wrote: > > I think 60 is just a guideline. In stdlib .py source code I want it not >> to extend beyond the 79th column (see recent PEP 8 argument). For a >> > > PEP 8 says "Limit all lines to a maximum

Re: [Python-Dev] Enum Eccentricities

I am quickly losing interest in this -- I was only jumping in because I feared there was support for making Color.red.blue "work". I don't think I hve to worry about that any more -- what's best for Django templates is up to the template author. On Mon, Sep 23, 2013 at 10:46 AM, Stephen J. Turnbu

Re: [Python-Dev] Best practice for documentation for std lib

On 9/23/2013 10:56 AM, Guido van Rossum wrote: I think 60 is just a guideline. In stdlib .py source code I want it not to extend beyond the 79th column (see recent PEP 8 argument). For a PEP 8 says "Limit all lines to a maximum of 79 characters. For flowing long blocks of text with fewer stru

Re: [Python-Dev] Best practice for documentation for std lib

On 9/23/2013 11:18 AM, Skip Montanaro wrote: It would be great if the docstring contained a link to the online documentation. That would have to be a feature of help(), not hardcoded in each docstring. That *is* a feature of the help function: Help on built-in module sys: help(sys) NAME

Re: [Python-Dev] Enum Eccentricities

On Mon, Sep 23, 2013 at 09:45:46AM -0400, Chris Lambacher wrote: > [...] The exact use case is in Django templates where a value comes > from the database. If you want to compare you either have to use > __class__ which I would say is a code smell, or you have > to provide the Enum class. I'm havi

Re: [Python-Dev] Enum Eccentricities

On Mon, Sep 23, 2013 at 8:17 AM, Zero Piraeus wrote: > On Mon, Sep 23, 2013 at 09:45:46AM -0400, Chris Lambacher wrote: > > [...] The exact use case is in Django templates where a value comes > > from the database. If you want to compare you either have to use > > __class__ which I would say is a

Re: [Python-Dev] Best practice for documentation for std lib

On 09/23/2013 04:43 PM, R. David Murray wrote: On Sun, 22 Sep 2013 16:19:21 -0700, Guido van Rossum wrote: On Sun, Sep 22, 2013 at 2:41 PM, Xavier Morel wrote: The points here are that there's a single source of truth (so we can't have conflicting docstring and rst documentation), and documen

Re: [Python-Dev] Enum Eccentricities

On 09/23/2013 08:16 AM, Steven D'Aprano wrote: I would expect instance.blue to work, and I'm completely at a loss as to how Enum has managed to prevent it. [A peek behind the curtains...] Currently, Enum members do not live in the class dict. So when, for example, blue is searched for in red

Re: [Python-Dev] Enum Eccentricities

On Mon, Sep 23, 2013 at 8:16 AM, Steven D'Aprano wrote: > On Mon, Sep 23, 2013 at 07:53:00AM -0700, Guido van Rossum wrote: > > > there is no rule that because you can > > access something on the class you should be able to access it on the > > instance. Try asking an instance for its class's __mr

Re: [Python-Dev] Best practice for documentation for std lib

>> It would be great if the docstring contained a link to the online >> documentation. > > That would have to be a feature of help(), not hardcoded in each docstring. That *is* a feature of the help function: Help on built-in module sys: >>> help(sys) NAME sys FILE (built-in) MODULE DO

Re: [Python-Dev] Best practice for documentation for std lib

On Mon, 23 Sep 2013 08:57:01 +0100 Larry Hastings wrote: > On 09/23/2013 03:44 AM, Guido van Rossum wrote: > > On Sun, Sep 22, 2013 at 7:25 PM, Terry Reedy > > wrote: > > > > I am gradually changing Idle docstrings, though only Idle > > developers will ever see th

Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message

On Mon, 23 Sep 2013 18:51:04 +1000 Nick Coghlan wrote: > On 23 September 2013 18:45, Antoine Pitrou wrote: > > Le Mon, 23 Sep 2013 18:17:51 +1000, > > Nick Coghlan a écrit : > >> > >> Here's what I suggest changing that error to: > >> > >> >>> del x > >> Unraisable exception suppressed when call

Re: [Python-Dev] Best practice for documentation for std lib

On Sun, 22 Sep 2013 16:19:21 -0700, Guido van Rossum wrote: > On Sun, Sep 22, 2013 at 2:41 PM, Xavier Morel wrote: > > > The points here are that there's a single source of truth (so we can't > > have conflicting docstring and rst documentation), and documentation > > becoming outdated can be not

Re: [Python-Dev] Enum Eccentricities

On Mon, Sep 23, 2013 at 6:45 AM, Chris Lambacher wrote: > > On Sun, Sep 22, 2013 at 10:41 PM, Zero Piraeus wrote: > >> I may be misunderstanding the use case given in the issue, >> > > To clarify the use case, since it is my bug, this is so that the enum > values are always available for comparis

Re: [Python-Dev] Enum Eccentricities

On Mon, Sep 23, 2013 at 07:53:00AM -0700, Guido van Rossum wrote: > there is no rule that because you can > access something on the class you should be able to access it on the > instance. Try asking an instance for its class's __mro__ or __bases__. It might not be a rule, but it's certainly the

Re: [Python-Dev] Best practice for documentation for std lib

On Mon, Sep 23, 2013 at 12:57 AM, Larry Hastings wrote: > On 09/23/2013 03:44 AM, Guido van Rossum wrote: > > On Sun, Sep 22, 2013 at 7:25 PM, Terry Reedy wrote: > >> I am gradually changing Idle docstrings, though only Idle developers will >> ever see them. Writing a 60 char summary forces a

Re: [Python-Dev] Best practice for documentation for std lib

On Mon, Sep 23, 2013 at 4:27 AM, Walter Dörwald wrote: > It would be great if the docstring contained a link to the online > documentation. > That would have to be a feature of help(), not hardcoded in each docstring. -- --Guido van Rossum (python.org/~guido) ___

Re: [Python-Dev] Best practice for documentation for std lib

Le Mon, 23 Sep 2013 15:51:27 +0200, Walter Dörwald a écrit : > On 23.09.13 15:38, Fred Drake wrote: > > > On Mon, Sep 23, 2013 at 7:27 AM, Walter Dörwald > > wrote: > >> It would be great if the docstring contained a link to the online > >> documentation. > > > > The docstring itself, or the pre

Re: [Python-Dev] Best practice for documentation for std lib

On 23.09.13 15:38, Fred Drake wrote: On Mon, Sep 23, 2013 at 7:27 AM, Walter Dörwald wrote: It would be great if the docstring contained a link to the online documentation. The docstring itself, or the presentation generated by help() ? The presentation generated by help(), or the output o

Re: [Python-Dev] Enum Eccentricities

On Sun, Sep 22, 2013 at 10:41 PM, Zero Piraeus wrote: > I may be misunderstanding the use case given in the issue, > To clarify the use case, since it is my bug, this is so that the enum values are always available for comparison. The exact use case is in Django templates where a value comes fro

Re: [Python-Dev] Best practice for documentation for std lib

On Mon, Sep 23, 2013 at 7:27 AM, Walter Dörwald wrote: > It would be great if the docstring contained a link to the online > documentation. The docstring itself, or the presentation generated by help() ? -Fred -- Fred L. Drake, Jr. "A storm broke loose in my mind." --Albert Einstein __

Re: [Python-Dev] Best practice for documentation for std lib

On 22.09.13 16:34, 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. just enough

[Python-Dev] PEP 453 (pip bootstrapping) ready for pronouncement?

With the last round of updates, I believe PEP 453 is ready for Martin's pronouncement. HTML: http://www.python.org/dev/peps/pep-0453/ Major diffs: http://hg.python.org/peps/rev/b2993450b32a Many of the updates are just clarifications in response to questions, but the actual significant changes ar

Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message

On 23 September 2013 18:45, Antoine Pitrou wrote: > Le Mon, 23 Sep 2013 18:17:51 +1000, > Nick Coghlan a écrit : >> >> Here's what I suggest changing that error to: >> >> >>> del x >> Unraisable exception suppressed when calling > of <__main__.C object at 0x7f98b8b61538>> >> Traceback (most recen

Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message

Le Mon, 23 Sep 2013 18:17:51 +1000, Nick Coghlan a écrit : > > Here's what I suggest changing that error to: > > >>> del x > Unraisable exception suppressed when calling of <__main__.C object at 0x7f98b8b61538>> > Traceback (most recent call last): > File "", line 3, in __del__ > RuntimeError

Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message

On 23 September 2013 16:11, Greg Ewing wrote: > Guido van Rossum wrote: >> >> Somehow "unraisable" sounds too technical, > > > It's not even really accurate. It's been raised, it just > can't be propagated any further. But "unpropagatable > exception" would be a bit of a mouthful. I felt I needed

Re: [Python-Dev] sys.intern should work on bytes

On 09/20/2013 06:50 PM, PJ Eby wrote: On Fri, Sep 20, 2013 at 9:54 AM, Jesus Cea wrote: Why str/bytes doesn't support weakrefs, beside memory use? The typical use case for weakrefs is to break reference cycles, Another typical use case, and the prime reason why languages without reference

Re: [Python-Dev] Best practice for documentation for std lib

On 09/23/2013 03:44 AM, Guido van Rossum wrote: On Sun, Sep 22, 2013 at 7:25 PM, Terry Reedy > wrote: I am gradually changing Idle docstrings, though only Idle developers will ever see them. Writing a 60 char summary forces a clear understanding of the functi