[issue2804] Integer right shift raises OverflowError when second operand is large

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: I still don't think the improvement in observable behavior is worth the cost of additional code (and as Alexander observes, the patch in file10234 is incorrect in boundary cases). __ Tracker <[EMAIL PROTECTED]

[issue2295] cPickle corner case - docs or bug?

Changes by Alexandre Vassalotti <[EMAIL PROTECTED]>: -- nosy: +alexandre.vassalotti __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list maili

[issue2782] datetime/date strftime() method and time.strftime() inconsistency

Changes by Alexandr Zamaraev <[EMAIL PROTECTED]>: -- nosy: +shura_zam __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing list Unsubs

[issue2789] Comparsion datetime objects with None

Terry J. Reedy <[EMAIL PROTECTED]> added the comment: You actually have it backwards ;-) The arbitrary responses to nonsensical cross-class order comparisons found in 1.x and 2.x are now considered a design bug. They are disappearing in 3.0. Datetime is a fairly recent module (new in 2.3) writ

[issue2755] IDLE ignores module change before restart

Terry J. Reedy <[EMAIL PROTECTED]> added the comment: On Windows, I tested this in both 2.5.2 and 3.0a4. In both cases, at paragraph 4 of your report, I got 2 in the shell, as you expected,not 1. I have no idea whether the system difference makes a difference (the TCL and TK binaries are obvious

[issue2804] Integer right shift raises OverflowError when second operand is large

Mark Dickinson <[EMAIL PROTECTED]> added the comment: It's the current behaviour that seems arbitrary to me: a >> b is well- defined, and efficiently computable, for any integer a and nonnegative integer b; it seems odd to have an unnecessary and (from a user's viewpoint) arbitrary limit on th

[issue2804] Integer right shift raises OverflowError when second operand is large

Alexander Belopolsky <[EMAIL PROTECTED]> added the comment: On Fri, May 9, 2008 at 7:08 PM, Martin v. Löwis <[EMAIL PROTECTED]> wrote: .. > I'm -1 on this patch (or any other fixing the perceived problem). > Special cases aren't special enough to break the rules. > > If you ever see this error in

[issue2804] Integer right shift raises OverflowError when second operand is large

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: > I'm not sure I understand. What rule would be broken by this patch? The (implicit) rule that there is a range limitation on the shift width. The limitation would continue to exist, just not for selected left-hand parameters. This is fairl

[issue2804] Integer right shift raises OverflowError when second operand is large

Mark Dickinson <[EMAIL PROTECTED]> added the comment: I'm not sure I understand. What rule would be broken by this patch? __ Tracker <[EMAIL PROTECTED]> __

[issue2664] The position of special value tables (cmathmodule.c)

Hirokazu Yamamoto <[EMAIL PROTECTED]> added the comment: Nope, I don't have strong reason. I just thought exceeding 80 line width is a little ugly, and if data and function are close you can refer both more easily. Please feel free to close this entry as "WONT FIX". _

[issue1733134] sqlite3.dll cannot be relocated

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: > Unfortunately, this bug appears to affect Py30a5 too (at least on Win XP > Home): I'm somewhat skeptical that this is the same bug, though. Much more likely related to switching to VS 2008 (and I'm skeptical that we can resolve all VS 2008

[issue1267629] pdb: implement "until",fix for 1248119

Changes by Benjamin Peterson <[EMAIL PROTECTED]>: Added file: http://bugs.python.org/file10235/until.patch _ Tracker <[EMAIL PROTECTED]> _ __

[issue1267629] pdb: implement "until",fix for 1248119

Changes by Benjamin Peterson <[EMAIL PROTECTED]>: Removed file: http://bugs.python.org/file6759/until.patch _ Tracker <[EMAIL PROTECTED]> _ _

[issue2804] Integer right shift raises OverflowError when second operand is large

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: I'm -1 on this patch (or any other fixing the perceived problem). Special cases aren't special enough to break the rules. If you ever see this error in a real application, you have deeper problems than the exception. -- nosy: +loewi

