Alexander Belopolsky added the comment:
Any objections to closing this as "won't fix"?
--
nosy: +belopolsky -Alexander.Belopolsky
___
Python tracker
<http://bugs.py
Changes by Alexander Belopolsky :
--
assignee: -> belopolsky
nosy: +belopolsky -Alexander.Belopolsky
___
Python tracker
<http://bugs.python.org/iss
Changes by Alexander Belopolsky :
--
assignee: -> belopolsky
nosy: +belopolsky
___
Python tracker
<http://bugs.python.org/issue5476>
___
___
Python-bugs-lis
Changes by Alexander Belopolsky :
--
assignee: -> belopolsky
nosy: +belopolsky
___
Python tracker
<http://bugs.python.org/issue1647654>
___
___
Python-bugs-lis
Changes by Alexander Belopolsky :
--
stage: -> patch review
type: -> feature request
versions: +Python 3.2 -Python 2.7, Python 3.1
___
Python tracker
<http://bugs.python.org/iss
Changes by Alexander Belopolsky :
--
nosy: +belopolsky
___
Python tracker
<http://bugs.python.org/issue1667546>
___
___
Python-bugs-list mailing list
Unsubscribe:
Alexander Belopolsky added the comment:
> Could you provide some reasoning for such a resolution?
> I had thought that "won't fix" indicated that the issue
> wasn't actually an error in behavior.
No, that would be "invalid." IMO, "won't fix
Changes by Alexander Belopolsky :
--
resolution: -> out of date
status: open -> pending
___
Python tracker
<http://bugs.python.org/issue8005>
___
___
Pyth
Alexander Belopolsky added the comment:
I've untabified my last patch and added a NEWS entry. I believe it is ready
for commit review. Mark?
--
nosy: +mark.dickinson
stage: patch review -> commit review
Added file: http://bugs.python.org/file17466/issue71
Alexander Belopolsky added the comment:
I have untabified James' patch, ran the tests on the result, but did not
otherwise review it.
There is a not-so-easy-to-find thread on python-dev discussing this issue under
subject "Python 2.6.5".
Here is a relevant quote from
Changes by Alexander Belopolsky :
Added file: http://bugs.python.org/file17468/issue6608.diff
___
Python tracker
<http://bugs.python.org/issue6608>
___
___
Python-bug
Alexander Belopolsky added the comment:
The patch as written causes buffer overflow for year >= 10,000:
>>> len(time.asctime( (1, 1, 1, 0, 0, 0, 0, 1, -1)))
26
>>> len(time.asctime( (10, 1, 1, 0, 0, 0, 0, 1, -1)))
27
while the buffer is only 26 characters:
+
Changes by Alexander Belopolsky :
--
assignee: -> belopolsky
stage: -> commit review
___
Python tracker
<http://bugs.python.org/issue7879>
___
___
Pyth
Alexander Belopolsky added the comment:
Mark,
I have zero experience with Windows and don't even have a win32 machine to test
the patch.
On the other hand the patch is so simple that I think it can be reviewed based
on theoretical considerations.
This is probably bikesheding, but I h
Alexander Belopolsky added the comment:
OK, I'll commit it then.
--
resolution: -> accepted
___
Python tracker
<http://bugs.python.org/issue7879>
___
_
Alexander Belopolsky added the comment:
Committed in r81555 (trunk) and r81556 (py3k). Is this a 2.6 backport
candidate? I don't think so.
Leaving this open to consider using newer unittest.skipIf mechanism. See
attached patch, issue7879.diff.
--
Added file:
Alexander Belopolsky added the comment:
>From IRC:
Taggnostr: imho tests and doc updates can be backported
--
keywords: +26backport
___
Python tracker
<http://bugs.python.org/iss
Changes by Alexander Belopolsky :
--
versions: +Python 2.6, Python 3.1, Python 3.2
___
Python tracker
<http://bugs.python.org/issue7879>
___
___
Python-bugs-list m
Alexander Belopolsky added the comment:
SkipIf patch committed in r81559 (trunk) and r81560 (py3k).
--
___
Python tracker
<http://bugs.python.org/issue7
Alexander Belopolsky added the comment:
> 'naive' and 'aware' are key datetime types - they need a proper
> definition and anchor for crossrefences.
The definition is given in the introductory section:
"""
There are two kinds of date and time object
New submission from Alexander Belopolsky :
This is a semi-serious feature request following a brief discussion on
#python-dev IRC.
Brett Cannon pointed out on python-checkins list [1] that the names should be
alphabetized. However, given that the names are international, it is not
obvious
Changes by Alexander Belopolsky :
--
keywords: +patch
stage: -> patch review
Added file: http://bugs.python.org/file17475/issue8834.diff
___
Python tracker
<http://bugs.python.org/iss
Alexander Belopolsky added the comment:
Committed in r81566 (trunk), r81568 (py3k), r81569 (release26-maint), r81570
(release31-maint).
--
stage: commit review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.p
Changes by Alexander Belopolsky :
--
stage: -> commit review
Added file: http://bugs.python.org/file17476/issue1289118-withdoc.diff
___
Python tracker
<http://bugs.python.org/issue1
Changes by Alexander Belopolsky :
--
nosy: +belopolsky
___
Python tracker
<http://bugs.python.org/issue2394>
___
___
Python-bugs-list mailing list
Unsubscribe:
Alexander Belopolsky added the comment:
I don't run Windows either but I believe sizeof(char) == 1 is guaranteed by the
C standard, so the first report (Python/dynload_win.c) is invalid.
The last two appear to be valid [1], and a common mistake. [2] Unit tests are
needed for these. I
Alexander Belopolsky added the comment:
Strike my comment about Python/dynload_win.c - I was looking at the trunk
version instead of py3k. In py3k theInfo is wchar_t and patch seems to be
valid.
--
___
Python tracker
<http://bugs.python.
Changes by Alexander Belopolsky :
--
assignee: -> belopolsky
nosy: +belopolsky
___
Python tracker
<http://bugs.python.org/issue2651>
___
___
Python-bugs-lis
Changes by Alexander Belopolsky :
--
versions: +Python 3.2 -Python 2.5
___
Python tracker
<http://bugs.python.org/issue2651>
___
___
Python-bugs-list mailin
Changes by Alexander Belopolsky :
--
assignee: -> belopolsky
nosy: +belopolsky
___
Python tracker
<http://bugs.python.org/issue2920>
___
___
Python-bugs-lis
Alexander Belopolsky added the comment:
Is there still any interest in pursuing this? Raymond?
--
___
Python tracker
<http://bugs.python.org/issue762
Changes by Alexander Belopolsky :
--
assignee: -> belopolsky
nosy: +belopolsky
___
Python tracker
<http://bugs.python.org/issue3196>
___
___
Python-bugs-lis
Alexander Belopolsky added the comment:
The patch already checks for failed import and falls back to printing
numerical error code. However, I don't like the import either. I will
think about the alternatives.
On May 28, 2010, at 8:27 AM, Antoine Pitrou
wrote:
>
> Antoine Pi
Alexander Belopolsky added the comment:
- 26backport committed in r81618.
- merged to release31-maint in r81619.
The skipIf patch blocked from release26-maint (skipIf is new in 2.7) and merged
into release31-maint in r81620.
--
stage: commit review -> committed/rejected
status: o
New submission from Alexander Belopolsky :
>From issue1289118, msg106389:
"""
>>> from datetime import timedelta as d
>>> [d(microseconds=i + .5)//d.resolution for i in range(-10,10)]
[-10, -9, -8, -7, -6, -5, -4, -3, -2, -1, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
S
Alexander Belopolsky added the comment:
Committed in r81625. Fixed white space and added a note to "new in 3.2"
section of the RST doc.
--
resolution: -> accepted
stage: commit review -> committed/rejected
status: open -> closed
___
Alexander Belopolsky added the comment:
Here is a shorter example of inconsistent behavior:
>>> 0.5 * timedelta(microseconds=1)
datetime.timedelta(0)
>>> timedelta(microseconds=0.5)
datetime.timedelta(0, 0, 1)
--
___
Pyt
Alexander Belopolsky added the comment:
Does this need to be brought up on python-dev for acceptance?
--
nosy: +mark.dickinson
stage: unit test needed -> patch review
versions: +Python 3.2 -Python 2.7
___
Python tracker
<http://bugs.pyth
Changes by Alexander Belopolsky :
--
stage: -> unit test needed
___
Python tracker
<http://bugs.python.org/issue5023>
___
___
Python-bugs-list mailing list
Un
Alexander Belopolsky added the comment:
Philipp,
Why do you think you see the same problem as Eric?
Can you set a trace on &tuple and see when it gets modified?
Do you see the crash with zone_failure.py, test_datetime.py or both?
--
___
Py
Alexander Belopolsky added the comment:
Mark> (2) seems like overkill to me.
I agree, however it would be interesting to figure out when accumulated errors
can produce an inaccurate result. ISTM that leftover is the sum of up to 7
doubles each between 0 and 1 which is then rounded to
Alexander Belopolsky added the comment:
I wonder if it would be justified to expose something like
int
_PyLong_IsOdd(PyObject *self)
{
PyLongObject *lo = (PyLongObject *)self;
return Py_SIZE(lo) != 0 && ((lo->ob_digit[0] & 1) != 0);
}
Alexander Belopolsky added the comment:
On Wed, Jun 2, 2010 at 11:17 AM, Tal Einat wrote:
..
> If so, I can have the patch ready by Friday 14:00 GMT, but if nobody will
> have time to review
> (and possibly commit) in time for RC1 I guess I'll take my time with this.
I'l
Changes by Alexander Belopolsky :
--
assignee: -> belopolsky
___
Python tracker
<http://bugs.python.org/issue1766304>
___
___
Python-bugs-list mailing list
Un
Alexander Belopolsky added the comment:
This is already in 3.x. The only reason I can think of to get this in
2.7 is to have fewer performance surprises between 2.x and 3.x.
--
___
Python tracker
<http://bugs.python.org/issue1766
Alexander Belopolsky added the comment:
Rejecting this for stdlib. A 3rd party package is available at
http://pypi.python.org/pypi?name=MonthDelta&:action=display .
--
stage: -> committed/rejected
status: pending -> closed
___
Pyth
Alexander Belopolsky added the comment:
Here is my first attempt to implement fixed offset timezone type. The patch is
based on Brett's next-patch.txt and while I changed the type name from
datetime.UTC to datetime.timezone, I did not change the name of the related C
structures. I
Alexander Belopolsky added the comment:
On Wed, Jun 2, 2010 at 5:24 PM, Brett Cannon wrote:
..
> 1. Call it FixedTimezone or something (remember it has to be CapWords).
I thought consistency within module trumps PEP 8 naming standards.
The datetime module (for better or worse) uses lowerc
Alexander Belopolsky added the comment:
I am reopening this issue because the following note is still not entirely
correct:
"""
The range really is 0 to 61; according to the Posix standard this accounts for
leap seconds and the (very rare) double leap seconds. The time modu
Alexander Belopolsky added the comment:
Here is a quote from the relevant CERT advisory (MSC33-C):
"""
This function is supposed to output a character string of 26 positions at most,
including the terminating zero. If we count the length indicated by the format
directives
Alexander Belopolsky added the comment:
I am attaching the next installment of the datetime.timezone class
implementation.
Here I add ``utc`` class attribute to timezone. I decided to place it in class
rather than module namespace because this seems to be more inline with how
datetime
Alexander Belopolsky added the comment:
On Thu, Jun 3, 2010 at 3:19 PM, Mark Dickinson wrote:
..
> Aren't there valid timezones that are offset by more than 12 hours from UTC?
I am not sure. At this stage treat 12 as a placeholder for whatever
the relevant standard says. I
Alexander Belopolsky added the comment:
On Thu, Jun 3, 2010 at 3:41 PM, Alexander Belopolsky
wrote:
..
> I am not sure. At this stage treat 12 as a placeholder for whatever
> the relevant standard says.
Believe it or not, at least one standard, RFC 2822, allows any offset
representa
Alexander Belopolsky added the comment:
On Thu, Jun 3, 2010 at 3:15 PM, Brett Cannon wrote:
..
> As for the float/int argument, I personally am wary of it. Since the
> timedelta constructor accepts hours as a keyword argument, I don't
> see the benefit of having to support both
Changes by Alexander Belopolsky :
--
assignee: -> belopolsky
___
Python tracker
<http://bugs.python.org/issue5094>
___
___
Python-bugs-list mailing list
Un
Alexander Belopolsky added the comment:
I am having second thoughts about dst indicator. I wrote:
"""
2. Do we want to add a dst indicator and altname attributes? I would say: no. I
would rather treat DST as a different fixed offset timezone.
"""
and Brett res
Alexander Belopolsky added the comment:
> In this case, the docs.python.org link you point to seems
> to be correct, saying that it returns a timedelta.
This issue is specifically about ReST documentation, not the docstring. I
explained in the opening comment that 'It is later exp
Changes by Alexander Belopolsky :
--
stage: committed/rejected -> needs patch
___
Python tracker
<http://bugs.python.org/issue8810>
___
___
Python-bugs-list mai
Changes by Alexander Belopolsky :
--
resolution: accepted ->
___
Python tracker
<http://bugs.python.org/issue8810>
___
___
Python-bugs-list mailing list
Un
Alexander Belopolsky added the comment:
Sean,
It looks like you committed your first patch rather than your second. Is that
what you intended?
Also in msg106734, you agree to change "West" to "west", but committed "West."
Note that "west" is
Alexander Belopolsky added the comment:
> So you want a third argument that lets you flag if the timezone is DST or not?
The third argument is not a flag, it is a timedelta just like the offset. I am
attaching a python prototype for clarity. (See datetimeex.py.)
Conceptually, a 3-argum
Alexander Belopolsky added the comment:
On Thu, Jun 3, 2010 at 3:19 PM, Mark Dickinson wrote:
..
> Aren't there valid timezones that are offset by more than 12 hours from UTC?
Indeed, Christmas Island uses UTC+14. (http://en.wikipedia.org/wiki/Kiritimati).
The most western timezone
Alexander Belopolsky added the comment:
Merging in issue7584 nosy list.
--
nosy: +durban, l0nwlf, r.david.murray, techtonik
___
Python tracker
<http://bugs.python.org/issue5
Alexander Belopolsky added the comment:
> It seems to me that we should not try to produce an RFC 3339 compliant
> date string from a naive datetime. It will be practical to accept
> that restriction once issue 5094 is resolved.
Does this mean that t.rfcformat() should fail if t
Alexander Belopolsky added the comment:
> I'm still leary of supporting any form of DST. A proper DST
> implementation would need to have some conditional code to
> account for the datetime object passed into dst, and yet the
> version you have prototyped doesn't hand
Changes by Alexander Belopolsky :
--
nosy: +tim_one
___
Python tracker
<http://bugs.python.org/issue5094>
___
___
Python-bugs-list mailing list
Unsubscribe:
Alexander Belopolsky added the comment:
Issue #1667546 is more ambitious than this. I propose a very simple patch
which makes tm_zone and tm_gmtoff available on systems with
HAVE_STRUCT_TM_TM_ZONE defined (Linux and BSD variants). The additional fields
are only allowed as attributes so len
Changes by Alexander Belopolsky :
Added file: http://bugs.python.org/file17555/issue1647654a.diff
___
Python tracker
<http://bugs.python.org/issue1647654>
___
___
Pytho
New submission from Alexander Belopolsky :
The time.struct_time class is missing class and field docstrings:
>>> time.struct_time.__doc__ is None
True
>>> time.struct_time.tm_year.__doc__ is None
True
This is significant because it is not obvious that field values are differ
Alexander Belopolsky added the comment:
The timedelta(seconds=0.6112295) example is handled correctly because 0.6112295
sec is not half way between two nearest microseconds:
>>> abs(0.6112295 - 0.6112290) == abs(0.6112295 - 0.6112300)
False
The fact that it displays as if it is does
Alexander Belopolsky added the comment:
The half-way check should be done with decimal arihmetics, but the result is
the same:
>>> x = Decimal(0.6112295)
>>> abs(x - Decimal('0.6112290')) == abs(x - Decimal('0.6112300'))
False
--
Alexander Belopolsky added the comment:
Please see fixes in issue8899.diff.
* Quite a few lines are pretty long. Please stay below 80 chars/line.
Fixed.
* There are trailing spaces in two member docs.
Fixed.
* The range notation is inconsistent. [first, last] or [first, last+1) is what
Alexander Belopolsky added the comment:
On Fri, Jun 4, 2010 at 4:09 PM, Brett Cannon wrote:
..
> For the allowable range, follow the datetime docs as someone might be relying
> on that specification already.
>
Will do. I think it is as simple simple s/12/24/ in two places of th
Changes by Alexander Belopolsky :
--
resolution: -> accepted
___
Python tracker
<http://bugs.python.org/issue8899>
___
___
Python-bugs-list mailing list
Un
Alexander Belopolsky added the comment:
Committed in r81756 (trunk) and r81757 (py3k).
--
stage: commit review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.org/
New submission from Alexander Belopolsky :
Doc/library/time.rst differs in trunk and py3k. It appears that the trunk
version is more up to date and can simply replace the py3k version, but I would
like to have another pair of eyes to take a look before committing.
I also noticed that
Changes by Alexander Belopolsky :
--
nosy: +d...@python
___
Python tracker
<http://bugs.python.org/issue8907>
___
___
Python-bugs-list mailing list
Unsubscribe:
Alexander Belopolsky added the comment:
On Sat, Jun 5, 2010 at 11:35 AM, anatoly techtonik
wrote:
..
> s/datetime/date\/time/ in the last sentence, as the complication comes from:
> -- start offtopic --
> 1. the vast amount of various date and time modules/functions
"Vas
Alexander Belopolsky added the comment:
It may be a bit off-topic for this issue, but I don't like that the python
manual uses UTC as if it was a geographical location. UTC is a time scale.
You cannot be to the east or to the west of UTC just as you cannot be to the
north of the Greg
Alexander Belopolsky added the comment:
The latest patch will produce wrong results if the file was last modified
before timezone rules changed in your location. See issue1647654.
--
assignee: -> belopolsky
dependencies: +No obvious and correct way to get the time zone off
Alexander Belopolsky added the comment:
On Sat, Jun 5, 2010 at 1:24 PM, anatoly techtonik
wrote:
..
> As for offtopic UTC vs GMT - I doubt there is a way to clearly express that
> the offset sign of the
> returned values is negated in comparison with real "UTC offsets" with
Alexander Belopolsky added the comment:
On Sat, Jun 5, 2010 at 1:24 PM, anatoly techtonik
wrote:
..
> So, to answer a question "What is the current UTC offset?" you need to:
> if time.daylight:
> if time.altzone: # using only if defined
> use time.altzone
> else
Alexander Belopolsky added the comment:
How hard is it to add
now = datetime.now
todate = date.today
at the top of your module is you really like shorter names?
-1
--
assignee: -> belopolsky
nosy: +belopolsky
priority: normal -> low
___
Alexander Belopolsky added the comment:
Anatoly,
Didn't you just recently complain about the large number of functions in
datetime module? (issue7584)
datetime.datetime.now().time() seems adequate to me.
What is your use case?
--
assignee: -> belopolsky
nosy: +belopolsky
Alexander Belopolsky added the comment:
I see this in py3k branch on MacOS X:
[GCC 4.2.1 (Apple Inc. build 5646) (dot 1)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import datetime
>>> date
Alexander Belopolsky added the comment:
What platforms have broken strftime and how badly is it broken there?
Is there a python version somewhere? PyPy?
--
assignee: -> belopolsky
nosy: +belopolsky
type: -> feature request
___
Python t
Alexander Belopolsky added the comment:
With recent enhancements to datetime module, timegm has become a 1-liner:
EPOCH = 1970
_EPOCH_DATETIME = datetime.datetime(EPOCH, 1, 1)
_SECOND = datetime.timedelta(seconds=1)
def timegm(tuple):
"""Unrelated but handy function to
Alexander Belopolsky added the comment:
Closing as duplicate of issue1289118. Division of timedelta by integer is
supported in py3k since r81625.
--
nosy: +belopolsky -Alexander.Belopolsky
resolution: -> duplicate
status: open -> closed
superseder: -> timedelta multiply a
Changes by Alexander Belopolsky :
--
assignee: -> belopolsky
nosy: +belopolsky
stage: -> needs patch
___
Python tracker
<http://bugs.python.org/
Alexander Belopolsky added the comment:
As far as I remember, the datetime module started as a pure python module and
was reimplemented in C around year 2003 or so. One of the important additions
at that time was the C API to datetime functionality. I am afraid that with
the _timemodule.c
Changes by Alexander Belopolsky :
--
assignee: -> belopolsky
nosy: +belopolsky -Alexander.Belopolsky
___
Python tracker
<http://bugs.python.org/issue1
Alexander Belopolsky added the comment:
I would prefer exposing tm_gmtoff in time.localtime() output. The advantage is
that on platforms that support it is struct tm, it will return correct offset
for times in the past, not only for the current time. See issue1647654.
On platforms without
Alexander Belopolsky added the comment:
Looks like a bug to me:
>>> datetime.strptime("1", "%d")
datetime.datetime(1900, 1, 1, 0, 0)
>>> datetime.strptime('1', '%m')
datetime.datetime(1900, 1, 1, 0, 0)
both %m and %d accept single dig
Changes by Alexander Belopolsky :
--
versions: +Python 3.2 -Python 2.4, Python 2.5, Python 2.6, Python 2.7, Python
3.0, Python 3.1
___
Python tracker
<http://bugs.python.org/issue5
Alexander Belopolsky added the comment:
With %f support in, isn't this issue out of date?
--
assignee: -> belopolsky
nosy: +belopolsky
stage: -> unit test needed
versions: +Python 3.2 -Python 2.6
___
Python tracker
<http://b
Changes by Alexander Belopolsky :
Removed file: http://bugs.python.org/file14759/unnamed
___
Python tracker
<http://bugs.python.org/issue2516>
___
___
Python-bugs-list m
Alexander Belopolsky added the comment:
gungor: your messages look mangled. It may be the case of email to trucker
bug. Can you briefly explain what you are trying to add to the discussion?
--
assignee: -> belopolsky
___
Python tracker
&l
Alexander Belopolsky added the comment:
I wonder if this is subject to change. I find it odd that
>>> "{:g}".format(1e3)
'1000'
but one has to use % in
>>> "{:%Y}".format(datetime.now())
'2010'
It is also different from PEP 3101
Alexander Belopolsky added the comment:
I am attaching the next version of my patch and changing priority to high
because it appears that several issues depend on resolution of this one.
Here is the summary of changes since issue5094a.diff:
1. The constructor now accepts only whole number of
Alexander Belopolsky added the comment:
Good catch, Daniel!
Fixed in issue5094c.diff.
--
Added file: http://bugs.python.org/file17570/issue5094c.diff
___
Python tracker
<http://bugs.python.org/issue5
2301 - 2400 of 3596 matches
Mail list logo
