[issue2562] Cannot use non-ascii letters in disutils if setuptools is used.

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: The official supported way for non-ASCII characters in distutils is to use Unicode strings. If anything else fails, that's not a bug. IIUC, in this case, it's setuptools that fails, not distutils. Assuming I understoo

[issue2562] Cannot use non-ascii letters in disutils if setuptools is used.

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: I don't understand. It is *certainly* allowed to use byte strings for these data, as long as they are ASCII. The Unicode requirement exists only for non-ASCII characters, and distutils makes explicit, deliberate use of the defau

[issue2552] test_ctypes failed Python 2.6a2 Solaris 10 SUN C

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: > If option --with-system-ffi is not specified and if the compiler is not > gcc, raise an error. Up to here, it all sounded fine. What do you mean by error? Abort? That should not happen. Instead, setup.py skips modules if it

[issue2562] Cannot use non-ascii letters in disutils if setuptools is used.

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: I agree there is a bug in distutils. Before we proceed, I think distutils-sig needs to be consulted. My proposal would be the one I suggested earlier: all strings should either be Unicode or ASCII-only byte strings. This contradicts

[issue2562] Cannot use non-ascii letters in disutils if setuptools is used.

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: As a follow-up: for compatibility, it might be possible to support either Unicode or arbitrary plain strings in write_pkg_file. In 3k, such support can then be dropped. As that constitutes a new feature, it shouldn't be app

[issue2388] Compiler warnings when using UCS4

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: This is now fixed in r62199 -- resolution: -> fixed status: open -> closed __ Tracker <[EMAIL PROTECTED]> <http://bugs

[issue2565] Change 'type' to 'class' in repr/str(builtin-class)

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: So which one should it be: type or class? -- nosy: +loewis __ Tracker <[EMAIL PROTECTED]> <http://bugs.pytho

[issue2128] sys.argv is wrong for unicode strings

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: What warnings precisely are you seeing? I didn't see anything in the 3k branch (not even for #2388, as PyErr_Format doesn't have the GCC format attribute in 3k, unlike 2.x). __ Tracker &

[issue2567] Section "New-style and classic classes" needs to be removed/rewritten

New submission from Martin v. Löwis <[EMAIL PROTECTED]>: There are no classic classes anymore in Python. -- assignee: georg.brandl components: Documentation messages: 65065 nosy: georg.brandl, loewis severity: normal status: open title: Section "New-style and classic classe

[issue2565] Change 'type' to 'class' in repr/str(builtin-class)

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: This is now fixed in r62203. -- resolution: -> fixed status: open -> closed __ Tracker <[EMAIL PROTECTED]> <http://bugs

[issue2562] Cannot use non-ascii letters in disutils if setuptools is used.

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: > If we do use Unicode, I think we might need an extra meta-data, > "encoding", that would default to "utf8", and that could be used when > the class needs to serialize the data in a file. I don't thi

[issue2562] Cannot use non-ascii letters in disutils if setuptools is used.

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: > I don't think that we should support non-ASCII encodings for meta-data > strings passed to setup(). > > If setuptools is broken in this respect, it needs to be fixed. Dito for > other 3rd party tools. We do

[issue1232947] non-admin install may fail (win xp pro)

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: > I can repro this too using python-2.6a2.msi - after selecting "just for > me" on XP running as a non-admin user, I see an error message regarding > permissions. I think this is mixing up entirely unrelated

[issue2562] Cannot use non-ascii letters in disutils if setuptools is used.

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: > Agreed, but any change will target the package authors who can easily > upgrade their packages to use Unicode for e.g. names. They can't: that would break their 2.5-and-earlier compatibility. > If the change were

[issue1232947] non-admin install may fail (win xp pro)

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: I'm closing this as "won't fix". I don't really see a way to support this kind of setup (i.e. the start menu is on a network drive to which the installer service cannot write). -- resolution: -&g

