On Jul 14, 2013, at 6:32 AM, David Beazley d...@dabeaz.com 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 the standard library.
It would open up a
2013/7/12 Andrea Griffini agr...@tin.it:
Is there any semantic difference between
BUILD_TUPLE 0
LOAD_CONST code object ...
MAKE_CLOSURE 0
and
LOAD_CONST code object ...
MAKE_FUNCTION 0
?
In other words is there any difference between a function and a closure that
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
On 15 July 2013 16:01, Raymond Hettinger raymond.hettin...@gmail.com wrote:
On Jul 14, 2013, at 6:32 AM, David Beazley d...@dabeaz.com 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
On 15 July 2013 07:01, Raymond Hettinger raymond.hettin...@gmail.comwrote:
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
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
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:
+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 p.f.mo...@gmail.com:
With the addition of the Python launcher (PEP 397), Python scripts on
Windows are executable in much the same way as on
On 15 July 2013 09:40, Nick Coghlan ncogh...@gmail.com 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
On 15 July 2013 18:42, Paul Moore p.f.mo...@gmail.com wrote:
On 15 July 2013 09:40, Nick Coghlan ncogh...@gmail.com 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
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
On 9 Jul, 2013, at 1:21, Steve Dower steve.do...@microsoft.com 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
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
On Mon, Jul 15, 2013 at 8:12 AM, Ronald Oussoren ronaldousso...@mac.com 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
On 15 Jul, 2013, at 18:49, Guido van Rossum gu...@python.org 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
On Mon, Jul 15, 2013 at 11:32 AM, ronald.oussoren
python-check...@python.org wrote:
http://hg.python.org/cpython/rev/ccbaf6762b54
changeset: 84634:ccbaf6762b54
user:Ronald Oussoren ronaldousso...@mac.com
date:Mon Jul 15 18:32:09 2013 +0200
summary:
Issue #18393: Remove
On Mon, Jul 15, 2013 at 9:56 AM, Ronald Oussoren ronaldousso...@mac.com wrote:
On 15 Jul, 2013, at 18:49, Guido van Rossum gu...@python.org wrote:
A major open issue: the __locallookup__ method could also be used for
normal attribute resolution, but that probably causes issues with
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 I
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
On Mon, 15 Jul 2013 15:51:31 -0400
Barry Warsaw ba...@python.org 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
On 16 Jul 2013 06:13, Barry Warsaw ba...@python.org 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. :)
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.
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
On Mon, Jul 15, 2013 at 4:14 PM, Guido van Rossum 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 the target string (i.e. the haystack, not the needle)
is a buffer
On 16/07/2013 00:30, Gregory P. Smith wrote:
On Mon, Jul 15, 2013 at 4:14 PM, Guido van Rossum gu...@python.org
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
On 16 Jul 2013 09:17, Guido van Rossum gu...@python.org 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
On Mon, Jul 15, 2013 at 5:10 PM, MRAB pyt...@mrabarnett.plus.com wrote:
On 16/07/2013 00:30, Gregory P. Smith wrote:
On Mon, Jul 15, 2013 at 4:14 PM, Guido van Rossum gu...@python.org
mailto:gu...@python.org wrote:
In a discussion about mypy I discovered that the Python 3 version of
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
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
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
On 16 July 2013 10:23, Chris McDonough chr...@plope.com 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
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
On 16/07/2013 01:25, Guido van Rossum wrote:
On Mon, Jul 15, 2013 at 5:10 PM, MRAB pyt...@mrabarnett.plus.com wrote:
On 16/07/2013 00:30, Gregory P. Smith wrote:
On Mon, Jul 15, 2013 at 4:14 PM, Guido van Rossum gu...@python.org
mailto:gu...@python.org wrote:
In a discussion about mypy
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 have
On Mon, Jul 15, 2013 at 7:18 PM, MRAB pyt...@mrabarnett.plus.com 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
On 16 July 2013 12:20, Chris McDonough chr...@plope.com 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
2013/7/16 benjamin.peterson python-check...@python.org:
http://hg.python.org/cpython/rev/8889c9b5dd3a
changeset: 84654:8889c9b5dd3a
branch: 3.3
parent: 84653:c3a510b22218
parent: 84652:8a078bf3cf14
user:Benjamin Peterson benja...@python.org
date:Mon Jul 15
2013/7/16 benjamin.peterson python-check...@python.org:
http://hg.python.org/cpython/rev/c3a510b22218
changeset: 84653:c3a510b22218
branch: 3.3
parent: 84651:e22dd5fda5a8
user:Benjamin Peterson benja...@python.org
date:Mon Jul 15 19:15:34 2013 -0700
summary:
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 existing
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 lines of
On 16 July 2013 12:20, Guido van Rossum gu...@python.org wrote:
On Mon, Jul 15, 2013 at 7:03 PM, Stephen J. Turnbull step...@xemacs.org
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
On 16 July 2013 13:02, Chris McDonough chr...@plope.com 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
On Tue, 2013-07-16 at 13:11 +1000, Nick Coghlan wrote:
On 16 July 2013 13:02, Chris McDonough chr...@plope.com 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.
2013/7/15 Victor Stinner victor.stin...@gmail.com:
2013/7/16 benjamin.peterson python-check...@python.org:
http://hg.python.org/cpython/rev/c3a510b22218
changeset: 84653:c3a510b22218
branch: 3.3
parent: 84651:e22dd5fda5a8
user:Benjamin Peterson benja...@python.org
date:
On 16 July 2013 13:16, Chris McDonough chr...@plope.com 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*!
45 matches
Mail list logo
