Hello,
2007/7/17, Joe Smith wrote:
> Building Py3k_struni under Cygwin I've noticed a few more tests failing than
> the wiki shows.
> These are using SVN revision 56413.
>
> Some spurious errors seem to occur if Python/ is not remaned temporally. I
> have not included those. (This is an oddity of
On 7/17/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 01:37 PM 7/18/2007 +1200, Greg Ewing wrote:
> >Phillip J. Eby wrote:
> > > It allows the framework to bootstrap via successive
> > > approximation. Initially, the 'implies()' function is just a plain
> > > function, and then it later becom
On 7/18/07, Amaury Forgeot d'Arc <[EMAIL PROTECTED]> wrote:
> Hello,
>
> 2007/7/17, Joe Smith wrote:
> > Building Py3k_struni under Cygwin I've noticed a few more tests failing than
> > the wiki shows.
> > These are using SVN revision 56413.
> >
> > Some spurious errors seem to occur if Python/ is
On 7/17/07, Joe Smith <[EMAIL PROTECTED]> wrote:
> Building Py3k_struni under Cygwin I've noticed a few more tests failing than
> the wiki shows.
> These are using SVN revision 56413.
>
> Some spurious errors seem to occur if Python/ is not remaned temporally. I
> have not included those. (This is
On 7/17/07, Kurt B. Kaiser <[EMAIL PROTECTED]> wrote:
> For what it's worth, I posted a patch to ast.c against the 2.6 trunk
> which massages the unicode exception into a SyntaxError showing the
> location.
>
> That approach lets unicodeobject.c handle the gory details while ast.c
> handles the Syn
At 09:47 AM 7/18/2007 -0700, Guido van Rossum wrote:
>Sorry, but I'm still totally uncomfortable with this. While I admit
>the feature exists, I really, really, really don't want it to be used
>on a regular basis. As long as Phillip calls a counterproposal
>"fingernails on a chalkboard", I call thi
On 7/17/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > When a source file contains a string literal with an out-of-range \U
> > escape (e.g. "\U12345678"), instead of a syntax error pointing to the
> > offending literal, I get this, without any indication of the file or
> > line:
> >
> > Unic
"Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> On 7/17/07, Joe Smith <[EMAIL PROTECTED]> wrote:
>> Building Py3k_struni under Cygwin I've noticed a few more tests failing
>> than
>> the wiki shows.
>> These are using SVN revision 56413.
>>
>> Some spurious error
On 7/18/07, Joe Smith <[EMAIL PROTECTED]> wrote:
>
> "Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> > On 7/17/07, Joe Smith <[EMAIL PROTECTED]> wrote:
> >> Building Py3k_struni under Cygwin I've noticed a few more tests failing
> >> than
> >> the wiki shows.
> >>
On 7/17/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Yes, see a thread between me, Georg and Brett around March 7-10:
>
> http://mail.python.org/pipermail/python-3000/2007-March/006061.html
>
Thanks for the pointer.
> I think the conclusion was to get rid of Py_FindMethod altogether. The
> r
"Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> On 7/18/07, Joe Smith <[EMAIL PROTECTED]> wrote:
>>
>> "Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
>> news:[EMAIL PROTECTED]
>> > On 7/17/07, Joe Smith <[EMAIL PROTECTED]> wrote:
>> >> Building Py3k_strun
On 7/18/07, Alexandre Vassalotti <[EMAIL PROTECTED]> wrote:
> On 7/17/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > Yes, see a thread between me, Georg and Brett around March 7-10:
> >
> > http://mail.python.org/pipermail/python-3000/2007-March/006061.html
> >
>
> Thanks for the pointer.
>
>
On 7/18/07, Joe Smith <[EMAIL PROTECTED]> wrote:
> >> I'm wondering if the recusion limit on my build is getting set too low
> >> somehow.
> >
> > Can you find out what it is? sys.getrecursionlimit().
>
> Hmm... It is a limit of 1000.
> That is probably large enough, no?
Yes, that's what it is fo
So, any decision on the proposed semantic change of truncate?
-- Alexandre
On 7/3/07, Alexandre Vassalotti <[EMAIL PROTECTED]> wrote:
> On 7/2/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > Honestly, I think truncate() should always set the current position to
> > the new size, even though t
Unless anyone cares, it should imply a seek to the indicated position
if an argument was present.
On 7/18/07, Alexandre Vassalotti <[EMAIL PROTECTED]> wrote:
> So, any decision on the proposed semantic change of truncate?
>
> -- Alexandre
>
> On 7/3/07, Alexandre Vassalotti <[EMAIL PROTECTED]> wro
"Guido van Rossum" <[EMAIL PROTECTED]> writes:
>> www.python.org/sf/1755885
>
> Thanks! Checked in, and merged into p3yk.
Thanks!
Unfortunately, I see there's an error from test_unicode.py, which I
neglected to re-run. My apologies!
I've checked in a fix on the trunk and the buildbots are rela
On 7/18/07, Kurt B. Kaiser <[EMAIL PROTECTED]> wrote:
> "Guido van Rossum" <[EMAIL PROTECTED]> writes:
>
> >> www.python.org/sf/1755885
> >
> > Thanks! Checked in, and merged into p3yk.
>
> Thanks!
>
> Unfortunately, I see there's an error from test_unicode.py, which I
> neglected to re-run. My ap
Guido van Rossum schrieb:
> On 7/17/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>> > When a source file contains a string literal with an out-of-range \U
>> > escape (e.g. "\U12345678"), instead of a syntax error pointing to the
>> > offending literal, I get this, without any indication of the
On 7/15/07, Georg Brandl <[EMAIL PROTECTED]> wrote:
> Most obvious would be a special comment, something like
>
> for x in curiousobject.iteritems(): # 2to3:keep
> foo(x)
>
> Does that make sense?
It would be a good idea to define a convention for these special
comments. For example, we coul
Alexandre Vassalotti schrieb:
> On 7/17/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>> Yes, see a thread between me, Georg and Brett around March 7-10:
>>
>> http://mail.python.org/pipermail/python-3000/2007-March/006061.html
>>
>
> Thanks for the pointer.
>
>> I think the conclusion was to g
Alexandre Vassalotti wrote:
> I expect other tools, like pdb.py and trace.py could follow this
> convention as well. For example:
I used the time machine to convince the author of trace.py use this
convention.
He didn't like your spelling, but eventually agreed to #pragma NO COVER.
--
Benji Yor
(FWIW, I've formally rejected the PEP now, referring to this message.)
--Guido
On 7/3/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 6/30/07, Matt Chisholm <[EMAIL PROTECTED]> wrote:
> > I've created and submitted a new PEP proposing support for labels in
> > Python's break and continue sta
Guido van Rossum wrote:
> Sorry, but I'm still totally uncomfortable with this. While I admit
> the feature exists, I really, really, really don't want it to be used
> on a regular basis.
As long as the objects defined by a regular def statement
aren't modifiable, it seems like it won't be possibl
On 7/16/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Guido van Rossum schrieb:
> > That sounds like a good idea to try. It may break some more tests but
> > those are all indications of places that incorrectly still require
> > str8.
> >
> >> I wonder whether the "s" specifier in CallFunction
> You broke backwards compatibility this way; I think that a pickle
> produced by Python 2.x should be readable by Python 3.0.
It is, is it not?
> (I haven't decided whether to keep str8 or something like it, or
> whether to try to get rid of it completely).
I assumed the latter - and if it inde
On 7/18/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > Sorry, but I'm still totally uncomfortable with this. While I admit
> > the feature exists, I really, really, really don't want it to be used
> > on a regular basis.
>
> As long as the objects defined by a regular def s
On 7/18/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > You broke backwards compatibility this way; I think that a pickle
> > produced by Python 2.x should be readable by Python 3.0.
>
> It is, is it not?
No; {'a': 1} pickled on 2.x results in an error complaining about an
unhashable object w
27 matches
Mail list logo
