Alexander Belopolsky added the comment:
On Tue, Jan 4, 2011 at 1:30 PM, Alexander Belopolsky
wrote:
..
> This is clearly a bug. (Although Y2K note contradicts time.accept2dyear
> documentation.)
>
PyObject_IsTrue() may fail - this is probably the reason for the
current odd logic.
Alexander Belopolsky added the comment:
On Tue, Jan 4, 2011 at 1:49 PM, Georg Brandl wrote:
..
> But if it fails, why not just let it fail?
>
Sure. That's what I meant by fixing the patch. See new patch attached.
--
Added file: http://bugs.python.org/file20261/issue
Alexander Belopolsky added the comment:
Victor,
Here is an interesting case for your collection: PyDict_GetItemString. Note
that it is documented as not setting error, but in fact it may if encoding
fails. This rarely an issue because most uses of PyDict_GetItemString are with
an ASCII
Alexander Belopolsky added the comment:
Attached patch, issue10827b.diff, fixes the accept2dyear = True issue and
removes unnecessary struct_time to tuple conversion, but otherwise does not
change the Y2K behavior. The code handling accept2dyear is refactored so that
it is now easy to
Alexander Belopolsky added the comment:
The patch contains a lot of repeated boilerplate code. I wonder if some of it
can be factored out and reused. For example iov buffer allocation code appears
to be identical in writev and readv.
--
nosy: +belopolsky
Alexander Belopolsky added the comment:
I would like to push this for 3.2. Recent discussions at issue10827 and on
python-dev seem to favor removal of arbitrary limits on year range.
--
nosy: +georg.brandl
___
Python tracker
<h
Changes by Alexander Belopolsky :
--
title: Python's strftime dislikes years before 1900 -> datetime.strftime
dislikes years before 1900
___
Python tracker
<http://bugs.python.org/i
Alexander Belopolsky added the comment:
This is yet another request for functionality that can be implemented as a
simple expression using datetime arithmetics. Also, issue #9864 is not a
compelling use case because "the parsedate() function now returns a datetime
object." See
Alexander Belopolsky added the comment:
I agree with Eric. Limiting field width when formatting error messages is a
good safety measure. It is not only the amount of garbage that can be spitted
in error logs, if garbage is not null-terminated, you may get a SEGV instead of
a somewhat
Alexander Belopolsky added the comment:
> /* Caller is responsible for limiting the format */
Note that it is a good idea to avoid memory allocation during exception
processing. Think of out of memory errors: how would you report those if you
need more memory to format the error mess
Alexander Belopolsky added the comment:
Maybe rather than spending the effort maintaining a legacy API such as
strftime, someone could look into implementing localized date formatting as
defined by recent Unicode standards:
http://unicode.org/reports/tr35/#Date_Format_Patterns
Apparently
Alexander Belopolsky added the comment:
On Thu, Jan 6, 2011 at 2:56 PM, Eric Smith wrote:
..
> If we're going to take this on (re-writing strftime), I think the way to do
> it is to have it take the locale info as a
> parameter, and if that parameter is NULL then look up t
Alexander Belopolsky added the comment:
On Thu, Jan 6, 2011 at 3:49 PM, STINNER Victor wrote:
..
> eric> I always thought that one of the reasons for specifying the length
> eric> was in case a pointer pointed to garbage: at least you'd be limiting
> eric> how much tr
New submission from Alexander Belopolsky :
It is much easier to remember and to type -m test instead of -m test.regrtest,
but the usefulness of this feature is limited by the fact that it only works
with the latest version. Since this does not require any user-visible changes,
I think it
Changes by Alexander Belopolsky :
--
nosy: +michael.foord
___
Python tracker
<http://bugs.python.org/issue10849>
___
___
Python-bugs-list mailing list
Unsubscribe:
Alexander Belopolsky added the comment:
> -0 we don't backport new features
New tests are routinely backported when they accompany bug fixes, so new
features under Lib/test are probably a fair game. Given that this feature is
implemented entirely in a file that is not used for a
Alexander Belopolsky added the comment:
Attached patch, issue10827c.diff, implements the following logic in gettmarg:
/* If year is specified with less that 4 digits, its interpretation
Changes by Alexander Belopolsky :
Added file: http://bugs.python.org/file20295/issue10827c.diff
___
Python tracker
<http://bugs.python.org/issue10827>
___
___
Python-bug
Alexander Belopolsky added the comment:
> I think we should investigate deeper why this enhancement
> request didn't get into Python 3.
There is nothing to investigate here. This is a request for a marginal
improvement and OP did not follow up even though a core developer respon
Alexander Belopolsky added the comment:
Committed in 87829.
I added a year >= 1900 check in time.strftime for now because removing or
relaxing this limit should be done in coordination with similar datetime module
issue. See #1777412.
See also python-dev discussion starting at
h
Alexander Belopolsky added the comment:
Commit link: r87829
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue10827>
___
___
Python-
Alexander Belopolsky added the comment:
As Raymond explained, he added these links as a kind of social experiment and
this issue itself shows that it works. :-)
I have a few suggestions on how to make these links more useful:
1. A ViewVC link is the simplest solution to present the source
Alexander Belopolsky added the comment:
On Fri, Jan 7, 2011 at 4:32 PM, Éric Araujo wrote:
..
> 3: Not all modules are good examples (see threading for some unelegant code),
> so I support ad-hoc selection.
The problem with ad-hoc selection is that it adds maintenance burden
(someone
Alexander Belopolsky added the comment:
After r87829 (see issue10827), the insane Y2K behavior of time module functions
does not extend beyond year 999. Hopefully in Python 3.3, accept2dyear will be
removed completely and datetime.strftime() will be able to support the full
intersection of
Alexander Belopolsky added the comment:
On Fri, Jan 7, 2011 at 7:26 PM, STINNER Victor wrote:
..
> Here is a patch removing the arbitrary datetime.strftime() limit on year: it
> adds an
> option "accept2dyear" to time.strftime() and datetime just sets this option
> to
Alexander Belopolsky added the comment:
--
--Guido van Rossum (python.org/~guido)
""" -- http://mail.python.org/pipermail/python-dev/2011-January/107246.html
^^^ the last lines of msg125738 cut by roundup ^^^
--
___
Python
Alexander Belopolsky added the comment:
I like strftime_1_.patch, but it really belongs to #10827. Please leave a
note there once you commit and mention the issue in commit log.
--
___
Python tracker
<http://bugs.python.org/issue1777
Changes by Alexander Belopolsky :
--
resolution: -> rejected
stage: unit test needed -> committed/rejected
status: open -> pending
superseder: -> Add aware local time support to datetime module
___
Python tracker
<http://
Alexander Belopolsky added the comment:
On Sun, Jan 9, 2011 at 3:52 PM, Terry J. Reedy wrote:
> .. It would be nice to get the fixes into 3.2.
Yes, it would be nice, but I don't have a 3.2 patch (yet). As you can
see from my last comment, I ran into a bug in the alpha version of
sph
Alexander Belopolsky added the comment:
The C89 draft as available through a Wikipedia link,
http://flash-gordon.me.uk/ansi.c.txt, specifies tm_sec range as [0, 60].
Although it looks like the range has been extended in the published version. A
discussion on comp.std.c describes the
Alexander Belopolsky added the comment:
Committed in revision 87910.
--
resolution: -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.o
Changes by Alexander Belopolsky :
--
stage: unit test needed -> needs patch
versions: +Python 3.3 -Python 3.2
___
Python tracker
<http://bugs.python.org/iss
Alexander Belopolsky added the comment:
I am going to close this as superseded by #9527. In order to properly
implement #9527 in datetime.py, some kind of tm_gmtoff support will need to be
added to the time module, but I don't want this to become a feature that is
exclusively available
Alexander Belopolsky added the comment:
I would also like to consider using OS strptime on platforms with a decent
implementation.
--
stage: -> needs patch
type: -> feature request
versions: +Python 3.3 -Python 3.2
___
Python tracker
Alexander Belopolsky added the comment:
-1 on releasing the GIL around strftime(). Until we have an implementation
that can support multiple locales and multiple timezones, people will work
around this limitation by messing up with the TZ environment variable or global
locale settings
Alexander Belopolsky added the comment:
Adding #8915 as a dependency because deducing D_T_FMT locale setting from
strftime output seems impossible:
>>> locale.nl_langinfo(locale.D_T_FMT)
'%a %b %e %H:%M:%S %Y'
--
dependencies: +Use locale.nl_langinfo in _strptim
Alexander Belopolsky added the comment:
Victor,
You may be interested because your native language is implicated. :-)
--
nosy: +haypo
___
Python tracker
<http://bugs.python.org/issue8
Alexander Belopolsky added the comment:
Committed in revision 87919. If bots are happy about the unit test, this
should be backported to 3.1 and 2.7.
--
resolution: -> fixed
stage: unit test needed -> committed/rejected
___
Python tracker
Alexander Belopolsky added the comment:
Note that before r82065, python prototype, now available as Lib/datetime.py had
binary operations implemented to return subclass instances. Here is annotated
pre-r82065 code:
39876 gvanrossum def __add__(self, other):
39876 gvanrossum
Changes by Alexander Belopolsky :
--
versions: +Python 3.3 -Python 3.2
___
Python tracker
<http://bugs.python.org/issue9034>
___
___
Python-bugs-list mailin
Changes by Alexander Belopolsky :
--
versions: +Python 3.3 -Python 3.2
___
Python tracker
<http://bugs.python.org/issue9004>
___
___
Python-bugs-list mailin
Alexander Belopolsky added the comment:
I am going to reject this. None of the proposed changes seem to be better than
the current documentation. The time.daylight variable has the same meaning as
eponymous C variable defined in time.h header. The latter is described in
widely available
Alexander Belopolsky added the comment:
On Tue, Jan 11, 2011 at 5:06 AM, anatoly techtonik
wrote:
..
> IIUC #9527 is about datetime and this request is about time.localtime,
This is correct, but did you notice what I wrote in my last message?
"""
In order to properly
Alexander Belopolsky added the comment:
On Tue, Jan 11, 2011 at 4:55 AM, anatoly techtonik
wrote:
..
> I propose the following change:
..
> http://docs.python.org/library/time.html#time.daylight
> - Nonzero if a DST timezone is defined.
> + .. To check if DST is currently
Changes by Alexander Belopolsky :
--
versions: +Python 3.3 -Python 3.2
___
Python tracker
<http://bugs.python.org/issue9051>
___
___
Python-bugs-list mailin
Alexander Belopolsky added the comment:
Backported to 3.1 (r87934) and 2.7 (r87935).
--
resolution: accepted -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/
Alexander Belopolsky added the comment:
New patch needed to address the issue of time.strftime() accepting %Y when year
is 1900 and other similar oddities. See msg107402 above. Also a patch for
datetime.py is needed.
--
stage: patch review -> needs patch
versions: +Python
Alexander Belopolsky added the comment:
Georg,
Is it too late to commit this for 3.2?
--
nosy: +georg.brandl
___
Python tracker
<http://bugs.python.org/issue5
Alexander Belopolsky added the comment:
Here is a related bug:
$ make patchcheck
./python.exe ../py3k-commit/Tools/scripts/patchcheck.py
Getting the list of files that have been added/changed ... need a checkout to
get modified files
[49399 refs]
make: *** [patchcheck] Error 1
Alexander Belopolsky added the comment:
I've noticed that the time module docstring handles this issue rather nicely:
>>> help('time')
...
timezone -- difference in seconds between UTC and local standard time
altzone -- difference in seconds between UTC and lo
Alexander Belopolsky added the comment:
On Tue, Jan 11, 2011 at 11:20 AM, Tomas Kubes wrote:
..
> You should try to think like a person that does not have any background
> knowledge of underlying libraries but
> just looks through the time library trying to solve the question -
Alexander Belopolsky added the comment:
On Tue, Jan 11, 2011 at 1:56 PM, Georg Brandl wrote:
..
> It seems to me that the quoted function from bzr ...
> would be very helpful to add to the `time` module docs as an example.
The problem with this function is the same as with the doc p
Alexander Belopolsky added the comment:
On Tue, Jan 11, 2011 at 4:15 PM, anatoly techtonik
wrote:
..
> To summarize: What is wrong with my previous proposal if we remove t
> from params?
Not much is wrong with it. If it would come in a form of a patch and
without typos or mark-up mi
Alexander Belopolsky added the comment:
Committed in revision 87942.
@Georg: Yes, I ran coverage and all branches are covered.
@Meador: I don't think the old len calculation could handle the case of array
object in initial. In any case, I don't find the new code much more
compli
Alexander Belopolsky added the comment:
Committed to 2.7 in revision 87944.
--
stage: commit review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.org/
Alexander Belopolsky added the comment:
Reverted backport in r87945.
--
versions: -Python 2.7
___
Python tracker
<http://bugs.python.org/issue5109>
___
___
Pytho
Alexander Belopolsky added the comment:
> time.strptime(s, '%c' ) ?
Oh my. It certainly took a long time to recognize a silly mistake!
Thanks.
--
dependencies: -Use locale.nl_langinfo in _strptime
resolution: -> invalid
__
Changes by Alexander Belopolsky :
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue8957>
___
___
Python-bugs-list mailing list
Un
Alexander Belopolsky added the comment:
On Tue, Jan 11, 2011 at 6:10 PM, Terry J. Reedy wrote:
..
> Doctest runs on .rst files, which are plain text files, finds and reports
> errors, and reports no errors when the errors are fixed.
> See #10875 where is was very helpful. So your las
Alexander Belopolsky added the comment:
My tests were wrong but the problem does exist. I am attaching a script that
tests strptime(.., '%c') for all locales installed on my system (an unmodified
US Mac OS X 10.6.6).
The only failing locale that I recognize is Hebrew (he_IL).
Changes by Alexander Belopolsky :
--
title: strptime('%c', ..) fails to parse output of strftime('%c', ..) in
non-English locale -> strptime(.., '%c') fails to parse output of
strftime('%c', ..) in some locales
__
Alexander Belopolsky added the comment:
> build outside source tree fail for me and pass for python
> developers :). So no idea how to convince them to fix this issue.
I am collecting out of tree build failures in issue 9860. One issue that is
easily reproducible is triggered when the
Alexander Belopolsky added the comment:
On Tue, Jan 11, 2011 at 7:26 PM, Roumen Petrov wrote:
..
> - locales with %A and %B are broken on this platform as %c is "Appropriate
> date and time representation (%c) with abbreviations"
According to what standard? POSIX defines it
Alexander Belopolsky added the comment:
I am going to close this as superseded by #9527. All these issues, current,
#9527, and #1647654 are really about Python's lack of access to the system
timezone information and #9527 seem to be the most appropriate solution.
My specific concern
Changes by Alexander Belopolsky :
--
keywords: -patch
___
Python tracker
<http://bugs.python.org/issue5516>
___
___
Python-bugs-list mailing list
Unsubscribe:
Alexander Belopolsky added the comment:
On Tue, Jan 11, 2011 at 10:03 PM, Terry J. Reedy wrote:
..
> What is the alternative?
I am attaching an alternative patch for sorting howto. You can run the
doctests in it as follows:
$ python2.7 tools/sphinx-build.py -b doctest -d build/doctr
Alexander Belopolsky added the comment:
I have updated Sphinx and rerun py3k doctests. It looks like the newest Sphinx
does not check examples unless the file has a .. testsetup:: directive
somewhere. This is nice because it focuses on the files that are clearly
intended to be doctest
Changes by Alexander Belopolsky :
Added file: http://bugs.python.org/file20376/issue10225-py3k.diff
___
Python tracker
<http://bugs.python.org/issue10225>
___
___
Pytho
Changes by Alexander Belopolsky :
Removed file: http://bugs.python.org/file20375/issue10225-py3k.diff
___
Python tracker
<http://bugs.python.org/issue10225>
___
___
Pytho
Changes by Alexander Belopolsky :
--
versions: +Python 3.3 -Python 3.2
___
Python tracker
<http://bugs.python.org/issue9941>
___
___
Python-bugs-list mailin
Alexander Belopolsky added the comment:
Committed the simple fixes in r87957. Updated the patch to include only the
remaining changes.
--
Added file: http://bugs.python.org/file20377/issue10225-py3k.diff
___
Python tracker
<http://bugs.python.
Changes by Alexander Belopolsky :
Removed file: http://bugs.python.org/file20376/issue10225-py3k.diff
___
Python tracker
<http://bugs.python.org/issue10225>
___
___
Pytho
Alexander Belopolsky added the comment:
On Sat, Dec 4, 2010 at 3:34 AM, Eli Bendersky wrote:
>..
> However, while experimenting, I think I ran into much larger problems. Either
> that or I've forgotten
> how to use the module :-)
I am afraid it is the latter. :-) The
Alexander Belopolsky added the comment:
On Wed, Jan 12, 2011 at 12:17 PM, Alexander Belopolsky
wrote:
..
> The counts should grow in repeated runs.
I did not pay attention: the numbers in summary are numbers of lines,
not execution counts. The execution counts in .cover file grow as
expec
Alexander Belopolsky added the comment:
On Sat, Dec 4, 2010 at 3:34 AM, Eli Bendersky wrote:
..
> I reviewed the patch and ported the changes to the newest sources
Eli,
I don't think you ever posted an updated patch. Do you still have it?
This may be a good starting issue for
Alexander Belopolsky added the comment:
Committed documentation changes in revision 87990.
--
resolution: -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.o
Alexander Belopolsky added the comment:
I am replacing issue6697-lsprof.diff with a (hopefully) more carefully written
version that addresses the issues that Victor noted.
Victor,
I take your comment as +1 for adding PyModule_GetNameObject().
I started looking into adding unit tests that
Changes by Alexander Belopolsky :
Removed file: http://bugs.python.org/file19980/issue6697-lsprof.diff
___
Python tracker
<http://bugs.python.org/issue6697>
___
___
Pytho
Alexander Belopolsky added the comment:
Just to clarify: Anatoly changed the resolution, not status (and I agree that
was not appropriate.) The status was set to "pending" and that would change to
"open" automatically if a new comment is posted.
As for the substance of
Alexander Belopolsky added the comment:
Closing this in favor of #9527. See msg126064 for more details.
--
stage: patch review -> committed/rejected
___
Python tracker
<http://bugs.python.org/issue1
Alexander Belopolsky added the comment:
Let me summarize the issue: the PyArg_ParseTuple format code 'O' returns a
borrowed reference. However, when the 'O' code appears inside parenthesis,
there may not be an object to hold the reference to borrow from. This is what
Alexander Belopolsky added the comment:
Attached patch passes the regrtest and makes test-functools.py raise an
exception rather than crash. The proposed change will make functions like
partial.__setstate__ require tuple argument even though currently it would
accept any container. This is
Alexander Belopolsky added the comment:
What "manpage" are you reporting? In py3k branch,
$ groff -Tascii -man Misc/python.man
..
PYTHONIOENCODING
If this is set before running the interpreter, it overrides the
encoding used for stdin/stdout/
Alexander Belopolsky added the comment:
On the second thought, maybe "de manpage" is not a misspelling of "the
manpage", but a reference to a German locale manpage? I don't think python.org
releases include manpage translations. You may need to report
Alexander Belopolsky added the comment:
Following Anatoly's review, I renamed datetime argument and a local variable,
added comments and expanded docstring. I am uploading a new patch:
datetime-localtime-proto-1.diff.
Martin, I could not figure out how to add the new patch to rietveld
Alexander Belopolsky added the comment:
Forwarding Rietveld conversation to the tracker. It looks like
Rietveld integration has a bug and sends reviews to
n...@psf.upfronthosting.co.za rather than to rep...@bugs.python.org.
Forwarded conversation
Subject: Add aware local time support to
Changes by Alexander Belopolsky :
--
title: Add aware local time support to datetime module (issue9527) -> Add aware
local time support to datetime module
___
Python tracker
<http://bugs.python.org/iss
Changes by Alexander Belopolsky :
--
nosy: +eli.bendersky
___
Python tracker
<http://bugs.python.org/issue10908>
___
___
Python-bugs-list mailing list
Unsubscribe:
Alexander Belopolsky added the comment:
On Sat, Jan 15, 2011 at 2:20 AM, Eli Bendersky wrote:
..
> This solution is a hack, but so is the whole __calc_date_time function :-)
> [IMHO]
>
I am not sure how to proceed. On one hand, I opened this issue to
demonstrate that th
Alexander Belopolsky added the comment:
6. datetime.find(self.f_month[m]) >= 0 -> self.f_month[m] in datetime
Python is not C!
--
___
Python tracker
<http://bugs.python.org/
Alexander Belopolsky added the comment:
You pretty much hit the nail on the head. Some platforms don't have strptime
or did not have it at the time this code was written. The locale module is
probably more recent than this code as well.
--
nosy: +Alexander.Belop
Alexander Belopolsky added the comment:
> 1. It crashes with "KeyError". ...
I assume this means it raises a KeyError when given a bytes object as an
argument.
>>> Internaldate2tuple(b'INTERNALDATE "01-Jan-2000 12:00:00 +"')
Traceback (mos
Alexander Belopolsky added the comment:
There are at least 3 issues here: a documentation issue, a py3k bug and at
least one feature request. Given that the logistics are different for
different kinds of issues, I think it would be best to split them on the
tracker. Here is how I see what
Changes by Alexander Belopolsky :
--
resolution: -> duplicate
stage: unit test needed -> committed/rejected
superseder: -> imaplib: Internaldate2tuple() is documented to return UTC, but
it returns local time
___
Python track
Alexander Belopolsky added the comment:
It makes sense that Internaldate2tuple() returns local time because timetuple
(with its tm_isdst flag) strongly suggests local time. (See also issue 9004.)
If UTC or any other timezone time is needed, it would be best to provide a
function that would
Alexander Belopolsky added the comment:
Committed in revision 88114.
--
___
Python tracker
<http://bugs.python.org/issue10934>
___
___
Python-bugs-list mailin
Alexander Belopolsky added the comment:
Merged to 2.7 in revision 88116.
--
stage: commit review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.org/i
Alexander Belopolsky added the comment:
Georg,
This is an obvious artifact of an untested py3k port. Can this go in 3.2?
The patch looks good except for a long line in the test which I can take care
of.
--
assignee: -> belopolsky
nosy: +belopolsky, georg.brandl
stage: ->
Alexander Belopolsky added the comment:
I agree that this is a bug and the solution is right, I am not sure this should
be applied during RC period. The bug has been present and known for a long
time, so affected parties probably have a work-around in place already.
--
nosy
Alexander Belopolsky added the comment:
David,
Can you weigh in on this?
I am -1 on improving Internaldate2tuple(). I think the module should provide a
function that would return an aware datetime object instead of a timetuple.
The proposed patch will make error reporting from
801 - 900 of 3596 matches
Mail list logo
