On Tue, Dec 13, 2011 at 23:38, Nick Coghlan wrote:
> On Wed, Dec 14, 2011 at 8:17 AM, Michael Foord
> wrote:
>> More specifically "six" [1] is the name of Benjamin Peterson's support
>> package to help write code that works on both 2 and 3. So the idea is that
>> the conversion isn't just a strai
On 12/13/2011 7:01 PM, "Martin v. Löwis" wrote:
What I'm asking is that
(1) The other values be documented as reserved, rather than as illegal.
How is that different?
(2) The macros produce an error rather than silently corrupting data.
In debug mode, or release mode? -1 on release mode.
On 12/13/2011 6:36 PM, exar...@twistedmatrix.com wrote:
On 09:37 pm, tjre...@udel.edu wrote:
On 12/13/2011 10:54 AM, Vinay Sajip wrote:
I started writing a tool today, tentatively called '2to23', which
aims to do
this. It's basically 2to3, but with a package of custom fixers in a
package
'lib2t
On Tue, Dec 13, 2011 at 7:30 PM, Antoine Pitrou wrote:
> On Tue, 13 Dec 2011 14:02:45 -0500
> PJ Eby wrote:
> >
> > Among other things, it means that:
> >
> > * There's only one codebase
> > * If the conversion isn't perfect, you only have to fix it once
> > * Line numbers are the same
> > * The
On Tue, 13 Dec 2011 14:02:45 -0500
PJ Eby wrote:
>
> Among other things, it means that:
>
> * There's only one codebase
> * If the conversion isn't perfect, you only have to fix it once
> * Line numbers are the same
> * There's no conversion step slowing down development
>
> So, I expect that i
> Any chance of adding the rationale to the code?
I'm really short of time right now, so you need to find somebody
else to make such a change.
> I am willing to believe that requests for a wchar_t (or utf-8 or
> System Locale charset) representation are common enough to justify
> caching the data
On 09:37 pm, tjre...@udel.edu wrote:
On 12/13/2011 10:54 AM, Vinay Sajip wrote:
I started writing a tool today, tentatively called '2to23', which aims
to do
this. It's basically 2to3, but with a package of custom fixers in a
package
'lib2to23.fixers' adapted from the corresponding fixers in li
14.12.11 00:38, Nick Coghlan написав(ла):
String translation is also an open question. For some codebases, you
want both u"" and "" to translate to a Unicode "" (either in Py3k or
via the future import), but if a code base deals with WSGI-style
native strings (by means of u"" for text, "" for nat
On Dec 14, 2011, at 08:38 AM, Nick Coghlan wrote:
>String translation is also an open question. For some codebases, you
>want both u"" and "" to translate to a Unicode "" (either in Py3k or
>via the future import)
I have a fixer for this:
http://bazaar.launchpad.net/~barry/flufl.i18n/devel/view/
On Wed, Dec 14, 2011 at 8:17 AM, Michael Foord
wrote:
> More specifically "six" [1] is the name of Benjamin Peterson's support
> package to help write code that works on both 2 and 3. So the idea is that
> the conversion isn't just a straight syntax conversion - but that it [could]
> generate code
On 13/12/2011 21:10, Terry Reedy wrote:
On 12/13/2011 2:02 PM, PJ Eby wrote:
On Tue, Dec 13, 2011 at 11:24 AM, Antoine Pitrou mailto:solip...@pitrou.net>> wrote:
On Tue, 13 Dec 2011 15:28:31 +0100
"Laurence Rowe" mailto:l...@lrowe.co.uk>> wrote:
>
> The approach that most people seem to
On 12/13/2011 10:54 AM, Vinay Sajip wrote:
I started writing a tool today, tentatively called '2to23', which aims to do
this. It's basically 2to3, but with a package of custom fixers in a package
'lib2to23.fixers' adapted from the corresponding fixers in lib2to3.
When, some year in the future,
On Tue, Dec 13, 2011 at 2:55 AM, "Martin v. Löwis" wrote:
>> (1) Why is PyObject_HEAD used instead of PyObject_VAR_HEAD?
> The unicode object is not a var object. In a var object, tp_itemsize
> gives the element size, which is not possible for unicode objects,
> since the itemsize may vary by in
On 12/13/2011 2:02 PM, PJ Eby wrote:
On Tue, Dec 13, 2011 at 11:24 AM, Antoine Pitrou mailto:solip...@pitrou.net>> wrote:
On Tue, 13 Dec 2011 15:28:31 +0100
"Laurence Rowe" mailto:l...@lrowe.co.uk>> wrote:
>
> The approach that most people seem to have settled on for porting
On 12/12/2011 10:56 PM, Ben Wolfson wrote:
> Hi,
>
> I'm hoping to get some kind of consensus about the divergences between
> the implementation and documentation of str.format
> (http://mail.python.org/pipermail/python-dev/2011-June/111860.html and
> the linked bug report contain examples of the
On Tue, Dec 13, 2011 at 11:24 AM, Antoine Pitrou wrote:
> On Tue, 13 Dec 2011 15:28:31 +0100
> "Laurence Rowe" wrote:
> >
> > The approach that most people seem to have settled on for porting
> > libraries to Python 3 is to make a single codebase that is compatible
> with
> > both Python 2 and Py
On Tue, Dec 13, 2011 at 14:33, Laurence Rowe wrote:
> Could this manual work be cut down if there was a version of 2to3 that
> targeted the subset of the language that is compatible with both 2 and 3?
Not really, but a 2to6, ie something that tries to keep Python 2
compatibility by using the six
On Dec 13, 2011, at 05:24 PM, Antoine Pitrou wrote:
>On Tue, 13 Dec 2011 15:28:31 +0100
>"Laurence Rowe" wrote:
>>
>> The approach that most people seem to have settled on for porting
>> libraries to Python 3 is to make a single codebase that is compatible with
>> both Python 2 and Python 3,
On Tue, 13 Dec 2011 15:28:31 +0100
"Laurence Rowe" wrote:
>
> The approach that most people seem to have settled on for porting
> libraries to Python 3 is to make a single codebase that is compatible with
> both Python 2 and Python 3, perhaps making use of the six library.
Do you have eviden
Laurence Rowe lrowe.co.uk> writes:
> The approach that most people seem to have settled on for porting
> libraries to Python 3 is to make a single codebase that is compatible with
> both Python 2 and Python 3, perhaps making use of the six library. If I
> understand correctly, Chris' experi
On 13/12/2011 14:28, Laurence Rowe wrote:
On Tue, 13 Dec 2011 14:42:12 +0100, Michael Foord
wrote:
On 13/12/2011 13:33, Laurence Rowe wrote:
On Mon, 12 Dec 2011 22:18:40 +0100, Chris McDonough
wrote:
On Mon, 2011-12-12 at 09:50 -0500, PJ Eby wrote:
As someone who ported WebOb a
On Tue, 13 Dec 2011 14:42:12 +0100, Michael Foord
wrote:
On 13/12/2011 13:33, Laurence Rowe wrote:
On Mon, 12 Dec 2011 22:18:40 +0100, Chris McDonough
wrote:
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
On 13/12/2011 14:24, Nick Coghlan wrote:
Input = normal 2.x code; Output = code that runs on both 2.x and 3.x.
That is, tinkering with what 2to3 produces, not what it accepts.
How is that different from what 2to3 currently does? Are you agreeing
with Laurence, suggesting an alternative, or
Input = normal 2.x code; Output = code that runs on both 2.x and 3.x.
That is, tinkering with what 2to3 produces, not what it accepts.
--
Nick Coghlan (via Gmail on Android, so likely to be more terse than usual)
On Dec 13, 2011 11:46 PM, "Michael Foord" wrote:
> On 13/12/2011 13:33, Laurence R
On 13/12/2011 13:33, Laurence Rowe wrote:
On Mon, 12 Dec 2011 22:18:40 +0100, Chris McDonough
wrote:
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 uni
On Mon, 12 Dec 2011 22:18:40 +0100, Chris McDonough
wrote:
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
2011/12/13 Armin Rigo
> No, the behavior _is_ undefined. The comment you cited says that it
> cannot crash the Python interpreter; additionally, it makes a
> best-effort attempt at catching such accesses and raising ValueError.
> But I think I can build a strange-looking example where you mutate
Hi,
On Tue, Dec 13, 2011 at 11:37, Amaury Forgeot d'Arc wrote:
>> "When sorting a list using the sort() method, attempting to inspect or
>> mutate the content of the list will result in undefined behaviour."
>
> (...)
> So behaviour is not undefined at all...
No, the behavior _is_ undefined. Th
2011/12/12 Victor Stinner
> "When sorting a list using the sort() method, attempting to inspect or
> mutate the content of the list will result in undefined behaviour."
But is this even true? in listobject.c::listsort(), since 2002,
/* The list is temporarily made empty, so that mutations perfo
Ben Wolfson wrote:
> Hi,
>
> I'm hoping to get some kind of consensus about the divergences between
> the implementation and documentation of str.format
> (http://mail.python.org/pipermail/python-dev/2011-June/111860.html and
> the linked bug report contain examples of the divergences). These
> pe
On Tue, Dec 13, 2011 at 6:37 PM, Raymond Hettinger
wrote:
>
> On Dec 12, 2011, at 7:56 PM, Ben Wolfson wrote:
>
> I personally would prefer (1) to (2) or (3), and (3) to (2), had I my
> druthers, but it doesn't matter a *whole* lot to me; I'd prefer any of
> them to nothing (or to changing the doc
On Dec 12, 2011, at 7:56 PM, Ben Wolfson wrote:
> I personally would prefer (1) to (2) or (3), and (3) to (2), had I my
> druthers, but it doesn't matter a *whole* lot to me; I'd prefer any of
> them to nothing (or to changing the docs to reflect the current batty
> behavior).
+1 on changing the
32 matches
Mail list logo