[issue2800] make htmlhelp creates python30a5.chm but msi.py expects pydoc.chm

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: This is now fixed in r62949. I don't quite understood why this had the priority "high" - it just worked fine the way it was - you just have to manually rename the result file. In any case, I'd appreciate if the file name scheme stays as-is

[issue2799] Remove PyUnicode_AsString(), rework PyUnicode_AsStringAndSize(), add PyUnicode_AsChar()

Alexandre Vassalotti <[EMAIL PROTECTED]> added the comment: Honestly, I am not sure if removing PyUnicode_AsString() is a good idea. There is many cases where the size of the returned string is not needed. Furthermore, this would be a rather major backward-incompatible change to be included in a

[issue2807] Remove the API PyUnicode_AsString()

Alexandre Vassalotti <[EMAIL PROTECTED]> added the comment: Oops, it seems Marc-André has already opened an issue about this. Closing as duplicate. -- resolution: -> duplicate status: open -> closed superseder: -> Remove PyUnicode_AsString(), rework PyUnicode_AsStringAndSize(), add P

[issue2807] Remove the API PyUnicode_AsString()

Alexandre Vassalotti <[EMAIL PROTECTED]> added the comment: Honestly, I am not sure if removing PyUnicode_AsString() is a good idea. There is many cases where the size of the returned string is not needed. Furthermore, this would be a rather major backward-incompatible change to be included in a

[issue2807] Remove the API PyUnicode_AsString()

New submission from Alexandre Vassalotti <[EMAIL PROTECTED]>: Marc-Andre Lemburg noted: BTW: The API PyUnicode_AsString() is pretty useless by itself - there's no way to access the size information of the returned string without again going to the Unicode object. I'd suggest to remove

[issue2805] 2to3 doesn't correct divisions

Collin Winter <[EMAIL PROTECTED]> added the comment: I say do it before the GSoC projects complete. Those projects will take months, and we can't stop development for that long. __ Tracker <[EMAIL PROTECTED]>

[issue2806] Py30a5: Tk Menu Alt-f behaves differently Linux vs Windows

New submission from Mark Summerfield <[EMAIL PROTECTED]>: #Python 3.0a5 (py3k:62932M, May 9 2008, 16:23:11) [MSC v.1500 32 bit #(Intel)] on win32 # # If you run this tiny program on Linux and press Alt+F (Alt-f in Tk # terminology) the File menu pops up as expected. But run it on # Windows Home

[issue1733134] sqlite3.dll cannot be relocated

Mark Summerfield <[EMAIL PROTECTED]> added the comment: Unfortunately, this bug appears to affect Py30a5 too (at least on Win XP Home): Python 3.0a5 (py3k:62932M, May 9 2008, 16:23:11) [MSC v.1500 32 bit (Intel)] on win32 IDLE 3.0a5 >>> import sqlite3 Traceback (most recent call last):

[issue2805] 2to3 doesn't correct divisions

Guilherme Polo <[EMAIL PROTECTED]> added the comment: If I were to add such fixer, should I wait for changes coming by gsoc projects ? I did a quick pass through 2to3 code a while ago, but I'm very far from understanding it in a good manner so I'm not sure if I should starting doing that now beca

[issue2804] Integer right shift raises OverflowError when second operand is large

Mark Dickinson <[EMAIL PROTECTED]> added the comment: > On the second thought, it is theoretically possible to have a long int a > for which a >> maxsize is not zero This occurred to me too; somehow this hardly seems worth worrying about- --there are already other problems in longobject.c when

[issue2805] 2to3 doesn't correct divisions

Collin Winter <[EMAIL PROTECTED]> added the comment: My gut feeling is that the number of cases where both operands are written as literals is exceedingly small when compared to the number of cases where one or both is an identifier. Since 2to3 doesn't support type inference, we'd miss the releva

[issue2804] Integer right shift raises OverflowError when second operand is large

