[issue10665] Expand unicodedata module documentation

Alexander Belopolsky added the comment: On Thu, Dec 9, 2010 at 6:10 PM, Martin v. Löwis wrote: .. > Please, one issue per report and checkin, The s/5.2/6.0/ issue is hardly worth a tracker ticket. I've committed these changes in r87159. (Sorry for the unrelated changes - reverte

[issue10665] Expand unicodedata module documentation

Changes by Alexander Belopolsky : -- nosy: +ezio.melotti, haypo, lemburg ___ Python tracker <http://bugs.python.org/issue10665> ___ ___ Python-bugs-list mailin

[issue10665] Expand unicodedata module documentation

Alexander Belopolsky added the comment: In issue10665.diff, I completed the character examples in the general categories table. -- Added file: http://bugs.python.org/file20002/issue10665.diff ___ Python tracker <http://bugs.python.org/issue10

[issue10665] Expand unicodedata module documentation

Alexander Belopolsky added the comment: On Fri, Dec 10, 2010 at 6:04 PM, Martin v. Löwis wrote: .. >> Why?  I thought "release early, release often" was a good thing. > > Create a branch for that, or post an issue on Rietveld. Martin, This is a documentation patch a

[issue9012] Separate compilation of time and datetime modules

Alexander Belopolsky added the comment: > it sounds like the patch is ready for commit. there are two pending patches here: time.diff - a hack that makes _time.c look like a module while it is not. add_time_to_vc8_build.diff - a patch for VC 8.0 project file. I don't like time.diff

[issue9232] Allow trailing comma in any function argument list.

Alexander Belopolsky added the comment: > In #10682, several committers indicated that they would prefer > not to change this. Issue #10682 has been open for less than 24 hours before it was rejected. In contrast, this issue was open after an almost week-long discussion on python-dev

[issue10700] python pickle.dumps AssertionError

Alexander Belopolsky added the comment: This looks like another duplicate of issue1062277. -- nosy: +belopolsky ___ Python tracker <http://bugs.python.org/issue10

[issue10700] python pickle.dumps AssertionError

Alexander Belopolsky added the comment: This is a known problem. See issues #1062277 and #9269. You can work around the issue by using a dict. I am attaching two test files. First, set-graph.py, reproduces the issue in 3.x and the second, dict-graph.py, contains a workaround

[issue10700] python pickle.dumps AssertionError

Changes by Alexander Belopolsky : Added file: http://bugs.python.org/file20037/dict-graph.py ___ Python tracker <http://bugs.python.org/issue10700> ___ ___ Python-bug

[issue10701] Error pickling a dict

New submission from Alexander Belopolsky : The work-around that I proposed for issue10700 does not work with Python 2.x: $ python2.7 dict-graph.py Vertex 0 -> 2, 1 Vertex 1 -> Vertex 2 -> Traceback (most recent call last): File "dict-graph.py", line 74, in

[issue10700] python pickle.dumps AssertionError

Alexander Belopolsky added the comment: It turns out that dict-graph.py does not work with python2.x, but that is a different problem, so I opened a separate issue for it. See issue10701. -- ___ Python tracker <http://bugs.python.org/issue10

[issue10541] regrtest.py -T broken

Alexander Belopolsky added the comment: Here is a simpler invocation that produces a similar error: $ ./python.exe -m test.regrtest -T test_trace test_pkg ... IOError: [Errno 2] No such file or directory: '/var/folders/qs/qsqFUI2xFUKG+9CTf4z7pU+++TI/-Tmp-/tmpy1iyp7/t4/sub/__init

[issue10587] Document the meaning of str methods

Alexander Belopolsky added the comment: I am attaching a patch that expands the documentation of isalnum, isalpha, isdecimal, isdigit, isnumeric, islower, isupper, and isspace. I did not change isidentifier or isprintable because their docs were already complete. I also left out istitle

[issue10702] bytes and bytearray methods are not documented

