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.
___
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. ___ 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. ___ 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 Sense. 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. ___ 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. ___ 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. "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. ___ 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. ___ 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. ___ 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. ___ 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. ___ 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. ___ 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. ___ 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. ___ 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. ___ 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. ___ 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.
___
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. ___ 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. ___ 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.
___
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] whitespace normalization
On Wednesday 25 April 2007, Steve Holden wrote: > Duncan Booth wrote: > > That way the whitespace ought to stay normalized so you shouldn't need a > > separate cleanup step and you won't be breaking diff and blame for the > > sources (and if the reindent does ever break anything it should be more > > tracable). > > +1 +1 here as well; there's no need to let things like this get out-of-sync from what we want. -Fred -- Fred L. Drake, Jr. ___ 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. ___ 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. ___ 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. ___ 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. ___ 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. ___ 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] Integer division operator can give float result?
On Tuesday 27 February 2007 22:34, Greg Ewing wrote: > Is this intentional? I would have expected the > // operator to always give an integer result. Think "floor division", not "integer division". The result (r) may be a float, but it'll hold to the constraint: r == int(r) -Fred -- Fred L. Drake, Jr. ___ 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. ___ 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. ___ 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. ___ 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. ___ 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. ___ 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. ___ 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. ___ 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. ___ 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. ___ 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. ___ 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. ___ 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. ___ 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. ___ 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. ___ 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. ___ 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. ___ 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. ___ 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. ___ 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. ___ 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. ___ 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.
___
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.
___
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. ___ 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. ___ 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. ___ 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. ___ 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.
___
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. ___ 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. ___ 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. ___ 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. ___ 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. ___ 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. ___ 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. ___ 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. ___ 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 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. ___ 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. ___ 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. ___ 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. ___ 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. ___ 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 incorporate a fix to prevent a crasher?
On Friday 30 June 2006 14:19, Brett Cannon wrote: > The question is how long do we wait for the expat developers to patch and > do a micro release? Do we just leave this possible crasher in and just > rely entirely on the expat developers, or do we patch our copy and use > that until they get around to doing their next version push? Sigh. Too much to do all around. I'll try to take a look at this over the weekend. -Fred -- Fred L. Drake, Jr. ___ 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. ___ 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. ___ 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. ___ 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. ___ 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. ___ 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 Sunday 11 June 2006 16:26, Sam Ruby wrote:
> Planet is a feed aggregator written in Python. It depends heavily on
> SGMLLib. A recent bug report turned out to be a deficiency in sgmllib,
> and I've submitted a test case and a patch[1] (use or discard the patch,
> it is the test that I care about).
And it's a nice aggregator to use, indeed!
> While looking around, a few things surfaced. For starters, it would
> seem that the version of sgmllib in SVN HEAD will selectively unescape
> certain character references that might appear in an attribute. I say
> selectively, as:
>
> * it will unescape &
> * it won't unescape ©
> * it will unescape &
> * it won't unescape &
> * it will unescape ’
> * it won't unescape ’
And just why would you use sgmllib to handle RSS or ATOM feeds? Neither is
defined in terms of SGML. The sgmllib documentation also notes that it isn't
really a fully general SGML parser (it isn't), but that it exists primarily
as a foundation for htmllib.
> There are a number of issues here. While not unescaping anything is
> suboptimal, at least the recipient is aware of exactly which characters
> have been unescaped (i.e., none of them). The proposed solution makes
> it impossible for the recipient to know which characters are unescaped,
> and which are original. (Note: feeds often contain such abominations as
> © which the new code will treat indistinguishably from ©)
My suspicion is that the "right" thing to do at the sgmllib level is to
categorize the markup and call a method depending on what the entity
reference is, and let that handle whatever it is. For SGML, that means we
have things like &name; (entity references), { (character references),
and that's it. ģ isn't legal SGML under any circumstance;
the "&#x;" syntax was introduced with XML.
> Additionally, there is a unicode issue here - one that is shared by
> handle_charref, but at least that method is overrideable. If unescaping
> remains, do it for hex character references and for values greather than
> 8-bits, i.e., use unichr instead of chr if the value is greater than 127.
For SGML, it's worse than that, since the document character set is defined in
the SGML declaration, which is a far hairier beast than an XML
declaration. :-)
It really sounds like sgmllib is the wrong foundation for this. While the
module has some questionable behaviors, none of them are signifcant in the
context it's intended context (support for htmllib). Now, I understand that
RSS has historical issues, with HTML-as-practiced getting embedded as payload
data with various flavors of escaping applied, and I'm not an expert in the
details of that. Have you looked at HTMLParser as an alternate to sgmllib?
It has better support for XHTML constructs.
-Fred
--
Fred L. Drake, Jr.
___
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. ___ 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. ___ 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 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. ___ 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 Friday 05 May 2006 10:16, Nick Coghlan wrote: > And I imagine API designers that abused the feature would end up being > abused by their users :) If used to create poor APIs, I think that's a reasonable outcome. :-) I don't think using such a feature to constrain APIs is necessarily abuse, which is what seems to be the point of disagreement in this thread. -Fred -- Fred L. Drake, Jr. ___ 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 Friday 05 May 2006 02:38, Terry Reedy wrote: > My point has been that the function writer should not make such a > requirement (for four no-defaut, required params) and that proposing to do > so with the proposed '*' is an abuse (for public code). The caller should And what exactly is the point at which constraining use goes from unreasonable to reasonable? Perhaps that involves a judgement call? I think it does. Since we're all consenting adults, we should have the tools to make our judgements easy to apply. Since it requires specific action to make the constraint (insertion of the "*" marker), there doesn't appear to be any real issue here. -Fred -- Fred L. Drake, Jr. ___ 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. ___ 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. ___ 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. ___ 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. ___ 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. ___ 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. ___ 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. ___ 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.
___
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. ___ 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. ___ 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. ___ 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. ___ 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. ___ 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. ___ 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. ___ 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. ___ 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. ___ 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.
___
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. ___ 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. ___ 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. ___ 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