[issue2240] setitimer, getitimer wrapper

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: > Should further discussion be moved to python-dev ? I'm somewhat stuck on > how to resolve this, besides saying to upgrade to FreeBSD 7 which uses > libthr by default. Discussing on python-dev is fine. An acceptable

[issue2562] Cannot use non-ascii letters in disutils if setuptools is used.

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: > But write_pkg_file will use ascii encoding if we don't indicate it > here: > >>>> pkg_info.write('Author: %s\n' % self.get_contact() ) Why do you say that it uses ascii? It uses whatever encodi

[issue2513] 64bit cross compilation on windows

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: > Martin - my patch creates a new executable in Lib\distutils\command, and > IMO it should be included in binary builds for all windows platforms. > Is there something I should change in the MSI process? Yes, I fixed that in

[issue1297] pyconfig.h not compatible with MS VC++ Express Edition

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: > Amaury: The file python.hpp, thus basetsd.h, is used by boost-python. I don't think that was the question. Instead, the question was: why is basetsd.h needed in the first place, when compiling Python? Apparently, basets

[issue2256] Install failure of 2.6a1 on Windows XP without VS8 installed

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: > Ping. Does the problem still exist in 2.6a2? It shouldn't. __ Tracker <[EMAIL PROTECTED]> <http://bu

[issue2606] trace module crashes due to using wrong sort idiom

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: I've further simplified the code by eliminating the local variables, and committed that as r62270. -- nosy: +loewis resolution: -> fixed status: open -> closed __ Tracker <[EMA

