[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

[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] Unicode charmap decoders slow

Is there a faster way to transcode from 8-bit chars (charmaps) to utf-8 than going through unicode()? I'm writing a small card-file program. As a test, I use a 53 MB MBox file, in mac-roman encoding. My program reads and parses the file into messages in about 3 to 5 seconds (Wow! Go Python!), but

Re: [Python-Dev] Unicode charmap decoders slow

At 9:37 AM +0200 10/4/05, Walter Dörwald wrote: >Am 04.10.2005 um 04:25 schrieb [EMAIL PROTECTED]: > >>As the OP suggests, decoding with a codec like mac-roman or iso8859-1 is >>very slow compared to encoding or decoding with utf-8. Here I'm working >>with 53k of data instead of 53 megs. (Note: thi

Re: [Python-Dev] Unicode charmap decoders slow

[Recipient list not trimmed, as my replies must be vetted by a moderator, which seems to delay them. :] At 11:48 PM +0200 10/4/05, Walter Dörwald wrote: >Am 04.10.2005 um 21:50 schrieb Martin v. Löwis: > >> Walter Dörwald wrote: >> >>> For charmap decoding we might be able to use an array (e.g. a

Re: [Python-Dev] Unicode charmap decoders slow

At 8:36 AM +0200 10/5/05, Martin v. Löwis wrote: >Tony Nelson wrote: ... >> Encoding can be made fast using a simple hash table with external chaining. >> There are max 256 codepoints to encode, and they will normally be well >> distributed in their lower 8 bits. Hash on

Re: [Python-Dev] Unicode charmap decoders slow

here's still a tiny bit of debugging print statements in it. >At 8:36 AM +0200 10/5/05, Martin v. Löwis wrote: >>Tony Nelson wrote: > ... >>> Encoding can be made fast using a simple hash table with external chaining. >>> There are max 256 codepoints to encode

Re: [Python-Dev] Unicode charmap decoders slow

I have put up a new, packaged version of my fast charmap module at . Hopefully it is packaged properly and works properly (it works on my FC3 Python 2.3.4 system). This version is over 5 times faster than the base codec according to Hye-Shik Chang's benchmar

Re: [Python-Dev] Unicode charmap decoders slow

At 11:56 AM +0200 10/16/05, Martin v. Löwis wrote: >Tony Nelson wrote: >> BTW, Martin, if you care to, would you explain to me how a Trie would be >> used for charmap encoding? I know a couple of approaches, but I don't know >> how to do it fast. (I've never act

[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

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-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

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

rimitives <http://mail.python.org/ pipermail/python-dev/2005-October/057269.html>`__ [SJB] - Speed of Unicode decoding - Tony Nelson found that decoding with a codec like mac-roman or iso8859-1 can take around ten times as long as decoding with u

[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-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 [

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

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] 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

[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] 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] 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

[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

[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

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)

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] 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] 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] 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] 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

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] / 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

[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] 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

[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] / 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

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] 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

[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

[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

[Python-Dev] Re: Help to Resolve issues with Pull request 25220

issue-43737 branch was branched off of something other than master, which is usually a fatal mistake. The parent branch may also have been branched off of something other than master. Tony, with rare exception, each branch should be branched directly off master, which means checking out master

<    1   2