Phillip J. Eby wrote:
> In other words, a class' metaclass has to be a derivative of all its
> bases' metaclasses; ISTM that a __prepare__ namespace needs to be a
> derivative in some sense of all its bases' __prepare__ results. This
> probably isn't enforceable, but the pattern should be docum
>> if j in r:
>> ...
>>
>> Given the context, I think this is a very Obvious Way To Do It, and
>> it's surprising that it isn't as efficient as it looks like it should
>> be.
Guido> Fair enough. So maybe *you* can contribute a patch?
Given the nature of this discussi
At 07:40 PM 7/31/2007 +1000, Nick Coghlan wrote:
>Phillip J. Eby wrote:
>>In other words, a class' metaclass has to be a derivative of all
>>its bases' metaclasses; ISTM that a __prepare__ namespace needs to
>>be a derivative in some sense of all its bases' __prepare__
>>results. This probably
""Martin v. Löwis"" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Guido van Rossum schrieb:
>>> I found that in many cases, this is a virus scanner or the indexing
>>> service interfering. They open the file, and then the test suite cannot
>>> delete it.
>>
>> Oh darn. I remember
On 7/31/07, Joe Smith <[EMAIL PROTECTED]> wrote:
> Hmm... The documentation for Cygwin's unlink() implies that it should
> function the same as a POSIX unlink() except perhaps if a non-Cygwin process
> has an open handle for it without the correct attributes. I see nothing on
> my system that would
On 7/31/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Also, bringing it back more on-topic, what should the value of this
> expression be?
>
> 4 in range(0, 10, 3)
>
> That is, are we treating range() as a set or an interval? Maybe I missed
> earlier messages in this thread where this was
On 7/30/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Does this mean that Py3k text streams will accept byte arrays
> in their write() methods, and that byte arrays can be concatenated
> with unicode strings and otherwise used in any context expecting
> a text string, as long as all their elements ar
On 7/31/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Also, bringing it back more on-topic, what should the value of this
> expression be?
> 4 in range(0, 10, 3)
> That is, are we treating range() as a set or an interval?
IMHO, 'range' is a like a set of integers, not an interval. For me
Guido> You missed it -- it should definitely be equivalent to
Guido> 4 in list(range(0, 10, 3))
Guido> i.e.
Guido> 4 in [0, 4, 8]
Ummm... you mean
4 in [0, 3, 6, 9]
right?
Skip
___
Python-3000 mailing list
Python-3000@
On 7/31/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> You missed it -- it should definitely be equivalent to
> 4 in list(range(0, 10, 3))
> i.e.
> 4 in [0, 4, 8]
An then, as list/tuple __contains__ is implemented in terms of rich
comparison (with Py_EQ), perhaps a patch is not so easy
"Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> On 7/31/07, Joe Smith <[EMAIL PROTECTED]> wrote:
>> Hmm... The documentation for Cygwin's unlink() implies that it should
>> function the same as a POSIX unlink() except perhaps if a non-Cygwin
>> process
>> has an
"Joe Smith" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>
> Exactly the issue.
> I see the problem here is cygwin's partial POSIX complience. However,
> Windows NT had a design goal of allowing a complient implementation
> of POSIX to be implmented in a subsystem (along with usere
> Regular Windows typically won't let you remove a file when you still
> have it open.
It depends. If FILE_SHARE_DELETE was passed to CreateFile when opening,
you may DeleteFile it while it is still open. Otherwise, you get an
error from DeleteFile.
> Is this also a restriction on CYGWIN?
Cygwin
>> Is this also a restriction on CYGWIN? I don't know
>> anything about CYGWIN but I could imagine that they allow unlink() to
>> succeed when there's still a file descriptor referencing it, and that
>> they will delete the file when you close it.
>
> Exactly. That is exactly what they do.
Not ex
On 7/31/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> >> Is this also a restriction on CYGWIN? I don't know
> >> anything about CYGWIN but I could imagine that they allow unlink() to
> >> succeed when there's still a file descriptor referencing it, and that
> >> they will delete the file when
""Martin v. Löwis"" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>>> Is this also a restriction on CYGWIN? I don't know
>>> anything about CYGWIN but I could imagine that they allow unlink() to
>>> succeed when there's still a file descriptor referencing it, and that
>>> they will
"Joe Smith" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>
> "Joe Smith" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>>
>> Exactly the issue.
>> I see the problem here is cygwin's partial POSIX complience. However,
>> Windows NT had a design goal of allowing a com
> That is what they do with the latest patches. It is pretty much
> equivent to the POSIX system. That requires Native NT Calls, and is
> not part of win32. It is equivlent to marking the file for deletion
> on close, except the other handles do not need to have shared_delete.
> The moving the fil
>> What they do instead is
>> 1. try to delete the file. If that fails for sharing
>>violation, try 2.
>> 2. move the file to the recycle bin, and set the
>>"delete" disposition flag on the file, this will
>>cause it to be removed from the recycle bin when
>>the last handle is clos
I think that WeakKeyDictionary and should be renamed to WeakKeyDict (same
with WeakValueDictionary). This will make it consistent with dict and
collections.defaultdict.
Sincerely
___
Python-3000 mailing list
[email protected]
http://mail.python.org/
20 matches
Mail list logo
