[Python-Dev] PEP 418 glossary
I believe PEP 418 (or at least the discussion) would benefit greatly from a glossary to encourage people to use the same definitions. This is arguably the Definitions section, but it should move either near the end or (preferably) ahead of the Functions. It also needs to be greatly expanded. Here is my strawman proposal, which does use slightly different definitions than the current PEP even for some terms that the PEP does define: Accuracy: Is the answer correct? Any clock will eventually drift; if a clock is intended to match Civil Time, it will need to be adjusted back to the true time. Adjusted: Resetting a clock to the correct time. This may be done either with a Step or by Slewing. Civil Time: Time of day; external to the system. 10:45:13am is a Civil time; 45 seconds is not. Provided by existing function time.localtime() and time.gmtime(). Not changed by this PEP. Clock: An instrument for measuring time. Different clocks have different characteristics; for example, a clock with nanonsecond precision may start to drift after a few minutes, while a less precise clock remained accurate for days. This PEP is primarily concerned with clocks which use a unit of seconds. Clock_Monotonic: The characteristics expected of a monotonic clock in practice. In addition to being monotonic, the clock should also be steady and have relatively high precision, and should be convertible to a unit of seconds. The tradeoffs often include lack of a defined epoch or mapping to Civil Time, and being more expensive (in latency, power usage, or duration spent within calls to the clock itself) to use. For example, the clock may represent (a constant multiplied by) ticks of a specific quartz timer on a specific CPU core, and calls would therefore require synchronization between cores. The original motivation for this PEP was to provide a cross-platform name for requesting a clock_monotonic clock. Counter: A clock which increments each time a certain event occurs. A counter is strictly monotonic, but not clock_monotonic. It can be used to generate a unique (and ordered) timestamp, but these timestamps cannot be mapped to civil time; tick creation may well be bursty, with several advances in the same millisecond followed by several days without any advance. CPU Time: A measure of how much CPU effort has been spent on a certain task. CPU seconds are often normalized (so that a variable number can occur in the same actual second). CPU seconds can be important when profiling, but they do not map directly to user response time, nor are they directly comparable to (real time) seconds. time.clock() is deprecated because it returns real time seconds on Windows, but CPU seconds on unix, which prevents a consistent cross-platform interpretation. Duration: Elapsed time. The difference between the starting and ending times. A defined epoch creates an implicit (and usually large) duration. More precision can generally be provided for a relatively small duration. Drift: The accumulated error against true time, as defined externally to the system. Epoch: The reference point of a clock. For clocks providing civil time, this is often midnight as the day (and year) rolled over to January 1, 1970. For a clock_monotonic clock, the epoch may be undefined (represented as None). Latency: Delay. By the time a clock call returns, the real time has advanced, possibly by more than the precision of the clock. Microsecond: 1/1,000,000 of a second. Fast enough for most -- but not all -- profiling uses. Millisecond: 1/1,000 of a second. More than adequate for most end-to-end UI measurements, but often too coarse for profiling individual functions. Monotonic: Moving in at most one direction; for clocks, that direction is forward. A (nearly useless) clock that always returns exactly the same time is technically monotonic. In practice, most uses of monotonic with respect to clocks actually refer to a stronger set of guarantees, as described under clock_monotonic Nanosecond 1/1,000,000,000 of a second. The smallest unit of resolution -- and smaller than the actual precision -- available in current mainstream operating systems. Precision: Significant Digits. What is the smallest duration that the clock can distinguish? This differs from resolution in that a difference greater than the minimum precision is actually meaningful. Process Time: Time elapsed since the process began. It is typically measured in CPU time rather than real time, and typically does not advance while the process is suspended. Real Time: Time in the real world. This differs from Civil time in that it is not adjusted, but they should otherwise advance in lockstep. It is not related to the real time of Real Time [Operating] Systems. It is sometimes called wall clock time to avoid that ambiguity; unfortunately, that introduces different ambiguities. Resolution:
Re: [Python-Dev] PEP 418 glossary
On Wed, Apr 11, 2012 at 4:49 PM, Jim Jewett jimjjew...@gmail.com wrote: Clock: An instrument for measuring time. Different clocks have different characteristics; for example, a clock with nanonsecond precision Small typo. Otherwise, excellent reference document - thank you! Well worth gathering all those terms. ChrisA There's a glory for you! ___ 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 418 glossary
A few comments, YMMV. On Wed, Apr 11, 2012 at 3:49 PM, Jim Jewett jimjjew...@gmail.com wrote: Here is my strawman proposal, which does use slightly different definitions than the current PEP even for some terms that the PEP does define: Accuracy: Is the answer correct? Any clock will eventually drift; if a clock is intended to match Civil Time, it will need to be adjusted back to the true time. Accuracy is not a Boolean. Accuracy is the lack of difference from some standard. Adjusted: Resetting a clock to the correct time. This may be done either with a Step or by Slewing. Civil Time: Time of day; external to the system. 10:45:13am is a Civil time; 45 seconds is not. Provided by existing function time.localtime() and time.gmtime(). Not changed by this PEP. Clock: An instrument for measuring time. Different clocks have different characteristics; for example, a clock with nanonsecond precision may start to drift after a few minutes, while a less precise clock remained accurate for days. This PEP is primarily concerned with clocks which use a unit of seconds. Clock_Monotonic: The characteristics expected of a monotonic clock in practice. Whose practice? In C++, monotonic was defined as mathematically monotonic, and rather than talk about what's expected of a monotonic clock in practice, they chose to use a different term (steady) for the clocks that (come closer to) DTRT. I think it would be best to use a different name. In addition to being monotonic, the clock should also be steady and have relatively high precision, and should be convertible to a unit of seconds. The tradeoffs often include lack of a defined epoch or mapping to Civil Time, and being more expensive (in latency, power usage, or duration spent within calls to the clock itself) to use. For example, the clock may represent (a constant multiplied by) ticks of a specific quartz timer on a specific CPU core, and calls would therefore require synchronization between cores. The original motivation for this PEP was to provide a cross-platform name for requesting a clock_monotonic clock. Counter: A clock which increments each time a certain event occurs. A counter is strictly monotonic, but not clock_monotonic. It can be used to generate a unique (and ordered) timestamp, but these timestamps cannot be mapped to civil time; tick creation may well be bursty, with several advances in the same millisecond followed by several days without any advance. CPU Time: A measure of how much CPU effort has been spent on a certain task. CPU seconds are often normalized (so that a variable number can occur in the same actual second). CPU seconds can be important when profiling, but they do not map directly to user response time, nor are they directly comparable to (real time) seconds. time.clock() is deprecated because it returns real time seconds on Windows, but CPU seconds on unix, which prevents a consistent cross-platform interpretation. Duration: Elapsed time. The difference between the starting and ending times. A defined epoch creates an implicit (and usually large) duration. More precision can generally be provided for a relatively small duration. Epoch is independent of duration. Rather, epoch can be combined with duration to provide a clock that measures civil time. Drift: The accumulated error against true time, as defined externally to the system. Epoch: The reference point of a clock. For clocks providing civil time, this is often midnight as the day (and year) rolled over to January 1, 1970. For a clock_monotonic clock, the epoch may be undefined (represented as None). Latency: Delay. By the time a clock call returns, the real time has advanced, possibly by more than the precision of the clock. Microsecond: 1/1,000,000 of a second. Fast enough for most -- but not all -- profiling uses. Millisecond: 1/1,000 of a second. More than adequate for most end-to-end UI measurements, but often too coarse for profiling individual functions. Monotonic: Moving in at most one direction; for clocks, that direction is forward. A (nearly useless) clock that always returns exactly the same time is technically monotonic. In practice, most uses of monotonic with respect to clocks actually refer to a stronger set of guarantees, as described under clock_monotonic Again, even in a glossary you need to be vague about monotonic. Nanosecond 1/1,000,000,000 of a second. The smallest unit of resolution -- and smaller than the actual precision -- available in current mainstream operating systems. Precision: Significant Digits. What is the smallest duration that the clock can distinguish? This differs from resolution in that a difference greater than the minimum precision is actually meaningful. I think you have this backwards. Precision is the number of significant digits reported. Resolution
[Python-Dev] Meaning of the f_tstate field in the frame object
What is the purpose of the f_tstate field in the frame object? It holds a borrowed reference to the threadstate in which the frame was created. If PyThreadState_GET()-frame-f_state == PyThreadState_GET() then it is redundant. But what if PyThreadState_GET()-frame-f_state != PyThreadState_GET(), which can happen when a generator is created in one thread and called in another? Removing the f_tstate field provides a clean fix to http://bugs.python.org/issue14432, but is it safe to do so? I think it is safe, but does anyone think otherwise? (Removing it requires the replacement of frame-f_state with PyThreadState_GET() at one place in _PyEval_CallTracing) Cheers, Mark. ___ 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] Experimenting with STM on CPython
Hi all, This is an update on the (so far PyPy-only) project of adding Automatic Mutual Exclusion to Python, via STM (Software Transactional Memory). For the motivation, see here: http://morepypy.blogspot.com/2012/03/call-for-donations-for-software.html The point is that [with STM/AME] your program is always correct, and can be tweaked to improve performance. This is the opposite from what explicit threads and locks give you, which is a performant program which you need to tweak to remove bugs. Arguably, this approach is the reason for why you use Python in the first place :-) The update is: I now believe that it might be (reasonably) possible to apply the same techniques to CPython, and not only to PyPy. For now I am experimenting with applying them in a simple CPython-like interpreter. If it works, it might end up as a patch to the core parts of CPython. The interesting property is that it would still be able to run unmodified C extension modules --- the Python code gets the benefits of multi-core STM/AME only if it involves only the patched parts of the C code, but in all cases it still works correctly, falling back to single-core usage. I did not try to hack CPython so far, but only this custom interpreter for a Lisp language, whose implementation should be immediately familiar to anyone who knows CPython C code: https://bitbucket.org/arigo/duhton . The non-standard built-in function is transaction, which schedules a transaction to run later (see test/test_transaction.py). The code contains the necessary tweaks to reference counting, and seems to work on all examples, but leaks some of the objects so far. Fixing this directly might be possible, but I'm not sure yet (it might require interaction with the cycle-detecting GC of CPython). Moreover the performance hit is well below 2x, more like 20%. If anyone is interested, I could create a dedicated mailing list in order to discuss this in more details. From experience I would think that this has the potential to become a Psyco-like experiment, but unlike 10 years ago, today I'm not ready any more to dive completely alone into a project of that scale :-) A bientôt, Armin. ___ 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] Experimenting with STM on CPython
Armin Rigo, 11.04.2012 13:47: This is an update on the (so far PyPy-only) project of adding Automatic Mutual Exclusion to Python, via STM (Software Transactional Memory). [...] Moreover the performance hit is well below 2x, more like 20%. Hmm, those 20% refer to STM, right? Without hardware support? Then hardware support could be expected to drop that even further? Did you do any experiments with running parallel code so far, to see if that scales as expected? Stefan ___ 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 418 glossary
On Wed, Apr 11, 2012 at 7:30 PM, Stephen J. Turnbull step...@xemacs.org wrote: Clock_Monotonic: The characteristics expected of a monotonic clock in practice. Whose practice? In C++, monotonic was defined as mathematically monotonic, and rather than talk about what's expected of a monotonic clock in practice, they chose to use a different term (steady) for the clocks that (come closer to) DTRT. I think it would be best to use a different name. We may as well stick with the POSIX terminology (noting cases where there are discrepancies with other uses of terms). For better or for worse, Python is a POSIX based language. Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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] Experimenting with STM on CPython
Hi Stefan, On Wed, Apr 11, 2012 at 14:29, Stefan Behnel stefan...@behnel.de wrote: Moreover the performance hit is well below 2x, more like 20%. Hmm, those 20% refer to STM, right? Without hardware support? Then hardware support could be expected to drop that even further? Yes, that's using STM on my regular laptop. How HTM would help remains unclear at this point, because in this approach transactions are typically rather large --- likely much larger than what the first-generation HTM-capable processors will support next year. But 20% looks good anyway :-) Did you do any experiments with running parallel code so far, to see if that scales as expected? Yes, it scales very nicely on small non-conflicting examples. I believe that it scales just as nicely on large examples on CPython too, based on the approach --- as long as we, as CPython developers, make enough efforts to adapt a sufficiently large portion of the CPython C code base (which would mean: most mutable built-in objects' implementation). A bientôt, Armin. ___ 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 change to logging.handlers.SysLogHandler
Gregory P. Smith greg at krypto.org writes: Given the existing brokenness I personally think that removing the BOM insertion (because it is incorrect) in 2.7 and 3.2 is fine if you cannot find a way to make it correct in 2.7 and 3.2 without breaking existing APIs. I have an idea for a change which won't require changing any public APIs; though it does change the behaviour so that BOM insertion doesn't happen any more, anyone who needs a BOM can have it by a simple update to their format string. The idea is outlined here: http://bugs.python.org/issue14452#msg158030 Comments would be appreciated. Regards, Vinay Sajip ___ 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] Experimenting with STM on CPython
Armin Rigo, 11.04.2012 14:51: On Wed, Apr 11, 2012 at 14:29, Stefan Behnel wrote: Moreover the performance hit is well below 2x, more like 20%. Hmm, those 20% refer to STM, right? Without hardware support? Then hardware support could be expected to drop that even further? Yes, that's using STM on my regular laptop. How HTM would help remains unclear at this point, because in this approach transactions are typically rather large --- likely much larger than what the first-generation HTM-capable processors will support next year. Ok. I guess once the code is there, the hardware will eventually catch up. However, I'm not sure what you consider large. A lot of manipulation operations for the builtin types are not all that involved, at least in the normal cases (read: fast paths) that involve no memory reallocation etc., and anything that can be called by and doesn't call into the interpreter would be a complete and independent transaction all by itself, as the GIL is allowed to be released between any two ticks. Do you know if hybrid TM is possible at this level? I.e. short transactions run in hardware, long ones in software? (Assuming we know what's long and short, I guess...) But 20% looks good anyway :-) Oh, definitely. Did you do any experiments with running parallel code so far, to see if that scales as expected? Yes, it scales very nicely on small non-conflicting examples. I believe that it scales just as nicely on large examples on CPython too, based on the approach --- as long as we, as CPython developers, make enough efforts to adapt a sufficiently large portion of the CPython C code base (which would mean: most mutable built-in objects' implementation). Right, that would involve some work. But the advantage, as I understand it, is that this can be done incrementally. I.e. make it work, then make it fast and make it scale. Stefan ___ 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] Experimenting with STM on CPython
Stefan Behnel, 11.04.2012 15:31: Armin Rigo, 11.04.2012 14:51: On Wed, Apr 11, 2012 at 14:29, Stefan Behnel wrote: Did you do any experiments with running parallel code so far, to see if that scales as expected? Yes, it scales very nicely on small non-conflicting examples. I believe that it scales just as nicely on large examples on CPython too, based on the approach --- as long as we, as CPython developers, make enough efforts to adapt a sufficiently large portion of the CPython C code base (which would mean: most mutable built-in objects' implementation). Right, that would involve some work. But the advantage, as I understand it, is that this can be done incrementally. Hmm, and according to the papers that are referenced on the PyPy proposal page, at least some of this work has already been done, it seems. http://pypy.org/tmdonate.html#why-hasn-t-the-idea-been-implemented-for-cpython-already Stefan ___ 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] Experimenting with STM on CPython
Yes, that's using STM on my regular laptop. How HTM would help remains unclear at this point, because in this approach transactions are typically rather large --- likely much larger than what the first-generation HTM-capable processors will support next year. Ok. I guess once the code is there, the hardware will eventually catch up. However, I'm not sure what you consider large. A lot of manipulation operations for the builtin types are not all that involved, at least in the normal cases (read: fast paths) that involve no memory reallocation etc., and anything that can be called by and doesn't call into the interpreter would be a complete and independent transaction all by itself, as the GIL is allowed to be released between any two ticks. Large as in L2-cache large, and as in you won't get a page fault or an interrupt, you won't make any syscall, any I/O... ;-) ___ 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] Experimenting with STM on CPython
On Wed, 11 Apr 2012 15:31:09 +0200 Stefan Behnel stefan...@behnel.de wrote: Ok. I guess once the code is there, the hardware will eventually catch up. However, I'm not sure what you consider large. A lot of manipulation operations for the builtin types are not all that involved, at least in the normal cases (read: fast paths) that involve no memory reallocation etc., and anything that can be called by and doesn't call into the interpreter would be a complete and independent transaction all by itself, as the GIL is allowed to be released between any two ticks. I think Armin's plan is not to work at the bytecode level, but make transactions explicit (at least in framework code - e.g. Twisted or Stackless -, perhaps not in user code). Perhaps he can elaborate on that. Do you know if hybrid TM is possible at this level? I.e. short transactions run in hardware, long ones in software? (Assuming we know what's long and short, I guess...) There are other issues than the size of transactions. For example, one issue is that not all operations may be allowed in a transaction: “In addition, there are a number of instructions that may cause an abort on specific implementations. These instructions include x87 and MMX, mixed access to XMM and YMM registers, updates to non-status parts of EFLAGs, updating segment, debug or control registers, ring transitions, cache and TLB control instructions, any non-writeback memory type accesses, processor state save, interrupts, I/O, virtualization (VMX), trusted execution (SMX) and several miscellaneous types.” http://realworldtech.com/page.cfm?ArticleID=RWT021512050738 So, realistically, a (S)TM implementation in CPython (and probably also in PyPy) would have to stand on its own merits, rather than betting on pie-in-the-sky improvements of HTM implementations. Regards Antoine. ___ 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] Experimenting with STM on CPython
Hi Antoine, hi Stefan, On Wed, Apr 11, 2012 at 16:33, Antoine Pitrou solip...@pitrou.net wrote: I think Armin's plan is not to work at the bytecode level, but make transactions explicit (at least in framework code - e.g. Twisted or Stackless -, perhaps not in user code). Perhaps he can elaborate on that. Yes, precisely. It should be explained in the proposal. The references in http://pypy.org/tmdonate.html#why-hasn-t-the-idea-been-implemented-for-cpython-already; don't change CPython (or only minimally). They use Hardware TM, but (the most important thing imho) they target bytecode-level transactions --- i.e. the programmer is still stuck with the threading module. About using it explicitly in user code: I found out that there are use cases to do so directly. If you have a CPU-intensive program that does: for x in some_random_order_iterator: do_stuff_for(x) Then if the things you do are not too dependent on each other, you can win by replacing it with: for x in some_random_order_iterator: transaction.add(do_stuff_for, x) transaction.run() and no other change. It has exactly the same semantics, and in this case you don't really need a framework in which to hide the transaction.add(). Compare it with the situation of spawning threads: you need to carefully add locks *everywhere* or your program is buggy --- both in today's CPython or in a GIL-less, bytecode-level-transaction CPython. By the way, that's why I said that transactions are arbitrarily long: one transaction will be, in this case, everything that do_stuff_for(x) does. A bientôt, Armin. ___ 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] cpython: use assertWarns instead of check_warnings - Issue14341
On 11.04.2012 17:06, senthil.kumaran wrote:
http://hg.python.org/cpython/rev/751c7b81f6ee
changeset: 76241:751c7b81f6ee
parent: 76232:8a47d2322df0
user:Senthil Kumaransent...@uthcode.com
date:Wed Apr 11 23:05:49 2012 +0800
summary:
use assertWarns instead of check_warnings - Issue14341
files:
Lib/test/test_urllib2.py | 16 +---
1 files changed, 9 insertions(+), 7 deletions(-)
diff --git a/Lib/test/test_urllib2.py b/Lib/test/test_urllib2.py
--- a/Lib/test/test_urllib2.py
+++ b/Lib/test/test_urllib2.py
@@ -618,21 +618,23 @@
def test_method_deprecations(self):
req = Request(http://www.example.com;)
-with support.check_warnings(('', DeprecationWarning)):
+
+with self.assertWarns(DeprecationWarning) as cm:
req.add_data(data)
There's no need for adding the as cm if you don't need the cm object.
Georg
___
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] [RELEASED] Python 2.6.8, 2.7.3, 3.1.5, and 3.2.3
We're bursting with enthusiasm to announce the immediate availability of Python 2.6.8, 2.7.3, 3.1.5, and 3.2.3. These releases included several security fixes. Note: Virtualenvs created with older releases in the 2.6, 2.7, 3.1, or 3.2 series may not work with these bugfix releases. Specifically, the os module may not appear to have a urandom function. This is a virtualenv bug, which can be solved by recreating the broken virtualenvs with the newer Python versions. The main impetus for these releases is fixing a security issue in Python's hash based types, dict and set, as described below. Python 2.7.3 and 3.2.3 include the security patch and the normal set of bug fixes. Since Python 2.6 and 3.1 are maintained only for security issues, 2.6.8 and 3.1.5 contain only various security patches. The security issue exploits Python's dict and set implementations. Carefully crafted input can lead to extremely long computation times and denials of service. [1] Python dict and set types use hash tables to provide amortized constant time operations. Hash tables require a well-distributed hash function to spread data evenly across the hash table. The security issue is that an attacker could compute thousands of keys with colliding hashes; this causes quadratic algorithmic complexity when the hash table is constructed. To alleviate the problem, the new releases add randomization to the hashing of Python's string types (bytes/str in Python 3 and str/unicode in Python 2), datetime.date, and datetime.datetime. This prevents an attacker from computing colliding keys of these types without access to the Python process. Hash randomization causes the iteration order of dicts and sets to be unpredictable and differ across Python runs. Python has never guaranteed iteration order of keys in a dict or set, and applications are advised to never rely on it. Historically, dict iteration order has not changed very often across releases and has always remained consistent between successive executions of Python. Thus, some existing applications may be relying on dict or set ordering. Because of this and the fact that many Python applications which don't accept untrusted input are not vulnerable to this attack, in all stable Python releases mentioned here, HASH RANDOMIZATION IS DISABLED BY DEFAULT. There are two ways to enable it. The -R commandline option can be passed to the python executable. It can also be enabled by setting an environmental variable PYTHONHASHSEED to random. (Other values are accepted, too; pass -h to python for complete description.) More details about the issue and the patch can be found in the oCERT advisory [1] and the Python bug tracker [2]. Another related security issue fixed in these releases is in the expat XML parsing library. expat had the same hash security issue detailed above as Python's core types. The hashing algorithm used in the expat library is now randomized. A few other security issues were fixed. They are described on the release pages below. These releases are production releases. Downloads are at http://python.org/download/releases/2.6.8/ http://python.org/download/releases/2.7.3/ http://python.org/download/releases/3.1.5/ http://python.org/download/releases/3.2.3/ As always, please report bugs to http://bugs.python.org/ Happy-to-put-hash-attack-issues-behind-them-ly yours, The Python release team Barry Warsaw (2.6), Georg Brandl (3.2), and Benjamin Peterson (2.7 and 3.1) [1] http://www.ocert.org/advisories/ocert-2011-003.html [2] http://bugs.python.org/issue13703 ___ 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 418 glossary
On Apr 11, 2012, at 2:49 AM, Jim Jewett wrote: I believe PEP 418 (or at least the discussion) would benefit greatly from a glossary to encourage people to use the same definitions. This sort of information is a good candidate for the HOW-TO section of the docs. Raymond___ 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 418 glossary
2012/4/11 Jim Jewett jimjjew...@gmail.com: I believe PEP 418 (or at least the discussion) would benefit greatly from a glossary to encourage people to use the same definitions. This is arguably the Definitions section, but it should move either near the end or (preferably) ahead of the Functions. It also needs to be greatly expanded. I integrated a simplified version of your Glossary into the PEP. Some changes: * a monotonic clock has not necessary an high precision, on Windows, the two properties are exclusive * I replaced Clock Monotonic with Monotonic and removed the Monotonic term * I removed some questions Victor ___ 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] Failed issue tracker submission
An unexpected error occurred during the processing of your message. The tracker administrator is being notified. Return-Path: python-dev@python.org X-Original-To: rep...@bugs.python.org Delivered-To: roundup+trac...@psf.upfronthosting.co.za Received: from mail.python.org (mail.python.org [82.94.164.166]) by psf.upfronthosting.co.za (Postfix) with ESMTPS id E4BA91C99B for rep...@bugs.python.org; Thu, 12 Apr 2012 02:41:05 +0200 (CEST) Received: from albatross.python.org (localhost [127.0.0.1]) by mail.python.org (Postfix) with ESMTP id 3VSjwK4VJXzMYx for rep...@bugs.python.org; Thu, 12 Apr 2012 02:41:05 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=python.org; s=200901; t=1334191265; bh=lo47e+asT0uJCAqRxhHod6Ew5FD2UVZ/Hv0bVhpeOUw=; h=Date:Message-Id:Content-Type:MIME-Version: Content-Transfer-Encoding:From:To:Subject; b=FsM+hBGbG0zAjavHnV3td7hqCskSq6wdTfPSNViUvv+CdHDk2DvCJe20fZ430xpBb gn+4wlvxHKY9rHfNvO+XzyZLkec7f6XD4h7fFcztlkTJPPscZhKwgICtmO6NpfVyi8 ITZ9D8vkNOrSAp8Z9+dlmrDELiKwWuQ2S9dOHIyQ= Received: from localhost (HELO mail.python.org) (127.0.0.1) by albatross.python.org with SMTP; 12 Apr 2012 02:41:05 +0200 Received: from dinsdale.python.org (svn.python.org [IPv6:2001:888:2000:d::a4]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.python.org (Postfix) with ESMTPS for rep...@bugs.python.org; Thu, 12 Apr 2012 02:41:05 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=dinsdale.python.org ident=hg) by dinsdale.python.org with esmtp (Exim 4.72) (envelope-from python-dev@python.org) id 1SI85x-00062T-Eb for rep...@bugs.python.org; Thu, 12 Apr 2012 02:41:05 +0200 Date: Thu, 12 Apr 2012 02:41:05 +0200 Message-Id: e1si85x-00062t...@dinsdale.python.org Content-Type: text/plain; charset=utf8 MIME-Version: 1.0 Content-Transfer-Encoding: base64 From: python-dev@python.org To: rep...@bugs.python.org Subject: [issue14552] TmV3IGNoYW5nZXNldCBmMjVmYjdlMWQwNzYgYnkgUiBEYXZpZCBNdXJyYXkgaW4gYnJhbmNoICcz LjInOgojMTQ1NTI6IHJlbW92ZSByZWR1bmRhbnQgd29yZGluZyBpbiAndGVzdCcgZG9jcy4KaHR0 cDovL2hnLnB5dGhvbi5vcmcvY3B5dGhvbi9yZXYvZjI1ZmI3ZTFkMDc2CgoKTmV3IGNoYW5nZXNl dCBiZDM1M2YxMmMwMDcgYnkgUiBEYXZpZCBNdXJyYXkgaW4gYnJhbmNoICdkZWZhdWx0JzoKTWVy Z2UgZG9jIGZpeGVzICMxNDU1MyBhbmQgIzE0NTUyLgpodHRwOi8vaGcucHl0aG9uLm9yZy9jcHl0 aG9uL3Jldi9iZDM1M2YxMmMwMDcKCgpOZXcgY2hhbmdlc2V0IGQ2MGVmMTQxZTA5MCBieSBSIERh dmlkIE11cnJheSBpbiBicmFuY2ggJzIuNyc6CiMxNDU1MjogcmVtb3ZlIHJlZHVuZGFudCB3b3Jk aW5nIGluICd0ZXN0JyBkb2NzLgpodHRwOi8vaGcucHl0aG9uLm9yZy9jcHl0aG9uL3Jldi9kNjBl ZjE0MWUwOTAK ___ 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] [RELEASED] Python 2.6.8, 2.7.3, 3.1.5, and 3.2.3
On 4/11/2012 3:37 PM, Benjamin Peterson wrote: Downloads are at http://python.org/download/releases/2.6.8/ http://python.org/download/releases/2.7.3/ This page lists 'program databases' after the normal msi installers for Windows. I am puzzled and curious as to what those are, and I suspect other naive users will be too. http://python.org/download/releases/3.1.5/ http://python.org/download/releases/3.2.3/ No such thing here. -- Terry Jan 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/archive%40mail-archive.com
