[issue7372] Regression in pstats

Alexander Belopolsky added the comment: I am attaching a simple fix. The test for data format could be taken out of the loop, but it is probably not worth complicating the logic. In any case the real issue is whether profile and cProfile should produce compatible output or not

[issue7372] Regression in pstats

Changes by Alexander Belopolsky : -- versions: +Python 3.1, Python 3.2 ___ Python tracker <http://bugs.python.org/issue7372> ___ ___ Python-bugs-list mailin

[issue7376] FAIL: Doctest: __main__.DebugRunner

Alexander Belopolsky added the comment: Apparently this was introduced with r51625 : r51625 | guido.van.rossum | 2006-08-26 16:37:44 -0400 (Sat, 26 Aug 2006) | 4 lines Inspired by SF patch #860326, make the exception formatting by traceback.py be closer to the built-in formatting. A few

[issue7372] Regression in pstats

Alexander Belopolsky added the comment: It would be fairly easy to change format before dumping stats to disk, but unfortunately Profile does not encapsulate it's run-time data and changing its format would be a mess. Of course, one can hack around that by turning Profile.stats into a com

[issue2706] datetime: define division timedelta/timedelta

Alexander Belopolsky added the comment: On Tue, Mar 10, 2009 at 5:15 PM, Tennessee Leeuwenburg wrote: .. > 2) Allow divmod, the operator '%', to be applied to two timedeltas (e.g. > td1 % td2). I think there is some debate here about whether the return > value be an integer

[issue1676121] Problem linking to readline lib on x86(64) Solaris

Alexander Belopolsky added the comment: I don't have a Solaris box to test at the moment, but I believe the following commit fixed this issue: r66283 | gregory.p.smith | 2008-09-07 01:15:18 -0400 (Sun, 07 Sep 2008

[issue1424152] urllib/urllib2: HTTPS over (Squid) Proxy fails

Changes by Alexander Solovyov : -- nosy: +piranha ___ Python tracker <http://bugs.python.org/issue1424152> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue3959] Add Google's ipaddr.py to the stdlib

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

[issue8692] Use divide-and-conquer for faster factorials

Changes by Alexander Belopolsky : Removed file: http://bugs.python.org/file17310/factorial.py ___ Python tracker <http://bugs.python.org/issue8692> ___ ___ Python-bug

[issue8692] Use divide-and-conquer for faster factorials

Changes by Alexander Belopolsky : Removed file: http://bugs.python.org/file17312/factorial3.py ___ Python tracker <http://bugs.python.org/issue8692> ___ ___ Python-bug

[issue8692] Use divide-and-conquer for faster factorials

Alexander Belopolsky added the comment: I agree, recursive version of partial_product is much simpler to follow. While allocation of all numbers can be avoided in iterative version, doing so would further complicate code with little benefit. I still believe, however that an iterative

[issue8692] Use divide-and-conquer for faster factorials

Alexander Belopolsky added the comment: > I still believe, however that an iterative version can benefit .. s/iterative/recursive/ -- ___ Python tracker <http://bugs.python.org/iss

[issue8692] Use divide-and-conquer for faster factorials

Alexander Belopolsky added the comment: Mark, It is always a pleasure to read your algorithm descriptions! Just a few comments: - It would be nice if a pure python implementation would make it somewhere in the code base. Maybe it can be placed in comments in C file or added to the test

[issue8692] Use divide-and-conquer for faster factorials

Alexander Belopolsky added the comment: Some more ... - Mark's notes talk about "odd-part-of-factorial". It would be clearer if r variable in math_factorial() was called odd_part. - I would also rename nminusnumbits to ntwos or something else that explains what it is rather

[issue8692] Use divide-and-conquer for faster factorials

Alexander Belopolsky added the comment: On Sat, May 15, 2010 at 6:32 AM, Mark Dickinson wrote: > New patch (factorial3.patch) addressing all of Alexander's points except the > one about including Python source somewhere. Thanks for making the changes. I think we converged to a

[issue8692] Use divide-and-conquer for faster factorials

Alexander Belopolsky added the comment: There is one place in the notes still referring to factorial_part_product. -- nosy: +Alexander.Belopolsky ___ Python tracker <http://bugs.python.org/issue8

[issue8692] Use divide-and-conquer for faster factorials

Alexander Belopolsky added the comment: Sorry for terseness. Sending it from my phone. The line was in factorial4.patch: + * The factorial_partial_product function computes the product of all odd j in >> > > Hmm. I can't find it. Can you be more specific? > >

[issue8692] Use divide-and-conquer for faster factorials