Alexander Belopolsky <[EMAIL PROTECTED]> added the comment: On the second thought, it is theoretically possible to have a long int a for which a >> maxsize is not zero because that would require only maxsize/15 digits. I am not sure it is worth the trouble to account for that. _

[issue2805] 2to3 doesn't correct divisions

New submission from Guilherme Polo <[EMAIL PROTECTED]>: Given the sample code: for i in range(len([1, 2]) / 2): pass print 2 / 3 2to3 tells no files need to be modified after running it over this code, but range doesn't accept float values and the print result will differ. Would it be too

[issue2804] Integer right shift raises OverflowError when second operand is large

Alexander Belopolsky <[EMAIL PROTECTED]> added the comment: Attached patch makes a >> b return 0 for b > maxsize. -- keywords: +patch nosy: +belopolsky Added file: http://bugs.python.org/file10234/issue2804.diff __ Tracker <[EMAIL PROTECTED]>

[issue2804] Integer right shift raises OverflowError when second operand is large

New submission from Mark Dickinson <[EMAIL PROTECTED]>: In Python 2.6a3: >>> 1 >> (2**31) # unexpected exception Traceback (most recent call last): File "", line 1, in OverflowError: long int too large to convert to int >>> 1 >> (2**31-1) # works as expected 0L It might make more sense for

[issue2782] datetime/date strftime() method and time.strftime() inconsistency

Changes by broadus jones <[EMAIL PROTECTED]>: -- nosy: +sbj3 __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing list Unsubscribe: h

[issue2664] The position of special value tables (cmathmodule.c)

