Re: [Python-Dev] Building on OS X 10.4 fails
On Jan 18, 2006, at 8:24 AM, Stephen J. Turnbull wrote: > The import of the Ghostscript case is that the FSF considers a > Makefile stanza clearly intended to cause linkage to a GPL library, > even if optional and supplied by the user, to create a work derived > from that library. A "GNU readline"-enabled Python is derived from > GNU readline, and must be distributed under the GPL or not distributed > at all. I assume that the former is not acceptable to Python, and the > latter is clearly undesirable. In that case, what I think we ought to do is not add the DP paths (i.e. /opt/local) to setup.py specifically to get its readline, but instead to pick up any libraries that happen to be in DP in preference to those in OSX by default. If that /happens/ to cause a different version of readline to be used as a side-effect, then oops! sorry, but so be it. -Barry ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Building on OS X 10.4 fails
On Jan 21, 2006, at 11:19 AM, Barry Warsaw wrote: > In that case, what I think we ought to do is not add the DP paths > (i.e. /opt/local) to setup.py specifically to get its readline, but > instead to pick up any libraries that happen to be in DP in > preference to those in OSX by default. If that /happens/ to cause a > different version of readline to be used as a side-effect, then oops! > sorry, but so be it. This patch (currently unassigned) does the trick for me: https://sourceforge.net/tracker/index.php? func=detail&aid=1411588&group_id=5470&atid=305470 -Barry ___ Python-Dev mailing list Python-Dev@python.org 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 - python/branches/release24-maint/Lib/unittest.py
Georg Brandl wrote: > For 2.5, this would be a good opportunity to add additional schemes > to urlparse. Candidates? The registered ones: http://www.iana.org/assignments/uri-schemes Not sure whether urn parsing would also be desirable: http://www.iana.org/assignments/urn-namespaces Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org 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. ___ Python-Dev mailing list Python-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 Pythondoc by effbot
What Fredrik hacks together there (http://www.effbot.org/lib) is very impressive. I especially like the "permalinks" in this style: http://effbot.org/lib/os.path.join What I would suggest (for any new doc system) is a "split" view: on the left, the normal text, on the right, an area with only the headings, functions, example and "see also" links (which preferably stays in sight). This way, you always keep the outline in view. Of course, I wouldn't say no to a user-commenting system, but this would have to be moderated. What I'm also curious about regarding the current docs, why are optional arguments in function declarations not written in Python style? regards, Georg PS: Fredrik, if I can help you, please tell me! ___ Python-Dev mailing list Python-Dev@python.org 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 - python/branches/release24-maint/Lib/unittest.py
Fred L. Drake, Jr. wrote: > 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. That's okay, but it may be much work to find out which of them use relative paths, fragments, queries and parameters. Is there a list of these features somewhere? Georg ___ Python-Dev mailing list Python-Dev@python.org 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 - python/branches/release24-maint/Lib/unittest.py
Georg Brandl wrote: > That's okay, but it may be much work to find out which of them use relative > paths, fragments, queries and parameters. Is there a list of these features > somewhere? Not that I know of. Collecting a list of missing schemes in the file might be a good start already. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org 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 Pythondoc by effbot
On 1/21/06, Georg Brandl <[EMAIL PROTECTED]> wrote: > What Fredrik hacks together there (http://www.effbot.org/lib) is very > impressive. I especially like the "permalinks" in this style: > > http://effbot.org/lib/os.path.join Which (despite having "perma" in its name) evaporates and leaves behind a link to os.path.html#join. > What I would suggest (for any new doc system) is a "split" view: on the left, > the normal text, on the right, an area with only the headings, functions, > example and "see also" links (which preferably stays in sight). This way, you > always keep the outline in view. Can you mock that up a bit? I'm somewhat confused about what you're requesting, and also worried that it would take up too much horizontal space. (Despite that monitors are wider than tall, horizontal real estate feels more scarce than vertical, because horizontal scrolling is such a pain.) > Of course, I wouldn't say no to a user-commenting system, but this would have > to > be moderated. Why? If wikipedia can do without moderation (for most pages) then why couldn't the Python docs? > What I'm also curious about regarding the current docs, why are optional > arguments in function declarations not written in Python style? I'm assuming you're asking why we use foo(a[, b[, c]]) instead of foo(a, b=1, c=2) ? I can see several reasons; arguments with default values aren't necessarily usable keyword arguments (at least not if they function/method is implemented in C); the default value isn't always relevant (or is dynamic, or is a huge expression); and square brackets are the standard way in computer manuals to indicate optional parts of syntax. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org 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 Pythondoc by effbot
>> http://effbot.org/lib/os.path.join On this page, 8 of 30 entries have a 'new in' comment. For anyone with no interest in the past, these constitute noise. I wonder if for 3.0, the timer can be reset and the docs start clean again. To keep them backwards compatible, they would also have to be littered with 'changed in 3.0' and 'deleted in 3.0' entries. Better, I think, to refer people to the last 2.x docs and a separate 2.x/3.0 changes doc. ___ Python-Dev mailing list Python-Dev@python.org 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 Pythondoc by effbot
On 1/21/06, Terry Reedy <[EMAIL PROTECTED]> wrote: > On this page, 8 of 30 entries have a 'new in' comment. For anyone with no > interest in the past, these constitute noise. I wonder if for 3.0, the > timer can be reset and the docs start clean again. To keep them backwards > compatible, they would also have to be littered with 'changed in 3.0' and > 'deleted in 3.0' entries. Better, I think, to refer people to the last 2.x > docs and a separate 2.x/3.0 changes doc. (That has nothing to do with Fredrik's efforts of course -- he's just faithfully copying the annotations from the existing docs.) If Python 3.0 is indeed the major incompatible release that we currently expect it will be, I agree that "new in 3.0" and "new in 2.x" annotations make little sense, since so much will be "new in 3.0" (or "deleted in 3.0"). It's probably better to have a separate document explaining the differences between 2.x and 3.0. For the 2.x line, however (and again post-3.0) I think the "new in X" annotations are important -- lots of people have to deal with different Python versions, and it's a lot easier to depend on "new in X" notations than to manually compare two or more versions of the docs. (Although you still need to do thorough testing -- like the rest of the docs, these annotations can't be 100% perfect.) As far as noise goes, "new in X" is minor compared to all the stuff that's documented that the average user never needs... :-) -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org 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 - python/branches/release24-maint/Lib/unittest.py
The "data:" scheme would be a good one. Bill > Barry Warsaw wrote: > > On Fri, 2006-01-20 at 21:43 +0100, Thomas Wouters wrote: > > > >> I don't believe this belongs in 2.4, since it can, actually, break code. > >> Code that depends on the current situation, _TestCase__attributename. > >> Fragile code, to be sure, but still. If there were a compelling reason to > >> backport, I guess it could be hacked to work right-ish, but subclassing > >> TestCase in this way, while convenient, isn't important enough to warrant > >> this (IMHO). > > > > Exactly right. > > You're right. Next time I'm going to decide in favor of not backporting. > I reverted both checkins, this and the urlparse one. > > > For 2.5, this would be a good opportunity to add additional schemes > to urlparse. Candidates? > > Georg > > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/janssen%40parc.com ___ Python-Dev mailing list Python-Dev@python.org 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 Pythondoc by effbot
On Sat, Jan 21, 2006, Guido van Rossum wrote: > > Why? If wikipedia can do without moderation (for most pages) then why > couldn't the Python docs? If we're strictly talking about user comments, I won't disagree, but the main docs do need to be "authoritative" IMO. Aside to Georg: your messages are all getting /dev/null'd because you use "spam" in your From: line. I get too much spam to change that, and I'll bet other people use that heuristic. Please change your From: line for this mailing list. -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ "19. A language that doesn't affect the way you think about programming, is not worth knowing." --Alan Perlis ___ Python-Dev mailing list Python-Dev@python.org 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 Pythondoc by effbot
Guido van Rossum wrote: > On 1/21/06, Terry Reedy <[EMAIL PROTECTED]> wrote: >> On this page, 8 of 30 entries have a 'new in' comment. For anyone with no >> interest in the past, these constitute noise. I wonder if for 3.0, the >> timer can be reset and the docs start clean again. To keep them backwards >> compatible, they would also have to be littered with 'changed in 3.0' and >> 'deleted in 3.0' entries. Better, I think, to refer people to the last 2.x >> docs and a separate 2.x/3.0 changes doc. > > (That has nothing to do with Fredrik's efforts of course -- he's just > faithfully copying the annotations from the existing docs.) > > If Python 3.0 is indeed the major incompatible release that we > currently expect it will be, I agree that "new in 3.0" and "new in > 2.x" annotations make little sense, since so much will be "new in 3.0" > (or "deleted in 3.0"). It's probably better to have a separate > document explaining the differences between 2.x and 3.0. > > For the 2.x line, however (and again post-3.0) I think the "new in X" > annotations are important -- lots of people have to deal with > different Python versions, and it's a lot easier to depend on "new in > X" notations than to manually compare two or more versions of the > docs. (Although you still need to do thorough testing -- like the rest > of the docs, these annotations can't be 100% perfect.) > > As far as noise goes, "new in X" is minor compared to all the stuff > that's documented that the average user never needs... :-) And, of course, the "new in 2.x" could be formatted less space-consuming, perhaps to the right of the method name. Georg ___ Python-Dev mailing list Python-Dev@python.org 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 Pythondoc by effbot
Georg Brandl wrote: > Guido van Rossum wrote: >> As far as noise goes, "new in X" is minor compared to all the stuff >> that's documented that the average user never needs... :-) > > And, of course, the "new in 2.x" could be formatted less space-consuming, > perhaps to the right of the method name. That makes it worse by giving the information a prominence it doesn't really deserve. It also doesn't help when the change being noted was a signature or semantics change, rather than the addition of the function. As with many other things, being able to clean out some of this history will be one of the benefits of Py3k. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.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 Pythondoc by effbot
Aahz wrote: > On Sat, Jan 21, 2006, Guido van Rossum wrote: >> >> Why? If wikipedia can do without moderation (for most pages) then why >> couldn't the Python docs? > > If we're strictly talking about user comments, I won't disagree, but the > main docs do need to be "authoritative" IMO. > > Aside to Georg: your messages are all getting /dev/null'd because you use > "spam" in your From: line. I get too much spam to change that, and I'll > bet other people use that heuristic. Please change your From: line for > this mailing list. I don't quite understand that. Why would a spam email have "spam" in the From? For me, the "-nospam" suffix works relatively good to avoid spam, as most harvesting programs will think this is a false address. Of course, that may be more useful in Usenet, not in mailing lists. Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
