Re: [Python-Dev] PEP 418 glossary
On Wed, Apr 11, 2012 at 4:49 PM, Jim Jewett wrote: > Clock: > An instrument for measuring time. Different clocks have different > characteristics; for example, a clock with 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 [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] PEP 418 glossary
A few comments, YMMV.
On Wed, Apr 11, 2012 at 3:49 PM, Jim Jewett 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 ; if a
> clock is intended to match , it will need to be
> 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 or by .
>
> 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
> may start to after a few minutes, while a less precise clock
> remained accurate for days. This PEP is primarily concerned with
> clocks which use a 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 , the should also be and
> have relatively high , and should be convertible to a
> of seconds. The tradeoffs often include lack of a defined
> or mapping to , and being more expensive (in
> , power usage, or 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 , but not . It can be
> used to generate a unique (and ordered) timestamp, but these
> timestamps cannot be mapped to ; 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 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 creates an implicit (and usually large)
> duration. More precision can generally be provided for a relatively
> small .
Epoch is independent of duration. Rather, epoch can be combined with
duration to provide a clock that measures .
> Drift:
> The accumulated error against "true" time, as defined externally
> to the system.
>
> Epoch:
> The reference point of a clock. For clocks providing time>, this is often midnight as the day (and year) rolled over to
> January 1, 1970. For a clock, the epoch may be
> undefined (represented as None).
>
> Latency:
> Delay. By the time a clock call returns, the 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
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 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 is the smallest duration that
is meaningful.
> Process Time:
> Time elapsed since the process began. It is typically measured in
> rather than , and typically
[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 [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] 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 [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] 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 [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] PEP 418 glossary
On Wed, Apr 11, 2012 at 7:30 PM, Stephen J. Turnbull 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 | [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] Experimenting with STM on CPython
Hi Stefan, 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. 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 [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] Possible change to logging.handlers.SysLogHandler
Gregory P. Smith 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 [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] 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 [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] 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 [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] 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 [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] Experimenting with STM on CPython
On Wed, 11 Apr 2012 15:31:09 +0200 Stefan Behnel 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 [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] Experimenting with STM on CPython
Hi Antoine, hi Stefan, On Wed, Apr 11, 2012 at 16:33, Antoine Pitrou 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 [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: 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 Kumaran
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
[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] [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 [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] 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 [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] PEP 418 glossary
2012/4/11 Jim Jewett : > 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 [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] Failed issue tracker submission
An unexpected error occurred during the processing of your message. The tracker administrator is being notified. Return-Path: X-Original-To: [email protected] Delivered-To: [email protected] Received: from mail.python.org (mail.python.org [82.94.164.166]) by psf.upfronthosting.co.za (Postfix) with ESMTPS id E4BA91C99B for ; 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 ; 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 ; 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 ) id 1SI85x-00062T-Eb for [email protected]; Thu, 12 Apr 2012 02:41:05 +0200 Date: Thu, 12 Apr 2012 02:41:05 +0200 Message-Id: Content-Type: text/plain; charset="utf8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 From: [email protected] To: [email protected] Subject: [issue14552] TmV3IGNoYW5nZXNldCBmMjVmYjdlMWQwNzYgYnkgUiBEYXZpZCBNdXJyYXkgaW4gYnJhbmNoICcz LjInOgojMTQ1NTI6IHJlbW92ZSByZWR1bmRhbnQgd29yZGluZyBpbiAndGVzdCcgZG9jcy4KaHR0 cDovL2hnLnB5dGhvbi5vcmcvY3B5dGhvbi9yZXYvZjI1ZmI3ZTFkMDc2CgoKTmV3IGNoYW5nZXNl dCBiZDM1M2YxMmMwMDcgYnkgUiBEYXZpZCBNdXJyYXkgaW4gYnJhbmNoICdkZWZhdWx0JzoKTWVy Z2UgZG9jIGZpeGVzICMxNDU1MyBhbmQgIzE0NTUyLgpodHRwOi8vaGcucHl0aG9uLm9yZy9jcHl0 aG9uL3Jldi9iZDM1M2YxMmMwMDcKCgpOZXcgY2hhbmdlc2V0IGQ2MGVmMTQxZTA5MCBieSBSIERh dmlkIE11cnJheSBpbiBicmFuY2ggJzIuNyc6CiMxNDU1MjogcmVtb3ZlIHJlZHVuZGFudCB3b3Jk aW5nIGluICd0ZXN0JyBkb2NzLgpodHRwOi8vaGcucHl0aG9uLm9yZy9jcHl0aG9uL3Jldi9kNjBl ZjE0MWUwOTAK ___ 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] [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 [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] [RELEASED] Python 2.6.8, 2.7.3, 3.1.5, and 3.2.3
On 12.04.2012 06:47, Terry Reedy wrote: 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. Here they are called "Visual Studio debug information files". I agree that "program database", while it is the official name of the file and the literal meaning of the file extension ".pdb", is not a very good description. Georg ___ 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
