On approximately 4/25/2009 5:35 AM, came the following characters from
the keyboard of Martin v. Löwis:
Because the encoding is not reliably reversible.
Why do you say that? The encoding is completely reversible
(unless we disagree on what "reversible" means).
I'm +1 on the concept, -1 on the
> How about another str-like type, a sequence of char-or-bytes?
That would be a different PEP. I personally like my own proposal
more, but feel free to propose something different.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http:/
ark Dickinson wrote:
> On Sun, Apr 26, 2009 at 10:42 PM, Scott David Daniels wrote:
>...
>> I had also said (without explaining:
only the trailing zeroes with the e, so we wind up with:
1157920892373161954235709850086879078532699846656405640e+23
or 1157920892373161954235709850
How about another str-like type, a sequence of char-or-bytes? Could be
called strbytes or stringwithinvalidcharacters. It would support
whatever subset of str functionality makes sense / is easy to
implement plus a to_escaped_str() method (that does the escaping the
PEP talks about) for people who
Mark Dickinson wrote:
(1) Currently, '%f' formatting automatically changes to '%g' formatting for
numbers larger than 1e50. For example:
'%f' % 2**166.
'93536104789177786765035829293842113257979682750464.00'
'%f' % 2**167.
'1.87072e+50'
I propose removing this feature for 3.1
I don't
it would make more sense to me if it
stayed fixed at 56 sig digits for numbers larger than 1e50.
So I agree with this, even if the default # of sig digits were less.
Several reasons to accept Mark's proposal:
* It matches what C does and many languages tend to copy the
C standards with
On Sun, Apr 26, 2009 at 10:42 PM, Scott David Daniels
wrote:
> I had also said (without explaining:
>> > only the trailing zeroes with the e, so we wind up with:
>> > 1157920892373161954235709850086879078532699846656405640e+23
>> > or 115792089237316195423570985008687907853269984665640564.0
Mark Dickinson wrote:
> On Sun, Apr 26, 2009 at 8:11 PM, Scott David Daniels
> wrote:
>> As a user of Idle, I would not like to see the change you seek of
>> having %f stay full-precision. When a number gets too long to print
>> on a single line, the wrap depends on the current window width, and
Mark Dickinson wrote:
I'd like to propose two minor changes to float and complex
formatting, for 3.1. I don't think either change should prove
particularly disruptive.
(1) Currently, '%f' formatting automatically changes to '%g' formatting for
numbers larger than 1e50. For example:
'%f' % 2*
Floating point printing is tricky, as I am sure you know. You might
want to refrefresh your understanding by consulting the literture--I
know I would. For example, you might want to look at
http://portal.acm.org/citation.cfm?id=93559
Guy Steele's paper:
Guy L. Steele , Jon L. White, H
On Sun, Apr 26, 2009 at 8:11 PM, Scott David Daniels
wrote:
> As a user of Idle, I would not like to see the change you seek of
> having %f stay full-precision. When a number gets too long to print
> on a single line, the wrap depends on the current window width, and
> is calculated dynamically.
Mark Dickinson wrote:
... """[5] These numbers are fairly arbitrary. They are intended to
avoid printing endless strings of meaningless digits without
hampering correct use and without having to know the exact
precision of floating point values on a particular machine."""
I don't f
> Does anyone know what the problem is?
The hardware running it apparently has serious problems.
Upfronthosting, the company providing the hardware, is
working on a solution. Unfortunately, it is difficult to
get support from the datacenter on weekends.
Regards,
Martin
___
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Terry Reedy wrote:
> Is NUL \0 allowed in POSIX file names? If not, could that be used as an
> escape char. If it is not legal, then custom translated strings that
> escape in the wild would raise a red flag as soon as something else
> tried to u
On Sun, Apr 26, 2009 at 5:59 PM, Eric Smith wrote:
> Mark Dickinson wrote:
>> I propose changing the complex str and repr to behave like the
>> float version. That is, repr(4. + 10.j) should be "(4.0 + 10.0j)"
>> rather than "(4+10j)".
>
> I'm +0.5 on this. I'd probably be +1 if I were a big comp
Mark Dickinson wrote:
I'd like to propose two minor changes to float and complex
formatting, for 3.1. I don't think either change should prove
particularly disruptive.
(1) Currently, '%f' formatting automatically changes to '%g' formatting for
numbers larger than 1e50. For example:
...
I pro
On Sun, Apr 26, 2009, Mark Dickinson wrote:
> On Sun, Apr 26, 2009 at 4:19 PM, Aahz wrote:
>> On Sun, Apr 26, 2009, Mark Dickinson wrote:
>>>
>>> The bugs.python.org site seems to be down.
>>
>> Dunno -- forwarded to the people who can do something about it. ?(There's
>> a migration to a new mails
On Sun, Apr 26, 2009 at 4:19 PM, Aahz wrote:
> On Sun, Apr 26, 2009, Mark Dickinson wrote:
>>
>> The bugs.python.org site seems to be down.
>
> Dunno -- forwarded to the people who can do something about it. (There's
> a migration to a new mailserver going on, but I don't think this is
> related.
On Sun, Apr 26, 2009, Mark Dickinson wrote:
>
> The bugs.python.org site seems to be down.
Dunno -- forwarded to the people who can do something about it. (There's
a migration to a new mailserver going on, but I don't think this is
related.)
--
Aahz (a...@pythoncraft.com) <*>
The bugs.python.org site seems to be down. ping gives me
the following (from Ireland):
Macintosh-4:py3k dickinsm$ ping bugs.python.org
PING bugs.python.org (88.198.142.26): 56 data bytes
36 bytes from et.2.16.rs3k6.rz5.hetzner.de (213.239.244.101):
Destination Host Unreachable
Vr HL TOS Len ID
Paul Moore writes:
> 2009/4/24 Stephen J. Turnbull :
> > Paul Moore writes:
> >
> > > The pros for Martin's proposal are a uniform cross-platform interface,
> > > and a user-friendly API for the common case.
> >
> > A more accurate phrasing would be "... a user-friendly API for those
> >
Steven D'Aprano wrote:
On Sun, 26 Apr 2009 08:06:56 pm Mark Dickinson wrote:
I'd like to propose two minor changes to float and complex
formatting, for 3.1. I don't think either change should prove
particularly disruptive.
(1) Currently, '%f' formatting automatically changes to '%g'
formatt
On Sun, 26 Apr 2009 08:06:56 pm Mark Dickinson wrote:
> I'd like to propose two minor changes to float and complex
> formatting, for 3.1. I don't think either change should prove
> particularly disruptive.
>
> (1) Currently, '%f' formatting automatically changes to '%g'
> formatting for numbers la
I'd like to propose two minor changes to float and complex
formatting, for 3.1. I don't think either change should prove
particularly disruptive.
(1) Currently, '%f' formatting automatically changes to '%g' formatting for
numbers larger than 1e50. For example:
>>> '%f' % 2**166.
'93536104789177
24 matches
Mail list logo
