Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
On Fri, Apr 11, 2008 at 12:06 PM, Brad Miller <[EMAIL PROTECTED]> wrote:
> Our use of range in the first few classes is exactly for iteration
> purposes, but I do not like students to have to have too many mysteri
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
As you are working on this, please consider changing
self.hide+self.ignore in phase0 to chain(self.hide, self.ignore) where
chain should be imported from itertools. There is no need to create the
combined list (twice!) and not acc
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
On Fri, Apr 11, 2008 at 2:45 PM, Brad Miller <[EMAIL PROTECTED]> wrote:
..
> My question is how does this get resolved. When I posted this idea to
> python-dev Guido suggested an approach. Nobody else expressed an o
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
Note that in r61458 Neal replaced PyMem_RESIZE with a direct call to
PyMem_REALLOC thus eliminating integer overflow check even from the debug
builds.
--
nosy: +belopolsky, nnorwitz
__
T
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
Justin,
Where did you find the definition that you cited:
95 #define PyMem_RESIZE(p, type, n) \
96 ( assert((n) <= PY_SIZE_MAX / sizeof(type)) , \
97 ( (p) = (type *) PyMem_REALLOC((p), (n) * sizeof(type)) ) )
?
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
The following simple change should be enough for this issue, but I would
consider implementing the overflow check in the PyMem_RESIZE and PyMem_NEW
macros and de-deprecate the
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
On Sun, Apr 13, 2008 at 11:12 PM, Gregory P. Smith
<[EMAIL PROTECTED]> wrote:
..
> Here's a patch that fixes this by making both Python's malloc and
> realloc return NULL if (0 <= size <= PY_SSIZE
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
The patch does not add unit tests for hash(range(..)). I would actually
test that hash(range(a,b,c)) == hash((a,b,c)) for various values of a,
b, and c.
A nit-pick: while I personally like the coding style with line breaks
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
On Tue, Apr 15, 2008 at 10:21 PM, Benjamin Peterson
<[EMAIL PROTECTED]> wrote:
> I'm not really sure what to do about the hash. I
> just removed the Py_SIZE parts. I hope that's OK.
If you want to maintai
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
With range_eq5.patch applied on an x86-64 Linux box:
$ ./python
Python 3.0a4+ (py3k:62359M, Apr 16 2008, 13:36:31)
[GCC 3.4.6 20060404 (Red Hat 3.4.6-3)] on linux2
Type "help", "copyright", "credits&quo
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
range_eq5.patch fails to reproduce tuple hash because in the tuple hash
implementation the len variable varies between iterations over items. I
would just use literals for the three different values of mult rather
than copyin
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
On Wed, Apr 16, 2008 at 3:40 PM, Antoine Pitrou <[EMAIL PROTECTED]> wrote:
..
> Why would you want to have hash(range(a,b,c)) == hash((a,b,c)) ?
No particular reason other than that this is easy to test and gives
some
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
On Wed, Apr 16, 2008 at 9:24 PM, Benjamin Peterson wrote:
..
> Why not just hash a tuple?
There are a few reasons, but neither is good enough to have another
round of code review :-)
1. It is strange to have the hash function
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
I would say this is a good idea for 2.6.
Note that C functions are more forgiving:
>>> from datetime import *
>>> date(1,2,**{u'day':10})
datetime.date(1, 2, 10)
>>> dict(**{u'x':1
Changes by Alexander Belopolsky <[EMAIL PROTECTED]>:
Added file: http://bugs.python.org/file10045/issue2646.diff
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
On the interface, I would suggest renaming 'exclude' to 'ignore' for
consistency with filecmp.dircmp. Also consider detecting file separator
in the patterns and interpreting them as an absolute (if
patte
New submission from Alexander Belopolsky <[EMAIL PROTECTED]>:
Current Doc/library/functions.rst says "The use of apply() is exactly
equivalent to function(*args, **keywords)." which is no longer correct
because f(*args, **keywords) notation allows use of an arbitrary mapping
as
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
This has nothing to do with set.update, the difference is due to the
time to setup the generator:
$ python -m timeit -s 'x = set(range(1)); y = []' 'x.update(y)'
100 loops, best of 3: 0.38 usec per loo
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
On Thu, Apr 24, 2008 at 2:23 PM, John Arbash Meinel
<[EMAIL PROTECTED]> wrote:
..
> So if you compare consuming a generator multiple times to creating it
> each time, it is 0.662 usec - 0.173 usec = 0.489 usec to
Changes by Alexander Belopolsky <[EMAIL PROTECTED]>:
--
components: Interpreter Core
files: range.diff
keywords: patch
nosy: belopolsky
severity: normal
status: open
title: Fix indentation in range_item
versions: Python 3.0
Added file: http://bugs.python.org/file10104/rang
New submission from Alexander Belopolsky <[EMAIL PROTECTED]>:
Attached patch makes range objects precompute their length on creation.
This speeds up indexing and len at the expense of a small increase in
range object size. The main benefit, however is that unsupported length >
sy
New submission from Alexander Belopolsky <[EMAIL PROTECTED]>:
Attached patch adds documentation for the new in 2.5 APIs:
PyObject* PyLong_FromSsize_t(Py_ssize_t v)
PyObject* PyLong_FromSize_t(size_t v)
and
Py_ssize_t PyLong_AsSsize_t(PyObject *pylong)
--
assignee: georg.
Changes by Alexander Belopolsky <[EMAIL PROTECTED]>:
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2691>
__
___
Python-bugs-list mailing list
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
-
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2691>
__
___
Python-bugs-list mailing list
Changes by Alexander Belopolsky <[EMAIL PROTECTED]>:
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2691>
__
___
Python-bugs-list mailing list
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
Web submission did not work. Trying sending the patch as an e-mail attachment.
--
keywords: +patch
Added file: http://bugs.python.org/file10108/doc-long.diff
__
Tracker <[EMAIL
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
For some reason the tracker web interface fails to upload the patch.
Trying again with this message, if it fails again, will resubmit by e-
mail.
__
Tracker <[EMAIL PROTECTED]>
<http://
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
On Fri, Apr 25, 2008 at 12:55 PM, Mark Dickinson <[EMAIL PROTECTED]> wrote:
..
> I don't much like this aspect of the change: there are uses for
>
> for i in range(ridiculously_large_number):
For this app
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
Option (3) would require changing both sq_item and sq_length signatures,
which is likely to have a large negative impact on performance.
Option (2) would either require a change for the sq_length signature, or
leave the prob
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
On Fri, Apr 25, 2008 at 4:37 PM, Mark Dickinson <[EMAIL PROTECTED]> wrote:
..
> for i in range(1, p):
> if (i_is_a_nonresidue_modulo_p):
> break
>
> Here p might be a 200-digit prime number, and
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
On Fri, Apr 25, 2008 at 4:37 PM, Benjamin Peterson
<[EMAIL PROTECTED]> wrote:
>
> I don't really see what's wrong with the indentation.
Sorry, I thought it would be obvious from the patch. As of revision
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
On Fri, Apr 25, 2008 at 5:31 PM, Benjamin Peterson
<[EMAIL PROTECTED]> wrote:
> Comments?
In the range_hash function, len, start, step locals should be declared
Py_ssize_t, not long. Also, you can use range_leng
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
It looks like e-mail processor eats '>>>' examples. My examples were
>>> range(2**100) == range(2**100+1)
Traceback (most recent call last):
File "", line 1, in
OverflowError: Pytho
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
On Fri, Apr 25, 2008 at 5:57 PM, Amaury Forgeot d'Arc
<[EMAIL PROTECTED]> wrote:
..
> - Did you change your mind about range equality?
> range(0,10,2) == range(0,9,2)
> seems True now; it was not with ran
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
On Fri, Apr 25, 2008 at 7:10 PM, Guido van Rossum
<[EMAIL PROTECTED]> wrote:
..
> I think I'd be okay with normalization on creation, so that range(0,
> 5, 2) returns range(0, 6, 2). Hm, but isn't that o
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
With respect to range_eq8_normalize2.patch, it is unusual to have a
function that consumes a reference to its argument. I would combine
normalize_stop with PyNumber_Index and make it similar to validate_step
with resp
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
... and your patch produces wrong results:
>>> list(range(5,0,-2)) # expected [5, 3, 1]
[5, 3]
See my patch in issue2690 for a way to compute length correctly in
range_new.
__
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
The patch looks good. Just a question: I thought the strings returned by
PyUnicode_AsStringAndSize are 0-terminated, while your patch at several
places attempts to explicitly 0-terminate a copy of such string. Are you
sure t
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
I've implemented range slicing and x in range(..) in range-sequence.diff
and registered range with the Sequence ABC.
Added file: http://bugs.python.org/file10131/range-sequence.diff
__
Trac
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
Reviewing my own patch (range-sequence.diff), I've realized that it is
being a bit too clever in handling x in range(..) where x is not an
integer. It seems that upon a failed PyLong_Check, range_contains should
just
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
> For me, range() should mimic a number generator: no limit, no length.
That's itertools.count()
__
Tracker <[EMAIL PROTECTED]>
<http://bu
New submission from Alexander Belopolsky <[EMAIL PROTECTED]>:
On Tue, Apr 29, 2008 at 10:36 PM, Guido van Rossum <[EMAIL PROTECTED]>
wrote:
..
> Let's also fix __len__() so that it returns sys.{maxint,maxsize} when
> the result doesn't fit in a Py_ssize_t.
http
Changes by Alexander Belopolsky <[EMAIL PROTECTED]>:
--
type: -> feature request
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2723>
__
___
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
On Wed, Apr 30, 2008 at 2:32 AM, Raymond Hettinger
<[EMAIL PROTECTED]> wrote:
> Wouldn't it be better to raise OverflowError or somesuch?
Thats what the current code does. I don't know what Guido's full
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
I thought new code is supposed to use Py_TYPE macro instead of ->ob_type:
+ "%.200s object is not an iterator", it->ob_type-
>tp_name);
..
+ res = (*it->ob_type->tp_iternext)
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
One more question: What is the rationale for
+ res = (*it->ob_type->tp_iternext)(it);
+ if (res == NULL) {
..
+ PyErr_SetNone(PyExc_StopIteration);
+ return NULL;
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
On Wed, Apr 30, 2008 at 12:41 PM, Guido van Rossum
<[EMAIL PROTECTED]> wrote:
>
> Guido van Rossum <[EMAIL PROTECTED]> added the comment:
>
> > .. builtin_next() should return
> > NULL with
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
On Wed, Apr 30, 2008 at 12:41 PM, Guido van Rossum
<[EMAIL PROTECTED]> wrote:
> the iternext slot is designed to return NULL without setting an
> exception.
This is not what the documentation says:
New submission from Alexander Belopolsky <[EMAIL PROTECTED]>:
See discussion in issue2719 for details.
--
assignee: georg.brandl
components: Documentation
files: doc-typeobj.diff
keywords: patch
messages: 66016
nosy: belopolsky, georg.brandl
severity: normal
status: open
title: c
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
The start/step/stop getter functions should INCREF return values. Is
there a reason not to adapt slice implementation:
static PyMemberDef slice_members[] = {
{"start", T_OBJECT, offsetof(PySliceObject,
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
- With length precomputed in range_new, we can probably get rid of
get_len_of_range.
- There is no need to recompute length in range_iter.
A nit: iterator object's size member is called "len", but the same
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
One more nit: you don't need to zero out trailing range_as_sequence
members explicitly.
static PySequenceMethods range_as_sequence = {
(lenfunc)range_length, /* sq_length */
};
shoul
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
Lorenz's patch uses a set, not a list for special characters. Set
lookup is as fast as dict lookup, but a set takes less memory because it
does not have to store dummy values. More importantly, use of frozenset
inst
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
On Thu, May 8, 2008 at 10:36 AM, Russ Cox <[EMAIL PROTECTED]> wrote:
..
> The title of this issue (#2650) is "re.escape should not escape underscore",
> not "re.escape is too slow and too easy to rea
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
On Thu, May 8, 2008 at 11:45 AM, Russ Cox <[EMAIL PROTECTED]> wrote:
..
> My argument is only that Python should behave the same in
> this respect as other systems that use substantially the same
> regular expres
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
This is similar to issue2516.
--
nosy: +belopolsky
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
Attached patch makes a >> b return 0 for b > maxsize.
--
keywords: +patch
nosy: +belopolsky
Added file: http://bugs.python.org/file10234/issue2804.diff
__
Tracker <[EMAIL
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
On the second thought, it is theoretically possible to have a long int a
for which a >> maxsize is not zero because that would require only
maxsize/15 digits. I am not sure it is worth the trouble to acco
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
On Fri, May 9, 2008 at 7:08 PM, Martin v. Löwis <[EMAIL PROTECTED]> wrote:
..
> I'm -1 on this patch (or any other fixing the perceived problem).
> Special cases aren't special enough to break the rules.
&g
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
On Sun, May 11, 2008 at 6:38 PM, Gregory P. Smith
<[EMAIL PROTECTED]> wrote:
..
> But I must've missed something, why can't __len__ return the correct
> value?
The problem is the C signature of the sq_leng
New submission from Alexander Belopolsky <[EMAIL PROTECTED]>:
With attached teestmodule.zip and svn revision 67006,
$ ./python.exe testmodule.zip
Traceback (most recent call last):
File "/Users/sasha/Work/python-svn/trunk/Lib/runpy.py", line 121, in
_run_module_as_main
&
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
Attached patch addresses the crash, but two issues remain:
$ ./python.exe testmodule.zip
**
File "__main__", line ?, in __main__.c
Failed exam
Changes by Alexander Belopolsky <[EMAIL PROTECTED]>:
--
keywords: +patch
Added file: http://bugs.python.org/file11878/doctest.patch
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
The next patch, doctest-1.patch addresses the line number issue, but the
file name is still wrong.
$ ./python.exe testmodule.zip
**
File "__main__&q
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
I don't think there is an easy way to fix source file name reporting
without injecting __file__ = '/' into the
module namespace is zipimporter, but I don't know if any code relies on
__file__ set to None.
S
New submission from Alexander Belopolsky <[EMAIL PROTECTED]>:
With attached test.zip and svn revision 67006,
$ ./python.exe test.zip
> /Users/sasha/Work/python-svn/trunk/test.zip/__main__.py(2)f()
(Pdb) l
[EOF]
With pdb.patch:
$ ./python.exe test.zip
> /Users/sasha/Work/pyth
Changes by Alexander Belopolsky <[EMAIL PROTECTED]>:
--
keywords: +patch
Added file: http://bugs.python.org/file11883/pdb.patch
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Changes by Alexander Belopolsky <[EMAIL PROTECTED]>:
--
components: +Library (Lib)
type: -> behavior
versions: +Python 2.5.3
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
Changes by Alexander Belopolsky <[EMAIL PROTECTED]>:
--
versions: +Python 2.5.3, Python 2.6
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
This must be very similar to #4197 and #4201 that I reported a few days
ago. I'll see if a similar patch would work in this case.
--
nosy: +belopolsky
___
Python tracker <[E
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
Hmm, apparently inspect was made to work with zipped modules back in r45248 .
I cannot reproduce the problem either.
Jean-Paul, can you attach your foobar.zip? What else do you have in your
/tmp dir
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
Thanks, Jean-Paul, I can now reproduce your problem and I think I found
the culprit.
I believe the file name check in linecache.updatecache is unnecessary
and is responsible for this problem. With the following patch:
-
Changes by Alexander Belopolsky <[EMAIL PROTECTED]>:
--
nosy: +belopolsky
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue4216>
___
_
Changes by Alexander Belopolsky <[EMAIL PROTECTED]>:
--
nosy: +belopolsky
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue4220>
___
_
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
Mark,
I noticed that you replaced a call to _PyLong_AsScaledDouble with your
round to nearest algorithm. I wonder if _PyLong_AsScaledDouble itself
would benefit from your change. Currently it is used in PyLong_AsDoubl
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
I am not sure whether it is appropriate to comment on a closed issue,
but if the tracker will take this comment, hopefully it will find the
right audience.
I have recently stumbled on this bug running python 2.5. While trackin
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
amaury> What if PyGC_Collect() is called just before?
That would work. With the following patch:
===
--- Python/import.c (revision 67183)
+++ Python
Changes by Alexander Belopolsky <[EMAIL PROTECTED]>:
--
versions: +Python 2.5.3, Python 2.6, Python 2.7
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.o
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
Chris> I keep needing to know the number of seconds that a timedelta
Chris> represents.
I propose an alternative approach that I believe will neatly solve
fractional vs. whole seconds and multitude of conceivable toxxx met
Changes by Alexander Belopolsky <[EMAIL PROTECTED]>:
--
nosy: +belopolsky
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue4111>
___
_
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
The patch no longer applies to trunk, but that would be trivial to fix.
Changes like these have been accepted with little resistance in the past
(see e.g. issue651362), so I don't see why this patch has been pending
f
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
The new patch looks fine to me. It applies and compiles without
warnings and the changes are now reflected in the docs. I guess
someone would need to write a NEWS entry because it is a public API
change, but otherwise I would
Changes by Alexander Belopolsky <[EMAIL PROTECTED]>:
--
nosy: +jhylton
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1699259>
___
_
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
While technically this is an API change, in reality it is unlikely to
break anyone's code because you can always pass char * to a function
that expects const char* and the ABI does not change. (Also I cannot
think why a
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
I was going to say the same as Amaury: timedelta / timedelta is
dimensionless (time units cancel each other in division) and the
advantage of this notation is that you get a way to express
timedelta.toxxx for all units accep
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
I attaching webograph's patch updated to revision 67223 where I added a
few tests.
I am +1 on the floor divide changes (allowing timedelta // timedelta),
but I am not sure how true division should work if at all. For t
Changes by Alexander Belopolsky <[EMAIL PROTECTED]>:
--
nosy: +amaury.forgeotdarc, jribbens
versions: +Python 2.7, Python 3.1
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
On Fri, Nov 14, 2008 at 12:51 PM, STINNER Victor <[EMAIL PROTECTED]> wrote:
>
> STINNER Victor <[EMAIL PROTECTED]> added the comment:
>
> Why not also implementing divmod()? It's useful to split a ti
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
Also, why not
>>> divmod(timedelta(3), 2)
(datetime.timedelta(1), datetime.timedelta(1))
?
And where do we stop? :-)
On Fri, Nov 14, 2008 at 1:02 PM, Alexander Belopolsky
<[EMAIL PROTECTED]> wrote:
> On Fri,
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
While I agree that divmod may be useful, your particular use case is
not convincing. The same can be done easier without divmod:
def formatTimedelta(delta):
return "{0}h {1}min {2}sec".format(*str(delta).split(&
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
On Fri, Nov 14, 2008 at 1:28 PM, STINNER Victor <[EMAIL PROTECTED]> wrote:
..
> What do you think about:
> timedelta / # only with __future__.divison
> timedelta //
> timedelta %
> divmod(timedelta, )
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
Oops, the tracker ate some lines from e-mail. Reposting through the
web:
On Fri, Nov 14, 2008 at 1:28 PM, STINNER Victor <[EMAIL PROTECTED]>
wrote:
..
> What do you think about:
> timedelta / # only with
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
haypo> How? I don't understand your suggestion.
Sorry, another case of mail to tracker bug. Here is what I wrote:
"""
.. you can convert delta to time using an arbitrary anchor date and
extract hms that
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
I would like to voice my opposition the totimestamp method.
Representing time as a float is a really bad idea (originated at
Microsoft as I have heard). In addition to the usual numeric problems
when dealing with the floating
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
On Fri, Nov 14, 2008 at 8:37 PM, STINNER Victor <[EMAIL PROTECTED]> wrote:
> .. but we can create new methods like:
> datetime.fromepoch(seconds, microseconds=0)# (int/long, int)
While 1970 is the most popula
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
On Sat, Nov 15, 2008 at 5:08 AM, Mark Dickinson <[EMAIL PROTECTED]> wrote:
>
> Mark Dickinson <[EMAIL PROTECTED]> added the comment:
>
>> timedelta / should be disallowed in true division mode.
>
&g
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
@Christian
Adding a __float__ method to datetime was entertained back in 2003, but
was rejected. The same reasons apply to timedelta:
"""
- A C double doesn't have enough precision for roundtrip guarantees.
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
On Mon, Nov 24, 2008 at 9:04 AM, David Fraser <[EMAIL PROTECTED]> wrote:
...
> The point for me is that having to interact with Microsoft systems that
> require times means that the conversions have to be done.
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
That's an impressive summary, but what is your conclusion? I don't
see any format that will benefit from a subsecond
timedelta.totimestamp(). Your examples have either multisecond or
submicrosecond resolution.
On Mon,
Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
On Mon, Nov 24, 2008 at 12:13 PM, STINNER Victor <[EMAIL PROTECTED]> wrote:
..
> Hum, it's maybe not possible to choose between integer and float. Why
> not supporting both? Example:
> - totimestamp()-&
1501 - 1600 of 4095 matches
Mail list logo