[issue2607] why is (default)dict so slow on tuples???

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: I cannot reproduce this. The attached script for me gives for 1M iterations a total time of 0.8s, on 3.2GHz Pentium 4. -- nosy: +loewis resolution: -> works for me __ Tracker <[EMA

[issue2607] why is (default)dict so slow on tuples???

Changes by Martin v. Löwis <[EMAIL PROTECTED]>: Added file: http://bugs.python.org/file/a.py __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2607> __ __

[issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: > I'd like to know the status of this issue. I'm having the same problems > here with PPC64, and the patch that Bob Atkins has sent works fine for > me too. Would you intend to apply this patch in upstream? >

[issue2610] string representation of range

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: > I use Python in my CS1 and CS2 curriculum and I have a question. At this point, I would have almost stopped reading - the tracker is not a place for questions. I read on and then noticed that you have a patch also, not just a

[issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: > Thanks for your quick answer. I'd like to know what can we do to push > this patch into upstream. Does the fact that the patch is posted in a > bug report (and not in a developer's mailing list) is slowing down the

[issue2256] Install failure of 2.6a1 on Windows XP without VS8 installed

Changes by Martin v. Löwis <[EMAIL PROTECTED]>: -- resolution: -> fixed status: open -> closed __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2256> __ __

[issue2611] Extend buildbot web interface to allow for forced tests to be run on a slave in verbose mode.

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: I think this will be fairly difficult to set up. If the clean buildstep had been executed, you would have to rerun configure and compile before you can run any tests. Also, how would you communicate what specific test you want to

[issue2610] string representation of range

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: > In a world where ints and long ints have been unified the existence of > this error seems like a bug. > > I think the right thing would be to fix range_item and range_length so > they do not use Py_ssize_t for th

[issue2607] why is (default)dict so slow on tuples???

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: > Perhaps your GC thresholds would be better default > values than what is currently in force. No, the defaults are correct for typical applications. __ Tracker <[EMAIL PROTECTED]> <h

[issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: > Actually, I know that you can use CC to do it, but IMHO that's not the > correct approach. I understand too you concern about adding @CFLAGS@, > but I think the user should be able to define his/her own CFLAG

[issue2610] string representation of range

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: > I don't think <0, 1, ..., 9> is much clearer than range(0, 10). The > only problem students may have is that 10 not in range(0, 10), but this > can be learned very quickly. The <..> repr breaks x == eva

[issue2610] string representation of range

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: > Now there are objections. > > Other than some mild frustration at having invested a fair amount of > time in producing my first python patch, I am also in the middle of > editing a textbook that will come out

[issue2618] Tile module: Add support for themed widgets

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: Kevin, is this all your code (the comment seems to suggest otherwise). Can all authors fill out contributor agreements? -- nosy: +loewis __ Tracker <[EMAIL PROTECTED]> <http://

[issue2621] rename test_support to support

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: What's the rationale for this change? -- nosy: +loewis __ Tracker <[EMAIL PROTECTED]> <http://bugs.

[issue2624] swig support in distutils should use the build and temp dirs

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: Can you provide a patch? -- nosy: +loewis __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2624> __

[issue2626] If compile with gcc 4.3.0 python interpreter itself eats all memory

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: That's a bug in gcc 4.3, see http://mail.python.org/pipermail/python-3000/2008-April/012965.html -- nosy: +loewis resolution: -> invalid status: open -> closed versions: +3rd

[issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: > This is what you get when you try to build a 64-bit Python on a biarch > machine (64-bit kernel, 32-bit userspace), using a gcc that generates > natively 32-bit objects (therefore, you *must* pass the '-m64' option

[issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: > Your suggestion for using the CC variable to fix the problem that I > reported won't work - I already tried it and based on what others are > reporting, you are beating a dead horse. Believe me I would rather not &g

[issue2611] Extend buildbot web interface to allow for forced tests to be run on a slave in verbose mode.

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: > We could re-order and do clean first. That would leave all the build > artifacts in tact after a build which would be nice for some > debugging. With the current setup, that wouldn't quite work. We can't run it

[issue2122] mmap.flush does not check for errors on windows

Changes by Martin v. Löwis <[EMAIL PROTECTED]>: -- keywords: +patch __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2122> __ ___ Python-bugs

[issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: Just to repeat my concern about this patch: It gives the impression of supporting CFLAGS, but doesn't really. There *is* a hard rule that CFLAGS given to configure should override any options passed to configure, and there is a

[issue2504] Add gettext.pgettext() and variants support

Changes by Martin v. Löwis <[EMAIL PROTECTED]>: -- assignee: -> loewis __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2504> __ ___ Python-b

[issue2647] XML munges apos entity in tag content

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: That's not a bug. The two XML documents are completely equivalent. If you rely on the lexical representation of specific characters, you should reconsider your usage of XML. toxml could have chosen to represent < as <, and

[issue2646] Python does not accept unicode keywords

Changes by Martin v. Löwis <[EMAIL PROTECTED]>: -- versions: +Python 2.6 -Python 2.5 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2646> __ __

[issue2677] Argument rules for callables do not apply when function implementation uses PyArg_ParseTuple

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: I fail to see the problem. The open function really doesn't have a named parameter called flags; the positional parameters are unnamed. So there is no violation of the language reference, AFAICT. Perhaps it would be useful to poi

[issue2677] Argument rules for callables do not apply when function implementation uses PyArg_ParseTuple

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: > I'd believe you when you say "positional parameters are unnamed", but: > > - the language reference contains terms such as "first formal parameter > name". This means that positional paramete

[issue2677] Argument rules for callables do not apply when function implementation uses PyArg_ParseTuple

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: > Maybe yes, the easier but probably harmless solution is to change the > documentation and point out that "in general, you can't". Maybe this > somehow leans towards promoting a bug to the rank of feature? ;

[issue2677] Argument rules for callables do not apply when function implementation uses PyArg_ParseTuple

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: Making it a documentation issue; I don't think the implementation should change. Georg, if you don't see the need for action, feel free to close it. -- assignee: -> georg.brandl components: +Documentation

[issue2682] cyclic reference in ctypes CFunctionType objects

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: Can you please elaborate your (apparent) concerns about this patch? IOW, why did you not check it in? -- nosy: +loewis __ Tracker <[EMAIL PROTECTED]> <http://bugs.pytho

[issue2686] Any chance we could double the height of the 'Comment:' text area on tracker?

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: Fixed in r62496. Amaury was right - please do use the meta-tracker in the future for this. But what should I do with your left arm now :-? FWIW, Safari users don't need to rely on the HTML page providing them with enough space

[issue2686] Any chance we could double the height of the 'Comment:' text area on tracker?

Changes by Martin v. Löwis <[EMAIL PROTECTED]>: -- resolution: invalid -> fixed __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2686> __ ___ Pyt

[issue2682] cyclic reference in ctypes CFunctionType objects

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: > Martin, are there any problems with this approach? No, it's fine. I was just puzzled. __ Tracker <[EMAIL PROTECTED]> <http://bu

[issue2693] IDLE doesn't work with Tk 8.5

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: I'm skeptical about this patch; it may break other things. So Python 2.5 just doesn't support Tcl 8.5 - you need to stay with Tcl 8.4. -- nosy: +loewis __ Tracker <[EMAI

[issue2696] unicode string does not get freed --> memory leak?

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: This is a duplicate of issue 2321. There was no memory leak whatsoever, instead, malloc just failed to return the memory returned to it (through free(3)) to the operating system. Don't trust resident_size() to detect memory

[issue2694] msilib file names check too strict ?

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: Indeed, the primary keys in many tables must be Identifiers, see http://msdn2.microsoft.com/en-us/library/aa369212(VS.85).aspx make_id tries to synthesize an identifier from a file name, and fails for your file names. -

[issue2694] msilib file names check too strict ?

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: Actually, the algorithm should be fixed to generate a valid identifier for any input. Would you like to work on a fix? __ Tracker <[EMAIL PROTECTED]> <http://bugs.pytho

[issue2694] msilib file names check too strict ?

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: > Do I understand right that dist_msi builds a database of the files, and > that the identifiers could be named differently than the filenames > themselves, as long as they are unique ? Correct. As a design objectiv

[issue2693] IDLE doesn't work with Tk 8.5

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: > I wish I could be as cavalier about Tk 8.5. The last version of Tk 8.4 > just came out and it really shows its age, especially on Mac OS X, and > those are ~25% of our application's downloads. Still, why is that a p

[issue2702] pickling of large recursive structures crashes cPickle

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: What operating system and compiler are you using? -- nosy: +loewis __ Tracker <[EMAIL PROTECTED]> <http://bugs.pytho

[issue2712] enhanced ioctl

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: > IIUC, current ioctl is not capable of handling arbitrary argument > types. Can you please be a bit more explicit? What limitation do you see in fcntl.ioctl, and how does this fragment overcome the limitation? AFAICT, they do

[issue1734346] patch for bug 1170311 "zipfile UnicodeDecodeError"

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: > Any chance of this making it in sometime? I'll see what I can do for 2.6, but perhaps it gets delayed until 2.7/3.1. _ Tracker <[EMAIL PROTECTED]> <http://bugs.

[issue1734346] patch for bug 1170311 "zipfile UnicodeDecodeError"

Changes by Martin v. Löwis <[EMAIL PROTECTED]>: -- priority: normal -> high _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1734346> _ ___

[issue2712] enhanced ioctl

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: Passing structures is certainly possible. I'd try args = struct.pack("iP", len(c), cast (pointer (c), c_void_p).value) fcntl.ioctl(fd, request, args) Alternatively, args = eos_dl_args_t() ... args_p = cast(pointer(arg

[issue2714] Unable to start IDLE on Windows Server 2003 x64 Edition w/ SP2

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: Can you please run IDLE in a console window, and report the exceptions that you get? Invoke Lib\idlelib\idle.py to do so. -- nosy: +loewis __ Tracker <[EMAIL PROTECTED]> <http://

[issue2712] enhanced ioctl

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: I think we should close it. -- resolution: -> works for me status: open -> closed __ Tracker <[EMAIL PROTECTED]> <http://bugs

[issue2714] Unable to start IDLE on Windows Server 2003 x64 Edition w/ SP2

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: Check whether the TCL_DIR or TK_DIR environment variables are set. If so, unset them. __ Tracker <[EMAIL PROTECTED]> <http://bugs.pytho

[issue1569] Add VS CRT redist to the MSI installer

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: Correct. This is now fixed. -- resolution: -> fixed status: pending -> closed __ Tracker <[EMAIL PROTECTED]> <http://bugs

[issue2741] documentation -- do serversockets work with ipv6

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: I fail to see the issue. There are many other address families supported as well, such as AF_BLUETOOTH, AF_PACKET, AF_TIPC, and AF_NETLINK, depending on the system. The documentation just lists some examples. -- nosy: +

[issue2742] example code does not work

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: What operating system are you using? It could be a bug in the operating system as well. -- nosy: +loewis __ Tracker <[EMAIL PROTECTED]> <http://bugs.pytho

[issue2741] documentation -- do serversockets work with ipv6

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: > the way i read the text, i gathered that it might not work > with sockets belonging to a subset of address families. I still cannot see anything wrong with that text, but then, English is not my native language. Can y

[issue2745] Add support for IsWow64Process

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: I think this can be just as well done with (untested, as I don't have access to a Windows system right now) def iswow64(): if platform.getarchitecture()[0] == '64-bit':return False return os.environ["PROCES

[issue2745] Add support for IsWow64Process

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: One reason for IsWow64Process is that it allows to determine the wow-ness of a different process, which is e.g. needed to display the asterisk in the process viewer. This reason indeed doesn't apply to Python, and your patch doe

[issue2753] Test issue

New submission from Martin v. Löwis <[EMAIL PROTECTED]>: Testing the integration with the review tool. -- files: regrtest.diff keywords: patch messages: 66192 nosy: loewis severity: normal status: open title: Test issue Added file: http://bugs.python.org/file10187/regrtes

[issue2753] Test issue (different spelling)

Changes by Martin v. Löwis <[EMAIL PROTECTED]>: -- resolution: -> fixed status: open -> closed __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2753> __ __

[issue1734346] patch for bug 1170311 "zipfile UnicodeDecodeError"

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: Thanks for the patch, committed as r62724. I didn't see the need to clear the UTF-8 flag, so I left it in (in case somebody wants to inspect it). -- resolution: -> accepted status:

[issue1734346] patch for bug 1170311 "zipfile UnicodeDecodeError"

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: > Martin, I cleared the flag bit because filename was changed in-place, to > mark that filename does not need further processing. This was primarily > compatibility concern, to accommodate for situations where users try to >

[issue2741] documentation -- do serversockets work with ipv6

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: > so i suggest just removing this sentence -- > > AF_INET and socket.AF_UNIX are two possible values. > > this would imply that all socket address families are supported. > but if that is not true just list the e

[issue2610] string representation of range and dictionary views

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: > Is there any chance this patch will make it into the latest alpha?? I don't think there is any such chance. __ Tracker <[EMAIL PROTECTED]> <http://bu

[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 fi

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

[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

[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 param

[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 <[E

[issue7847] Remove 'python -U' or document it

Martin v. Löwis added the comment: I fail to see the point. This bug was fixed in Python 3. Why risk breaking something in the last 2.x release? -- ___ Python tracker <http://bugs.python.org/issue7

[issue7847] Remove 'python -U' or document it

Martin v. Löwis added the comment: I'm +0 on such a change - I don't think it makes anything better (it will only cause more users asking what this is, why it was added, and demand that something should be done about it). Feel free to commit it, anyway. -- assignee: loewi

[issue7856] cannot decode from or encode to big5 \xf9\xd8

Martin v. Löwis added the comment: That iconv supports it is not convincing, IMO. Do you have other sources (like tables in the web somewhere) that support your request? -- nosy: +loewis ___ Python tracker <http://bugs.python.org/issue7

[issue7856] cannot decode from or encode to big5 \xf9\xd8

Martin v. Löwis added the comment: In particular, the Unicode consortium mapping table, now at http://www.unicode.org/Public/MAPPINGS/OBSOLETE/EASTASIA/OTHER/BIG5.TXT doesn't map f9d8 to anything; the current version of that table (in unihan.zip) has these mappings for U+88CF: U

[issue7856] cannot decode from or encode to big5 \xf9\xd8

Martin v. Löwis added the comment: perky, what do you think? -- assignee: -> hyeshik.chang nosy: +hyeshik.chang ___ Python tracker <http://bugs.python.org/iss

[issue7889] random produces different output on different architectures

Martin v. Löwis added the comment: Would you like to work on a patch? -- nosy: +loewis ___ Python tracker <http://bugs.python.org/issue7889> ___ ___ Python-bug

[issue7890] equal unicode/str objects can have unequal hash

Martin v. Löwis added the comment: This is not a bug in Python, but in your code. sys.setdefaultencoding is only supported when setting the default encoding to either latin-1, or ascii, or 'undefined'. Setting it to any other value will have undesirable consequences like the one

[issue7932] print statement delayed IOError when stdout has been closed

Martin v. Löwis added the comment: This is not a bug. The output stream gets buffered, and that it is closed is only detected when a flush is attempted. Use the -u option if you want unbuffered stdout. It is, however, a bug that Python 2.6 apparently fails to flush the output at all; Python

[issue3920] OpenBSD 4.4 still doesn't support _XOPEN_SOURCE

Martin v. Löwis added the comment: I have now committed bsd3.diff as r78194, r78195, r78196, and r78197 -- resolution: -> accepted status: open -> closed versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.5, Python 3.0 ___ Python t

[issue7903] Configure script incorrect for reasonably recent OpenBSD

Martin v. Löwis added the comment: This issue is now superseded by issue 3920. It would be good if somebody could confirm that the approach taken for 4.4 continues to work in more recent releases. -- nosy: +loewis ___ Python tracker <h

[issue7903] Configure script incorrect for reasonably recent OpenBSD

Martin v. Löwis added the comment: Stefan, what ncurses problem are you referring to? I quite object to working around OpenBSD limitations, and would rather hope that OpenBSD fixes their POSIX support at some point. -- ___ Python tracker <h

[issue7903] Configure script incorrect for reasonably recent OpenBSD

Martin v. Löwis added the comment: Thanks for the tests, and the patch. Committed as r78202, r78203, r78204, and r78205. -- resolution: -> fixed status: open -> closed ___ Python tracker <http://bugs.python.org/

[issue6375] compile failure in Modules/python.c

Martin v. Löwis added the comment: Closing this as unreproducible. -- resolution: -> works for me status: open -> closed ___ Python tracker <http://bugs.python.org/

[issue4639] Build failure on OpenBSD 4.4-current regarding lstat()

Martin v. Löwis added the comment: Can you please try the Python trunk (or release26-maint branch) and report whether the problem still occurs? -- nosy: +loewis ___ Python tracker <http://bugs.python.org/issue4

[issue1212900] Python segfaults on OpenBSD (tested 3.4 and 3.5)

Changes by Martin v. Löwis : -- resolution: -> wont fix status: open -> closed ___ Python tracker <http://bugs.python.org/issue1212900> ___ ___ Python-bugs-

[issue7942] Inconsistent error types/messages for __len__ between old and new-style classes

Martin v. Löwis added the comment: I fail to see the bug in this report. What did you expect to happen instead? -- nosy: +loewis ___ Python tracker <http://bugs.python.org/issue7

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