Re: [Python-Dev] [Python-checkins] cpython: Issue #18393: Remove use of deprecated API on OSX

On 15 Jul, 2013, at 18:43, Zachary Ware wrote: > On Mon, Jul 15, 2013 at 11:32 AM, ronald.oussoren > wrote: >> http://hg.python.org/cpython/rev/ccbaf6762b54 >> changeset: 84634:ccbaf6762b54 >> user:Ronald Oussoren >> date:Mon Jul 15 18:32:09 2013 +0200 >> summary: >> Issue #

Re: [Python-Dev] Misc re.match() complaint

On 16 July 2013 14:53, Guido van Rossum wrote: > Hm. I'd still like to change this, but I understand it's debatable... > Is the group() method written in C or Python? If it's in C it should > be simple enough to let it just do a little bit of pointer math and > construct a bytes object from the gi

Re: [Python-Dev] Tweaking PEP 8 guidelines for use of leading underscores

On 16 July 2013 16:01, Chris McDonough wrote: > Well, I know it's arguing with the umpire at this point, but PEP8 > prescriptionism (great word by the way!) is de rigeur these days. It's > a python-dev perogative to ignore that, but it has consequences that > reverberate further than this maillis

Re: [Python-Dev] Tweaking PEP 8 guidelines for use of leading underscores

On Tue, 2013-07-16 at 15:44 +1000, Nick Coghlan wrote: > On 16 July 2013 13:16, Chris McDonough wrote: > > I understand that. Unfortunately the remainder of the world does not. > > The same IDEs that would be helped via this proposed change have "PEP8 > > modes" turned on *by default*! > > http:/

Re: [Python-Dev] Misc re.match() complaint

Guido van Rossum writes: > I'm not sure I understand you. :-( My apologies. This: > > Or is this something deeper, that a group *is* a new object in > > principle? > > No, I just think of it as returning "a string" and I think it's most > useful if that is always an immutable object, eve

Re: [Python-Dev] Tweaking PEP 8 guidelines for use of leading underscores

On 16 July 2013 13:16, Chris McDonough wrote: > I understand that. Unfortunately the remainder of the world does not. > The same IDEs that would be helped via this proposed change have "PEP8 > modes" turned on *by default*! > http://blog.jetbrains.com/pycharm/2013/02/long-awaited-pep-8-checks-on-

Re: [Python-Dev] Misc re.match() complaint

Hm. I'd still like to change this, but I understand it's debatable... Is the group() method written in C or Python? If it's in C it should be simple enough to let it just do a little bit of pointer math and construct a bytes object from the given area of memory -- after all, it must have a pointer

