On 12/16/2014 03:09 AM, Barry Warsaw wrote:
On Dec 16, 2014, at 02:15 PM, Skip Montanaro wrote:
While he doesn't explicitly say so, I got the distinct impression reading
his recent blog post that he supports one source, not forked sources.
I've ported a fair bit of code, both pure-Python and
On 08/17/2014 09:40 PM, Antoine Pitrou wrote:
Le 17/08/2014 20:08, Nick Coghlan a écrit :
On 18 Aug 2014 09:57, Barry Warsaw ba...@python.org
mailto:ba...@python.org wrote:
On Aug 18, 2014, at 09:12 AM, Nick Coghlan wrote:
I'm talking more generally - do you *really* want to be
On 04/19/2014 07:41 AM, Kristján Valur Jónsson wrote:
Wouldn't iterkeys simply be an alias for keys and so on?
I'm +1 on that.
It is a signigificant portion of the incompatibility, and seems like such a
minor concession to compatibility to make.
K
FWIW, I'm +1 on this and other minor changes
On Tue, 2013-07-16 at 15:44 +1000, Nick Coghlan wrote:
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
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 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 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 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
On Fri, 2013-05-31 at 03:05 +0200, Łukasz Langa wrote:
On 31 maj 2013, at 01:51, Łukasz Langa luk...@langa.pl wrote:
Back to the point, though. I don't feel we should complicate the
code, tests and documentation by introducing special handling
for methods. In terms of pure type-driven
On Fri, 2013-05-24 at 15:56 -0400, Barry Warsaw wrote:
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.
On Sat, 2013-05-25 at 17:57 +1000, Nick Coghlan wrote:
I think the simplest thing to do is just append the 3 to the binary
name (as we do ourselves for pydoc) and then abide by the
recommendations in PEP 394 to reference the correct system executable.
I'm curious if folks have other concrete
On Sat, 2013-01-19 at 14:30 -0500, Benjamin Peterson wrote:
It's been almost a year since 2.7.3, so it's time for another 2.7
bugfix release.
2013-02-02 - 2.7.4 release branch created; rc released
2013-02-16 - 2.7.4 released
Does this work for you, Martin and Ned?
I have a pet issue that
On 06/28/2012 06:36 AM, Benoît Bryon wrote:
Le 27/06/2012 13:34, Antoine Pitrou a écrit :
Similarly, I think the section about private projects (Private
(including closed-source) projects use a namespace) should be removed.
It is not our duty to promote naming standards for private (i.e.
On 06/21/2012 04:45 AM, Nick Coghlan wrote:
On Thu, Jun 21, 2012 at 2:44 PM, Chris McDonoughchr...@plope.com wrote:
All of these are really pretty minor issues compared with the main benefit
of not needing to ship everything with everything else. The killer feature
is that developers can
On 06/21/2012 08:21 AM, Nick Coghlan wrote:
Installing a distribution will change behavior whether or not sys.path is
changed as a result. That's its purpose.
No it won't. An ordinary package will only change the behaviour of
Python applications that import a package by that name. Other
On 06/21/2012 09:29 AM, Nick Coghlan wrote:
My only comment on that is this: Since this is a problem related to the
installation of Python distributions, it should deal with the problems that
Python developers have more forcefully than non-Python developers and
non-programmers.
Thanks to venv,
On 06/21/2012 10:30 AM, Nick Coghlan wrote:
A tool to generate an OS-specific system package from a Python library
project should be unrelated to a Python distribution *installer*. Instead,
you'd use related tools that understood how to unpack the distribution
packaging format to build one or
On 06/21/2012 11:37 AM, PJ Eby wrote:
On Jun 21, 2012 11:02 AM, Zooko Wilcox-Oapos;Hearn zo...@zooko.com
mailto:zo...@zooko.com wrote:
Philip J. Eby provisionally approved of one of the patches, except for
some specific requirement that I didn't really understand how to fix
and that now
On 06/21/2012 11:45 AM, PJ Eby wrote:
On Jun 21, 2012 10:12 AM, Chris McDonough chr...@plope.com
mailto:chr...@plope.com wrote:
- Install package resources, which are non-Python source files that
happen to live in package directories.
I love this phrasing, by the way (non-Python source
On 06/21/2012 12:26 PM, PJ Eby wrote:
On Thu, Jun 21, 2012 at 11:50 AM, Chris McDonough chr...@plope.com
mailto:chr...@plope.com wrote:
On 06/21/2012 11:37 AM, PJ Eby wrote:
On Jun 21, 2012 11:02 AM, Zooko Wilcox-Oapos;Hearn
zo...@zooko.com mailto:zo...@zooko.com
On 06/21/2012 01:20 PM, Tarek Ziadé wrote:
On 6/21/12 6:44 PM, Chris McDonough wrote:
Yes. At the very least, there will be updated development snapshots
(which are what buildout uses anyway).
(Official releases are in a bit of a weird holding pattern.
distribute's versioning scheme leads
On 06/20/2012 11:57 PM, Nick Coghlan wrote:
On Thu, Jun 21, 2012 at 3:29 AM, PJ Ebyp...@telecommunity.com wrote:
On Wed, Jun 20, 2012 at 9:02 AM, Nick Coghlanncogh...@gmail.com wrote:
On Wed, Jun 20, 2012 at 9:46 PM, Antoine Pitrousolip...@pitrou.net
wrote:
Agreed, especially if the proven
On 06/19/2012 05:46 PM, Éric Araujo wrote:
Hi all,
We need to make a decision about the packaging module in Python 3.3.
Please read this message and breathe deeply before replying :)
...
With beta coming, a way to deal with that unfortunate situation needs to
be found. We could (a) grant an
On Sun, 2012-03-04 at 17:34 +1000, Nick Coghlan wrote:
My rewritten version of PEP 414 is now up
(http://www.python.org/dev/peps/pep-0414/). It describes in detail a
lot more of the historical background that was taken as read when
Guido accepted the PEP.
Just as support for string
On Fri, 2012-03-02 at 14:41 -0500, Barry Warsaw wrote:
On Mar 02, 2012, at 02:48 PM, Nick Coghlan wrote:
Consider: an application that uses 8-bit strings everywhere and blows up on
non-ASCII data in Python 2 has at least a fighting chance to run unmodified
*and* handle Unicode properly on
On Fri, 2012-03-02 at 15:39 -0500, Barry Warsaw wrote:
On Mar 02, 2012, at 03:13 PM, Chris McDonough wrote:
FWIW, I think this issue's webness may be overestimated. There happens to be
lots and lots of existing UI code which contains complex interactions between
unicode literals
On Tue, 2012-02-28 at 15:54 -0500, Benjamin Peterson wrote:
2012/2/28 Ethan Furman et...@stoneleaf.us:
Here's what I know:
We don't add features to bug-fix releases.
u'' is considered a feature.
By not backporting to 3.1 and 3.2 we are not easing the migration pains from
2.x.
On Tue, 2012-02-28 at 16:48 -0500, Barry Warsaw wrote:
On Feb 28, 2012, at 03:54 PM, Benjamin Peterson wrote:
If there is already a FAQ entry feel free to point me to it, but I would
still be curious why, in this instance, practicality does not beat purity?
Because it's practical not to
On Mon, 2012-02-27 at 12:41 -0500, R. David Murray wrote:
On Mon, 27 Feb 2012 09:05:54 -0800, Ethan Furman et...@stoneleaf.us wrote:
Martin v. Löwis wrote:
Am 26.02.2012 07:06, schrieb Nick Coghlan:
On Sun, Feb 26, 2012 at 1:13 PM, Guido van Rossum gu...@python.org
wrote:
A small
On Mon, 2012-02-27 at 13:44 -0500, Terry Reedy wrote:
On 2/27/2012 1:01 PM, Chris McDonough wrote:
On Mon, 2012-02-27 at 12:41 -0500, R. David Murray wrote:
Eh? The 2.6 version would also be u('that'). That's the whole point
of the idiom. You'll need a better counter argument than
On Mon, 2012-02-27 at 15:23 -0500, R. David Murray wrote:
On Mon, 27 Feb 2012 14:50:21 -0500, Chris McDonough chr...@plope.com wrote:
Currently we handle 3.2 compatibility in packages that straddle via
six-like functions. We can continue doing this as necessary. If the
It seems to me
On Mon, 2012-02-27 at 20:18 +, Vinay Sajip wrote:
Chris McDonough chrism at plope.com writes:
I suspect not everyone lives and dies by OS distribution release support
policies. Many folks are both willing and capable to install a newer
Python on an older OS.
But many folks aren't
On Mon, 2012-02-27 at 21:07 +, Paul Moore wrote:
On 27 February 2012 20:39, Chris McDonough chr...@plope.com wrote:
Note that u'' literals are sort of the tip of the iceberg here;
supporting them will obviously not make development under the subset an
order of magnitude less sucky, just
On Mon, 2012-02-27 at 21:03 +, Vinay Sajip wrote:
Chris McDonough chrism at plope.com writes:
I really don't know how long I'll need to do future development in the
subset language of Python 2 and Python 3 because I can't predict the
future. It could be two years, it might be five
On Mon, 2012-02-27 at 21:43 +, Vinay Sajip wrote:
Chris McDonough chrism at plope.com writes:
It's great to have software that installs easily. That said, the
versions of Python that my software supports is (and has to be) be my
choice.
Of course. And if I understand correctly
On Sun, 2012-02-26 at 16:06 -0500, Barry Warsaw wrote:
On Feb 26, 2012, at 09:20 PM, Nick Coghlan wrote:
It reduces the problem (compared to omitting the import and using a
u() function), but it's still ugly and still involves the action at a
distance of the unicode literals import.
On Sun, 2012-02-26 at 23:06 +, Vinay Sajip wrote:
Chris McDonough chrism at plope.com writes:
If we use the unicode_literals future import, or some other exernal
module strategy, it doesn't help much with the hitnrun contributor
thing, I fear.
Surely some curating of hit-and-run
On Sat, 2011-12-10 at 15:55 +1000, Nick Coghlan wrote:
So I'm back to being -1 on the idea of adding back u'' literals for
3.3. Instead, people should explicitly call str() on any literals that
they want to be actual str instances both in 3.x and in 2.x when the
unicode literals future import
On Mon, 2011-12-12 at 09:50 -0500, PJ Eby wrote:
As someone who ported WebOb and other stuff built on top of it
to Python
3 without using from __future__ import unicode_literals, I'm
kinda sad
that to be using best practice I'll have to go back and
On Thu, 2011-12-08 at 22:34 -0500, Barry Warsaw wrote:
On Dec 09, 2011, at 03:50 AM, Lennart Regebro wrote:
One reason is that you need to be able to say This should be str in
Python 2, and binary in Python 3, that should be Unicode in Python 2
and str in Python 3, and that over there should
On Fri, 2011-12-09 at 03:50 +0100, Lennart Regebro wrote:
from future import unicode_literals is my fault. I'm sorry. It's
pretty useless. It was suggested by somebody and I then supported it's
adding, instead of allowing u'' which I suggested. But it doesn't
work.
One reason is that you
On Thu, 2011-12-08 at 19:52 -0500, Glyph wrote:
Zooming back in to the actual issue this thread is about, I think the
u-vs- issue is a bit of a red herring, because the _real_ problem
here is that 2to3 is slow and buggy and so migration efforts are
starting to work around it, and therefore
On Thu, 2011-12-08 at 21:43 -0800, Guido van Rossum wrote:
On Thu, Dec 8, 2011 at 9:33 PM, Chris McDonough chr...@plope.com
wrote:
On Thu, 2011-12-08 at 19:52 -0500, Glyph wrote:
Zooming back in to the actual issue this thread is about, I
think the
u-vs
On Fri, 2011-12-09 at 16:36 +1000, Nick Coghlan wrote:
On Fri, Dec 9, 2011 at 4:01 PM, Chris McDonough chr...@plope.com wrote:
On the consumer side, folks who want to run 2.6/2.7/3.3-only codebases
will have the wherewithal to compile their own Python 3 (or use a PPA or
equivalent) until
On the heels of Armin's blog post about the troubles of making the same
codebase run on both Python 2 and Python 3, I have a concrete
suggestion.
It would help a lot for code that straddles both Py2 and Py3 to be able
to make use of u'' literals. It would seem to be an easy thing to
reenable
On Thu, 2011-12-08 at 01:02 -0500, Benjamin Peterson wrote:
2011/12/8 Chris McDonough chr...@plope.com:
On the heels of Armin's blog post about the troubles of making the same
codebase run on both Python 2 and Python 3, I have a concrete
suggestion.
It would help a lot for code
On Thu, 2011-12-08 at 01:18 -0500, Benjamin Peterson wrote:
2011/12/8 Chris McDonough chr...@plope.com:
On Thu, 2011-12-08 at 01:02 -0500, Benjamin Peterson wrote:
2011/12/8 Chris McDonough chr...@plope.com:
On the heels of Armin's blog post about the troubles of making the same
On Thu, 2011-12-08 at 17:33 +1000, Nick Coghlan wrote:
Such code still won't work on 3.2, hence restoring the redundant
notation would be ultimately pointless.
None of the code I've written which straddles Python 2/3 supports
anything except Python 3.2+, and likewise I expect that for the next
This is really very comprehensive, thank you!
Why not modify sys.prefix?
- --
As discussed above under `Backwards Compatibility`_, this PEP proposes
to add ``sys.site_prefix`` as the prefix relative to which
site-package directories are found. This maintains
I'll throw this out there.. why is it going to have a different name on
python2 than on python3?
- C
On Wed, 2011-08-17 at 22:30 +, Vinay Sajip wrote:
Tarek Ziadé ziade.tarek at gmail.com writes:
IOW, the task to do is:
1/ copy packaging and all its stdlib dependencies in a
On Tue, 2010-09-21 at 23:38 +1000, Nick Coghlan wrote:
And if this turns out to be a disaster in practice:
a) on my head be it; and
b) we still have the option of the DeprecationWarning dance for bytes
inputs to the existing functions and moving to a parallel API
In the case of urllib.parse,
On Tue, 2010-09-21 at 12:09 -0400, P.J. Eby wrote:
While the Web-SIG is trying to hash out PEP 444, I thought it would
be a good idea to have a backup plan that would allow the Python 3
stdlib to move forward, without needing a major new spec to settle
out implementation questions.
If a
On Sun, 2010-09-19 at 12:03 +1000, Nick Coghlan wrote:
On Sun, Sep 19, 2010 at 4:18 AM, John Nagle na...@animats.com wrote:
On 9/18/2010 2:29 AM, python-dev-requ...@python.org wrote:
Polymorphic best practices [was: (Not) delaying the 3.2 release]
If you're hung up on this, try
On Mon, 2010-09-20 at 23:23 +1000, Nick Coghlan wrote:
On Mon, Sep 20, 2010 at 10:12 PM, Chris McDonough chr...@plope.com wrote:
urllib.parse.urlparse/urllib.parse.urlsplit will never need to decode
anything when passed bytes input.
Correct. Supporting manipulation of bytes directly
On Tue, 2010-09-21 at 07:12 +1000, Nick Coghlan wrote:
On Tue, Sep 21, 2010 at 4:30 AM, Chris McDonough chr...@plope.com wrote:
Existing APIs save for quote don't really need to deal with charset
encodings at all, at least on any level that Python needs to care about.
The potential already
On Tue, 2010-09-21 at 08:19 +1000, Nick Coghlan wrote:
On Tue, Sep 21, 2010 at 7:39 AM, Chris McDonough chr...@plope.com wrote:
On Tue, 2010-09-21 at 07:12 +1000, Nick Coghlan wrote:
On Tue, Sep 21, 2010 at 4:30 AM, Chris McDonough chr...@plope.com wrote:
Existing APIs save for quote don't
For reference, I have developed a spec and an (untested) reference
implementation of a WSGI successor I've given the name Web3. Ian is
not hot on this spec (he prefers native strings as environ keys). I'm
definitely not going to write a WebOb analogue, so I'd more or less
given up trying to
On Wed, 2010-09-15 at 13:46 -0700, Brett Cannon wrote:
Both the RM and BDFL agree that Python 3.2b1 should be held up until
we settle this wsgi matter. That makes it a question of how to settle
it.
Thinking out loud here to keep this discussion focused, I say we give
a deadline for PEPs to
This spec, a WSGI-like spec for Python2 and Python3 named Web3 was
accepted today as PEP 444.
http://python.org/dev/peps/pep-0444/
Comments and competing specs would be useful.
- C
On Wed, 2010-09-15 at 18:16 -0400, Chris McDonough wrote:
On Wed, 2010-09-15 at 13:46 -0700, Brett Cannon wrote
On Wed, 2010-06-09 at 01:15 -0400, Fred Drake wrote:
On Wed, Jun 9, 2010 at 12:30 AM, Senthil Kumaran orsent...@gmail.com wrote:
it would still be a good idea to
introduce some of them in minor releases in 2.7. I know, this
deviating from the process, but it could be an option considering
Guido van Rossum wrote:
Please mail me topics you'd like to hear me talk about in my keynote
at PyCon this year.
Can you tell us where Uncle Timmy has been and when he'll be back?
___
Python-Dev mailing list
Python-Dev@python.org
Brett Cannon wrote:
IMO keeping Python 2.x around past 2.7 is the equivalent of python-dev
saying Python 3 is the future, but we are keeping the old Python 2.x
around because we don't have *that* much faith in the future we have
laid out. That's poison to Python 3 by showing a lack of
I've been trying to follow this discussion now for weeks. The signal to noise
ratio is pretty low.
I'd love to have an stdlib solution for distribution packaging and installation.
But I think we might as well pack it up and go home if the folks whom are
contributing to the discussion
Daniel Stutzbach wrote:
On Wed, Mar 4, 2009 at 12:54 PM, Guido van Rossum gu...@python.org wrote:
The same as always. We don't change APIs in bugfix releases.
This question is actually for the Zope folks and others who have had
problems with the 2.6 asyncore/asynchat:
Are any of the
zooko wrote:
On Mar 26, 2008, at 7:34 PM, Chris McDonough wrote:
zooko wrote:
http://mail.python.org/pipermail/python-dev/2008-March/078243.html
Here is a simple proposal: make the standard Python import
mechanism notice eggs on the PYTHONPATH and insert them (into the
*same
zooko wrote:
Folks:
Here is a simple proposal: make the standard Python import
mechanism notice eggs on the PYTHONPATH and insert them (into the
*same* location) on the sys.path.
This eliminates the #1 problem with eggs -- that they don't easily
work when installing them into
I have a very remedial question about how to fix test failures due to
the side effects of string-unicode integration.
The xmlrpc library uses explicit encoding to encode XML tag payloads
to (almost always) utf8. Tag literals are not encoded.
What would be the best way to mimic this behavior
Wrt http://www.python.org/dev/peps/pep-3101/
PEP 3101 says Py3K should allow item and attribute access syntax
within string templating expressions but to limit potential security
issues, access to underscore prefixed names within attribute/item
access expressions will be disallowed.
I am a
Would adding an API for sigprocmask help here?
(Although it has been tried before -- http://mail.python.org/
pipermail/python-dev/2003-February/033016.html and died in the womb
due to threading-related issues -- http://mail.mems-exchange.org/
durusmail/quixote-users/1248/)
- C
On Sep 2,
From the initial bugreport
(http://sourceforge.net/tracker/index.php?
func=detailaid=1112549group_id=5470atid=105470)
Various parts of cgi.FieldStorage call its
read_lines_to_outerboundary, read_lines and
skip_lines methods. These methods use the
readline method of the file object that
70 matches
Mail list logo
