On 10/28/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Jim Jewett wrote:
> > Decimal doesn't mean "base 10", it means "has a decimal point"
> According to dictionary.com, it means
I see that I wasn't clear about this still being within the scope of
"To most people ..."
The dictionary gives a corre
> Bill Janssen wrote:
> > that whole mess of code is a good argument for *not* exposing the
> > fileno in Python
>
> Seems to me that a socket should already *be* a file,
> so it shouldn't need a makefile() method and you
> shouldn't have to mess around with filenos.
I like that model, too. I al
Bill Janssen wrote:
> that whole mess of code is a good argument for *not* exposing the
> fileno in Python
Seems to me that a socket should already *be* a file,
so it shouldn't need a makefile() method and you
shouldn't have to mess around with filenos.
--
Greg
___
Jim Jewett wrote:
> Decimal doesn't mean "base 10", it means "has a decimal point"
According to dictionary.com, it means
1. pertaining to tenths or to the number 10.
2. proceeding by tens: a decimal system.
--
Greg
___
Python-3000 mailing lis
On 10/28/07, James Thiele <[EMAIL PROTECTED]> wrote:
> PEP 361 lists __bool__ support as being possible for 2.6 backporting.
> As of today the trunk build uses __nonzero__ like 2.5 but 3.0 alpha
> uses __bool__. Has a decision been made on whether this will make the
> cut for 2.6?
>
> In a more gen
Dnia 27-10-2007, So o godzinie 16:23 +0200, Christian Heimes pisze:
> The second line is a fprintf(stderr, "%s\n", char *path). Do you see the
> difference between "testäöü" and "testõ÷³"?
"äöü" in CP-1252 has the same bytes as "õ÷³" in CP-850, so this is some
confusion between ANSI and OEM codep
PEP 361 lists __bool__ support as being possible for 2.6 backporting.
As of today the trunk build uses __nonzero__ like 2.5 but 3.0 alpha
uses __bool__. Has a decision been made on whether this will make the
cut for 2.6?
In a more general vein, is there a cutoff date for producing a list of
3.0 fe
I've now got a working SSL patch for Py3K (assuming that the patches
for #1347 and #1349 are committed), but I'm a bit worried about the
lazy GC of sockets. I find that simply dropping an SSLSocket on the
floor doesn't GC the C structures. This implies that the instance in
the SSLSocket._sslobj s
Jim Jewett wrote:
> On 10/27/07, Bill Janssen <[EMAIL PROTECTED]> wrote:
>
> > > > File "/local/python/3k/src/Lib/io.py", line 455, in read
> > > > del b[n:]
> > > > TypeError: 'slice' object does not support item deletion
>
> > b = bytes(n.__index__())
>
> Isn't bytes the *im*muta
Jim Jewett wrote:
> Isn't bytes the *im*mutable bytestring, so that you would need a
> buffer (rather than a bytes) if you plan to clear it out?
The types aren't renamed yet. Bytes is still the mutable bytestring and
str8 the immutable.
Christian
___
P
Jim Jewett wrote:
> One likely difference is that testäöü should be a legitimate (unicode)
> Python name, but testõ÷³ probably isn't, because the division sign
> isn't alphanumeric.
>
> Also, there is a chance that testäöü was already in the appropriate
> normalized form, but testõ÷³ probably isn'
On 10/27/07, Bill Janssen <[EMAIL PROTECTED]> wrote:
> > > File "/local/python/3k/src/Lib/io.py", line 455, in read
> > > del b[n:]
> > > TypeError: 'slice' object does not support item deletion
> b = bytes(n.__index__())
Isn't bytes the *im*mutable bytestring, so that you would ne
On 10/27/07, Christian Heimes <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> The second line is a fprintf(stderr, "%s\n", char *path).
> Do you see the
> difference between "testäöü" and "testõ÷³"?
One likely difference is that testäöü should be a legitimate (unicode)
Python name, but tes
On 10/26/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Jim Jewett wrote:
> > If it weren't for backwards compatibility, 'i' would be a much better
> > option,
> No, it wouldn't, because 'integer' is a data type, not
> a display format. The Python format codes specify display
> formats, not data type
14 matches
Mail list logo
