Re: [Python-Dev] [Python-checkins] cpython (3.2): adjust braces a bit
What's the logic for adding some braces, but removing others?
On 10/19/2011 4:58 PM, benjamin.peterson wrote:
> http://hg.python.org/cpython/rev/9c79a25f4a8b
> changeset: 73010:9c79a25f4a8b
> branch: 3.2
> parent: 72998:99a9f0251924
> user:Benjamin Peterson
> date:Wed Oct 19 16:57:40 2011 -0400
> summary:
> adjust braces a bit
>
> files:
> Objects/genobject.c | 9 -
> 1 files changed, 4 insertions(+), 5 deletions(-)
>
>
> diff --git a/Objects/genobject.c b/Objects/genobject.c
> --- a/Objects/genobject.c
> +++ b/Objects/genobject.c
> @@ -232,8 +232,9 @@
>
> /* First, check the traceback argument, replacing None with
> NULL. */
> -if (tb == Py_None)
> +if (tb == Py_None) {
> tb = NULL;
> +}
> else if (tb != NULL && !PyTraceBack_Check(tb)) {
> PyErr_SetString(PyExc_TypeError,
> "throw() third argument must be a traceback object");
> @@ -244,9 +245,8 @@
> Py_XINCREF(val);
> Py_XINCREF(tb);
>
> -if (PyExceptionClass_Check(typ)) {
> +if (PyExceptionClass_Check(typ))
> PyErr_NormalizeException(&typ, &val, &tb);
> -}
>
> else if (PyExceptionInstance_Check(typ)) {
> /* Raising an instance. The value should be a dummy. */
> @@ -262,10 +262,9 @@
> typ = PyExceptionInstance_Class(typ);
> Py_INCREF(typ);
>
> -if (tb == NULL) {
> +if (tb == NULL)
> /* Returns NULL if there's no traceback */
> tb = PyException_GetTraceback(val);
> -}
> }
> }
> else {
>
>
>
>
> ___
> Python-checkins mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-checkins
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] memcmp performance
On Fri, 21 Oct 2011 08:24:44 +0200 Stefan Behnel wrote: > Antoine Pitrou, 20.10.2011 23:08: > >> I have been doing some performance experiments with memcmp, and I was > >> surprised that memcmp wasn't faster than it was in Python. I did a whole, > >> long analysis and came up with some very simple results. > > > > Thanks for the analysis. Non-bugfix work now happens on Python 3, where > > the str type is Python 2's unicode type. Your recommendations would > > have to be revisited under that light. > > Well, Py3 is quite a bit different now that PEP393 is in. It appears to use > memcmp() or strcmp() a lot less than before, but I think unicode_compare() > should actually receive an optimisation to use a fast memcmp() if both > string kinds are equal, at least when their character unit size is less > than 4 (i.e. especially for ASCII strings). Funny enough, tailmatch() has > such an optimisation. Yes, unicode_compare() probably deserves optimizing. Patches welcome, by the way :) Regards Antoine. ___ 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] Summary of Python tracker Issues
ACTIVITY SUMMARY (2011-10-14 - 2011-10-21) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open3095 (+18) closed 21927 (+43) total 25022 (+61) Open issues with patches: 1319 Issues opened (47) == #7322: Socket timeout can cause file-like readline() method to lose d http://bugs.python.org/issue7322 reopened by r.david.murray #11254: distutils doesn't byte-compile .py files to __pycache__ during http://bugs.python.org/issue11254 reopened by eric.araujo #11637: Add cwd to sys.path for hooks http://bugs.python.org/issue11637 reopened by eric.araujo #13180: pysetup silently ignores invalid entries in setup.cfg http://bugs.python.org/issue13180 opened by pmoore #13183: pdb skips frames after hitting a breakpoint and running step http://bugs.python.org/issue13183 opened by xdegaye #13184: Multi-layered symlinks to python cause runtime error. sys.pat http://bugs.python.org/issue13184 opened by Jason.Howlett #13189: New bdist_simple binary distribution format for packaging http://bugs.python.org/issue13189 opened by pmoore #13190: ConfigParser uses wrong newline on Windows http://bugs.python.org/issue13190 opened by noam.el #13191: Typo in argparse documentation http://bugs.python.org/issue13191 opened by mikehoy #13192: ImportError silences low-level OS errors http://bugs.python.org/issue13192 opened by pitrou #13193: test_packaging and test_distutils failures http://bugs.python.org/issue13193 opened by pitrou #13195: subprocess: args with shell=True is not documented on Windows http://bugs.python.org/issue13195 opened by techtonik #13196: subprocess: undocumented if shell=True is necessary to find ex http://bugs.python.org/issue13196 opened by techtonik #13197: subprocess: move shell arguments to a separate keyword param http://bugs.python.org/issue13197 opened by techtonik #13198: Remove duplicate definition of write_record_file http://bugs.python.org/issue13198 opened by eric.araujo #13200: Add start, stop and step attributes to range objects http://bugs.python.org/issue13200 opened by smarnach #13201: Implement comparison operators for range objects http://bugs.python.org/issue13201 opened by smarnach #13203: Doc: say id() is only useful for existing objects http://bugs.python.org/issue13203 opened by terry.reedy #13204: sys.flags.__new__ crashes http://bugs.python.org/issue13204 opened by Trundle #13207: os.path.expanduser breaks when using unicode character in the http://bugs.python.org/issue13207 opened by mandel #13208: Problems with urllib on windows http://bugs.python.org/issue13208 opened by Deepak.Dodo #13209: Refactor code using unicode_encode_call_errorhandler() in unic http://bugs.python.org/issue13209 opened by haypo #13210: Support Visual Studio 2010 http://bugs.python.org/issue13210 opened by sable #13211: urllib2.HTTPError does not have 'reason' attribute. http://bugs.python.org/issue13211 opened by jason.coombs #13212: json library is decoding/encoding when it should not http://bugs.python.org/issue13212 opened by thinred #13213: generator.throw() behavior http://bugs.python.org/issue13213 opened by petri.lehtinen #13214: Cmd: list available completions from the cmd.Cmd subclass and http://bugs.python.org/issue13214 opened by yaneurabeya #13215: multiprocessing Manager.connect() aggressively retries refused http://bugs.python.org/issue13215 opened by bgilbert #13216: Add cp65001 codec http://bugs.python.org/issue13216 opened by haypo #13217: Missing header dependencies in Makefile http://bugs.python.org/issue13217 opened by jcon #13218: test_ssl failures on Ubuntu 11.10 http://bugs.python.org/issue13218 opened by nadeem.vawda #13220: print function unable while multiprocessing.Process is being r http://bugs.python.org/issue13220 opened by Ben.thelen #13223: pydoc removes 'self' in HTML for method docstrings with exampl http://bugs.python.org/issue13223 opened by Cameron.Hayne #13224: Change str(class) to return only the class name http://bugs.python.org/issue13224 opened by eric.araujo #13225: Failing packaging hooks should not stop operation http://bugs.python.org/issue13225 opened by eric.araujo #13226: Expose RTLD_* constants in the posix module http://bugs.python.org/issue13226 opened by haypo #13228: Add "Quick Start" section to the devguide index http://bugs.python.org/issue13228 opened by ezio.melotti #13229: Add shutil.filter_walk http://bugs.python.org/issue13229 opened by ncoghlan #13231: sys.settrace - document 'some other code blocks' for 'call' ev http://bugs.python.org/issue13231 opened by techtonik #13232: Logging: Unicode Error http://bugs.python.org/issue13232 opened by guettli #13234: os.listdir breaks with literal paths http://bugs.python.org/issue13234 opened by mandel #13236: unittest needs more flush calls http://bugs.python.org/is
Re: [Python-Dev] [Python-checkins] cpython (3.2): adjust braces a bit
2011/10/21 Eric V. Smith : > What's the logic for adding some braces, but removing others? No braces if everything is a one-liner, otherwise braces everywhere. -- Regards, Benjamin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython (3.2): adjust braces a bit
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/21/2011 12:31 PM, Benjamin Peterson wrote: > 2011/10/21 Eric V. Smith : >> What's the logic for adding some braces, but removing others? > > No braces if everything is a one-liner, otherwise braces > everywhere. Hmm, PEP 7 doesn't show any example of the one-liner exception. Given that it tends to promote errors, particularly among indentation-conditioned Python programmers (adding another statement at the same indentation level), why not just have braces everywhere? Tres. - -- === Tres Seaver +1 540-429-0999 [email protected] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6hoI4ACgkQ+gerLs4ltQ5xlACeLTfh93yW6jxaySzgVwyA9xDS GxMAn1ZmY5KcjZ50m5eYFusc6FMI++NF =mSl4 -END PGP SIGNATURE- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython (3.2): adjust braces a bit
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Oct 21, 2011, at 12:40 PM, Tres Seaver wrote: >Hmm, PEP 7 doesn't show any example of the one-liner exception. Given >that it tends to promote errors, particularly among >indentation-conditioned Python programmers (adding another statement >at the same indentation level), why not just have braces everywhere? +1 - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCAAGBQJOoaGfAAoJEBJutWOnSwa/ng4P/AkZvFfMIwYnX5F8ctItZhgS nZjCpbuH1dG0JBrYwXq+A0+CPJM2fnS/UItt1Lmu464XAjs53Gyk5sc4OFR4ex07 7gYz65yrs7YLkefxc+06Ate1VvyTCDy7iagGwjELaRM/Pmt47Ei2Rhm5sVgZNbSa XzoEKURw7Uk5Yc/9/rHW5uo2KmRMp91hvU20oXFE9aq/N5bZXhfRrJqol7CURNgf AfGM7PP/Bl4g3prOJFSXdmELzFuppnlqJ77q8UuckI5I4q7n8dBk8WJskWmZFfo1 xZo7S8P+3wt7BKw3yoOxkjzeYN0Hk17ct9aeDfmQXXKNUNRu7lpiqzCi5mcY5EOL E5Nzw1/qmf9dkSBHUTH/zl1VDw5LFPiUdvTXM1mEROuH5MfpbGob1da+YCSG4UWJ 3ekqSDBmfuaPRfMBD1gY/m4olNW/0Bixb0upWCncuWBdng6SB8qeegEEyAPMQkWz llMOaySLxVFG7zNPJQRli4HbARedqpUzk1SzjPJINaAUuwyVx3KbCpsJIDkwNOHl yJ1MoGYRQzlWdR/X2KJahHzYUaRDa+Rg9p9uXmnoDFAmVomh6HDVDbjHfhsxj5Xd H+wP9wI2k0tI2ZMMHgDJO9nSI51ec2WmMtXe+bYG8D/D1HWuYo/D6qhHFKGR3zNm aLH0qwwieUTpa81Qg7D8 =HB4F -END PGP SIGNATURE- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython (3.2): adjust braces a bit
Tres Seaver wrote: On 10/21/2011 12:31 PM, Benjamin Peterson wrote: 2011/10/21 Eric V. Smith : >>> What's the logic for adding some braces, but removing others? >> No braces if everything is a one-liner, otherwise braces everywhere. Hmm, PEP 7 doesn't show any example of the one-liner exception. Given that it tends to promote errors, particularly among indentation-conditioned Python programmers (adding another statement at the same indentation level), why not just have braces everywhere? +1 ~Ethan~ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython (3.2): adjust braces a bit
2011/10/21 Tres Seaver : > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 10/21/2011 12:31 PM, Benjamin Peterson wrote: >> 2011/10/21 Eric V. Smith : >>> What's the logic for adding some braces, but removing others? >> >> No braces if everything is a one-liner, otherwise braces >> everywhere. > > Hmm, PEP 7 doesn't show any example of the one-liner exception. Given > that it tends to promote errors, particularly among > indentation-conditioned Python programmers (adding another statement > at the same indentation level), why not just have braces everywhere? It certainly doesn't explicitly but if (type->tp_dictoffset != 0 && base->tp_dictoffset == 0 && type->tp_dictoffset == b_size && (size_t)t_size == b_size + sizeof(PyObject *)) return 0; /* "Forgive" adding a __dict__ only */ -- Regards, Benjamin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython (3.2): adjust braces a bit
2011/10/21 Tres Seaver : > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 10/21/2011 12:31 PM, Benjamin Peterson wrote: >> 2011/10/21 Eric V. Smith : >>> What's the logic for adding some braces, but removing others? >> >> No braces if everything is a one-liner, otherwise braces >> everywhere. > > Hmm, PEP 7 doesn't show any example of the one-liner exception. Given > that it tends to promote errors, particularly among > indentation-conditioned Python programmers (adding another statement > at the same indentation level), why not just have braces everywhere? Because we're not writing Python? -- Regards, Benjamin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] memcmp performance
>>> Richard Saunders>>> I have been doing some performance experiments with memcmp, and I was>>> surprised that memcmp wasn't faster than it was in Python. I did a whole,>>> long analysis and came up with some very simple results.Antoine Pitrou, 20.10.2011 23:08:>> Thanks for the analysis. Non-bugfix work now happens on Python 3, where>> the str type is Python 2's unicode type. Your recommendations would>> have to be revisited under that light.>> Stefan Behnel >Well, Py3 is quite a bit different now that PEP393 is in. It appears to use >memcmp() or strcmp() a lot less than before, but I think unicode_compare() >should actually receive an optimisation to use a fast memcmp() if both >string kinds are equal, at least when their character unit size is less >than 4 (i.e. especially for ASCII strings). Funny enough, tailmatch() has >such an optimisation.I started looking at the most recent 3.x baseline: a lot of places, the memcmp analysis appears relevant (zlib, arraymodule, datetime, xmlparse):all still use memcmp in about the same way. But I agree that there are some major differences in the unicode portion.As long as the two strings are the same unicode "kind", you can use a memcmp to compare. In that case, I would almost argue some memcmpoptimization is even more important: unicode strings are potentially 2to 4 times larger, so the amount of time spent in memcmp may be more(i.e., I am still rooting for -fno-builtin-memcmp on the compile lines).I went ahead a quick string_test3.py for comparing strings(similar to what I did in Python 2.7)# Simple python string comparison test for Python 3.3a = []; b = []; c = []; d = []for x in range(0,1000) : a.append("the quick brown fox"+str(x)) b.append("the wuick brown fox"+str(x)) c.append("the quick brown fox"+str(x)) d.append("the wuick brown fox"+str(x))count = 0for x in range(0,20) : if a==c : count += 1 if a==c : count += 2 if a==d : count += 3 if b==c : count += 5 if b==d : count += 7 if c==d : count += 11print(count)Timings on On My FC14 machine (Intel Xeon [email protected]):29.18 seconds: Vanilla build of Python 3.3 29.17 seconds: Python 3.3 compiled with -fno-builtin-memcmp: No change: a little investigation shows unicode_compare is where allthe work is: Here's currently the main loop inside unicode_compare: for (i = 0; i < len1 && i < len2; ++i) { Py_UCS4 c1, c2; c1 = PyUnicode_READ(kind1, data1, i); c2 = PyUnicode_READ(kind2, data2, i); if (c1 != c2) return (c1 < c2) ? -1 : 1; } return (len1 < len2) ? -1 : (len1 != len2);If both loops are the same unicode kind, we can add memcmpto unicode_compare for an optimization: Py_ssize_t len = (len1 /* use memcmp if both the same kind */ if (kind1==kind2) { int result=memcmp(data1, data2, ((int)kind1)*len); if (result!=0) return result<0 ? -1 : +1; }Rerunning the test with this small change to unicode_compare:17.84 seconds: -fno-builtin-memcmp 36.25 seconds: STANDARD memcmpThe standard memcmp is WORSE that the original unicode_comparecode, but if we compile using memcmp with -fno-builtin-memcmp, we get thatwonderful 2x performance increase again.I am still rooting for -fno-builtin-memcmp in both Python 2.7 and 3.3 ...(after we put memcmp in unicode_compare) Gooday, Richie___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython (3.2): adjust braces a bit
2011/10/21 Eric V. Smith :
> On 10/21/2011 12:31 PM, Benjamin Peterson wrote:
>> 2011/10/21 Eric V. Smith :
>>> What's the logic for adding some braces, but removing others?
>>
>> No braces if everything is a one-liner, otherwise braces everywhere.
>
> Not sure what "everything" means here. My specific question is why
> braces were added here:
> - if (tb == Py_None)
> + if (tb == Py_None) {
> tb = NULL;
> + }
Because an else if follows it.
--
Regards,
Benjamin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] memcmp performance
Richard Saunders, 21.10.2011 20:23: As long as the two strings are the same unicode "kind", you can use a memcmp to compare. In that case, I would almost argue some memcmp optimization is even more important: unicode strings are potentially 2 to 4 times larger, so the amount of time spent in memcmp may be more (i.e., I am still rooting for -fno-builtin-memcmp on the compile lines). I would argue that the pure ASCII (1 byte per character) case is even more important than the other cases, and it suffers from the "1 byte per comparison" problem you noted. That's why you got the 2x speed-up for your quick test. Stefan ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP397 no command line options to python?
On 19 October 2011 13:17, Sam Partington wrote: > Ok ok, I give up. Apparently I am the only one who wants to be able > to run different versions of python based on the shebang line AND add > occasional arguments to the python command line. I don't know if this is of use to anyone, but I attach a Powershell module which does more or less what you're suggesting. It exports a few functions, and an alias "pyx" (just to distinguish it from the launcher, it could be renamed "py" if you prefer) which takes an -X.Y version option similar to the launcher (and a -w option for selecting the GUI version). All the remaining arguments are passed to Python. You can also add your own aliases - "Add-Python dev ." is a good way of adding a -dev flag to select the current development version you're working on. Hope it's useful to someone... Paul. pyx.psm1 Description: Binary data ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] memcmp performance
On Fri, 21 Oct 2011 18:23:24 + (GMT)
Richard Saunders wrote:
>
> If both loops are the same unicode kind, we can add memcmp
> to unicode_compare for an optimization:
>
> Py_ssize_t len = (len1
> /* use memcmp if both the same kind */
> if (kind1==kind2) {
> int result=memcmp(data1, data2, ((int)kind1)*len);
> if (result!=0)
> return result<0 ? -1 : +1;
> }
Hmm, you have to be a bit subtler than that: on a little-endian
machine, you can't compare two characters by comparing their bytes
representation in memory order. So memcmp() can only be used for the
one-byte representation.
(actually, it can also be used for equality comparisons on any
representation)
> Rerunning the test with this small change to unicode_compare:
>
> 17.84 seconds: -fno-builtin-memcmp
> 36.25 seconds: STANDARD memcmp
>
> The standard memcmp is WORSE that the original unicode_compare
> code, but if we compile using memcmp with -fno-builtin-memcmp, we get that
> wonderful 2x performance increase again.
The standard memcmp being worse is a bit puzzling. Intuitively, it
should have roughly the same performance as the original function.
I also wonder whether the slowdown could materialize on non-glibc
systems.
> I am still rooting for -fno-builtin-memcmp in both Python 2.7 and 3.3 ...
> (after we put memcmp in unicode_compare)
A patch for unicode_compare would be a good start. Its performance can
then be checked on other systems (such as Windows).
Regards
Antoine.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Status of the PEP 400? (deprecate codecs.StreamReader/StreamWriter)
Le vendredi 29 juillet 2011 19:01:06, Guido van Rossum a écrit : > On Fri, Jul 29, 2011 at 8:37 AM, Nick Coghlan wrote: > > On Sat, Jul 30, 2011 at 1:17 AM, Antoine Pitrou wrote: > >> On Thu, 28 Jul 2011 11:28:43 +0200 > >> > >> Victor Stinner wrote: > >>> I will add your alternative to the PEP (except if you would like to do > >>> that yourself?). If I understood correctly, you propose to: > >>> > >>> * rename codecs.open() to codecs.open_stream() > >>> * change codecs.open() to reuse open() (and so io.TextIOWrapper) > >>> > >>> (and don't deprecate anything) > >> > >> This may be an interesting approach. In a few years, we can evaluate > >> whether users are calling open_stream(), and if there aren't any, we > >> can deprecate the whole thing. > > > > Indeed. I'm also heavily influenced by MAL's opinion on this > > particular topic, so the fact he's OK with this approach counts for a > > lot. It achieves the main benefit I'm interested in (transparently > > migrating users of the codecs.open API to the new IO stack), while > > paving the way for eliminating the redundancy at some point in the > > future. > > +1 I updated the PEP 400 to no longer *remove* deprecated functions in Python 3.4. I don't like the idea of adding a *new* function (codecs.open_stream()) which emits a DeprecatingWarning. New functions are not supposed to be (indirectly) deprecated. Short summary of the updated PEP 400: - patch codecs.open() to make it reuse TextIOWrapper to access text files (instead of Stream* classes) - instanciate Stream* classes emit a DeprecationWarning - that's all So you can still get stream reader/writer using codecs.getreader() and codecs.getwriter() functions. Victor ___ 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] Buildbot failures
Hello, There are currently a bunch of various buildbot failures on all 3 branches. I would remind committers to regularly take a look at the buildbots, so that these failures get solved reasonably fast. Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: Issue 13227: Option to make the lru_cache() type specific (suggested by Andrew
On Fri, Oct 21, 2011 at 1:57 AM, raymond.hettinger
wrote:
> + If *typed* is set to True, function arguments of different types will be
> + cached separately. For example, ``f(3)`` and ``f(3.0)`` will be treated
> + as distinct calls with distinct results.
I've been pondering this one a bit since reviewing it on the tracker,
and I'm wondering if we have the default behaviour the wrong way
around.
For "typed=True":
- never results in accidental type coercion and potentially wrong
answers* (see below)
- cache uses additional memory (each entry is larger, more entries
may be stored)
- additional cache misses
- differs from current behaviour
For "typed=False" (current default):
- matches current (pre-3.3) behaviour
- can lead to accidental type coercion and incorrect answers
I only just realised this morning that the existing (untyped) caching
behaviour can give answers that are *numerically* wrong, not just of
the wrong type. This becomes clear once we use division as our test
operation rather than multiplication and bring Decimal into the mix:
>>> from functools import lru_cache
>>> @lru_cache()
... def divide(x, y):
... return x / y
...
>>> from decimal import Decimal
>>> 10 / 9
1.1112
>>> Decimal(10) / Decimal(9)
Decimal('1.111')
>>> divide(10, 9)
1.1112
>>> divide(Decimal(10), Decimal(9))
1.1112
At the very least, I think lru_cache should default to typed behaviour
in 3.3, with people being able to explicitly switch it off as a cache
optimisation technique when they know it doesn't matter. You could
even make the case that making the cache type aware under the hood in
3.2 would be a bug fix, and the only new feature in 3.3 would be the
ability to switch off the type awareness to save memory.
Regards,
Nick.
--
Nick Coghlan | [email protected] | Brisbane, Australia
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: Document that packaging doesn’t create __init__.py files (#3902).
On Fri, Oct 21, 2011 at 11:52 PM, eric.araujo
wrote:
> +To distribute extension modules that live in a package (e.g.
> ``package.ext``),
> +you need to create you need to create a :file:`{package}/__init__.py` file to
> +let Python recognize and import your module.
"you need to create" is repeated in the new text.
Cheers,
Nick.
--
Nick Coghlan | [email protected] | Brisbane, Australia
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP397 no command line options to python?
On Wed, Oct 19, 2011 at 10:17 PM, Sam Partington
wrote:
> Ok ok, I give up. Apparently I am the only one who wants to be able
> to run different versions of python based on the shebang line AND add
> occasional arguments to the python command line.
As a simpler alternative, I suggest the launcher just gain a "--which"
long option that displays the full path to the interpreter it found.
So:
C:\> py -2 --which
C:\Python27\python.exe
C:\> py -3 --which
C:\Python32\python.exe
No significant complexity in the launcher, and if you want to add
additional arguments like -m, -c, or -i you can do it by running
'--which' and switching to invoking that interpreter directly. "-i" in
particular is invaluable for the following scenario:
- app crashes with exception
- rerun with "-i"
- at the interpreter prompt, do "import pdd; pdb.pm()"
- poke around in the offending frame directly rather than sprinkling
print statement fairy dust around everywhere potentially relevant
And, of course, the "-m" use case has already been mentioned to invoke
modules by module name rather than file name ("python -m timeit",
anyone?)
Cheers,
Nick.
--
Nick Coghlan | [email protected] | Brisbane, Australia
___
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] [PATCH] unicode subtypes broken in latest py3k debug builds
Hi, the py3k debug build has been broken in Cython's integration tests for a couple of weeks now due to a use-after-decref bug. Here's the fix, please apply. BTW, is there a reason unicode_subtype_new() copies the buffer of the unicode object it just created, instead of just stealing it? Stefan # HG changeset patch # User Stefan Behnel # Date 1319258140 -7200 # Node ID bbd4261e770df456ce35784343a4f7426ce2a642 # Parent c1effa2cdd20897bcda6a501a022b3b800a69a11 fix use-after-decref crash bug in setup code for unicode subtypes in pydebug mode diff -r c1effa2cdd20 -r bbd4261e770d Objects/unicodeobject.c --- a/Objects/unicodeobject.c Thu Oct 20 23:54:17 2011 +0200 +++ b/Objects/unicodeobject.c Sat Oct 22 06:35:40 2011 +0200 @@ -13826,11 +13826,11 @@ Py_MEMCPY(data, PyUnicode_DATA(unicode), kind * (length + 1)); -Py_DECREF(unicode); assert(_PyUnicode_CheckConsistency(self, 1)); #ifdef Py_DEBUG _PyUnicode_HASH(self) = _PyUnicode_HASH(unicode); #endif +Py_DECREF(unicode); return (PyObject *)self; onError: ___ 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
