Re: [Python-Dev] PEP 394 accepted
Congratulations to Kerrick Staley and Nick Coghlan, the authors of the PEP! It's good to hear that the python, python2 and python3 symlinks are now standardized in a PEP. I hope that most Linux distributions will follow this PEP :-) 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
Re: [Python-Dev] PEP 410 (Decimal timestamp): the implementation is ready for a review
Georg Brandl wrote:
Am 16.02.2012 11:14, schrieb Martin v. Löwis:
Am 16.02.2012 10:51, schrieb Victor Stinner:
2012/2/16 Martin v. Löwis mar...@v.loewis.de:
Maybe an alternative PEP could be written that supports the filesystem
copying use case only, using some specialized ns APIs? I really think
that all you need is st_{a,c,m}time_ns fields and os.utime_ns().
I'm -1 on that, because it will make people write complicated code.
Python 3.3 *has already* APIs for nanosecond timestamps:
os.utimensat(), os.futimens(), signal.sigtimedwait(), etc. These
functions expect a (seconds: int, nanoseconds: int) tuple.
I'm -1 on adding these APIs, also. Since Python 3.3 is not released
yet, it's not too late to revert them.
+1.
Sorry, is that +1 on the revert, or +1 on the APIs?
--
Steven
___
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 410 (Decimal timestamp): the implementation is ready for a review
Maybe it's okay to wait a few years on this, until either 128-bit floats are more common or cDecimal becomes the default floating point type? In the mean time for clock freaks we can have a few specialized APIs that return times in nanoseconds as a (long) integer. I don't think that the default float type does really matter here. If I understood correctly, the major issue with Decimal is that Decimal is not fully compatible with float: Decimal+float raises a TypeError. Can't we improve the compatibility between Decimal and float, e.g. by allowing Decimal+float? Decimal (base 10) + float (base 2) may loss precision and this issue matters in some use cases. So we still need a way to warn the user on loss of precision. We may add a global flag to allow Decimal+float and turn it on by default. Developers concerns by loss of precision can just turn the flag off at startup. Something like what we did in Python 2: allow str+unicode, and only switch to unicode when unicode was mature enough and well accepted :-) -- I have some questions about 128-bit float and Decimal. Currently, there is only one hardware supporting IEEE 754-2008 the 128-bit base-2: the IBM S/390, which is quite rare (at least on desktop :-)). Should we expect more CPU supporting this type in the (near) future? GCC, ICC and Clang implement this type in software, but there are license issues. At least with GCC which uses MPFR: the library is distributed under the GNU LGPL license, which is not compatible with the Python license. I didn't check Clang and ICC. I don't think that we can use 128-bit float by default before it is commonly available on hardware, because arithmetic in software is usually slower. We do also support platforms with a compiler not supporting 128-bit float, e.g. Windows with Visual Studio 2008. floating point in base 2 has also an issue with timestamp using 10^k resolution: such timestamp cannot be represented exactly in base 2 because 5 is coprime with 2 (10=2*5). The loss of precision is smaller than 10^-9 (nanosecond) with 128-bit float (for Epoch timestamps), but it would be more natural to use the base 10. System calls and functions of the C standard library use types with 10^k resolution: - 1 (time_t): time(), mktime(), localtime(), sleep(), ... - 10^-3 (int): poll() - 10^-6 (timeval, useconds_t): select(), gettimeofday(), usleep(), ... - 10^-9 (timespec): nanosleep(), utimensat(), clock_gettime(), ... decimal and cdecimal (_decimal) have the same performance issue, so I don't expect them to become the standard float type. But Decimal is able to store exactly a timetamp with a resolution of 10^k. There are also IEEE 754 for floating point types in base 10: decimal floating point (DFP), in 32, 64 and 128 bits. IBM System z9, System z10 and POWER6 CPU support these types in hardware. We may support this format in a specific module, or maybe use it to speedup the Python decimal module. But same issue here, such hardware is also rare, so we cannot use them by default or rely on them. 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
Re: [Python-Dev] PEP 394 accepted
On Fri, Feb 17, 2012 at 4:57 PM, Martin v. Löwis mar...@v.loewis.de wrote: As the PEP czar for PEP 394, I have reviewed it and am happy to say that I can accept it. Excellent news, thanks! I've pushed an updated version promoting it to Active status, and also incorporating Barry's suggestion of making it explicit that we expect the recommendation to change *eventually*, we just don't know when. I suppose that Nick will keep track of actually implementing it in Python 2.7. Indeed I will (as well as the comparatively minor change of converting the 3.x hard link to a symlink as described in the PEP). Unfortunately, dinsdale appears to have fallen over again, so I can't push the change right now :( Cheers, 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] PEP 410 (Decimal timestamp): the implementation is ready for a review
On Fri, Feb 17, 2012 at 9:33 PM, Victor Stinner victor.stin...@gmail.com wrote: Maybe it's okay to wait a few years on this, until either 128-bit floats are more common or cDecimal becomes the default floating point type? In the mean time for clock freaks we can have a few specialized APIs that return times in nanoseconds as a (long) integer. I don't think that the default float type does really matter here. If I understood correctly, the major issue with Decimal is that Decimal is not fully compatible with float: Decimal+float raises a TypeError. Can't we improve the compatibility between Decimal and float, e.g. by allowing Decimal+float? Decimal (base 10) + float (base 2) may loss precision and this issue matters in some use cases. So we still need a way to warn the user on loss of precision. We may add a global flag to allow Decimal+float and turn it on by default. Developers concerns by loss of precision can just turn the flag off at startup. Something like what we did in Python 2: allow str+unicode, and only switch to unicode when unicode was mature enough and well accepted :-) Disallowing implicit binary float and Decimal interoperability was a deliberate design decision in the original Decimal PEP, in large part to discourage use of binary floats in applications where exact Decimal values are required. While this has been relaxed slightly to allow the exact explicit conversion of a binary float value to its full binary precision Decimal equivalent, the original rationale against implicit interoperability still seems valid (See http://www.python.org/dev/peps/pep-0327/#id17). OTOH, people have long had to cope with the fact that integer+float interoperability runs the risk of triggering ValueError if the integer is too large - it seems to me that the signalling behaviour of implicit promotions from float to Decimal could be adequately controlled with the Inexact flag on the Decimal context. Cheers, 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] PEP 394 accepted
On Fri, Feb 17, 2012 at 10:27 PM, Nick Coghlan ncogh...@gmail.com wrote: Unfortunately, dinsdale appears to have fallen over again, so I can't push the change right now :( It appears that was a temporary glitch - the 2.7 change is now in Mercurial. Cheers, 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
[Python-Dev] dll name for embedding?
Hi all, I'm an app developer with a CPython dll in the folder of that app. In general, are there strict requirements about the dll name (a preference would be python.dll (easy to update (simple replace) ). I successfully used python.dll and a few standard modules, then I tried to use the sympy library and its import fails with an AV exception, unless I rename the dll back to the original python32.dll Is there an intrinsic filename requirement inside the CPython dll, modules, or are name-restrictions to be presumed only in case of third-party libs? ___ 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 410 (Decimal timestamp): the implementation is ready for a review
Victor Stinner victor.stin...@gmail.com wrote:
Can't we improve the compatibility between Decimal and float, e.g. by
allowing Decimal+float? Decimal (base 10) + float (base 2) may loss
precision and this issue matters in some use cases. So we still need a
way to warn the user on loss of precision.
I think this should be discussed in a separate thread. It's getting
slightly difficult to follow all the issues raised here.
decimal and cdecimal (_decimal) have the same performance issue,
don't expect them to become the standard float type.
Well, _decimal in tight loops is about 2 times slower than float.
There are areas where _decimal is actually faster than float, e.g
in the cdecimal repository printing and formatting seems to be
significantly faster:
$ cat format.py
import time
from decimal import Decimal
d = Decimal(7.928137192)
f = 7.928137192
out = open(/dev/null, w)
start = time.time()
for i in range(100):
out.write(%s\n % d)
end = time.time()
print(Decimal: , end-start)
start = time.time()
for i in range(100):
out.write(%s\n % f)
end = time.time()
print(float: , end-start)
start = time.time()
for i in range(100):
out.write({:020,.30}\n.format(d))
end = time.time()
print(Decimal: , end-start)
start = time.time()
for i in range(100):
out.write({:020,.30}\n.format(f))
end = time.time()
print(float: , end-start)
$ ./python format.py
Decimal: 0.8835508823394775
float: 1.3872010707855225
Decimal: 2.1346139907836914
float: 3.154278039932251
So it would make sense to profile the exact application in order to
determine the suitability of _decimal for timestamps.
There are also IEEE 754 for floating point types in base 10: decimal
floating point (DFP), in 32, 64 and 128 bits. IBM System z9, System
z10 and POWER6 CPU support these types in hardware. We may support
this format in a specific module, or maybe use it to speedup the
Python decimal module.
Apart from the rarity of these systems, decimal.py is arbitrary precision.
If I restricted _decimal to DECIMAL64, I could probably speed it up further.
All that said, personally I wouldn't have problems with a chunked representation
that includes nanoseconds, thus avoiding the decimal/float discusion entirely.
I'm also a happy user of:
http://cr.yp.to/libtai/tai64.html#tai64n
Stefan Krah
___
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 for new dictionary implementation
On 16/02/12 20:45, Antoine Pitrou wrote: On Wed, 08 Feb 2012 19:18:14 + Mark Shannonm...@hotpy.org wrote: Proposed PEP for new dictionary implementation, PEP 410? is attached. So, I'm running a few benchmarks using Twisted's test suite (see https://bitbucket.org/pitrou/t3k/wiki/Home). At the end of `python -i bin/trial twisted.internet.test`: - vanilla 3.3: RSS = 94 MB - new dict:RSS = 91 MB At the end of `python -i bin/trial twisted.python.test`: - vanilla 3.3: RSS = 31.5 MB - new dict:RSS = 30 MB At the end of `python -i bin/trial twisted.conch.test`: - vanilla 3.3: RSS = 68 MB - new dict:RSS = 42 MB (!) At the end of `python -i bin/trial twisted.trial.test`: - vanilla 3.3: RSS = 32 MB - new dict:RSS = 30 MB At the end of `python -i bin/trial twisted.test`: - vanilla 3.3: RSS = 62 MB - new dict:RSS = 78 MB (!) In theory, new-dict should never use more a few kbs more than vanilla. That looks like a serious leak. I'll investigate as soon as I get a chance. Which revision of new-dict are you using? Cheers, Mark. Runtimes were mostly similar in these test runs. Perspective broker benchmark (doc/core/benchmarks/tpclient.py and doc/core/benchmarks/tpserver.py): - vanilla 3.3: 422 MB/sec - new dict:402 MB/sec 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/mark%40hotpy.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] A new dictionary implementation
On 15/02/12 21:09, Yury Selivanov wrote:
Hello Mark,
First, I've back-ported your patch on python 3.2.2 (which was relatively
easy). Almost all tests pass, and those that don't are always failing on
my machine if I remember. The patch can be found here: http://goo.gl/nSzzY
Then, I compared memory footprint of one of our applications (300,000 LOC)
and saw it about 6% less than on vanilla python 3.2.2 (660 MB of reserved
process memory compared to 702 MB; Linux Gentoo 64bit) The application is
written in heavy OOP style (for instance, ~1000 classes are generated by our
ORM on the fly, and there are approximately the same amount of hand-written
ones) so I hoped for a much bigger saving.
As for the patch itself I found one use-case, where python with the patch
behaves differently::
class Foo:
def __init__(self, msg):
self.msg = msg
f = Foo('123')
class _str(str):
pass
print(f.msg)
print(getattr(f, _str('msg')))
The above snippet works perfectly on vanilla py3.2, but fails on the patched
one (even on 3.3 compiled from your 'cpython_new_dict' branch) I'm not sure
that it's a valid code, though. If not, then we need to fix some python
internals to add exact type check in 'getattr', in the 'operator.getattr', etc.
And if it is - your patch needs to be fixed. In any case, I propose to add
the above code to the python test-suite, with either expecting a result or an
exception.
Your code is valid, the bug is in my code.
I've fixed and updated the repository.
More tests to be added later.
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
Re: [Python-Dev] PEP for new dictionary implementation
On Fri, 17 Feb 2012 13:10:51 + Mark Shannon m...@hotpy.org wrote: On 16/02/12 20:45, Antoine Pitrou wrote: On Wed, 08 Feb 2012 19:18:14 + Mark Shannonm...@hotpy.org wrote: Proposed PEP for new dictionary implementation, PEP 410? is attached. So, I'm running a few benchmarks using Twisted's test suite (see https://bitbucket.org/pitrou/t3k/wiki/Home). At the end of `python -i bin/trial twisted.internet.test`: - vanilla 3.3: RSS = 94 MB - new dict:RSS = 91 MB At the end of `python -i bin/trial twisted.python.test`: - vanilla 3.3: RSS = 31.5 MB - new dict:RSS = 30 MB At the end of `python -i bin/trial twisted.conch.test`: - vanilla 3.3: RSS = 68 MB - new dict:RSS = 42 MB (!) At the end of `python -i bin/trial twisted.trial.test`: - vanilla 3.3: RSS = 32 MB - new dict:RSS = 30 MB At the end of `python -i bin/trial twisted.test`: - vanilla 3.3: RSS = 62 MB - new dict:RSS = 78 MB (!) In theory, new-dict should never use more a few kbs more than vanilla. That looks like a serious leak. I'll investigate as soon as I get a chance. Which revision of new-dict are you using? 6c4d5d9dfc6d Thanks :) 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] PEP 410 (Decimal timestamp): the implementation is ready for a review
On 02/16/2012 02:14 AM, Martin v. Löwis wrote:
Am 16.02.2012 10:51, schrieb Victor Stinner:
2012/2/16 Martin v. Löwismar...@v.loewis.de:
Maybe an alternative PEP could be written that supports the filesystem
copying use case only, using some specialized ns APIs? I really think
that all you need is st_{a,c,m}time_ns fields and os.utime_ns().
I'm -1 on that, because it will make people write complicated code.
Python 3.3 *has already* APIs for nanosecond timestamps:
os.utimensat(), os.futimens(), signal.sigtimedwait(), etc. These
functions expect a (seconds: int, nanoseconds: int) tuple.
I'm -1 on adding these APIs, also. Since Python 3.3 is not released
yet, it's not too late to revert them.
+1. I also think they should be removed in favor of adding support for
a nanosecond-friendly representation to the existing APIs (os.utime,
etc). Python is not C, we don't need three functions that do the same
thing but take different representations as their arguments.
/arry
___
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] Summary of Python tracker Issues
ACTIVITY SUMMARY (2012-02-10 - 2012-02-17)
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:
open3257 (+11)
closed 22567 (+44)
total 25824 (+55)
Open issues with patches: 1391
Issues opened (40)
==
#13609: Add os.get_terminal_size() function
http://bugs.python.org/issue13609 reopened by Arfrever
#13866: {urllib,urllib.parse}.urlencode should not use quote_plus
http://bugs.python.org/issue13866 reopened by Stephen.Day
#13989: gzip always returns byte strings, no text mode
http://bugs.python.org/issue13989 opened by maubp
#13990: Benchmarks: 2to3 failures on the py3 side
http://bugs.python.org/issue13990 opened by francismb
#13992: Segfault in PyTrash_destroy_chain
http://bugs.python.org/issue13992 opened by Aaron.Staley
#13997: Clearly explain the bare minimum Python 3 users should know ab
http://bugs.python.org/issue13997 opened by ncoghlan
#13998: Lookbehind assertions go behind the start position for the mat
http://bugs.python.org/issue13998 opened by Devin Jeanpierre
#13999: Queue references in multiprocessing doc points to Queue module
http://bugs.python.org/issue13999 opened by sandro.tosi
#14001: CVE-2012-0845 Python v2.7.2 / v3.2.2 (SimpleXMLRPCServer): DoS
http://bugs.python.org/issue14001 opened by iankko
#14002: distutils2 fails to install a package from PyPI on Python 2.7.
http://bugs.python.org/issue14002 opened by pmoore
#14003: __self__ on built-in functions is not as documented
http://bugs.python.org/issue14003 opened by SpecLad
#14004: Distutils filelist selects too many files on Windows
http://bugs.python.org/issue14004 opened by jason.coombs
#14005: IDLE Crash when running/saving a file
http://bugs.python.org/issue14005 opened by Scott.Bowman
#14006: Improve the documentation of xml.etree.ElementTree
http://bugs.python.org/issue14006 opened by eli.bendersky
#14007: xml.etree.ElementTree - XMLParser and TreeBuilder's doctype()
http://bugs.python.org/issue14007 opened by eli.bendersky
#14009: Clearer documentation for cElementTree
http://bugs.python.org/issue14009 opened by eric.araujo
#14010: deeply nested filter segfaults
http://bugs.python.org/issue14010 opened by alex
#14011: packaging should use shutil archiving functions transparently
http://bugs.python.org/issue14011 opened by eric.araujo
#14012: Misc tarfile fixes
http://bugs.python.org/issue14012 opened by eric.araujo
#14013: tarfile should expose supported formats
http://bugs.python.org/issue14013 opened by eric.araujo
#14014: codecs.StreamWriter.reset contract not fulfilled
http://bugs.python.org/issue14014 opened by Jim.Jewett
#14015: surrogateescape largely missing from documentation
http://bugs.python.org/issue14015 opened by Jim.Jewett
#14017: Make it easy to create a new TextIOWrapper based on an existin
http://bugs.python.org/issue14017 opened by ncoghlan
#14018: OS X installer does not detect bad symlinks created by Xcode 3
http://bugs.python.org/issue14018 opened by ned.deily
#14019: Unify tests for str.format and string.Formatter
http://bugs.python.org/issue14019 opened by ncoghlan
#14020: Improve HTMLParser doc
http://bugs.python.org/issue14020 opened by ezio.melotti
#14023: bytes implied to be mutable
http://bugs.python.org/issue14023 opened by SpecLad
#14026: test_cmd_line_script should include more sys.argv checks
http://bugs.python.org/issue14026 opened by ncoghlan
#14027: distutils2 lack of pysetup.bat
http://bugs.python.org/issue14027 opened by åå.ç½
#14030: Be more careful about selecting the compiler in distutils
http://bugs.python.org/issue14030 opened by djc
#14032: test_cmd_line_script prints undefined 'data' variable
http://bugs.python.org/issue14032 opened by Jason.Yeo
#14034: the example in argparse doc is too complex
http://bugs.python.org/issue14034 opened by tshepang
#14035: behavior of test.support.import_fresh_module
http://bugs.python.org/issue14035 opened by flox
#14036: urlparse insufficient port property validation
http://bugs.python.org/issue14036 opened by zulla
#14037: Allow grouping of argparse subparser commands in help output
http://bugs.python.org/issue14037 opened by ncoghlan
#14038: Packaging test support code raises exception
http://bugs.python.org/issue14038 opened by vinay.sajip
#14039: Add metavar argument to add_subparsers() in argparse
http://bugs.python.org/issue14039 opened by ncoghlan
#14040: Deprecate some of the module file formats
http://bugs.python.org/issue14040 opened by pitrou
#14042: json.dumps() documentation is slightly incorrect.
http://bugs.python.org/issue14042 opened by tomchristie
#14043: Speed-up importlib's _FileFinder
http://bugs.python.org/issue14043 opened by pitrou
Most recent 15 issues with no replies (15)
==
#14043: Speed-up importlib's _FileFinder
Re: [Python-Dev] PEP for new dictionary implementation
On Fri, Feb 17, 2012 at 1:50 AM, Martin v. Löwis mar...@v.loewis.de wrote: Good idea. However, how do you track per-dict how large the table is? [Or, rather, what is the highest index needed to store any values that are actually set for this instance.] To determine whether it needs to grow the array, it needs to find out how large the array is, no? So: how do you do that? Ah, now I understand; you do need a single ssize_t either on the dict or at the head of the values array to indicate how many slots it has actually allocated. It *may* also be worthwhile to add a second ssize_t to indicate how many are currently in use, for faster results in case of len. But the dict is guaranteed to have at least one free slot, so that extra index will never make the allocation larger than the current code. -jJ ___ 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 for new dictionary implementation
On 17 February 2012 at 17:42 Jim Jewett jimjjew...@gmail.com wrote: On Fri, Feb 17, 2012 at 1:50 AM, Martin v. Löwis mar...@v.loewis.de wrote: Good idea. However, how do you track per-dict how large the table is? [Or, rather, what is the highest index needed to store any values that are actually set for this instance.] To determine whether it needs to grow the array, it needs to find out how large the array is, no? So: how do you do that? Ah, now I understand; you do need a single ssize_t either on the dict or at the head of the values array to indicate how many slots it has actually allocated. It *may* also be worthwhile to add a second ssize_t to indicate how many are currently in use, for faster results in case of len. But the dict is guaranteed to have at least one free slot, so that extra index will never make the allocation larger than the current code. The dict already has a field indicating how many items are in use, the ma_used field. 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
Re: [Python-Dev] PEP 410 (Decimal timestamp): the implementation is ready for a review
Am 17.02.2012 10:28, schrieb Steven D'Aprano:
Georg Brandl wrote:
Am 16.02.2012 11:14, schrieb Martin v. Löwis:
Am 16.02.2012 10:51, schrieb Victor Stinner:
2012/2/16 Martin v. Löwis mar...@v.loewis.de:
Maybe an alternative PEP could be written that supports the filesystem
copying use case only, using some specialized ns APIs? I really think
that all you need is st_{a,c,m}time_ns fields and os.utime_ns().
I'm -1 on that, because it will make people write complicated code.
Python 3.3 *has already* APIs for nanosecond timestamps:
os.utimensat(), os.futimens(), signal.sigtimedwait(), etc. These
functions expect a (seconds: int, nanoseconds: int) tuple.
I'm -1 on adding these APIs, also. Since Python 3.3 is not released
yet, it's not too late to revert them.
+1.
Sorry, is that +1 on the revert, or +1 on the APIs?
It's on what Martin said; you're right, it was a bit too ambiguous even
for a RM :)
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
Re: [Python-Dev] folding cElementTree behind ElementTree in 3.3
On Fri, Feb 17, 2012 at 4:29 AM, Ezio Melotti ezio.melo...@gmail.com wrote: I'm assuming that eventually the module will be removed (maybe for Python 4?), and I don't expect nor want to seen it removed in the near future. If something gets removed it should be deprecated first, and it's usually better to deprecate it sooner so that the developers have more time to update their code. Not really - as soon as we programmatically deprecate something, it means anyone with a strict warnings policy (or with customers that have such a policy) has to update their code *now*. (Previously it was even worse than that, which is why deprecation warnings are no longer displayed by default). For things that we have no intention of deprecating in 3.x, but will likely ditch in a hypothetical future Python 4000, we'll almost certainly do exactly what we did with Pyk: later in the 3.x series, add a -4 command line switch and a sys.py4kwarning flag to trigger conditional deprecation warnings. So, assuming things continue as they have for the first couple of decades of Python's existence, we can probably start worrying about it some time around 2020 :) Cheers, 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] folding cElementTree behind ElementTree in 3.3
On 18/02/2012 0.04, Nick Coghlan wrote: On Fri, Feb 17, 2012 at 4:29 AM, Ezio Melottiezio.melo...@gmail.com wrote: I'm assuming that eventually the module will be removed (maybe for Python 4?), and I don't expect nor want to seen it removed in the near future. If something gets removed it should be deprecated first, and it's usually better to deprecate it sooner so that the developers have more time to update their code. Not really - as soon as we programmatically deprecate something, it means anyone with a strict warnings policy (or with customers that have such a policy) has to update their code *now*. (Previously it was even worse than that, which is why deprecation warnings are no longer displayed by default). The ones with a strict warning policy should be ready to deal with this situation. A possible solution (that I already proposed a while ago) would be to reuse the 2to3 framework to provide fixers that could be used for these mechanical updates between 3.x releases. For example I wrote a 2to3 fixer to replace all the deprecate unittest methods (fail*, some assert*) with the correct ones, but this can't be used to fix them while moving from 3.1 to 3.2. For things that we have no intention of deprecating in 3.x, but will likely ditch in a hypothetical future Python 4000, we'll almost certainly do exactly what we did with Pyk: later in the 3.x series, add a -4 command line switch and a sys.py4kwarning flag to trigger conditional deprecation warnings. I think Guido mentioned somewhere that this hypothetical Python 4000 will most likely be backward compatible, so we would still need a regular deprecation period. So, assuming things continue as they have for the first couple of decades of Python's existence, we can probably start worrying about it some time around 2020 :) What bothers me most is that a valid mechanism to warn users who cares about things that will be removed is being hindered in several ways. DeprecationWarnings were first silenced (and this is fine as long as the developers are educated to enable warnings while testing), now discouraged (because people are still able to make them visible and also to turn them into errors), and on the tracker there's even a discussion about making the deprecation notes in the doc less visible (because the red boxes are too scary). See also http://mail.python.org/pipermail/python-dev/2011-October/114199.html Best Regards, Ezio Melotti Cheers, Nick. ___ 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] PEP 410, 3rd revision, Decimal timestamp
PEP: 410 Title: Use decimal.Decimal type for timestamps Version: $Revision$ Last-Modified: $Date$ Author: Victor Stinner victor.stin...@haypocalc.com Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 01-February-2012 Python-Version: 3.3 Abstract Decimal becomes the official type for high-resolution timestamps to make Python support new functions using a nanosecond resolution without loss of precision. Motivation == Python 2.3 introduced float timestamps to support sub-second resolutions. os.stat() uses float timestamps by default since Python 2.5. Python 3.3 introduced functions supporting nanosecond resolutions: * os module: futimens(), utimensat() * time module: clock_gettime(), clock_getres(), monotonic(), wallclock() os.stat() reads nanosecond timestamps but returns timestamps as float. The Python float type uses binary64 format of the IEEE 754 standard. With a resolution of one nanosecond (10\ :sup:`-9`), float timestamps lose precision for values bigger than 2\ :sup:`24` seconds (194 days: 1970-07-14 for an Epoch timestamp). Nanosecond resolution is required to set the exact modification time on filesystems supporting nanosecond timestamps (e.g. ext4, btrfs, NTFS, ...). It helps also to compare the modification time to check if a file is newer than another file. Use cases: copy the modification time of a file using shutil.copystat(), create a TAR archive with the tarfile module, manage a mailbox with the mailbox module, etc. An arbitrary resolution is preferred over a fixed resolution (like nanosecond) to not have to change the API when a better resolution is required. For example, the NTP protocol uses fractions of 2\ :sup:`32` seconds (approximatively 2.3 × 10\ :sup:`-10` second), whereas the NTP protocol version 4 uses fractions of 2\ :sup:`64` seconds (5.4 × 10\ :sup:`-20` second). .. note:: With a resolution of 1 microsecond (10\ :sup:`-6`), float timestamps lose precision for values bigger than 2\ :sup:`33` seconds (272 years: 2242-03-16 for an Epoch timestamp). With a resolution of 100 nanoseconds (10\ :sup:`-7`, resolution used on Windows), float timestamps lose precision for values bigger than 2\ :sup:`29` seconds (17 years: 1987-01-05 for an Epoch timestamp). Specification = Add decimal.Decimal as a new type for timestamps. Decimal supports any timestamp resolution, support arithmetic operations and is comparable. It is possible to coerce a Decimal to float, even if the conversion may lose precision. The clock resolution can also be stored in a Decimal object. Add an optional *timestamp* argument to: * os module: fstat(), fstatat(), lstat(), stat() (st_atime, st_ctime and st_mtime fields of the stat structure), sched_rr_get_interval(), times(), wait3() and wait4() * resource module: ru_utime and ru_stime fields of getrusage() * signal module: getitimer(), setitimer() * time module: clock(), clock_gettime(), clock_getres(), monotonic(), time() and wallclock() The *timestamp* argument value can be float or Decimal, float is still the default for backward compatibility. The following functions support Decimal as input: * datetime module: date.fromtimestamp(), datetime.fromtimestamp() and datetime.utcfromtimestamp() * os module: futimes(), futimesat(), lutimes(), utime() * select module: epoll.poll(), kqueue.control(), select() * signal module: setitimer(), sigtimedwait() * time module: ctime(), gmtime(), localtime(), sleep() The os.stat_float_times() function is deprecated: use an explicit cast using int() instead. .. note:: The decimal module is implemented in Python and is slower than float, but there is a new C implementation which is almost ready for inclusion in CPython. Backwards Compatibility === The default timestamp type is unchanged, so there is no impact on backward compatibility nor on performances. The new timestamp type, decimal.Decimal, is only returned when requested explicitly. Objection: clocks accuracy == Computer clocks and operating systems are inaccurate and fail to provide nanosecond accuracy in practice. A nanosecond is what it takes to execute a couple of CPU instructions. Even on a real-time operating system, a nanosecond-precise measurement is already obsolete when it starts being processed by the higher-level application. A single cache miss in the CPU will make the precision worthless. .. note:: Linux *actually* is able to measure time in nanosecond precision, even though it is not able to keep its clock synchronized to UTC with a nanosecond accuracy. Alternatives: Timestamp types = To support timestamps with an arbitrary or nanosecond resolution, the following types have been considered: * number of nanoseconds * 128-bits float * decimal.Decimal * datetime.datetime * datetime.timedelta * tuple of integers * timespec structure Criteria: * Doing arithmetic on timestamps must be
Re: [Python-Dev] PEP 410, 3rd revision, Decimal timestamp
As asked by Martin, I tried to list *all* objections and alternatives. * A: (numerator, denominator) * value = numerator / denominator * resolution = 1 / denominator * denominator 0 (...) Tuple of integers have been rejected because they don't support arithmetic operations. Oh, after writing the 3rd version of this PEP, I realized that fractions.Fraction is very close to this format except that it can be coerced to float and arithmetic on Fraction and float is allowed (return float). My implementation of the PEP implements something like Fraction in C, but something more specific to timestamps (e.g. without arithmetic). I don't know yet if Fraction is better or worse than Decimal. I see at least one drawback, str(Fraction): 5576475333606653/4194304 is less readable than 1329535325.43341. * Ruby (1.9.3), the `Time class http://ruby-doc.org/core-1.9.3/Time.html`_ supports picosecond (10\ :sup:`-12`) We must do better than Ruby: support arbritrary precision! :-D 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
Re: [Python-Dev] dll name for embedding?
On 17/02/2012 7:44 PM, Egon Smiwa wrote: Hi all, I'm an app developer with a CPython dll in the folder of that app. In general, are there strict requirements about the dll name (a preference would be python.dll (easy to update (simple replace) ). I successfully used python.dll and a few standard modules, then I tried to use the sympy library and its import fails with an AV exception, unless I rename the dll back to the original python32.dll Is there an intrinsic filename requirement inside the CPython dll, modules, or are name-restrictions to be presumed only in case of third-party libs? Note that this is off-topic for python-dev, which is for the development of Python - python-list would be a better choice. But the short story is that given Python extensions have a link-time dependency on the core Python DLL, it isn't possible to rename the DLL without breaking all extensions built against the original name - this is just how link-time dependencies work on Windows. You may also find http://www.python.org/dev/peps/pep-0384 of interest, but this still includes the major version in the DLL name and also depends on the authors of the extensions you want to use opting in. As mentioned above, please followup on python-list. 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] Status of PEP 397 - Python launcher for Windows
I'm wondering what thoughts are on PEP 397, the Python launcher for Windows. I've been using the implementation for a number of months now and I find it incredibly useful. To my mind, the specific steps would be: * Have someone pronounce it as accepted (or suggest steps to be taken before such a pronouncement). I can't recall the current process - does Guido have to pronounce personally or formally delegate to a czar? * Move the source into the Python tree and update the build process. * Arrange for it to be installed with the next release of 3.2 and all future versions - I'm happy to try and help with that, but will probably need some help from Martin. * Write some user-oriented docs. Thoughts or comments? 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
Re: [Python-Dev] Status of PEP 397 - Python launcher for Windows
On Fri, Feb 17, 2012 at 23:24, Mark Hammond skippy.hamm...@gmail.com wrote: I'm wondering what thoughts are on PEP 397, the Python launcher for Windows. I've been using the implementation for a number of months now and I find it incredibly useful. To my mind, the specific steps would be: * Arrange for it to be installed with the next release of 3.2 and all future versions - I'm happy to try and help with that, but will probably need some help from Martin. I've been doing some installer work lately and would be willing to help out if I can. Thoughts or comments? Will you be at PyCon, specifically at the language summit? I proposed a side-track to discuss this PEP, and I say side-track since a great majority of the group are not Windows users, so I don't think it's a topic to bring before the entire group. ___ 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] Status of PEP 397 - Python launcher for Windows
On 18/02/2012 4:37 PM, Brian Curtin wrote: On Fri, Feb 17, 2012 at 23:24, Mark Hammondskippy.hamm...@gmail.com wrote: I'm wondering what thoughts are on PEP 397, the Python launcher for Windows. I've been using the implementation for a number of months now and I find it incredibly useful. To my mind, the specific steps would be: * Arrange for it to be installed with the next release of 3.2 and all future versions - I'm happy to try and help with that, but will probably need some help from Martin. I've been doing some installer work lately and would be willing to help out if I can. Great. Thoughts or comments? Will you be at PyCon, specifically at the language summit? I proposed a side-track to discuss this PEP, and I say side-track since a great majority of the group are not Windows users, so I don't think it's a topic to bring before the entire group. Unfortunately not, but if you can get a few people together to discuss this, I'm happy to wait and see what consensus they arrive at. 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
