Re: [Python-Dev] Attention Bazaar mirror users
Barry Warsaw wrote: I've just upgraded the Bazaar mirrors on code.python.org to use bzr 1.12. We now have the opportunity to upgrade the repository format for better performance. Because of the bzr-svn requirement, we need a "rich root" format. Upgrading to 1.9-rich-root could buy us some significant performance improvements, but it will require all clients to upgrade to at least bzr 1.9, which was released on November 7, 2008. I would like to do this upgrade. If you are currently using the Bazaar mirrors at code.python.org and upgrading your client to at least bzr 1.9 would be a hardship, please contact me. If I don't hear any objections by say Tuesday, I'll go ahead and do the repo upgrades. This is now done. Please let me know if you have any problems with the mirrors. I'd suggest updating the text at http://www.python.org/dev/bazaar/ In particular: What do I need? * Bazaar 1.0 or newer. As of this writing (04-Nov-2008) Bazaar 1.8 is the most recent release. As Bazaar is written in Python (yay!), it is available for all major platforms, See the Bazaar home page for information about versions for your platform. --Scott David Daniels scott.dani...@acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 372 -- Adding an ordered directory to collections ready for pronouncement
Forest wrote: On Tue, March 3, 2009 11:20 am, Forest wrote: Okay, but I'd also like a convenient and fast way to find the oldest entry in an OrderedDict, which I think I'd need for an LRU cache. Skimming the current patch (od7.diff), I didn't notice one. Perhaps I simply missed something. Shouldn't popitem() allow the caller to choose which end from which to pop? Thinking it through a bit more, and LRU cache would actually need to access the oldest item before knowing whether to remove it. Besides, popitem() should probably retain the signature of dict.popitem(). I therefore retract my suggestion about popitem(). Still, I think an LRU cache would be a very common use case for an ordered dict. The current implementation already uses a list to keep track of order, which makes accessing the oldest key a simple matter of exposing it. Perhaps a new method like getfirst() would be worth while here? But you must decide if what you want really does LRU -- does accessing the oldest entry make it the most recent entry? --Scott David Daniels scott.dani...@acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Ext4 data loss
A.M. Kuchling wrote: With zipfile, you could at least access the .fp attribute to sync it (though is the .fp documented as part of the interface?). For this one, I'd like to add the sync as a method (so that Zip-inside- Zip is eventually possible). In fact, a sync on an exposed writable for a single file should probably push back out to a full sync. This would be trickier to accomplish if the using code had to suss out how to get to the fp. Clearly I have plans for a ZipFile expansion, but this could only conceivably hit 2.7, and 2.8 / 3.2 is a lot more likely. --Scott David Daniels scott.dani...@acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Non-Core project: IDLE
Guilherme Polo wrote: On Wed, Mar 18, 2009 at 8:53 PM, Terry Reedy wrote: IDLE needs lots of attention -- more than any one experienced person is likely to have I'm willing to step up as a student for this but I still have to write a good proposal for it. My actual concern is about mentor availability, is someone around interested on being an IDLE mentor ? You might want to talk to Bruce Sherwood, as VPython suffered through a bunch of Idle problems. I got the impression he had a person or two who were his Idle experts (so I am thinking they might be the mentors you are looking for). In any case, even a charter of "unit tests to 50% coverage" of Idle would be a huge improvement. I've run after specific bugs in Idle, but don't really know the lay of the land. --Scott David Daniels scott.dani...@acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] GPython?
Nick Coghlan wrote: Collin Winter wrote: That would be a bikeshed discussion of such magnitude, you'd have to invent new colors to paint the thing. Octarine. Definitely octarine :) I'm not so sure of the color itself, but its name should definitely rhyme with "orange." --Scott David Daniels scott.dani...@acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Evaluated cmake as an autoconf replacement
Greg Ewing wrote: Steve Holden wrote: Isn't it strange how nobody every complained about the significance of whitespace in makefiles: only the fact that leading tabs were required rather than just-any-old whitespace. Make doesn't care how *much* whitespace there is, though, only whether it's there or not. If it accepted anything that looks like whitespace, there would be no cause for complaint. Make and the *roff formats had the nasty feature that they treated homographs differently. That is, you could print two sources that placed all the same ink on the paper at the same places, but they would perform differently. For make it was tabs. For the *roff files, the periods ending sentences and the periods for abbreviations (such as honorifics) were distinguished by following end-of-sentence periods with two spaces. This left any line ending in a period ambiguous, and tools to strip whitespace off the end of lines as information-destroying. --Scott David Daniels scott.dani...@acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python-Dev Digest, Vol 69, Issue 143
Greg Ewing wrote:
Steven D'Aprano wrote:
it should be obvious in the same way that string concatenation is
different from numerical addition:
1 + 2 = 2 + 1
'1' + '2' != '2' + '1'
However, the proposed arithmetic isn't just non-
commutative, it's non-associative, which is a
much rarer and more surprising thing. We do
at least have
('1' + '2') + '3' == '1' + ('2' + '3')
But we don't have:
(1e40 + -1e40) + 1 == 1e40 + (-1e40 + 1)
Non-associativity is what makes for floating point headaches.
To my knowledge, floating point is at least commutative.
--Scott David Daniels
scott.dani...@acm.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Two proposed changes to float formatting
Mark Dickinson wrote: ... """[5] These numbers are fairly arbitrary. They are intended to avoid printing endless strings of meaningless digits without hampering correct use and without having to know the exact precision of floating point values on a particular machine.""" I don't find this particularly convincing, though---I just don't see a really good reason not to give the user exactly what she/he asks for here. As a user of Idle, I would not like to see the change you seek of having %f stay full-precision. When a number gets too long to print on a single line, the wrap depends on the current window width, and is calculated dynamically. One section of the display with a 8000 -digit (100-line) text makes Idle slow to scroll around in. It is too easy for numbers to go massively positive in a bug. - the change isn't gentle: as you go over the 1e50 boundary, the number of significant digits produced suddenly changes from 56 to 6; it would make more sense to me if it stayed fixed at 56 sig digits for numbers larger than 1e50. > - now that we're using David Gay's 'perfect rounding' >code, we can be sure that the digits aren't entirely >meaningless, or at least that they're the 'right' meaningless >digits. This wasn't true before. However, this is, I agree, a problem. Since all of these numbers should end in a massive number of zeroes, how about we replace only the trailing zeroes with the e, so we wind up with: 1157920892373161954235709850086879078532699846656405640e+23 or 115792089237316195423570985008687907853269984665640564.0e+24 or some such, rather than 1.157920892373162e+77 or 1.15792089237316195423570985008687907853269984665640564e+77 --Scott David Daniels scott.dani...@acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Two proposed changes to float formatting
Mark Dickinson wrote: > On Sun, Apr 26, 2009 at 8:11 PM, Scott David Daniels > wrote: >> As a user of Idle, I would not like to see the change you seek of >> having %f stay full-precision. When a number gets too long to print >> on a single line, the wrap depends on the current window width, and >> is calculated dynamically. One section of the display with a 8000 >> -digit (100-line) text makes Idle slow to scroll around in. It is >> too easy for numbers to go massively positive in a bug. > I had also said (without explaining: > > only the trailing zeroes with the e, so we wind up with: > > 1157920892373161954235709850086879078532699846656405640e+23 > > or 115792089237316195423570985008687907853269984665640564.0e+24 > > or some such, rather than > > 1.157920892373162e+77 > > or 1.15792089237316195423570985008687907853269984665640564e+77 These are all possible representations for 2 ** 256. > I see your point. Since we're talking about floats, thought, there > should never be more than 316 characters in a '%f' % x: the > largest float is around 1.8e308, giving 308 digits before the > point, 6 after, a decimal point, and possibly a minus sign. > (Assuming that your platform uses IEEE 754 doubles.) You are correct that I had not thought long and hard about that. 308 is livable, if not desireable. I was remebering accidentally displaying the result of a factorial call. >> However, this is, I agree, a problem. Since all of these numbers >> should end in a massive number of zeroes > > But they typically don't end in zeros (except the six zeros following > the point), > because they're stored in binary rather than decimal _but_ the printed decimal number I am proposing is within one ULP of the value of the binary numbery. That is, the majority of the digits in int(1e308) are a fiction -- they could just as well be the digits of int(1e308) + int(1e100) because 1e308 + 1e100 == 1e308 That is the sense in which I say those digits in decimal are zeroes. My proposal was to have the integer part of the expansion be a representation of the accuracy of the number in a visible form. I chose the value I chose since a zero lies at the very end, and tried to indicate I did not really care where trailing actual accuracy zeros get taken off the representation. The reason I don't care is that the code from getting a floating point value is tricky, and I suspect the printing code might not easily be able to distinguish between a significant trailing zero and fictitous bits. --Scott David Daniels scott.dani...@acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Two proposed changes to float formatting
ark Dickinson wrote: > On Sun, Apr 26, 2009 at 10:42 PM, Scott David Daniels wrote: >... >> I had also said (without explaining: >>>> only the trailing zeroes with the e, so we wind up with: >>>> 1157920892373161954235709850086879078532699846656405640e+23 >>>> or 115792089237316195423570985008687907853269984665640564.0e+24 >>>> or some such, rather than >>>> 1.157920892373162e+77 >>>> or 1.15792089237316195423570985008687907853269984665640564e+77 >> These are all possible representations for 2 ** 256. > > Understood. > >> _but_ the printed decimal number I am proposing is within one ULP of >> the value of the binary numbery. > > But there are plenty of ways to get this if this is what you want: if > you want a displayed result that's within 1 ulp (or 0.5 ulps, which > would be better) of the true value then repr should serve your needs. The representation I am suggesting here is a half-way measure between your proposal and the existing behvior. This representation addresses the abrupt transition that you point out (number of significant digits drops precipitously) without particularly changing the goal of the transition (displaying faux accuracy), without, in my (possibly naive) view, seriously complicating either the print-generating code or the issues for the reader of the output. To wit, the proposal is (A) for numbers where the printed digits exceed the accuracy presented, represent the result as an integer with an e+N, rather than a number between 1 and 2-epsilon with an exponent that makes you have to count digits to compare the two values, and (B) that the full precision available in the the value be shown in the representation. Given that everyone understands that is what I am proposing, I am OK with the decision going where it will. I am comforted that we are only talking about about four wrapped lines if we go to the full integer, which I had not realized. Further, I agree with you that there is an abrupt transition in represented accuracy as we cross from %f to %g, that should be somehow addressed. You want to address it by continuing to show digits, and I want to limit the digits shown to a value that reflects the known accuracy. I also want text that compares "smoothly" with numbers near the transition (so that greater-than and less-than relationships are obvious without thinking, hence the representation that avoids the "normalized" mantissa. . Having said all this, I think my compromise position should be clear. I did not mean to argue with you, but rather intended to propose a possible middle way that some might find appealing. --Scott David Daniels scott.dani...@acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ctime: I don't think that word means what you think it means.
Steven D'Aprano wrote: On Sun, 14 Jun 2009 10:40:53 am Greg Ewing wrote: Zooko Wilcox-O'Hearn wrote: 1. Add a "st_crtime" field which gets populated on filesystems (Windows, ZFS, Mac) which can do so. "crtime" looks rather too similar to "ctime" for my liking. People who think that the "c" in "ctime" means "creation" are still likely to confuse them. Why not give it a more explicit name, such as "st_creationtime"? My this bike-shed looks a bit greenish. How about: creation_time or, at least, st_creation_time Speaking as somebody who thought the c in ctime meant creation, I'm +1 on this proposal with Greg's modification. --Scott David Daniels scott.dani...@acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] io.BufferedReader.peek() Behaviour in python3.1
MRAB wrote: I was thinking along the lines of: def peek(self, size=None, block=True) If 'block' is True then return 'size' bytes, unless the end of the file/stream is reached; if 'block' is False then return up to 'size' bytes, without blocking I tend to prefer zero-ish defaults, how about: def peek(self, size=None, nonblocking=False) We still don't have "at most one read" code, but something a bit like data = obj.peek(size=desired, nonblocking=True) if len(data) < desired: data = obj.peek(size=wanted, nonblocking=False) might suffice. --Scott David Daniels scott.dani...@acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r73569 - peps/trunk/pep-0101.txt
While we are on that, I just noticed: http://www.python.org/download/releases/3.1/ Has downloads for 3.1rc2, but show checksums as if for 3.1rc1 The size and checksum is correct for python-3.1rc2.msi, distinct from that for python-3.1rc1.msi, but are labeled as rc1. The 32-bit .msi is the only one of the four I checked; I suspect the other three are similarly mislabeled. --Scott David Daniels scott.dani...@acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 376
Tarek Ziadé wrote: On Tue, Jun 30, 2009 at 8:37 PM, Paul Moore wrote: [1] I'd actually like it if the PEP defined an uninstall command - something like "python -m distutils.uninstall packagename". It can be as minimalist as you like, but I'd like to see it present. it's already there: http://www.python.org/dev/peps/pep-0376/#adding-an-uninstall-function That (at least as I read it) is a function, not a command. If it is a command, give an example of its use from the command line for us poor "don't want to research" people. If the following works: $ python setup.py uninstall some_package Then explicitly say so for us poor schlubs. --Scott David Daniels scott.dani...@acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 376
Kevin Teague wrote: On Jun 30, 2009, at 4:46 PM, Tarek Ziadé wrote: On Tue, Jun 30, 2009 at 10:06 PM, Scott David Daniels wrote: Tarek Ziadé wrote: On Tue, Jun 30, 2009 at 8:37 PM, Paul Moore wrote: [1] I'd actually like it if the PEP defined an uninstall command - something like "python -m distutils.uninstall packagename". It can be as minimalist as you like, but I'd like to see it present. it's already there: http://www.python.org/dev/peps/pep-0376/#adding-an-uninstall-function That (at least as I read it) is a function, not a command. If it is a command, give an example of its use from the command line for us poor "don't want to research" people. If the following works: $ python setup.py uninstall some_package Then explicitly say so for us poor schlubs. Right, I'll add that. Although it will be a reference implementation only. Uninstall as a command feels a little weird I dunno what the right solution is. My two-cents is either to punt and only include an uninstall function as currently proposed, or for only supporting some form of the "python setup.py uninstall" style But for us poor schlubs, we want you brilliant packagers to actually come to a hard decision. If you want approval either admit you have no solution in the PEP (and detail the issues that prevent a decision), provide a minimally acceptable command, or expect that nobody sees the value of what you propose --Scott David Daniels scott.dani...@acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 376
Antoine Pitrou wrote: Guido van Rossum python.org> writes: I noted an inconsistency: first you say that the RECORD file uses the excel dialect, but at the end of the same section you say it uses the default csv settings. Sounds like you need to delete one or the other. If I remember correctly, the default csv dialect is just the Excel dialect, so this would be two different ways of saying the same things. Right, but Guido's point is, decide which one is the is the definition and stick to talking about it in that form. --Scott David Daniels scott.dani...@acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Current patch process question
I am confused by the current hydra-like development. I've recently submitted a change (issue6422 -- a feature request) which is currently moving through the process. I am not particularly asking for special attention on that issue, but I am confused about the process I should be using (in the face of two trunks). There seem to be two places to plausibly introduce a change: py3k and trunk. Should I submit changes for trunk, py3k, or both? I tried asking in the initial feature request, but nobody replied, and I finally decided that I'd go for patching trunk in the interim. For myself, I'd like to know if I should add a patch file for the py3k branch, or will that simply make more work for someone else? Certainly it will be easier for me to do this sooner rather than later. For the wider group, how should I have known the answer to these questions? Is there some page I overlooked? Is there a better forum in which to ask this question? --Scott David Daniels scott.dani...@acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Current patch process question
Martin v. Löwis wrote: There seem to be two places to plausibly introduce a change: py3k and trunk. Should I submit changes for trunk, py3k, or both? Patches are usually first checked into trunk, and then svnmerge'd to py3k. So it makes more sense to submit your patch against trunk. For myself, I'd like to know if I should add a patch file for the py3k branch, or will that simply make more work for someone else? If porting the patch to py3k is trivial, you shouldn't care. svnmerge will take care of it. If, on the other hand, porting your patch requires many changes, or delicate ones, providing a patch against py3k can make the committer's life easier. I usually abstain from "me too" messages, but only this time: as Antoine says. Thanks to both of you for the quick response. In this case, the port should be dirt simple, so I'll consider myself done until comments come back on the patch. --Scott David Daniels scott.dani...@acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] random number generator state
I find I have a need in randomized testing for a shorter version of getstate, even if it _is_ slower to restore. When running exhaustive tests, a failure report should show the start state of the generator. Unfortunately, our current state includes a 625-element array. I want a state that can be read off a report and typed in to reproduce the state. Something a bit like the initial seed, a count of cycle calls, and a few other things. So, in addition to .getstate() and .setstate(...), I'd at least need to have .get_slow_state() and possibly expand what .setstate(...) takes. However, a call to .setstate should reset the counter or all is for naught. That means I need to change the results of .getstate, thus giving me three kinds of input to .setstate: old, new-short, and new-long. In trying to get this to work, I found what might be a bug: code says mt[0] = 0x8000UL; /* MSB is 1; assuring non-zero initial array */ but probably should be: mt[0] |= 0x8000UL; /* MSB is 1; assuring non-zero initial array */ In checking into that issue, I went to the original Mersenne-Twister code, and I see the original authors are pursuing a newer generator, dSFMT. I now have a dilemma. Should I continue the work on the original M-T code (which is now seeming problematic for compatibility) or simply make a new generator with similar calls using dSFMT and put the new feature in that where there is no compatibility problem. Which would be more useful for the Python community? --Scott David Daniels scott.dani...@acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] random number generator state
Raymond Hettinger wrote: [Scott David Daniels] I find I have a need in randomized testing for a shorter version of getstate, even if it _is_ slower to restore. [blah about big state] Sounds like you could easily wrap the generator to get this. It would slow you down but would give the information you want. Well, I was thinking that this might be generally useful for randomized testing. I think it would be a mistake to complexify the API to accomodate short states -- I'm not even sure than they are generally useful (recording my initial seed and how many cycles I've run through is only helpful for sequences short enough that I'm willing to rerun them). Right, that was what I was asking about. The complexity of the change grew on me; I hadn't realized at the outset it would be more than adding a counter internally. Consider me officially dissuaded. I'm curious what your use case is. Why not just record the the sequence as generated -- I don't see any analytic value to just knowing the initial seed and cycle count. I'm building data structures controlled by an rng, and then performing sequences of (again randomly controlled) operations on those data structures, check all invariants at each step. I then lather, rinse, repeat recording the start of each failing experiment. In the morning I come in and look for commonality in the cases I see. Having the short state means I means I can easily rebuild the data structure and command list to see what is going on. I prune commands, simplify the tree, and thus isolate the problem I found. I did enough experimenting to see that if I simply provide access to run N cycles of the block, I can actually do 2**32 cycles in feasible time, so I have a pair of counters, and the code should take long enough for eternity to show up before the wrap. My short state is: seed, block_index, cycles_low, cycles_high, floating (block_index + 625 * (cycles_low + (cycles_high << 32)) is the position, and could be done as such; the pieces reflect the least-expensive cost in performance to the rng. floating is simply the same final floating piece that the state keeps now. Ability to print out a short state implies that you are using only a small subset of possible states (i.e. the ones you can get to with a short seed). Well, as you see above, I do capture the seed. I realize that the time- constructed seeds are distinct from identically provided values as small ints, and I also mark when the rng gets called by set_state to indicate that I then know nothing about the seed. >> mt[0] = 0x8000UL; /* MSB is 1; assuring non-zero initial array */ >> but probably should be: >> mt[0] |= 0x8000UL; /* MSB is 1; assuring non-zero initial array*/ > Please file a bug report for this and assign to me Also, our > tests for MT exactly reproduce their published test sequence. > I've been assured it is not a bug, and I filed no report since I had just arrived at the point of suspicion. To summarize, I am officially dissuaded, and will post a recipe if I get something nice working. --Scott David Daniels scott.dani...@acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Retrieve an arbitrary element from a set without removing it
John Arbash Meinel wrote:
res = heads(node1, node2)
if len(res) == 1:
# What is the 'obvious' way to get the node out?
I posit that there *isn't* an obvious way to get the single item out of
a 1-entry frozenset.
for x in res: break
list(res)[0]
set(res).pop()
iter(res).next()
[x for x in res][0]
x, = res # I didn't think of this one before recently
Are all answers, but none of them I would consider *obvious*.
And from my SQL-hacking experience:
x = min(s)
--Scott David Daniels
scott.dani...@acm.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Signals, threads, blocking C functions
Johan Dahlin wrote: > Nick Maclaren wrote: >> "Gustavo Carneiro" <[EMAIL PROTECTED]> wrote: >>> I'm pretty sure writing to a pipe is async signal safe. It is the >>> oldest trick in the book, everyone uses it. I ... know that it works. >> Ah. Well, I can assure you that it's not the oldest trick in the book, >> and not everyone uses it. > ... > Can't this just be enabled for platforms where it's known to work and let > Python as it currently is for the users of these legacy systems ? Ah, but that _is_ the current state of affairs. .5 :-) -- Scott David Daniels [EMAIL PROTECTED] ___ 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] Tix not included in 2.5 for Windows
Christos Georgiou wrote: > Does anyone know why this happens? I can't find any information pointing to > this being deliberate. > > I just upgraded to 2.5 on Windows (after making sure I can build extensions > with the freeware VC++ Toolkit 2003) and some of my programs stopped > operating. I saw in a French forum that someone else had the same problem, > and what they did was to copy the relevant files from a 2.4.3 installation. > I did the same, and it seems it works, with only a console message appearing > as soon as a root window is created: Also note: the Os/X universal seems to include a Tix runtime for the non-Intel processor, but not for the Intel processor. This makes me think there is a build problem. -- Scott David Daniels [EMAIL PROTECTED] ___ 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] Tix not included in 2.5 for Windows
Bob Ippolito wrote:
> On 9/30/06, Scott David Daniels <[EMAIL PROTECTED]> wrote:
>> Christos Georgiou wrote:
>>> Does anyone know why this happens? I can't find any information pointing to
>>> this being deliberate.
>> Also note: the Os/X universal seems to include a Tix runtime for the
>> non-Intel processor, but not for the Intel processor. This
>> makes me think there is a build problem.
>
> Are you sure about that? What file are you referring to specifically?
OK, from the 2.5 universal: (hand-typed, I e-mail from another machine)
=== Using Idle ===
>>> import Tix
>>> Tix.Tk()
Traceback (most recent call last):
File "(pyshell#8)", line 1, in (module)
Tix.Tk()
File "/Library/Frameworks/Python.framework/Versions/2.5/
lib/python2.5/lib-tk/Tix.py", line 210 in __init__
self.tk.eval('package require Tix')
TclError: no suitable image found. Did find:
/Library/Tcl/Tix8.4/libTix8.4.dylib: mach-o, but wrong architecture.
=== From the command line ===
>>> import Tix
>>> Tix.Tk()
Traceback (most recent call last):
File "", line 1, in (module)
File "/Library/Frameworks/Python.framework/Versions/2.5/
lib/python2.5/lib-tk/Tix.py", line 210 in __init__
self.tk.eval('package require Tix')
_tkinter.TclError: no suitable image found. Did find:
/Library/Tcl/Tix8.4/libTix8.4.dylib: mach-o, but wrong architecture.
-- Scott David Daniels
[EMAIL PROTECTED]
___
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)
James Y Knight wrote:
> On Oct 3, 2006, at 8:30 AM, Martin v. Löwis wrote:
>> As Michael Hudson observed, this is difficult to implement, though:
>> You can't distinguish between -0.0 and +0.0 easily, yet you should.
>
> Of course you can. It's absolutely trivial. The only part that's even
> *the least bit* sketchy in this is assuming that a double is 64 bits.
> Practically speaking, that is true on all architectures I know of,
> and if it's not guaranteed, it could easily be a 'configure' time check.
>
> typedef union {
> double d;
> uint64_t i;
> } rawdouble;
>
> int isposzero(double a) {
> rawdouble zero;
> zero.d = 0.0;
> rawdouble aa;
> aa.d = a;
> return aa.i == zero.i;
> }
>
> int main() {
> if (sizeof(double) != sizeof(uint64_t))
> return 1;
>
> printf("%d\n", isposzero(0.0));
> printf("%d\n", isposzero(-0.0));
>
> }
>
And you should be able to cache the single positive zero
with something vaguely like:
PyObject *
PyFloat_FromDouble(double fval)
{ ...
if (fval == 0.0 && raw_match(&fval, cached)) {
PY_INCREF(cached);
return cached;
}
...
--
-- Scott David Daniels
[EMAIL PROTECTED]
___
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] splitext('.cshrc')
Martin v. Löwis wrote:
> Phillip J. Eby schrieb:
>> I consider it correct, or at the least, don't think it should be
>> changed, as it would make the behavior more difficult to reason about
>> and introduce yet another thing to worry about when writing
>> cross-version code.
>
> Now it's becoming difficult: several people in favor, some opposed...
>
> I'll wait a bit longer, but will still likely commit it, unless
> opposition gets stronger: If the current behavior is incorrect
> (in the sense that it contradicts wide-spread intuition), then
> an application worrying about this detail should surely make the
> 2.6 behavior also appear in 2.5 and earlier.
>
> I'm not sure what people actually use splitext for: I guess there
> are two applications:
> a) given a list of file names, give me all those belonging to a
> hard-coded list of extensions (e.g. .py, .pyc, .c, .h). These
> won't break, since they likely won't search for "all files
> ending in .bash_profile" - there is only one per directory,
> and if the want it, they use the entire filename.
> b) given a list of file names, classify them for display (the
> way the Windows explorer works, and similar file managers).
> They use MIME databases and the like, and if they are unix-ish,
> they probably reject the current splitext implementation already
> as incorrect, and have work-arounds. As these files now show
> up with "no extension", I rather expect that the work-around
> won't trigger, and the default behavior will be the correct one.
c) Given a filename, make an appropriately named associated file.
pyo_name = os.path.splitext(name)[0] + '.pyo'
This argues for os.path.splitext('.pythonrc') == ('.pythonrc','')
--
-- Scott David Daniels
[EMAIL PROTECTED]
___
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] Contributing to Python
Guido van Rossum wrote: > On Jan 5, 2008 2:36 PM, Christian Heimes <[EMAIL PROTECTED]> wrote: >> A patch should contain edits for Misc/NEWS. Patches without >> documentation and NEWS updates costs the committer more time >> and reduces the likelihood of a commit. >> >> Even a perfect patch costs several minutes of our life time. >> The patch must be reviewed, applied, compiled, the entire unit >> test suite must pass and finally it must be committed and the >> issues needs to be closed, too. > > Several minutes?! The average "perfect" patch costs me more like > between half an hour and an hour. > QOTW. I think this excerpt should show up in the new developer area. --Scott David Daniels [EMAIL PROTECTED] ___ 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] Do we need both Trac and Roundup?
[EMAIL PROTECTED] wrote: > Do people think it would be worthwhile to merge the Trac tracker content > (the issue tracker that holds tickets related to the python.org website) > into the Roundup tracker (the issue tracker that holds tickets related to > Python the language)? While they are nominally distinct activities, it > seems to me that we must waste some precious resources (mostly people) > maintaining two mostly disjoint trackers. I think it would be a great idea. As I try to get back up on a new, "privacy=paranoid" machine, I went to mention that somewhere in the logging in process, there should be an indication of how much your box must be opened up before you can "log on," at least in the screen you get to when you log on. However, each time I went to enter such a note, I needed to "log on." I just gave up. -Scott David Daniels [EMAIL PROTECTED] ___ 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] pkgutil, pkg_resource and Python 3.0 name space packages
Reed O'Brien wrote: > On Jan 9, 2008, at 1:48 AM, Jeroen Ruigrok van der Werven wrote: >> -On [20080108 17:07], Christian Heimes ([EMAIL PROTECTED]) wrote: >>> Python's _winreg module and pywin32 expose several functions to >>> get the paths from the registry but I don't think it has a simple >>> function like get_mydocuments(). >> Careful with the name though. Microsoft Windows Vista did away with >> 'My Documents & Settings'. It is now C:\Users. >> >> So you get: >> C:\Users\\AppData\Local\ (former Local Settings\Application Data) >> C:\Users\\AppData\Roaming\ (former Application Data) >> C:\Users\\Documents(former My Documents) >> C:\Users\\Music(former My Music) >> C:\Users\\Pictures (former My Pictures) >> C:\Users\\Videos (former My Videos) > yay, next up posix support I suspect that the whole thing was done to make sure that developers of applications could: A: cope with stupidly long path names. V: cope with spaces in path names. I bet they never intended to keep the huge names, just to make you cope with them. --Scott David Daniels [EMAIL PROTECTED] ___ 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] Rational approximation methods
Jeffrey Yasskin wrote: > The second returns the simplest rational within some distance. For > instance, it'll prefer 22/7 over 333/106 if both are close enough. We > might call it .simplest_within() for now. This seems useful for > converting from float and displaying results to users, where we prefer > readability over accuracy or have reason to believe that a simpler > fraction might be more correct. You can use a mediant walk to get to two surrounding fractions w/ some limit, and then return the pair to let the caller choose. See http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/52317 for an imperfect implementation. ___ 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] py3k: print function treats sep=None and end=None in an unintuitive way
Alessandro Guido wrote:
> Nick Coghlan wrote:
> Eric Smith wrote:
>> Because None means 'use the default value'. You probably want:
>> print('a', 'b', sep='', end='')
>
> I think this is a "not optimally designed" API
> because you have to read the documentation to understand why
Excuse me, I don't know about you, but I don't mind a language
with a document to consult. I actually wasn't born understanding
_any_ computer (or for that matter natural) language.
0Scott David Daniels
[EMAIL PROTECTED]
___
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 8: Discourage named lambdas?
Mike Klaas wrote: ... A common pattern for me is to replace an instances method with a lambda to add monitoring hooks or disable certain functionality: inst.get_foo = lambda: FakeFoo() This is not replacable in one line with a def (or without locals() detritius). Assuming this is good style, it seems odd that inst.get_foo = lambda: FakeFoo() is acceptible style, but get_foo = lambda: FakeFoo() But surely, none of these are great style, and in fact the lambda lures you into using it. I'd propose a far better use is: inst.get_foo = FakeFoo or get_foo = FakeFoo --Scott David Daniels [EMAIL PROTECTED] ___ 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] Update bz2 library?
I just noticed that the bz2lib version was updated to 1.0.5 in December of 2007, for security reasons. I suspect it would be good to be sure to ship this with 2.6 or 3.0. --Scott David Daniels [EMAIL PROTECTED] ___ 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: Frequently-requested additional features for the `unittest` module
Ben Finney wrote:
...
def assert_compare_true(op, first, second, msg=None):
if msg is None:
msg = "%(first)r %(op)r %(second)" % vars()
if not op(first, second):
raise self.failure_exception(msg)
I would rather something more like:
def assert_compare_true(op, first, second, msg=None):
if op(first, second):
return
raise self.failure_exception(msg)
if msg is None:
self.failure_exception("%(first)r %(op)r %(second)"
% vars())
self.failure_exception("%(first)r %(op)r %(second): %(msg)"
% vars())
--Scott David Daniels
[EMAIL PROTECTED]
___
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: Frequently-requested additional features for the `unittest` module
Ben Finney wrote:
Scott David Daniels <[EMAIL PROTECTED]> writes:>
I would rather something more like:
def assert_compare_true(op, first, second, msg=None):
if op(first, second):
return
raise self.failure_exception(msg)
if msg is None:
self.failure_exception("%(first)r %(op)r %(second)"
% vars())
self.failure_exception("%(first)r %(op)r %(second): %(msg)"
% vars())
I'm confused. It appears to me that your version never gets past the
first 'raise' statement, which is unconditional; and the rest seems to
do nothing but instantiate exceptions without using them.
Sorry, I was too hasty last time (had to jet out of the house) and sent
out the unfinished version. This is what I meant:
def assert_compare_true(op, first, second, msg=None):
if op(first, second):
return
if msg is None:
raise self.failure_exception(
"%(first)r %(op)r %(second)" % vars())
raise self.failure_exception(
"%(first)r %(op)r %(second): %(msg)" % vars())
(1) Displaying args is the whole point, otherwise just use assert_.
This form fosters tests that say what is wrong, and not simply
_that_ something has gone wrong.
The point is a readable test, reducing boilerplate at the
call location. Something like:
...
self.assert_le(sum(source) // len(source), 5, "Mean OK")
(2) No point to doing string conversion except on failure; slow
__repr__ methods are fine to use if the result is not discarded.
--Scott David Daniels
[EMAIL PROTECTED]
___
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: Frequently-requested additional features for the `unittest` module
Ben Finney wrote: Michael Foord <[EMAIL PROTECTED]> writes: The full list of changes proposed […] and not shot down was something like: […] assertLessThan assertGreaterThan assertLessThanOrEquals assertGreaterThanOrEquals […] "Brett Cannon" <[EMAIL PROTECTED]> writes: Is any of this really necessary? Isn't this the equivalent of ``assert_(a < b)``? It seems like the only thing you get out of this is a nicer error message, but ``assert_(a < b, 'not %r <= %s' % (a, b))`` is not that complex. And do these cases really come up that often? I would want to see some numbers showing that these are really necessary (in both usage and people even specifying an error message in the first place). Though I'm the champion of this PEP, I'll have to refer to Michael Foord for his reasoning (or reference to others' reasoning) on this. My reasoning goes something like this: self.assertLessThan(abs(self.base.method(parm1, parm2) - self.base.nominal), 2.54, 'Within an inch') vs. distance = self.base.method(parm1, parm2) deviation = self.base.method(parm1, parm2) - self.base.nominal self.assert_(abs(deviation) < 2.54, '%s is %s out of spec (more ' 'than an inch)' % (distance, deviation) It is not so much the assertion on values in variables, as it is assertions on results of calculations. Unfortunately, my tendency would be to forgo the "within an inch" over extracting the values into locals for the purpose of the test; the tests I'm writing currently focus on the manipulation of hardware for the reader, not on the extraction of data for the purpose of testing. Some of the longer sections are already nearly a couple of pages long; that's how much code it takes to do a coherent operation on this particular hardware. I hate that I am using 2 pages now (half a page per is what I'd prefer), and I'm not willing to bloat the operation with more code. As a result, I implemented my own versions of these asserts (Le, Lt, ...) a year or so ago, and still find them so useful that I'll re-implement them where- ever I am working without similar tests available. --Scott David Daniels [EMAIL PROTECTED] ___ 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] Weak Dictionary Iteration Behavior in Python 3
Josiah Carlson wrote: On Sat, Sep 13, 2008 at 1:20 PM, Armin Ronacher wrote: Iterating over weak key dictionaries might not be the most common task but I know some situations where this is necessary. Unfortunately I can't see a way to achieve that in Python 3. i = list(d.keys()) Surely i = list(d) is a more reasonable way to do this. I seldom find a reason to use .keys --Scott David Daniels [EMAIL PROTECTED] ___ 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] Possible issue in warnings.py
Does someone who knows the design of warnings.py a bit better than I know whether it would be an improvement to switch from: > try: > file.write(formatwarning(message, category, filename, > lineno, line)) > except IOError: > pass # the file (probably stderr) is invalid > # - this warning gets lost. to: > complaint = formatwarning(message, category, filename, > lineno, line) > try: > file.write(complaint) > except IOError: > pass # the file (probably stderr) is invalid > # - this warning gets lost. on the grounds that you might not want failures in the linecache code to behave the same as failures in writing the complaint to the target area? I'm working on a patch where the Idle warnings code seems to accidentally escalating warnings into errors, and it looked to me like this would accidentally swallow errors getting warning context and make them fail silently. The Idle issue that I'm fiddling with is that it doesn't take the new showwarning call format, and it looked like this should possibly be fixed at the same time. --Scott David Daniels [EMAIL PROTECTED] ___ 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] Redirecting warnings.showwarning to logging
Vinay Sajip wrote: Brett Cannon has suggested [1] that the logging package should provide an implementation of warnings.showwarning which redirects to logging. Here are my first thoughts about how this might work: A new function, showwarning( message, category, filename, lineno[, file]) will be added to the logging package. To redirect all warnings to the logging system, it will only be necessary to do the following: warnings.showwarning = logging.showwarning The implementation of logging.showwarning will call formatwarning(message, category, filename, lineno) and will log the resulting string to a warnings logger named "stdlib.warnings" (or perhaps "std.warnings") with level logging.WARNING. The optional file argument to logging.showwarning is only for signature compatibility with warnings.showwarning and will be ignored; in order to configure logging of warnings to any particular destination, the logging configuration will need to add appropriate handlers to the warnings logger. The precise format of the logging message will be determined by the logging configuration in effect, i.e. any formatters configured for the handlers attached to the logger. Match the new warning protocol exactly: def showwarning(message, category, filename, lineno, file=None, line=None): ... If the line is not None, use it (which will happen if you pass it along to showwarning). If the line is None and file is not None, use file to get to your line, rather than opening the filename which may not work. and: def formatwarning(message, category, filename, lineno, line=None): ... Having chased problems around in idle code for a bit, I can assure you that more code than you suspect calls warnings.formatwarning and warnings.showwarning. If you get it wrong, a deprecation warning can prevent a module like md5 from loading (for example). --Scott David Daniels [EMAIL PROTECTED] ___ 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] Redirecting warnings.showwarning to logging
Scott David Daniels wrote:
>
> Match the new warning protocol exactly:
> def showwarning(message, category, filename, lineno,
> file=None, line=None):
> ...
> If the line is not None, use it (which will happen if you pass it
> along to showwarning).
> If the line is None and file is not None, use file to get to your
> line, rather than opening the filename which may not work.
>
Sorry, this had no sooner left my terminal than I realized that the file
argument is the output target, and nothing to do with fetching source.
I'd not put the data into the log if file is provided, because it may
be code trying to extract output formatting.
I'd do something like this:
if file is not None:
old_showwarning(message, category, filename, lineno, file, line)
return
at the top of the code.
--Scott David Daniels
[EMAIL PROTECTED]
___
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] extremely slow exit for program having huge (45G) dict (python 2.5.2)
Mike Coleman wrote: ... Regarding interning, I thought this only worked with strings. Is there some way to intern integers? I'm probably creating 300M integers more or less uniformly distributed across range(1)? held = list(range(1)) ... troublesome_dict[string] = held[number_to_hold] ... --Scott David Daniels scott.dani...@acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] A wart which should have been repaired in 3.0?
Jeff Hall wrote: ... For those that prefer not to add functions all willy-nilly, would it not be better to add a "delimiter" keyword that defaults to False? Then "delimiter=False" will function with the current functionality unchanged while os.path.commonprefix(["bob/export/home", "bob/etc/passwd"], delimiter = "/") The proper call should be: os.path.commonprefix(["bob/example", "bob/etc/passwd"], delimiter=True) and output: 'bob' (path to the common directory) Perhaps even call the keyword arg "delimited," rather than "delimiter." On Windows, I'd like to see: os.path.commonprefix(['a/b/c.d/e'f', r'a\b\c.d\eve'], delimited=True) return either 'a/b/c.d' or r'a\b\c.d' Perhaps even ['a', 'b', 'c.d'] (suitable for os.path.join). --Scott David Daniels scott.dani...@acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] A wart which should have been repaired in 3.0?
Paul Moore wrote:
2008/12/30 Phillip J. Eby :
You know, all this path separator and list complication isn't really
necessary, when you can just take the os.path.dirname() of the return from
commonprefix()
Actually, consider: ...
os.path.commonprefix(["foo\\bar\\baz", "foo/bar/boink"])
'foo'
... I'm not sure how to deal with this, except by recommending that all
paths passed to os.path.commonprefix should at the very least be
normalised via os.path.normpath first - which starts to get clumsy
fast. So the "recommended" usage to get the common directory is
paths = [...]
common = os.path.dirname(os.path.commonprefix([
>os.path.normpath(p) for p in paths]))
More trouble with the "just take the dirname":
paths = ['/a/b/c', '/a/b/d', '/a/b']
os.path.dirname(os.path.commonprefix([
os.path.normpath(p) for p in paths]))
give '/a', not '/a/b'.
--Scott David Daniels
scott.dani...@acm.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3.0.1 (io-in-c)
Raymond Hettinger wrote: [Antoine Pitrou] Now here are some performance figures. Text I/O is done in utf-8 with universal newlines enabled: That's a substantial boost. How does it compare to Py2.x equivalents? Comparison of three cases (including performance rations): MB/S MB/SMB/S in C in py3k in 2.7 C/3k 2.7/3k ** Binary append ** 10M write 1e6 units at a time 1529.00 728.000 1523.000 2.10 2.09 20K write one unit at a time 0.668 0.1500.887 4.45 5.91 400K write 20 units at a time 12.200 2.880 15.800 4.24 5.49 400K write 4096 units at a time 722.00 346.000 1071.000 2.09 3.10 ** Binary input ** 10M read whole contents at once 980.00 274.000 966.000 3.58 3.53 20K read whole contents at once 924.00 443.000 1145.000 2.09 2.58 400K alternate read & seek 1000 units 490.000 81.200 563.000 6.03 6.93 400K alternate read & seek one unit 1.330 0.0821.11 16.20 13.52 400K read 20 units at a time 27.200 3.440 29.200 7.91 8.49 400K read 4096 units at a time845.00 246.000 1038.000 3.43 4.22 400K read one unit at a time1.64 0.1741.480 9.43 8.51 400K read whole contents at once 883.00 216.000 891.000 4.09 4.13 400K seek forward 1000 units a time 516.00 182.000 568.000 2.84 3.12 400K seek forward one unit at a time0.528 0.1880.893 2.81 4.75 ** Binary overwrite ** 20K modify one unit at a time 0.677 0.1230.867 5.50 7.05 400K alternate read & write 1000 unit 276.000 41.100 153.000 6.72 3.72 400K alternate read & write one unit0.827 0.0450.22 18.46 4.93 400K alternate write & seek 1000 unit 173.000 71.400 151.000 2.42 2.11 400K alternate write & seek one unit0.212 0.0820.237 2.60 2.90 400K modify 20 units at a time 12.100 2.340 15.300 5.17 6.54 400K modify 4096 units at a time 382.00 213.000 446.000 1.79 2.09 ** Text append ** 10M write 1e6 units at a time261.00 218.000 1540.000 1.20 7.06 20K write one unit at a time 0.983 0.0811.33 12.08 16.34 400K write 20 units at a time 16.000 1.510 22.90 10.60 15.17 400K write 4096 units at a time 236.00 118.000 1244.000 2.00 10.54 ** Text input ** 10M read whole contents at once 89.700 68.700 966.000 1.31 14.06 20K read whole contents at once 108.000 70.500 1196.000 1.53 16.96 400K read 20 units at a time 29.200 3.800 28.400 7.68 7.47 400K read 4096 units at a time 97.400 34.900 1060.000 2.79 30.37 400K read one line at a time 71.700 3.690 207.00 19.43 56.10 400K read one unit at a time2.280 0.2181.41 10.46 6.47 400K read whole contents at once 112.000 81.000 841.000 1.38 10.38 400K seek forward 1000 units at a time 87.400 67.300 589.000 1.30 8.75 400K seek forward one unit at a time0.090 0.0710.873 1.28 12.31 ** Text overwrite ** 20K modify one unit at a time 0.296 0.0721.320 4.09 18.26 400K modify 20 units at a time 5.690 1.360 22.500 4.18 16.54 400K modify 4096 units at a time 151.000 88.300 509.000 1.71 5.76 --Scott David Daniels scott.dani...@acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Partial function application 'from the right'
Antoine Pitrou wrote: ... In py3k, we could also use "..." (the Ellipsis object) to denote places where an argument is missing, so that: split_comma = partial(str.split, ..., ',') would do what you want. Thus preventing any use of partial when an argument could be an the Ellipsis instance. --Scott David Daniels scott.dani...@acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Partial function application 'from the right'
s...@blueyonder.co.uk wrote: Hi all, On Thu, Jan 29, 2009 at 6:12 AM, Ben North wrote: I find 'functools.partial' useful, but occasionally I'm unable to use it because it lacks a 'from the right' version. -1 For me, the main objection to a partial that places its stored positional arguments from the right is that you don't know which positions those arguments will actually occupy until the partial is called. Certainly this interacts in a magical way with keyword args. That definitional problem is the reason there was no curry_right in the original recipe that was the basis of the first partial. If you have: def button(root, position, action=None, text='*', color=None): ... ... blue_button = partial(button, my_root, color=(0,0,1)) Should partial_right(blue_button, 'red') change the color or the text? It is computationally hard to do that (may have to chase chains of **kwarg-passing functions), but even hard to document. So, I'd avoid it. --Scott David Daniels scott.dani...@acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The interpreter accepts f(**{'5':'foo'}); is this intentional?
Christian Heimes wrote: ... The performance penalty is slime to nothing for the common case Sorry, I love this typo. -Scott ___ 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: MS VC compiler versions
M.-A. Lemburg wrote: Here's an update of the list I currently have: * MS VS6 SP5 (International version, optimizing VC6 compiler with SP5): Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 12.00.8168 for 80x86 Copyright (C) Microsoft Corp 1984-1998. All rights reserved. * MS VC6 (German version; optimizing VC6 compiler with SP6): Optimierender Microsoft (R) 32-Bit C/C++-Compiler, Version 12.00.8804, fuer x86 Copyright (C) Microsoft Corp 1984-1998. Alle Rechte vorbehalten. * MS VC6 (US version; optimizing VC6 compiler with SP6): Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 12.00.8804 for 80x86 Copyright (C) Microsoft Corp 1984-1998. All rights reserved. * MS .NET SDK 1.1 Compiler (German version; non-optimizing VC7.1 compiler): Microsoft (R) 32-Bit C/C++-Standardcompiler Version 13.10.3077 für 80x86 Copyright (C) Microsoft Corporation 1984-2002. Alle Rechte vorbehalten. * MS VC7.1 (aka .NET 2003, German version; optimizing VC7.1 compiler) Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.10.3077 for 80x86 Copyright (C) Microsoft Corporation 1984-2002. All rights reserved. * MS Windows XP DDK (International version, optimizing VC 7.0): Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.00.9176 for 80x86 Copyright (C) Microsoft Corporation 1984-2001. All rights reserved. Does someone have the details for the MS Toolkit compiler ? Thanks, \Program Files\Microsoft Visual C++ Toolkit 2003\bin\cl.exe: Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.10.3077 for 80x86 Copyright (C) Microsoft Corporation 1984-2002. All rights reserved. -- -- Scott David Daniels [EMAIL PROTECTED] ___ 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.4 news reaches interesting places
Oleg Broytmann wrote: Raymond Hettinger wrote: * Python's website has traditionally been self-centered, leaving others to have to make the case for their own products. Perhaps, it is time to change that. Those who really care about speed cannot make a balanced decision about Python without considering psyco, pyrex, numpy, and the like as part of the total development environment. That's overreaction, I think. People always say this and that about python - python is slow, and python is not like java, and python does not have static type checks... And what? Should the webmasters adapt the site to every complain? Perhaps a link on the main page to a "for even more speed" page where we can combine advice on how to improve application performance (measure, abstract, choose good data structures) with references to these other projects for particular applications. This is the place to say things like "operating on every character of a string is seldom efficient." -- -- Scott David Daniels [EMAIL PROTECTED] ___ 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: proto-pep: How to change Python's bytecode
Brett C. wrote: A few things can be done to make sure that development goes smoothly when experimenting with Python's bytecode. One is to delete all .py(c|o|w) Don't you mean ".pyc or .pyo (remember such files in zips as well)" .pyw is normal python source. -- Scott David Daniels [EMAIL PROTECTED] ___ 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: proto-pep: How to change Python's bytecode
Brett C. wrote: Terry Reedy wrote: "Brett C." <[EMAIL PROTECTED]> wrote Over the last several years, various people have reported experimenting with CPython's bytecodes. I wonder if it would be helpful to have a respository of the results, in one place, for new experimenters and curious people to peruse. Wouldn't hurt. Adding that section would not be bad, but I don't have the inclination to hunt them down. What do others think about having this section? What you could do is declare a wiki page which anyone could go to; less work for you, and forms a new place to pool knowledge. -- Scott David Daniels [EMAIL PROTECTED] ___ 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] Zipfile needs?
I'm hoping to add BZIP2 compression to zipfile for 2.5. My primary motivation is that Project Gutenberg seems to be starting to use BZIP2 compression for some of its zips. What other wish list things do people around here have for zipfile? I thought I'd collect input here and make a PEP. I can open a pseudo-file for STORED files in binary read mode, for example, to allow reading zip-in-zip files without fully occupying memory. -- Scott David Daniels [EMAIL PROTECTED] ___ 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: Zipfile needs?
Josiah Carlson wrote: Scott David Daniels <[EMAIL PROTECTED]> wrote: I'm hoping to add BZIP2 compression to zipfile for 2.5. My primary motivation is that Project Gutenberg seems to be starting to use BZIP2 compression for some of its zips. What other wish list things do people around here have for zipfile? I thought I'd collect input here and make a PEP. I can open a pseudo-file for STORED files in binary read mode, for example, to allow reading zip-in-zip files without fully occupying memory. I'm not sure that zipfile needs BZIP2 support...being that there is a bzip2 module. - Josiah ___ 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/python-python-dev%40m.gmane.org But if you look at the zipfile document, BZIP2 is a compression technique you can use (per file) in a zip archive. In fact, I use bz2 to compress/decompress, but the data still needs to inhabit the archive. -- -- Scott David Daniels [EMAIL PROTECTED] ___ 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: Zipfile needs?
Brett C. wrote: Scott David Daniels wrote: I'm hoping to add BZIP2 compression to zipfile for 2.5. My primary motivation is that Project Gutenberg seems to be starting to use BZIP2 compression for some of its zips. What other wish list things do people around here have for zipfile? I thought I'd collect input here and make a PEP. Encryption/decryption support. Will most likely require a C extension since the algorithm relies on ints (or longs, don't remember) wrapping around when the value becomes too large. I'm trying to use byte-block streams (iterators taking iterables) as the basic structure of getting data in and out. I think the encryption/ decryption can then be plugged in at the right point. If it can be set up properly, you can import the encryption separately and connect it to zipfiles with a call. Would this address what you want? I believe there is an issue actually building in the encryption/decryption in terms of redistribution. -- -- Scott David Daniels [EMAIL PROTECTED] ___ 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] Recent IBM Patent releases
IBM has recently released 500 patents for use in opensource code. http://www.ibm.com/ibm/licensing/patents/pledgedpatents.pdf "...In order to foster innovation and avoid the possibility that a party will take advantage of this pledge and then assert patents or other intellectual property rights of its own against Open Source Software, thereby limiting the freedom of IBM or any other Open Source developer to create innovative software programs, the commitment not to assert any of these 500 U.S. patents and all counterparts of these patents issued in other countries is irrevocable except that IBM reserves the right to terminate this patent pledge and commitment only with regard to any party who files a lawsuit asserting patents or other intellectual property rights against Open Source Software." Since this includes patents on compression and encryption stuff, we will definitely be faced with deciding on whether to allow use of these patents in the main Python library. Somebody was worried about BSD-style licenses on Groklaw, and said, "Yes, you can use this patent in the free version... but if you close the code, you're violating IBM's Patents, and they WILL come after you. Think of what would have happened if IBM had held a patent that was used in the FreeBSD TCP/IP stack? Microsoft used it as the base of the Windows NT TCP/IP stack. IBM could then sue Microsoft for patent violations." To which he got the following reply: "Sorry, but that's not correct. That specific question was asked on the IBM con-call about this announcement. i.e. if there were a commercial product that was a derived work of an open source project that used these royalty-free patents, what would happen? "IBM answered that, so long as the commercial derived work followed the terms of the open source license agreement, there was no problem. (So IBM is fine with a commercial product based on an open source BSD project making use of these patents.)" This means to me we can put these in Python's library, but it is definitely something to start deciding now. -- Scott David Daniels [EMAIL PROTECTED] ___ 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: Recent IBM Patent releases
Skip Montanaro wrote: Who is going to decide if a particular library would be affected by one or more of the 500 patents IBM released? Skip I am thinking more along the lines of, "our policy on accepting new code [will/will not] be to allow new submissions which use some of that patented code." I believe our current policy is that the author warrants that the code is his/her own work and not encumbered by any patent. -- Scott David Daniels [EMAIL PROTECTED] ___ 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: Recent IBM Patent releases
Terry Reedy wrote: "Scott David Daniels" <[EMAIL PROTECTED]> I believe our current policy is that the author warrants that the code is his/her own work and not encumbered by any patent. Without a qualifier such as 'To the best of my knowledge', the latter is an impossible warrant both practically, for an individual author without $1000s to spend on a patent search, and legally. Legally, there is no answer until the statute of limitations runs out or until there is an after-the-fact final answer provided by the court system. Absolutely. I should have written that in the first place. I was trying to generate a little discussion about a particular case (the released IBM patents) where we might want to say, "for these patents, feel free to include code based on them." My understanding is that we will remove patented code if we get notice that it _is_ patented, and that we strive to not put any patented code into the source. --Scott David Daniels [EMAIL PROTECTED] ___ 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: string find(substring) vs. substring in string
Irmen de Jong wrote: There's the Boyer-Moore string search algorithm which is allegedly much faster than a simplistic scanning approach, and I also found this: http://portal.acm.org/citation.cfm?id=79184 So perhaps there's room for improvement :) The problem is setup vs. run. If the question is 'ab in 'rabcd', Boyer-Moore and other fancy searches will be swamped with prep time. In Fred's comparison with re, he does the re.compile(...) outside of the timing loop. You need to decide what the common case is. The longer the thing you are searching in, the more one-time-only overhead you can afford to reduce the per-search-character cost. --Scott David Daniels [EMAIL PROTECTED] ___ 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: string find(substring) vs. substring in string
Fredrik Lundh wrote:
(btw, the benchmark was taken from jim hugunin's ironpython talk, and
seems to be carefully designed to kill performance also for more advanced
algorithms -- including boyer-moore)
Looking for "not there" in "not the xyz"*100 using Boyer-Moore should do
about 300 probes once the table is set (the underscores below):
not the xyznot the xyznot the xyz...
not ther_
not the__
not ther_
not the__
not ther_
...
-- Scott David Daniels
[EMAIL PROTECTED]
___
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: OK, time to retire
Brett C. wrote: I have decided that I am going to stop doing the python-dev Summaries > after PyCon; the Summary covering the last half of March 2005 will be > it for me. I (as well as most, I'd guess) have enjoyed your voice in the summaries. Thanks for a great series of summaries. Perhaps your final summary could be a personal view of PyCon for those of us unable to get there. If you make no more contribution to Python than you have so far, you will have done us a great service. Hip-hip-hooray-ly y'rs --Scott David Daniels [EMAIL PROTECTED] ___ 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: docstring before function declaration
Brett C. wrote: I am going to be -42 on this one. I personally love having the docstring below the definition line I can't really rationalize > it beyond just aesthetics at the moment I completely agree that the current form is better. It reduces the temptation to use boilerplate docstrings. No comment is better than an uninformative comment. If you don't want to spend the time to write a comment, step back and let me read the code itself. If the docstring is below the declaration, you needn't repeat the declaration in the comment (and people are less tempted to do so). Documentation and code should come from a human mind, and should communicate to another human mind. Attempting to automate the task of documentation creates hard-to-read code, interrupted by large meaningless comments which, often as not, are copied from a template and incompletely editted to be appropriate to the given function. Sorry about the rant, but this is another of my hot buttons. The single most disappointing thing I encountered on one project in a large corporation was an operating system requirements document that was being developped. The group had, at one point, a twenty-two page document with no real content. Really, the twenty two pages included an introduction, conclusion, table of contents, appendix, and index. It just didn't have anything but section headings. It was a thrilling triumph of form over function; a real Suahuab aesthetic, to coin a term. --Scott David Daniels [EMAIL PROTECTED] ___ 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: @decoration of classes
Michael Chermside wrote:
Josiah Carlson writes:
...While I have not used it often, I have done the equivalent of decorating
classes; it is as natural (though perhaps not quite as useful initially)
as decorating functions,
But a few *good* use cases would change my mind.
Until this weekend, I really had no idea what a good use case for
class decorators would look like. However, I stumbled upon something
interesting. I was refactoring Kirby Urner's "hypertoons" code this
weekend and hit upon an interesting use for decorators. On reflection,
this might well be a candidate for class decorators. The unusual thing
is that it does nothing to the decorated function; it simply stores it
in a data structure. The "converter" decorator builder can be used for
data values, including classes, but there is an advantage to having
them at the top of the definition.
Using such decorators looks like:
@converter('inch', 'foot')
def someconversion(...
@converter('foot', 'yard')
def anotherconversion(...
@converter('yard', 'furlong')
def yetanotherconversion(...
Classes can be put into the data structures with:
converter('flour', 'bread')(BakingClass)
_But_ (at least for the app I was fiddling with) decorating at the top
of declaration helps show the purpose of the class.
Have a look at:
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/393010
and see what you think.
-- Scott David Daniels
[EMAIL PROTECTED]
___
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-dev Summary for 2005-03-16 through 2005-03-31 [draft]
Brett C. wrote: ... I figured I would take up the idea. So hear ^^ here ^^ we go. ___ 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] marshal / unmarshal
What should marshal / unmarshal do with floating point NaNs (the case we
are worrying about is Infinity) ? The current behavior is not perfect.
Michael Spencer chased down a supposed "Idle" problem to (on Win2k):
marshal.dumps(1e1) == 'f\x061.#INF'
marshal.loads('f\x061.#INF') == 1.0
Should loads raise an exception?
Somehow, I thing 1.0 is not the best possible representation for +Inf.
-- Scott David Daniels
[EMAIL PROTECTED]
___
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: marshal / unmarshal
Terry Reedy wrote: "Tim Peters" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] All Python behavior in the presence of a NaN, infinity, or signed zero is a platform-dependent accident. The particular issue here is not platform dependence as such but within-platform usage dependence, as in the same code giving radically different answers in a standard interactive console window and an idle window, or when you run it the first time (from xx.py) versus subsequent times (from xx.pyc) until you edit the file again. (I verified this on 2.2, but MSpencer claimed to have tested on 2.4). Having the value of an expression such as '100 < 1e1000' flip back and forth between True and False from run to run *is* distressing for some people ;-). I know that this has come up before as 'wont fix' bug, but it might be better to have invalid floats like 1e1000, etc, not compile and raise an exception (at least on Windows) instead of breaking the reasonable expectation that unmarshal(marshal(codeob)) == codeob. That would force people (at least on Windows) to do something more more within-platform deterministic. If marshal could reliably detect a NaN, then of course unmarshal should reliably reproduce the NaN -- provided the platform on which it's unpacked supports NaNs Windows seems to support +- INF just fine, doing arithmetic and comparisons 'correctly'. So it seems that detection or reproduction is the problem. Terry J. Reedy ___ 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/python-python-dev%40m.gmane.org I can write the Windows-dependent detect code if that is what is wanted. I just want to know what the consensus is on the "should." If we cause exceptions, should they be one encode or decode or both? If not, do we replicate all NaNs, Infs of both signs, Indeterminates? --Scott David Daniels [EMAIL PROTECTED] ___ 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: marshal / unmarshal
Fredrik Lundh wrote:
pickle doesn't have the INF=>1.0 bug:
import pickle
pickle.loads(pickle.dumps(1e1))
...
ValueError: invalid literal for float(): 1.#INF
import cPickle
cPickle.loads(cPickle.dumps(1e1))
...
ValueError: could not convert string to float
import marshal
marshal.loads(marshal.dumps(1e1))
1.0
should I check in a fix for this?
the code in PyFloat_FromString contains lots of trickery to deal with more or
less
broken literals, and more or less broken C libraries.
unfortunately, and unlike most other functions with similar names,
PyFloat_FromString
takes a Python object, not a char pointer. would it be a good idea to add a
variant
that takes a char*? if so, should PyFloat_FromString use the new function, or
are we
avoiding that kind of refactoring for speed reasons these days?
any opinions?
From yesterday's sprint, we found a smallest-change style fix.
At the least a change like this will catch the unpacking:
in marshal.c (around line 500) in function r_object:
...
case TYPE_FLOAT:
{
char buf[256];
+ char *endp;
double dx;
n = r_byte(p);
if (n == EOF || r_string(buf, (int)n, p) != n) {
PyErr_SetString(PyExc_EOFError,
"EOF read where object expected");
return NULL;
}
buf[n] = '\0';
PyFPE_START_PROTECT("atof", return 0)
- dx = PyOS_ascii_atof(buf);
+ dx = PyOS_ascii_strtod(buf, &endptr);
PyFPE_END_PROTECT(dx)
+ if buf + n != &endptr) {
+ PyErr_SetString(PyExc_ValueError,
+ "not all marshalled float text read");
+ return NULL;
+ }
return PyFloat_FromDouble(dx);
}
-- Scott David Daniels
[EMAIL PROTECTED]
___
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] Is PEP 237 final -- Unifying Long Integers and Integers
Guido van Rossum wrote: > On 6/17/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote: >>IIRC, there was a decision to not implement phase C and to keep the >>trailing L in representations of long integers. > For 2.x, yes. I'm fine with marking it as Final and adding this to PEP > 3000 instead. Since PEP 313 has been rejected, the trailing L no longer introduces ambiguity in the representation of roman(40) vs. roman(10L). --Scott David Daniels [EMAIL PROTECTED] ___ 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.from_hex()
Chermside, Michael wrote: > ... I will say that if there were no legacy I'd prefer the tounicode() > and tostring() (but shouldn't itbe 'tobytes()' instead?) names for Python 3.0. Wouldn't 'tobytes' and 'totext' be better for 3.0 where text == unicode? -- -- Scott David Daniels [EMAIL PROTECTED] ___ 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] Coverity Open Source Defect Scan of Python
Michael Chermside wrote: > (PS: too bad I can't buy stock in Coverity. How come all the GOOD > companies are private? I had to wait around 6 years before I could > buy stock in Google.) Maybe because the companies whose stock is available early are companies bent on producing stock profits, rather than a solid value proposition. Trying to satisfy the profit-lust of angels has redirected more than one company. --Scott David Daniels [EMAIL PROTECTED] ___ 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] Expose the array interface in Python 2.5?
Greg Ewing wrote: > Nick Coghlan wrote: > >> The former seems fairly pointless, and the latter difficult (since it has >> implications for moving the data store when the array gets resized). > > I don't see why that should be a serious problem, as > long as it's understood that the address reported by > the array interface is only for temporary use. > > I also don't see what relevance the semantics of > Python indexing or mutation has. The array interface > should just report the location and shape of the > data as it happens to be when the call is made. > What happens to it in between times is entirely > up to the object. But it might be nice to be able to determine if the object has a way of promising a constant address while a reference is held. The array.array implementation could simply say, "nope." I certainly have use for implementations that can give better guarantees, and I'd like to be able to distinguish the two. --Scott David Daniels [EMAIL PROTECTED] ___ 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] Discussing the Great Library Reorganization
Brett Cannon wrote: > Here is a place I think we can take a queue from Java. I think we > should have a root package, 'py', and then have subpackages within > that At one point Tim Peters and I thought the right spot for python equivalents of C-coded modules belonged in package "py". Would 'std' do as well for the top level, or should we use "python" for the python-coded versions? -- -- Scott David Daniels [EMAIL PROTECTED] ___ 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] tally (and other accumulators)
Jess Austin wrote: > Alex wrote: >> On Apr 4, 2006, at 10:53 PM, Jess Austin wrote: >>> Alex wrote: >>>> import collections >>>> def tally(seq): >>>> d = collections.defaultdict(int) >>>> for item in seq: >>>> d[item] += 1 >>>> return dict(d) [Jess again] >>> def tally(seq): >>> return dict((group[0], len(tuple(group[1]))) >>> for group in itertools.groupby(sorted(seq))) >>> In general itertools.groupby() seems like a very clean way to do this >>> sort of thing, whether you want to end up with a dict or not. I'll go >>> so far as to suggest that the existence of groupby() obviates the >>> proposed tally(). Maybe I've just coded too much SQL and it has >>> warped my brain... > You're right in that it won't raise an exception on an iterator, but the > sorted() means that it's much less memory efficient than your version > for iterators. Another reason to avoid sorted() for this application, > besides the big-O. Anyway, I still like groupby() for this sort of > thing, with the aforementioned caveats. Functional code seems a little > clearer to me, although I realize that preference is not held > universally. However, sorted requires ordering. Try seq = [1, 1j, -1, -1j] * 5 Alex's tally works, but yours does not. -- -- Scott David Daniels [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Should issubclass() be more like isinstance()?
Crutcher Dunnavant wrote: > On 4/4/06, Greg Ewing <[EMAIL PROTECTED]> wrote: >> Crutcher Dunnavant wrote: >>> B) issubclass() won't work on a list of classs, >> > the way isinstance() does. >> >> That sounds more reasonable. I can't think of any >> reason why it shouldn't work. There is an issue of confusion: class CheeseShop(Sketch, ByCleese, ByGraham): pass You need to be careful that the user understands issubclass(SillyWalks, (Sketch, ByCleese, ByGraham)) is not simply testing that SillyWalks has the same ancestors as CheeseShop, but is True simply because issubclass(SillyWalks, Sketch) is True. More a document issue than anything, but to be considered. --Scott David Daniels [EMAIL PROTECTED] ___ 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] PyRange_New() alternative?
Ralf W. Grosse-Kunstleve wrote:
> Thanks! This does the trick for me:
>
> #if PY_VERSION_HEX >= 0x0203
> PyObject_CallFunction(
> (PyObject*) &PyRange_Type, "lll", start, start+len*step, step)
> #else
> PyRange_New(start, len, step, 1)
> #endif
>
> I am compiling the code above with a C++ compiler (in the context of
> Boost.Python). Newer g++ versions unfortunatly produce a warning if -Wall is
> specified:
>
> warning: dereferencing type-punned pointer will break strict-aliasing rules
I am not sure about your compiler, but if I remember the standard
correctly, the following code shouldn't complain:
PyObject_CallFunction((PyObject*) (void *) &PyRange_Type,
"lll", start, start+len*step, step)
-- Scott David Daniels
[EMAIL PROTECTED]
___
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] PyRange_New() alternative?
Martin v. Löwis wrote: > Scott David Daniels wrote: >> ... if I remember the standard >> correctly, the following code shouldn't complain: >> >> PyObject_CallFunction((PyObject*) (void *) &PyRange_Type, >> "lll", start, start+len*step, step) > > You remember the standard incorrectly. Python's usage of casts has > undefined behaviour, and adding casts only makes the warning go away, > but does not make the problem go away. ... (PyObject*) &PyRange_Type, ... should only work in the presence of subtypes (which C89 and C99 don't define). If there were a way to declare PyTypeObject as a subtype of PyObject then this cast should work. ... (PyObject*) (void *) &PyRange_Type, ... Says a pointer to PyRange_Type should have the structure of a pointer PyObject. Since the prelude to PyTypeObject matches that of PyObject, this should be an effective cast. In addition, casting pointers to and from "void *" should be silent -- _that_ is what I thought I was remembering of the standard. Do not mistake this for advocacy of changing Python's macros; I was telling the OP how he could shut up the complaint he was getting. In C extensions I'd be likely to do the "convert through void *" trick myself. -- Scott David Daniels [EMAIL PROTECTED] ___ 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] doc for new restricted execution design for Python
Brett Cannon wrote: > On 6/27/06, Jim Jewett <[EMAIL PROTECTED]> wrote: >> ... >> Caps and current usage should also be available (though read-only) >> from python; it is quite sensible to spill some cache when getting too >> close to your memory limit. > > Yeah, being able to read your restrictions seems reasonable to do from an > untrusted interpreter. Certainly in some cases I'd like to run a Python program that claims it "plays nice" without its being able to see that it is in jail. Otherwise I can't escalate my trust of the code based on old behavior (it might be nice only when the jailer is around). So, reading your restrictions is a capability I'd like to be able to control. -- Scott David Daniels [EMAIL PROTECTED] ___ 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] Joke: Rush Limbaugh (a joke in and of himself)
Rush Limbaugh was detained and questioned for transporting a possible illegal Viagra prescription into the country. Well... a least we know his back is feeling better. -- Scott David Daniels [EMAIL PROTECTED] ___ 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] Joke: Rush Limbaugh (a joke in and of himself)
Aahz wrote: > On Thu, Jun 29, 2006, Scott David Daniels wrote: >> . > I'm hoping this was a typo of an e-mail address for sending, because > this is not appropriate for python-dev. This absolutely was a matter of clicking the wrong spot. I completely agree it would be inappropriate for this forum. I retracted it as soon as I could, and I apologize to the group. -- Scott David Daniels [EMAIL PROTECTED] ___ 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] xturtle.py a replacement for turtle.py(!?)
Martin v. Löwis wrote: > Greg Ewing wrote: >> BTW, I'm not sure if 'xturtle' is such a good name. >> There's a tradition of X Windows executables having >> names starting with 'x', whereas this is presumably >> platform-independent. >> >> Maybe 'turtleplus' or something? > > When it goes into Python, it will be 'turtle'. > Perhaps in the meantime (if xturtle is not loved), you could go with "turtle_" as in "like the standard turtle, but my definition." -- -- Scott David Daniels [EMAIL PROTECTED] ___ 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] Possible C API problem?
Michael Hudson wrote: > Gary Robinson <[EMAIL PROTECTED]> writes: >>... bus error 100% of the time ...: We've boiled it down pretty far, and I've sent him off to the mac-python folks (looks gcc-compilerish to me, or maybe fallout from slight changes in C function call semantics). --Scott David Daniels [EMAIL PROTECTED] ___ 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] Chaining try statements: eltry?
[EMAIL PROTECTED] wrote: >... if Py3k ever happens, I'd hope that it would be the *one* Python > to use -- too many incompatibilities would probably mean *two* > Pythons fighting each other). A caduceus to heal software problems? http://www.pantheon.org/articles/c/caduceus.html --Scott David Daniels [EMAIL PROTECTED] ___ 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] zlib 1.2.3 is just out
Note zlib 1.2.3 is just out -- the zlib compression/decompression http://www.zlib.net/ From the page: Version 1.2.3 eliminates potential security vulnerabilities in zlib 1.2.1 and 1.2.2, so all users of those versions should upgrade immediately. The following important fixes are provided in zlib 1.2.3 over 1.2.1 and 1.2.2: * Eliminate a potential security vulnerability when decoding invalid compressed data * Eliminate a potential security vulnerability when decoding specially crafted compressed data * Fix a bug when decompressing dynamic blocks with no distance codes * Fix crc check bug in gzread() after gzungetc() * Do not return an error when using gzread() on an empty file I'd guess this belongs in 2.5, with a possible retrofit for 2.4. --Scott David Daniels [EMAIL PROTECTED] ___ 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 348 (exception reorg) revised again
Toby Dickenson wrote: > On Monday 15 August 2005 14:16, Raymond Hettinger wrote: > > The rationale for including TerminatingException in the PEP would also be > satisfied by having a TerminatingExceptions tuple (in the exceptions > module?). It makes sense to express the classification of exceptions that are > intended to terminate the interpreter, but we dont need to express that > classification as inheritence. > An argument _for_ TerminatingException as a class is that I can define my own subclasses of TerminatingException without forcing it to being a subclass of KeyboardInterrupt or SystemExit. -- Scott David Daniels [EMAIL PROTECTED] ___ 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] Bare except clauses in PEP 348
Raymond Hettinger wrote: >... I propose that the transition plan be as simple as introducing > BaseException. This allows people to write code that will work on both > 2.x and 3.0. It doesn't break anything. > > The guidance for cross-version (2.5 to 3.0) code would be: > > * To catch all but terminating exceptions, write: > > except (KeyError, SystemExit): > raise > except Exception: > ... How about: except BaseException, error: if not isinstance(error, Exception): raise ... This would accommodate other invented exceptions such as "FoundConvergance(BaseException)", which is my pseudo-example for an exiting exception that is not properly a subclass of either KeyError or SystemExit. The idea is a relaxation stops when it doesn't move and may start generating something silly like divide-by-zero. Not the end of an App, but the end of a Phase. --Scott David Daniels [EMAIL PROTECTED] ___ 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] empty string api for files
Raymond Hettinger wrote: > We would use: > for block in f.readblocks(20): > . . . What would be nice is a reader that allows a range of bytes. Often when you read a chunk, you don't care about the exact size you get, example uses include the re-blocking that makes reading from compressed data sources unnecessarily inefficient. --Scott David Daniels [EMAIL PROTECTED] ___ 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] GIL, Python 3, and MP vs. UP
Michael Hudson wrote: > How does a copying gc differ much from a non-copying non-refcounted gc > here? One important issue for C coded modules is that addresses may change when a GC is invoked, so no remembering addresses in your module; you must recalculate before each use. -- Scott David Daniels [EMAIL PROTECTED] ___ 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] int(string) (was: DRAFT: python-dev Summary for 2005-09-01 through 2005-09-16)
Tim Peters wrote: > ... > Someone want a finite project that would _really_ help their Uncle > Timmy in his slow-motion crusade to get Python on the list of "solved > it!" languages for each problem on that magnificent site? ... > Turns out it's _not_ input speed that's the problem here, and not even > mainly the speed of integer mod: the bulk of the time is spent in > int(string) OK, I got an idea about how to do this fast. I started with Python code, and I now have C code that should beat int(string) always while getting a lot of speed making long values. The working tables can be used to do the reverse transformation (int or long to string in some base) with a little finesse, but I haven't done that yet in C. The code is pretty sprawly now (a lot left in for instrumentation and testing pieces), but can eventually get smaller. I gave myself time to do this as a birthday present to myself. It may take a while to build a patch, but perhaps you can let me know how much speedup you get using this code. if you build this module, I'd suggest using "from to_int import chomp" to get a function that works like int (producing a long when needed and so on). > If you can even track all the levels of C function calls that ends up > invoking , you find yourself in PyOS_strtoul(), which is a > nifty all-purpose routine that accepts inputs in bases 2 thru 36, can > auto-detect base, and does platform-independent overflow checking at > the cost of a division per digit. All those are features, but it > makes for slw conversion. OK, this code doesn't deal with unicode at all. The key observations are: A) to figure out the base, you pretty much need to get to the first digit; getting to the first non-zero digit is not that much worse. B) If you know the length of a string of digits (starting at the first non-zero digit) and the base, you know approximately how bits the result will have. You can do a single allocation if you are building a long. You can tell if you need to test for overflow in building an int; there is one length per base where you must. So the question becomes, is it worth taking two passes at the digits? Well, it sure looks like it to me, but I haven't timed one or two- character integers. I do longs in "megadigits" -- the largest set of digits that fits safely in SHIFT bits, so they have no need for overflow checks. For further excitement, you can use a similar technique to go from the number of bits to the string length. That should make for a fast convert int/long to string in any of 36 (or more, really) bases. I pass all of your mentioned test cases (including the one from a later message). I'm pretty much out of time for this project at the moment, but encouraging words would help me steal some time to finish. For anyone wanting to look at the code, or try it themselves: Installer: http://members.dsl-only.net/~daniels/dist/to_int-0.10.win32-py2.4.exe Just the 2.4 dll: http://members.dsl-only.net/~daniels/dist/to_int-0.10.win32.zip Sources: http://members.dsl-only.net/~daniels/dist/to_int-0.10.zip --Scott David Daniels [EMAIL PROTECTED] ___ 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] to_int -- oops, one step missing for use.
Well, wouldn't you know it. I get the code right and mess up the directions. Scott David Daniels wrote: > if you build this module, I'd suggest using > "from to_int import chomp" to get a function that works like int > (producing a long when needed and so on). Well, actually it is a bit more than that. "from to_int import chomp, _flag; _flag(1)" This sets a flag to suppress the return of the length along with the value from chomp. --Scott David Daniels [EMAIL PROTECTED] ___ 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] to_int -- oops, one step missing for use.
OK, Tim and I corresponded off-list (after that Aahz graciously suggested direct mail). The code I have is still stand-alone, but I get good speeds: 60% - 70% of the speed of int(string, base). It will take a little bit to figure out how it best belongs in the Python sources, so don't look for anything for a couple of weeks. Also, I'd appreciate someone testing the code on a 64-bit machine. Essentially all I'll need is that person to do a build and then run the tests. Unfortunately the posted module tests only cover the 32-bit long cases, so what I need is another test tried on a 64-bit long machine (that uses 64-bit longs in Python). So, if you have a Python installation where sys.maxint == (1 << 63) - 1 is True, and you'd like to help, here's what I need. If you already have the zip, retrieve: http://members.dsl-only.net/~daniels/dist/test_hi_powers.py If you don't already have the zip, retrieve: http://members.dsl-only.net/~daniels/dist/to_int-0.10.zip (I just added the test_hi_powers.py to the tests in the zip) Unpack the zip, do the build: $ python setup_x.py build copy the built module into the test directory, cd to that dir, and run test_hi_powers.py. Let me know if the tests pass or fail. Thanks. --Scott David Daniels [EMAIL PROTECTED] ___ 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] Behavoir question.
Since I am fiddling with int/long conversions to/from string:
Is the current behavior intentional (or mandatory?):
v = int(' 5 ')
works, but:
v = int(' 5L ')
fails.
--Scott David Daniels
[EMAIL PROTECTED]
___
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] Deprecate __ private (was Re: PEP 8 updates/clarifications)
Jim Fulton wrote: > Ian Bicking wrote: >> Jim Fulton wrote: >>> Ian Bicking wrote: >>>>Private attributes should have two leading underscores, no >>>>trailing underscores. >>>> >>>> This conflicts with a previous suggestion "Generally, double leading >>>> underscores should be used only to avoid name conflicts with >>>> attributes in classes designed to be subclassed." Or perhaps >>>> "private attributes" needs to be better explained. ... >> I really really hate double underscores, but I thought I'd let some >> other people suggest stronger language first > > Can we officially mark __private as a mistake. Perhaps: > - Strongly discourage it in the style guide > - Mark it in the language reference as a deprecated feature > - Generate deprecation warnings when it is used? >(This might be too much.) Perhaps "The __ name convention is designed for 'mixins'; as a means of enforcing "private" it is both ineffective and annoying. For example, distutils.msvccompiler uses a bunch of instance variables which would I would like to access in a subclass, but are "unavailable" because the author could not imagine why I would need them. --Scott David Daniels [EMAIL PROTECTED] ___ 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] Deprecate __ private (was Re: PEP 8 updates/clarifications)
Jeremy Hylton wrote: > On 12/12/05, Scott David Daniels <[EMAIL PROTECTED]> wrote: >> Perhaps "The __ name convention is designed for 'mixins'; as a means of >> enforcing "private" it is both ineffective and annoying. For example, >> distutils.msvccompiler uses a bunch of instance variables which would I >> would like to access in a subclass, but are "unavailable" because the >> author could not imagine why I would need them. > > These are really separate issues, right? The effect of __ names is to > make a variable private to a class, because it's a right pain to > access it from any other class. If you design a class for inheritance > and use __ names, you're deciding to keep the details of those names > private. For 'mixins' (or other multi-inheritance schemes) the renaming serves a useful (and necessary) function -- collision avoidance. In a hierarchy designed for inheritance, I suspect fewer problems than I see in the cited code. For code built with no thought of inheritance, it will be easier to (re) use parts if non-'__' names are used. Code built for inheritance is not responsible for the correctness of subclasses; I suspect many '__' names are used in a mistaken attempt to prevent subclasses from making mistakes, rather than attempting to ease their use. --Scott David Daniels [EMAIL PROTECTED] ___ 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] Sharing expat instances
Fredrik Lundh wrote: > Phillip J. Eby wrote. > >>> my current idea is to >>> >>> 1. include it under a different name (_elementtree.so) >>> 2. add a cElementTree.py under xml.etree, which simply does >>> from _elementtree import * >>> >>> does anyone have a better idea ? >> I was under the impression that simply installing cElementTree.so in the >> relevant package directory would work; this is what the distutils do for >> extensions with a package name. > > it would work, of course, but the core puts all the binaries in a separate > directory (lib-dynload on unix, DLLs on windows, etc). One good reason for this is that the .pyd's or .so's cannot necessarily be used from zip files, so it is nice to keep those binaries out of the package directory (packages can then easily go in a Python25.zip). My (admittedly weak) understanding of how packages work is that all parts of a package should lie off the same node of the PYTHONPATH. --Scott David Daniels [EMAIL PROTECTED] ___ 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] Sharing expat instances
Barry Warsaw wrote: > On Wed, 2005-12-14 at 09:56 -0800, Scott David Daniels wrote: >> One good reason for this is that the .pyd's or .so's cannot necessarily >> be used from zip files > When you say "cannot necessarily", are the situations where they can be > imported from zip files? I thought the answer to that was always "no". I thought so too, but was not sure enough to state it that way. --Scott David Daniels [EMAIL PROTECTED] ___ 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] Sharing expat instances
Phillip J. Eby wrote: > At 05:51 PM 12/14/2005 +0100, Fredrik Lundh wrote: >> Phillip J. Eby wrote. >> >>>> my current idea is to >>>> >>>> 1. include it under a different name (_elementtree.so) >>>> >>>> 2. add a cElementTree.py under xml.etree, which simply does >>>> >>>> from _elementtree import * >>>> >>>> does anyone have a better idea ? >>> I was under the impression that simply installing cElementTree.so in the >>> relevant package directory would work; this is what the distutils do for >>> extensions with a package name. >> it would work, of course, but the core puts all the binaries in a separate >> directory (lib-dynload on unix, DLLs on windows, etc). >> >> do we really want to put executables in other locations ? > > I don't know. I can see that the split makes sense for prefix/exec-prefix > distinctions, but then again, the disutils will install an entire > distribution in exec-prefix if it contains "impure" parts, so that's > certainly an option here. > > On the other hand, it's not clear to me *why* the lib-dynload/DLLs > directories exist, since it seems to me that that's what exec-prefix is > for. Perhaps somebody can explain why lib-dynload/ and DLLs/ > exist? Perhaps some platforms have to add these directories to some > godforsaken environment variables like LD_LIBRARY_PATH or something? What I believe I understand about /.pyd / .so / .dll / shared libraries is that they are meant to allow several processes to map the same disk backing store to the same same virtual address for more than a single process. If the .egg strategy is followed, I expect that either the file shared is in a user(or even process)-specific location or there is a shared folder that is writable by many processes from which executable code can be run. The one solution reduces sharing, the other violates security principles. --Scott David Daniels [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ElementTree in stdlib
Michael Chermside wrote: > ... a meme will spread which says (and PLEASE don't quote this!) > "ElementTree has a great API, but it's just too slow for real work." +1 DNQOTW :-) (Do Not Quote Of The Week) --Scott David Daniels [EMAIL PROTECTED] ___ 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] Incorporation of zlib sources into Python subversion
Martin v. Löwis wrote: > Thomas (Heller) and I have been discussing whether the zlib > module should become builtin, atleast on Win32 (i.e. part > of python25.dll). This would simplify py2exe, which then could > bootstrap extraction from the compressed file just with > pythonxy.dll (clearly, zlib.pyd cannot be *in* the compressed > file). Question: I am trying to enable other compression forms in zipfile, in particular bzip2, but eventually extensible. My primary intent is to extend the useful life of .zips by allowing better compression (and enabling reading and writing zip formats that are starting to be created from other sources). Would it make sense to include bzip2 in here as well (if the zipfile changes go in)? --Scott David Daniels [EMAIL PROTECTED] ___ 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] Keep default comparisons - or add a second set?
Jim Jewett wrote: > Jim Fulton asked how this canonical ordering > should be defined. > > The obvious answer is "Just like the __lt__ > operator today". But it doesn't actually *need* > to be that sensible, if there are strong reasons > to prefer a simpler ordering. > > The more I think about it, though, __eq__ really > does need to be honored; I don't want an > "Are these two containers equivalent?" > test to depend on how well the memory > subsystem happened to be working. > > Given that, also honoring an explicit __lt__ > isn't much of an extra burden, and will make > the ordering much more useful for debugging > and output. Tell me: >>> a = [0] * 3 >>> b = [0] * 3 >>> a[0] = b >>> b[0] = a What order should a and b have? --Scott David Daniels [EMAIL PROTECTED] ___ 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 quit that actually quits
Aahz wrote:
> On Wed, Dec 28, 2005, Brett Cannon wrote:
>> On 12/28/05, Aahz <[EMAIL PROTECTED]> wrote:
>>> Here's yet a different take on this: .. change the startup message...
>>> Type "help", "copyright", "credits" or "license" for more information.
>>> Let's add another line that says
>>> Type "quit()" to exit
>>> ...
Or, perhaps:
class _Quitter(str):
def __call__(self): raise SystemExit
quit = _Quitter('The quit command. Type "quit()" to exit')
exit = _Quitter('The exit command. Type "exit()" to exit')
--Scott David Daniels
[EMAIL PROTECTED]
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Checking in a broken test was: Re: [Python-checkins]r41940 - python/trunk/Lib/test/test_compiler.py
James Y Knight wrote:
> On Jan 8, 2006, at 1:01 PM, Martin v. Löwis wrote:
>
>> Fred L. Drake, Jr. wrote:
>>
>>> I like the way trial (from twisted) supports this. The test
>>> method is written
>>> normally, in whatever class makes sense. Then the test is marked
>>> with an
>>> attribute to say it isn't expected to pass yet. When the code is
>>> fixed and
>>> the test passes, you get that information in trial's output, and
>>> can unmark
>>> the test. This avoids having to refactor test classes just to
>>> update the
>>> status of a test.
>>>
>> So how is the mark added? I would suggest
>>
>>@xfail
>>def test_foo(self):
>> self.assertEquals(0,1)
>
>def test_foo(self):
> self.assertEquals(0,1)
>test_foo.todo = "Why this test fails description message."
Looks pretty good. Here's some code to critique:
import unittest
class BrokenTest(unittest.TestCase.failureException):
def __repr__(self):
return '%s: %s: %s works now' % (
(self.__class__.__name__,) + self.args)
def known_broken_XXX(reason):
def wrapper(test_method):
def replacement(*args, **kwargs):
try:
test_method(*args, **kwargs)
except unittest.TestCase.failureException:
pass
else:
raise BrokenTest(test_method.__name__, reason)
return replacement
wrapper.todo = reason
return wrapper
So your use looks like:
class SomeTests(unittest.TestCase):
...
@known_broken_XXX('Someday the naive expect this to work')
def test_distinct_ones(self):
self.failIfEqual(1, 1.0)
-- Scott David Daniels
[EMAIL PROTECTED]
___
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