Alexander Belopolsky added the comment: s/partial_product/odd_part/ It looks like you made this change in some places but not all. On May 15, 2010, at 11:16 AM, Mark Dickinson wrote: > > Mark Dickinson added the comment: > > Okay, thanks. I'm still not seeing what&

[issue8692] Use divide-and-conquer for faster factorials

Alexander Belopolsky added the comment: Sorry I didn't realize that ... -- ___ Python tracker <http://bugs.python.org/issue8692> ___ ___ Python-bugs-list m

[issue1800] ctypes callback fails when called in Python with array argument

Changes by Alexander Belopolsky : -- nosy: +belopolsky stage: -> unit test needed versions: +Python 3.2, Python 3.3 -Python 2.5 ___ Python tracker <http://bugs.python.org/iss

[issue1800] ctypes callback fails when called in Python with array argument

Alexander Belopolsky added the comment: Attached patch fixes the issue, but feels a little bit like a band-aid. I think making array arguments "decay" into pointers is the right solution, but I am not sure this should be done when prototype is created or when it is called. If py

[issue1800] ctypes callback fails when called in Python with array argument

Changes by Alexander Belopolsky : -- keywords: +needs review stage: unit test needed -> patch review ___ Python tracker <http://bugs.python.org/issue1800> ___ _

[issue1289118] timedelta multiply and divide by floating point

Changes by Alexander Belopolsky : -- assignee: -> belopolsky nosy: +belopolsky -Alexander.Belopolsky ___ Python tracker <http://bugs.python.org/issue1

[issue1289118] timedelta multiply and divide by floating point

Alexander Belopolsky added the comment: dt.diff does not apply to current SVN version anymore. I am attaching a quick update that does not change the actual calculation performed. See issue1289118-py3k.diff. I am still -1 for the reason I stated before, but I would like to review a

[issue1436346] yday in datetime module

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

[issue1436346] yday in datetime module

Alexander Belopolsky added the comment: I think this should be rejected. The OP's premise was that t.timetuple()[7] was unreadable, but in the modern python, the same can be written as t.timetuple().tm_yday. The later is only slightly less readable than the proposed t.yday(). Fo

[issue2736] datetime needs an "epoch" method

Alexander Belopolsky added the comment: On Fri, May 21, 2010 at 7:26 AM, STINNER Victor wrote: .. >>  ... If the tzinfo of the datetime object does not match the >> system TZ used by mktime, the result will be quite misleading. > > Can you suggest a possible fix to take ca

[issue2736] datetime needs an "epoch" method

Alexander Belopolsky added the comment: On Fri, May 21, 2010 at 7:37 AM, Antoine Pitrou wrote: .. > I agree with Victor that the APIs need improving, even if it involves > providing obvious replacements of obscure one-liners. While I agree that the datetime API can be improved, I don&#

[issue2736] datetime needs an "epoch" method

Changes by Alexander Belopolsky : -- assignee: -> belopolsky nosy: -Alexander.Belopolsky stage: -> unit test needed versions: +Python 3.2 -Python 2.6, Python 3.0 ___ Python tracker <http://bugs.python.org/

[issue2736] datetime needs an "epoch" method

Alexander Belopolsky added the comment: On Fri, May 21, 2010 at 11:20 AM, Alexander Belopolsky wrote: .. > I believe it should be something like this: > > from claendar import timegm s/claendar/calendar/, of course. -- nosy: +Alexander.B

[issue5288] tzinfo objects with sub-minute offsets are not supported (e.g. UTC+05:53:28)

Changes by Alexander Belopolsky : -- assignee: -> belopolsky nosy: +belopolsky stage: -> unit test needed type: -> feature request versions: +Python 3.2 -Python 2.7, Python 3.1 ___ Python tracker <http://bugs.python.o

[issue2736] datetime needs an "epoch" method

Alexander Belopolsky added the comment: On Fri, May 21, 2010 at 12:20 PM, Antoine Pitrou wrote: .. > Well, for example, the datetime module encourages you to use "aware" datetime > objects (rather than so-called "naive" objects), > but there isn't a single fa

[issue5094] datetime lacks concrete tzinfo impl. for UTC

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

[issue1436346] yday in datetime module

Alexander Belopolsky added the comment: On Thu, May 20, 2010 at 7:27 PM, Antoine Pitrou wrote: > >> .. The OP's premise was that >> t.timetuple()[7] was unreadable, but in the modern python, the same >> can be written as t.timetuple().tm_yday. > > Could I sugg

[issue1436346] yday in datetime module