Mark Dickinson <[EMAIL PROTECTED]> added the comment: I'm actually pretty happy with the tables the way they are; everything's working at the moment, and the current code seems clear enough. Do you have a strong reason to want this change? __ Tracker <[EMAIL PR

[issue2487] ldexp(x,n) misbehaves when abs(n) is large

Mark Dickinson <[EMAIL PROTECTED]> added the comment: I've committed a (slightly reworked) version of this patch in r62948. Closing this issue; the problem with 1 >> 2**31 is a separate issue. Thanks for the report, Fredrik. -- resolution: -> fixed status: open -> closed ___

[issue2801] Py30a5 float.is_integer() raises ValueError

Mark Dickinson <[EMAIL PROTECTED]> added the comment: Thanks, Mark. I've also backported the fix to the trunk in r62943. -- resolution: -> fixed status: open -> closed __ Tracker <[EMAIL PROTECTED]> ___

[issue2803] heapq.heappush called with too few arguments in sched.py

New submission from Matt Harden <[EMAIL PROTECTED]>: In the method scheduler.run in the sched module, heapq.heappush is called with single argument (event). It's a two argument function. The correct call would be heapq.heappush(q, event). This problem is probably not frequently experienced bec

[issue2802] str.format() :n integer output

Mark Dickinson <[EMAIL PROTECTED]> added the comment: > As to the implementation, the OS supplied float formatting does not add > thousands separators. I added the function add_thousands_grouping() to > Python/pystrtod.c in order implement this for floats. Excellent! I didn't realise this code

[issue2802] str.format() :n integer output

Mark Summerfield <[EMAIL PROTECTED]> added the comment: On 2008-05-09, Eric Smith wrote: > Eric Smith <[EMAIL PROTECTED]> added the comment: > > The reason for this is that 'n' is defined in PEP 3101 as being a float > format only, and the rule is that if an integer sees a float format, it > does

[issue2802] str.format() :n integer output

Eric Smith <[EMAIL PROTECTED]> added the comment: > It isn't hard (in Python): It's more complex, because the "3" is locale dependent, and is allowed to be something like "3, then 2, then 3, then 1, repeating until the start of the string". See _group() in Lib/locale.py. In any event, the co

[issue2801] Py30a5 float.is_integer() raises ValueError

Mark Summerfield <[EMAIL PROTECTED]> added the comment: OK, I've just built against your fix and it works fine now! Python 3.0a5+ (py3k:60668:62940, May 9 2008, 15:48:15) [GCC 4.1.2 20070925 (Red Hat 4.1.2-33)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>>

[issue2802] str.format() :n integer output

Mark Summerfield <[EMAIL PROTECTED]> added the comment: On 2008-05-09, Mark Dickinson wrote: > Mark Dickinson <[EMAIL PROTECTED]> added the comment: > > I think that n should stay the same for floats, but for integers should > > never switch to g, but just use as many separators as needed. > > I

[issue2802] str.format() :n integer output

Eric Smith <[EMAIL PROTECTED]> added the comment: The reason for this is that 'n' is defined in PEP 3101 as being a float format only, and the rule is that if an integer sees a float format, it does a float conversion and then prints the float with the supplied format. I'd be okay with adding 'n

[issue2801] Py30a5 float.is_integer() raises ValueError

Mark Summerfield <[EMAIL PROTECTED]> added the comment: On 2008-05-09, Mark Dickinson wrote: > Mark Dickinson <[EMAIL PROTECTED]> added the comment: > > Is this on Windows? I can't reproduce it on OS X 10.5.2: > > Python 3.0a5+ (py3k:62937M, May 9 2008, 09:32:27) > [GCC 4.0.1 (Apple Inc. build

[issue2802] str.format() :n integer output

Mark Dickinson <[EMAIL PROTECTED]> added the comment: > I think that n should stay the same for floats, but for integers should > never switch to g, but just use as many separators as needed. I agree with this, in principle. It might be some work to implement, though: for floats, Python gets

[issue2802] str.format() :n integer output

New submission from Mark Summerfield <[EMAIL PROTECTED]>: In Py30a5 the 'n' format option is not v. useful for integers: >>> for x in range(8): print("{0:n} ".format(10**x), end="") 1 10 100 1,000 10,000 100,000 1e+06 1e+07 This is because it behaves like g once a number grows

[issue2801] Py30a5 float.is_integer() raises ValueError

Changes by Mark Dickinson <[EMAIL PROTECTED]>: -- assignee: -> marketdickinson priority: -> normal __ Tracker <[EMAIL PROTECTED]> __ ___ Pytho

[issue2801] Py30a5 float.is_integer() raises ValueError

Mark Dickinson <[EMAIL PROTECTED]> added the comment: That should be r62939, not r62938. Sorry. __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list m

[issue2801] Py30a5 float.is_integer() raises ValueError

Mark Dickinson <[EMAIL PROTECTED]> added the comment: This should be fixed in r62938. Mark, can you confirm? __ Tracker <[EMAIL PROTECTED]> __ ___ Pytho

[issue2801] Py30a5 float.is_integer() raises ValueError

Mark Dickinson <[EMAIL PROTECTED]> added the comment: Is this on Windows? I can't reproduce it on OS X 10.5.2: Python 3.0a5+ (py3k:62937M, May 9 2008, 09:32:27) [GCC 4.0.1 (Apple Inc. build 5465)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> x = 5.0 >>>

[issue2748] ceil(), floor() and round() broken in Decimal

Mark Dickinson <[EMAIL PROTECTED]> added the comment: Thanks for reviewing this, Raymond! Committed, r62938. -- status: open -> closed __ Tracker <[EMAIL PROTECTED]> __ __

[issue2772] Add PendingDeprecationWarning for % formatting

Eric Smith <[EMAIL PROTECTED]> added the comment: The attached patch (percent_formatting_pending_deprecation_0.diff) adds both the simple global lock to unicode_mod() and changes warnings.py to use .format() instead of % formatting. I think this is good enough. We should add a warning to the do

[issue2801] Py30a5 float.is_integer() raises ValueError

New submission from Mark Summerfield <[EMAIL PROTECTED]>: The new method float.is_integer() introduced in Py30a5 behaves unexpectedly: >>> x = 5.0 >>> x.as_integer_ratio() (5, 1) >>> x.is_integer() Traceback (most recent call last): File "", line 1, in x.is_integer() ValueError: (11, 'Res

[issue2800] make htmlhelp creates python30a5.chm but msi.py expects pydoc.chm

New submission from Christian Heimes <[EMAIL PROTECTED]>: The sphinx tool chain now creates the htmlhelp files as python30a5.* but the MSI installer packages expects pydoc.chm. Either msi.py or the doc tool chain must be altered. By the way Martin: Should the RM set snapshot to 0 in Tools/msi/ms

[issue2799] Remove PyUnicode_AsString(), rework PyUnicode_AsStringAndSize(), add PyUnicode_AsChar()

New submission from Marc-Andre Lemburg <[EMAIL PROTECTED]>: The API PyUnicode_AsString() is pretty useless by itself - there's no way to access the size information of the returned string without again going to the Unicode object. I'd suggest to remove the API altogether and not only deprecating

[issue2798] Crash on non-Windows if Python runs from a non-ASCII directory

Changes by Antoine Pitrou <[EMAIL PROTECTED]>: Added file: http://bugs.python.org/file10231/getargs.patch __ Tracker <[EMAIL PROTECTED]> __ ___ Python-b

[issue2798] Crash on non-Windows if Python runs from a non-ASCII directory

Changes by Antoine Pitrou <[EMAIL PROTECTED]>: Removed file: http://bugs.python.org/file10230/getargs.patch __ Tracker <[EMAIL PROTECTED]> __ ___ Python

[issue1342] Crash on Windows if Python runs from a directory with umlauts

Antoine Pitrou <[EMAIL PROTECTED]> added the comment: See #2798 for the non-Windows case, with a patch. __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs

[issue2798] Crash on non-Windows if Python runs from a non-ASCII directory

New submission from Antoine Pitrou <[EMAIL PROTECTED]>: (Note: I'm splitting this from #1342 because the fix is much simpler in the non-Windows case) py3k does not accept running from a path with non-ascii characters. $ pwd /home/antoine/py3k/héhé $ ./python Fatal Python error: Py_Initialize: c

[issue2789] Comparsion datetime objects with None

Changes by Ralf Schmitt <[EMAIL PROTECTED]>: -- nosy: +schmir __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing list Unsubscribe:

[issue1342] Crash on Windows if Python runs from a directory with umlauts

Antoine Pitrou <[EMAIL PROTECTED]> added the comment: There are some problems under Linux too: $ pwd /home/antoine/py3k/héhé $ ./python Fatal Python error: Py_Initialize: can't initialize sys standard streams Traceback (most recent call last): File "/home/antoine/py3k/pristine/Lib/encodings/__

[issue2723] Truncate __len__() at sys.maxsize

Antoine Pitrou <[EMAIL PROTECTED]> added the comment: Well apparently the Java guys think raising an exception would have been a much better idea than the behaviour they are stuck with. There's also in interesting proposal there: """ The ReturnValueTooBigException could even have a method declar

[issue2797] Trunk build issues in DragonFly BSD

New submission from Hasso Tepper <[EMAIL PROTECTED]>: The attached patch fixes trunk build problems in DragonFly BSD. It's trunk version of the issue #2796, but adds one (not DragonFly specific) fix to the Modules/mmapmodule.c - in case of (!HAVE_SYSCONF || !_SC_PAGESIZE) my_getallocationgranu

[issue2796] Build issues in DragonFly BSD

Changes by Hasso Tepper <[EMAIL PROTECTED]>: Added file: http://bugs.python.org/file10228/dragonfly-python24.patch __ Tracker <[EMAIL PROTECTED]> __ ___

[issue2796] Build issues in DragonFly BSD

New submission from Hasso Tepper <[EMAIL PROTECTED]>: The attached patch fixes obvious problems with build in DragonFly BSD platform. Modules/socketmodule.c part adds NetBSD to the blacklist as well - both OS'es use the same Bluetooth stack. Although the code seems to have support for NetBSD