Greg Ewing writes:
> But an FF or VT is not *just* a line break, it can
> have other semantics attatched to it as well. So
> treating it just the same as a \n by default would be
> wrong, I think.
*Python* does the right thing: it leaves the line break character(s)
in place. It's not Python'
I've updated the patch; the latest version now contains the grammar
and compiler changes needed to make super a keyword and to
automatically add a required parameter 'super' when super is used.
This requires the latest p3yk branch (r55692 or higher).
Comments anyone? What do people think of the ch
Talin wrote:
> In the case where you want direct access to global variables, you can
> make it even more convenient by caching the Formatter:
>
> f = Formatter(globals()).format
> a = 1
> print(f("The value of a is {a}"))
>
> (You can't do this with locals() because you can't keep
Guido van Rossum wrote:
> I've updated the patch; the latest version now contains the grammar
> and compiler changes needed to make super a keyword and to
> automatically add a required parameter 'super' when super is used.
> This requires the latest p3yk branch (r55692 or higher).
>
> Comments any
On 5/31/07, Tim Delaney <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > I've updated the patch; the latest version now contains the grammar
> > and compiler changes needed to make super a keyword and to
> > automatically add a required parameter 'super' when super is used.
> > This require
Guido van Rossum wrote:
>> The patch notes say that you're actually inserting a keyword-only
>> argument - is this purely meant to be a stopgap measure so that
>> you've got a local (which could be put into a cell)?
>
> I'm not using a cell because I'm storing the result of calling
> super(Class,
> But an FF or VT is not *just* a line break, it can
> have other semantics attatched to it as well. So
> treating it just the same as a \n by default would be
> wrong, I think.
I agree. I have text files which contain lines of FF NL, which
are supposed to be single lines with a FF as their conte
At 07:48 PM 5/31/2007 +0800, Guido van Rossum wrote:
>I've updated the patch; the latest version now contains the grammar
>and compiler changes needed to make super a keyword and to
>automatically add a required parameter 'super' when super is used.
>This requires the latest p3yk branch (r55692 or
Guido just fixed a case in the py3k branch where you could assign to
"None" in a function call.
__debug__ has similar problems: it can't be assigned to normally, but via
keyword arguments it is possible.
This should be fixed; or should __debug__ be thrown out anyway?
Georg
--
Thus spake the Lo
Bill Janssen writes:
> > But an FF or VT is not *just* a line break, it can
> > have other semantics attatched to it as well. So
> > treating it just the same as a \n by default would be
> > wrong, I think.
>
> I agree. I have text files which contain lines of FF NL, which
> are supposed
Hello,
I finished yesterday the implementations of BytesIO and StringIO
objects in C. They are both fully working. (The code is available in
my cpy_merge branch in the svn tree.) There is only one thing that is
bothering me with StringIO, it doesn't accept buffer objects. Should I
care about this?
On 5/31/07, Georg Brandl <[EMAIL PROTECTED]> wrote:
Guido just fixed a case in the py3k branch where you could assign to
"None" in a function call.
__debug__ has similar problems: it can't be assigned to normally, but via
keyword arguments it is possible.
This should be fixed; or should __debu
Brett Cannon schrieb:
> On 5/31/07, Georg Brandl <[EMAIL PROTECTED]> wrote:
>>
>> Guido just fixed a case in the py3k branch where you could assign to
>> "None" in a function call.
>>
>> __debug__ has similar problems: it can't be assigned to normally, but via
>> keyword arguments it is possible.
>
On 5/31/07, Alexandre Vassalotti <[EMAIL PROTECTED]> wrote:
> Hello,
>
> I finished yesterday the implementations of BytesIO and StringIO
> objects in C. They are both fully working. (The code is available in
> my cpy_merge branch in the svn tree.) There is only one thing that is
> bothering me wit
I vaguely remember a discussion about the str/unicode unification and
whether there was going to be standardization on the internal representation
of Unicode or not. I don't remember the outcome, but I am curious as to
whether it will lead to the removal of --enable-unicode or not.
Reason I ask
Ouch. You're right. Class methods are broken by this patch. I don't
have time right now to look into a fix (thanks for the various
suggstions) but if somebody doesn't get to it first I'll look into
this in-depth on Monday.
class C:
@classmethod
def cm(cls): return cls.__name__
class D(C):
Stephen J. Turnbull wrote:
> *Python* does the right thing: it leaves the line break character(s)
> in place. It's not Python's problem if programmers go around
> stripping characters just because they happen to be at the end of the
> line.
But currently you *know* that, e.g. string.strip() will
Making __debug__ another keyword atom sounds great to me.
On 6/1/07, Thomas Heller <[EMAIL PROTECTED]> wrote:
> Brett Cannon schrieb:
> > On 5/31/07, Georg Brandl <[EMAIL PROTECTED]> wrote:
> >>
> >> Guido just fixed a case in the py3k branch where you could assign to
> >> "None" in a function cal
I don't know exactly what that option does; it won't be possible to
disable unicode in 3.0, but I fully plan to continue supporting both
2-byte and 4-byte storage. 4-byte storage is broken on OSX it ought to
be fixed (unless it's a platform policy not to support it, as appears
to be the case on Win
On 5/31/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
I don't know exactly what that option does;
It specifies how Unicode is stored internally in the interpreter (I
believe).
it won't be possible to
disable unicode in 3.0, but I fully plan to continue supporting both
2-byte and 4-byte st
Greg Ewing writes:
> Stephen J. Turnbull wrote:
>
> > *Python* does the right thing: it leaves the line break character(s)
> > in place. It's not Python's problem if programmers go around
> > stripping characters just because they happen to be at the end of the
> > line.
>
> But current
Hi,
I've been reading the list for a couple of weeks, but this is my first post.
Guido van Rossum wrote:
> I don't know exactly what that option does; it won't be possible to
> disable unicode in 3.0, but I fully plan to continue supporting both
> 2-byte and 4-byte storage.
Does this still inclu
> Guido van Rossum wrote:
>> I don't know exactly what that option does; it won't be possible to
>> disable unicode in 3.0, but I fully plan to continue supporting both
>> 2-byte and 4-byte storage.
>
> Does this still include the possibility of switching between 1-, 2- and
> 4-byte storage intern
23 matches
Mail list logo