Changes by Alexander Belopolsky : -- nosy: +georg.brandl ___ Python tracker <http://bugs.python.org/issue1436346> ___ ___ Python-bugs-list mailing list Unsub

[issue1436346] yday in datetime module

Alexander Belopolsky added the comment: Attaching a documentation patch. -- Added file: http://bugs.python.org/file17446/issue1436346-doc.diff ___ Python tracker <http://bugs.python.org/issue1436

[issue1436346] yday in datetime module

Changes by Alexander Belopolsky : -- assignee: belopolsky -> components: +Documentation keywords: +needs review versions: +Python 2.7 ___ Python tracker <http://bugs.python.org/issue1

[issue8810] TZ offset description is unclear in docs

New submission from Alexander Belopolsky : >From ><http://docs.python.org/dev/py3k/library/datetime.html#datetime.tzinfo.utcoffset>: """ tzinfo.utcoffset(self, dt) Return offset of local time from UTC, in minutes east of UTC. """ This su

[issue5288] tzinfo objects with sub-minute offsets are not supported (e.g. UTC+05:53:28)

Alexander Belopolsky added the comment: As far as I can tell, the TZ offset code can be simplified by eliminating conversion from timedelta to int and back in utcoffset() and dst() methods of time and datetime objects. The only reason for the restriction that I can think of is that some text

[issue1289118] timedelta multiply and divide by floating point

Alexander Belopolsky added the comment: I am attaching a patch that implements Mark's timedelta_arith.py algorithms in C. With rounding well defined, I am close to withdrawing my opposition to supporting mixed timedelta with float operations. There is still one issue that I belie

[issue1289118] timedelta multiply and divide by floating point

Alexander Belopolsky added the comment: It looks like we have a consensus on the rounding mode. Note, however that timedelta constructor rounds away from zero at least on Intel/MacOS X: [-10, -9, -8, -7, -6, -5, -4, -3, -2, -1, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10] Should this be considered a bug

[issue1289118] timedelta multiply and divide by floating point

