Alexander Belopolsky added the comment:
Committed to py3k in revision 87442.
--
versions: -Python 3.2
___
Python tracker
<http://bugs.python.org/issue10
Alexander Belopolsky added the comment:
On Wed, Dec 22, 2010 at 9:27 PM, Scott Dial wrote:
>
> Scott Dial added the comment:
>
> On 12/22/2010 8:52 PM, STINNER Victor wrote:
> > Amaury asked for a sys.setsegfaultenabled() option: I think that the
> > command line op
Alexander Belopolsky added the comment:
Committed r87443 (3.2) and r87444 (3.1).
--
resolution: -> fixed
stage: commit review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Changes by Alexander Belopolsky :
--
status: pending -> closed
___
Python tracker
<http://bugs.python.org/issue6280>
___
___
Python-bugs-list mailing list
Un
Alexander Belopolsky added the comment:
Committed in r87463 (3.2), r87464 (2.7) and r87465 (3.1).
--
resolution: -> fixed
stage: commit review -> committed/rejected
status: open -> closed
versions: +Python 3.1
___
Python track
Alexander Belopolsky added the comment:
I would like to start reviewing this code, but dated zip files on a tracker
make a very inefficient VC setup. Would you consider exporting your
development history to some public VC system?
--
nosy: +belopolsky
New submission from Alexander Belopolsky :
Among other things, README says:
"""
Each test should have a link to the bug report:
# http://python.org/sf/BUG#
"""
but the only such link is found in crashers/infinite_loop_re.py and points to a
closed iss
Alexander Belopolsky added the comment:
Committed backports:
r87540 (3.1)
r87541 (2.7)
r87546 (2.6)
--
resolution: -> fixed
stage: commit review -> committed/rejected
status: open -> closed
versions: +Python 3.2
___
Python track
Alexander Belopolsky added the comment:
I like the idea, but I don't like the trend that parser code continues to
diverge from pgen. I understand that most of the Python runtime is not
available to pgen, but maybe a more elegant solution than changing the type
conditional on PGEN c
Alexander Belopolsky added the comment:
On Sat, Nov 27, 2010 at 5:03 PM, Marc-Andre Lemburg
wrote:
..
> * this version should be slightly faster and is also easier to read:
>
> #define Py_UCS4_READ_CODE_POINT(ptr, end) \
..
> Py_UNICODE_JOIN_SURROGATES((ptr)++, (ptr)++)
Alexander Belopolsky added the comment:
I am attaching a patch for commit review. I added an underscore prefix to all
new macros. This way I am not introducing new features and we will have a full
release cycle to come up with better names. i would just note that "next"
term
Alexander Belopolsky added the comment:
On Wed, Dec 29, 2010 at 10:00 AM, Georg Brandl wrote:
..
>
>> Let's wait for 3.3 with the change.
>
> Definitely.
Does this also mean that the numerous surrogates related bugs should
wait until 3.3 as well? (See issues #9200 and #105
Alexander Belopolsky added the comment:
On Wed, Dec 29, 2010 at 7:19 AM, Marc-Andre Lemburg
wrote:
..
> * The macros still need some more attention to enhance their performance.
>
Although I made your suggested change from '-' to '&', I seriously
doubt that thi
Alexander Belopolsky added the comment:
On Sat, Nov 27, 2010 at 5:24 PM, Marc-Andre Lemburg
wrote:
..
> Perhaps we should allow ord() to work on surrogates in
> UCS4 builds as well. That would reduce the number of
> surprises.
>
This is an interesting idea, however, having surrog
Alexander Belopolsky added the comment:
The example in my previous message should have been:
>>> '\U0001' == '\uD800\uDC00'
True
--
___
Python tracker
<h
Alexander Belopolsky added the comment:
On Wed, Dec 29, 2010 at 11:36 AM, Georg Brandl wrote:
..
> That bug already strikes me as quite exotic.
>
Would it look as exotic if presented like this?
File "", line 1
𐌀 = 5
^
SyntaxError: invalid character in identifier
Alexander Belopolsky added the comment:
I should stop using e-mail to reply to bug reports! The mangled example was
>>> 𐌀 = 5
File "", line 1
𐌀 = 5
^
SyntaxError: invalid character in identifier
--
___
Py
Changes by Alexander Belopolsky :
Added file: http://bugs.python.org/file20190/issue10542a.diff
___
Python tracker
<http://bugs.python.org/issue10542>
___
___
Python-bug
Alexander Belopolsky added the comment:
On Wed, Dec 29, 2010 at 3:36 PM, STINNER Victor wrote:
..
> Use non-ASCII identifiers is exotic. Use non-BMP identifiers is
> crazy :-)
Hmm, we clearly disagree on what crosses the boundary of the mental
norm. IMHO, it is crazy to require us
Changes by Alexander Belopolsky :
--
nosy: +belopolsky
___
Python tracker
<http://bugs.python.org/issue8271>
___
___
Python-bugs-list mailing list
Unsubscribe:
Alexander Belopolsky added the comment:
[MAL]
> * Unicode objects are NUL-terminated, but only very external APIs
>rely on this (e.g. code using the Windows Unicode API). Please
>don't make the code in unicodeobject.c itself rely on this
>subtle detail.
I would
Alexander Belopolsky added the comment:
Martin's original code (r32301) was pretty clear:
32301 loewis # IDNA allows decoding to operate on Unicode strings,
too.
32301 loewis if isinstance(input, unicode):
32301 loewis labels = dots.split(
Alexander Belopolsky added the comment:
Arguably, it is not a bug if codec's decode method rejects unicode strings with
a TypeError. The 2.x implementation seems to allow decoding of ASCII-only
unicode labels joined by arbitrary RFC 3490 separators. I am not sure what the
use case for
Alexander Belopolsky added the comment:
On Wed, Dec 29, 2010 at 8:02 PM, Martin v. Löwis wrote:
..
>
> I plan to propose a complete redesign of the representation of Unicode
> strings, which may well make this entire set of changes obsolete.
>
Are you serious? This sounds like
Alexander Belopolsky added the comment:
On Wed, Dec 29, 2010 at 9:38 PM, Alexander Belopolsky
wrote:
..
> Given that until recently (r87433) the PEP and the reference manual
> disagreed on the definition,
Actually, it looks like PEP 3131 and the Language Reference [1] still
disagree
Alexander Belopolsky added the comment:
I wonder if the issues raised here can be neatly addressed by applying NFKC
normalization before string to number conversion. This will convert full-width
variants to ASCII and also eliminate digit/decimal differences. For example
superscript and
Alexander Belopolsky added the comment:
On Sun, Jan 2, 2011 at 10:52 AM, Georg Brandl wrote:
..
> Well, then I would have no problem with checking for that condition
> beforehand and raising
> ValueError.
>
IIRC, there was a similar bug report about ctime where pre-condition
Alexander Belopolsky added the comment:
On Sun, Jan 2, 2011 at 1:52 PM, Alexander Belopolsky
wrote:
..
>> Well, then I would have no problem with checking for that condition
>> beforehand and raising
>> ValueError.
>>
>
> IIRC, there was a similar bug report a
Changes by Alexander Belopolsky :
--
nosy: +belopolsky
___
Python tracker
<http://bugs.python.org/issue10807>
___
___
Python-bugs-list mailing list
Unsubscribe:
Alexander Belopolsky added the comment:
On Sun, Jan 2, 2011 at 1:59 PM, Alexander Belopolsky
wrote:
..
> Hmm. My search brought up issue 10563, but the last message on that
> issue says that "a change has been recently made to time.asctime() to
> reject year > . See r85
Alexander Belopolsky added the comment:
Committed in revision 87648.
--
___
Python tracker
<http://bugs.python.org/issue8013>
___
___
Python-bugs-list mailin
Alexander Belopolsky added the comment:
On Sun, Jan 2, 2011 at 5:35 PM, Georg Brandl wrote:
..
> Both asctime() and ctime() fixed to remove newline no matter how many
> digits the year has in r87657. I also took the liberty of making the error
> messages consistent.
Georg,
I disa
Alexander Belopolsky added the comment:
On Sun, Jan 2, 2011 at 6:01 PM, Georg Brandl wrote:
..
>
> Since all implementations we have or can test have a defined behavior in one
> way or the other,
> I think an example of an implementation that exhibits such undefined behavior
&
Alexander Belopolsky added the comment:
On Sun, Jan 2, 2011 at 6:10 PM, Georg Brandl wrote:
..
> All right, then I wonder why your checktm() doesn't check the tm_year?
It is not mine. I thought it did. I might have missed that when I
reviewed the patch or there was a reason for tha
Alexander Belopolsky added the comment:
On Sun, Jan 2, 2011 at 6:17 PM, Georg Brandl wrote:
..
> (What I mean is that overwriting \n or not, the code is unsafe, so the check
> must be
> done beforehand. Why should that be left to 3.3?)
Reading beyond a buffer is somewhat safer tha
Alexander Belopolsky added the comment:
On Sun, Jan 2, 2011 at 6:29 PM, Georg Brandl wrote:
..
> You cannot have both: a safe implementation and the correct behavior with
> glibc
> (not Linux!) -- except if you start special-casing. Not sure that's worth it.
>
That's t
Alexander Belopolsky added the comment:
..
> My plan was to pick the low-hanging fruit (the null check) for 3.3 and
s/3.3/3.2/
--
___
Python tracker
<http://bugs.python.org/iss
Alexander Belopolsky added the comment:
On Sun, Jan 2, 2011 at 6:46 PM, Georg Brandl wrote:
..
> I don't see the range checking as particularly challenging; I'm sure you can
> get it done in time for 3.2.
Will do.
--
___
Pytho
Alexander Belopolsky added the comment:
Backported in r87664 (2.6), r87663 (2.7) and r87662 (3.1).
Reopening to implement bounds checking for 3.2. Note that for time.asctime,
checking the year range is trivial, but for time.ctime it is not because year
is not computed in python code. One
Changes by Alexander Belopolsky :
--
assignee: -> belopolsky
___
Python tracker
<http://bugs.python.org/issue10814>
___
___
Python-bugs-list mailing list
Un
Alexander Belopolsky added the comment:
Can someone with a windows box test
>>> time.asctime((12345, 1, 1, 0, 0, 0, 0, 0, 0))?
If that crashes as well, can you tell which part of
( ( tb->tm_mday >= 1 ) && ( ( ( _days[ tb->tm_mon + 1 ] - _days[ tb-&
Alexander Belopolsky added the comment:
On Mon, Jan 3, 2011 at 11:26 AM, Brian Curtin wrote:
..
>>PCbuild\amd64\python_d.exe
> Python 3.2b2+ (py3k, Jan 3 2011, 10:24:18) [MSC v.1500 64 bit (AMD64)] on
> win32
> Type "help", "copyright", "cr
Alexander Belopolsky added the comment:
On Mon, Jan 3, 2011 at 11:43 AM, Brian Curtin wrote:
..
> No crash on 0-day or 300,000. I bumped it up to 3,000,000 and got a
> UnicodeDecodeError, although
> I'm not sure of the relevance of that to this issue.
It looks like we need an
Alexander Belopolsky added the comment:
I committed a a fix for the test in r87690. If this fixes the buildbot, I'll
backport to 2.7 and call it a day for < 3.2. For 3.2 a proper year range check
will be added to close issue 8013.
--
__
Alexander Belopolsky added the comment:
On Mon, Jan 3, 2011 at 12:30 PM, Amaury Forgeot d'Arc
wrote:
..
> Btw, I have a failed assertion in the test suite, with "time.ctime(1e12)"
This is from r87657. I commented on that change in msg125117.
Hopefully a range check wil
Alexander Belopolsky added the comment:
The 3.1 buildbot is green:
http://www.python.org/dev/buildbot/all/builders/x86%20XP-4%203.1/builds/1591
Committed 2.7 backport in r87692.
--
___
Python tracker
<http://bugs.python.org/issue10
Alexander Belopolsky added the comment:
2.7 buildbot is green as well. Closing.
http://www.python.org/dev/buildbot/all/builders/x86%20XP-4%202.7
--
resolution: -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
_
Alexander Belopolsky added the comment:
Attached patch, issue8013-pre-check.diff, checks for year range before calling
system asctime and replaces a call to ctime with a asctime(localtime(..)).
--
stage: needs patch -> commit review
Added file: http://bugs.python.org/file20
Alexander Belopolsky added the comment:
Following Guido's response [1] to my inquiry on python-dev, I am attaching a
new patch that makes time.asctime and time.ctime produce longer than
24-character strings for large years.
[1] http://mail.python.org/pipermail/python-dev/2011-January/1
New submission from Alexander Belopolsky :
"""
> http://docs.python.org/library/time.html#time-y2kissues
> "Values 100–1899 are always illegal."
Why are these values illegal? The GNU libc accepts year in [1900-2^31; 2^31-1]
(tm_year in [-2147483648; 2147481747]).
Alexander Belopolsky added the comment:
Committed in r87736. I opened a separate issue #10827 to address the lower
bound.
--
resolution: -> fixed
stage: commit review -> committed/rejected
status: open -> closed
___
Python track
Alexander Belopolsky added the comment:
> The system libc would raise an error (return NULL) if it doesn't know
> how to format years older than 1900.
As experience with asctime has shown, system libc can do whatever it pleases
with out of range values including overrunning a
Alexander Belopolsky added the comment:
I am attaching a patch. While working on the patch, I noticed that although
time.accept2dyear is documented as boolean, the current code expects int and
treats any non-int including True as 0:
>>> time.accept2dyear = True; time.asctime((99,)
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
801 - 900 of 4095 matches
Mail list logo
