Re: [Python-Dev] Minor: Unix icons for 2.5?
Anthony Baxter wrote: > There's an open PEP-356 issue for "update the icons to the newer > shinier ones" for Unix. As far as I can see, there's the 14x15 GIF > images used for Idle and the documentation. Note that for me at least, > idle comes up without an icon _anyway_. A pyfav.(gif|png) replacement would be quite welcome! On Tuesday 11 July 2006 13:25, Georg Brandl wrote: > In case we add a Python .desktop file (as proposed in patch #1353344), > we'll need some PNGs in /usr/share/icons. A patch for Makefile.pre.in > is attached. I know the .desktop files have become fairly standard, but are these our responsibility or does that rest with the distributions/integrators? (I'm not objecting, but I'm not sure what the right thing really is since Python is an interpreter, not a desktop application.) -Fred -- Fred L. Drake, Jr. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Community buildbots (was Re: User's complaints)
On Thursday 13 July 2006 16:05, Barry Warsaw wrote: > This really is an excellent point and makes me think that we may want > to consider elaborating on the Python release cycle to include a > gamma phase or a longer release candidate cycle. OT1H I think there ... > "absolutely no changes are allowed now unless it's to fix backward > compatibility". No more sneaking in new sys functions or types > module constants during the gamma phase. +42 It feels like the release cycle from alpha1 to final has gotten increasingly rushed. While I'm sure some of that is just me having my attention elsewhere, I suspect a longer tail on the cycle to do gammas (or release candidates, or whatever) would definately encourage more testing with applications and the larger frameworks. No, it won't catch everything, but I think it would help. -Fred -- Fred L. Drake, Jr. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Community buildbots (was Re: User's complaints)
On Friday 14 July 2006 00:32, [EMAIL PROTECTED] wrote: > Same here. I believe there was some shortening of the 2.5 release cycle > two or three months ago. I don't recall why or by how much, but I think > the acceleration has resulted in a lot of the "can't we please squeeze > this one little change in?" that's been happening. Shortening a micro > release a bit seems reasonably easy to accommodate, but since minor > releases occur so infrequently, I think it would be better to stretch them > out if necessary. The squeezing of the releases isn't where the problem is, I think. It's that, once squeezed, more releases aren't being added to compensate. We really need to determine what time we need to go from beta1 to (gamma|rc)1, and then from (gamma|rc)1 to final. Plenty of interim releases in the beta phase is good. -Fred -- Fred L. Drake, Jr. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Community buildbots (was Re: User's complaints)
On Friday 14 July 2006 01:45, Fredrik Lundh wrote: > I'd prefer something like 90 days. +1 -Fred -- Fred L. Drake, Jr. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] logging module broken because of locale
On Tuesday 18 July 2006 14:52, Mihai Ibanescu wrote: > Unicode might be a perfectly acceptable suggestion for others too. Are we still supporting builds that don't include Unicode? If so, that needs to be considered in a patch as well. -Fred -- Fred L. Drake, Jr. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] first draft of bug guidelines for www.python.org/dev/
On Friday 21 July 2006 00:10, Neil Hodgson wrote: > Brett Cannon: > > But SourceForge does not support anonymous reporting. > >SourceForge does support anonymous reporting. A large proportion of > the fault reports I receive for Scintilla are anonymous as indicated > by "nobody" in the "Submitted By" column. SourceForge supports anonymous reporting, but the Python project determined that the management cost of anonymous reports was higher than the value they provided. It might be time to reconsider that decision (though my position hasn't changed). -Fred -- Fred L. Drake, Jr. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Release manager pronouncement needed: PEP 302 Fix
On Friday 28 July 2006 00:49, Neal Norwitz wrote: > Based on this comment, is it really acceptable to just document a > behaviour change? ISTM there should really only be 2 choices: fix > 2.5 properly or revert the change. This seemed to be Armin's > position. I agree those are the only reasonable solutions. I'd rather see things fixed, but I don't know how much time Phillip has to work on it. I'll be working on the straigtening out the xmlcore issue tonight/tomorrow. -Fred -- Fred L. Drake, Jr. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Py2.5 release schedule
On Sunday 30 July 2006 15:44, Barry Warsaw wrote: > if isinstance(obj, ClassType) or isinstance(obj, type(type)) Looks like you've got a possible name clash in the second isinstance. ;-) -Fred -- Fred L. Drake, Jr. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Py2.5 release schedule
On Sunday 30 July 2006 16:17, Georg Brandl wrote: > The second "type" seems to be superfluous. ;) I was thinking it suggested there was a local named "type". But if not, yeah. I get the impression Barry's pretty new to this "Python thing." Wonder what he's been up to. ;-) -Fred -- Fred L. Drake, Jr. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] internal weakref API should be Py_ssize_t?
Neal Norwitz wrote: > I'm wondering if the following change should be made to > Include/weakrefobject.h: On Wednesday 02 August 2006 00:53, Tim Peters wrote: > Yes. ... > +1 on biting the bullet for 2.5. Agreed. This should definately go with the rest of the Py_ssize_t changes. -Fred -- Fred L. Drake, Jr. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Arlington VA sprint on Sept. 23
On Monday 14 August 2006 18:21, Georg Brandl wrote:
> * flag RFE patches as RFE ("patch" shouldn't be a category on its own)
This is something Martin and I have disagreed over in the past. Martin has
indicated that he'd rather see the patches as separate artifacts rather than
as attachments to a bug report, while I'd rather see them attached to the
relevant bug report or feature request.
My thought is that it's easier to deal with fewer items in the tracker.
Keeping the candidate patches with the bug report or feature request makes
them readily accessible to a reviewer. It's not the only way.
I can guess at Martin's thinking, but I'd rather let him speak for himself,
since I'm not a trained channeller. ;-)
-Fred
--
Fred L. Drake, Jr.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] A test suite for unittest
On Thursday 31 August 2006 22:52, Collin Winter wrote: > I've just uploaded a trio of unittest-related patches: Thanks, Collin! > #1550272 (http://python.org/sf/1550272) is a test suite for the > mission-critical parts of unittest. > > #1550273 (http://python.org/sf/1550273) fixes 6 issues uncovered while > writing the test suite. Several other items that I raised earlier > (http://mail.python.org/pipermail/python-dev/2006-August/068378.html) > were judged to be either non-issues or behaviours that, while > suboptimal, people have come to rely on. I'm hesitant to commit even tests at this point (the release candidate has already been released, and there's no plan for a second). I've not reviewed the patches. > #1550263 (http://python.org/sf/1550263) follows up on an earlier patch > I submitted for unittest's docs. This new patch corrects and clarifies > numerous sections of the module's documentation. Anthony did approve documentation changes for 2.5, so I've committed this for 2.5 and on the trunk (2.6). These should be considered for 2.4.4 as well. (The other two may be appropriate as well.) -Fred -- Fred L. Drake, Jr. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Py2.5 issue: decimal context manager misimplemented, misdesigned, and misdocumented
On Saturday 02 September 2006 23:58, Anthony Baxter wrote: > I think this is suitable for 2.5. I'm thinking, though, that we need a > second release candidate, given the number of changes since rc1. +1 -Fred -- Fred L. Drake, Jr. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: Problem withthe API for str.rpartition()
On Tuesday 05 September 2006 13:24, Michael Chermside wrote: > How about something like this: > > S.partition(sep) -> (head, sep, tail) > S.rpartition(sep) -> (tail, sep, rest) I think I prefer: S.partition(sep) -> (head, sep, rest) S.rpartition(sep) -> (tail, sep, rest) Here, "rest" is always used for "what remains"; head/tail are somewhat more clear here I think. -Fred -- Fred L. Drake, Jr. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: Problem withthe API for str.rpartition()
On Tuesday 05 September 2006 13:46, Raymond Hettinger wrote: > Changing to left/sep/right will certainly disambiguate questions about left/right is definately not helpful. It's also ambiguous in the case of .rpartition(), where left and right in the input and result are different. > the ordering of the return tuple. OTOH, there is some small loss in > that the head/tail terminology is highly suggestive of how to use the > function when making succesive partitions. See my previous note in this thread for another suggestion. -Fred -- Fred L. Drake, Jr. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: Problem withthe API for str.rpartition()
On Tuesday 05 September 2006 14:02, Jim Jewett wrote:
> Then shouldn't rpartition be S.rpartition(sep) -> (rest, sep, tail)
Whichever matches reality, sure. I've lost track of the rpartition() result
order. --sigh--
> Another possibility is data (for head/tail) and unparsed (for rest).
>
> S.partition(sep) -> (data, sep, unparsed)
> S.rpartition(sep) -> (unparsed, sep, data)
It's all data, so I think that's too contrived.
> I'm not sure which is worse --
> (1) distinguishing between tail and rest
> (2) using (overly generic) jargon like unparsed and data.
I don't see the distinction between tail and rest as problematic. But I've
not used lisp for a long time.
> Whatever the final decision, it would probably be best to add an
> example to the docstring. "a.b.c".rpartition(".") -> ("a.b", ".",
> "c")
Agreed.
-Fred
--
Fred L. Drake, Jr.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] dict.discard
On Thursday 21 September 2006 09:42, Gustavo Niemeyer wrote:
> After trying to use it a few times with no success :-), I'd like
>
> to include a new method, dict.discard, mirroring set.discard:
> >>> print set.discard.__doc__
>
> Remove an element from a set if it is a member.
>
> If the element is not a member, do nothing.
Would the argument be the key, or the pair? I'd guess the key.
If so, there's the 2-arg flavor of dict.pop():
>>> d = {}
>>> d.pop("key", None)
It's not terribly obvious, but does the job without enlarging the dict API.
-Fred
--
Fred L. Drake, Jr.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] list.discard? (Re: dict.discard)
On Thursday 21 September 2006 20:21, Greg Ewing wrote: >if x not in somelist: > somelist.remove(x) I'm just guessing you really meant "if x in somelist". ;-) -Fred -- Fred L. Drake, Jr. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] release25-maint is UNFROZEN
On Thursday 21 September 2006 08:35, Armin Rigo wrote: > Thanks for the hassle! I've got another bit of it for you, though. The > freezed 2.5 documentation doesn't seem to be available on-line. At > least, the doc links from the release page point to the 'dev' 2.6a0 > version, and the URL following the common scheme - > http://www.python.org/doc/2.5/ - doesn't work. This should mostly be working now. The page at www.python.org/doc/2.5/ isn't "really" right, but will do the trick. Hopefully I'll be able to work out how these pages should be updated properly at the Arlington sprint this weekend, at which point I can update PEP 101 appropriately and make sure this gets done when releases are made. -Fred -- Fred L. Drake, Jr. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] what's really new in python 2.5 ?
On Tuesday 03 October 2006 08:56, Fredrik Lundh wrote: > just noticed that the first google hit for "what's new in python 2.5": > > http://docs.python.org/dev/whatsnew/whatsnew25.html > > points to a document that's a weird mix between that actual document, and > a placeholder for "what's new in python 2.6". I suspect Google (and all other search engines) should be warded off from docs.python.org/dev/. -Fred -- Fred L. Drake, Jr. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] what's really new in python 2.5 ?
On Tuesday 03 October 2006 10:30, A.M. Kuchling wrote: > Neal, could you please delete all the temp files in whatever directory > is used to build the documentation? I wonder if there's a *.aux file > or something that still has labels from the 2.5 document. It might be > easiest to just delete the whatsnew/ directory and then do an 'svn up' > to get it back. I would guess this has everything to do with how the updated docs are deployed and little or nothing about the cleanliness of the working area. The mkhowto script should be cleaning out the old HTML before generating the new. I'm guessing the deployment simply unpacks the new on top of the old; the old should be removed first. For the /dev/ area, I don't think redirects are warranted. I'd rather see the crawlers just not bother with that, since those are more likely decoys than usable end-user docs. -Fred -- Fred L. Drake, Jr. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] what's really new in python 2.5 ?
On Tuesday 03 October 2006 14:08, A.M. Kuchling wrote: > That doesn't explain it, though; the contents of whatsnew26.html > contain references to pep-308.html. It's not simply a matter of new > files being untarred on top of old. Ah; I missed that the new HTML file was referring to an old heading. That does sound like a .aux file got left around. I don't know what the build process is for the material in docs.python.org/dev/; I think the right thing would be to start each build with a fresh checkout/export. -Fred -- Fred L. Drake, Jr. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] what's really new in python 2.5 ?
On Wednesday 04 October 2006 00:32, Neal Norwitz wrote: > I probably did not do that to begin with. I did rm -rf Doc && svn up > Doc && cd Doc && make. Let me know if there's anything else I should > do. I did this for both the 2.5 and 2.6 versions. That certainly sounds like it should be sufficient. The doc build should never write anywhere but within the Doc/ tree; it doesn't even use the tempfile module to pick up any other temporary scratch space. -Fred -- Fred L. Drake, Jr. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Caching float(0.0)
On Wednesday 04 October 2006 00:53, Tim Peters wrote: > Someone (Fred, I think) introduced a front-end optimization to > collapse that to plain LOAD_CONST, doing the negation at compile time. I did the original change to make negative integers use just LOAD_CONST, but I don't think I changed what was generated for float literals. That could be my memory going bad, though. The code changed several times as people with more numeric-fu that myself fixed all sorts of border cases. I've tried really hard to stay away from the code generator since then. :-) -Fred -- Fred L. Drake, Jr. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] what's really new in python 2.5 ?
On Friday 06 October 2006 08:35, Gerrit Holl wrote: > Isn't there a lot of useful, search-engine worthy stuff in /dev? > I search for peps with google, and I suppose the 'explanation' section, > as well as the developer faq and subversion instructions, are good pages > that deserve to be in the google index. Should /dev really be > Disallow:'ed entirely in robots.txt? As Georg noted, we've been discussing docs.python.org/dev/, which contains nightly builds of the documentation on a couple of branches. The material at www.python.org/dev/ is generally interesting, as you note, and remains open to crawlers. -Fred -- Fred L. Drake, Jr. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.4.4 docs?
On Tuesday 24 October 2006 21:02, A.M. Kuchling wrote: > Does someone need to unpack the 2.4.4 docs in the right place so that > http://www.python.org/doc/2.4.4/ works? That would be me, and yes, and done. Sorry for the delay; life's just been busy lately. Time for me to go look at the release PEP again... -Fred -- Fred L. Drake, Jr. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 355 status
On Wednesday 25 October 2006 13:16, Talin wrote: > Never heard of it. Its not in the standard library, is it? I don't see > it in the table of contents or the index. This is a documentation bug. :-( I'd thought they were mentioned *somewhere*, but it looks like I'm wrong. os.path is an alias for one of several different real modules; which is selected depends on the platform. I see the following: macpath, ntpath, os3emxpath, riscospath. (ntpath is used for all Windows versions, not just NT.) -Fred -- Fred L. Drake, Jr. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python and the Linux Standard Base (LSB)
On Wednesday 29 November 2006 22:20, [EMAIL PROTECTED] wrote: > GNOME et. al. aren't promoting the concept too hard. It's just the first > convention I came across. (Pardon the lack of references here, but it's > very hard to google for "~/.local" - I just know that I was looking for a > convention when I wrote combinator, and this is the one I found.) ~/.local/ is described in the "XDG Base Directory Specification": http://standards.freedesktop.org/basedir-spec/latest/ > On the "easy_install" naming front, how about "layegg"? Actually, why not just "egg"? That's parallel to "rpm" at least, and there isn't such a command installed on my Ubuntu box already. (Using synaptic to search for "egg" resulted in little that actually had "egg" in the name or short description; there was wnn7egg (a Wnn7 input method), but that's really it.) -Fred -- Fred L. Drake, Jr. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r53110 - pyt hon/trunk/Lib/mailbox.py
On Thursday 21 December 2006 15:23, Martin v. Löwis wrote: > Now it seem that introducing them has the unfortunate side effect > that people think they *have* to use them, and that doing so gives > better code... Speaking strictly for myself: I don't think I *have* to use them, but I do prefer to use them because I don't like magic constants that affect what a function does in code; I'd rather have a named constant for readability's sake. Maybe I just can't keep enough in my head, but I don't find I actually use seek() enough to remember what the numeric values mean with checking the reference documentation. -Fred -- Fred L. Drake, Jr. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Cached Property Pattern
On Friday 29 December 2006 10:50, Oleg Broytmann wrote: >I don't remember any resolution. I think submitting a small module to > the patch tracker would be the simplest way to revive the discussion. We have a handful of interesting descriptors we use for Zope 3 development: http://svn.zope.org/Zope3/trunk/src/zope/cachedescriptors/ I find I use the Lazy property quite a bit in short-lived contexts (a single web request); this sounds very much like what's being described here. The readproperty is probably better when the computation isn't so expensive and the value may need to be re-computed frequently anyway. -Fred -- Fred L. Drake, Jr. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r53110 - python/trunk/Lib/mailbox.py
On Friday 29 December 2006 16:55, Guido van Rossum wrote: > If we want to make the seek API more 21st century, why not use keyword > arguments? I'd prefer that myself. I'm not advocating the constants as a way to go forward, but was simply expressing a preference for the named constant over a magic number in code. -Fred -- Fred L. Drake, Jr. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Renaming Include/object.h
On Wednesday 03 January 2007 11:06, Martin v. Löwis wrote: > In #1626545, Anton Tropashko requests that object.h should be > renamed, because it causes conflicts with other software. > > I would like to comply with this requests for 2.6, assuming there > shouldn't be many problems with existing software as object.h > shouldn't be included directly, anyway. +1 -Fred -- Fred L. Drake, Jr. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Renaming Include/object.h
On Wednesday 03 January 2007 12:38, Guido van Rossum wrote: > Maybe this should be done in a more systematic fashion? E.g. by giving > all "internal" header files a "py_" prefix? Even better. +42 -Fred -- Fred L. Drake, Jr. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Renaming Include/object.h
On Wednesday 03 January 2007 14:29, Martin v. Löwis wrote: > Yet another alternative would be to move all such header files into a > py/ directory, so you would refer to them as > > #include "py/object.h" > > Any preferences? None here; the goal is the only part I care about. -Fred -- Fred L. Drake, Jr. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Private header files (Was: Renaming Include/object.h)
On Thursday 04 January 2007 11:33, Martin v. Löwis wrote: > For the python subdirectory, there is the issue that the framework > includes in OSX magically look for python.framework when searching for > python/foo.h, which they find, so that may get us the wrong version. > Somebody would have to study the details here, first. If everything public gets included from Python.h, perhaps python/object.h and friends could become pythonX.Y/object.h; I'm not sure this will solve the Mac OS framework magic issue, though, not being a Mac OS developer. -Fred -- Fred L. Drake, Jr. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pydoc Improvements / Rewrite
On Friday 05 January 2007 02:49, Talin wrote: > One issue that needs to be worked out, however, is the division of > responsibility between markup processor and output formatter. Does a > __markup__ plugin do both jobs, or does it just do parsing, and leave > the formatting of output to the appropriate HTML / text output module? > How does the HTML output module know how to handle non-standard metadata? There's already __docformat__; see: http://www.python.org/dev/peps/pep-0258/#choice-of-docstring-format -Fred -- Fred L. Drake, Jr. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding timeout option to httplib...connect()
On Friday 09 February 2007 08:52, [EMAIL PROTECTED] wrote: > In principle it's probably a fine idea. We should consider if it's > possible to develop a uniform approach to timeouts for all the libraries > that use sockets though. Otherwise you run the risk of doing it in > different ways for different libraries and having to make a (small, but > annoying) semantic leap when going from, say, httplib to smtpllib or > ftplib. Agreed. In the meanwhile, there's socket.setdefaulttimeout(), which has proved quite useful. -Fred -- Fred L. Drake, Jr. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Integer division operator can give float result?
On Tuesday 27 February 2007 22:34, Greg Ewing wrote: > Is this intentional? I would have expected the > // operator to always give an integer result. Think "floor division", not "integer division". The result (r) may be a float, but it'll hold to the constraint: r == int(r) -Fred -- Fred L. Drake, Jr. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Has anyone been in touch with Fred Drake?
On Wednesday 28 March 2007 17:17, Martin Thomas wrote: > Down here in Texas, Comcast subscribers were recently moved to > Roadrunner.. changing email addresses from, for example, > [EMAIL PROTECTED] to [EMAIL PROTECTED] Other parts of the country were > also affected. Is it possible that Fred has been moved also? What part > of the country is he in? Not to worry; I've been found. (And not in Texas, as it happens.) Comcast has a helpful feature where they save any spam you get, and count it against you. I think I've fixed the settings so they won't continue pushing that mis-feature on me. :-/ I appear to be receiving my Python lists just fine again. -Fred -- Fred L. Drake, Jr. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Italic text in the manual
On Thursday 08 March 2007 08:42, Martin v. Löwis wrote: > Certainly not. In today's copy (8.3.07, 13:30 GMT), this starts > between 18.17 and 18.17.1. However, looking at the tex, I cannot > find anything suspicious. texcheck complains about a missing ), > which I added, but it only was a problem of the text, not of the > markup. This doesn't seem to be a problem any more, so I'm going to presume Martin fixed it. ;-) -Fred -- Fred L. Drake, Jr. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Italic text in the manual
On Thursday 29 March 2007 17:48, Collin Winter wrote: > The docs for atexit in py3k [1] are mostly (though not all) in > italics; I can't figure out why, and I'd appreciate if anyone with > stronger latex-foo could take a look. This is now fixed in Py3K, and there are no further occurrances of \em on the trunk of in Py3K. The online build will catch up when the automated build runs again. -Fred -- Fred L. Drake, Jr. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] context manager - generator interaction?
On where to write guidelines about exception handling scope: Guido wrote: > This rule has no place in a pure language *reference* manual. But > it certainly deserves mention in any form of more practical > documentation, be it a tutorial or a more advanced programming > manual. On Friday 06 April 2007 10:31, [EMAIL PROTECTED] wrote: > PEP 8 anyone? New users should be exposed sooner than this; most will never read any PEP. The tutorial seems like a good place. This is general good programming practice we're talking about here, not style. -Fred -- Fred L. Drake, Jr. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] minidom -> new-style classes?
On Tuesday 17 April 2007 22:37, Jason Orendorff wrote: > The right way to implement these quirks is using new-style classes and > properties. Right now minidom uses old-style classes and lots of > hackery, and it's pretty broken. (Another example--there is an > Attr._set_prefix method, but it is *not* called from __setattr__.) Yes, it's truly vile. Better than it used to be, but There's also some vague attempt at supporting the Python CORBA IDL mapping, since the W3C DOM specifications use that. I expect the support is incomplete at best. > Surely nobody is subclassing these classes. You don't subclass DOM > interfaces--the DOM doesn't work that way. So this change should be > OK. Right? There are people who've tried building new DOM implementations by subclassing the minidom classes to get most of the behavior. I'm don't know the status of any of these implementations, but changes to these classes have proved difficult due to this and the possibility of breaking pickles (amazed me, that one did!). I'd love to see a sane implementation, using new-style classes and properties, but as long as we've got to support existing applications, we're pretty well hosed as far as xml.dom.minidom is concerned. A new DOM implementation conforming to the W3C recommendations would be nice, but I'd really rather see an XML object model that doesn't suck, but that supports as much of the information found in the W3C DOM as possible. Something based more on the ElementTree API, perhaps. The value of the W3C-approved API has certainly turned out to be more decoy than anything. -Fred -- Fred L. Drake, Jr. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] whitespace normalization
On Wednesday 25 April 2007, Steve Holden wrote: > Duncan Booth wrote: > > That way the whitespace ought to stay normalized so you shouldn't need a > > separate cleanup step and you won't be breaking diff and blame for the > > sources (and if the reindent does ever break anything it should be more > > tracable). > > +1 +1 here as well; there's no need to let things like this get out-of-sync from what we want. -Fred -- Fred L. Drake, Jr. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 30XZ: Simplified Parsing
On Wednesday 02 May 2007, Trent Mick wrote:
> raise MakeError("extracting '%s' in '%s' did not create the "
> "directory that the Python build will expect: "
> "'%s'" % (src_pkg, dst_dir, dst))
>
> I use this kind of thing frequently. Don't know if others consider it
> bad style.
I do this too; this is a good way to have a simple human-readable message
without doing weird things to about extraneous newlines or strange
indentation.
-1 on removing implicit string catenation.
-Fred
--
Fred L. Drake, Jr.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Changing string constants to byte arr ays ([Python-checkins] r55119 - in python/branches/p y3k-struni/Lib: codecs.py test/test_codecs.py )
On Friday 04 May 2007, M.-A. Lemburg wrote: > I also suggest making all bytes literals immutable to avoid running > into any issues like the above. +1 from me. -Fred -- Fred L. Drake, Jr. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Byte literals (was Re: [Python-checkins] Changing string constants to byte arrays ( r55119 - in python/branches/py3k-struni/Lib: codecs.py test/test_codecs.py ))
On Saturday 05 May 2007, Aahz wrote: > I'm with MAL and Fred on making literals immutable -- that's safe and > lots of newbies will need to use byte literals early in their Python > experience if they pick up Python to operate on network data. Yes; there are lots of places where bytes literals will be used the way str literals are today. buffer(b'...') might be good enough, but it seems more than a little idiomatic, and doesn't seem particularly readable. I'm not suggesting that /all/ literals result in constants, but bytes literals seem like a case where what's wanted is the value. If b'...' results in a new object on every reference, that's a lot of overhead for a network protocol implementation, where the data is just going to be written to a socket or concatenated with other data. An immutable bytes type would be very useful as a dictionary key as well, and more space-efficient than tuple(b'...'). Whether there should be one type with a flag indicating mutability, or two separate types (as with set and frozenset), I'm not sure. The later offers some small performance benefits, but I don't expect there's enough to really matter there. -Fred -- Fred L. Drake, Jr. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] \code or \constant in tex markup
On Wednesday 09 May 2007, Neal Norwitz wrote:
> Which is correct?
\constant was introduced much more recently than \code (though it's not really
new anymore). The intent for \constant when it was introduced was that it be
used for names that were treated as constants in code (such as
string.ascii_letters or doctest.REPORT_NDIFF), not syntactic literals like 3
or "abc".
At the time, None, True, and False were just named values in the __builtin__
module. I don't think the support for None as a "real" constant should
change the status of the value as "just another named constant" other than in
the implementation details.
So I think \constant is right for all three; we just haven't gone back and
changed all the older instances of \code{None}, \code{True}, and
\code{False}. We've generally resisted that sort of blanket change, but
consistency is valuable too. Perhaps it's time to make the change across the
board.
-Fred
--
Fred L. Drake, Jr.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Official version support statement
On Thursday 10 May 2007, Barry Warsaw wrote: > This came up in a different context. I originally emailed this to > the python.org admins, but Aahz rightly points out that we should > first agree here that this actually /is/ our official stance. +1 -Fred -- Fred L. Drake, Jr. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The docs, reloaded
On Monday 21 May 2007, [EMAIL PROTECTED] wrote: > Then I submit that you are probably removing some significant piece of > functionality from the provided documentation toolchain which some people > probably rely on. After all, that's what LaTeX excels at. They will be > able to continue to use the old tools, but where will they get them if > they are no longer part of Python? I'll be happy to pull the existing tools out into a separate distribution if we move to something else for Python. There are too many users of the existing tools to abandon. -Fred -- Fred L. Drake, Jr. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The docs, reloaded
On Monday 21 May 2007, A.M. Kuchling wrote: > Disadvantages: > > * reST markup isn't much simpler than LaTeX. * reST doesn't support nested markup, which is used in the current documentation. -Fred -- Fred L. Drake, Jr. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The docs, reloaded
On Monday 21 May 2007, [EMAIL PROTECTED] wrote: > Take a look at <http://www.webfast.com/modindex/>. It records request > counts for the various pages and presents the most frequently requested > pages in a section at the top of the page. I can make the script > available if anyone wants it (it uses Myghty - Mason in Python.) This is very cool. ;-) -Fred -- Fred L. Drake, Jr. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The docs, reloaded
On Tuesday 22 May 2007, Barry Warsaw wrote: > considerably. Even with a nice distro packaging system it can be a > PITA to get all the tools you need to build the documentation > properly installed. A pure-Python solution, even a lesser one, would > be a win if we can still produce top quality online and written > documentation from one source. The biggest potential wins I see for a new system are: - more contributions - platform-independent processing I remain sceptical on being able to achieve the first, but there some hope for it. The later should make things easier for people who are willing to put the work into contribution, which is valuable in its own right. -Fred -- Fred L. Drake, Jr. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The docs, reloaded
On Tuesday 22 May 2007, Georg Brandl wrote: > But that's at least funnier than before :) It's not our job to make whiner-babies sound funny. -Fred -- Fred L. Drake, Jr. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The docs, reloaded
Nick Craig-Wood wrote: > ``comment'' produces smart quotes in latex if I remember correctly. > You probably want to convert it somehow because it looks a bit odd on > the web page as it stands. I'm not sure what the reST replacement > might be, but converting it just to "comment" would probably be OK. > Likewise with `comment' to 'comment'. > > For an example see the first paragraph here: > > http://pydoc.gbrandl.de/reference/index.html What latex does here for typeset output is nice, but it's also a bit of a hack job. The ` and ' characters aren't smart, the fonts just have curved glyphs for them. `` and '' are mapped to additional glyphs using ligatures, again part of the font information. The result, of course, is really nice. :-) Scott Dial wrote: > In fairness to Georg, latex2html also misses the smart quotes. See the > same paragraph here: > > http://docs.python.org/ref/front.html There's a way to make latex2html do "the right thing" for these, except... it then happily does so even to ` and '' (and `` and '') in code samples, since there's no equivalent to the font information used to handle this in latex. -Fred -- Fred L. Drake, Jr. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Minor ConfigParser Change
On Saturday 26 May 2007, Joseph Armbruster wrote: > I noticed that one of the parts of ConfigParser was not using "for line > in fp" style of readline-ing :-) So, this will reduce the SLOC by 3 > lines and improve readability. However, I did a quick grep and this > type of practice appears in several other places. Before the current iteration support was part of Python, there was no way to iterate over a the way there is now; the code you've dug up is simply from before the current iteration support. (As I'm sure you know.) Is there motivation for these changes other than a stylistic preference for the newer idioms? Keeping the SLOC count down seems pretty minimal, and unimportant. Making the code more understandable is valuable, but it's not clear how much this really achieves that. In general, we try to avoid making style changes to the code since that can increase the maintenance burden (patches can be harder to produce that can be cleanly applied to multiple versions). Are there motivations we're missing? -Fred -- Fred L. Drake, Jr. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Minor ConfigParser Change
On Friday 01 June 2007, BJörn Lindqvist wrote: > Patches are applied once, but thousands of people read the code in the > standard library each month. The standard library should be as > readable as possible to make it as easy as possible to maintain. It is > just good software development methodology. Rest assured, I understand your sentiment here, and am not personally against an occaissional clean-up. ConfigParser in particular is old and highly idiosyncratic. > Many parts of the standard library are arcane and almost impossible to > understand (see httplib for example) because refactoring changes are > Not done. So if someone wants to improve the code why not let them? Changes in general are a source of risk; they have to be considered carefully. We've seen too many cases in which a change was thought to be safe, but broke something for someone. Avoiding style-only changes helps avoid introducing problems without being able to predict them; there are tests for ConfigParser, but it's hard to be sure every corner case has been covered. This is a general policy in the Python project, not simply my preference. I'd love to be able to say "yes, the code is painful to read, let's make it nicer", but it's hard to say that without being able to say "I'm sure it won't break anything for anybody." Python's too flexible for that to be easy. -Fred -- Fred L. Drake, Jr. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [RFC] urlparse - parse query facility
On Tuesday 12 June 2007, Senthil Kumaran wrote: > This mail is a request for comments on changes to urlparse module. We > understand that urlparse returns the 'complete query' value as the query > component and does not > provide the facilities to separate the query components. User will have to > use the cgi module (cgi.parse_qs) to get the query parsed. I agree with the comments Jim provided. > Below method implements the urlparse_qs(url, > keep_blank_values,strict_parsing) that will help in parsing the query > component of the url. It behaves same as the cgi.parse_qs. Except that it takes a URL, not only a query string. > def urlparse_qs(url, keep_blank_values=0, strict_parsing=0): ... > scheme, netloc, url, params, querystring, fragment = urlparse(url) I see no reason to incorporate the URL splitting into the function; the existing function signatures for cgi.parse_qs and cgi.parse_qsl are sufficient. It may be convenient to add methods to the urlparse.BaseResult class providing access to the parsed version of the query on the instance. -Fred -- Fred L. Drake, Jr. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [RFC] urlparse - parse query facility
On Saturday 16 June 2007, O.R.Senthil Kumaran wrote: > The urlparse will cotain parse_qs and parse_qsl takes the query string > (not url) and with optional arguments keep_blank_values and strict_parsing > (same as cgi). > > http://deadbeefbabe.org/paste/5154 Looks good. > > It may be convenient to add methods to the urlparse.BaseResult class > > providing access to the parsed version of the query on the instance. ... > * parse_qs or parse_qsl will be invoked on the query component separately > by the user. Yes; this doesn't change, really. Methods would still need to be invoked separately, but the query string doesn't need to be passed in; it's part of the data object. > * If parsed query needs to be available at the instance as a convenience > function, then we will have to assume the keep_blank_values and > strict_parsing values. If it were a property, yes, but I think a method on the result object makes more sense because we don't want to assume values for these arguments. > * Coding question: Without retyping the bunch of code again in the > BaseResult, would is the possible to call parse_qs/parse_qsl function on > self.query and provide the result? Basically, what would be a good of > doing it. That's what I was thinking. Just add something like this to BaseResult (untested): def parsedQuery(self, keep_blank_values=False, strict_parsing=False): return parse_qs( self.query, keep_blank_values=keep_blank_values, strict_parsing=strict_parsing) def parsedQueryList(self, keep_blank_values=False, strict_parsing=False): return parse_qsl( self.query, keep_blank_values=keep_blank_values, strict_parsing=strict_parsing) Whether there's a real win with this is unclear. I generally prefer having an object that represents the URL and lets me get what I want from it, rather than having to pass the bits around to separate parsing functions. The result objects were added in 2.5, though, and I've no real idea how widely they've been adopted. -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.6 BaseException.message deprecation, really needed?
On Saturday 07 July 2007, Gustavo Carneiro wrote: > In PyGObject we want to use a 'message' attribute in an exception defined > by us. The name 'message' comes from a C API, therefore we would like to > keep it for easier mapping between C and Python APIs. Why does Python > have to deprecate this attribute? It can be deprecated for BaseException without it being deprecated for your exception. You'll need to define a property that overrides the property in BaseException; something like this in Python (not tested): class MyException(Exception): _message = None @apply def message(): def get(self): return self._message def set(self, value): self._message = value return property(get, set) I think your use case is entirely reasonable, and can be handled readily. -Fred -- Fred L. Drake, Jr. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Add a -z interpreter flag to execute a zip file
At 03:52 PM 7/12/2007 -0700, Andy C wrote: >So does everyone agree that there should be a new extension called >.pyz? And that the definition of this is a .zip file with a >__zipmain__.py module at its root? If so, I can make the change... I >haven't looked around the codebase yet but it sounds easy enough. I'm not a Windows user, so don't have a good feel for the state of the extension mess on that platform these days. PYZ isn't listed on filext.com, but I don't know if that means much. On Thursday 12 July 2007, Phillip J. Eby wrote: > Let's use __main__, please. Fewer names to remember, and __main__ is > supposed to be the __name__ of the main program. It Just Makes Sense. Indeed. Let's not do something so specific it's a pain to use. Andy C: >* Does anyone else want to change the -z flag to make more sense for >directories (and possibly change __zipmain__.py to __main__.py)? In >thinking about this again, I am not sure I can come up with a real use >case. Yes. A use case for using directories, or for *not* supporting them? These cases should be as similar as possible; like Phillip suggested, we should be thinking "sys.path entry" rather than "zip file". Phillip Eby: > Testing your package before you zip it, would be one. :) My > personal main interest was in being able to add an item to sys.path > without having to set $PYTHONPATH on Windows. That's why I'd like it > to be possible to use -z more than once (or whatever the option ends up > as). What happens if multiple entries contain __main__.py entries? I don't like this one so much. I don't know what Java does if you specify -jar more than once; that might suggest something. > The only competing proposal besides what > I've suggested was the one to add an option to "runpy", and IMO > that's dead in the water due to shebang argument limits. Agreed. Andy: >* Magically looking at the first argument to see if it's a zip file >seems problematic to me. I'd rather be explicit with the -z flag. >Likewise, I'd rather be explicit and call it __zipmain__ rather than >__main__. Identifying ZIP files is straightforward; there's nothing weird about this one. -Fred -- Fred L. Drake, Jr. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Add a -z interpreter flag to execute a zip file
On Friday 13 July 2007, Paul Moore wrote: > Fair point. Doesn't it argue that there are valid uses for both -p and > -z (in Python terms)? I'm not expert in Java usage, but on Windows, Indeed it does. I'd be happy for there to be a -p that allows both Windows and Unix users to prepend to sys.path. It should also be separate from the -z (or whatever that gets called). -Fred -- Fred L. Drake, Jr. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Add a -z interpreter flag to execute a zip file
On Friday 13 July 2007, Anders J. Munch wrote: > How about .pyzip instead? To make it more obvious, and not mistakable for > .py.z. I guess it would be pinheaded to call it .zippy. ;-) -Fred -- Fred L. Drake, Jr. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Add a -z interpreter flag to execute a zip file
On Saturday 14 July 2007, Andy C wrote:
> I don't mind calling it -z and using it for directories. But mainly
> that's because no one has proprosed another name. : ) I think we've
> agreed that -p is something totally different.
We could use -r ("run"), or -X ("execute"); not sure those are really right
either.
> > > while I think it would be a bad practice to
> > > import __main__,
> >
> > I have seen it recommended as the right place to store global
> > (cross-module) settings.
>
> Where? People use __main__.py now? That seems bad, because __ names
> are reserved, so they should just use main.py, I would think.
I've seen __main__ suggested as a place to store application-specific global
settings, but not for a long time. I don't think it was ever mapped directly
to a file on disk though.
I find the idea really hackish.
-Fred
--
Fred L. Drake, Jr.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python.org current docs
On Tuesday 30 November 2004 02:46 pm, Thomas Heller wrote: > http://www.python.org/doc/current/ > and > http://docs.python.org/ > > still point to 2.3.4 docs. I'll be fixing that up tonight. -Fred -- Fred L. Drake, Jr. ___ Python-Dev mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python.org current docs
On Tuesday 30 November 2004 02:46 pm, Thomas Heller wrote: > http://www.python.org/doc/current/ > and > http://docs.python.org/ > > > still point to 2.3.4 docs. I think everything is properly updated now. Please let me know if I've missed anything. -Fred -- Fred L. Drake, Jr. ___ Python-Dev mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Rewriting PEP4
On Tuesday 07 December 2004 04:46 am, Nick Coghlan wrote: > One other question occurred to me for "deprecate X in favour of Y" > situations - should the deprecation warning added to X point developers > towards Y? Not sure about the warning, but the documentation certainly should. When the mapping from the old module to the new is not obvious and trivial, sufficient information should be included in the documentation for the old module to make it fairly easy to perform the conversion. (Placing this in the docs for the old module ensures that it goes away when the documentation for the old module goes away, and the docs for the new module need never be loaded with information about the old module.) > Also, should the PEP include example wordings for deprecation warnings, > rather than being completely freeform? Martin listed some information that > should be included, but it seems an example or two would make it easy to > get right. Examples would be good, though specific wording should not be proscribed. -Fred -- Fred L. Drake, Jr. ___ Python-Dev mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[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. ___ Python-Dev mailing list Python-Dev@python.org 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. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I think setup.py needs major rework
On Tuesday 25 January 2005 23:30, Skip Montanaro wrote: > Python's setup.py has grown way out of control. I'm trying to build > and install Python 2.4.0 on a Solaris system with Tcl/Tk installed in a > non-standard place and I can't figure out the incantation to tell setup.py > to look where they are installed. ... > This might be an excellent sprint topic for PyCon. Indeed it would be! -Fred -- Fred L. Drake, Jr. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: 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. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] JOB OPENING: Implementor for Python and Search
On Friday 04 February 2005 09:04, [EMAIL PROTECTED] wrote: > I hope posting job vacancies does not violate established list > netiquette. The job in question is mainly to do with the PyPy EU project. There's a Python Job Board on python.org; see http://www.python.org/Jobs-howto.html for information on posting opportunities there. -Fred -- Fred L. Drake, Jr. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[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. ___ Python-Dev mailing list Python-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.
___
Python-Dev mailing list
Python-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. ___ Python-Dev mailing list Python-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/idlelib NEWS.txt, 1.49.2.3, 1.49.2.4 idlever.py, 1.22.2.1, 1.22.2.2
On Wednesday 09 March 2005 06:54, [EMAIL PROTECTED] wrote: > RCS file: /cvsroot/python/python/dist/src/Lib/idlelib/NEWS.txt,v ... > -What's New in IDLE 1.1.1? > -=== > +What's New in IDLE 1.1.1c1? ... > RCS file: /cvsroot/python/python/dist/src/Lib/idlelib/idlever.py,v > -IDLE_VERSION = "1.1.1" > +IDLE_VERSION = "1.1.1c1" Shouldn't this progress from 1.1.1 to 1.1.2c1? Otherwise it's moving backward. -Fred -- Fred L. Drake, Jr. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Re: [Python-checkins] python/dist/src/Lib/idlelib NEWS.txt, 1.49.2.3, 1.49.2.4 idlever.py, 1.22.2.1, 1.22.2.2
On Wednesday 09 March 2005 12:06, Anthony Baxter wrote: > No - Py2.4 shipped with idle 1.1. I must've updated it to 1.1.1 sometime > after the 2.4 release (I vaguely recall doing this). Ah, ok. I guess I should have looked. -Fred -- Fred L. Drake, Jr. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Re: Change 'env var BROWSER override' semantics in webbrowser.py
On Friday 18 March 2005 17:44, Reinhold Birkenfeld wrote: > Additionally, there are several patches on SF that pertain to > webbrowser.py; perhaps you can review some of them... Given the time I haven't been able to devote to the webbrowser module, a consolidated set of reviews would be very helpful. Patch reviews should be written in the tracker, as always, and a summary of all the webbrowser-related patches in a single email to python-dev. -Fred -- Fred L. Drake, Jr. ___ Python-Dev mailing list Python-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. ___ Python-Dev mailing list Python-Dev@python.org 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. ___ Python-Dev mailing list Python-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. ___ Python-Dev mailing list Python-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.org
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. ___ Python-Dev mailing list Python-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.org
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 . 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. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] C API for the bool type?
On Monday 21 March 2005 04:54, Bo Thorsen wrote: > If this is not the correct place to post this problem, I apologize. In > that case, please be gentle and point me to a better mailing list. You should be able to get answers to this kind of question on comp.lang.python (aka python-list at python.org). But I'll give you this one for free. :-) > I'm coding a text editor in Qt that uses Python for macros. The problem I > have is that want to use the bool type introduced in 2.3, but I can't see > how to do this. On http://docs.python.org/api/arg-parsing.html the format > units are described, but no bool is there. There is no format character for boolean, and you don't actually need one. Recall that in Python, all objects have some interpretation as a truth value. The easiest way to check this from C code is to pass the object to PyObject_IsTrue() or PyObject_Not() (depending on the sense of the test you want, and how you want your code to read). The argument can be retrieved in your PyArg_ParseTuple*() call using the "O" format character. > If it doesn't exist, I guess I should use the int format unit and call the > http://docs.python.org/api/boolObjects.html functions to see if this is > actually a bool or not? In most cases, you really don't care if the object is actually a bool. The recipe above will also work in older versions of Python. That lets you use bools for the reason they were really introduced: to enhance readability. -Fred -- Fred L. Drake, Jr. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python.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. ___ Python-Dev mailing list Python-Dev@python.org 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. ___ Python-Dev mailing list Python-Dev@python.org 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. ___ Python-Dev mailing list Python-Dev@python.org 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. ___ Python-Dev mailing list Python-Dev@python.org 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. ___ Python-Dev mailing list Python-Dev@python.org 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. ___ Python-Dev mailing list Python-Dev@python.org 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 Tuesday 14 February 2006 22:34, Greg Ewing wrote: > Seems to me this is a case where you want to be able > to change encodings in the middle of reading the stream. > You start off reading the data as ascii, and once you've > figured out the encoding, you switch to that and carry > on reading. Not quite. The proper response in this case is often to re-start decoding with the correct encoding, since some of the data extracted so far may have been decoded incorrectly. A very carefully constructed application may be able to go back and re-decode any data saved from the stream with the previous encoding, but that seems like it would be pretty fragile in practice. There may be cases where switching encoding on the fly makes sense, but I'm not aware of any actual examples of where that approach would be required. -Fred -- Fred L. Drake, Jr. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] http://www.python.org/dev/doc/devel still available
On Tuesday 14 February 2006 03:09, Neal Norwitz wrote: > While you are here, are you planning to do the doc releases for 2.5? > You are tentatively listed in PEP 356. (Technically it says TBD with > a ? next to your name.) Releases generally aren't a problem, since they're heavily automated and scheduled well in advance. I'm glad to continue helping with that, especially since that seems to be about all I can get to sometimes. > I think this was the quick hack I did. I hope there are many > concerns. :-) For example, if the doc build fails, ... Hmmm, this > probably isn't a problem. The doc won't be updated, but will still be > the last good version. So if I send mail when the doc doesn't build, > then it might not be so bad. Seems reasonable to me. > I still need to > switch over the failure mails to go to python-checkins. There are too > many right now though. Unless people don't mind getting several > messages about refleaks every day? Anyone? Documentation build errors should probably be separated from leak detection reports. I don't know what it would take to get them separated. > That shouldn't be a problem. See http://docs.python.org/dev/2.4/ Works for me! Thanks for putting the effort into this. The general question of where the development docs should show up remains. There are a number of options: 1. www.python.org/dev/doc/, where I'd put them at one point 2. www.python.org/doc/..., which is reasonable, but new 3. docs.python.org/dev/, which seems reasonable, but docs.python.org proponents may not like 4. www.python.org/dev/doc/ for trunk documentation, and docs.python.org/ and/or www.python.org/doc/current/ for maintenance updates That last one has a certain appeal. It would allow corrections to go online quicker, so people using python.org or a mirror would get updates quickly (an advantage of delivering docs over the net!), and I wouldn't get so many repeat reports of commonly-noticed typos. The released versions would still be available via www.python.org/doc/x.y.z/. My own inclination is that if we continue to use docs.python.org, it should contain only one copy of the documentation, and that should be for the most recent "stable" release (though perhaps an updated version of the documentation). I'm not really on either side of the fence about whether docs.python.org is the "right thing" to do; the idea came out of the folks interested in advocacy. -Fred -- Fred L. Drake, Jr. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 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 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. ___ Python-Dev mailing list Python-Dev@python.org 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. ___ Python-Dev mailing list Python-Dev@python.org 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. ___ Python-Dev mailing list Python-Dev@python.org 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. ___ Python-Dev mailing list Python-Dev@python.org 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. ___ Python-Dev mailing list Python-Dev@python.org 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. ___ Python-Dev mailing list Python-Dev@python.org 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. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.5 Schedule
On Monday 20 March 2006 00:49, Anthony Baxter wrote: > I'd still like to push 2.4.3rc1 out in a couple of days time, with > 2.4.3 final next week, and then maybe aim for 2.5a1 a week or two > later? How does that work for everyone? I should be fine to build the documentation Wednesday night (US Eastern time). -Fred -- Fred L. Drake, Jr. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
