Changes by Ezio Melotti ezio.melo...@gmail.com:
--
stage: - test needed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11457
___
___
Larry Hastings la...@hastings.org added the comment:
Mark Dickinson wrote:
I think this could work.
could? Oh ye of little faith!
Attached is a patch against a nice fresh trunk (2b47f0146639) that adds Decimal
attributes ctime, mtime, and atime to the object returned by os.stat().
The
Martin v. Löwis mar...@v.loewis.de added the comment:
As I wrote before, I would prefer to keep the same number of fields
in the Python structure and in the C structure, but I don't have a
strong opinion on this choice.
I'm with Larry - exposing time fields as structured records is
hostile
Mark Dickinson dicki...@gmail.com added the comment:
I propose adding the Decimal fields ctime, atime, and mtime to the
named tuple returned by os.stat().
That would be an interesting precedent: I don't think there are many (any?)
other places outside the 'decimal' module that deal with
Larry Hastings la...@hastings.org added the comment:
Mark Dickinson:
I realize a new float type would be a major undertaking
That's an understatement and a half. The only way this could ever
be viable is if float128 support becomes widespread enough that we
don't have to write our own
STINNER Victor victor.stin...@haypocalc.com added the comment:
As I mentioned earlier in this thread, GCC has supported __float128 since 4.3,
Clang added support within the last year, and Intel has a _Quad type. All are
purported to be IEEE 754-2008 quad-precision floats. Glibc added
Larry Hastings la...@hastings.org added the comment:
Victor STINNER:
Python is compiled using Visual Studio 2008 on Windows. Portability
does matter on Python. If a type is not available on *all* platforms
(including some old platforms, e.g. FreeBSD 6 or Windows XP), we
cannot use it by
Martin v. Löwis mar...@v.loewis.de added the comment:
The quad-precision float would be highly portable
Larry, please stop this discussion in this issue. I believe
a PEP would be needed, and would likely be rejected because
of the very very very long list of issues that can't be
resolved. I
STINNER Victor victor.stin...@haypocalc.com added the comment:
If a two-ints representation
is considered necessary, I'd favor a rational number (numerator,
denominator) over a pair (second, subsecond); this would also support
2**-32 fractions (as used in NTP !!!).
Which OS uses NTP
Mark Dickinson dicki...@gmail.com added the comment:
[about adding float128]
I realize a new float type would be a major undertaking
That's an understatement and a half. The only way this could ever be viable is
if float128 support becomes widespread enough that we don't have to write our
Larry Hastings la...@hastings.org added the comment:
I think a pair of integers is a poor API. It ties the value of the fractional
part to nanoseconds. What happens when a future filesystem implements
picosecond resolution? And then later goes to femtoseconds? Or some platform
chooses
Alexander Belopolsky alexander.belopol...@gmail.com added the comment:
On Fri, Sep 9, 2011 at 4:50 PM, Larry Hastings rep...@bugs.python.org wrote:
..
I think a pair of integers is a poor API. It ties the value of the
fractional part to nanoseconds. What happens
when a future filesystem
Alexander Belopolsky alexander.belopol...@gmail.com added the comment:
On Fri, Sep 9, 2011 at 5:22 PM, Alexander Belopolsky
rep...@bugs.python.org wrote:
..
If history repeats, struct stat will grow new st_xtimesuperspec
fields, st_xtimespec will become a macro expanding to
Larry Hastings la...@hastings.org added the comment:
To support higher resolution
will need to supply 3 fields in st_xtimesuperspec: tv_sec and tv_nsec
packed in st_xtimespec (say tv_timespec) and new tv_psec field.
st_xtime will now be st_xtimesuperspec.tv_timespec.tv_sec and
Martin v. Löwis mar...@v.loewis.de added the comment:
This predates both the inclusion of Decimal in Python (2.4) and
nanosecond resolution in the utime API (2008). I could find no
discussion of the change, so I don't know what other representations
were considered. It's hard to say what
Larry Hastings la...@hastings.org added the comment:
I've drawn an ASCII table summarizing the proposals so far. If I've made any
factual errors I trust you'll let me know.
=type means os.stat().st_mtime is changed to that type.
+type means os.stat() grows a new field using that type,
and
Larry Hastings la...@hastings.org added the comment:
s/pair-of-floats/pair-of-ints/
Also, to be clear: yocto is the smallest defined SI prefix. And what I meant
when I referred to 10**-3 was, float128 could handle 10**-24 but not 10**-27.
According to my back-of-the-envelope calculations,
Alexander Belopolsky alexander.belopol...@gmail.com added the comment:
On Fri, Sep 9, 2011 at 5:42 PM, Larry Hastings rep...@bugs.python.org wrote:
..
How is this superior to using either Decimal or float128?
It is explicit about the units of time used. If we use named tuples
and retain C API
Alexander Belopolsky alexander.belopol...@gmail.com added the comment:
On Fri, Sep 9, 2011 at 6:18 PM, Larry Hastings rep...@bugs.python.org wrote:
..
I've drawn an ASCII table summarizing the proposals so far.
You did not mention closely matches C API as an upside.
--
STINNER Victor victor.stin...@haypocalc.com added the comment:
timespec is just a structure of two integers, so we should expose it as a
simple and efficient Python tuple: (int, int). We can simply expose this type
in os.stat, or we can do better by providing an optional callback to convert
Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com added the comment:
I suggest to have low-level, POSIX-compatible, (int, int)-based interface in os
module and add high-level, decimal.Decimal-based interface in shutil module.
--
___
Python
Larry Hastings la...@hastings.org added the comment:
Here's a better idea: we add a new IEEE 754-2008 quad-precision float type.
The IEEE 754-2008 quad precision float has 1 sign bit, 15 bits of exponent, and
112 bits of mantissa, so it should have enough precision to last utime until
Changes by Stefan Krah stefan-use...@bytereef.org:
--
nosy: +skrah
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11457
___
___
Python-bugs-list
Larry Hastings la...@hastings.org added the comment:
This is probably a terrible idea, but: what about using a subclass of float
that internally preserves the original sec / usec values? Call it a
utime_float for now. os.stat would produce them, and os.utime would look for
them--and if it
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
On Sun, Jun 26, 2011 at 8:23 AM, Martin v. Löwis rep...@bugs.python.org wrote:
..
I understand that it is an issue of the datetime module. Can it be
solved, or is there a design issue in the module?
It's an inherent
Martin v. Löwis mar...@v.loewis.de added the comment:
any broken-down time has issues of time stamp ordering in the
duplicate hour of switching from DST to normal time
I understand that it is an issue of the datetime module. Can it be
solved, or is there a design issue in the module?
It's
STINNER Victor victor.stin...@haypocalc.com added the comment:
I suggest that rather than using composite time stamps,
decimal.Decimal is used to represent high-precision time in Python.
Hey, why nobody proposed datetime.datetime objects? Can't we improve the
datetime precision to support
Martin v. Löwis mar...@v.loewis.de added the comment:
Hey, why nobody proposed datetime.datetime objects?
datetime.datetime is extremely bad at representing time stamps.
Don't use broken-down time if you can avoid it.
By the way, Windows does also use timestamps with a nanosecond
STINNER Victor victor.stin...@haypocalc.com added the comment:
datetime.datetime is extremely bad at representing time stamps.
Don't use broken-down time if you can avoid it.
I didn't know that datetime is extremely bad at representing time stamps,
could you explain please?
--
Martin v. Löwis mar...@v.loewis.de added the comment:
I didn't know that datetime is extremely bad at representing time
stamps, could you explain please?
- there is no easy way to convert it into seconds since the epoch
- any broken-down time has issues of time stamp ordering in the
STINNER Victor victor.stin...@haypocalc.com added the comment:
there is no easy way to convert it into seconds since the epoch
Ah yes, it remembers me that Alexander rejected my .totimestamp() patch (#2736)
because he considers that Converting datetime values to float is easy:
(dt -
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
On Fri, Jun 3, 2011 at 6:52 PM, Martin v. Löwis rep...@bugs.python.org wrote:
..
One reason is the desire to avoid loading Python module from a
C-module.
This desire is indeed no guidance for Python development; the
Martin v. Löwis mar...@v.loewis.de added the comment:
Can you elaborate on this?
Not on the tracker; this is appropriate on python-dev.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11457
R. David Murray rdmur...@bitdance.com added the comment:
The mailbox module would benefit from having this precision available.
--
nosy: +r.david.murray
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11457
Martin v. Löwis mar...@v.loewis.de added the comment:
I suggest that rather than using composite time stamps, decimal.Decimal is used
to represent high-precision time in Python.
On input to os.utime, the function could just polymorphically accept Decimal,
and try its best.
I see three
Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com added the comment:
os.utimensat() and os.futimens() already exist since Python 3.3 and require
2-tuples (or None) as second and third argument.
(utime() is deprecated since POSIX 2008:
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
On Fri, Jun 3, 2011 at 3:57 PM, Martin v. Löwis rep...@bugs.python.org wrote:
..
I suggest that rather than using composite time stamps, decimal.Decimal is
used to represent high-precision time in Python.
I support this
Martin v. Löwis mar...@v.loewis.de added the comment:
Am 03.06.2011 22:11, schrieb Arfrever Frehtes Taifersar Arahesis:
Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com added the
comment:
os.utimensat() and os.futimens() already exist since Python 3.3 and require
2-tuples (or
Martin v. Löwis mar...@v.loewis.de added the comment:
I support this idea in theory, but as long as decimal is implemented
in Python, os module should probably expose a low level (tuple-based?)
interface and a higher level module would provide Decimal-based
high-precision time.
Can you
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
On Fri, Jun 3, 2011 at 6:13 PM, Martin v. Löwis rep...@bugs.python.org wrote:
..
I support this idea in theory, but as long as decimal is implemented
in Python, os module should probably expose a low level (tuple-based?)
Martin v. Löwis mar...@v.loewis.de added the comment:
One reason is the desire to avoid loading Python module from a
C-module.
This desire is indeed no guidance for Python development; the opposite
is the case. The only exception may be bootstrapping issues, which I
claim are irrelevant in
Changes by Jesús Cea Avión j...@jcea.es:
--
nosy: +jcea
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11457
___
___
Python-bugs-list mailing list
Changes by Ross Lagerwall rosslagerw...@gmail.com:
--
dependencies: +Support st_atim, st_mtim and st_ctim attributes in os.stat_result
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11457
___
Ross Lagerwall rosslagerw...@gmail.com added the comment:
Closed #11941 as a duplicate of this.
--
nosy: +rosslagerwall
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11457
___
Changes by Alexander Belopolsky belopol...@users.sourceforge.net:
--
nosy: +belopolsky
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11457
___
___
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
See also issue10812 which implements os.futimens().
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11457
___
Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com:
--
nosy: +Arfrever
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11457
___
Changes by Nadeem Vawda nadeem.va...@gmail.com:
--
nosy: +nvawda
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11457
___
___
Python-bugs-list
New submission from Kris Henriksson kthenriks...@gmail.com:
The most recent (issue 7) release of the POSIX standard mandates support for
nanosecond precision in certain system calls. For example, the stat structure
include a timespec struct for each of mtime, atime, and ctime that provides
Kris Henriksson kthenriks...@gmail.com added the comment:
Also, a new function similar to os.utime would be needed as well, perhaps
something named like os.utimens. This would be needed to allow setting times
with nanosecond precision.
--
___
Changes by Antoine Pitrou pit...@free.fr:
--
nosy: +mark.dickinson
versions: +Python 3.3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11457
___
Changes by Lars Gustäbel l...@gustaebel.de:
--
nosy: +lars.gustaebel
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11457
___
___
Python-bugs-list
52 matches
Mail list logo
