Re: [Python-Dev] Caching float(0.0)
On 3 Oct 2006, at 15:10, Martin v. Löwis wrote: > Nick Maclaren schrieb: >> That was the point of a previous posting of mine in this thread :-( >> >> You shouldn't, despite what IEEE 754 says, at least if you are >> allowing for either portability or numeric validation. >> >> There are a huge number of good reasons why IEEE 754 signed zeroes >> fit extremely badly into any normal programming language and are >> seriously incompatible with numeric validation, but Python adds more. >> Is there any other type where there are two values that are required >> to be different, but where both the hash is required to be zero and >> both are required to evaluate to False in truth value context? > > Ah, you are proposing a semantic change, then: -0.0 will become > unrepresentable, right? It's only a semantic change on platforms that "happen to" use IEEE 754 float representations, or some other representation that exposes the sign of zero. The Python docs have for many years stated with regard to the float type: "All bets on their precision are off unless you happen to know the machine you are working with." and that "You are at the mercy of the underlying machine architecture...". Not all floating point representations support sign of zero, though in the modern world it's true that the vast majority do. It would be instructive to understand how much, if any, python code would break if we lost -0.0. I'm do not believe that there is any reliable way for python code to tell the difference between all of the different types of IEEE 754 zeros and in the special case of -0.0 the best test I can come up with is repr(n)[0]=='-'. Is there an compelling case, to do with compatibility or otherwise, for exposing the sign of a zero? It seems like a numerical anomaly to me. Nicko ___ 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] PATCH submitted: Speed up + for string concatenation, now as fast as "".join(x) idiom
On 5 Oct 2006, at 20:28, Gregory P. Smith wrote: >> I've never liked the "".join([]) idiom for string concatenation; >> in my >> opinion it violates the principles "Beautiful is better than >> ugly." and >> "There should be one-- and preferably only one --obvious way to do >> it.". >> (And perhaps several others.) To that end I've submitted patch >> #1569040 >> to SourceForge: >> >> http://sourceforge.net/tracker/index.php? >> func=detail&aid=1569040&group_id=5470&atid=305470 >> This patch speeds up using + for string concatenation. > > yay! i'm glad to see this. i hate the "".join syntax. Here here. Being able to write what you mean and have the language get decent performance none the less seems to me to be a "good thing". > have you run any generic benchmarks such as pystone to get a better > idea of what the net effect on "typical" python code is? Yeah, "real world" performance testing is always important with anything that uses lazy evaluation. If you get to control if and when the computation actually happens you have even more scope than usual for getting the benchmark answer you want to see! Cheers, Nicko ___ 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] PATCH submitted: Speed up + for string concatenation, now as fast as "".join(x) idiom
On 6 Oct 2006, at 12:37, Ron Adam wrote: >>> I've never liked the "".join([]) idiom for string concatenation; >>> in my >>> opinion it violates the principles "Beautiful is better than >>> ugly." and >>> "There should be one-- and preferably only one --obvious way to >>> do it.". ... > Well I always like things to run faster, but I disagree that this > idiom is broken. > > I like using lists to store sub strings and I think it's just a > matter of > changing your frame of reference in how you think about them. I think that you've hit on exactly the reason why this patch is a good idea. You happen to like to store strings in lists, and in many situations this is a fine thing to do, but if one is forced to change ones frame of reference in order to get decent performance then as well as violating the maxims Larry originally cited you're also hitting both "readability counts" and "Correctness and clarity before speed." The "".join(L) idiom is not "broken" in the sense that, to the fluent Python programmer, it does convey the intent as well as the action. That said, there are plenty of places that you'll see it not being used because it fails to convey the intent. It's pretty rare to see someone write: for k,v in d.items(): print " has value: ".join([k,v]) but, despite the utility of the % operator on strings it's pretty common to see: print k + " has value: " + v This patch _seems_ to be able to provide better performance for this sort of usage and provide a major speed-up for some other common usage forms without causing the programmer to resort making their code more complicated. The cost seems to be a small memory hit on the size of a string object, a tiny increase in code size and some well isolated, under-the-hood complexity. It's not like having this patch is going to force anyone to change the way they write their code. As far as I can tell it simply offers better performance if you choose to express your code in some common ways. If it speeds up pystone by 5.5% with such minimal down side I'm hard pressed to see a reason not to use it. Cheers, Nicko ___ 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] PATCH submitted: Speed up + for string concatenation, now as fast as "".join(x) idiom
On 7 Oct 2006, at 09:17, Fredrik Lundh wrote: > Nicko van Someren wrote: > >> If it speeds up pystone by 5.5% with such minimal down side >> I'm hard pressed to see a reason not to use it. > > can you tell me where exactly "pystone" does string concatenations? No, not without more in depth examination, but it is a pretty common operation in all sorts of cases including inside the interpreter. Larry's message in reply to Gregory Smith's request for a pystone score showed a 5.5% improvement and as yet I have no reason to doubt it. If the patch provides a measurable performance improvement for code that merely happens to use strings as opposed to being explicitly heavy on string addition then all the better. It's clear that this needs to be more carefully measured before it goes in (which is why that quote above starts "If"). As I've mentioned before in this thread, getting good performance measures on code that does lazy evaluation is often tricky. pystone is a good place to start but I'm sure that there are use cases that it does not cover. As for counting up the downsides, Josiah Carlson rightly points out that it breaks binary compatibility for modules, so the change can not be taken lightly and clearly it will have to wait for a major release. Still, if the benefits outweigh the costs it seems worth doing. Cheers, Nicko ___ 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] [poll] New name for __builtins__
On 29 Nov 2007, at 14:06, Isaac Morland wrote: > > I wonder how much you could sell the naming rights for? i.e. call it > __[name of sponsor]__. Python's pretty popular, such advertising > should > be worth something I'm sorry, but if you call it __Microsoft_Office_2007__ I shall never write a program that uses what we now call __builtins__ ever again! > PS: I actually do like __universal__. Me too. +1 for __universal__ Nicko ___ 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-string keys in namespace dicts
On 2 Dec 2007, at 03:09, Neil Toronto wrote: > Are there any use-cases for allowing namespace dicts (such as globals, > builtins and classes) to have non-string keys? I'm asking because I'm > planning on accelerating method lookups next, and the possibility of a > key compare changing the underlying dict could be a major pain. (It > was > a minor pain for globals.) The only plausible use case I can think of might be wanting to use ints or longs as keys, though I've never seen it done. Of course this would be trivial to code around and it seems very much a fringe case, so I'd be in favour of deprecating non-string namespace keys if it's going to make look-ups go faster. Cheers, Nicko ___ 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] Monkeypatching idioms -- elegant or ugly?
On 15 Jan 2008, at 15:37, Guido van Rossum wrote: > Second, a "metaclass" to add a number of methods (or other attributes) > to an existing class, using a convenient class notation: ... > class (): >__metaclass__ = monkeypatch_class >def (...): ... >def (...): ... >... In Objective-C it's perfectly common to extend existing classes using 'categories' and I have often found this idiom very useful. What is described here is basically categories for Python. I've implemented something like this before and I would be happy to see this added to the standard library and formalised. Nicko ___ 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] Tracker marks my messages as spam :-)
Perhaps it has to do with the low signal to noise ratio of your messages... Nicko On 31 Jan 2008, at 10:07, Jesus Cea wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > This will be my last email today, I don't want to waste (more of) your *valuable* time. > > http://bugs.python.org/issue1391 > http://bugs.python.org/msg61892 > > - -- > Jesus Cea Avion _/_/ _/_/_/_/_/_/ > [EMAIL PROTECTED] http://www.argo.es/~jcea/ _/_/_/_/ _/_/_/_/ _/ > _/ > jabber / xmpp:[EMAIL PROTECTED] _/_/_/_/ _/_/_/_/_/ > ~ _/_/ _/_/_/_/ _/_/ _/_/ > "Things are not so easy" _/_/ _/_/_/_/ _/_/_/_/ _/_/ > "My name is Dump, Core Dump" _/_/_/_/_/_/ _/_/ _/_/ > "El amor es poner tu felicidad en la felicidad de otro" - Leibniz > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.6 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iQCVAwUBR6Gd25lgi5GaxT1NAQLDiwP/aMUOxhoRH8/ZnCtHCUzr95tIJUe1ySh6 > SuDjR3OS19S8lcRVgEL0droIP44lmozpdyOW1eaPDPBMA02XCqiPWmCxBCeXsbJ/ > xf/XVzl53vAQmtfqxHrNyrS+mXv5YW2CjOKWk52IKuf/Rckf9FYSP13OKW7WTjNy > orjAdOYRd/8= > =gSNB > -END PGP SIGNATURE- > ___ > 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/nicko%40nicko.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] Tracker marks my messages as spam :-)
On 1 Feb 2008, at 18:37, Steve Holden wrote: > Jeffrey Yasskin wrote: >> On Feb 1, 2008 6:43 AM, Nicko van Someren <[EMAIL PROTECTED]> wrote: >>> Perhaps it has to do with the low signal to noise ratio of your >>> messages... >> >> That was a little uncalled for. Be polite. > > I don't believe it was at all impolite: It was a literal observation > of > a relevant phenomenon. Jesus's email that started this thread used > 1305 > characters to simply say > > "This will be my last email today, I don't want to waste (more of) > your > *valuable* time." > > a message of 89 characters. By anyone's standards that's a low S/N > ratio. Even without the digital signature overhead it is still 89 > characters from a total of 648 ... it's quite possible that's why his > messages are being misinterpreted. Exactly. I by no means meant to suggest that the quality of the content was low, only that it was lost in a morass of padding which might confuse a spam filter. Sorry if my comment was misconstrued. Nicko ___ 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 - Mac Installer?
On 30 Dec 2008, at 13:45, Barry Scott wrote: ... Since I've been building 3.0 for a while now I looked at the script. build-install.py seems to have been half converted to py 3.0. Going full 3.0 was not hard but then there is the problem of the imports. Python 3.0 does not have MacOS or Carbon modules. Seems that there are two ways to go. Put back the Carbon and MacOS modules into 3.0. Use Python 2 to build the python 3 package. As far as I can tell the Carbon and MacOS modules are _only_ used in the setIcon() function, which is used to give pretty icon to the python folder. Perhaps it might be better to have a fully Python 3 build system and loose the prettiness for the time being. Nicko ___ 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] Pre-PEP: Allow Empty Subscript List Without Parentheses
On 9 Jun 2006, at 17:44, Guido van Rossum wrote: > This is an elaborate joke, right? > > On 6/9/06, Noam Raphael <[EMAIL PROTECTED]> wrote: ... >> It's simply this: Currently, the expression "x[]" is a syntax >> error. I >> suggest that it will be a valid syntax, and equivalent to "x[()]", >> just as "x[a, b]" is equivalent to "x[(a, b)]" right now. ... >> Motivation >> == >> >> This suggestion allows you to refer to zero-dimensional arrays >> elegantly. I don't think that this suggestion is any less reasonable the the very existence of zero-dimensional arrays in the first place, although in my personal opinion that's a fairly low bar. Nicko ___ 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 note in random.shuffle.__doc__ ...
On 12 Jun 2006, at 02:19, Terry Jones wrote: >> "Greg" == Greg Ewing <[EMAIL PROTECTED]> writes: > > Greg> Terry Jones wrote: >>> Suppose you have a RNG with a cycle length of 5. There's nothing >>> to stop an >>> algorithm from taking multiple already returned values and >>> combining them >>> in some (deterministic) way to generate > 5 outcomes. > > Greg> No, it's not. As long as the RNG output is the only input to > Greg> the algorithm, and the algorithm is deterministic, it is > Greg> not possible get more than N different outcomes. It doesn't > Greg> matter what the algorithm does with the input. ... > The code below uses a RNG with period 5, is deterministic, and has one > initial state. It produces 20 different outcomes. I think that in any meaningful sense your code is producing just one outcome, since it has just one initial state. It is completely deterministic and has no seed, so this is expected. > It's just doing a simplistic version of what a lagged RNG generator > does, > but the lagged part is in the "algorithm" not in the rng. That's > why I said > if you included the state of the algorithm in what you meant by > "state" I'd > be more inclined to agree. This is a different issue. You instantiate more than one PRNG. If you have n PRGNs which each have a period p then you can get have the combination in p^n different starting states, which can be useful but only if you can find n*log2(p) bits of starting entropy to get the thing into a usefully random state. Nicko > def rng(): ... > history = [rng()] ... > for lag in range(1, 5): ... > new = rng() ___ 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] Switch statement
On 15 Jun 2006, at 11:37, Nick Coghlan wrote:
> ...
> The lack of a switch statement doesn't really bother me personally,
> since I
> tend to just write my state machine type code so that it works off a
> dictionary that I define elsewhere,
Not trying to push more LISP into python or anything, but of course
we could converge your method and the switch statement elegantly if
only we could put whole suites into lamdbas rather than just single
expressions :-)
{"case1": lamdba : some-suite-lambda... ,
"case2": lambda : some-other-suite...
}[switch-condition-expression]()
Nicko
___
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] Switch statement
On 16 Jun 2006, at 00:49, Phillip J. Eby wrote: > At 11:45 PM 6/15/2006 +0100, Nicko van Someren wrote: >> On 15 Jun 2006, at 11:37, Nick Coghlan wrote: >> > ... >> > The lack of a switch statement doesn't really bother me personally, >> > since I >> > tend to just write my state machine type code so that it works >> off a >> > dictionary that I define elsewhere, >> >> Not trying to push more LISP into python or anything, but of course >> we could converge your method and the switch statement elegantly if >> only we could put whole suites into lamdbas rather than just single >> expressions :-) > > As has already been pointed out, this > > 1) adds function call overhead, > 2) doesn't allow changes to variables in the containing function, and > 3) even if we had a rebinding operator for free variables, we would > have the overhead of creating closures. Noted. I find (2) the most compelling issue. I was merely suggesting a succinct way to express the model that Nick Cohglan was espousing. > The lambda syntax does nothing to fix any of these problems, and > you can already use a mapping of closures if you are so inclined. > However, you'll probably find that the cost of creating the > dictionary of closures exceeds the cost of a naive sequential > search using if/elif. The smiley was supposed to indicate that this was not an entirely serious suggestion; my apologies if the signal was lost in transmission. In the equivalent if/elif to a switch you're only comparing a single value against a set of pre-computed values, and expecting to only do half the tests, so it's almost certainly going to be quicker than sorting out the whole set of closures. I do however have a bug-bear about lambdas being restricted to single expressions, but maybe that's just me. Nicko ___ 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 328 and PEP 338, redux
On 27 Jun 2006, at 13:03, Nick Coghlan wrote:
> ...
> It occurred to me that a slight modification to PEP 338 might solve
> the
> problem fairly cleanly: instead of simply setting __name__ to
> '__main__' for a
> module in a package, the -m switch could prepend the package name
> so that
> relative imports can work correctly.
>
> Inside the module, the test for "am I the main module" would need
> to be
> "__name__.endswith('__main__')" instead of "__name__ ==
> '__main__'", but other
> than that, there should be very little impact.
Hum... other than effecting more or less every runnable python module
around it should be very little impact. That sounds like quite a bit
of impact to me!
Nicko
___
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
