Johan> FWIW, I'd say yes; I sometimes find it a bit difficult to
Johan> remember how the operator should be placed, there are several
Johan> possible ways of making a mistake, eg;
Johan>a > x < b
Johan>a < x > b
Johan>a < x < b
Johan>a > x > b
If the t
i understand there is no much need for using ranges instead of
intervals (a < x < b), but:
1) it's already supported. you CAN use x in range(100), so
why not optimize it? there's no justification to keep it an
O(N) operation (you're not trying to punish anyone :).
it just calls for adding a __cont
On 7/29/07, tomer filiba <[EMAIL PROTECTED]> wrote:
> i understand there is no much need for using ranges instead of
> intervals (a < x < b), but:
>
> 1) it's already supported. you CAN use x in range(100), so
> why not optimize it? there's no justification to keep it an
> O(N) operation (you're no
On 7/28/07, Johan Dahlin <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > Do we really need another way to spell a <= x < b?
>
> FWIW, I'd say yes; I sometimes find it a bit difficult to remember
> how the operator should be placed, there are several possible ways
> of making a mistake, eg;
On 7/29/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Don't forget the *cost* in terms of code bloat. Plus, I asked for a
> patch. Where is it? This is not Santa Claus's email address. You're
> expected to contribute more than a wish.
first off all, that's not the politest way to put it, espec
>> Don't forget the *cost* in terms of code bloat. Plus, I asked for a
>> patch. Where is it? This is not Santa Claus's email address. You're
>> expected to contribute more than a wish.
>
> first off all, that's not the politest way to put it, especially since i have
> submitted some patches befor
"Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> On 7/18/07, Joe Smith <[EMAIL PROTECTED]> wrote:
>> >> I'm wondering if the recusion limit on my build is getting set too low
>> >> somehow.
>> >
>> > Can you find out what it is? sys.getrecursionlimit().
>>
>> Hmm..
"Joe Smith" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>
> "Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>> On 7/18/07, Joe Smith <[EMAIL PROTECTED]> wrote:
>>> >> I'm wondering if the recusion limit on my build is getting set too
>>> >> low
>>
On 7/29/07, Joe Smith <[EMAIL PROTECTED]> wrote:
> What I have found is that (on CYGWIN) all of marshal seems to work fine
> except for marshal.load().
> marshal.dump()'s output can be read by 2.5's marshal.load() without problem.
> 3k's marshal.load() will not
> load the data from 3k's marshal.dum
Nick Coghlan wrote:
> Py3k strings are unicode, so returning a string would mean you just have
> to encode it again using the ascii codec to get the bytes to put on the
> wire.
I still believe that producing a string is conceptually
the right thing to do. The point of base64 is to encode
binary
Martin v. Löwis wrote:
> The point that proponents of "base64 encoding should
> yield strings" miss is that US-ASCII is *both* a character set,
> and an encoding.
Last time we discussed this, I went and looked at the
RFC where base64 is defined. According to my reading of
it, nowhere does it say t
On 7/29/07, Joe Smith <[EMAIL PROTECTED]> wrote:
> There are still some problems with the 'Python' directory for example. This
> is because of a change in the internals of Cygwin.
> Cygwin does have "managed mounts" which allow for case sensitivity.
> Compiling Python inside a managed mount elimina
[EMAIL PROTECTED] wrote:
> You can't spell
>
> a <= x <= b
>
> or
>
> a < x < b
>
> without remembering to add or subtract 1 from the appropriate endpoint
I think the use cases for this are where you're trying to
express a range-like condition, i.e 'a <= x < b'. Then you
have to make
On 7/29/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Martin v. Löwis wrote:
> > The point that proponents of "base64 encoding should
> > yield strings" miss is that US-ASCII is *both* a character set,
> > and an encoding.
>
> Last time we discussed this, I went and looked at the
> RFC where base64 i
Guido van Rossum wrote:
> On 7/29/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
>> Martin v. Löwis wrote:
>>> The point that proponents of "base64 encoding should
>>> yield strings" miss is that US-ASCII is *both* a character set,
>>> and an encoding.
>> Last time we discussed this, I went and looked a
Greg> I think the use cases for this are where you're trying to express
Greg> a range-like condition, i.e 'a <= x < b'. Then you have to make
Greg> sure you get the right relations in the right places, which is the
Greg> same kind of burden as remembering to add or subtract 1 in th
Greg Ewing wrote:
> Nick Coghlan wrote:
>> Py3k strings are unicode, so returning a string would mean you just have
>> to encode it again using the ascii codec to get the bytes to put on the
>> wire.
>
> I still believe that producing a string is conceptually
> the right thing to do. The point
"Greg Ewing" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| Nick Coghlan wrote:
| > Py3k strings are unicode, so returning a string would mean you just
have
| > to encode it again using the ascii codec to get the bytes to put on the
| > wire.
|
| I still believe that producing a s
Phillip J. Eby wrote:
> At 08:25 AM 7/27/2007 -0700, Guido van Rossum wrote:
>> Basic GFs, great. Before/after/around, good. Other method
>> combinations, fine. But GFs in classes and subclassing? Not until we
>> have a much better design.
>
> Sounds reasonable to me. The only time I actually use
> I believe that converting a Unicode string to a base64 encoded form is
> necessarily a 2-step process.
I think that part is undebated. What is the debate is whether
base64.encodestring (which accepts bytes) should *produce*
(unicode) strings, which would then have to be encoded as
us-ascii. Tha
>> If I patch io.py to default to "utf-8" rather than using the filesystem
>> encoding (ascii), that fixes a few more things. (test_coding.py and
>> test_minidom.py)
>
> How come the filesystem decoding is set to ASCII?
I guess there are two problems: a) MS_WINDOWS isn't defined, and the
relevant
On 7/29/07, Talin <[EMAIL PROTECTED]> wrote:
> Phillip J. Eby wrote:
> > At 08:25 AM 7/27/2007 -0700, Guido van Rossum wrote:
> >> Basic GFs, great. Before/after/around, good. Other method
> >> combinations, fine. But GFs in classes and subclassing? Not until we
> >> have a much better design.
> >
The issue seems to be in the socket.py close method. It needs to sleep
socket.SO_REUSEADDR seconds before returning. Yes, it is a simple fix
in python, but the socket code is C. I found some code in socket.py
and made the changes. Patch is available at
http://sourceforge.net/tracker/index.php?func=
23 matches
Mail list logo
