Re: [Python-Dev] Add a -z interpreter flag to execute a zip file
On Saturday 14 July 2007, Andy C wrote: I don't mind calling it -z and using it for directories. But mainly that's because no one has proprosed another name. : ) I think we've agreed that -p is something totally different. We could use -r (run), or -X (execute); not sure those are really right either. while I think it would be a bad practice to import __main__, I have seen it recommended as the right place to store global (cross-module) settings. Where? People use __main__.py now? That seems bad, because __ names are reserved, so they should just use main.py, I would think. I've seen __main__ suggested as a place to store application-specific global settings, but not for a long time. I don't think it was ever mapped directly to a file on disk though. I find the idea really hackish. -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Add a -z interpreter flag to execute a zip file
On Friday 13 July 2007, Paul Moore wrote: Fair point. Doesn't it argue that there are valid uses for both -p and -z (in Python terms)? I'm not expert in Java usage, but on Windows, Indeed it does. I'd be happy for there to be a -p that allows both Windows and Unix users to prepend to sys.path. It should also be separate from the -z (or whatever that gets called). -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Add a -z interpreter flag to execute a zip file
On Friday 13 July 2007, Anders J. Munch wrote: How about .pyzip instead? To make it more obvious, and not mistakable for .py.z. I guess it would be pinheaded to call it .zippy. ;-) -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Add a -z interpreter flag to execute a zip file
At 03:52 PM 7/12/2007 -0700, Andy C wrote: So does everyone agree that there should be a new extension called .pyz? And that the definition of this is a .zip file with a __zipmain__.py module at its root? If so, I can make the change... I haven't looked around the codebase yet but it sounds easy enough. I'm not a Windows user, so don't have a good feel for the state of the extension mess on that platform these days. PYZ isn't listed on filext.com, but I don't know if that means much. On Thursday 12 July 2007, Phillip J. Eby wrote: Let's use __main__, please. Fewer names to remember, and __main__ is supposed to be the __name__ of the main program. It Just Makes SenseTM. Indeed. Let's not do something so specific it's a pain to use. Andy C: * Does anyone else want to change the -z flag to make more sense for directories (and possibly change __zipmain__.py to __main__.py)? In thinking about this again, I am not sure I can come up with a real use case. Yes. A use case for using directories, or for *not* supporting them? These cases should be as similar as possible; like Phillip suggested, we should be thinking sys.path entry rather than zip file. Phillip Eby: Testing your package before you zip it, would be one. :) My personal main interest was in being able to add an item to sys.path without having to set $PYTHONPATH on Windows. That's why I'd like it to be possible to use -z more than once (or whatever the option ends up as). What happens if multiple entries contain __main__.py entries? I don't like this one so much. I don't know what Java does if you specify -jar more than once; that might suggest something. The only competing proposal besides what I've suggested was the one to add an option to runpy, and IMO that's dead in the water due to shebang argument limits. Agreed. Andy: * Magically looking at the first argument to see if it's a zip file seems problematic to me. I'd rather be explicit with the -z flag. Likewise, I'd rather be explicit and call it __zipmain__ rather than __main__. Identifying ZIP files is straightforward; there's nothing weird about this one. -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org 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.6 BaseException.message deprecation, really needed?
On Saturday 07 July 2007, Gustavo Carneiro wrote: In PyGObject we want to use a 'message' attribute in an exception defined by us. The name 'message' comes from a C API, therefore we would like to keep it for easier mapping between C and Python APIs. Why does Python have to deprecate this attribute? It can be deprecated for BaseException without it being deprecated for your exception. You'll need to define a property that overrides the property in BaseException; something like this in Python (not tested): class MyException(Exception): _message = None @apply def message(): def get(self): return self._message def set(self, value): self._message = value return property(get, set) I think your use case is entirely reasonable, and can be handled readily. -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [RFC] urlparse - parse query facility
On Saturday 16 June 2007, O.R.Senthil Kumaran wrote: The urlparse will cotain parse_qs and parse_qsl takes the query string (not url) and with optional arguments keep_blank_values and strict_parsing (same as cgi). http://deadbeefbabe.org/paste/5154 Looks good. It may be convenient to add methods to the urlparse.BaseResult class providing access to the parsed version of the query on the instance. ... * parse_qs or parse_qsl will be invoked on the query component separately by the user. Yes; this doesn't change, really. Methods would still need to be invoked separately, but the query string doesn't need to be passed in; it's part of the data object. * If parsed query needs to be available at the instance as a convenience function, then we will have to assume the keep_blank_values and strict_parsing values. If it were a property, yes, but I think a method on the result object makes more sense because we don't want to assume values for these arguments. * Coding question: Without retyping the bunch of code again in the BaseResult, would is the possible to call parse_qs/parse_qsl function on self.query and provide the result? Basically, what would be a good of doing it. That's what I was thinking. Just add something like this to BaseResult (untested): def parsedQuery(self, keep_blank_values=False, strict_parsing=False): return parse_qs( self.query, keep_blank_values=keep_blank_values, strict_parsing=strict_parsing) def parsedQueryList(self, keep_blank_values=False, strict_parsing=False): return parse_qsl( self.query, keep_blank_values=keep_blank_values, strict_parsing=strict_parsing) Whether there's a real win with this is unclear. I generally prefer having an object that represents the URL and lets me get what I want from it, rather than having to pass the bits around to separate parsing functions. The result objects were added in 2.5, though, and I've no real idea how widely they've been adopted. -Fred -- Fred L. Drake, Jr. fdrake at acm.org Chaos is the score upon which reality is written. --Henry Miller ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [RFC] urlparse - parse query facility
On Tuesday 12 June 2007, Senthil Kumaran wrote: This mail is a request for comments on changes to urlparse module. We understand that urlparse returns the 'complete query' value as the query component and does not provide the facilities to separate the query components. User will have to use the cgi module (cgi.parse_qs) to get the query parsed. I agree with the comments Jim provided. Below method implements the urlparse_qs(url, keep_blank_values,strict_parsing) that will help in parsing the query component of the url. It behaves same as the cgi.parse_qs. Except that it takes a URL, not only a query string. def urlparse_qs(url, keep_blank_values=0, strict_parsing=0): ... scheme, netloc, url, params, querystring, fragment = urlparse(url) I see no reason to incorporate the URL splitting into the function; the existing function signatures for cgi.parse_qs and cgi.parse_qsl are sufficient. It may be convenient to add methods to the urlparse.BaseResult class providing access to the parsed version of the query on the instance. -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Minor ConfigParser Change
On Friday 01 June 2007, BJörn Lindqvist wrote: Patches are applied once, but thousands of people read the code in the standard library each month. The standard library should be as readable as possible to make it as easy as possible to maintain. It is just good software development methodology. Rest assured, I understand your sentiment here, and am not personally against an occaissional clean-up. ConfigParser in particular is old and highly idiosyncratic. Many parts of the standard library are arcane and almost impossible to understand (see httplib for example) because refactoring changes are Not done. So if someone wants to improve the code why not let them? Changes in general are a source of risk; they have to be considered carefully. We've seen too many cases in which a change was thought to be safe, but broke something for someone. Avoiding style-only changes helps avoid introducing problems without being able to predict them; there are tests for ConfigParser, but it's hard to be sure every corner case has been covered. This is a general policy in the Python project, not simply my preference. I'd love to be able to say yes, the code is painful to read, let's make it nicer, but it's hard to say that without being able to say I'm sure it won't break anything for anybody. Python's too flexible for that to be easy. -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Minor ConfigParser Change
On Saturday 26 May 2007, Joseph Armbruster wrote: I noticed that one of the parts of ConfigParser was not using for line in fp style of readline-ing :-) So, this will reduce the SLOC by 3 lines and improve readability. However, I did a quick grep and this type of practice appears in several other places. Before the current iteration support was part of Python, there was no way to iterate over a the way there is now; the code you've dug up is simply from before the current iteration support. (As I'm sure you know.) Is there motivation for these changes other than a stylistic preference for the newer idioms? Keeping the SLOC count down seems pretty minimal, and unimportant. Making the code more understandable is valuable, but it's not clear how much this really achieves that. In general, we try to avoid making style changes to the code since that can increase the maintenance burden (patches can be harder to produce that can be cleanly applied to multiple versions). Are there motivations we're missing? -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The docs, reloaded
Nick Craig-Wood wrote: ``comment'' produces smart quotes in latex if I remember correctly. You probably want to convert it somehow because it looks a bit odd on the web page as it stands. I'm not sure what the reST replacement might be, but converting it just to comment would probably be OK. Likewise with `comment' to 'comment'. For an example see the first paragraph here: http://pydoc.gbrandl.de/reference/index.html What latex does here for typeset output is nice, but it's also a bit of a hack job. The ` and ' characters aren't smart, the fonts just have curved glyphs for them. `` and '' are mapped to additional glyphs using ligatures, again part of the font information. The result, of course, is really nice. :-) Scott Dial wrote: In fairness to Georg, latex2html also misses the smart quotes. See the same paragraph here: http://docs.python.org/ref/front.html There's a way to make latex2html do the right thing for these, except... it then happily does so even to ` and '' (and `` and '') in code samples, since there's no equivalent to the font information used to handle this in latex. -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The docs, reloaded
On Tuesday 22 May 2007, Barry Warsaw wrote: considerably. Even with a nice distro packaging system it can be a PITA to get all the tools you need to build the documentation properly installed. A pure-Python solution, even a lesser one, would be a win if we can still produce top quality online and written documentation from one source. The biggest potential wins I see for a new system are: - more contributions - platform-independent processing I remain sceptical on being able to achieve the first, but there some hope for it. The later should make things easier for people who are willing to put the work into contribution, which is valuable in its own right. -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The docs, reloaded
On Tuesday 22 May 2007, Georg Brandl wrote: But that's at least funnier than before :) It's not our job to make whiner-babies sound funny. -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The docs, reloaded
On Monday 21 May 2007, [EMAIL PROTECTED] wrote: Then I submit that you are probably removing some significant piece of functionality from the provided documentation toolchain which some people probably rely on. After all, that's what LaTeX excels at. They will be able to continue to use the old tools, but where will they get them if they are no longer part of Python? I'll be happy to pull the existing tools out into a separate distribution if we move to something else for Python. There are too many users of the existing tools to abandon. -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The docs, reloaded
On Monday 21 May 2007, A.M. Kuchling wrote: Disadvantages: * reST markup isn't much simpler than LaTeX. * reST doesn't support nested markup, which is used in the current documentation. -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The docs, reloaded
On Monday 21 May 2007, [EMAIL PROTECTED] wrote: Take a look at http://www.webfast.com/modindex/. It records request counts for the various pages and presents the most frequently requested pages in a section at the top of the page. I can make the script available if anyone wants it (it uses Myghty - Mason in Python.) This is very cool. ;-) -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] \code or \constant in tex markup
On Wednesday 09 May 2007, Neal Norwitz wrote:
Which is correct?
\constant was introduced much more recently than \code (though it's not really
new anymore). The intent for \constant when it was introduced was that it be
used for names that were treated as constants in code (such as
string.ascii_letters or doctest.REPORT_NDIFF), not syntactic literals like 3
or abc.
At the time, None, True, and False were just named values in the __builtin__
module. I don't think the support for None as a real constant should
change the status of the value as just another named constant other than in
the implementation details.
So I think \constant is right for all three; we just haven't gone back and
changed all the older instances of \code{None}, \code{True}, and
\code{False}. We've generally resisted that sort of blanket change, but
consistency is valuable too. Perhaps it's time to make the change across the
board.
-Fred
--
Fred L. Drake, Jr. fdrake at acm.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Official version support statement
On Thursday 10 May 2007, Barry Warsaw wrote: This came up in a different context. I originally emailed this to the python.org admins, but Aahz rightly points out that we should first agree here that this actually /is/ our official stance. +1 -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Byte literals (was Re: [Python-checkins] Changing string constants to byte arrays ( r55119 - in python/branches/py3k-struni/Lib: codecs.py test/test_codecs.py ))
On Saturday 05 May 2007, Aahz wrote: I'm with MAL and Fred on making literals immutable -- that's safe and lots of newbies will need to use byte literals early in their Python experience if they pick up Python to operate on network data. Yes; there are lots of places where bytes literals will be used the way str literals are today. buffer(b'...') might be good enough, but it seems more than a little idiomatic, and doesn't seem particularly readable. I'm not suggesting that /all/ literals result in constants, but bytes literals seem like a case where what's wanted is the value. If b'...' results in a new object on every reference, that's a lot of overhead for a network protocol implementation, where the data is just going to be written to a socket or concatenated with other data. An immutable bytes type would be very useful as a dictionary key as well, and more space-efficient than tuple(b'...'). Whether there should be one type with a flag indicating mutability, or two separate types (as with set and frozenset), I'm not sure. The later offers some small performance benefits, but I don't expect there's enough to really matter there. -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Changing string constants to byte arr ays ([Python-checkins] r55119 - in python/branches/p y3k-struni/Lib: codecs.py test/test_codecs.py )
On Friday 04 May 2007, M.-A. Lemburg wrote: I also suggest making all bytes literals immutable to avoid running into any issues like the above. +1 from me. -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 30XZ: Simplified Parsing
On Wednesday 02 May 2007, Trent Mick wrote: raise MakeError(extracting '%s' in '%s' did not create the directory that the Python build will expect: '%s' % (src_pkg, dst_dir, dst)) I use this kind of thing frequently. Don't know if others consider it bad style. I do this too; this is a good way to have a simple human-readable message without doing weird things to about extraneous newlines or strange indentation. -1 on removing implicit string catenation. -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] minidom - new-style classes?
On Tuesday 17 April 2007 22:37, Jason Orendorff wrote: The right way to implement these quirks is using new-style classes and properties. Right now minidom uses old-style classes and lots of hackery, and it's pretty broken. (Another example--there is an Attr._set_prefix method, but it is *not* called from __setattr__.) Yes, it's truly vile. Better than it used to be, but There's also some vague attempt at supporting the Python CORBA IDL mapping, since the W3C DOM specifications use that. I expect the support is incomplete at best. Surely nobody is subclassing these classes. You don't subclass DOM interfaces--the DOM doesn't work that way. So this change should be OK. Right? There are people who've tried building new DOM implementations by subclassing the minidom classes to get most of the behavior. I'm don't know the status of any of these implementations, but changes to these classes have proved difficult due to this and the possibility of breaking pickles (amazed me, that one did!). I'd love to see a sane implementation, using new-style classes and properties, but as long as we've got to support existing applications, we're pretty well hosed as far as xml.dom.minidom is concerned. A new DOM implementation conforming to the W3C recommendations would be nice, but I'd really rather see an XML object model that doesn't suck, but that supports as much of the information found in the W3C DOM as possible. Something based more on the ElementTree API, perhaps. The value of the W3C-approved API has certainly turned out to be more decoy than anything. -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] context manager - generator interaction?
On where to write guidelines about exception handling scope: Guido wrote: This rule has no place in a pure language *reference* manual. But it certainly deserves mention in any form of more practical documentation, be it a tutorial or a more advanced programming manual. On Friday 06 April 2007 10:31, [EMAIL PROTECTED] wrote: PEP 8 anyone? New users should be exposed sooner than this; most will never read any PEP. The tutorial seems like a good place. This is general good programming practice we're talking about here, not style. -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Italic text in the manual
On Thursday 08 March 2007 08:42, Martin v. Löwis wrote: Certainly not. In today's copy (8.3.07, 13:30 GMT), this starts between 18.17 and 18.17.1. However, looking at the tex, I cannot find anything suspicious. texcheck complains about a missing ), which I added, but it only was a problem of the text, not of the markup. This doesn't seem to be a problem any more, so I'm going to presume Martin fixed it. ;-) -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Italic text in the manual
On Thursday 29 March 2007 17:48, Collin Winter wrote: The docs for atexit in py3k [1] are mostly (though not all) in italics; I can't figure out why, and I'd appreciate if anyone with stronger latex-foo could take a look. This is now fixed in Py3K, and there are no further occurrances of \em on the trunk of in Py3K. The online build will catch up when the automated build runs again. -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Has anyone been in touch with Fred Drake?
On Wednesday 28 March 2007 17:17, Martin Thomas wrote: Down here in Texas, Comcast subscribers were recently moved to Roadrunner.. changing email addresses from, for example, [EMAIL PROTECTED] to [EMAIL PROTECTED] Other parts of the country were also affected. Is it possible that Fred has been moved also? What part of the country is he in? Not to worry; I've been found. (And not in Texas, as it happens.) Comcast has a helpful feature where they save any spam you get, and count it against you. I think I've fixed the settings so they won't continue pushing that mis-feature on me. :-/ I appear to be receiving my Python lists just fine again. -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding timeout option to httplib...connect()
On Friday 09 February 2007 08:52, [EMAIL PROTECTED] wrote: In principle it's probably a fine idea. We should consider if it's possible to develop a uniform approach to timeouts for all the libraries that use sockets though. Otherwise you run the risk of doing it in different ways for different libraries and having to make a (small, but annoying) semantic leap when going from, say, httplib to smtpllib or ftplib. Agreed. In the meanwhile, there's socket.setdefaulttimeout(), which has proved quite useful. -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pydoc Improvements / Rewrite
On Friday 05 January 2007 02:49, Talin wrote: One issue that needs to be worked out, however, is the division of responsibility between markup processor and output formatter. Does a __markup__ plugin do both jobs, or does it just do parsing, and leave the formatting of output to the appropriate HTML / text output module? How does the HTML output module know how to handle non-standard metadata? There's already __docformat__; see: http://www.python.org/dev/peps/pep-0258/#choice-of-docstring-format -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Private header files (Was: Renaming Include/object.h)
On Thursday 04 January 2007 11:33, Martin v. Löwis wrote: For the python subdirectory, there is the issue that the framework includes in OSX magically look for python.framework when searching for python/foo.h, which they find, so that may get us the wrong version. Somebody would have to study the details here, first. If everything public gets included from Python.h, perhaps python/object.h and friends could become pythonX.Y/object.h; I'm not sure this will solve the Mac OS framework magic issue, though, not being a Mac OS developer. -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Renaming Include/object.h
On Wednesday 03 January 2007 11:06, Martin v. Löwis wrote: In #1626545, Anton Tropashko requests that object.h should be renamed, because it causes conflicts with other software. I would like to comply with this requests for 2.6, assuming there shouldn't be many problems with existing software as object.h shouldn't be included directly, anyway. +1 -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Renaming Include/object.h
On Wednesday 03 January 2007 12:38, Guido van Rossum wrote: Maybe this should be done in a more systematic fashion? E.g. by giving all internal header files a py_ prefix? Even better. +42 -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Renaming Include/object.h
On Wednesday 03 January 2007 14:29, Martin v. Löwis wrote: Yet another alternative would be to move all such header files into a py/ directory, so you would refer to them as #include py/object.h Any preferences? None here; the goal is the only part I care about. -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Cached Property Pattern
On Friday 29 December 2006 10:50, Oleg Broytmann wrote: I don't remember any resolution. I think submitting a small module to the patch tracker would be the simplest way to revive the discussion. We have a handful of interesting descriptors we use for Zope 3 development: http://svn.zope.org/Zope3/trunk/src/zope/cachedescriptors/ I find I use the Lazy property quite a bit in short-lived contexts (a single web request); this sounds very much like what's being described here. The readproperty is probably better when the computation isn't so expensive and the value may need to be re-computed frequently anyway. -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org 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-checkins] r53110 - python/trunk/Lib/mailbox.py
On Friday 29 December 2006 16:55, Guido van Rossum wrote: If we want to make the seek API more 21st century, why not use keyword arguments? I'd prefer that myself. I'm not advocating the constants as a way to go forward, but was simply expressing a preference for the named constant over a magic number in code. -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org 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-checkins] r53110 - pyt hon/trunk/Lib/mailbox.py
On Thursday 21 December 2006 15:23, Martin v. Löwis wrote: Now it seem that introducing them has the unfortunate side effect that people think they *have* to use them, and that doing so gives better code... Speaking strictly for myself: I don't think I *have* to use them, but I do prefer to use them because I don't like magic constants that affect what a function does in code; I'd rather have a named constant for readability's sake. Maybe I just can't keep enough in my head, but I don't find I actually use seek() enough to remember what the numeric values mean with checking the reference documentation. -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org 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 and the Linux Standard Base (LSB)
On Wednesday 29 November 2006 22:20, [EMAIL PROTECTED] wrote: GNOME et. al. aren't promoting the concept too hard. It's just the first convention I came across. (Pardon the lack of references here, but it's very hard to google for ~/.local - I just know that I was looking for a convention when I wrote combinator, and this is the one I found.) ~/.local/ is described in the XDG Base Directory Specification: http://standards.freedesktop.org/basedir-spec/latest/ On the easy_install naming front, how about layegg? Actually, why not just egg? That's parallel to rpm at least, and there isn't such a command installed on my Ubuntu box already. (Using synaptic to search for egg resulted in little that actually had egg in the name or short description; there was wnn7egg (a Wnn7 input method), but that's really it.) -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 355 status
On Wednesday 25 October 2006 13:16, Talin wrote: Never heard of it. Its not in the standard library, is it? I don't see it in the table of contents or the index. This is a documentation bug. :-( I'd thought they were mentioned *somewhere*, but it looks like I'm wrong. os.path is an alias for one of several different real modules; which is selected depends on the platform. I see the following: macpath, ntpath, os3emxpath, riscospath. (ntpath is used for all Windows versions, not just NT.) -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org 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.4 docs?
On Tuesday 24 October 2006 21:02, A.M. Kuchling wrote: Does someone need to unpack the 2.4.4 docs in the right place so that http://www.python.org/doc/2.4.4/ works? That would be me, and yes, and done. Sorry for the delay; life's just been busy lately. Time for me to go look at the release PEP again... -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] what's really new in python 2.5 ?
On Friday 06 October 2006 08:35, Gerrit Holl wrote: Isn't there a lot of useful, search-engine worthy stuff in /dev? I search for peps with google, and I suppose the 'explanation' section, as well as the developer faq and subversion instructions, are good pages that deserve to be in the google index. Should /dev really be Disallow:'ed entirely in robots.txt? As Georg noted, we've been discussing docs.python.org/dev/, which contains nightly builds of the documentation on a couple of branches. The material at www.python.org/dev/ is generally interesting, as you note, and remains open to crawlers. -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] what's really new in python 2.5 ?
On Tuesday 03 October 2006 08:56, Fredrik Lundh wrote: just noticed that the first google hit for what's new in python 2.5: http://docs.python.org/dev/whatsnew/whatsnew25.html points to a document that's a weird mix between that actual document, and a placeholder for what's new in python 2.6. I suspect Google (and all other search engines) should be warded off from docs.python.org/dev/. -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] what's really new in python 2.5 ?
On Tuesday 03 October 2006 10:30, A.M. Kuchling wrote: Neal, could you please delete all the temp files in whatever directory is used to build the documentation? I wonder if there's a *.aux file or something that still has labels from the 2.5 document. It might be easiest to just delete the whatsnew/ directory and then do an 'svn up' to get it back. I would guess this has everything to do with how the updated docs are deployed and little or nothing about the cleanliness of the working area. The mkhowto script should be cleaning out the old HTML before generating the new. I'm guessing the deployment simply unpacks the new on top of the old; the old should be removed first. For the /dev/ area, I don't think redirects are warranted. I'd rather see the crawlers just not bother with that, since those are more likely decoys than usable end-user docs. -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] what's really new in python 2.5 ?
On Tuesday 03 October 2006 14:08, A.M. Kuchling wrote: That doesn't explain it, though; the contents of whatsnew26.html contain references to pep-308.html. It's not simply a matter of new files being untarred on top of old. Ah; I missed that the new HTML file was referring to an old heading. That does sound like a .aux file got left around. I don't know what the build process is for the material in docs.python.org/dev/; I think the right thing would be to start each build with a fresh checkout/export. -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] what's really new in python 2.5 ?
On Wednesday 04 October 2006 00:32, Neal Norwitz wrote: I probably did not do that to begin with. I did rm -rf Doc svn up Doc cd Doc make. Let me know if there's anything else I should do. I did this for both the 2.5 and 2.6 versions. That certainly sounds like it should be sufficient. The doc build should never write anywhere but within the Doc/ tree; it doesn't even use the tempfile module to pick up any other temporary scratch space. -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Caching float(0.0)
On Wednesday 04 October 2006 00:53, Tim Peters wrote: Someone (Fred, I think) introduced a front-end optimization to collapse that to plain LOAD_CONST, doing the negation at compile time. I did the original change to make negative integers use just LOAD_CONST, but I don't think I changed what was generated for float literals. That could be my memory going bad, though. The code changed several times as people with more numeric-fu that myself fixed all sorts of border cases. I've tried really hard to stay away from the code generator since then. :-) -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org 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-checkins] release25-maint is UNFROZEN
On Thursday 21 September 2006 08:35, Armin Rigo wrote: Thanks for the hassle! I've got another bit of it for you, though. The freezed 2.5 documentation doesn't seem to be available on-line. At least, the doc links from the release page point to the 'dev' 2.6a0 version, and the URL following the common scheme - http://www.python.org/doc/2.5/ - doesn't work. This should mostly be working now. The page at www.python.org/doc/2.5/ isn't really right, but will do the trick. Hopefully I'll be able to work out how these pages should be updated properly at the Arlington sprint this weekend, at which point I can update PEP 101 appropriately and make sure this gets done when releases are made. -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] dict.discard
On Thursday 21 September 2006 09:42, Gustavo Niemeyer wrote:
After trying to use it a few times with no success :-), I'd like
to include a new method, dict.discard, mirroring set.discard:
print set.discard.__doc__
Remove an element from a set if it is a member.
If the element is not a member, do nothing.
Would the argument be the key, or the pair? I'd guess the key.
If so, there's the 2-arg flavor of dict.pop():
d = {}
d.pop(key, None)
It's not terribly obvious, but does the job without enlarging the dict API.
-Fred
--
Fred L. Drake, Jr. fdrake at acm.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] list.discard? (Re: dict.discard)
On Thursday 21 September 2006 20:21, Greg Ewing wrote: if x not in somelist: somelist.remove(x) I'm just guessing you really meant if x in somelist. ;-) -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: Problem withthe API for str.rpartition()
On Tuesday 05 September 2006 13:24, Michael Chermside wrote: How about something like this: S.partition(sep) - (head, sep, tail) S.rpartition(sep) - (tail, sep, rest) I think I prefer: S.partition(sep) - (head, sep, rest) S.rpartition(sep) - (tail, sep, rest) Here, rest is always used for what remains; head/tail are somewhat more clear here I think. -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: Problem withthe API for str.rpartition()
On Tuesday 05 September 2006 13:46, Raymond Hettinger wrote: Changing to left/sep/right will certainly disambiguate questions about left/right is definately not helpful. It's also ambiguous in the case of .rpartition(), where left and right in the input and result are different. the ordering of the return tuple. OTOH, there is some small loss in that the head/tail terminology is highly suggestive of how to use the function when making succesive partitions. See my previous note in this thread for another suggestion. -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: Problem withthe API for str.rpartition()
On Tuesday 05 September 2006 14:02, Jim Jewett wrote: Then shouldn't rpartition be S.rpartition(sep) - (rest, sep, tail) Whichever matches reality, sure. I've lost track of the rpartition() result order. --sigh-- Another possibility is data (for head/tail) and unparsed (for rest). S.partition(sep) - (data, sep, unparsed) S.rpartition(sep) - (unparsed, sep, data) It's all data, so I think that's too contrived. I'm not sure which is worse -- (1) distinguishing between tail and rest (2) using (overly generic) jargon like unparsed and data. I don't see the distinction between tail and rest as problematic. But I've not used lisp for a long time. Whatever the final decision, it would probably be best to add an example to the docstring. a.b.c.rpartition(.) - (a.b, ., c) Agreed. -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Py2.5 issue: decimal context manager misimplemented, misdesigned, and misdocumented
On Saturday 02 September 2006 23:58, Anthony Baxter wrote: I think this is suitable for 2.5. I'm thinking, though, that we need a second release candidate, given the number of changes since rc1. +1 -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] A test suite for unittest
On Thursday 31 August 2006 22:52, Collin Winter wrote: I've just uploaded a trio of unittest-related patches: Thanks, Collin! #1550272 (http://python.org/sf/1550272) is a test suite for the mission-critical parts of unittest. #1550273 (http://python.org/sf/1550273) fixes 6 issues uncovered while writing the test suite. Several other items that I raised earlier (http://mail.python.org/pipermail/python-dev/2006-August/068378.html) were judged to be either non-issues or behaviours that, while suboptimal, people have come to rely on. I'm hesitant to commit even tests at this point (the release candidate has already been released, and there's no plan for a second). I've not reviewed the patches. #1550263 (http://python.org/sf/1550263) follows up on an earlier patch I submitted for unittest's docs. This new patch corrects and clarifies numerous sections of the module's documentation. Anthony did approve documentation changes for 2.5, so I've committed this for 2.5 and on the trunk (2.6). These should be considered for 2.4.4 as well. (The other two may be appropriate as well.) -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Arlington VA sprint on Sept. 23
On Monday 14 August 2006 18:21, Georg Brandl wrote: * flag RFE patches as RFE (patch shouldn't be a category on its own) This is something Martin and I have disagreed over in the past. Martin has indicated that he'd rather see the patches as separate artifacts rather than as attachments to a bug report, while I'd rather see them attached to the relevant bug report or feature request. My thought is that it's easier to deal with fewer items in the tracker. Keeping the candidate patches with the bug report or feature request makes them readily accessible to a reviewer. It's not the only way. I can guess at Martin's thinking, but I'd rather let him speak for himself, since I'm not a trained channeller. ;-) -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] internal weakref API should be Py_ssize_t?
Neal Norwitz wrote: I'm wondering if the following change should be made to Include/weakrefobject.h: On Wednesday 02 August 2006 00:53, Tim Peters wrote: Yes. ... +1 on biting the bullet for 2.5. Agreed. This should definately go with the rest of the Py_ssize_t changes. -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Py2.5 release schedule
On Sunday 30 July 2006 15:44, Barry Warsaw wrote: if isinstance(obj, ClassType) or isinstance(obj, type(type)) Looks like you've got a possible name clash in the second isinstance. ;-) -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Py2.5 release schedule
On Sunday 30 July 2006 16:17, Georg Brandl wrote: The second type seems to be superfluous. ;) I was thinking it suggested there was a local named type. But if not, yeah. I get the impression Barry's pretty new to this Python thing. Wonder what he's been up to. ;-) -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Release manager pronouncement needed: PEP 302 Fix
On Friday 28 July 2006 00:49, Neal Norwitz wrote: Based on this comment, is it really acceptable to just document a behaviour change? ISTM there should really only be 2 choices: fix 2.5 properly or revert the change. This seemed to be Armin's position. I agree those are the only reasonable solutions. I'd rather see things fixed, but I don't know how much time Phillip has to work on it. I'll be working on the straigtening out the xmlcore issue tonight/tomorrow. -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] first draft of bug guidelines for www.python.org/dev/
On Friday 21 July 2006 00:10, Neil Hodgson wrote: Brett Cannon: But SourceForge does not support anonymous reporting. SourceForge does support anonymous reporting. A large proportion of the fault reports I receive for Scintilla are anonymous as indicated by nobody in the Submitted By column. SourceForge supports anonymous reporting, but the Python project determined that the management cost of anonymous reports was higher than the value they provided. It might be time to reconsider that decision (though my position hasn't changed). -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] logging module broken because of locale
On Tuesday 18 July 2006 14:52, Mihai Ibanescu wrote: Unicode might be a perfectly acceptable suggestion for others too. Are we still supporting builds that don't include Unicode? If so, that needs to be considered in a patch as well. -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Community buildbots (was Re: User's complaints)
On Thursday 13 July 2006 16:05, Barry Warsaw wrote: This really is an excellent point and makes me think that we may want to consider elaborating on the Python release cycle to include a gamma phase or a longer release candidate cycle. OT1H I think there ... absolutely no changes are allowed now unless it's to fix backward compatibility. No more sneaking in new sys functions or types module constants wink during the gamma phase. +42 It feels like the release cycle from alpha1 to final has gotten increasingly rushed. While I'm sure some of that is just me having my attention elsewhere, I suspect a longer tail on the cycle to do gammas (or release candidates, or whatever) would definately encourage more testing with applications and the larger frameworks. No, it won't catch everything, but I think it would help. -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Community buildbots (was Re: User's complaints)
On Friday 14 July 2006 00:32, [EMAIL PROTECTED] wrote: Same here. I believe there was some shortening of the 2.5 release cycle two or three months ago. I don't recall why or by how much, but I think the acceleration has resulted in a lot of the can't we please squeeze this one little change in? that's been happening. Shortening a micro release a bit seems reasonably easy to accommodate, but since minor releases occur so infrequently, I think it would be better to stretch them out if necessary. The squeezing of the releases isn't where the problem is, I think. It's that, once squeezed, more releases aren't being added to compensate. We really need to determine what time we need to go from beta1 to (gamma|rc)1, and then from (gamma|rc)1 to final. Plenty of interim releases in the beta phase is good. -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Community buildbots (was Re: User's complaints)
On Friday 14 July 2006 01:45, Fredrik Lundh wrote: I'd prefer something like 90 days. +1 -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Minor: Unix icons for 2.5?
Anthony Baxter wrote: There's an open PEP-356 issue for update the icons to the newer shinier ones for Unix. As far as I can see, there's the 14x15 GIF images used for Idle and the documentation. Note that for me at least, idle comes up without an icon _anyway_. A pyfav.(gif|png) replacement would be quite welcome! On Tuesday 11 July 2006 13:25, Georg Brandl wrote: In case we add a Python .desktop file (as proposed in patch #1353344), we'll need some PNGs in /usr/share/icons. A patch for Makefile.pre.in is attached. I know the .desktop files have become fairly standard, but are these our responsibility or does that rest with the distributions/integrators? (I'm not objecting, but I'm not sure what the right thing really is since Python is an interpreter, not a desktop application.) -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] introducing __dir__?
On Thursday 06 July 2006 13:22, tomer filiba wrote: my suggestion is simple -- replace this mechanism with a __dir__ - a special method that returns the list of attributes of the object. rationale: * remove deprecated __methods__, etc. * symmetry -- just like hex() calls __hex__, etc. * __methods__ and __members__ are lists rather than callable objects, which means they cannot be updated on-demand +1 -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Time-out in URL Open
On Monday 03 July 2006 14:07, Facundo Batista wrote: I want to know, please, if this is useful in general, for me to post a patch in SF. It seems like something that should be easy, and lots of people need to consider this for applications. -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] how long to wait for expat to incorpo rate a fix to prevent a crasher?
On Friday 30 June 2006 16:03, Martin v. Löwis wrote: If you have a patch, you should commit it to our copy. Make sure you activate the test case, so that somebody incorporating the next Expat release doesn't mistakenly roll back your change. A modified version of Brett's patch has been committed to Expat, along with regression tests for two specific cases that it handles (only one of which is relevant to Python). The patch to xmlparse.c has also been committed to Python's copy, and the crasher test has been moved to the regular xml.parsers.expat tests. Of course, you might wait a few days to see whether Fred creates another release that we could incorporate without introducing new features. I'm not ready to push for an Expat release, since I've not had much time to pay attention to that project over the past year. I'm trying to catch up on that project's email, but don't expect it to be quick. Once I've had time to discuss this with the current principal maintainer, it shouldn't be difficult to get a 2.0.1 release out the door. Once that's done, it'll be time to sync with the Expat release again. -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] document @property?
On Thursday 29 June 2006 14:31, Georg Brandl wrote: In followup to a clpy discussion, should the docs contain a note that property can be used as a decorator for creating read-only properties? I certainly wouldn't object. This is a very handy feature of property that I use frequently. -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ImportWarning flood
On Sunday 25 June 2006 20:48, Greg Ewing wrote: BTW, when that was being discussed, did anyone consider allowing a directory to be given a .py suffix as an alternative way to mark it as a package? I'd certainly be a lot happier with that than with the current behavior. Silly little warnings about perfectly good data-only directories are just silly. -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Dropping externally maintained packages (Was:Please stop changing wsgiref on the trunk)
On Monday 12 June 2006 20:42, Steve Holden wrote: Phillip J. Eby wrote: I'm sorry to contradict you, but every issue of significance is already known to be Barry's fault. And don't forget, all the issues of no significance as well. Barry's been busy! :-) -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] External Package Maintenance (was Re: Please stop changing wsgiref on the trunk)
On Monday 12 June 2006 13:42, Guido van Rossum wrote: Maybe we should get serious about slimming down the core distribution and having a separate group of people maintain sumo bundles containing Python and lots of other stuff. +1 -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] sgmllib Comments
On Monday 12 June 2006 00:05, Sam Ruby wrote: Just to be clear: Planet uses Mark's feed parser, which uses SGMLlib. Cool. I was investigating a bug in sgmllib which affected the feed parser (and therefore Planet), and noticed that there were changes in the SVN head of Python which broke three feed parser unit tests. It is my belief that these changes will break other existing users of sgmllib. This is good to know; thanks for pointing it out. If you can summarize the specific changes to sgmllib that cause problems for the feed parser, and identify the tests there that rely on the old behavior, I'll be glad to look at the problems. I expect to have some time in the next few evenings, so I should be able to look at these soon. Is the SourceForge CVS the definitive development source for the feed parser? -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.5 issues need resolving in a few days
On Saturday 10 June 2006 12:34, Fredrik Lundh wrote: if all undocumented modules had as much documentation and articles as ET, the world would be a lot better documented ;-) I've posted a text version of the xml.etree.ElementTree PythonDoc here: Here's a question that we should answer before the beta: With the introduction of the xmlcore package in Python 2.5, should we document xml.etree or xmlcore.etree? If someone installs PyXML with Python 2.5, I don't think they're going to get xml.etree, which will be really confusing. We can be sure that xmlcore.etree will be there. I'd rather not propogate the pain caused xml package insanity any further. -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.5 issues need resolving in a few days
On Friday 09 June 2006 10:28, Guido van Rossum wrote: Really? The old situation is really evil, and the new approach is at least marginally better by giving users a way to migrate to a new non-evil approach. What exactly is the backwards incompatibility you speak of? The incompatibility depends on your point of view for this one. I don't think there is any for client code; you get the old behavior for the xml package, and predictable behavior for the xmlcore package. Martin's objection is that the sources for the xmlcore package can no longer be shared with the PyXML project. I understand that he wants to reduce the cost of maintaining two trees for what's essentially the same code. I played with some ideas for making the tree more agnostic to where it really lives, but wasn't particularly successful. When I was working on that, I found that the PyXML unit tests weren't passing. I didn't have time to pursue that, though. On the whole, I'm unconvinced that there's value in continuing to worry about being able to copy the source tree between the two projects at this time. There's almost no effort going into PyXML any more, as far as I can tell. In that light, the maintenance cost seems irrelevant compared to not finally solving the fundamental problem of magic in the xml package import. I must consider the problem a nice-to-solve issue rather than a particularly important issue. All the benefit is for PyXML, and shouldn't really impact Python releases. -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] A Horrible Inconsistency
On Friday 26 May 2006 11:50, Georg Brandl wrote: This is actually a nice idea, because it's even a more nonintuitive answer for Python newbies posting to c.l.py asking how to reverse a string wink Even better: 123*-1 We'd get to explain: - what the *- operator is all about, and - why we'd use it with a string and an int. I see possibilities here. :-) -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3102: Keyword-only arguments
On Tuesday 02 May 2006 22:32, Guido van Rossum wrote: and '@deco'). Pronounced at-deck-oh, @deco is an art-deco variant favored in r-deprived regions. -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3102: Keyword-only arguments
On Sunday 30 April 2006 22:50, Edward Loper wrote: I see two possible reasons: Another use case, observed in the wild: - An library function is written to take an arbitrary number of positional arguments using *args syntax. The library is released, presumably creating dependencies on the specific signature of the function. In a subsequent version of the function, the function is determined to need additional information. The only way to add an argument is to use a keyword for which there is no positional equivalent. -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] New methods for weakref.Weak*Dictionary types
I'd like to commit this for Python 2.5: http://www.python.org/sf/1479988 The WeakKeyDictionary and WeakValueDictionary don't provide any API to get just the weakrefs out, instead of the usual mapping API. This can be desirable when you want to get a list of everything without creating new references to the underlying objects at that moment. This patch adds methods to make the references themselves accessible using the API, avoiding requiring client code to have to depend on the implementation. The WeakKeyDictionary gains the .iterkeyrefs() and .keyrefs() methods, and the WeakValueDictionary gains the .itervaluerefs() and .valuerefs() methods. The patch includes tests and docs. -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New methods for weakref.Weak*Dictionary types
On Monday 01 May 2006 16:57, Tim Peters wrote: +1. A real need for this is explained in ZODB's ZODB/util.py's WeakSet class, which contains a WeakValueDictionary: ... As that implementation suggests, though, I'm not sure there's real payback for the extra time taken in the patch's `valuerefs` implementation to weed out weakrefs whose referents are already gone: the caller has to make this check anyway when it iterates over the Good point; I've updated the patch accordingly. -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New-style icons, .desktop file
On Thursday 27 April 2006 11:57, Bill Janssen wrote: By the way, check out the new Python/Mac iconography that Jacob Rus has put together (with lots of advice from others :-), at http://hcs.harvard.edu/~jrus/python/prettified-py-icons.png. Very nice! I just might have to start using some of these modern desktops just to get all the pretty pictures. -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Dropping __init__.py requirement for subpackages
On Wednesday 26 April 2006 15:05, André Malo wrote: Another point is that one can even hide supplementary packages within such a subdirectory. It's only visible to scripts inside the dir (I admit, that the latter is not a real usecase, just a thought that came up while writing this up). I have tests that do this. This is a very real use case. -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Dropping __init__.py requirement for subpackages
On Wednesday 26 April 2006 22:42, Barry Warsaw wrote: So I suspect you're right when you say that if the rule had already been relaxed and you were now proposing to tighten the rules, we probably get just as many complaints. Indeed. I think the problem many of us have with the proposal isn't the new behavior, but the change in the behavior. That's certainly it for me. -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] GNU info version of documentation
Something's gone south in the GNU info conversion of the documentation on the trunk. If there's anyone here with time to look at it, I'd appreciate it. Unfortunately, the GNU info conversion is one of the bits I understand the least in the doc tool chain, and there's little information in the error message: $ make info cd info make EMACS=emacs WHATSNEW=whatsnew25 make[1]: Entering directory `/home/fdrake/projects/python/trunk/Doc/info' Using emacs to build the info docs EMACS=emacs ../tools/mkinfo ../lib/lib.tex python-lib.texi python-lib.info emacs -batch -q --no-site-file -l /home/fdrake/projects/python/trunk/Doc/tools/py2texi.el --eval (setq py2texi-dirs '(/home/fdrake/projects/python/trunk/Doc/lib /home/fdrake/projects/python/trunk/Doc/commontex ../texinputs)) --eval (setq py2texi-texi-file-name python-lib.texi) --eval (setq py2texi-info-file-name python-lib.info) --eval (py2texi /home/fdrake/projects/python/trunk/Doc/lib/lib.tex) -f kill-emacs Mark set Unknown environment: quote Unknown environment: quote Unknown environment: quote Unknown environment: quote Unknown environment: longtable Wrong type argument: char-or-string-p, nil make[1]: *** [python-lib.info] Error 255 make[1]: Leaving directory `/home/fdrake/projects/python/trunk/Doc/info' make: *** [info] Error 2 -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] setuptools in the stdlib
On Tuesday 18 April 2006 19:00, Phillip J. Eby wrote: He then mentioned it in his 2.5 slideshow at PyCon. This is the first anyone's objected to it, however, at least that I'm aware of. Until the past week, I wasn't aware it was being considered. But then, I've not been paying a lot of attention lately, so I suspect that's my fault. The setuptools manual is currently at: http://peak.telecommunity.com/DevCenter/setuptools pending conversion to the standard Pythondoc format. I posted earlier today asking about how it, and the other related manuals should be included in the overall Python documentation structure: Saw that; hopefully I'll have a chance to look at it soon. I wonder, generally, if it should be merged into the distutils documentation. Those documents happen to be distutils-centric now, because that's what's been provided. Their titles should be the guide to their content, however. So, I'm not too pleased by insinuations that setuptools is anything other than a Python community project. I've no doubt about that at all, FWIW. I think you've put a lot of effort into discussing it with the community, and applaud you for that as well as your implementation efforts. -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] posix_confstr seems wrong
On Monday 17 April 2006 17:39, [EMAIL PROTECTED] wrote: 1. Why is errno being set to 0? The C APIs don't promise to clear errno on input; you have to do that yourself. 2. Why is errno's value then tested to see if it's not zero? Looks like this have been that way since December 1999 when Fred added it. Looks like a bug to me. It should be set just before confstr() is called. -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New-style icons, .desktop file
On Friday 14 April 2006 06:35, Andrew Clover wrote: Files and preview here: http://doxdesk.com/img/software/py/icons2.zip http://doxdesk.com/img/software/py/icons2.png Very nice! -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] str.partition?
On Thursday 06 April 2006 18:09, Georg Brandl wrote: a while ago, Raymond proposed str.partition, and I guess the reaction was positive. So what about including it now? +1 -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Reminder: TRUNK FREEZE. 2.5a1, 00:00 UTC, Wednesday 5th of April.
On Tuesday 04 April 2006 22:34, Anthony Baxter wrote: Just a reminder - the trunk is currently frozen for 2.5a1. Please don't check anything into it until the release is done. I'll send an update when this is good. Documentation packages have been uploaded to the download area. -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Need Py3k group in trackers
On Monday 03 April 2006 14:45, Guido van Rossum wrote: Could one of the tracker admins add a Python-3000 group to the SF trackers (while we're still using them :-)? This is so we can easily move proposals between Python 3000 and Python 2.x status. Done. -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Class decorators
On Friday 31 March 2006 11:52, Phillip J. Eby wrote: class bar: @class foo def __init___(...): ... The more I think about it, the more I like the @class foo syntax. The existing syntax for functions doesn't have anything between the decorators and the def; having class decorators embedded within the class should still allow the docstring to be the first thing, so there's more distance between the decorator and the name being decorated. The extra hint about what's being decorated is nice. -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pysqlite for 2.5?
On Wednesday 29 March 2006 21:55, Greg Ewing wrote: import db where db.stdlib == True and db.language == SQL \ and db.interface == DBAPI2.0 While we're at it, we could spell import select. :-) -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Class decorators
On Tuesday 28 March 2006 22:06, Phillip J. Eby wrote: And here it is: because the use cases for class decorators are different. This is vague. I routinely use them with things that take numerous keyword arguments, but this isn't nearly as common of a scenario for function decorators. The zope.formlib decorators are commonly used with many arguments; those construct the replacements and register with a class-specific registry. Also, class decorators are far more likely to be just registering the class with something -- which means they don't deserve so prominent a location as to obscure the class itself. I've not looked at the Java and C# examples, so I don't claim anything about those examples. For all the cases where I'm registering classes, however, it's not a local registry, but something that lives elsewhere in the system; it doesn't affect the class itself at all. I'm happy for that use case to be supported in other ways than prefixing the class with decorator-syntax stuff. ObDisclaimer: this is my personal experience and opinion. Others may have different use cases in mind. I'm just pointing out that if @decorator support were added for classes, I wouldn't use it, because it's not actually an improvement over what I'm doing now. So it doesn't apply. I suspect this is something for which familiarity with the use cases for the Java and C# precedents would help. For Zope 3, we have decorators that work with the component architecture (I'm sure Phillip is familiar with these). They're used with functions to indicate that the function adapts a particular kind of object, or that it implements or provides a particular interface. We have different functions that get used for this purpose in classes that are executed within the body of the class. There's some merit to being able to use a single set of functions in both cases, since the use cases are the same. I'm not sure I'd want to change the existing pattern, though, since it's already so widespread within the Zope 3 codebase (including 3rd-party components). -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Class decorators
On Wednesday 29 March 2006 00:01, Phillip J. Eby wrote: If we're using Zope 3 as an example, I personally find that: class Foo: Docstring here, blah blah blah implements(IFoo) is easier to read than: I think the existing usage for classes is perfectly readable. The @-syntax works well for functions as well. For some reason, this doesn't bother me with functions. But then, I can't remember how often I've actually needed to use two decorators on the same function, or how many times a function decorator's arguments took multiple lines to list. For zope.formlib actions, I find there's usually only one decorator. Sometimes it fits comfortably on one line, and sometimes it takes two or three. For component architecture decorators, we find we commonly use two (zope.interface.implementer and zope.component.adapter) in tandem. This can be fairly verbose with multi-object adaptation, or really long package names. It's too bad this syntax is ambiguous: class Foo: Docstring here, blah blah blah @implements(IFoo) As this achieves a desirable highlighting of the specialness, without forcing the decorator outside the class. Oh well. Agreed, but... guess we can't have everything. On the other hand, something like: class Foo: Documentation is good. @class implements(IFoo) is not ambiguous. Hmm. It even says what it means. :-) -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Class decorators
On Wednesday 29 March 2006 00:48, Fred L. Drake, Jr. wrote: I think the existing usage for classes is perfectly readable. The @-syntax works well for functions as well. On re-reading what I wrote, I don't think I actually clarified the point I was trying to make originally. My point wasn't that I desparately need @-syntax for class decorators (I don't), or see it as inherantly superior in some way. It's much simpler than that: I just want to be able to use the same syntax for a group of use cases regardless of whether the target is a function or a class. This fits into the nice-to-have category for me, since the use case can be the same regardless of whether I'm decorating a class or a function. (I will note that when this use case applies to a function, it's usually a module-level function I'm decorating rather than a method.) My other example, the zope.formlib example, has only ever involved a single decorator, and is always a method. It could conceivably be applied to a nested class without much of a stretch, however. -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Libref sections to put new modules under?
On Monday 27 March 2006 16:26, Phillip J. Eby wrote: Any thoughts on where documentation for the new contextlib module should go in the library reference? Most definately in Python Runtime Services. A similar issue exists for ctypes module, although I imagine an argument could easily be made for putting it with Optional Operating System Services. I'm less sure of that one. It could reasonably go in Python Runtime Services, Generic Operating System Services, or Optional Operating System Services. wsgiref can probably go in Internet Protocols and Support, while ElementTree obviously goes under Structured Markup Processing Tools. Yes to both. -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org 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.5 Schedule
On Monday 20 March 2006 00:49, Anthony Baxter wrote: I'd still like to push 2.4.3rc1 out in a couple of days time, with 2.4.3 final next week, and then maybe aim for 2.5a1 a week or two later? How does that work for everyone? I should be fine to build the documentation Wednesday night (US Eastern time). -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] towards a stricter definition of sys.executable
Guido van Rossum wrote: Can you say more about the motivation for wanting this reinterpreted? Fredrik Lundh wrote: d) If Python was started from a standard Python interpreter, My understanding matches Guido's description, so I'm not sure any changes are needed. Since an embedding application can provide an alternate API to the needed information, that seems sufficient. That said, option d seems like a reasonable approach as well, and I'd have no objection to the change. I suggest the sys.application instead of sys.app_executable for the new variable, but that's minor. -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] buildbot is all green
On Sunday 19 February 2006 16:14, Benji York wrote: I replied to Walter Dörwald's suggestions and made a few changes, but don't know which I like better. If you prefer the new one at http://www.benjiyork.com/pybb you can use it as well. I like the new one better; any chance we can switch to that on buildbot.zope.org as well? ;-) The improved use of horizontal space is good. -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] buildbot is all green
On Sunday 19 February 2006 18:07, Walter Dörwald wrote: How about this one: http://styx.livinglogic.de/~walter/python/BuildBot_%20Python.html Sigh. This is nice too. Now I'm not sure which I'd rather see on zope.org. ;-) -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.5 PEP
On Thursday 16 February 2006 17:06, Martin v. Löwis wrote: I'm still unhappy with that change, and still nobody has told me how to maintain PyXML so that it can continue to work both for 2.5 and for 2.4. Martin, I do intend to write a proper response for you, but have been massively swamped. python-dev topics occaissionally pop up for me, but time has been too limited to get back to the important items, like this one. -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal: defaultdict
On Friday 17 February 2006 14:09, Guido van Rossum wrote: So here's a new proposal. I like the version you came up with. It has sufficient functionality to make it easy to use, and enough flexibility to be useful in more specialized cases. I'm quite certain it would handle all the cases I've actually dealt with where I wanted a variation of a mapping with default values. -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Counter proposal: multidict (was: Proposal: defaultdict)
On Friday 17 February 2006 14:51, Ian Bicking wrote: This all seems to be a roundabout way to address one important use case of a dictionary with multiple values for each key, I think there are use cases that do not involve multiple values per key. That is one place where this commonly comes up, but not the only one. and in the process breaking an important quality of good Python code, that attribute and getitem access not have noticeable side effects. I'm not sure that's quite as well-defined or agreed upon as you do. -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