Alexander Belopolsky added the comment: Indeed. Here is what I intended: """ >>> 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]

[issue5094] datetime lacks concrete tzinfo impl. for UTC

Alexander Belopolsky added the comment: I have two questions about the proposed implementation: 1. Why not follow pytz lead and expose an instance of UTC rather than the UTC class itself? 2. Is there a real need to add a boolean argument to utcnow()? I think timedelta.now(UTC()) or with

[issue5094] datetime lacks concrete tzinfo impl. for UTC

Alexander Belopolsky added the comment: On Mon, May 24, 2010 at 11:06 PM, Rafe Kaplan wrote: .. > On 2, we had discussions about how to pass parameters in to utcnow that we > DID record.  When I > suggested it, Brett said: > >  "...using a boolean flag over an argumen

[issue5094] datetime lacks concrete tzinfo impl. for UTC

Alexander Belopolsky added the comment: > We didn't do a singleton because I don't like singletons. =) Plus they > muck with isinstance/issubclass if you don't expose the class. I am not sure what you mean by "muck with." Why would anyone want to subclass UTC

[issue1289118] timedelta multiply and divide by floating point

Alexander Belopolsky added the comment: > By the way, does your patch do the right thing for > timedelta(microseconds=1) / -4.0 No. >>> timedelta(microseconds=1) / -4.0 datetime.timedelta(-1, 86399, 99) (I just copied your python algorithm ...) I will merge with issue

[issue1289118] timedelta multiply and divide by floating point

Alexander Belopolsky added the comment: Attaching a combined issue1289118 + issue8817 patch. Datetime code now uses issue8817's _PyLong_Divmod_Near. -- Added file: http://bugs.python.org/file17460/issue1289118+issue8817-nodoc.diff ___ P

[issue8817] Expose round-to-nearest division algorithm in Objects/longobject.c

Alexander Belopolsky added the comment: Just a few nitpicks on the patch (in increasing pickiness): 1. Any reason to prefer PyTuple_SetItem to PyTuple_SET_ITEM at the end of _PyLong_Divmod_Near? You are filling a brand new tuple, so PyTuple_SET_ITEM seems to be more appropriate. 2. temp

[issue5094] datetime lacks concrete tzinfo impl. for UTC

Alexander Belopolsky added the comment: On Tue, May 25, 2010 at 5:45 AM, Antoine Pitrou wrote: .. > I also agree with Brett that a singleton looks rather unnecessary (it > also look quite C++/Java-esque to me). > I still don't understand your aversion to singletons and you did n

[issue665194] datetime-RFC2822 roundtripping

Changes by Alexander Belopolsky : -- assignee: -> belopolsky nosy: +belopolsky ___ Python tracker <http://bugs.python.org/issue665194> ___ ___ Python-bugs-lis

[issue6641] strptime doesn't support %z format ?

Alexander Belopolsky added the comment: If concrete tzinfo subclass is added to datetime module (see issue5094), it will become feasible to meaningfully parse timezone information. -- assignee: -> belopolsky ___ Python tracker &l

[issue5094] datetime lacks concrete tzinfo impl. for UTC

Alexander Belopolsky added the comment: On Mon, May 24, 2010 at 11:06 PM, Rafe Kaplan wrote: .. > I had originally thought of doing the class, and then having constants > associated with it: > >  UTC.UTC0 > > Eventually if we support multiple timezones: > >  UTC.UTC1

[issue5094] datetime lacks concrete tzinfo impl. for UTC

Alexander Belopolsky added the comment: .. Thanks for the explanation. I realize that I should not have used the s-word. :-) In fact I only wanted a module level constant utc = UTC() and did not care much about other UTC class instances and whether any are permitted or easy to create. Well

[issue5094] datetime lacks concrete tzinfo impl. for UTC

Alexander Belopolsky added the comment: Roundup bug bites again. Reposting via web: - On Tue, May 25, 2010 at 5:35 PM, Brett Cannon wrote: > > The singleton dislike from Antoine and me is that they are generally just not > liked in the stdlib. .. Thanks for the explanation.

[issue5094] datetime lacks concrete tzinfo impl. for UTC

Alexander Belopolsky added the comment: Note that Brett has already mentioned backward compatibility issues, but suggested that "[adding tz_aware argument may provide] a transition plan to make utcnow() always return a timezone-aware datetime object." [msg106413] I would say,

[issue8817] Expose round-to-nearest division algorithm in Objects/longobject.c

Alexander Belopolsky added the comment: Looking at Py_DECREF(one); result = PyTuple_New(2); if (result == NULL) goto error; .. error: Py_XDECREF(one); If PyTuple_New fails, wouldn't it result in one being DECREF&#x

[issue1289118] timedelta multiply and divide by floating point

Alexander Belopolsky added the comment: Attaching a new patch with documentation changes, additional tests, updated issue8817 patch and a reference leak fix. -- Added file: http://bugs.python.org/file17464/issue1289118+issue8817-withdoc.diff

[issue5094] datetime lacks concrete tzinfo impl. for UTC

Alexander Belopolsky added the comment: Brett: "[utcnow] should at least get deprecated with a message saying that people should be using ``now(utc)``" Yes, I believe all utcxxx methods of datetime are a kludge due to the lack of concrete UTC tzinfo: utcfromtimestamp() -> from

[issue5023] Segfault in datetime.time.strftime("%z")

Changes by Alexander Belopolsky : -- assignee: -> belopolsky nosy: +belopolsky ___ Python tracker <http://bugs.python.org/issue5023> ___ ___ Python-bugs-lis

[issue7584] datetime.rfcformat() for Date and Time on the Internet

Changes by Alexander Belopolsky : -- assignee: -> belopolsky nosy: +belopolsky ___ Python tracker <http://bugs.python.org/issue7584> ___ ___ Python-bugs-lis

[issue1100942] Add datetime.time.strptime and datetime.date.strptime

Changes by Alexander Belopolsky : -- assignee: -> belopolsky nosy: +belopolsky -Alexander.Belopolsky ___ Python tracker <http://bugs.python.org/issue1

[issue5434] datetime.monthdelta

Alexander Belopolsky added the comment: MonthDelta has been published on PyPI and there was no activity on this issue since then. I conclude that there is little support for including this in stdlib. I am marking this as "rejected" and setting the status to pending. I will close

[issue5094] datetime lacks concrete tzinfo impl. for UTC

Alexander Belopolsky added the comment: I have no opinion on the first question. I would be fine with a simple "soft" deprecation where we simply add a note in documentation warning that these methods create naive datetime instances and it is preferable to use aware variants p

[issue5516] equality not symmetric for subclasses of datetime.date and datetime.datetime

Alexander Belopolsky added the comment: I am leaning towards "won't fix". Any objections? -- assignee: -> belopolsky nosy: +belopolsky -Alexander.Belopolsky versions: -Python 2.5, Python 2.6 ___ Python tracker <http://bugs

[issue8005] datetime's comparison methods do not return NotImplemented when they should

Alexander Belopolsky added the comment: Any objections to closing this as "won't fix"? -- nosy: +belopolsky -Alexander.Belopolsky ___ Python tracker <http://bugs.py

[issue7150] datetime operations spanning MINYEAR give bad results

Changes by Alexander Belopolsky : -- assignee: -> belopolsky nosy: +belopolsky -Alexander.Belopolsky ___ Python tracker <http://bugs.python.org/iss

[issue5476] datetime: timedelta(minutes = i) silently fails with numpy.int32 input

Changes by Alexander Belopolsky : -- assignee: -> belopolsky nosy: +belopolsky ___ Python tracker <http://bugs.python.org/issue5476> ___ ___ Python-bugs-lis

[issue1647654] No obvious and correct way to get the time zone offset

Changes by Alexander Belopolsky : -- assignee: -> belopolsky nosy: +belopolsky ___ Python tracker <http://bugs.python.org/issue1647654> ___ ___ Python-bugs-lis

[issue1667546] Time zone-capable variant of time.localtime

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

[issue1667546] Time zone-capable variant of time.localtime

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

[issue5516] equality not symmetric for subclasses of datetime.date and datetime.datetime

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

[issue8005] datetime's comparison methods do not return NotImplemented when they should

Changes by Alexander Belopolsky : -- resolution: -> out of date status: open -> pending ___ Python tracker <http://bugs.python.org/issue8005> ___ ___ Pyth

[issue7150] datetime operations spanning MINYEAR give bad results

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

[issue6608] asctime causing python to crash

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

[issue6608] asctime causing python to crash

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

[issue6608] asctime causing python to crash

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

[issue7879] Too narrow platform check in test_datetime

Changes by Alexander Belopolsky : -- assignee: -> belopolsky stage: -> commit review ___ Python tracker <http://bugs.python.org/issue7879> ___ ___ Pyth

[issue7879] Too narrow platform check in test_datetime

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

[issue7879] Too narrow platform check in test_datetime

Alexander Belopolsky added the comment: OK, I'll commit it then. -- resolution: -> accepted ___ Python tracker <http://bugs.python.org/issue7879> ___ _

[issue7879] Too narrow platform check in test_datetime

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:

[issue7879] Too narrow platform check in test_datetime

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

[issue7879] Too narrow platform check in test_datetime

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

[issue7879] Too narrow platform check in test_datetime

Alexander Belopolsky added the comment: SkipIf patch committed in r81559 (trunk) and r81560 (py3k). -- ___ Python tracker <http://bugs.python.org/issue7

[issue8822] datetime naive and aware types should have a well-defined definition that can be cross-referenced

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

[issue8834] Define order of Misc/ACKS entries

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

[issue8834] Define order of Misc/ACKS entries

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

[issue7150] datetime operations spanning MINYEAR give bad results

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

[issue1289118] timedelta multiply and divide by floating point

Changes by Alexander Belopolsky : -- stage: -> commit review Added file: http://bugs.python.org/file17476/issue1289118-withdoc.diff ___ Python tracker <http://bugs.python.org/issue1

[issue2394] [Py3k] Finish the memoryview object implementation

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

[issue4653] Patch to fix typos for Py3K

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

[issue4653] Patch to fix typos for Py3K

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.

[issue2651] Strings passed to KeyError do not round trip

Changes by Alexander Belopolsky : -- assignee: -> belopolsky nosy: +belopolsky ___ Python tracker <http://bugs.python.org/issue2651> ___ ___ Python-bugs-lis

[issue2651] Strings passed to KeyError do not round trip

Changes by Alexander Belopolsky : -- versions: +Python 3.2 -Python 2.5 ___ Python tracker <http://bugs.python.org/issue2651> ___ ___ Python-bugs-list mailin

[issue2920] Patch to print symbolic value or errno in EnvironmentError.__str__()

Changes by Alexander Belopolsky : -- assignee: -> belopolsky nosy: +belopolsky ___ Python tracker <http://bugs.python.org/issue2920> ___ ___ Python-bugs-lis

[issue762920] API Functions for PyArray

Alexander Belopolsky added the comment: Is there still any interest in pursuing this? Raymond? -- ___ Python tracker <http://bugs.python.org/issue762

[issue3196] Option in pydoc to show docs from private methods

Changes by Alexander Belopolsky : -- assignee: -> belopolsky nosy: +belopolsky ___ Python tracker <http://bugs.python.org/issue3196> ___ ___ Python-bugs-lis

[issue2920] Patch to print symbolic value or errno in EnvironmentError.__str__()

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

[issue7879] Too narrow platform check in test_datetime

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

[issue8860] Rounding in timedelta constructor is inconsistent with that in timedelta arithmetics

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

[issue1289118] timedelta multiply and divide by floating point

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 ___

<    22   23   24   25   26   27   28   29   30   31   >