Patrick Maupin a écrit :
> A string
> replace on a data file is actually much easier than on a code file,
> and it really is a one-liner, so the potential existence of upper case
> 'X' in the data file does not seem like reason enough to make these
> different.
>
you don't analyse data files for
The update includes issues discussed to date, plus the support of
uppercase on input of binary and hex, e.g. '0O123'.
It was pointed out to me that, since I suggested upper/lowercase was
an issue for another PEP, removal of uppercase octal/binary belonged
in that same PEP, if anybody cares enough
On 3/19/07, Patrick Maupin <[EMAIL PROTECTED]> wrote:
> It was pointed out to me that, since I suggested
> upper/lowercase was an issue for another PEP,
> removal of uppercase octal/binary belonged in that same PEP
Removal of uppercase from other formats would affect backwards
compatibility. For
This is my first PEP, and one of my first postings to this list, so I
apologize in advance for any glaring errors. I wrote this up because I
feel like it is a good companion to the recent octal and binary
discussions/PEP. If nothing else, this should at least provide a jumping
off point for d
The point was not to reopen the discussion; we've had the discussion
and the outcome is clear. The point was, what should be justified in
the PEP.
On 3/18/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> On 3/18/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > Octal does need to be justified, since
In Py2.6 and Py3.0, what would these emit:
map(int, '08:30:00'.split(':')) # handle common decimal string
formats with leading zeroes
int('0777', 8) # handle externally
created octal literal strings
myfile.write(oct(44)) # wri
On 3/19/07, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> In Py2.6 and Py3.0, what would these emit:
I do not think we are contemplating breaking anything in 2.6, unless
the 3.0 compatibility mode is selected.
> map(int, '08:30:00'.split(':')) # handle common decimal string
> formats w
"Patrick Maupin" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| The update includes issues discussed to date, plus the support of
| uppercase on input of binary and hex, e.g. '0O123'.
|
| It was pointed out to me that, since I suggested upper/lowercase was
| an issue for another PE
On 3/19/07, Andrew Karem McCollum <[EMAIL PROTECTED]> wrote:
[SNIP]
> PEP: XXX
> Title: Requiring Lowercase Characters in Literal Modifiers
> Version: $Revision$
> Last-Modified: $Date$
> Author: Andrew McCollum
> Status: Draft
> Type: Standards Track
> Content-Type: text/x-rst
> Created: 19-Mar-2
Patrick Maupin wrote:
> Most of the discussion on these issues occurred on the Python-3000 mailing
> list starting 14-Mar-2007, prompted by Raymond Hettinger's observation
> (cleverly couched as a question) that the average human being would be
> completely mystified upon finding that prepending a
On 3/18/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> On 3/18/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > Octal does need to be justified, since some people argued to remove
> > it. I guess binary needs to be justified because Thomas doesn't see
> > the need. :-)
>
> I see literals for octal
I spent some time today fixing the compiler package so that it uses
the new metaclass syntax and generates the correct new-style code for
class definitions. But when testing this, I found that there's another
newfangled piece of syntax it doesn't understand: nonlocal. Can anyone
who is more familia
Bob Ippolito wrote:
> It would absolutely help if there was an obvious way to get a string
> of 1s and 0s out of an integer given the number of bits you want to
> write it as
The obvious thing would be
"%bm.n" % i
where n = maximum number of bits.
--
Greg
> Semantic Changes
>
>
> The behavior of the 'int' builtin when passed a radix of 0 will be changed to
> follow the above grammar. This change is to maintain the specified behavior
> [5]_ that a radix of 0 mirrors the literal syntax. The behavior of this
> function will otherwise n
> And float()? Will this break?
>
> In [9]: float('%E' % 3e-10)
> Out[9]: 3e-10
I don't see any compelling reason to break this behavior. Also, float is
different in that it already has special handling for values such as "Inf"
and "NaN" (even if they are inconsistent across platforms), and make
On 3/19/07, Andrew McCollum <[EMAIL PROTECTED]> wrote:
> > Changes like this don't do much for me. Sure, lowercase modifiers are
> > prettier, but why remove the general functionality and leave in a few
> > special cases, especially when functionality to display numbers in
> > those formats exist
Hi all,
I've added two new fixers to 2to3 this weekend, plus significant new
functionality for a third:
* fix_next handles the it.next() -> next(it) transition for PEP 3114.
* fix_nonzero converts __nonzero__ to __bool__ methods, as mentioned
in PEP 3100.
* fix_tuple_params now fixes up tuple par
Collin Winter schrieb:
> Hi all,
>
> I've added two new fixers to 2to3 this weekend, plus significant new
> functionality for a third:
>
> * fix_next handles the it.next() -> next(it) transition for PEP 3114.
> * fix_nonzero converts __nonzero__ to __bool__ methods, as mentioned
> in PEP 3100.
>
18 matches
Mail list logo
