On 8/14/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> I thought some more about the universal newlines situation, and I
> think I can handle all the use cases with a single 'newline'
> parameter. The use cases are:
>
> (A) input use cases:
>
> (1) newline=None: input with default universal newl
I just implemented PEP 3131 (non-ASCII identifiers).
There are several problems with displaying error messages,
in particular when the terminal cannot render the string;
if anybody wants to work on this, please go ahead.
Regards,
Martin
___
Python-3000
Talin wrote:
> A new version is up, incorporating material from the various discussions
> on this list:
>
> http://www.python.org/dev/peps/pep-3101/
I have a number of parts of this implemented. I'm refactoring the
original PEP 3101 sandbox code to get it working. Mostly it involves
un
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Aug 15, 2007, at 3:47 AM, Brett Cannon wrote:
> On 8/14/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>> I thought some more about the universal newlines situation, and I
>> think I can handle all the use cases with a single 'newline'
>> paramete
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Aug 15, 2007, at 4:37 AM, Martin v. Löwis wrote:
> I just implemented PEP 3131 (non-ASCII identifiers).
>
> There are several problems with displaying error messages,
> in particular when the terminal cannot render the string;
> if anybody wants to
Brett Cannon wrote:
> I like the options, but I would swap the meaning of None and the empty
> string. My reasoning for this is that for option 3 it says to me
> "here is a string representing EOL, and make it \n". So I would think
> of the empty string as, "I don't know what EOL is, but I want i
Brett Cannon schrieb:
> On 8/14/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>> I thought some more about the universal newlines situation, and I
>> think I can handle all the use cases with a single 'newline'
>> parameter. The use cases are:
>>
>> (A) input use cases:
>>
>> (1) newline=None: in
Brett Cannon schrieb:
> On 8/14/07, Georg Brandl <[EMAIL PROTECTED]> wrote:
>> Now that the converted documentation is fairly bug-free, I want to
>> make the switch.
>>
>> I will replace the old Doc/ trees in the trunk and py3k branches
>> tomorrow, moving over the reST ones found at
>> svn+ssh://s
Georg Brandl schrieb:
> Now that the converted documentation is fairly bug-free, I want to
> make the switch.
>
> I will replace the old Doc/ trees in the trunk and py3k branches
> tomorrow, moving over the reST ones found at
> svn+ssh://svn.python.org/doctools/Doc-{26,3k}.
>
> Neal will change h
I think the example:
"My name is {0.name}".format(file('out.txt'))
Would be easier to understand if you added:
Which would produce:
"My name is 'out.txt'"
On 8/14/07, Talin <[EMAIL PROTECTED]> wrote:
> A new version is up, incorporating material from the various discussions
> on
The section on the explicit conversion flag contains the following line:
These flags are typically placed before the format specifier:
Where else can they be placed?
Also there is no description of what action (if any) is taken if an
unknown explicit conversion flag is encoubtered.
On 8/1
On Aug 15, 2007, at 9:28 AM, Christian Heimes wrote:
> I like to propose some constants which should be used instead of the
> strings:
+1 for this. This should make code easier to read, too; not everyone
spends time with line-oriented I/O, and the strings are just magic
numbers in that case.
On 8/15/07, Georg Brandl <[EMAIL PROTECTED]> wrote:
> I'd use None and "\r"/... as proposed, but "U" instead of the empty string
> for universal newline mode.
I know that "U" already has this meaning as a differently named
parameter, but if I saw something like::
open(file_name, newline='U')
On 8/14/07, Ron Adam <[EMAIL PROTECTED]> wrote:
> Jim Jewett wrote:
> > On 8/13/07, Ron Adam <[EMAIL PROTECTED]> wrote:
> >>{name[:][type][alignment_term][,content_modifying_term]}
> > ... You used the (alignment term)
> > width as the number of digits before the decimal,
> > instead of
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Aug 15, 2007, at 9:28 AM, Christian Heimes wrote:
> I like to propose some constants which should be used instead of the
> strings:
>
> MAC = '\r'
> UNIX = '\n'
> WINDOWS = '\r\n'
> UNIVERSAL = ''
> NOTRANSLATE = None
>
> I think that open(filename
James Thiele wrote:
> I think the example:
>
> "My name is {0.name}".format(file('out.txt'))
>
> Would be easier to understand if you added:
>
> Which would produce:
>
> "My name is 'out.txt'"
I agree.
Also, the example a couple of paragraphs down:
"My name is {0[name]}".format(di
On 8/15/07, Georg Brandl <[EMAIL PROTECTED]> wrote:
> Brett Cannon schrieb:
> > On 8/14/07, Georg Brandl <[EMAIL PROTECTED]> wrote:
> >> Now that the converted documentation is fairly bug-free, I want to
> >> make the switch.
> >>
> >> I will replace the old Doc/ trees in the trunk and py3k branche
On 8/15/07, Ron Adam <[EMAIL PROTECTED]> wrote:
>
>
> Andrew James Wade wrote:
> > On Tue, 14 Aug 2007 21:12:32 -0500
> > Ron Adam <[EMAIL PROTECTED]> wrote:
>
> >> What I was thinking of was just a simple left to right evaluation order.
> >>
> >> "{0:spec1, spec2, ... }".format(x)
> >>
> >> I
On 8/14/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> I thought some more about the universal newlines situation, and I
> think I can handle all the use cases with a single 'newline'
> parameter. The use cases are:
>
> (A) input use cases:
>
> (1) newline=None: input with default universal newl
James Thiele wrote:
> The section on the explicit conversion flag contains the following line:
>
> These flags are typically placed before the format specifier:
>
> Where else can they be placed?
I'd like this to say they can only be placed where the PEP describes
them, or maybe to be onl
On 8/15/07, Christian Heimes <[EMAIL PROTECTED]> wrote:
> Brett Cannon wrote:
> > I like the options, but I would swap the meaning of None and the empty
> > string. My reasoning for this is that for option 3 it says to me
> > "here is a string representing EOL, and make it \n". So I would think
>
Greg Ewing wrote:
> I'm wondering whether we want a "byte character literal"
> to go along with "byte string literals":
>
>h[0] == c"P"
>
> After all, if it makes sense to write an array of bytes
> as though they were ASCII characters, it must make sense
> to write a single byte that way as
> Okay, I made the switch. I tagged the state of both Python branches
> before the switch as tags/py{26,3k}-before-rstdocs/.
Update instructions:
1. svn diff Doc; any pending changes will need to be redone
2. svn up; this will remove the tex sources, and then likely
fail if there were still o
On Aug 14, 2007, at 9:56 PM, Guido van Rossum wrote:
> I thought some more about the universal newlines situation, and I
> think I can handle all the use cases with a single 'newline'
> parameter. The use cases are:
>
> (A) input use cases:
>
> (1) newline=None: input with default universal newli
On Wednesday 15 August 2007 03:44:54 Bill Janssen wrote:
> > (...) I think that base64MIME.encode() may have to accept strings.
>
> Personally, I think it would avoid more errors if it didn't.
Yeah, how can you guess which charset the user want to use? For most user,
there is only one charset: la
On 8/14/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> I thought some more about the universal newlines situation, and I
> think I can handle all the use cases with a single 'newline'
> parameter. The use cases are:
>
> (A) input use cases:
>
> (1) newline=None: input with default universal newl
On 8/15/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 8/15/07, Adam Olsen <[EMAIL PROTECTED]> wrote:
> > On 8/14/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > > (2) newline='': input with untranslated universal newlines mode; lines
> > > may end in \r, \n, or \r\n, and these are return
Jim Jewett wrote:
> On 8/14/07, Ron Adam <[EMAIL PROTECTED]> wrote:
>> Jim Jewett wrote:
>>> On 8/13/07, Ron Adam <[EMAIL PROTECTED]> wrote:
>
{name[:][type][alignment_term][,content_modifying_term]}
>
>>> ... You used the (alignment term)
>>> width as the number of digits before t
On 8/15/07, Adam Olsen <[EMAIL PROTECTED]> wrote:
> On 8/14/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > (2) newline='': input with untranslated universal newlines mode; lines
> > may end in \r, \n, or \r\n, and these are returned untranslated.
>
> Caveat: this mode cannot be supported by so
I mentioned this in another message, but I thought I'd mention it here.
I see this change in the behavior of sys.stdin.name, between 2.3.3 and
3.0x (checked out a few minutes ago).
$ python
Python 2.3.3 (#1, May 7 2004, 10:31:40)
[GCC 3.3.3 20040412 (Red Hat Linux 3.3.3-7)] on linux2
Type "help
On 8/15/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > Okay, I made the switch. I tagged the state of both Python branches
> > before the switch as tags/py{26,3k}-before-rstdocs/.
>
> Update instructions:
>
> 1. svn diff Doc; any pending changes will need to be redone
> 2. svn up; this will
>> 1. svn diff Doc; any pending changes will need to be redone
>> 2. svn up; this will remove the tex sources, and then likely
>>fail if there were still other files present in Doc, e.g.
>>from building the documentation
>> 3. review any files left in Doc
>> 4. rm -rf Doc
>> 5. svn up
>>
>>
Adam Olsen wrote:
> On 8/15/07, Ron Adam <[EMAIL PROTECTED]> wrote:
>>
>> Andrew James Wade wrote:
>>> On Tue, 14 Aug 2007 21:12:32 -0500
>>> Ron Adam <[EMAIL PROTECTED]> wrote:
What I was thinking of was just a simple left to right evaluation order.
"{0:spec1, spec2, ... }".f
On 8/14/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> ... {foo!r} rather than {foo:!r}
> But either way, I suspect I'll find it difficult
> to avoid writing it as {foo:r} in the heat of the
> moment.
Me too.
And I don't like using up the "!" character. I know that it is still
available outside o
(Warning: quotation intentionally out of context!)
On 8/15/07, somebody wrote:
> For most users, there is only one charset: latin-1.
Whoa! Careful with those assumptions. This is very culture and
platforms dependent. For Americans it's ASCII (only half joking :-).
For most of the world it's likel
On 8/15/07, Ron Adam <[EMAIL PROTECTED]> wrote:
> After each term is returned from the __format__ call, the results
> __format__ method is called with the next specifier. GetTime.__format__
> returns a string. str.__format__, aligns it. A nice left to right
> sequence of events.
Is this a patt
It sort of is -- the new I/O library uses the file descriptor if no
filename is given. There were no unit tests that verified the old
behavior, and I think it was of pretty marginal usefulness. Code
inspecting f.name can tell the difference by looking at its type -- if
it is an int, it's a file des
Eric Smith wrote:
> Is this deliberate? I can file a bug report if need be, just let me know.
I'm sure it is a bug. The site.installnewio() function doesn't set the
names. The attached patch fixes the issue and adds an unit test, too.
Christian
Index: Lib/site.py
Ron Adam wrote:
>
> Greg Ewing wrote:
> > The format strings are starting to look like line
> > noise.
>
> Do you have a specific example or is it just an overall feeling?
It's an overall feeling from looking at your examples.
I can't take them in at a glance -- I have to minutely
examine them c
Jim Jewett wrote:
> On 8/15/07, Ron Adam <[EMAIL PROTECTED]> wrote:
>
>> After each term is returned from the __format__ call, the results
>> __format__ method is called with the next specifier. GetTime.__format__
>> returns a string. str.__format__, aligns it. A nice left to right
>> sequenc
Ron Adam wrote:
> What I was thinking of was just a simple left to right evaluation order.
>
> "{0:spec1, spec2, ... }".format(x)
That would work too, as long as you were willing to
forbid "," as a possible character in a type-specific
format string.
--
Greg Ewing, Computer Science Dept, +
Andrew James Wade wrote:
> {1:!renewal date: %Y-%m-%d} # no special meaning for ! here.
Yuck. Although it might happen to work due to reuse of
strftime, I'd consider that bad style -- constant parts
of the output string should be outside of the format
specs, i.e.:
"renewal date: {1:%Y-%m-%d}".
Barry Warsaw wrote:
> Add a flag
> called preserve_eols that defaults to False, is ignored unless
> universal newline mode is turned on,
Is there any reason it shouldn't work in non-universal-
newlines mode too?
--
Greg Ewing, Computer Science Dept, +--+
U
Christian Heimes wrote:
> Besides I always forget if Windows is '\r\n' or '\n\r'.
Oh, that's easy. The teletype needs to get the CR before
the LF so that it can start moving the carriage back
to the left while it's scrolling the paper up.
What? You don't have a teletype? Well, er, in that
case...
Georg Brandl wrote:
> "U" instead of the empty string for universal newline mode.
It would be good to leave open the possibility of
allowing arbitrary line separation strings at some
time in the future. In that case, newline == "U" would
mean lines separated by "U".
Predefined constants seem like
Joel Bender wrote:
> Would you propose these to be mutable as well?
No, they'd be integers.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | Carpe post meridiem! |
Christchurch, New Zealand | (I'm not a
Adam Olsen wrote:
> On 8/14/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> > (2) newline='': input with untranslated universal newlines mode; lines
> > may end in \r, \n, or \r\n, and these are returned untranslated.
>
> Caveat: this mode cannot be supported by sockets. When reading a lone
On 8/15/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Adam Olsen wrote:
> > On 8/14/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> >
> > > (2) newline='': input with untranslated universal newlines mode; lines
> > > may end in \r, \n, or \r\n, and these are returned untranslated.
> >
> > Caveat:
Eric Smith wrote:
> James Thiele wrote:
>> The section on the explicit conversion flag contains the following line:
>>
>> These flags are typically placed before the format specifier:
>>
>> Where else can they be placed?
>
> I'd like this to say they can only be placed where the PEP describe
Talin wrote:
> Eric Smith wrote:
>> James Thiele wrote:
>>> The section on the explicit conversion flag contains the following line:
>>>
>>> These flags are typically placed before the format specifier:
>>>
>>> Where else can they be placed?
>>
>> I'd like this to say they can only be placed
Eric Smith wrote:
> James Thiele wrote:
>> I think the example:
>>
>> "My name is {0.name}".format(file('out.txt'))
>>
>> Would be easier to understand if you added:
>>
>> Which would produce:
>>
>> "My name is 'out.txt'"
>
> I agree.
>
> Also, the example a couple of paragraphs down:
Eric Smith wrote:
> Talin wrote:
>> Eric Smith wrote:
>>> James Thiele wrote:
The section on the explicit conversion flag contains the following
line:
These flags are typically placed before the format specifier:
Where else can they be placed?
>>>
>>> I'd like t
Talin wrote:
> Eric Smith wrote:
>> Talin wrote:
>>> Guido expressed a definite preference for having them be first.
>>
>> I was afraid of that. Then can we say they'll always go first? Or is
>> the intent really to say they can go anywhere (PEP says "typically
>> placed")?
>
> I can revise it
Talin wrote:
> A new version is up, incorporating material from the various discussions
> on this list:
>
> http://www.python.org/dev/peps/pep-3101/
I've been following this thread for a few weeks, and I believe the
following issues haven't yet been addressed:
The PEP abstract says this
Alex Holkner wrote:
> Talin wrote:
>> A new version is up, incorporating material from the various discussions
>> on this list:
>>
>> http://www.python.org/dev/peps/pep-3101/
>
> I've been following this thread for a few weeks, and I believe the
> following issues haven't yet been addressed
On 8/15/07, Georg Brandl <[EMAIL PROTECTED]> wrote:
> Georg Brandl schrieb:
> >
> > Neal will change his build scripts, so that the 2.6 and 3.0 devel
> > documentation pages at docs.python.org will be built from these new
> > trees soon.
>
> Okay, I made the switch. I tagged the state of both Pyth
On Sat, 11 Aug 2007 01:57:16 -0700
Talin <[EMAIL PROTECTED]> wrote:
> Taking some ideas from the various threads, here's what I'd like to propose:
>
> (Assume that brackets [] means 'optional field')
>
>[:[type][align][sign][[0]minwidth][.precision]][/fill][!r]
>
> Examples:
>
> :f
(First, let me apologize for diving into a bike shed discussion.)
There are two proposed ways to handle custom __format__ methods:
> class MyInt:
> def __format__(self, spec):
> if int.is_int_specifier(spec):
> return int(self).__format__(spec)
> return "MyInt
58 matches
Mail list logo
