[Andrew Koenig]
> It has occurred to me that as Python stands today, an indent always begins
> with a colon. So in principle, we could define anything that looks like an
> indent but doesn't begin with a colon as a continuation. So the idea would
> be that you can continue a statement onto as man
Raymond Hettinger wrote:
> [Andrew Koenig]
>> It has occurred to me that as Python stands today, an indent always begins
>> with a colon. So in principle, we could define anything that looks like an
>> indent but doesn't begin with a colon as a continuation. So the idea would
>> be that you can c
Mark Hammond wrote:
> Please add my -1 to the chorus here, for the same reasons already expressed.
Another -1 here - while I agree there are benefits to removing backslash
continuations and string literal concatenation, I don't think they're
significant enough to justify the hassle of making it
> Too dangerous. The most common Python syntax error (by far, even for
> experienced users) is omission of a colon. If the missing colon starts
> to have its own special meaning, that would not be a good thing.
It's not special -- omitting it would have exactly the same effect as
omitting a colo
On 5/7/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> I don't know how this will work out yet. I'm not convinced that having
> both mutable and immutable bytes is the right thing to do; but I'm
> also not convinced of the opposite. I am slowly working on the
> string/unicode unification, and so
On 5/8/07, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Mark Hammond wrote:
> > Please add my -1 to the chorus here, for the same reasons already expressed.
>
> Another -1 here - while I agree there are benefits to removing backslash
> continuations and string literal concatenation, I don't think they
In fairness to would-be new PEP proposals for Python 3000, I am asking
everyone who still has a draft PEP that's not checked in to subversion
to please check in *a* version of it as soon as possible. This version
doesn't have to be final; expect debate which may require a rewrite
all or part of you
On 5/8/07, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> If you're in the mood to propose something radical, how about dropping
> the colon altogether, leaving indention as the sure reliable cue and
> cleaning-up the appearance of code in a new world where colons
> are also being used for annotati
On 5/8/07, Jason Orendorff <[EMAIL PROTECTED]> wrote:
> On 5/7/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > I don't know how this will work out yet. I'm not convinced that having
> > both mutable and immutable bytes is the right thing to do; but I'm
> > also not convinced of the opposite. I
On 5/8/07, Jason Orendorff <[EMAIL PROTECTED]> wrote:
> On 5/7/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > daunting to get rid of 8-bit strings even at the Python level let
> > alone at the C level.
> Guido, if 3.x had an immutable bytes type, could 2to3 provide a
> better guarantee? Nam
On 5/7/07, "Guido van Rossum" wrote:
>
>
> Around '99 Greg Stein and Mark Hammond tried to get rid of the GIL.
> They removed most of the global mutable data structures, added
> explicit locks to the remaining ones and to individual mutable
> objects, and actually got the whole thing working. Unfor
On 08/05/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> I will be unhappy if 2to3 produces code that I can't run in (at least)
> 2.6, because then I would need to convert more than once.
IIUC, the idea is that you should be able to write valid Python 2.6
code which 2to3 can convert automatically. The
On 5/8/07, Paul Moore <[EMAIL PROTECTED]> wrote:
> On 08/05/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> > I will be unhappy if 2to3 produces code that I can't run in
> > (at least) 2.6, because then I would need to convert more
> > than once.
> IIUC, the idea is that you should be able to write va
On 5/8/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> I will be unhappy if 2to3 produces code that I can't run in (at least)
> 2.6, because then I would need to convert more than once.
This is the first time I hear of this requirement. It has not so far
been a design goal for the conversions in 2to3.
On May 8, 2007, at 9:16 AM, Jason Orendorff wrote:
> Guido, if 3.x had an immutable bytes type, could 2to3 provide a
> better guarantee? Namely, "Set your default encoding to None
> in your 2.x code today, and 2to3 will not introduce bugs around
> str/unicode."
You cannot set the default encodi
On 5/8/07, Luis P Caamano <[EMAIL PROTECTED]> wrote:
> On 5/7/07, "Guido van Rossum" wrote:
> > Around '99 Greg Stein and Mark Hammond tried to get rid of the GIL.
> > They removed most of the global mutable data structures, added
> > explicit locks to the remaining ones and to individual mutable
>
Guido van Rossum schrieb:
> On 5/8/07, Luis P Caamano <[EMAIL PROTECTED]> wrote:
>> On 5/7/07, "Guido van Rossum" wrote:
>> > Around '99 Greg Stein and Mark Hammond tried to get rid of the GIL.
>> > They removed most of the global mutable data structures, added
>> > explicit locks to the remaining
On 5/8/07, Thomas Heller <[EMAIL PROTECTED]> wrote:
> Wouldn't multiple interpreters (assuming the problems with them would be
> fixed)
> in the same process give the same benefit? A separate GIL for each one?
No; numerous read-only and immutable objects (e.g. the small integers,
1-character str
One more test is failing:
test test_fileio failed -- Traceback (most recent call last):
File "/tmp/python-test-3.0/local/lib/python3.0/test/test_fileio.py",
line 128, in testAbles
f = _fileio._FileIO("/dev/tty", "a")
IOError: [Errno 6] No such device or address: '/dev/tty'
This seems to only
Should be fixed now.
Committed revision 55186.
On 5/8/07, Neal Norwitz <[EMAIL PROTECTED]> wrote:
> One more test is failing:
>
> test test_fileio failed -- Traceback (most recent call last):
> File "/tmp/python-test-3.0/local/lib/python3.0/test/test_fileio.py",
> line 128, in testAbles
>f =
On 5/8/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
On 5/8/07, Thomas Heller <[EMAIL PROTECTED]> wrote:
> Wouldn't multiple interpreters (assuming the problems with them would be
fixed)
> in the same process give the same benefit? A separate GIL for each one?
No; numerous read-only and immu
On 5/8/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 5/8/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> > I will be unhappy if 2to3 produces code that I can't run in (at least)
> > 2.6, because then I would need to convert more than once.
> This is the first time I hear of this requirement. It
On 5/8/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> On 5/8/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > On 5/8/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> > > I will be unhappy if 2to3 produces code that I can't run in (at least)
> > > 2.6, because then I would need to convert more than once.
On Mon, May 07, 2007 at 11:12:40AM -0700, Guido van Rossum wrote:
> On 5/7/07, Collin Winter <[EMAIL PROTECTED]> wrote:
> > Can I go ahead and mark PEP 3129 as "accepted"?
>
> Almost. I'm ok with it, but I think that to follow the procedure you
> ought to post the full text at least once on python
Cool! Looking forward to it. Collin or someone else can help you get
it checked in if you don't have dev privs yet.
Given the lack of discussion following the posting of the PEP, let's accept it.
On 5/8/07, Jack Diederich <[EMAIL PROTECTED]> wrote:
> On Mon, May 07, 2007 at 11:12:40AM -0700, Guid
> Wouldn't multiple interpreters (assuming the problems with them would be
> fixed)
> in the same process give the same benefit? A separate GIL for each one?
No. There is a global "current thread" variable that is protected by the
GIL (namely, _PyThreadState_Current). Without that, you would not
On 5/8/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Given the lack of discussion following the posting of the PEP, let's accept
> it.
Marked as accepted in r55190.
Collin Winter
> On 5/8/07, Jack Diederich <[EMAIL PROTECTED]> wrote:
> > On Mon, May 07, 2007 at 11:12:40AM -0700, Guido van R
Hello. I just joined the list as the whole Abstract Base Class,
Interfaces, and Roles/Traits system is of significant interest to me.
I've tried to catch up on the discussion by reading through the
archives, but I'm sure I missed a few posts and I apologize if I'm
wasting time covering ground that'
Luis P Caamano wrote:
> You gotta finish that sentence, it was a slow down on single CPU with
> a speed increase with two or more CPUs, leveling out at 4 CPUs or so.
But it's still going to slow down all code that
doesn't use threads. I don't want to be *forced*
to use threads to get decent speed
On Wed, 09 May 2007 12:46:14 +1200, Greg Ewing <[EMAIL PROTECTED]> wrote:
>Luis P Caamano wrote:
>
>> You gotta finish that sentence, it was a slow down on single CPU with
>> a speed increase with two or more CPUs, leveling out at 4 CPUs or so.
>
>But it's still going to slow down all code that
>do
At 03:52 PM 5/8/2007 -0600, Jeff Shell wrote:
>I have a lengthy post that dissects a major issue that I have with
>ABCs and the Interface definition that I saw in PEP 3124:: it all
>seems rigidly class and class-instance based.
Hi Jeff; I read your post a few days ago, but your blog doesn't
suppo
On 4/30/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
This is just the first draft (also checked into SVN), and doesn't include
the details of how the extension API works (so that third-party interfaces
and generic functions can interoperate using the same decorators,
annotations, etc.).
Commen
As of r55196 (and possibly earlier), the p3yk branch does not make
when configured with --with-pydebug. setup.py triggers this assertion
failure:
python: Objects/object.c:64: _Py_AddToAllObjects: Assertion
`(op->_ob_prev == ((void *)0)) == (op->_ob_next == ((void *)0))'
failed.
Any ideas?
___
Those following the octal literal discussion might enjoy reading one of today's
SF bug reports:
www.python.org/sf/1715302
Raymond
___
Python-3000 mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
On 5/8/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 03:52 PM 5/8/2007 -0600, Jeff Shell wrote:
> >I have a lengthy post that dissects a major issue that I have with
> >ABCs and the Interface definition that I saw in PEP 3124:: it all
> >seems rigidly class and class-instance based.
>
> Hi Jef
I had this problem. make clean solved it. -- n
On 5/8/07, Collin Winter <[EMAIL PROTECTED]> wrote:
> As of r55196 (and possibly earlier), the p3yk branch does not make
> when configured with --with-pydebug. setup.py triggers this assertion
> failure:
>
> python: Objects/object.c:64: _Py_AddToAllO
Works on a different laptop with a fresh checkout. False alarm, sorry.
On 5/8/07, Neal Norwitz <[EMAIL PROTECTED]> wrote:
> I had this problem. make clean solved it. -- n
>
> On 5/8/07, Collin Winter <[EMAIL PROTECTED]> wrote:
> > As of r55196 (and possibly earlier), the p3yk branch does not make
37 matches
Mail list logo
