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" 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 explaining
that
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 chang
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" t
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 pro
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
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
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 Fri, 2013-05-31 at 03:05 +0200, Łukasz Langa wrote:
> On 31 maj 2013, at 01:51, Łukasz Langa 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 single dispatch,
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 concre
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-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 issu
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.
inter
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
On 06/21/2012 12:26 PM, PJ Eby wrote:
On Thu, Jun 21, 2012 at 11:50 AM, Chris McDonough mailto:chr...@plope.com>> wrote:
On 06/21/2012 11:37 AM, PJ Eby wrote:
On Jun 21, 2012 11:02 AM, "Zooko Wilcox-O'Hearn"
mailto:zo...@zooko.com>
On 06/21/2012 11:45 AM, PJ Eby wrote:
On Jun 21, 2012 10:12 AM, "Chris McDonough" 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 t
On 06/21/2012 11:37 AM, PJ Eby wrote:
On Jun 21, 2012 11:02 AM, "Zooko Wilcox-O'Hearn" 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 I don't exac
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 mor
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 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 Pyth
On 06/21/2012 04:45 AM, Nick Coghlan wrote:
On Thu, Jun 21, 2012 at 2:44 PM, Chris McDonough 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 specify dependencies
On 06/20/2012 11:57 PM, Nick Coghlan wrote:
On Thu, Jun 21, 2012 at 3:29 AM, PJ Eby wrote:
On Wed, Jun 20, 2012 at 9:02 AM, Nick Coghlan wrote:
On Wed, Jun 20, 2012 at 9:46 PM, Antoine Pitrou
wrote:
Agreed, especially if the "proven in the wild" criterion is required
(people won't rush to a
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 exc
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
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 properl
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 practi
On Tue, 2012-02-28 at 15:54 -0500, Benjamin Peterson wrote:
> 2012/2/28 Ethan Furman :
> > 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.
> >
> >
> > He
On Mon, 2012-02-27 at 21:43 +, Vinay Sajip wrote:
> Chris McDonough 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
On Mon, 2012-02-27 at 21:03 +, Vinay Sajip wrote:
> Chris McDonough 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
On Mon, 2012-02-27 at 21:07 +, Paul Moore wrote:
> On 27 February 2012 20:39, Chris McDonough 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 ma
On Mon, 2012-02-27 at 20:18 +, Vinay Sajip wrote:
> Chris McDonough 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 ol
On Mon, 2012-02-27 at 15:23 -0500, R. David Murray wrote:
> On Mon, 27 Feb 2012 14:50:21 -0500, Chris McDonough wrote:
> > Currently we handle 3.2 compatibility in packages that "straddle" via
> > six-like functions. We can continue doing this as necessary. If the
>
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 idi
On Mon, 2012-02-27 at 12:41 -0500, R. David Murray wrote:
> On Mon, 27 Feb 2012 09:05:54 -0800, Ethan Furman 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
> > >> wrote:
> > >>> A small quibble: I'd like
On Sun, 2012-02-26 at 23:06 +, Vinay Sajip wrote:
> Chris McDonough 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.
>
&g
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 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
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 imp
On Fri, 2011-12-09 at 16:36 +1000, Nick Coghlan wrote:
> On Fri, Dec 9, 2011 at 4:01 PM, Chris McDonough 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
> > equivale
On Thu, 2011-12-08 at 21:43 -0800, Guido van Rossum wrote:
> On Thu, Dec 8, 2011 at 9:33 PM, Chris McDonough
> 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
>
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 theref
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
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 ther
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 nex
On Thu, 2011-12-08 at 01:18 -0500, Benjamin Peterson wrote:
> 2011/12/8 Chris McDonough :
> > On Thu, 2011-12-08 at 01:02 -0500, Benjamin Peterson wrote:
> >> 2011/12/8 Chris McDonough :
> >> > On the heels of Armin's blog post about the troubles of making t
On Thu, 2011-12-08 at 01:02 -0500, Benjamin Peterson wrote:
> 2011/12/8 Chris McDonough :
> > 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.
> >
>
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 (see
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é gmail.com> writes:
>
> > IOW, the task to do is:
> >
> > 1/ copy packaging and all its stdlib dependencies in a standalone pr
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 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.pars
On Tue, 2010-09-21 at 08:19 +1000, Nick Coghlan wrote:
> On Tue, Sep 21, 2010 at 7:39 AM, Chris McDonough wrote:
> > On Tue, 2010-09-21 at 07:12 +1000, Nick Coghlan wrote:
> >> On Tue, Sep 21, 2010 at 4:30 AM, Chris McDonough wrote:
> >> > Existing APIs save for &qu
On Tue, 2010-09-21 at 07:12 +1000, Nick Coghlan wrote:
> On Tue, Sep 21, 2010 at 4:30 AM, Chris McDonough 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.
&g
On Mon, 2010-09-20 at 23:23 +1000, Nick Coghlan wrote:
> On Mon, Sep 20, 2010 at 10:12 PM, Chris McDonough wrote:
> > urllib.parse.urlparse/urllib.parse.urlsplit will never need to decode
> > anything when passed bytes input.
>
> Correct. Supporting manipulation of bytes di
On Sun, 2010-09-19 at 12:03 +1000, Nick Coghlan wrote:
> On Sun, Sep 19, 2010 at 4:18 AM, John Nagle 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 writing the
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 wr
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 PEP
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 pro
On Wed, 2010-09-15 at 14:59 -0400, Chris McDonough wrote:
> 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).
That
On Wed, 2010-06-09 at 01:15 -0400, Fred Drake wrote:
> On Wed, Jun 9, 2010 at 12:30 AM, Senthil Kumaran 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 that
> > 2.7 i
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
http://mail.python
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 confide
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 "recreat
Daniel Stutzbach wrote:
> On Wed, Mar 4, 2009 at 12:54 PM, Guido van Rossum 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 problems
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
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
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
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, 2006
From the initial bugreport
(http://sourceforge.net/tracker/index.php?
func=detail&aid=1112549&group_id=5470&atid=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
71 matches
Mail list logo