Re: [Python-Dev] [Python-checkins] cpython (3.3): check the return value of new_string() (closes #18470)

2013/7/15 Victor Stinner : > 2013/7/16 benjamin.peterson : >> http://hg.python.org/cpython/rev/c3a510b22218 >> changeset: 84653:c3a510b22218 >> branch: 3.3 >> parent: 84651:e22dd5fda5a8 >> user:Benjamin Peterson >> date:Mon Jul 15 19:15:34 2013 -0700 >> summary: >> ch

Re: [Python-Dev] Tweaking PEP 8 guidelines for use of leading underscores

On Tue, 2013-07-16 at 13:11 +1000, Nick Coghlan wrote: > On 16 July 2013 13:02, Chris McDonough wrote: > > OSS developers have spent many months jumping through bw incompat hoops > > in Python over the last few years, and it has taken time away from doing > > things that provide value. The less I

Re: [Python-Dev] Tweaking PEP 8 guidelines for use of leading underscores

On 16 July 2013 13:02, Chris McDonough wrote: > OSS developers have spent many months jumping through bw incompat hoops > in Python over the last few years, and it has taken time away from doing > things that provide value. The less I can do of that, the better, and > Python gets more value too.

Re: [Python-Dev] Misc re.match() complaint

On 16 July 2013 12:20, Guido van Rossum wrote: > On Mon, Jul 15, 2013 at 7:03 PM, Stephen J. Turnbull > wrote: >> Or is this something deeper, that a group *is* a new object in >> principle? > > No, I just think of it as returning "a string" and I think it's most > useful if that is always an im

Re: [Python-Dev] Tweaking PEP 8 guidelines for use of leading underscores

On Tue, 2013-07-16 at 12:34 +1000, Nick Coghlan wrote: > How do get from "If this doesn't apply to a module, just add something > like 'This is an internal API' or 'This module includes internal APIs, > consult the documentation for the public API' to the module docstring" > to "updating 500k line

Re: [Python-Dev] Tweaking PEP 8 guidelines for use of leading underscores

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 conventions. It's okay to exempt exis

Re: [Python-Dev] [Python-checkins] cpython (3.3): check the return value of new_string() (closes #18470)

2013/7/16 benjamin.peterson : > http://hg.python.org/cpython/rev/c3a510b22218 > changeset: 84653:c3a510b22218 > branch: 3.3 > parent: 84651:e22dd5fda5a8 > user:Benjamin Peterson > date:Mon Jul 15 19:15:34 2013 -0700 > summary: > check the return value of new_string()

Re: [Python-Dev] [Python-checkins] cpython (merge default -> 3.3): merge 3.3 (#18470)

2013/7/16 benjamin.peterson : > http://hg.python.org/cpython/rev/8889c9b5dd3a > changeset: 84654:8889c9b5dd3a > branch: 3.3 > parent: 84653:c3a510b22218 > parent: 84652:8a078bf3cf14 > user:Benjamin Peterson > date:Mon Jul 15 19:15:49 2013 -0700 > summary: > merge

Re: [Python-Dev] Tweaking PEP 8 guidelines for use of leading underscores

On 16 July 2013 12:20, Chris McDonough wrote: > On Tue, 2013-07-16 at 11:25 +1000, Steven D'Aprano wrote: > >> >> If your code has no obvious, documented convention at all for what's >> internal and what is not, they are no worse off. >> >> If you do have a documented convention for internal impl

Re: [Python-Dev] Misc re.match() complaint

On Mon, Jul 15, 2013 at 7:18 PM, MRAB wrote: > On the other hand, I think that it's not unreasonable that the output > is the same type as the input. You could reason that what it's doing is > returning a slice of the input, and that slice should be the same type > as its source. By now I'm prett

Re: [Python-Dev] Misc re.match() complaint

On Mon, Jul 15, 2013 at 7:03 PM, Stephen J. Turnbull wrote: > Guido van Rossum writes: > > > And I still think that any return type for group() except bytes or str > > is wrong. (Except possibly a subclass of these.) > > I'm not sure I understand. Do you mean in the context of the match > objec

Re: [Python-Dev] Tweaking PEP 8 guidelines for use of leading underscores

On Tue, 2013-07-16 at 11:25 +1000, Steven D'Aprano wrote: > > If your code has no obvious, documented convention at all for what's internal > and what is not, they are no worse off. > > If you do have a documented convention for internal implementation details, > then you are no worse off. "I

Re: [Python-Dev] Misc re.match() complaint

On 16/07/2013 01:25, Guido van Rossum wrote: On Mon, Jul 15, 2013 at 5:10 PM, MRAB wrote: On 16/07/2013 00:30, Gregory P. Smith wrote: On Mon, Jul 15, 2013 at 4:14 PM, Guido van Rossum mailto:gu...@python.org>> wrote: In a discussion about mypy I discovered that the Python 3 version of

Re: [Python-Dev] Misc re.match() complaint

Guido van Rossum writes: > And I still think that any return type for group() except bytes or str > is wrong. (Except possibly a subclass of these.) I'm not sure I understand. Do you mean in the context of the match object API, where constructing "(target, match.start(), match.end())" to get a

Re: [Python-Dev] Tweaking PEP 8 guidelines for use of leading underscores

On 16 July 2013 10:23, 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 conventions. It's okay to exempt existing co

Re: [Python-Dev] Tweaking PEP 8 guidelines for use of leading underscores

On 16/07/13 10:23, Chris McDonough wrote: If what's being described here does become a rule, there is reason to believe that future users who treat this PEP as the word-of-god (and there are a *lot* of them; I hear from people literally every week who want to "PEP8-ify" my code in some limited-v

Re: [Python-Dev] Tweaking PEP 8 guidelines for use of leading underscores

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 conventions. It's okay to exempt existing code, and as a general > rule we've never been fond of

[Python-Dev] Is it safe to call PyEval_EvalFrameEx() with an exception set?

Hi, I'm working on the issue #18408 (fix issues found by my pyfailmalloc tool). To analyze some bugs, I have to add debug traces in various functions to find which function returned NULL without setting an error, or the opposite: returned a valid object, but with an exception set. I would like to

Re: [Python-Dev] Misc re.match() complaint

On Mon, Jul 15, 2013 at 5:10 PM, MRAB wrote: > On 16/07/2013 00:30, Gregory P. Smith wrote: >> >> >> On Mon, Jul 15, 2013 at 4:14 PM, Guido van Rossum > > wrote: >> >> In a discussion about mypy I discovered that the Python 3 version of >> the re module's Match obj

Re: [Python-Dev] Misc re.match() complaint

On 16 Jul 2013 09:17, "Guido van Rossum" wrote: > > Does anyone remember whether this was a conscious decision? I doubt it was a conscious decision - an unfortunate amount of the standard library's handling of the text model change falls into the category of "implementation accident" :( > Is it

Re: [Python-Dev] Misc re.match() complaint

On 16/07/2013 00:30, Gregory P. Smith wrote: On Mon, Jul 15, 2013 at 4:14 PM, Guido van Rossum mailto:gu...@python.org>> wrote: In a discussion about mypy I discovered that the Python 3 version of the re module's Match object behaves subtly different from the Python 2 version when t

Re: [Python-Dev] Misc re.match() complaint

Ok, created http://bugs.python.org/issue18468. On Mon, Jul 15, 2013 at 4:30 PM, Gregory P. Smith wrote: > > On Mon, Jul 15, 2013 at 4:14 PM, Guido van Rossum wrote: >> >> In a discussion about mypy I discovered that the Python 3 version of >> the re module's Match object behaves subtly different

Re: [Python-Dev] Misc re.match() complaint

On Mon, Jul 15, 2013 at 4:14 PM, Guido van Rossum wrote: > In a discussion about mypy I discovered that the Python 3 version of > the re module's Match object behaves subtly different from the Python > 2 version when the target string (i.e. the haystack, not the needle) > is a buffer object. > >

[Python-Dev] Misc re.match() complaint

In a discussion about mypy I discovered that the Python 3 version of the re module's Match object behaves subtly different from the Python 2 version when the target string (i.e. the haystack, not the needle) is a buffer object. In Python 2, the type of the return value of group() is always either

Re: [Python-Dev] Tweaking PEP 8 guidelines for use of leading underscores

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.

Re: [Python-Dev] Tweaking PEP 8 guidelines for use of leading underscores

On 16 Jul 2013 06:13, "Barry Warsaw" wrote: > > 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. :

Re: [Python-Dev] Tweaking PEP 8 guidelines for use of leading underscores

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

Re: [Python-Dev] Tweaking PEP 8 guidelines for use of leading underscores

On Mon, 15 Jul 2013 15:51:31 -0400 Barry Warsaw wrote: > 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

Re: [Python-Dev] Refactoring test.support into a subpackage

On 7/15/2013 6:22 AM, Nick Coghlan wrote: At the PyCon AU sprints, some of the sprinters worked on a plan Chris Jerdonek and I came up with months ago to convert test.support from a module into a subpackage. This plan arose from some nasty test suite hacks in the lead up to the release of Python

Re: [Python-Dev] Tweaking PEP 8 guidelines for use of leading underscores

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

Re: [Python-Dev] PEP 447: hooking into super() attribute resolution

On Mon, Jul 15, 2013 at 9:56 AM, Ronald Oussoren wrote: > > On 15 Jul, 2013, at 18:49, Guido van Rossum wrote: >> >> >>> A major open issue: the __locallookup__ method could also be used for >>> normal attribute resolution, but that probably causes issues with attribute >>> caching (see the PEP

Re: [Python-Dev] [Python-checkins] cpython: Issue #18393: Remove use of deprecated API on OSX

On Mon, Jul 15, 2013 at 11:32 AM, ronald.oussoren wrote: > http://hg.python.org/cpython/rev/ccbaf6762b54 > changeset: 84634:ccbaf6762b54 > user:Ronald Oussoren > date:Mon Jul 15 18:32:09 2013 +0200 > summary: > Issue #18393: Remove use of deprecated API on OSX > > The "Gestalt

Re: [Python-Dev] PEP 447: hooking into super() attribute resolution

On 15 Jul, 2013, at 18:49, Guido van Rossum wrote: > > >> A major open issue: the __locallookup__ method could also be used for normal >> attribute resolution, but that probably causes issues with attribute caching >> (see the PEP for details). I haven't worked out yet if it is worthwhile to

Re: [Python-Dev] PEP 447: hooking into super() attribute resolution

On Mon, Jul 15, 2013 at 8:12 AM, Ronald Oussoren wrote: > I've posted a new update of my proposal to add a way to override the > attribute resolution proces by super(). I've rewritten the PEP and > implementation based on feedback by Steve Dower. > > In the current edition of the proposal the ho

[Python-Dev] PEP 447: hooking into super() attribute resolution

Hi, I've posted a new update of my proposal to add a way to override the attribute resolution proces by super(). I've rewritten the PEP and implementation based on feedback by Steve Dower. In the current edition of the proposal the hook is a method on the type, defined in a metaclass for types

Re: [Python-Dev] Hooking into super() attribute resolution

On 9 Jul, 2013, at 1:21, Steve Dower wrote: > > Except that if it's on a metaclass, the 'instance' it has access to is cls. > The descriptor side of things is more interesting, but I see no reason why > super can't do that itself, since it knows the actual instance to call > __get__ with. (P

[Python-Dev] Refactoring test.support into a subpackage

At the PyCon AU sprints, some of the sprinters worked on a plan Chris Jerdonek and I came up with months ago to convert test.support from a module into a subpackage. This plan arose from some nasty test suite hacks in the lead up to the release of Python 3.3, where some of the pkgutil tests ended

Re: [Python-Dev] Adding Python scripts to PATHEXT on Windows

On 15 July 2013 18:42, Paul Moore wrote: > On 15 July 2013 09:40, Nick Coghlan wrote: >> >> Sounds good to me - in the long run it may allow us to drop the Windows >> exe wrappers when installing scripts on Windows. > > > That's my motivation. In particular removing pip's exe wrappers to ease som

Re: [Python-Dev] Adding Python scripts to PATHEXT on Windows

On 15 July 2013 09:40, Nick Coghlan wrote: > Sounds good to me - in the long run it may allow us to drop the Windows > exe wrappers when installing scripts on Windows. That's my motivation. In particular removing pip's exe wrappers to ease some of the issues being flagged on distutils-sig. Paul

Re: [Python-Dev] Adding Python scripts to PATHEXT on Windows

+1 BTW: I use lots of "*.py-executables" on Linux and OSX, so different extension don't bother me. Gerald Am 15.07.2013 um 10:26 schrieb Paul Moore : > With the addition of the Python launcher (PEP 397), Python scripts on > Windows are executable in much the same way as on Unix. However, "out

Re: [Python-Dev] Adding Python scripts to PATHEXT on Windows

Sounds good to me - in the long run it may allow us to drop the Windows exe wrappers when installing scripts on Windows. Cheers, Nick. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http

[Python-Dev] Adding Python scripts to PATHEXT on Windows

With the addition of the Python launcher (PEP 397), Python scripts on Windows are executable in much the same way as on Unix. However, "out of the box" it is still not quite possible to use Python scripts. This is because the .py extension is not registered with Windows in the PATHEXT environment v

Re: [Python-Dev] Tweaking PEP 8 guidelines for use of leading underscores

On 15 July 2013 17:31, Terry Reedy wrote: > I do not think absence of documentation is a good signal. I would rather say > that any private or partially private package that does not have a _ name > *must* have a docstring saying that it is all or mostly private. (Or be a > subpackage or module o

Re: [Python-Dev] PLY in stdlib (was cffi in stdlib)

On 15 July 2013 07:01, Raymond Hettinger wrote: > I would love to have PLY in the standard library. > It would open up a whole new world to some users > and be the basis for tool generation for others. > +1. Parser generators are useful tools - parsers are right on the boundary of "easy enough to

Re: [Python-Dev] PLY in stdlib (was cffi in stdlib)

On 15 July 2013 16:01, Raymond Hettinger wrote: > > On Jul 14, 2013, at 6:32 AM, David Beazley wrote: > > I honestly don't have any particular thoughts about PLY vs. other parser > generators and the merits of their inclusion (or not) in the standard > library. > > > I would love to have PLY in t

Re: [Python-Dev] Tweaking PEP 8 guidelines for use of leading underscores

On 7/15/2013 12:17 AM, Nick Coghlan wrote: You'd be surprised how many non-core devs react with astonishment when I suggest that not documenting something isn't enough to avoid having users consider it a supported public API - they usually get it after I point out how far you can usually get ju