Re: [Python-Dev] Encouraging developers

; had >> wrote a patch that contained bugs and I corrected them. And with >> that, I >> was the last person to comment or review the patch in question. [...] > On the other hand, what I've done is similar to what you did - comment > on someone else's patch. It

[Python-Dev] DRAFT: python-dev Summary for 2006-01-16 through 2005-01-31

Here's the draft for the second half of January. First half of February on its way soon. Any suggestions/corrections/additions/comments welcome. Thanks! -TAM = Announcements = - Google summer internships - Google is look

Re: [Python-Dev] 2.5 release schedule

> We still need a release manager. No one has heard from Anthony. It is the peak of the summer down here. Perhaps he is lucky enough to be enjoying it away from computers for a while? =Tony.Meyer ___ Python-Dev mailing list Python-Dev@python.org htt

Re: [Python-Dev] Extension to ConfigParser

[Paul Moore] > * No way to merge files or sections. Usually to provide default > values. I have a suite of applications, all using the same framework. > I have a hardcoded DEFAULT_CONFIG in the code, overriden by a > .ini, overridden again by a .ini. OK, maybe it's > overengineered, but I do use th

Re: [Python-Dev] Extension to ConfigParser

[Scott Dial] [Re: http://python.org/sf/1410680] > I've spent a small amount of time playing with this patch, and the > intent is there, but it appears to have some obvious bugs with adding > blank lines and (at least) making an empty [DEFAULT] section appear > and > disappear. I'm not sure that

Re: [Python-Dev] Extension to ConfigParser

[Guido van Rossum] > What would break if we rewrote the save functionality to produce a > predictable order? As a reminder to anyone interested, there are three patches on SF that provide this (each in a different way): ConfigParser to accept a custom dict to allow ordering http://python.o

Re: [Python-Dev] Extension to ConfigParser

[Guido] >> What's so bad about ConfigParser? [Skip Montanaro] > It's my opinion that ConfigParser should stay pretty much as it is > other > than perhaps adding round trip capability. [...] > If we want more sophisticated functionality a new module should be > written, > or one of the existing

Re: [Python-Dev] / as path join operator

[Jason Orendorff] > Filesystem paths are in fact strings on all operating systems I'm > aware of. And it's no accident or performance optimization. It's > good design. Isn't that simply because filesystems aren't object orientated? I can't call methods of a path through the filesystem. There

[Python-Dev] DRAFT: python-dev Summary for 2006-01-01 through 2006-01-15

that orders the output so that doctest output can be easily reliable. He pointed out that there is `another open patch`_ that allows the user to specify the order through an "ordered dictionary". Guido explained that he didn't feel that it mattered, as long as the patch also allows c

Re: [Python-Dev] The path module PEP

[Gustavo J. A. M. Carneiro] > Plus, the names are full of redundancy. Why abspath(), joinpath(), > realpath(), splitall()? Why not instead: absolute(), join(), real(), > split() ? Remember that they are all methods of a Path class, you > don't > need to keep repeating 'path' all over the place

Re: [Python-Dev] The path module PEP

[Ian Bicking] > Paths are strings, that's in the PEP. No, the PEP says that Path is a *subclass* of string ("Path extends from string"). In addition, it's a disputed part of the PEP (see elsewhere in this thread). =Tony.Meyer ___ Python-Dev mailing

Re: [Python-Dev] / as path join operator (was: Re: The path module PEP)

[John J Lee] > But it's a very readable way to write a common operation. Perhaps one > reason the discrepancy you point out doesn't bother me is that > division is > the least-used of the +-*/ arithmetic operations. Do you have evidence to back that up? It seems a strange claim. Outside of

Re: [Python-Dev] The path module PEP

logical choice. (There are also alternatives to "joinpath" if the name is the thing: add(), for example). [Tony Meyer] >> Against it: >> * Zen: Beautiful is better than ugly. Explicit is better than >> implicit. Readability counts. There should be one-- and &g

Re: [Python-Dev] The path module PEP

> Remove __div__ (Ian, Jason, Michael, Oleg) > > This is one of those where everyone (me too) says "I don't care either > way." If that is so, then I see no reason to change it unless someone > can show a scenario in which it hurts readability. Plus, a few people > have said that they like the shor

Re: [Python-Dev] The path module PEP

> The last time this was discussed six months ago it seemed like most of > python-dev fancied Jason Orendorff's path module. But Guido wanted a > PEP and noone created one. So I decided to claim the fame and write > one since I also love the path module. :) Much of it is copy-pasted > from Peter As

Re: [Python-Dev] New Pythondoc by effbot

> For me, the "-nospam" suffix works relatively good to avoid spam, > as most > harvesting programs will think this is a false address. http://spambayes.org works, too, without bothering others <0.5 wink> =Tony.Meyer ___ Python-Dev mailing list Python

Re: [Python-Dev] ConfigParser to save with order

[Tony Meyer] > Allowing 'surgical' editing of configuration files, as has been > proposed many times both here and c.l.p would not require > ConfigParser to be entirely rewritten (just more extensive > modification of the write() method). After writing the summary of th

Re: [Python-Dev] Names matter.

[Jim Fulton] > certainly, it should not be acceptable to contribute to Python > under a false name. What do you mean "contribute to Python"? Do you mean become one of the developers listed on sourceforge? Contribute any patches, even simple documentation ones? Review, comment and test pat

Re: [Python-Dev] DRAFT: python-dev Summary for 2005-12-01 through 2005-12-15

Opps. I just sent out the draft summary for the first half of December (which might only make it to the list after this one, since it's very long) but forgot to say anything at the top. No-doubt everyone knows the pitch by now, but if anyone is able to take a look at the summary (or parts of it)

[Python-Dev] DRAFT: python-dev Summary for 2005-12-01 through 2005-12-15

= Announcements = - Reminder: plain text documentation fixes are accepted - Want to help out with the Python documentation? Don't know LaTeX? No problem! Plain text or R

[Python-Dev] DRAFT: python-dev Summary for 2005-12-16 through 2005-12-31

Here's the second December summary. As always, if anyone can spare some time to take a look over it and send any comments/suggestions/corrections/additions to me or Steve that would be great. I'm not all that confident about the "default comparisons" thread, so particular attention to that would

Re: [Python-Dev] ConfigParser to save with order

> I see two paths here: > > - Rewrite ConfigParser entirely. > - Apply my patch. Allowing 'surgical' editing of configuration files, as has been proposed many times both here and c.l.p would not require ConfigParser to be entirely rewritten (just more extensive modification of the write() me

Re: [Python-Dev] ConfigParser to save with order

[Guido] >> I think it's moot unless you also preserve comments. Ideally would be >> something that prserved everything (ordering, blank lines, comments >> etc.) from how it was read in. Modifying a value should keep its >> position. Adding a value should add it to the end of the section it's >> in

Re: [Python-Dev] PEP 8 updates/clarifications

[Barry] >>> I've pushed out a revised PEP 8 >>> >>> http://www.python.org/peps/pep-0008.html >>> >>> Please review and comment. [Tony Meyer] >> Why does PEP 8 continually refer to one particular editor (Emacs)? [Guido] > I think the best

Re: [Python-Dev] PEP 8 updates/clarifications

> I've pushed out a revised PEP 8 > > http://www.python.org/peps/pep-0008.html > > Please review and comment. Why does PEP 8 continually refer to one particular editor (Emacs)? (There are even parts in the form "x is better because it works better in Emacs", when surely it's actually the case

Re: [Python-Dev] PEP 8 updates/clarifications

>> * Python core modules/packages >> >> * Third-party modules/packages >> >> * Local modules/packages > > This is already in PEP 8: [...] >1. standard library imports >2. related major package imports (i.e. all email package > imports > next) >3. application sp

Re: [Python-Dev] Tracker anonymity

[Nick] >> Can we put a warning on the anonymous submission page pointing out >> the problems with using it for non-trivial bug reports? [Skip] > I don't think we have any control over the boilerplate SF displays. There must be some control. There's a "Outlook users please see the list of frequ

[Python-Dev] DRAFT: python-dev Summary for 2005-11-01 through 2005-11-15

Surprise!  It's November, and here's a November summary .  Thanks to all those that proofread the triple summary hit last week; if anyone can spare some time to take a look over these in the next couple of days, that would be great.  As always, corrections and suggestions to [EMAIL PROTECTED] or [

[Python-Dev] DRAFT: python-dev Summary for 2005-10-16 to 2005-10-31

And this one brings us up-to-date (apart from the fortnight ending yesterday). Again, if you have the time, please send any comments/ corrections to us. Once again thanks to Steve for covering me and getting this all out on his own. = Announcements = --

[Python-Dev] DRAFT: python-dev Summary for 2005-10-01 to 2005-10-15

As you have noticed, there has been a summary delay recently. This is my fault (insert your favourite thesis/work/leisure excuse here). Steve has generously covered my slackness by doing all of the October summaries himself (thanks!). Anyway, if you have some moments to spare, cast your

[Python-Dev] DRAFT: python-dev Summary for 2005-09-16 to 2005-09-30

It's been some time (all that concurrency discussion didn't help ;) but here's the second half of September. Many apologies for the delay; hopefully you agree with Guido's 'better late than never', and I promise to try harder in the future. Note that the delay is all my bad, and epithets

Re: [Python-Dev] Proposal: can we have a python-dev-announce mailing list?

> I know I would be much helped with a moderated python-dev-announce > mailing list, which would be only low-volume, time-critical > announcements for people developing Python. Even during times when I > am actively following python-dev it would be handy to have important > announcements coming in

[Python-Dev] DRAFT: python-dev Summary for 2005-09-01 through 2005-09-16

This is over a month late, sorry, but here it is (Steve did his threads ages ago; I've fallen really behind). Summaries for the second half of September and the first half of October will soon follow. As always, if anyone is able to give this a quick look that would be great. Feedback to

[Python-Dev] [draft] python-dev Summary for 2005-08-16 through 2005-08-31

If anyone would like to take a break from all this Py3k discussion, please feel free to read through the following draft for the second August summary. Checking over the "O(N**2) behaviour in StreamReader.readline" summary would be particularly appreciated. As always, any corrections/suggestions s

[Python-Dev] Tools directory (Was RE: Replacement for print in Python 3.0)

[finding Tools/i18n/pygettext.py] > You're right, I think Tools is probably a bad place for > anything. If it's not part of the stdlib, I'll likely never > find it. Agreed. Maybe with the introduction of -m in Python 2.4, some of the Tools/ scripts could be put in __main__ sections of appropria

Re: [Python-Dev] Replacement for print in Python 3.0

[...] > maybe a few folks can go off and write up a PEP for a > print-replacement. [...] > I'm pulling out of the > discussion until I see a draft PEP. If there are two competing proposals, then the two groups write a PEP and counter-PEP and the PEPs duke it out. Is this still the case if prop

Re: [Python-Dev] Replacement for print in Python 3.0

[Nick Coghlan] > "Print as statement" => printing sequences nicely is a pain What's wrong with this? >>> print range(10) [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] >>> print tuple("string") ('s', 't', 'r', 'i', 'n', 'g') This is a serious question - that's how I would expect a print function to work anyway.

Re: [Python-Dev] setdefault's second argument

> To save you from following that link, to this day I still mentally > translate "setdefault" to "getorset" whenever I see it. I read these out of order (so didn't see the giveaway getorsetandget) and spent some time wondering what an "orset" was. I figured it must be some obscure CS/text process

Re: [Python-Dev] Remove str.find in 3.0?

[Kay Schluehr] >> The discourse about Python3000 has shrunken from the expectation >> of the "next big thing" into a depressive rhetorics of feature >> elimination. The language doesn't seem to become deeper, smaller >> and more powerfull but just smaller. [Guido] > There is much focus on removi

[Python-Dev] python-dev Summary for 2005-08-01 through 2005-08-15 [draft]

Here's August Part One. As usual, if anyone can spare the time to proofread this, that would be great! Please send any corrections or suggestions to Steve (steven.bethard at gmail.com) and/or me, rather than cluttering the list. Ta! = Announcements = ---

[Python-Dev] python-dev Summary for 2005-07-16 through 2005-07-31 [draft]

Here's July Part Two. As usual, if anyone can spare the time to proofread this (it's fairly short this fortnight!), that would be great! Please send any corrections or suggestions to Tim (tlesher at gmail.com), Steve (steven.bethard at gmail.com) and/or me, rather than cluttering the list. Ta! =

Re: [Python-Dev] PEP: Migrating the Python CVS to Subversion

> Do we also want to split off nondist and encodings? IWBNI > the Python source code proper weren't buried too deep in the > directory structure. +1 =Tony.Meyer ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listin

Re: [Python-Dev] PEP: Migrating the Python CVS to Subversion

[...] > Publish the Repositories > [...] > As an option, websvn (available > e.g. from the Debian websvn package) could be provided. Is there any reason that this should be an option, and not just done? For occasional source (particularly C source) lookups, I've found web

Re: [Python-Dev] Adding the 'path' module (was Re: Some RFEforreview)

Maybe this has already been answered somewhere (although I don't recall seeing it, and it's not in the sourceforge tracker) but has anyone asked Jason Orendorff what his opinion about this (including the module in the stdlib) is? If someone has, or if he posted it somewhere other than here, could

Re: [Python-Dev] Adding the 'path' module (was Re: Some RFE forreview)

[Reinhold Birkenfeld] >>>> One more issue is open: the one of naming. As "path" is already >>>> the name of a module, what would the new object be called to >>>> avoid confusion? pathobj? objpath? Path? [Michael Hoffman] >>> I would arg

Re: [Python-Dev] Adding the 'path' module (was Re: Some RFE forreview)

[Reinhold Birkenfeld] >> One more issue is open: the one of naming. As "path" is already the >> name of a module, what would the new object be called to avoid >> confusion? pathobj? objpath? Path? [Michael Hoffman] > I would argue for Path. Granted "path" is actually os.path, but I don't think

[Python-Dev] python-dev Summary for 2005-06-01 through 2005-06-15 [draft]

You've just read two summaries, but here is another one, as we come back up to speed. If at all possible, it would be great if we could send this out in time to catch people for the bug day (very tight, we know), so if anyone has a chance to check this straight away, that would be great. Please s

[Python-Dev] python-dev Summary for 2005-05-16 through 2005-05-31 [draft]

You may have noticed that the summaries have been absent for the last month - apologies for that; Steve has been dutifully doing his part, but I've been caught up with other things. Anyway, Steve will post the May 01-15 draft shortly, and here's May 16-31. We should be able to get the first June o

Re: [Python-Dev] Decimal FAQ

> Q. I'm writing a fixed-point application to two decimal places. > Some inputs have many places and needed to be rounded. Others > are not supposed to have excess digits and need to be validated. > What methods should I use? > > A. The quantize() method rounds to a fixed number of decimal > pl

[Python-Dev] python-dev Summary for 2005-04-16 through 2005-04-30 [draft]

Here's April Part Two. If anyone can take their eyes of the anonymous block threads for a moment and give this a once-over, that would be great! Please send any corrections or suggestions to Tim (tlesher at gmail.com), Steve (steven.bethard at gmail.com) and/or me, rather than cluttering the list

RE: [Python-Dev] Faster Set.discard() method?

>>> But the dict.pop method is about 12 times faster. Is this >>> worth doing? >> >> The 2.4 builtin set's discard function looks like it does >> roughly the same as the 2.3 sets.Set. Have you tried comparing >> a C version of your version with the 2.4 set to see if there are >> speedups there,

RE: [Python-Dev] Faster Set.discard() method?

> To avoid the exception in the discard method, it could be > implemented as: > > def discard(self, element): > """Remove an element from a set if it is a member. > > If the element is not a member, do nothing. > """ > try: > self._data.pop(element

RE: [Python-Dev] rationale for the no-new-features approach

[Bob Ippolito] try: set except NameError: from sets import Set as set You don't need the rest. [Skip Montanaro] >>> Sure, but then pychecker bitches about a statement that appears to >>> have no effect. ;-) [Bob Ippolito] >> Well then fix PyChecker to look

RE: [Python-Dev] Python2.4.1c1 and win32com

> Win32com generates Python-files for use with com interfaces, > using the make-py.py utility. > > The generated files are OK with Python2.3.5 > > The generated files crash the Python interpreter with Python 2.4 > > Under Python 2.4.1c1, They give a syntax error!? > > The files unfortunately a

RE: [Python-Dev] RELEASED Python 2.4.1, release candidate 1

[Martin v. Löwis] >> I'd like to encourage feedback on whether the Windows >> installer works for people. It replaces the VBScript part in the >> MSI package with native code, which ought to drop the dependency on >> VBScript, but might introduce new incompatibilities. [Tim Peters] > Worked fine

RE: [Python-Dev] python-dev Summary for 2005-02-15 through 2005-02-28[draft]

> I am not expecting the candidates for taking of the Summaries > to write stuff for this one (although I wouldn't mind it =). In penance for being late with the other ones, here are a summaries for a couple of skipped threads for this period: --- Slow unit t

RE: [Python-Dev] python-dev Summary for 2005-02-01 through 2005-02-14[draft]

Somewhat slower, but here are two more threads from me (email is mostly a weekday thing for me, and the last few days were full of sun, wine, food and jazz. Well, and work. But working with sun, wine, food and jazz, so it's hard to complain too much). Feedback will not be ignored :) ---

RE: [Python-Dev] Is msvcr71.dll re-redistributable?

(I should point out the thread that starts here, too: in case anyone isn't aware of it). > Sounds like this puts all Python users in the clear, since > Python is the Licensee Software in that case. So, anybody can > distri

RE: [Python-Dev] Is msvcr71.dll re-redistributable?

[Thomas Heller] >> For the spambayes binary, maybe there should be another >> person adding the msvcr71.dll to the distribution that Tony >> builds? Someone who has a MSVC license, and also is developer >> on the spambayes project? [Tim Peters] > To the best of my knowledge, Tony is distributing

RE: [Python-Dev] Is msvcr71.dll re-redistributable?

[Thanks for bringing this up, BTW, Thomas]. [Thomas Heller] >> The 2.4 python.org installer installs msvcr71.dll on the >> target system. >> >> If someone uses py2exe or a similar tool to create a frozen >> application, is he allowed to redistribute this msvcr71.dll >> to other users together w

[Python-Dev] Bug tracker reviews

As promised, here are five bug reviews with recommendations. If they help [ 1112812 ] Patch for Lib/bsddb/__init__.py to work with modulefinder get reviewed, then that'd be great. Otherwise I'll just

RE: [Python-Dev] Should Python's library modules be written to help the freeze tools?

[Tony Meyer] > The main question (to steal Thomas's words) is whether the > library modules should be written to help the freeze tools > - if the answer is 'yes', then I'll submit the above as a > patch for 2.5. [Martin v. Löwis] > The answer to this question

[Python-Dev] Should Python's library modules be written to help the freeze tools?

The Python 2.4 Lib/bsddb/__init__.py contains this: """ # for backwards compatibility with python versions older than 2.3, the # iterator interface is dynamically defined and added using a mixin # class. old python can't tokenize it due to the yield keyword. if sys.version >= '2.3': exec """

RE: [Python-Dev] Please help complete the AST branch

> Perhaps interested parties should take up the discussion on > the compiler-sig. This isn't listed in the 'currently active' SIGs list on - is it still active, or will it now be? If so, perhaps it should be added to the list? By 'discussion on', do you mean via the wi

RE: [Python-Dev] Deprecated xmllib module

> As far as I can tell, there are no CSS or XML 1.1 parsers for > Python, period. This belongs on c.l.p, I suppose, but the first page of google results includes: =Tony.Meyer ___

RE: [Python-Dev] Deprecated xmllib module

>> * The average quality of the library improves as we take >> out junk (the tzparse module for example) and put in high >> quality modules like logging, csv, decimal, etc. > > Yes and no. The added modules have to be relevant to what > users want to do. While (relatively) minor stuff like csv