[Python-Dev] Re: 2.3.5 delayed til next week
On Monday 17 January 2005 08:41, Anthony Baxter wrote: As I'd kinda feared, my return to work has left me completely buried this week, and so I'm going to have to push 2.3.5 until next week. Thomas and Fred: does one of the days in the range 25-27 January suit you? The 26th is a public holiday here, and so that's the day that's most likely for me... Sounds good to me. Anything in that range is equally doable. -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 bunch of Patch reviews
Irmen de Jong wrote: 3- Should the order of the chapters in the documentation be preserved? I'd rather add spwd below pwd, but this pushes the other unix modules 1 down... On Tuesday 18 January 2005 17:17, Martin v. Löwis wrote: You could make it a subsection (e.g. spwd -- shadow passwords) Not sure whether this would be supported by the processing tools; if not, inserting the module in the middle might be acceptable. I see no reason not to insert it right after pwd module docs. The order of the sections is not a backward compatibility concern. :-) -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: Moving towards Python 3.0 (was Re: [Python-Dev] Speed up functioncalls)
On Monday 31 January 2005 14:08, Glyph Lefkowitz wrote: As it stands, this idiom works most of the time, and if an EMFILE errno triggered the GC, it would always work. That might help things on Unix, but I don't think that's meaningful. Windows is much more sensitive to files being closed, and the refcount solution supports that more effectively than delayed garbage collection strategies. With the current approach, you can delete the file right away after releasing the last reference to the open file object, even on Windows. You can't do that with delayed GC since Windows will be convinced that the file is still open and refuse to let you delete it. To fix that, you'd have to trigger GC from the failed removal operation and try again. I think we'd find there are a lot more operations that need that support than we'd like to 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
[Python-Dev] Re: [Python-checkins] python/dist/src/Lib xmlrpclib.py, 1.38, 1.39
On Thursday 10 February 2005 14:09, Tim Peters wrote: Fred, is there a reason to avoid datetime.datetime's .isoformat() method here? Like so: Yes. The XML-RPC spec is quite vague. It claims that the dates are in ISO 8601 format, but doesn't say anything more about it. The example shows a string without hyphens (but with colons), so I stuck with eactly that. A possible downside is that you'll also get fractional seconds if the instance records a non-zero .microseconds value. There's nothing in the XML-RPC spec about the resolution of time, so, again, I'd rather be conservative in what we generate. -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] Re: [Python-checkins] python/dist/src/Lib xmlrpclib.py, 1.38, 1.39
On Thursday 10 February 2005 14:44, Tim Peters wrote:
Well, then since that isn't ISO 8601 format, it would be nice to have
a comment explaining why it's claiming to be anyway 0.5 wink.
Hmm, that's right (ISO 8601:2000, section 5.4.2). Sigh.
dt.replace(microsecond=0).isoformat()
suffices for that much. Tack on .replace('-', '') to do the whole job.
Yep, that would work too.
-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] Re: [Python-checkins] python/dist/src/Lib xmlrpclib.py, 1.38, 1.39
On Thursday 10 February 2005 14:44, Tim Peters wrote: Well, then since that isn't ISO 8601 format, it would be nice to have a comment explaining why it's claiming to be anyway 0.5 wink. I've posted a note on the XML-RPC list about this. There doesn't seem to be anything that describes the range of what's accepted and produced by the various XML-RPC libraries, but I've not looked hard for 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
[Python-Dev] distutils/PyPI package metadata fields
On Monday 21 March 2005 10:08, Thomas Heller wrote: I'm not sure where I should post this, but shouldn't there be a way to specify the encoding of the metadata? There are people (not me, fortunately), with umlauts in their names, for example. Agreed. I think there are a number of additional metadata fields which would be valuable, but which don't exist. Given that PEP 314 is close to being completely implemented, that's probably not the place to add them. I think a new PEP should be written to describe the new fields, and call that Metadata-Version 1.2. Some sort of Metadata-Encoding field should be included. There should also be a field for the version of Python that's required. -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] Re: python/dist/src/Lib/distutils/command upload.py, 1.3, 1.4
On Tuesday 22 March 2005 16:09, Jim Jewett wrote: Why not? I realize that version is more important for pre-compiled extension modules, but it applies even to a pure python package. Source code that uses @decoration won't work in python 1.5 This is distinct from the version of Python used to build a distribution. I've noted this as a metadata field that is needed, and plan to draft a PEP to include this and a few others. What I don't want is to conflate fields that should be separate, and end up with crufty data in PyPI. It's better to know that some data is missing than to be wrong about it. Defaulting to the version used to create the package isn't perfect, and may sometimes be too conservative -- but as a default, is it really worse than nothing? Yes, because we can't tell the difference later. For now, you can include comments in the long description or on a project web page. A proper field will be added for this in the future (hopefully not too distant). -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] Re: python/dist/src/Lib/distutils/command upload.py, 1.3, 1.4
On Tuesday 22 March 2005 18:29, Jim Jewett wrote: This is distinct from the version of Python used to build a distribution. In theory, yes. My suspicion is that if people are using the defaults, then they are probably also using a python version that they have tested with -- and perhaps the only one that they have tested with. I think this varies substantially. I routinely test cross-version code with several versions of Python. How about changing it to tack on a (guess) instead of just deleting it? But it's not a guess for non-source distributions. Or does that change break too many other things/cause too much ugliness for the timeframe it will be used in? Too much ugliness. Remember, this field is attached to the uploaded file, not the release as a whole. Many packages are going to see uploads for two or more versions of Python (PyXML for example). Getting the metadata wrong is just too evil. Now that more people have seen the code for PyPI (and understand more of it), it'll be easier to implement new fields once they've been carefully defined. -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] webbrowser.py: browser /dev/null 21
On Wednesday 23 March 2005 07:40, Oleg Broytmann wrote: While I'm working on webbrowser... Why do all graphical browsers are called with their stdout/stderr redirected to /dev/null? Do we really need to hide problems from the user? Browsers are usually silent beasts - they interact with the user using windows, not stdio. I don't remember why I did that; feel free to remove it. If it's actually useful, then 1) it should turn up before 2.5 final anyway, 2) we really want to know why, even if it just turns into a code comment, and 3) it should probably be controllable via the API, if its useful at all. -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] webbrowser.py: browser /dev/null 21
On Wednesday 23 March 2005 08:25, Rodrigo Dias Arruda Senra wrote: Under some linux distros (I'm positive for some Mdk releases), Mozilla is compiled dumping a lot of info to stdout/stderr. Since one of the goals of webbrowser is to give the end-user a stress-free experience, there goes the mentioned nullification wink. This sounds familliar. This was certainly true when Mozilla was young and I actually wrote the webbrowser module. (Or was that, when Grail was young? I don't even remember if there was a Mozilla for the first version!) In a development environment, a developer should not find difficulty to reverse that if needed. Right. I think if the API provides a control for this and some mention is made in the documentation, that would be 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] python.org crashing Mozilla?
On Tuesday 26 April 2005 16:53, Paul Dubois wrote: Three different computers running Linux / Mozilla are crashing Mozilla when directed to python.org. A Netscape works ok. Are we hacked or are we showing off? Paul, My Firefox 1.0.2 is fine. What version(s) of Mozilla, and what host platforms, would be helpful. -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] Old Python version categories in Bug Tracker
On Monday 30 May 2005 17:06, Raymond Hettinger wrote: There's no harm in having these surface. If the category is accurate, let's use it. If the bug is out of date, we can mark it as such and close it. While we can't (and shouldn't) delete categories, we can change the text used to describe them. So Python 2.2.2 can become Python 2.2.2 (unmaintained). Whether this is desirable or not, I'm not sure. -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] Old Python version categories in Bug Tracker
On Monday 30 May 2005 22:46, Josiah Carlson wrote: Pain in the rear, but it is a solution to the 'problem' of having 2.1 and 2.2 groups. The issue is really that it's not clear that this is a real problem. Unfortunate, yes, but that's it. Ideally, there'd be a way to say that certain categories/groups were marked unusable for new submissions. But that's not necessary in any way. -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 copy and clear (was Re: Inconsistent API for sets.Set and build-in set)
On Thursday 30 June 2005 17:26, Raymond Hettinger wrote: the current idiom: mylist[:] = [] # clear Unless you happen to prefer the other current idiom: del mylist[:] -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] Decimal rounding doc
On Friday 01 July 2005 08:55, Facundo Batista wrote: I'll point to there from the Money PEP, but I think this should be somewhere in the docs. I mean, as a final user, you shouldn't read a PEP or a 3rd party doc to know how to use a module. Please file a documentation bug on SF, with this link to the specific PEP section, so that we can get this fixed. Unless, of course, you have the time and inclination to finish it off yourself. :-) (I know, I've not been very helpful getting doc issues cleared up lately; I'm hoping that'll get a bit better soon.) -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] Terminology for PEP 343
On Tuesday 05 July 2005 02:57, Greg Ewing wrote: I'm thinking about something like context manager, or at least something with context in it. Oh, I like this one. Context manager / context protocol work well 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
Re: [Python-Dev] should doc string content == documentation content?
On Sunday 24 July 2005 09:34, [EMAIL PROTECTED] wrote: detailed as the full documentation? I'm inclined to think that while it might be a noble goal, it's probably not worth the effort for several reasons. All your reasons not to include all the documentation in the docstrings are good. I'll add: 5. It would be a maintenance problem keeping the two sets of docs in sync. 6. Most Python processes don't need the docs anyway. I suspect the docstrings are used primarily in the interactive interpreter and other development tools. Zope 2 is the only application that uses docstrings at runtime that I'm aware of. Given that Zope 3 abandons this, I'm not inclined to take that as a guiding example. While I can fix the isolated case of cgi.escape fairly easily, I'm not inclined to. (I will gladly do it if the sentiment is that picking off such low-hanging fruit is worthwhile.) What do other people think? The low-hanging fruit, of course, is to close the report with a 'reject' status. -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] should doc string content == documentation content?
On Sunday 24 July 2005 19:24, Martin Blais wrote: This ties well with the discussion on Doc-SIG a few months ago about manual docs vs. in-code docs. If a system could be devised to pull the docstrings into the manual (at appropriate places), the issue of syncing the docs partially goes away. Yes, it does. Avoiding the maintenance burden is a matter of having only one source for the docs, and doesn't not inform the selection of which place is best in a substantial way. A little though. -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: Migrating the Python CVS to Subversion
On Thursday 28 July 2005 20:07, Fernando Perez wrote: or something similar. It's an extra few chars, and it would give a convenient way to branch off pieces of the main code into their own subprojects in the future if needed. More interestingly, keeping it in a single repository makes it easier to merge projects, or parts of projects, together, without losing the history. This would be useful when developing packages that may be considered for the standard library, but which also need to continue separate releases to support older versions of Python. We've found it very handy to keep multiple projects in a single repository for 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] PEP: Migrating the Python CVS to Subversion
On Friday 29 July 2005 06:34, M.-A. Lemburg wrote: If SF is such a show-stopper, would it be reasonable to look for managed alternatives, such as eg. CollabNet (who funded Subversion development) ? docutils has been using berlios.de for Subversion; that might be a reasonable option. I'm not sure if there are any political issues about that, but I think everyone actively developing on that project has been happy with the move. (Only the berlios.de Subversion is being used; everything else remains at SourceForge IIRC.) -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: Migrating the Python CVS to Subversion
Martin v. Löwis wrote: So do you use project/trunk or trunk/project? If the former, I would need to get instructions on how to do the conversion from CVS. project/trunk/ On Friday 29 July 2005 02:12, Fernando Perez wrote: For ipython, which recently went through cvs2svn, I found that moving over to a project/trunk structure was a few minutes worth of work. Since svn has moving commands, it was just a matter of making the extra project/ directory and moving things one level down the hierarchy. Even if cvs2svn doesn't quite create things the way you want them in the long run, svn is flexible enough that a few manual tweaks should be quite easy to perform. Yes, this will work. I vaguely recall that Jim converted the zope.org repository one project at a time, so that made it easier to keep them separate. We didn't decommission the CVS entirely, though; Zope 2.7 is still maintained in CVS since we didn't want to risk worrying about the branch structure too much; cvs2svn still had a few issues with the complex branch structure combined with the use of symlinks within the repository (one of the reasons we were so keen to move to Subversion). I'm sure Jim can provide more details of what he had to do; I was only slightly involved in the discussions. -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: Migrating the Python CVS to Subversion
On Friday 29 July 2005 09:17, Jim Fulton wrote: 1. We were making extensive use of symbolic links to share packages among various Zope projects. This requires special care and was the main reason I wrote my own scrips. I don't expect that this would be an issue for Python. I know of three symlinks in the Python repository, all from the distutils project. There's one for the package and one for each of the documents. 2. I initially tried to conver our entire repository, including all branches. This would have taken days. I finally decided to just convert our trunk, which took several hours. The main time sink was in the load step of the conversion process. This might be a possibility for Python as well, though we have a much less complex branching structure, so the conversion may not be so difficult. -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] Pre-PEP: Exception Reorganization for Python 3.0
On Saturday 30 July 2005 22:20, Brett Cannon wrote: True, but the hierarchy should still properly reflect increasing severity in my opinion. I am going to push for this; we will see if I get pushed back enough to not do it. I have no idea what you mean by properly reflect increasing severity. Should the more severe or less severe case be derived from the other? I doubt there is a single answer that we can readily agree on. If DeprecationWarning and PendingDeprecationWarning need a class-hierarchy relationship (and I think they do; it *is* reasonable for someone to deal with them generically if they can reasonably want to deal with either), then it seems they need a common base: +--AnyDeprecationWarning +--DeprecationWarning +--PendingDeprecationWarning -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] Pre-PEP: Exception Reorganization for Python 3.0
On Sunday 31 July 2005 06:36, Willem Broekema wrote: I does not seem right to me to think of KeyboardInterrupt as a means to cause program halting. An interpreter could in principle recover from it and resume execution of the program. Somewhat. An interrupt may well not mean that the program should terminate, but may simply mean that the current operation should be stopped (as in many sorts of command interpreters). It's still *reasonable* to exit the Python interpreter if the application doesn't handle it; I can't think of any other reasonable default interpretation. (The interactive interpreter is simply an application that does handle the interrupt in an application-specific way.) So I think its reasonable to consider it a critical exception, because it's not predictable the way the control flow exceptions are; it's user-generated instead of application-generated. -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] Pre-PEP: Exception Reorganization for Python 3.0
On Sunday 31 July 2005 12:17, Brett Cannon wrote: Yeah, those explanations work for me. I think I am going to have to write an explanation for every exception so its usage is clear. That said, I agree with Phillip; a KeyboardInterrupt isn't an error, it's asynchronous user input. That makes it a child of Raisable, not Error. -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] PyTuple_Pack added references undocumented
On Sunday 07 August 2005 22:14, Guido van Rossum wrote: I think the INCREFs don't need to be documented because you don't have to worry about them -- they follow the normal pattern of reference counts: if you owned an object before passing it to PyTuple_Pack(), you still own it afterwards. That's right; the function doesn't affect the references you hold in any way, so there's no need to deal with them. It's not listed in refcounts.dat; that seems an omission (or perhaps the function's varargs signature doesn't fit in the pattern?). It should and can be listed. refcounts.dat won't deal with the varargs portion of the signature, but it can deal with the return value and normal arguments without worrying about varargs portions of the signature for any function. -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] dev listinfo page (was: Re: Python + Ping)
On Friday 12 August 2005 05:05, David Wilson wrote: Would it perhaps be an idea, given the number of users posting to the dev list, to put a rather obvious warning on the listinfo page: Well, not exactly the style you suggested, but I've made it fairly close. It's certainly more noticable now. :-) -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] Style for raising exceptions (pytho n-dev Summary for 2005-08-01 through 2005-08-15 [draft])
On Friday 26 August 2005 09:15, Michael Chermside wrote: Oh my GOD! Are you saying that in order to correctly read Python code that a programmer must know all of THAT! I would be entirely unsurprised to learn that NO ONE on this list... in fact, no one in the whole world could have reproduced that specification from memory accurately. I have never seen a more convincing argument for why we should allow only limited forms in Python 3.0. No kidding. The stuff about the tuples is particularly painful, but is specifically there to deal with string exceptions and the idiom that an exception could be defined as a tuple of exceptions. In fact, anydbm is particularly eggregious: it defines an error class derived from Exception, and then adds that to a tuple with the string exceptions from the specific modules it fronts for. The tuple handling in raise allows anydbm.error to be raised and then caught again abstractly, in addition to allow anydbm.error to act as a base exception that catches the specific errors raised by the backend databases. -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] partition() (was: Remove str.find in 3.0?)
On Tuesday 30 August 2005 11:26, Raymond Hettinger wrote: FWIW, I am VERY happy with the name partition(). I like it too. +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] Revising RE docs (was: partition() (was: Remove str.find in 3.0?))
On Tuesday 30 August 2005 17:35, Michael Chermside wrote: An excellent point. Obviously, EITHER (1) the module functions ought to be documented by reference to the RE object methods, or vice versa: (2) document the RE object methods by reference to the module functions. Agreed. I think the current arrangement is primarily a historical accident more than anything else, but I didn't write that section, so could be wrong. Does anyone else think we ought to swap that around in the documentation? I'm not trying to assign more work to Fred... but if there were a python-dev consensus that this would be desirable, then perhaps someone would be encouraged to supply a patch. I'd rather see it reversed from what it is as well. While I don't have the time myself (and don't consider it a critical issue), I certainly won't revert a patch to make the change without good reason. :-) -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 core documentation
On Tuesday 06 September 2005 16:26, Rodrigo Bernardo Pimentel wrote: I sent this to Fred Drake a few weeks ago but got no response. I assume he's busy, or maybe my message never reached him. I hope some of It did reach me, but feel into the black hole of I can't deal with this in the next 5 minutes. Sorry. I do intend to read your message carefully and respond 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] list splicing
On Monday 19 September 2005 16:36, Michael Chermside wrote: I'd just like to point out that this is a FRF (Frequently Requested Feature). I'm not arguing in favor of it, just pointing out that using star unpacking in tuple and list literals is an idea that I'm sure I've seen proposed at least a couple of times before. Indeed, star unpacking has been brought up many times; I think it would be really cool myself. (Regardless of whether it's the best use of development effort; that would be up to the contributor.) I haven't seen star packing proposed before, as best as I can recall. That's what strikes me as different in this discussion. -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] bool(iter([])) changed between 2.3 and 2.4
On Tuesday 20 September 2005 17:49, Guido van Rossum wrote: I realize that this was a deliberate feature, and that it exists in 2.4 as well as in 2.4.1 and will in 2.4.2; yet, I'm not sure I *like* I wasn't paying any attention at the time, so I don't know what was discussed. Some discussion here just now leads me to believe that at least two of us here (including myself) think iterators shouldn't have length at all: they're *not* containers and shouldn't act that way. -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] Python 2.4.2 documentation online
The Python 2.4.2 documentation is now online in the main documentation area (as opposed to just the /dev/ area) for both www.python.org and docs.python.org. The 2.4 and 2.4.1 documentation areas have been updated to link to the 2.4.2 documentation as the preferred documentation for all 2.4.x 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] Extending tuple unpacking
On Sunday 09 October 2005 22:44, Greg Ewing wrote: I'm aware of the differences, but I still see a strong similarity where this particular feature is concerned. The pattern of thinking is the same: I want to deal with the first n of these things individually, and the rest collectively. Well stated. I'm in complete agreement on this matter. -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] PythonCore\CurrentVersion
On Monday 10 October 2005 18:42, Tim Peters wrote: never before this year -- maybe sys.path _used_ to contain the current directory on Linux?). It's been a long time since this was the case on Unix of any variety; I *think* this changed to the current state back before 2.0. -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] Comparing date+time w/ just time
On Saturday 22 October 2005 07:48, [EMAIL PROTECTED] wrote: ..., I'm inclined to dump support for marshalling and comparison of time objects altogether. Do others agree that was a bad idea? Very much. As Jim notes, supporting date objects is more than a little questionable as well. Dates and times, separate from a date-time, are completely unsupported by the bare XML-RPC protocol. Applications must determine what they mean and how to encode them in XML-RPC separately if they need to do so. -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] Freezing the CVS on Oct 26 for SVN switchover
On Thursday 27 October 2005 12:07, [EMAIL PROTECTED] wrote: Send your keys to [EMAIL PROTECTED] Unless you specify otherwise, your login will probably be jim.fulton. Mail to pydotorg doesn't allow posting from non-members; I watch for notifications for owner on that list and try to approve as quickly as possible, but it's a manual process just to get the mail through. We should probably have a dedicated address for this, or tell people to send them to webmaster. -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] Freezing the CVS on Oct 26 for SVN switchover
On Thursday 27 October 2005 14:16, Martin v. Löwis wrote: I think I would request a separate address; I don't think I want to get all webmaster email. I like the idea of a separate address as well. That address should probably include webmaster, though. Are you suggesting that the key-deposit address be routed to the webmaster crew? Most of the webmasters don't have the access needed to deposit keys. -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] Conversion to Subversion is complete
On Thursday 27 October 2005 23:03, Brett Cannon wrote: I guess, but I just don't like wikis personally so I have no inclination to make the conversion. If someone wants to make the conversion over to the wiki and keep it up that's fine, but I have no problem keeping the dev FAQ updated like I have for CVS in the past. And I'm sure we all appreciate your efforts! I certainly do. Regarding using the wiki... I have mixed feelings. Wikis are really, really good for some things. Anything that's how-to based on technology (how to use SVN, CVS, etc.) seems like a reasonable candidate, because we get the advantages of peer review. For things that describe policy, I don't think that's so great. For policy (how to use SVN for Python development, because we have certain rules), I think we want to maintain strict editorial control. -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] Freezing the CVS on Oct 26 for SVN switchover
On Friday 28 October 2005 21:29, Tim Peters wrote: - Finding out what's changed in your sandbox. Use svn status for that. Bonus: in return for creating zillions of admin files, svn status is a local operation (no network access required). Do svn status -u to get, in addition, a listing of files that _would_ change if you were to do svn update. It's worth noting that svn status -u does require network access, since it has to check with the repository to see what's been updated 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] [Python-checkins] commit of r41352 - in python/trunk: . Lib Lib/distutils Lib/distutils/command Lib/encodings
On Saturday 29 October 2005 15:40, [EMAIL PROTECTED] wrote: Author: martin.v.loewis Date: Sat Oct 29 21:40:21 2005 New Revision: 41352 Modified: python/trunk/ (props changed) python/trunk/.cvsignore ... Add *.pyc to svn:ignore. Add libpython*.a to .cvsignore and svn:ignore. Shouldn't we simply remove the .cvsignore files? Subversion doesn't use them, so they'll just end up getting out of sync with the svn:ignore properties. -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] StreamHandler eating exceptions
On Sunday 30 October 2005 18:37, Gustavo Niemeyer wrote: I'd like to apply the following patch: +1 Might want to include SystemExit as well, though I think that's less likely to be seen in practice. -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] CVS repository mostly closed now
On Monday 28 November 2005 20:14, 장혜식 wrote: There's a hacky trick to remove them: put rm -rf $CVSROOT/src into CVSROOT/loginfo and remove the line then and commit again. :) Wow, that is tricky! Glad it wasn't me who thought of 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] xml package in standard library
On Tuesday 13 December 2005 18:40, A.M. Kuchling wrote: +1; it's what should have been done in the first place. If only I'd understood that when I added the xml/PyXML hack to the stdlib years ago. :-( Fixed now. I'll deal with the documentation in a few days; I actually expect to have some 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] Website cruft
On Wednesday 14 December 2005 10:12, Steve Holden wrote: However, this change highlights the fact that the checkins mailing-list description at http://mail.python.org/mailman/listinfo/python-checkins is so out of date it warns that the CVS repository on cvs.python.org should no longer be used as we have now migrated to CVS on Sourceforge :-( Try it now. -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] xml package in standard library
On Wednesday 14 December 2005 12:13, Fredrik Lundh wrote: looks like you broken installation (the libinstall target hasn't been updated); from comp.lang.python: Ouch! Thanks for fixing this. you also broke my subversion: $ svn up svn: subversion/libsvn_ra_svn/marshal.c:434: vwrite_tuple: Assertion `opt || cstr' failed. Aborted I've never seen anything like that from Subversion before. -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] ElementTree in stdlib
On Wednesday 14 December 2005 12:39, Ian Bicking wrote: I have myself in the past used or overridden non-public methods of ElementTree, which I'm sure wouldn't work with cElementTree. While I'd also prefer automatic fallback, it would be nice if there was additionally an explicit path to each version. I think the whole PyXML v. the standard library dabacle has taught us that there should *always* be an explicit path to each version of a module or package. -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] status of development documentation
[Copied to the Doc-SIG list.] On Wednesday 21 December 2005 13:02, Josiah Carlson wrote: +1 for using ReST. +0 for sticking with latex. I'll try and spend a little time on this issue this week, but time is hard to come by these days. ReST (as implemented in docutils) at this point does *not* support nested markup constructs, unless something has changed in the last few months. I think this is a significant limitation. LaTeX, for all the tool requirements, is a fairly light-weight markup language. Yes, it has too many special characters. But someone else invented it, and I'm not keen on inventing any more than we have to. There is the matter of all the semantic markup we're doing in the LaTeX sources; some people think it's fine, and others think using a specialized semantic markup is either a bad idea or at the least a barrier to contributions (though I've pointed out that contributing just plain text is fine many, many times). Alternatives to the semantic markup that I expect to see suggested include: nothing special, just using presentation markup directly: This prevents even simple information re-use. Conventions can help, but require a careful eye on the part of editors (possibly with tools to help). something like HTML, but with microformat style annotations: More reasonable, especially if we rely on conventions and stylesheets for presentation. I expect the markup will actually be much heavier than the current markup, though it will be somewhat more familiar to someone when they first look at it. Adding in the annotations changes that a bit. docbook, because others use that: This is really heavy, but tools exist. The last I looked at the OOP extensions, they were fairly simple, but not well matched to Python. ReST, possibly with additional interpreted text roles: This has been explored in the past, and would likely not be a bad approach. As noted above, I expect non-support for nested markup in docutils to be a problem that will become evident fairly quickly. All that said, I think this discussion belongs on the Doc-SIG; I've CC'd that list. -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] status of development documentation
On Thursday 22 December 2005 08:50, Michael Chermside wrote: Money is not a very effective motivator for this sort of work. (Well, in sufficient quantities it is, but the quantities required are quite large.) Offering *credit* is more effective -- a mention within a contributors list perhaps. There is a credits list for the documentation, and it's included in the HTML version of the formatted result as well. Extra credit if you know where it is without looking, though. My own favorite idea is to create a comment-on-the-docs mechanism allowing both COMMENTS, and PROPOSED EDITS. The proposed edits would need to be reviewed by one of a small number of skilled and dedicated I'm unclear on what you buy with having these two labels; are comments things that (presumably) get ignored by the documentation editor, or are the proposed edits simply more specific? If the later, I'm not sure having the labels helps. (I'm also concerned that the whole thing could end up being misused as a help desk, littering the docs with questions about application problems.) Of course, the person who REALLY gets to decide how it works isn't me; it's whoever decides to spend the time to BUILD this system. The builder certainly determines what they build, but in the longer term, whoever is using it to incorporate changes into the documentation will likely have something to say about it, since that's who determines if it actually gets used to improve the 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
[Python-Dev] LaTeX and Python doc contributions
Just a quick note based on some of the discussion on the Doc-SIG list: Some people are getting asked to convert their documentation contributions to LaTeX themselves, and that *is* a barrier to contribution. I've generally stated that I'm willing to perform conversion, making plain text / ReST completely acceptable for documentation contributions. Others have commonly converted plain text to LaTeX as well. I'd like to make sure that Python committers know that this is reasonable; if the only thing holding a contribution back is LaTeXification of documentation, feel free to assign it to me for conversion. I do not want LaTeX itself to cause us to lose documentation contributions; the hard part for documentation really is getting good content. Hard workers shouldn't be turned away. :-) -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] LaTeX and Python doc contributions
On Thursday 22 December 2005 13:39, Facundo Batista wrote: Very interesting. What I don't know here is how to submit patches... Patches certainly isn't the right word for changes not described as source diffs. I cleaned up some text about that on python.org earlier. I mean, if they were in LaTeX, a diff file would be enough. But in plain text (or ReST), how should people specify the corrections, the position of new paragraphs, etc? In English is fine. I'd expect something like: in the section on imaplib, before the paragraph starting with I often get descriptions like this when people point out typos to the docs at python.org address; it works well, and has almost no barriers to entry at all. I'm really interested in this, we've been discussing about docs in Python Argentina and some people were willing to help (and scared about LaTeX). Hopefully we can make sure it's easy for everyone to contribute. I'm certainly interested in suggestions, though I make all of them happen. -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] LaTeX and Python doc contributions
On Thursday 22 December 2005 13:23, [EMAIL PROTECTED] wrote: Who is asking this of potential contributors? I know you, Aahz and I have repeatedly told people on c.l.py that LaTeX knowledge is not necessary. Plain text is okay. What do we need to do to squash this meme? As Andrew noted, it doesn't really matter who it was. That person is now aware of what's going on, I think. :-) I've added a note to the developer's intro, and there should probably be a note in the development FAQ as well. Tony other python-dev summarizers (and maybe Cameron Laird for the c.l.py summaries): please make a note of this in your next summary. The I-can't-contribute-because-I-don't-know-LaTeX notion has to die, die, die. An excellent idea! -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] documentation comments
On Thursday 22 December 2005 13:44, Neal Norwitz wrote: I would help assuming this is easy--meaning a single click to remove a comment. It looks like the system the MySQL folks are using makes it easy, but I've not tried polluting their documentation with tests, just in case. :-) In general, my worry is less with dealing with spam than with ensuring integration of content enhancements before release candidates go out. -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] Automated Python testing (was Re: status of development documentation)
On Sunday 25 December 2005 15:23, Brett Cannon wrote: As in some machine I might personally have left on? That would require a static IP which I don't know how common that will be. But Only buildbot masters are required to have resolvable names (not necessarily static, though it helps; dynamic DNS is fine if the name propogation to the slaves is fast). The slaves do not need to be reachable from the buildbot master, since the slave is responsible for contacting the master. -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] status of development documentation
On Tuesday 27 December 2005 08:06, Fredrik Lundh wrote: the trunk link on http://www.python.org/dev/doc/ Fixed now; thanks for the reminder. -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] Naming conventions in Py3K
On Friday 30 December 2005 06:31, Ka-Ping Yee wrote: Is there a really good reason to do that? It's not obvious to me. No more than there is to rename None to none or NONE. -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] Checking in a broken test was: Re : [Python-checkins]r41940 - python/trunk/Lib/test/ test_compiler.py
On Sunday 08 January 2006 12:19, Martin v. Löwis wrote: I don't know how hard it would be, but I would also consider this appropriate. Of course, this should work on a case-by-case basis: if there are multiple test methods in a class, unexpected passes of each method should be reported. I like the way trial (from twisted) supports this. The test method is written normally, in whatever class makes sense. Then the test is marked with an attribute to say it isn't expected to pass yet. When the code is fixed and the test passes, you get that information in trial's output, and can unmark the test. This avoids having to refactor test classes just to update the status of a test. -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] ConfigParser to save with order
On Monday 09 January 2006 12:08, Facundo Batista wrote: What I wanted to add to the module was predicatibility: a very needed feature when you're writing test cases (and that's where I got bite). In that case, would sorting the keys within each section be sufficient when writing it back out? I had a class to do the really-careful editing bit like Guido described once, but lost it in a disk crash several years ago. I really wish I'd gotten that into revision control somewhere, but it's too late now. I've not needed that badly enough to re-write 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] Checking in a broken test was: Re: [Python-checkins]r41940 - python/trunk/Lib/test/test_compiler.py
Scott David Daniels wrote: Would expect_fail, expect_failure, expected_fail, or expected_failure, work for you? None of these use the same naming convention as the other unittest object attributes. Perhaps something like failureExpected? I'd definately prefer something that reads cleanly; mirroring the exact form of the word fail doesn't make sense; making it readable does. -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] r42116 - pyth on/branches/release24-maint/Lib/unittest.py
On Saturday 21 January 2006 13:37, Martin v. Löwis wrote: The registered ones: http://www.iana.org/assignments/uri-schemes I think that these should be supported. Not sure whether urn parsing would also be desirable: http://www.iana.org/assignments/urn-namespaces The hdl scheme already included in the urlparse module is a URN scheme from CNRI. Either we should support URNs, or we should consider deprecating support for that 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] Octal literals
On Tuesday 31 January 2006 14:55, Andrew Koenig wrote: Would you really want chmod(path, 0640) and chmod(path, 0640) to have different meanings? Actually, the proposal that suggested this also proposed that 0640 would raise a SyntaxError, since it was all about getting rid of octal literals. -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] Let's just *keep* lambda
On Sunday 05 February 2006 12:43, Guido van Rossum wrote: After so many attempts to come up with an alternative for lambda, perhaps we should admit defeat. I've not had the time to follow the most recent rounds, but I propose that we keep lambda, so as to stop wasting everybody's talent and time on an impossible quest. +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] http://www.python.org/dev/doc/devel still available
On Monday 13 February 2006 10:03, Georg Brandl wrote: The above docs are from August 2005 while docs.python.org/dev is current. Shouldn't the old docs be removed? I'm afraid I've generally been too busy to chime in much on this topic, but I've spent a bit of time thinking about it, and would like to keep on top of the issue still. The automatically-maintained version of the development docs is certainly preferrable to the manually-maintained-by-me version, and I've updated the link from www.python.org/doc/ to refer to that version for now. However, I do have some concerns about how this is all structured still. One of the goals of docs.python.org was to be able to do a Google site-search and only see the current version. Having multiple versions on that site is contrary to that purpose. I'd like to see the development version(s) move back to being in the www.python.org/dev/doc/ hierarchy. What I would also like to see is to have an automatically-updated version for each of the maintainer versions of Python, as well as the development trunk. That would mean two versions at this point (2.4.x, 2.5.x); only one of those is currently handled automatically. -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] http://www.python.org/dev/doc/devel still available
On Monday 13 February 2006 15:40, Guido van Rossum wrote: Shouldn't docs.python.org be removed? It seems to add mroe confusion than anything, especially since most links on python.org continue to point to python.org/doc/. docs.python.org was created specifically to make searching the most recent stable version of the docs easier (using Google's site: modifier, no less). I don't know what the link count statistics say (other than what you mention), and don't know which gets hit more often, but I still think it's a reasonable approach. I've been switching links to point to docs.python.org whenever I find an older link that points to www.python.org/doc/current/; other parts of the doc/ area from the site didn't move, and perhaps that's a problem that should be addressed. (Now that I work for Google I realize more than ever before the importance of keeping URLs stable; PageRank(tm) numbers don't get transferred as quickly as contents. I have this worry too in the context of the python.org redesign; 301 permanent redirect is *not* going to help PageRank of the new page.) Maybe I'm just not getting why that's relevant. -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 332 revival in coordination with pep 349? [ Was:Re: release plan for 2.5 ?]
On Monday 13 February 2006 21:52, Neil Schemenauer wrote: Also, I think it would useful to introduce byte array literals at the same time as the bytes object. That would allow people to use byte arrays without having to get involved with all the silly string encoding confusion. bytes([0, 1, 2, 3]) -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] bytes type discussion
On Wednesday 15 February 2006 01:44, Greg Ewing wrote: If the protocol has been sensibly designed, that shouldn't happen, since everything up to the coding marker should be ascii (or some other protocol-defined initial coding). Indeed. For protocols that are not sensibly designed (or if you're just trying to guess) what you suggest may be needed. But it would be good to have a nicer way of going about it for when the protocol is sensible. I agree in principle, but the example of using an HTML meta tag as a source of document encoding information isn't sensible. Unfortunately, it's still part of the HTML specification. :-( I'm not opposing a way to do a sensible thing, but wanted to note that it wasn't going to be right for all cases, with such an example having been mentioned already (though the issues with it had not been fully spelled out). -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
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] 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] 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] 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] 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] 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 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] 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] 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] 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] 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] 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] 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
[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] 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
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] 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] 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] 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] 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] 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] 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] 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