New submission from Alexander Belopolsky : Library reference manual has a section dedicated to string methods [1], but similar methods of bytes and bytearray types are not documented. Adding two new sections would probably be too repetitious, so I wonder if it would make sense to add notes

[issue10703] Regex 0.1.20101210

Alexander Belopolsky added the comment: Regex 0.1.20101210 is not part of the standard Python distribution, so this bug report is invalid. -- nosy: +belopolsky resolution: -> invalid status: open -> closed superseder: -> Regexp 2.7 (modifications to current

[issue10704] Regex 0.1.20101210 Python 3.1 install problem Mac OS X 10.6.5

Alexander Belopolsky added the comment: Regex 0.1.20101210 is not part of the standard Python distribution, so this bug report is invalid. See issue2636 for the development status of regex. -- nosy: +belopolsky resolution: -> invalid status: open -> closed superseder: -> R

[issue10704] Regex 0.1.20101210 Python 3.1 install problem Mac OS X 10.6.5

Alexander Belopolsky added the comment: On Tue, Dec 14, 2010 at 1:27 PM, Steve Moran wrote: .. > Yeah, it's not immediately clear how to bring this up at > > http://bugs.python.org/issue2636 > This is the URL listed as the home page for regex 0.1.20101210 on PyPI [1], so I as

[issue10704] Regex 0.1.20101210 Python 3.1 install problem Mac OS X 10.6.5

Alexander Belopolsky added the comment: FWIW, I was able to install Regex 0.1.20101210 on OSX 10.6.4, Developer Information: Version: 3.2 (10M2003) Location: /Developer Applications: Xcode:3.2.1 (1613) Interface Builder:3.2.1 (740) Instruments: 2.0.1 (1096

[issue10704] Regex 0.1.20101210 Python 3.1 install problem Mac OS X 10.6.5

Alexander Belopolsky added the comment: > If you build it yourself, you have other options. Yes, my python3.1 is from MacPorts. -- ___ Python tracker <http://bugs.python.org/issu

[issue10541] regrtest.py -T broken

Alexander Belopolsky added the comment: I am attaching a patch that fixes write_results() and makes test_trace tests restore the tracefunc after they run. This fixes generation off the coverage files, but many tests still fail when traced. -- keywords: +patch stage: needs patch

[issue10541] regrtest.py -T broken

Changes by Alexander Belopolsky : -- nosy: +eli.bendersky, terry.reedy ___ Python tracker <http://bugs.python.org/issue10541> ___ ___ Python-bugs-list mailin

[issue3446] center, ljust and rjust are inconsistent with unicode parameters

Changes by Alexander Belopolsky : -- status: pending -> closed ___ Python tracker <http://bugs.python.org/issue3446> ___ ___ Python-bugs-list mailing list Un

[issue10702] bytes and bytearray methods are not documented

Alexander Belopolsky added the comment: > I was persuaded there was already a bug open with a patch adding > bytes and bytearray in the sequence methods table, but I can’t find it. I can't find it either, but this issue is different. I propose renaming "String Methods"

[issue10718] Idle crashes on OSX when source is saved

Alexander Belopolsky added the comment: > After entering my code What code did you enter? Which window did you enter it to? > I am prompted to save what exactly did you do before you were "prompted"? What did the "prompt" look like. Can you post the screen sh

[issue10718] Idle crashes on OSX when source is saved

Alexander Belopolsky added the comment: Same behavior when starting /Applications/Python 2.7/IDLE.app in finder. -- ___ Python tracker <http://bugs.python.org/issue10

[issue10716] Modernize pydoc to use CSS

Alexander Belopolsky added the comment: I believe Ron has done something along these lines already. See issue2001. Committed css file is empty, (see r86971) but I am adding Ron to "nosy" in case he has something in the pipeline. -- nosy: +belopolsky

[issue10716] Modernize pydoc to use CSS

Alexander Belopolsky added the comment: See also the calendar module for an example of a "modern" html. -- ___ Python tracker <http://bugs.python.o

[issue10254] unicodedata.normalize('NFC', s) regression

Alexander Belopolsky added the comment: Adding an assert as shown in the diff below, makes it easy to reproduce the crash in py3k branch: $ ./python.exe crash.py Assertion failed: (cskipped < 20), function nfc_nfkc, file Modules/unicodedata.c, line 714. Abort trap I am attaching jhalcro

[issue10254] unicodedata.normalize('NFC', s) regression

Alexander Belopolsky added the comment: The logic suggested by Martin in msg120018 looks right to me, but the whole code seems to be unnecessarily complex. (And comb1==comb may need to be changed to comb1>=comb.) I don't understand why linear search through "skipped" ar

[issue10542] Py_UNICODE_NEXT and other macros for surrogates

Changes by Alexander Belopolsky : -- nosy: +doerwalter ___ Python tracker <http://bugs.python.org/issue10542> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue10542] Py_UNICODE_NEXT and other macros for surrogates

Alexander Belopolsky added the comment: On Fri, Dec 10, 2010 at 6:09 PM, Daniel Stutzbach wrote: .. > The second check for surrogates in Py_UNICODE_PUT_NEXT is necessary, unless > you can prove that > Py_UNICODE_SOME_TRANSFORMATION will never transform characters < 0x1 into

[issue10254] unicodedata.normalize('NFC', s) regression

Alexander Belopolsky added the comment: Attached patch, issue10254.diff, is essentially Martin's code from msg120018 and Part3 tests from NormalizationTest.txt. Since this bug exposes a buffer overflow condition, I think it qualifies as a security issue, so I am adding 2.6 to ver

[issue2736] datetime needs an "epoch" method

Alexander Belopolsky added the comment: On Fri, Dec 17, 2010 at 9:18 AM, R. David Murray wrote: > > R. David Murray added the comment: > > Alexander, I agree with Velko in that it isn't obvious to me how the addition > of localtime > would answer the desire

[issue10254] unicodedata.normalize('NFC', s) regression

Alexander Belopolsky added the comment: On Fri, Dec 17, 2010 at 3:47 AM, Martin v. Löwis wrote: .. > The worst case (wrt. cskipped) is the maximum number of characters that > can get combined into a single base character. It used to be (and I > hope still is) 20 (decomposition

[issue2736] datetime needs an "epoch" method

Alexander Belopolsky added the comment: On Fri, Dec 17, 2010 at 12:17 PM, Antoine Pitrou wrote: .. >> 1. Different application may need different epoch and retained >> precision depends on the choice of the epoch. > > But then why does fromtimestamp() exist? A bett

[issue2736] datetime needs an "epoch" method

Alexander Belopolsky added the comment: On Fri, Dec 17, 2010 at 1:17 PM, Antoine Pitrou wrote: .. >> A better question is why datetime.utcfromtimestamp(s) exists given >> that it is actually longer than equivalent EPOCH + timedelta(0, s)? > > ??? EPOCH is not even a consta

[issue10254] unicodedata.normalize('NFC', s) regression

Alexander Belopolsky added the comment: On Fri, Dec 17, 2010 at 2:08 PM, Martin v. Löwis wrote: .. >> As far as I (and a two-line script) can tell >> the maximum length of a canonical decomposition of a character is 4. > > Even better - so allowing for 20 characters should

[issue2736] datetime needs an "epoch" method

Alexander Belopolsky added the comment: On Fri, Dec 17, 2010 at 2:35 PM, Antoine Pitrou wrote: .. > I don't think the "time" module can be named "higher level", and it > still handles such timestamps. > >> datetime(1970, 1, 1) + timedelta(seconds=s) >

[issue2736] datetime needs an "epoch" method

Changes by Alexander Belopolsky : -- nosy: -Alexander.Belopolsky versions: +Python 3.3 -Python 3.2 ___ Python tracker <http://bugs.python.org/issue2736> ___ ___

[issue2736] datetime needs an "epoch" method

Alexander Belopolsky added the comment: On Fri, Dec 17, 2010 at 3:26 PM, Antoine Pitrou wrote: .. > >> Yes, UTC not being a proper acronym in any human language is one >> problem, > > Ok. Too bad you don't live on the same planet than most of us. I bail > out. S

[issue10557] Malformed error message from float()

Changes by Alexander Belopolsky : -- versions: +Python 3.1 ___ Python tracker <http://bugs.python.org/issue10557> ___ ___ Python-bugs-list mailing list Unsub

[issue10254] unicodedata.normalize('NFC', s) regression

Alexander Belopolsky added the comment: Attached patch, issue10254a.diff, adds the OP's cases to test_unicodedata and changes the code as I suggested in msg124173 because ISTM that comb >= comb1 matches the pr-29 definition: """ D2'. In any character sequence b

[issue10715] uninformative error message

Changes by Alexander Belopolsky : Removed file: http://bugs.python.org/file20125/unnamed ___ Python tracker <http://bugs.python.org/issue10715> ___ ___ Python-bugs-list m

[issue10254] unicodedata.normalize('NFC', s) regression

Alexander Belopolsky added the comment: On Mon, Dec 20, 2010 at 2:50 PM, Alexander Belopolsky wrote: .. > Unfortunately, all tests pass with either comb >= comb1 or comb == comb1, so > before > I commit, I would like to figure out the test case that would properly > exe

[issue10254] unicodedata.normalize('NFC', s) regression

Alexander Belopolsky added the comment: In the new patch, issue10254b.diff, I've added a test that would crash unpatched code: >>> unicodedata.normalize('NFC', 'C̸C̸C̸C̸C̸C̸C̸C̸C̸C̸C̸C̸C̸C̸C̸C̸C̸C̸C̸C̸Ç') Segmentation fault Martin, I still feel uneasy a

[issue10754] os.path.isfile doesn't work with some greek characters

Alexander Belopolsky added the comment: Just a random thought (no, I don't know anything about Windows): there are two "mu" characters: GREEK SMALL LETTER MU (μ) and MICRO SIGN (µ). Normalization turns one into the other: >>> from unicodedata import * >>>

[issue8863] Display Python backtrace on SIGSEGV, SIGFPE and fatal error

Alexander Belopolsky added the comment: Stephen, I wonder if you would have comments on this. As far as I know emacs installs SEGV handlers similar to the ones proposed here. How well do they work? Does it really help users to produce meaningful bug reports? -- nosy: +belopolsky

[issue10254] unicodedata.normalize('NFC', s) regression

Alexander Belopolsky added the comment: Committed to py3k in revision 87442. -- versions: -Python 3.2 ___ Python tracker <http://bugs.python.org/issue10

[issue8863] Display Python backtrace on SIGSEGV, SIGFPE and fatal error

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

[issue10587] Document the meaning of str methods

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

[issue6280] calendar.timegm() belongs in time module, next to time.gmtime()

Changes by Alexander Belopolsky : -- status: pending -> closed ___ Python tracker <http://bugs.python.org/issue6280> ___ ___ Python-bugs-list mailing list Un

[issue9063] TZ examples in datetime.rst are incorrect

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

[issue2636] Regexp 2.7 (modifications to current re 2.2.2)

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

[issue10767] Lib/test/crashers/README is out of date

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

[issue10254] unicodedata.normalize('NFC', s) regression

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

[issue10785] parser: store the filename as an unicode object

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

[issue10542] Py_UNICODE_NEXT and other macros for surrogates

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)++)

[issue10542] Py_UNICODE_NEXT and other macros for surrogates

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

[issue10542] Py_UNICODE_NEXT and other macros for surrogates

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

[issue10542] Py_UNICODE_NEXT and other macros for surrogates

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

[issue10542] Py_UNICODE_NEXT and other macros for surrogates

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

[issue10542] Py_UNICODE_NEXT and other macros for surrogates

Alexander Belopolsky added the comment: The example in my previous message should have been: >>> '\U0001' == '\uD800\uDC00' True -- ___ Python tracker <h

[issue10542] Py_UNICODE_NEXT and other macros for surrogates

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

[issue10542] Py_UNICODE_NEXT and other macros for surrogates

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

[issue10542] Py_UNICODE_NEXT and other macros for surrogates

Changes by Alexander Belopolsky : Added file: http://bugs.python.org/file20190/issue10542a.diff ___ Python tracker <http://bugs.python.org/issue10542> ___ ___ Python-bug

[issue10542] Py_UNICODE_NEXT and other macros for surrogates

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

[issue8271] str.decode('utf8', 'replace') -- conformance with Unicode 5.2.0

Changes by Alexander Belopolsky : -- nosy: +belopolsky ___ Python tracker <http://bugs.python.org/issue8271> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue8821] Range check on unicode repr

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

[issue3232] Wrong str->bytes conversion in Lib/encodings/idna.py

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(

[issue3232] Wrong str->bytes conversion in Lib/encodings/idna.py

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

[issue10542] Py_UNICODE_NEXT and other macros for surrogates

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

[issue10542] Py_UNICODE_NEXT and other macros for surrogates

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

[issue6632] Include more fullwidth chars in the decimal codec

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

[issue8013] time.asctime segfaults when given a time in the far future

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

[issue8013] time.asctime segfaults when given a time in the far future

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

[issue10807] `b'dGVzdA==\n'.decode('base64')` raise exception

Changes by Alexander Belopolsky : -- nosy: +belopolsky ___ Python tracker <http://bugs.python.org/issue10807> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue8013] time.asctime segfaults when given a time in the far future

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

[issue8013] time.asctime segfaults when given a time in the far future

Alexander Belopolsky added the comment: Committed in revision 87648. -- ___ Python tracker <http://bugs.python.org/issue8013> ___ ___ Python-bugs-list mailin

[issue8013] time.asctime segfaults when given a time in the far future

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

[issue8013] time.asctime segfaults when given a time in the far future

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 &

[issue8013] time.asctime segfaults when given a time in the far future

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

[issue8013] time.asctime segfaults when given a time in the far future

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

[issue8013] time.asctime segfaults when given a time in the far future

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

[issue8013] time.asctime segfaults when given a time in the far future

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

[issue8013] time.asctime segfaults when given a time in the far future

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

[issue8013] time.asctime segfaults when given a time in the far future

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

[issue10814] assertion failed on Windows buildbots

Changes by Alexander Belopolsky : -- assignee: -> belopolsky ___ Python tracker <http://bugs.python.org/issue10814> ___ ___ Python-bugs-list mailing list Un

[issue10814] assertion failed on Windows buildbots

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-&

[issue10814] assertion failed on Windows buildbots

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

[issue10814] assertion failed on Windows buildbots

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

[issue10814] assertion failed on Windows buildbots

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. -- __

[issue10814] assertion failed on Windows buildbots

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

[issue10814] assertion failed on Windows buildbots

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

[issue10814] assertion failed on Windows buildbots

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 _

[issue8013] time.asctime segfaults when given a time in the far future

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

[issue8013] time.asctime segfaults when given a time in the far future

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

[issue10827] Functions in time module should support year < 1900 when accept2dyear = 0

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]).

[issue8013] time.asctime segfaults when given a time in the far future

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

[issue10827] Functions in time module should support year < 1900 when accept2dyear = 0

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

[issue10827] Functions in time module should support year < 1900 when accept2dyear = 0

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,)

<    3   4   5   6   7   8   9   10   11   12   >