Re: [Python-Dev] Python 2.4 won the "Jolt productivity award" last night
On Thu, 17 Mar 2005 16:01:03 +, Gareth McCaughan <[EMAIL PROTECTED]> wrote: > http://www.sdmagazine.com/jolts/ , > > but it's not been updated yet and therefore still has last year's > winners on it. I haven't found anything with more up-to-date > results. The 2005 winners are listed here: http://www.sdmagazine.com/pressroom/jolt_winners_2005.pdf -- Cheers, Simon B, [EMAIL PROTECTED], http://www.brunningonline.net/simon/blog/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python-dev Summary for 2005-03-01 through 2005-03-15 [draft]
- sum() semantics discussed - Guido's blog entry on `the fate of reduce() in Python 3000`_ (which reiterated Guido's plan to cut map(), reduce(), filter() and lambdas (what about zip()?) caused a huge discussion on whether sum() worked the best way possible. As it stands now, sum() only accepts a sequence of numbers and its optional second argument works as an initial value to build off of. That last sentence isn't quite true. With an appropriate second argument, sum can be used to sum any sequence (even one containing strings): Py> class additive_identity(object): ... def __add__(self, other): ... return other ... Py> sum(["a"] * 5, additive_identity()) 'a' This is fairly abusive of sum, though :) Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.skystorm.net ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] thread semantics for file objects
On Fri, 18 Mar 2005 07:57:25 +0100, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > The guarantee that "we" want to make is certainly stronger: if the > threads all read from the same file, each will get a series of "chunks". > The guarantee is that it is possible to combine the chunks in a way to > get the original contents of the file (i.e. not only the sum of the > bytes is correct, but also the contents). That would be a useful property to be able to rely on, certainly. (Although in practical terms, probably a lot less than people would *like* to see guaranteed :-)) > However, I see little value adding this specific guarantee to the > documentation when so many other aspects of thread interleaving > are unspecified. I'm not sure I agree. It's an improvement in the situation, so why not add it? It may even encourage others, when thinking about threading issues, to consider whether the documentation should guarantee anything - and if so, to add that guarantee. Over time, the documentation gets better at describing thread-related behaviour - and correspondingly, people get (somewhat) more confident that where the documentation doesn't guarantee things, it's because there is a good reason. > For example, if a thread reads a dictionary simultaneous to a write > in another thread, and the read and the write deal with different > keys, there is a guarantee that they won't affect each other. If they > operate on the same key, the read either gets the old value, or the > new value, but not both. If this is a genuine guarantee, then let's document it! I asked about precisely this issue on python-list a long while ago, and no-one could provide me with a confident answer (I couldn't be sure myself, my head explodes when I try to understand thread-related code). The only confident answer I got was "you're safe if you use a lock", but taking that position to extremes results in massive levels of unnecessary serialisation. > Writing down all these properties does little good, IMO. Not a huge amount of good, certainly. But no harm, and a little bit of direct good, and also some indirect good in terms of making it clear that the issue has been thought about. I suppose what I am saying that there is a practical difference between "undefined" and "unknown", even if there isn't a theoretical one... Of course, there's an implied requirement here to confirm any documented guarantees in Jython, and IronPython, and PyPy, and... But given that none of these (yet) implement the full Python 2.4 language definition, as far as I am aware, it's probably not sensible to get too hung up on this fact (although confirming that a guarantee doesn't cause major implementation difficulties would be reasonable). Paul. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python-dev Summary for 2005-03-01 through 2005-03-15 [draft]
On Thu, 17 Mar 2005 18:21:33 -0800, Brett C. <[EMAIL PROTECTED]> wrote: > > 2.4.1 should be out soon > > Python 2.4.1c1 is out. Very shortly c2 will be released. Assuming no major > issues come up, 2.4 final will be out. You probably mean something like "2.4.1 final will be out shortly afterwards" (I don't recall if a date has been confirmed). Paul ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Faster Set.discard() method?
On Fri, 2005-03-18 at 01:19, Andrew McNamara wrote: > No, exceptions are fast at the C level - all they do is set a flag. The > expense of exceptions is saving a restoring python frames, I think, > which doesn't happen in this case. So the current implementation is > ideal for C code - clear and fast. The other advantage for raising and catching exceptions entirely in C is that the (class) exceptions are never instantiated. Once you cross the C-Python barrier you have to pay for that instantiation. -Barry signature.asc Description: This is a digitally signed message part ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.4 won the "Jolt productivity award" last night
On Fri, 18 Mar 2005 09:07:19 +, Simon Brunning <[EMAIL PROTECTED]> wrote: > The 2005 winners are listed here: > http://www.sdmagazine.com/pressroom/jolt_winners_2005.pdf Oh, and while I'm breaking cover on python-dev; congratulations to the lot of you for this. You all richly deserve it. -- Cheers, Simon B, [EMAIL PROTECTED], http://www.brunningonline.net/simon/blog/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] __metaclass__ problem
Hi there, first of all I'd like to introduce myself, because I'm new to this list. If I did wrong to post here, please be patient... The reason for my posting is my previous work with __metaclass__ and advice.py, which is nice to use. While working with __metaclass__ I found situations, where I could not explain the resulting output/behaviour of type.__new__ (super(...,...).__new__) using the available documentation. This is why I've been posting bug no. 1164631 - super(...).__new__( ... ) behaves "unexpected". After having checked the C code of 'typeobject.c', I think I might explain the (undocumented) behaviour now (I've been adding a comment to bug no. 1164631). It is - in short - the following: Lines 1602 to 1626 of 'typeobject.c' decide the "winning" metaclass within any class hierarchy. The effekt I noticed - and still consider to be a bug - is introduced in lines 1611 to 1614: The metaclass of the current class will always be the type of class which is at most subclassed from the metatype previously named as "winner". In consequence a programmer only is in control of the "metaclass" of his class, if he decides it to be a subtype of all former metaclasses he used in his class hierarchy, or if he uses the same metaclass as the superclass does. The reasons, why I consider this a bug is: 1. This feature is undocumented. If there is a documentation of it, i might not have found it - or maybe it was not detailed enough to make a programmer (like me: just starting with metaclasses) understand that point. In either cases it would be great to complete the documentation. 2. The class code using __metaclass__, produced by a programmer sets clear directives for the way the resulting Product (the class) has to be and/or to behave. If instead a product even might behave in a completely other way, because it just intends to, this either is a M$ Product ;-) or a bug. 3. If the intention is fixed by a specification, the bug is not the products/programs behaviour then. Instead the bug is a missing Exception, which should inform the programmer of a programming error which violates the specifications. E.g.: TypeError( "__metaclass__ is not of the expected type." ) (or whatever...) 4. Apart the points 1 to 3 and without knowledge of the discussions you probably had while developing this __metaclass__ thing, I'd call it a pitty, if using supertypes of metaclasses as metaclass in a subtype of a class is prohibited. This would make the whole thing somehow incomplete, because it would result in the need of a programmer to know, all metaclasses that have been used by all classes down the mro to 'object'. ...ok - these are my thoughts to what I called the "__metaclass problem" in the subject of this mail. Of course, I'm not into python as long as you are, so: 1. I might have tried something completely stupid 2. I did not take into account the discussions you already might have had about that. Above all I'm not a native english speaker... ;-) ... please don't flame :-) Any feedback (or bugfixes? :-) welcome. Dirk Brenckmann -- "Happy ProMail" bis 24. März: http://www.gmx.net/de/go/promail Zum 6. Geburtstag gibt's GMX ProMail jetzt 66 Tage kostenlos! ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] thread semantics for file objects
On Fri, 18 Mar 2005 07:57:25 +0100, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > Writing down all these properties does little good, IMO. This includes > your proposed property of file reads: anybody reading your statement > will think "of course it works this way - why even mention it". The thingsa that are so obvious they don't need to be written down are often the most interesting things to write down. In fact, you started the thread by saying there were no guarantees whatsoever and chiding me for asking if there were any. But it seems there are some intended semantics that are strong than what you would find in C or Perl. Hence, I don't think they would be obvious to anyone who comes to Python from one of those languages. I agree that the semantics of multi-threaded Python programs is an enormous domain and we're discussing a tiny corner of it. I agree that it would be quite challenging to get better documentation or specifications here. But I also think that every little bit helps. Jeremy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] thread semantics for file objects
Jeremy Hylton wrote: On Thu, 17 Mar 2005 16:25:44 -0500, Aahz <[EMAIL PROTECTED]> wrote: On Thu, Mar 17, 2005, Jeremy Hylton wrote: Are the thread semantics for file objecst documented anywhere? I don't see anything in the library manual, which is where I expected to find it. It looks like read and write are atomic by virtue of fread and fwrite being atomic. Uncle Timmy will no doubt agree with me: the semantics don't matter. NEVER, NEVER access the same file object from multiple threads, unless you're using a lock. And even using a lock is stupid. I just want to know what semantics are intended. If the documentation wants to say that the semantics are undefined that okay, although I think we need to say more because some behavior has been provided by the implementation for a long time. I think that when two threads write to the same fd without syncronization, the result is not deterministic anyway. In the case they are reading from the same fd, even worse! (and therefore the input cannot be useful to any serious algorithm) Python (libc in fact) just guarantees that there will be no crashes and corruption of data if the read/write functions are reentered. But ensuring that readline/writeline/etc is atomic would probably be a waste of resources protect the input/output for a case where the data is as good as random noise anyway. So I think aahz is right. Stelios ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Example workaround classes for using Unicode with csv module...
I added UnicodeReader and UnicodeWriter example classes to the csv module
docs just now. They mention problems with ASCII NUL characters (which I
vaguely remember - NUL-terminated strings are used internally, right?). Do
NULs still present a problem? I saw nothing in the log messages that
mentioned "ascii" or "nul" so I presume it is.
Here's what I added. Let me know if you think it needs any corrections,
especially if there's a better way to word "as long as you avoid encodings
like utf-16 that use NULs". Can that just be "as long as you avoid
multi-byte encodings other than utf-8"? I'd like to have something like
this in the docs to demonstrate a reasonable workaround for the current
no-Unicode code without casting it in stone by adding it to csv.py.
--
The \module{csv} module doesn't directly support reading and writing
Unicode, but it is 8-bit clean save for some problems with \ASCII{} NUL
characters, so you can write classes that handle the encoding and decoding
for you as long as you avoid encodings like utf-16 that use NULs.
\begin{verbatim}
import csv
class UnicodeReader:
def __init__(self, f, dialect=csv.excel, encoding="utf-8", **kwds):
self.reader = csv.reader(f, dialect=dialect, **kwds)
self.encoding = encoding
def next(self):
row = self.reader.next()
return [unicode(s, self.encoding) for s in row]
def __iter__(self):
return self
class UnicodeWriter:
def __init__(self, f, dialect=csv.excel, encoding="utf-8", **kwds):
self.writer = csv.writer(f, dialect=dialect, **kwds)
self.encoding = encoding
def writerow(self, row):
self.writer.writerow([s.encode("utf-8") for s in row])
def writerows(self, rows):
for row in rows:
self.writerow(row)
\end{verbatim}
They should work just like the \class{csv.reader} and \class{csv.writer}
classes but add an \var{encoding} parameter.
--
Thx,
Skip
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] thread semantics for file objects
stelios xanthakis wrote: I think that when two threads write to the same fd without syncronization, the result is not deterministic anyway. In the case they are reading from the same fd, even worse! (and therefore the input cannot be useful to any serious algorithm) Yes, but we are not talking about the same fd. Instead, we talk about the same FILE*. A thread-safe libc guarantees (AFAIK) that the data passed to fwrite are appended as a whole. This, in turn, means that the data passed to Python's file.write are also appended as a whole. I'm pretty sure this property also holds on Windows. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Re: [Python-checkins] python/dist/src/Doc/lib libcsv.tex, 1.18, 1.19
[EMAIL PROTECTED] wrote:
Update of /cvsroot/python/python/dist/src/Doc/lib
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv22325
Modified Files:
libcsv.tex
Log Message:
add UnicodeReader and UnicodeWriter example classes
[]
+The \module{csv} module doesn't directly support reading and writing
+Unicode, but it is 8-bit clean save for some problems with \ASCII{} NUL
+characters, so you can write classes that handle the encoding and decoding
+for you as long as you avoid encodings like utf-16 that use NULs.
The problem is more the fact that UTF-16 would require a stateful codec.
For the UnicodeWriter IMHO the best solution would be to make the csv
module unicode transparent (i.e. it simply calls the write method of the
underlying stream). Then it should be possible to stack the streams like
this:
import csv, codecs
w = cvs.writer(codecs.getwriter("utf-16")(open("foo.csv", "wb"))
w.writerow([u"foo", u"bar")]
If csv was implemented in Python this would be trivial.
Bye,
Walter Dörwald
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Change 'env var BROWSER override' semantics in webbrowser.py
Hi, I propose a small change in webbrowse.py module. At the present time: """ Under Unix, if the environment variable BROWSER exists, it is interpreted to override the platform default list of browsers,... """ (extract from Python-2.4/Doc/html/lib/module-webbrowser.html) I propose the following change: ''' --- webbrowser.py 2005-03-18 17:43:58.736854784 -0300 +++ webbrowser.py.new 2005-03-18 17:29:57.016815680 -0300 @@ -355,7 +355,7 @@ if "BROWSER" in os.environ: # It's the user's responsibility to register handlers for any unknown # browser referenced by this value, before calling open(). -_tryorder = os.environ["BROWSER"].split(os.pathsep) +_tryorder = os.environ["BROWSER"].split(os.pathsep) + _tryorder for cmd in _tryorder: if not cmd.lower() in _browsers: ''' This changes the semantics a bit, but in a positive way: - When the environment variable BROWSER is messed up, there is no reason not to try the other detected browser alternatives - If the BROWSER variable is Ok, than it is respected If nobody stand against it, or would like to propose an alternative (optimized) implementation, I can submit a patch to sf to alter both code and documentation. I'd appreciate to know if you consider this a bug or a new feature ? I consider this a bug: """ The webbrowser module provides a very high-level interface to allow displaying Web-based documents to users. The controller objects are easy to use and are platform-independent. Under most circumstances, simply calling the open() function from this module will do the right thing. """ (extract from Python-2.4/Doc/html/lib/module-webbrowser.html) Ignoring valid *already* detected browsers, due to a broken environment variable does not sound like _do the right thing_. cheers, Senra -- Rodrigo Senra MSc Computer Engineer [EMAIL PROTECTED] GPr Sistemas Ltda http://www.gpr.com.br ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Change 'env var BROWSER override' semantics in webbrowser.py
Rodrigo Dias Arruda Senra wrote: I propose a small change in webbrowse.py module. I think I'm generally in favour of such a change. However: - please don't post patches to python-dev, unless you *want* them to be ignored. Typically, nobody will pick up patches from python-dev and apply them, except for rare cases (e.g. urgent bug fixes of serious breakages); post to SF instead. - please accompany your change with a documentation patch. It may be that the exact search procedure for browsers is not specified yet; take that chance and specify it so clearly that the code without your patch would actually conflict with the documentation, so that readers of the new code can verify that this is indeed the documentation-mandated behaviour. - consider integration of test cases. As this involves startup code and environment variables, I would be willing to waive the test case requirement here as unimplementable. However, do consider writing test cases. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] RELEASED Python 2.4.1, release candidate 1
Vincent Wehren wrote: To check what I mentioned on comp.lang.python earlier, I ran the installer again (with 2.4.1 still intact), selected the "Change Python 2.4.1c1" radio button, clicked the "Finish" Button, clicked the "Advanced" button, clicked the "Cancel" button, and clicked "Yes" to the question "Are you sure you want to cancel the Python 2.4.1c1 installation". This crashed msiexec.exe. I was able to reproduce this on Windows XP Professional, Service Pack 2. I could reproduce it, but I doubt I can do anything about it. When it asked whether I want to report this to MS, I did - recently, I learned what the magic procedure behind this analysis is, and that there is a good chance that this report really ends up at the developer of installer responsible for the code that crashed. I'm pretty certain it is none of my code which causes the crash (the same rule applies as with Python: it may raise an exception, bring up an error message, and so on - but it should never crash). Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Re: Change 'env var BROWSER override' semantics in webbrowser.py
Martin v. Löwis wrote: > Rodrigo Dias Arruda Senra wrote: >> I propose a small change in webbrowse.py module. > > I think I'm generally in favour of such a change. However: > > - please don't post patches to python-dev, unless you *want* >them to be ignored. Typically, nobody will pick up patches >from python-dev and apply them, except for rare cases (e.g. >urgent bug fixes of serious breakages); post to SF instead. > - please accompany your change with a documentation patch. >It may be that the exact search procedure for browsers is >not specified yet; take that chance and specify it so >clearly that the code without your patch would actually >conflict with the documentation, so that readers of >the new code can verify that this is indeed the >documentation-mandated behaviour. > - consider integration of test cases. As this involves >startup code and environment variables, I would be willing >to waive the test case requirement here as unimplementable. >However, do consider writing test cases. Additionally, there are several patches on SF that pertain to webbrowser.py; perhaps you can review some of them... Reinhold -- Mail address is perfectly valid! ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] __metaclass__ problem
Dirk Brenckmann wrote: In consequence a programmer only is in control of the "metaclass" of his class, if he decides it to be a subtype of all former metaclasses he used in his class hierarchy, or if he uses the same metaclass as the superclass does. The behaviour is intentional, but you are correct that it is not fully documented in the official documentation [1]. Some of the 'wrinkles' described in Guido's original Python 2.2 essay [2] may need to be transferred to the docs. For instance: """For new-style metaclasses, there is a constraint that the chosen metaclass is equal to, or a subclass of, each of the metaclasses of the bases. Consider a class C with two base classes, B1 and B2. Let's say M = C.__class__, M1 = B1.__class__, M2 = B2.__class__. Then we require issubclass(M, M1) and issubclass(M, M2). (This is because a method of B1 should be able to call a meta-method defined in M1 on self.__class__, even when self is an instance of a subclass of B1.)""" If you are not getting an exception when breaking this rule, my guess would be that your metaclasses are not inheriting from 'type', or else are not invoking type's __new__ method. The logic to trigger the exception lives in type's __new__ method - if that doesn't get invoked, you won't get the exception. (Note that this also addresses your final objection: if you genuinely don't like the behaviour imposed by using 'type' as the metaclass, then don't use 'type' as the metaclass!) Cheers, Nick. [1] http://www.python.org/dev/doc/devel/ref/metaclasses.html [2] http://www.python.org/2.2/descrintro.html#metaclasses -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.skystorm.net ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Re: Change 'env var BROWSER override' semantics in webbrowser.py
On Friday 18 March 2005 17:44, Reinhold Birkenfeld wrote: > Additionally, there are several patches on SF that pertain to > webbrowser.py; perhaps you can review some of them... Given the time I haven't been able to devote to the webbrowser module, a consolidated set of reviews would be very helpful. Patch reviews should be written in the tracker, as always, and a summary of all the webbrowser-related patches in a single email to python-dev. -Fred -- Fred L. Drake, Jr. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] __metaclass__ problem
Nick Coghlan wrote: If you are not getting an exception when breaking this rule, my guess would be that your metaclasses are not inheriting from 'type', or else are not invoking type's __new__ method. The logic to trigger the exception lives in type's __new__ method - if that doesn't get invoked, you won't get the exception. OK, I actually read the bug report - I think the 'invalid metaclass' exception should also be getting thrown in the case described there. Py> class Meta1(type): pass ... Py> class Meta2(Meta1): pass ... Py> class MetaA(type): pass ... Py> class C1(object): ... __metaclass__ = Meta1 ... Py> class C2(C1): ... __metaclass__ = MetaA ... Traceback (most recent call last): File "", line 1, in ? TypeError: Error when calling the metaclass bases metaclass conflict: the metaclass of a derived class must be a (non-strict) subclass of the metaclasses of all its bases Py> class C2(C1): ... __metaclass__ = Meta2 ... Py> class C3(C2): ... __metaclass__ = Meta1 ... Py> type(C3) Py> 'Meta1' is NOT a subclass of 'Meta2', yet the exception is not thrown. Instead, the explicitly requested metaclass has been silently replaced with a subclass. I think the OP is justified in calling that 'suprising'. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.skystorm.net ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] __metaclass__ problem
At 10:11 AM 3/19/05 +1000, Nick Coghlan wrote: Nick Coghlan wrote: If you are not getting an exception when breaking this rule, my guess would be that your metaclasses are not inheriting from 'type', or else are not invoking type's __new__ method. The logic to trigger the exception lives in type's __new__ method - if that doesn't get invoked, you won't get the exception. OK, I actually read the bug report - I think the 'invalid metaclass' exception should also be getting thrown in the case described there. Py> class Meta1(type): pass ... Py> class Meta2(Meta1): pass ... Py> class MetaA(type): pass ... Py> class C1(object): ... __metaclass__ = Meta1 ... Py> class C2(C1): ... __metaclass__ = Meta2 ... Py> class C3(C2): ... __metaclass__ = Meta1 ... Py> type(C3) Py> 'Meta1' is NOT a subclass of 'Meta2', yet the exception is not thrown. Instead, the explicitly requested metaclass has been silently replaced with a subclass. I think the OP is justified in calling that 'suprising'. This is precisely the documented (in Guido's essay) behavior. That is, type.__new__ uses the "most derived" of the explicit metaclass and the __class__ attributes of the bases. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Draft PEP to make file objects support non-blocking mode.
On 18 March 2005, Donovan Baarda said: > Rationale > = > > Many Python library methods and classes like select.select(), os.popen2(), > and subprocess.Popen() return and/or operate on builtin file objects. > However even simple applications of these methods and classes require the > files to be in non-blocking mode. > > Currently the built in file type does not support non-blocking mode very > well. Setting a file into non-blocking mode and reading or writing to it > can only be done reliably by operating on the file.fileno() file descriptor. > This requires using the fnctl and os module file descriptor manipulation > methods. Is having to use fcntl and os really so awful? At least it requires the programmer to prove he knows what he's doing putting this file into non-blocking mode, and that he really wants to do it. ;-) > Details > === > > The documentation of file.read() warns; "Also note that when in non-blocking > mode, less data than what was requested may be returned, even if no size > parameter was given". An empty string is returned to indicate an EOF > condition. It is possible that file.read() in non-blocking mode will not > produce any data before EOF is reached. Currently there is no documented > way to identify the difference between reaching EOF and an empty > non-blocking read. > > The documented behaviour of file.write() in non-blocking mode is undefined. > When writing to a file in non-blocking mode, it is possible that not all of > the data gets written. Currently there is no documented way of handling or > indicating a partial write. That's more interesting and a better motivation for this PEP. > file.read([size]) Changes > -- > > The read method's current behaviour needs to be documented, so its actual > behaviour can be used to differentiate between an empty non-blocking read, > and EOF. This means recording that IOError(EAGAIN) is raised for an empty > non-blocking read. > > > file.write(str) Changes > > > The write method needs to have a useful behaviour for partial non-blocking > writes defined, implemented, and documented. This includes returning how > many bytes of "str" are successfully written, and raising IOError(EAGAIN) > for an unsuccessful write (one that failed to write anything). Proposing semantic changes to file.read() and write() is bound to raise hackles. One idea for soothing such objections: only make these changes active when setblocking(False) is in effect. I.e., a setblocking(True) file (the default, right?) behaves as you described above, warts and all. (So old code that uses fcntl() continues to "work" as before.) But files that have had setblocking(False) called could gain these new semantics that you propose. Greg -- Greg Ward <[EMAIL PROTECTED]> http://www.gerg.ca/ I just forgot my whole philosophy of life!!! ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] __metaclass__ problem
Phillip J. Eby wrote:
At 10:11 AM 3/19/05 +1000, Nick Coghlan wrote:
'Meta1' is NOT a subclass of 'Meta2', yet the exception is not thrown.
Instead, the explicitly requested metaclass has been silently replaced
with a subclass. I think the OP is justified in calling that 'suprising'.
This is precisely the documented (in Guido's essay) behavior. That is,
type.__new__ uses the "most derived" of the explicit metaclass and the
__class__ attributes of the bases.
Hmm, you're right. From Guido's essay [1]:
"""However, if one of the base metaclasses satisfies the constraint (including
the explicitly given __metaclass__, if any), the first base metaclass found
satisfying the constraint will be used as the metaclass."""
I missed this when re-reading it earlier. Unfortunately, that means an
explicitly set __metaclass__ may be ignored, if a base class has a subclass of
the explicitly supplied type as its metaclass (the exact problem the OP was
objecting to).
IOW, I was extremely surprised to learn that "('__metaclass__' in vars(C)) and
(type(C) is C.__metaclass__)" is NOT an invariant Python supports for new-style
classes (it breaks for C3 in my example).
I have no objection to the standard rule when __metaclass__ is not given, or if
it is __metaclass__ that satisifies the constraint. It's only when __metaclass__
*is* given, but doesn't meet the constraint, that I would expect an exception
rather than for Python to choose to use one of the base metaclasses instead.
Anyway, assuming Guido is happy with the status quo, it just means the above
text needs to be included when the __metaclass__ documentation is updated.
Cheers,
Nick.
[1] http://www.python.org/2.2/descrintro.html#metaclasses
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http://boredomandlaziness.skystorm.net
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Draft PEP to make file objects support non-blocking mode.
On Mar 18, 2005, at 8:19 PM, Greg Ward wrote: Is having to use fcntl and os really so awful? At least it requires the programmer to prove he knows what he's doing putting this file into non-blocking mode, and that he really wants to do it. ;-) I'd tend to agree. :) Moreover, I don't think fread/fwrite are guaranteed to work as you would expect with non-blocking file descriptors. So, providing a setblocking() call to files would require calling read/write instead of fread/fwrite in all the file methods, at least when in non-blocking mode. I don't think that's a good idea. James ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Weekly Python Patch/Bug Summary
Patch / Bug Summary ___ Patches : 286 open ( +7) / 2801 closed ( +4) / 3087 total (+11) Bugs: 870 open (+19) / 4867 closed (+14) / 5737 total (+33) RFE : 175 open ( +2) / 150 closed ( +0) / 325 total ( +2) New / Reopened Patches __ inspect.py fix for bug #1143895 (2005-03-09) CLOSED http://python.org/sf/1159931 reopened by arigo inspect.py fix for bug #1143895 (2005-03-09) CLOSED http://python.org/sf/1159931 opened by Simon Percivall use ReleaseItanium configuration for zlib IA64 build (2005-03-09) http://python.org/sf/1160164 opened by Trent Mick skip winsound for Windows/IA64 build (2005-03-09) http://python.org/sf/1160169 opened by Trent Mick Add method to function objects to simplify decoration (2005-03-12) http://python.org/sf/1161819 opened by Nick Coghlan python-config (2005-03-12) http://python.org/sf/1161914 opened by Andre Jonsson don't add -OPT:Olimit=0 for icc (2005-03-12) http://python.org/sf/1162023 opened by Michael Hoffman Heap class for heapq module (2005-03-13) http://python.org/sf/1162363 opened by Stefan Behnel EditorWindow's title with non-ASCII chars. (2005-03-14) http://python.org/sf/1162825 opened by SUZUKI Hisao _POSIX_SEMAPHORES checked incorrectly (2005-03-14) CLOSED http://python.org/sf/1163249 opened by Bob Ippolito the quotes page on the Web site links to something broken (2005-03-14) http://python.org/sf/1163314 opened by Shannon -jj Behrens small sanity checks for user-defined mros (2005-03-15) http://python.org/sf/1163731 opened by Michael Hudson Using size_t where appropriate (2005-03-18) http://python.org/sf/1166195 opened by Martin v. Löwis Patches Closed __ inspect.py fix for bug #1143895 (2005-03-09) http://python.org/sf/1159931 closed by jlgijsbers inspect.py fix for bug #1143895 (2005-03-09) http://python.org/sf/1159931 closed by jlgijsbers Syntax for iterator slicing, concatenation and repetition (2005-01-24) http://python.org/sf/1108272 closed by ncoghlan fix for a deadlock in the logging module (2005-03-07) http://python.org/sf/1158052 closed by vsajip _POSIX_SEMAPHORES checked incorrectly (2005-03-15) http://python.org/sf/1163249 closed by anthonybaxter New / Reopened Bugs ___ Setup file needs entries for collections, itertools, strop (2005-03-09) CLOSED http://python.org/sf/1160187 opened by Niraj Bajpai urllib2 post error when using httpproxy (2005-03-10) http://python.org/sf/1160328 opened by small tiger digit-only tag values are mishandled in Tkinter (2005-03-09) http://python.org/sf/1160383 opened by Ilya Sandler Autoconf failure on FreeBSD 5.3, and AC_INIT set incorrectly (2005-03-10) CLOSED http://python.org/sf/1160534 opened by Richard Brooksby Can't build Zope on Windows w/ 2.4.1c1 (2005-03-10) CLOSED http://python.org/sf/1160802 opened by Tim Peters Neverending warnings from asyncore (2005-03-11) http://python.org/sf/1161031 opened by Tony Meyer Install problem 2.4.1rc1 on Win98 (2005-03-11) CLOSED http://python.org/sf/1161187 opened by Spider Incorrect return value in gc docs (2005-03-11) CLOSED http://python.org/sf/1161476 opened by Aravind Minor error in section 3.2 (2005-03-11) http://python.org/sf/1161595 opened by Jeremy Barbay configure incorrectly adds -OPT:Olimit=0 for icc (2005-03-12) http://python.org/sf/1162001 opened by Michael Hoffman inspect.getmembers() breaks sometimes (2005-03-12) http://python.org/sf/1162154 opened by Doug Quale subprocess.Popen with copious output hangs (2005-03-13) http://python.org/sf/1162428 opened by neuhauser Parsing failures in parsedate_tz (2005-03-13) http://python.org/sf/1162477 opened by TH Unable to Install Python 2.4.1rc1 on windows XP SP2 (2005-03-13) http://python.org/sf/1162677 opened by Sergio Correia typesseq-mutable lacks note on combined key/cmp usage (2005-03-14) http://python.org/sf/1162912 opened by Stefan Behnel IDNA StreamReader broken (2005-03-14) http://python.org/sf/1163178 opened by Walter Dörwald Syntax error on large file with MBCS encoding (2005-03-14) http://python.org/sf/1163244 opened by Tim N. van der Leeuw "special" decimals aren't hashable (2005-03-14) CLOSED http://python.org/sf/1163325 opened by Marien Zwart correct/clarify documentation for super (2005-03-14) http://python.org/sf/1163367 opened by Steven Bethard uncaught AttributeError deep in urllib (2005-03-14) http://python.org/sf/1163401 opened by K Lars Lohn Sub threads execute in restricted mode (2005-03-15) http://python.org/sf/1163563 opened by anothermax subprocess pipe fails under Emacs (2005-03-15) http://python.org/sf/1163759 opened by Anders J. Munch super(
