Ron Adam wrote:
>
> Greg Ewing wrote:
>> Ron Adam wrote:
>>
>>> The digits value are number of digits before the decimal. This doesn't
>>> include the other symbols used in the field so it isn't the same as a field
>>> width.
>> How does this work with formats where the number of
>> digits befo
On 14/08/07, Walter Dörwald <[EMAIL PROTECTED]> wrote:
> Then why not have something more readable like
>
>al;s+;w15;d2
A brief sanity check freom someone who is not reading this thread, but
happened to see this post (and it's *not* a dig at Walter, just a
general comment):
If that's *more* r
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Aug 12, 2007, at 8:26 PM, Victor Stinner wrote:
> On Sunday 12 August 2007 16:50:05 Barry Warsaw wrote:
>> In r56957 I committed changes to sndhdr.py and imghdr.py so that they
>> compare what they read out of the files against proper byte
>> liter
Paul> If that's *more* readable, I'd hate to see what it's more readable
Paul> *than*.
Paul> I'd suggest that someone take a step back and think about how
Paul> people will use these things in practice. I'd probably refuse to
Paul> accept something like that in a code review w
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Aug 12, 2007, at 1:41 PM, Georg Brandl wrote:
> Bill Janssen schrieb:
>>> I don't like the behaviour of Python 3000 when we compare a bytes
>>> strings
>>> with length=1:
>> b'xyz'[0] == b'x'
>>>False
>>>
>>> The code can be see as:
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Aug 13, 2007, at 4:15 PM, Guido van Rossum wrote:
> I've seen similar behavior in MS VC++ (long ago, dunno what it does
> these days). It would read files with \r\n and \n line endings, and
> whenever you edited a line, that line also got a \r\n en
Walter Dörwald wrote:
>> Lets take apart the alternative syntax.
>>
>> f<+15.2
>>
>>f fixed point # of decimals is specified
>>
>>< align left (field attribute)
>>
>>+ sign(number attribute)
>>
>>15 width (field attribute
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Aug 13, 2007, at 10:22 PM, Victor Stinner wrote:
> After many tests, I'm unable to convert email module to Python
> 3000. I'm also
> unable to take decision of the best type for some contents.
I made a lot of progress on the email package while
On Tue, Aug 14, 2007 at 09:58:32AM -0400, Barry Warsaw wrote:
> This was all fine except that some of the tests started
> failing because of the EOL translation that happens unconditionally
> now. The file contained \r\n and the test was ensuring these EOLs
> were preserved in the parsed te
I'm trying to finalize PEP 3131, and want to collect proposals on
modifications of the identifier syntax. I will ignore any proposals
that suggest that different versions of the syntax should be used
depending on various conditions; I'm only asking for modifications
to the current proposed syntax.
On 8/13/07, Andrew James Wade <[EMAIL PROTECTED]> wrote:
> On Mon, 13 Aug 2007 20:53:26 -0700
> "Guido van Rossum" <[EMAIL PROTECTED]> wrote:
>
> ...
>
> > One of my favorite examples of non-numeric types are the date, time
> > and datetime types from the datetime module; here I propose that their
On 8/14/07, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> It would have been perfect, I think, if I could have opened the file
> in text mode so that read() gave me strings, with universal newlines
> and preservation of line endings (i.e. no translation to \n).
You can do that already, by passing newl
Benji York wrote:
>> But wouldn't the only reason you want to step into,
>> e.g. pickle be if there were a bug in pickle itself?
>
> I believe he's talking about a situation where pickle calls back into
> Python.
Yes, Benji is right. In the past I run into trouble with pickles two or
times. I wa
On 8/14/07, Christian Heimes <[EMAIL PROTECTED]> wrote:
> Benji York wrote:
> >> But wouldn't the only reason you want to step into,
> >> e.g. pickle be if there were a bug in pickle itself?
> >
> > I believe he's talking about a situation where pickle calls back into
> > Python.
>
> Yes, Benji is
On 8/13/07, Ron Adam <[EMAIL PROTECTED]> wrote:
> I reconsidered the split term forms a bit more and I think I've come up
> with a better way to think about them. Sometimes a slight conceptual
> shift can make a difference.
> The basic form is:
>{name[:][type][alignment_term][,content_mod
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 his build scripts, so that the 2.6 and
Georg Brandl wrote:
> Infos for people who will write docs in the new trees can be found in the
> new "Documenting Python" document, at the moment still available from
> http://pydoc.gbrandl.de:3000/documenting/, especially the "Differences"
> section at http://pydoc.gbrandl.de:3000/documenting/fro
Christian Heimes schrieb:
> Georg Brandl wrote:
>> Infos for people who will write docs in the new trees can be found in the
>> new "Documenting Python" document, at the moment still available from
>> http://pydoc.gbrandl.de:3000/documenting/, especially the "Differences"
>> section at http://pydoc
Jim Jewett wrote:
> On 8/13/07, Ron Adam <[EMAIL PROTECTED]> wrote:
>> I reconsidered the split term forms a bit more and I think I've come up
>> with a better way to think about them. Sometimes a slight conceptual
>> shift can make a difference.
>
>> The basic form is:
>
>>{name[:][typ
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://svn.python.org/doctools/Doc-{26
Ron Adam wrote:
>
> Greg Ewing wrote:
>
> > How does this work with formats where the number of
> > digits before the decimal can vary, but before+after
> > is constant?
>
> I think this is what you're looking for.
>
>f>15,.3 #15 field width, 3 decimal places, right aligned.
No, I'm talk
Guido van Rossum wrote:
> Over lunch we discussed putting !coercion first. IMO {foo!r:20} reads
> more naturally from left to right
It also has the advantage that the common case of
'r' with no other specifications is one character
shorter and looks tidier, i.e. {foo!r} rather than
{foo:!r}.
But
On 8/14/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > Over lunch we discussed putting !coercion first. IMO {foo!r:20} reads
> > more naturally from left to right
>
> It also has the advantage that the common case of
> 'r' with no other specifications is one character
> sho
Guido van Rossum wrote:
> On 8/13/07, Andrew James Wade <[EMAIL PROTECTED]> wrote:
>
>>On Mon, 13 Aug 2007 20:53:26 -0700
>>"Guido van Rossum" <[EMAIL PROTECTED]> wrote:
>>>I propose that their
>>>__format__ be defined like this:
>>>
>>> def __format__(self, spec):
>>> return self.strftime(
Guido van Rossum wrote:
> Now, this doesn't support bare \r as line terminator, but I doubt you
> care much about that (unless you want to port the email package to Mac
> OS 9 :-).
Haven't we decided that '\r' still occurs in some
cases even on MacOSX?
--
Greg
___
On 8/14/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
>
> > Now, this doesn't support bare \r as line terminator, but I doubt you
> > care much about that (unless you want to port the email package to Mac
> > OS 9 :-).
>
> Haven't we decided that '\r' still occurs in some
> ca
> > Let's take an example: multipart (MIME) email with latin-1 and
> > base64 (ascii)
> > sections. Mix latin-1 and ascii => mix bytes. So the best type
> > should be
> > bytes.
> >
> > => bytes
>
> Except that by the time they're parsed into an email message, they
> must be ascii, either en
Greg Ewing wrote:
> Ron Adam wrote:
>> Greg Ewing wrote:
> >
>>> How does this work with formats where the number of
>>> digits before the decimal can vary, but before+after
>>> is constant?
>> I think this is what you're looking for.
>>
>>f>15,.3 #15 field width, 3 decimal places, right a
Greg Ewing wrote:
> Guido van Rossum wrote:
>> On 8/13/07, Andrew James Wade <[EMAIL PROTECTED]> wrote:
>>
>>> On Mon, 13 Aug 2007 20:53:26 -0700
>>> "Guido van Rossum" <[EMAIL PROTECTED]> wrote:
>
I propose that their
__format__ be defined like this:
def __format__(self, sp
On Tue, 14 Aug 2007 09:41:48 -0700
"Guido van Rossum" <[EMAIL PROTECTED]> wrote:
> On 8/13/07, Andrew James Wade <[EMAIL PROTECTED]> wrote:
> > On Mon, 13 Aug 2007 20:53:26 -0700
> > "Guido van Rossum" <[EMAIL PROTECTED]> wrote:
> >
> > ...
> >
> > > One of my favorite examples of non-numeric type
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Aug 14, 2007, at 12:52 PM, Guido van Rossum wrote:
> On 8/14/07, Barry Warsaw <[EMAIL PROTECTED]> wrote:
>> It would have been perfect, I think, if I could have opened the file
>> in text mode so that read() gave me strings, with universal newlines
On 8/14/07, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> On Aug 14, 2007, at 12:52 PM, Guido van Rossum wrote:
> > On 8/14/07, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> >> It would have been perfect, I think, if I could have opened the file
> >> in text mode so that read() gave me strings, with univer
A new version is up, incorporating material from the various discussions
on this list:
http://www.python.org/dev/peps/pep-3101/
Diffs are here:
http://svn.python.org/view/peps/trunk/pep-3101.txt?rev=57044&r1=56535&r2=57044
-- Talin
___
Python
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Aug 15, 2007, at 12:03 AM, Guido van Rossum wrote:
> On 8/14/07, Barry Warsaw <[EMAIL PROTECTED]> wrote:
>> On Aug 14, 2007, at 12:52 PM, Guido van Rossum wrote:
>>> On 8/14/07, Barry Warsaw <[EMAIL PROTECTED]> wrote:
It would have been perfec
On Tue, 14 Aug 2007 21:12:32 -0500
Ron Adam <[EMAIL PROTECTED]> wrote:
>
>
> Greg Ewing wrote:
> > Guido van Rossum wrote:
> >> On 8/13/07, Andrew James Wade <[EMAIL PROTECTED]> wrote:
> >>
> >>> On Mon, 13 Aug 2007 20:53:26 -0700
> >>> "Guido van Rossum" <[EMAIL PROTECTED]> wrote:
> >
> I
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 newlines mode; lines
may end in \r, \n, or \r\n, and these are translate
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Aug 14, 2007, at 11:39 AM, Barry Warsaw wrote:
> I will create a sandbox branch and apply my changes later today so
> we have something concrete to look at.
Done. See:
http://svn.python.org/view/sandbox/trunk/emailpkg/5_0-exp/
I'm down to 5 f
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 don't expect this will ever get very long.
>
> The first __format
38 matches
Mail list logo
