[issue2827] IDLE 3.0a5 cannot handle UTF-8
Senthil [EMAIL PROTECTED] added the comment: I was NOT able to Reproduce it in IDLE 3.0b2 running on Linux. Would you like to try with 3.0b2 and also do. tjreedy: I did not properly get your comment. When you open Idle instance and create a new Document, cut-paste the code, and Run. The Execution happens in the IDLE instance which was running. No need of input() call. -- nosy: +orsenthil ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2827 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3532] bytes.tohex method
Martin v. Löwis [EMAIL PROTECTED] added the comment: You did the 3.1 thing again! We can accept a new feature like this before 3.0b3, can we not? Not without explicit approval by the release manager, no (or by BDFL pronouncement). The point of the betas is that *only* bugs get fixed, and *no* new are features added. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3532 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3300] urllib.quote and unquote - Unicode issues
Matt Giuca [EMAIL PROTECTED] added the comment:
Guido suggested that quote's safe parameter should allow any
character, not just ASCII range. I've implemented this now. It was a lot
messier than I imagined.
The problem is that in my older patches, both 's' and 'safe' are encoded
to bytes right away, and the rest of the process is just octet encoding
(matching each byte against the safe set to see whether or not to quote it).
The new implementation requires that you delay encoding both of these
till the iteration over the string, so you match each *character*
against the safe set, then encode it if it's not in 'safe'. Now the
problem is some encodings/errors produce bytes which are in the safe
range. For instance quote('\u6f22', encoding='latin-1',
errors='xmlcharrefreplace') should give %26%2328450%3B (which is
#28450; encoded). To preserve this behaviour, you then have to check
each *byte* of the encoded character against a 'safe bytes' set. I
believe that will slow down the implementation considerably.
In summary, it requires two levels of encoding: first characters, then
bytes. You can see how messy it made my quote implementation - I've
attached the patch (parse.py.patch8+allsafe).
I don't think it's worth the extra code bloat and performance hit just
to implement a feature whose only use is producing invalid URIs (since
URIs are supposed to only have ASCII characters). Does anyone disagree,
and want this feature in?
Added file: http://bugs.python.org/file11092/parse.py.patch8+allsafe
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3300
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3533] mac 10.4 buld of 3.0 --with-pydebug fails no __eprintf
Martin v. Löwis [EMAIL PROTECTED] added the comment: This might be a duplicate of issue 1099. Can you try building with --enable-universalsdk ? __eprintf should have been defined in libgcc, or else assert() should not call it. To investigate this further, you should determine how many copies of assert.h you have, whether they all refer to __eprintf, how many copies of libgcc you have, whether they all define __eprintf, and which header file and which library gets used. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3533 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3160] Building a Win32 binary installer crashes
Senthil [EMAIL PROTECTED] added the comment: What is the expected encoding of the pre_install_script file? I think, the pre_install_script will be provided by the user. It would be safe to assume UTF-8 for the encoding of pre_install_script -- nosy: +orsenthil ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3160 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3300] urllib.quote and unquote - Unicode issues
Matt Giuca [EMAIL PROTECTED] added the comment: Made a bunch of requested changes (I've reverted the all safe patch for now since it caused so much grief; see above). * quote: Fixed encoding illegal % sequences (and lots of new test cases to prove it). * quote now throws a type error if s is bytes, and encoding or errors supplied. * A few minor documentation fixes. Patch 9. Commit log for patch8 should suffice. Added file: http://bugs.python.org/file11093/parse.py.patch9 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3300 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3532] bytes.tohex method
Senthil [EMAIL PROTECTED] added the comment:
* scriptor Matt Giuca, explico
I think the biggest problem I have is the existence of fromhex. It's
really strange/inconsistent to have a fromhex without a tohex.
Except, when we look at the context. This is bytes class
method returns a bytes or bytearray object, decoding the given string object.
Do we require an opposite in the bytes class method? Where will we use it?
Also I think a lot of people (like me, in my relative inexperience) are
going to be at a loss as to why .encode('hex') went away, and they'll
No, it is not going away. str.encode('hex') is available to users when they
seek it. They wont look for it under bytes type.
--
nosy: +orsenthil
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3532
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3532] bytes.tohex method
Matt Giuca [EMAIL PROTECTED] added the comment:
Except, when we look at the context. This is bytes class
method returns a bytes or bytearray object, decoding the given
string object.
Do we require an opposite in the bytes class method? Where will
we use it?
No, tohex is not a class method (unlike fromhex). It's just a regular
method on the bytes object.
No, it is not going away. str.encode('hex') is available to
users when they seek it. They wont look for it under bytes type.
'hello'.encode('hex')
LookupError: unknown encoding: hex
This is deliberate, I'm pretty sure. encode/decode are for converting
to/from unicode strings and bytes. It never made sense to have hex in
there, which actually goes the other way. And it makes no sense to
encode a Unicode string as hex (since they aren't bytes). So it's good
that that went away.
I'm just saying it should have something equally accessible to replace it.
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3532
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3535] zipfile has problem reading zip files over 2GB
New submission from alonwas [EMAIL PROTECTED]: zipfile complains about Bad magic number for central directory when I give it files over 2GB. I believe the problem is that the offset for the central directory should be read as an unsigned long rather than as a signed long. Modifying structEndArchive from 4s4H2lH to 4s4H2LH (note the capital L) should probably fix it. When the offset is 2^31 you get a negative offset and the code fails to find the central directory. I'll appreciate it if someone more knowledgeable looks at the problem and the suggested fix, Thanks, Alon -- components: Library (Lib) messages: 70968 nosy: alonwas severity: normal status: open title: zipfile has problem reading zip files over 2GB type: behavior versions: Python 2.5 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3535 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3300] urllib.quote and unquote - Unicode issues
Antoine Pitrou [EMAIL PROTECTED] added the comment: Le dimanche 10 août 2008 à 07:05 +, Matt Giuca a écrit : I don't think it's worth the extra code bloat and performance hit just to implement a feature whose only use is producing invalid URIs (since URIs are supposed to only have ASCII characters). Agreed. If the QUERY_STRING is foo=w%FCt (Latin-1), with errors='strict', you get a UnicodeDecodeError when you call cgi.FieldStorage(). With errors='replace', the variable foo will be w�t. I think in general I'd rather have '�'s in my program (representing invalid user input) than exceptions, since this is usually a user input error, not a programming error. Invalid user input? What if the query string comes from filling a form? For example if I search the word numéro in a latin1 Web site, I get the following URL: http://www.le-tigre.net/spip.php?page=rechercherecherche=num%E9ro ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3300 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3300] urllib.quote and unquote - Unicode issues
Matt Giuca [EMAIL PROTECTED] added the comment: Invalid user input? What if the query string comes from filling a form? For example if I search the word numéro in a latin1 Web site, I get the following URL: http://www.le-tigre.net/spip.php?page=rechercherecherche=num%E9ro Yes, that is a concern. I suppose the idea should be that as the programmer _you_ write the website, so you make it UTF-8 and you use our defaults. Or you make it Latin-1, and you override our defaults (which is tricky if you use cgi.FieldStorage, for example). But anyway, how do you propose to handle that (other than the programmer setting the correct default). With errors='replace', the above query will result in num�ro, but with errors='strict', it will result in a UnicodeDecodeError (which you could handle, if you remembered). As a programmer I don't really want to handle that error every time I use unquote or anything that calls unquote. I'd rather accept the possibility of '�'s in my input. I'm not going to dig in my heels though, this time :) I just want to make sure the consequences of this decision are known before we commit. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3300 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1342811] Tkinter.Menu.delete doesn't delete command of entry
Robert Schuppenies [EMAIL PROTECTED] added the comment: Fixed in r65622. Backported to the release25-maint and merged into the py3k branch. -- resolution: accepted - fixed status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1342811 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3536] case conversion problems in Turkish
New submission from Ozan Çağlayan [EMAIL PROTECTED]:
sys.getdefaultencoding()
'utf-8'
s = 'iı'
s.upper()
'II' # should be 'İI'
t = 'Iİ'
t.lower()
'ii' # should be 'ıi'
unicodedata.name('ı') # The small dotless one
'LATIN SMALL LETTER DOTLESS I'
unicodedata.name('I') # The capital dotless one
'LATIN CAPITAL LETTER I'
unicodedata.name('i') # The small 'i'
'LATIN SMALL LETTER I'
unicodedata.name('İ') # The corresponding capital one
'LATIN CAPITAL LETTER I WITH DOT ABOVE'
The other non-ascii turkish characters 'şŞğĞöÖçÇüÜ' are correctly
handled by case conversion methods.
--
components: Unicode
messages: 70972
nosy: ozan
severity: normal
status: open
title: case conversion problems in Turkish
type: behavior
versions: Python 3.0
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3536
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3529] Remove long integer literals from Python 3.0 tutorial
Georg Brandl [EMAIL PROTECTED] added the comment: Thanks, applied in r65627. -- resolution: - fixed status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3529 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3532] bytes.tohex method
Georg Brandl [EMAIL PROTECTED] added the comment: This is why we will get transform() and untransform() in 3.1. -- nosy: +georg.brandl ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3532 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3532] bytes.tohex method
Matt Giuca [EMAIL PROTECTED] added the comment: Oh, where's the information on those? (A brief search of the peps and bug tracker shows nothing). ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3532 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3536] case conversion problems in Turkish
Georg Brandl [EMAIL PROTECTED] added the comment: Being Unicode strings, Py3k strings use the Unicode database's lowercase-uppercase mapping, which is not context sensitive. See #1528802 for more discussion. -- nosy: +georg.brandl resolution: - wont fix status: open - pending ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3536 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1288615] Python code.interact() and UTF-8 locale
STINNER Victor [EMAIL PROTECTED] added the comment: @kmtracey: Great and thanks! Three years later, the bug is finally fixed :-) ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1288615 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3532] bytes.tohex method
Georg Brandl [EMAIL PROTECTED] added the comment: At the moment, mails on python-dev are the only source of information :) Look here: http://mail.python.org/pipermail/python-3000/2008-August/014533.html ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3532 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3532] bytes.tohex method
Matt Giuca [EMAIL PROTECTED] added the comment: OK thanks. Well I still can't really see what transform/untransform are about. Is it OK to keep this issue open (and listed as 3.1) until more information becomes available on those methods? ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3532 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3532] bytes.tohex method
Georg Brandl [EMAIL PROTECTED] added the comment: They are meant to replace encode/decode for those 2.x codecs that didn't really encode/decode Unicode. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3532 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3532] bytes.tohex method
Matt Giuca [EMAIL PROTECTED] added the comment: So I assumed. In that case, why is there a fromhex? (Was that put in there before the notion of transform/untransform?) As I've been saying, it's weird to have a fromhex but not a tohex. Anyway, assuming we go to 3.1 and add transform/untransform, I suppose fromhex will remain for backwards, and tohex will not be needed. So I guess this issue is closed. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3532 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2578] Figure out what to do with unittest's redundant APIs
J. Pablo Fernández [EMAIL PROTECTED] added the comment: Is there anything that can be done now about this issue? like renaming the API and leaving the old names as aliases? If so, let me know and I'll try to work on it. -- nosy: +pupeno ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2578 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3533] mac 10.4 buld of 3.0 --with-pydebug fails no __eprintf
Barry Alan Scott [EMAIL PROTECTED] added the comment: I have Xcode 2.3 which is quite old. Simple program to test assert works with my current setup. I'm going to update to Xcode 2.5 and see what happens. I'll report back once I've installed and rebuild python. Added file: http://bugs.python.org/file11094/config.log ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3533 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3533] mac 10.4 buld of 3.0 --with-pydebug fails no __eprintf
Barry Alan Scott [EMAIL PROTECTED] added the comment: Xcode 2.5 solves the build issue. I suspect you can close the 1099 saying use Xcode 2.5. I think you can only get 2.5 by login in to the Apple developer site. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3533 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3097] sphinx: config option for exclude_dirnames
Georg Brandl [EMAIL PROTECTED] added the comment: Added in r65632. -- resolution: - accepted status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3097 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3533] mac 10.4 buld of 3.0 --with-pydebug fails no __eprintf
Changes by Martin v. Löwis [EMAIL PROTECTED]: -- resolution: - works for me status: open - closed versions: +3rd party -Python 3.0 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3533 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1099] Mac compile fails with pydebug and framework enabled
Martin v. Löwis [EMAIL PROTECTED] added the comment: Can you please try XCode 2.5? See issue 3533 for a report that says that upgrading solved the problem. -- nosy: +loewis ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1099 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3535] zipfile has problem reading zip files over 2GB
Martin v. Löwis [EMAIL PROTECTED] added the comment: What Python version exactly are you using? This might have been fixed in 2.5.2, with r60117. -- nosy: +loewis ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3535 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2841] Windows: Runtime Error! crash from pythonw.exe (3.0a5)
Terry J. Reedy [EMAIL PROTECTED] added the comment: I am closing this as 'out of date' because the problem went away in .b1 and is still gone in .b2. There is still, however, a crash problem if a file is run with utf-8. See http://bugs.python.org/issue2827 -- resolution: - out of date status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2841 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2827] IDLE 3.0a5 cannot handle UTF-8
Terry J. Reedy [EMAIL PROTECTED] added the comment: When one runs a file with Python30.exe, it opens a window, runs the file, and closes the window too fast to see what happened. The point of the input() statements is to 'pause' execution. This is standard debugging along with print()/write() statements. With three input()s, I determined that CPython compiled the file, executed the def statement, and failed the function call (due, I presume, to the requested disk file not being present). IDLE, on the other hand, crashed before getting to the first input() before the function def. So it crashed while compiling the file -- or as a result of trying to execute input(). I just tried cut and paste into the IDLE shell window (without the encoding cookie) and it runs as expected, giving IOError: [Errno 2] No such file or directory: 'slovník.txt' Retrying with the cookie gives the same. I have no idea if it is recognized in interactive mode or if interactive mode is utf8 by default. I just tried running from a file without the coding line and IDLE crashed again. So the problem is reading from a file on Windows. IDLE is doing *something* different than bare CPython. Actually, it uses pythonw30.exe rather that python.exe, but when I replace the input statements with file write statements (input raises error with pythonw), pythonw also executed through to the def statement. But I still suspect something in the interaction between IDLE and pythonw. There was a another problem with IDLE and pythonw in .a5 http://bugs.python.org/issue2841 which seems to have disappeared without being officially fixed. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2827 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3537] dict creation failure causes crash
New submission from Roger Upole [EMAIL PROTECTED]:
If the first item can't be inserted the interpreter will crash
eventually.
while 1:
try:
d = { 'a':a,
'b':'b',
'c':'c',
'd':'d',
'e':'e',
'f':'f',
'g':'g',
'h':'h',
'i':'i',
'j':'j',
'k':'k',
'l':'l',
'm':'m',
'n':'n',
'o':'o'
}
except:
pass
As best I can tell, this only happens for the first item.
In a debug build, this assert fails on the second time thru
the loop (dictobject.c, line 247):
assert (mp-ma_table == mp-ma_smalltable);
Apparently something is leaving one of the entries in the list
of preallocated dict objects in an inconsistent state.
--
messages: 70990
nosy: rupole
severity: normal
status: open
title: dict creation failure causes crash
versions: Python 3.0
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3537
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3537] dict creation failure causes crash
Georg Brandl [EMAIL PROTECTED] added the comment: Also happens in trunk. -- nosy: +georg.brandl versions: +Python 2.6 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3537 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3537] dict creation failure causes crash
Georg Brandl [EMAIL PROTECTED] added the comment: The problem is that PyDict_New doesn't reinitialize the fields of a dict from the free list when the number of entries is zero. For a preconstructed dict (like created by BUILD_MAP) of size =8, however, there will be an allocated ma_table and ma_mask will be 16-1, not 8-1. I propose the attached patch. -- keywords: +patch Added file: http://bugs.python.org/file11095/dictobj.diff ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3537 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1099] Mac compile fails with pydebug and framework enabled
Elias Pipping [EMAIL PROTECTED] added the comment: Configuring with '--with-pydebug --enable-framework --enable-universalsdk' (and invoking make afterwards) certainly works now for me. I'm running XCode 3.1 -- or more importantly 'i686-apple-darwin9-gcc-4.0.1 (GCC) 4.0.1 (Apple Inc. build 5484)' -- on OS X 10.5.4. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1099 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3160] Building a Win32 binary installer crashes
Viktor Ferenczi [EMAIL PROTECTED] added the comment: Is forcing the encoding as UTF-8 backwards compatible? It should be at least noted somewhere if this change could render existing setup scripts incompatible with Python 3.0. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3160 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3533] mac 10.4 buld of 3.0 --with-pydebug fails no __eprintf
Barry Alan Scott [EMAIL PROTECTED] added the comment: Grr... this problem is a pain... I have the __eprint undefined back... I tried to get readline going as well and rebuilt. Couldn't get that working then rebuilt without readline stuff and got the __eprintf. I'm goint to have to give up on devleoping this on Mac and move to linux. I don't have the spare time to get to the bottom of this problem. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3533 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3538] Docstring typos
New submission from Rambo007 [EMAIL PROTECTED]: Hello. I was pokinf around in the Python 3.0b2 interpreter and I found some typos in the following doctring: import sys; print(sys.platform.__doc__) str(string[, encoding[, errors]]) - str Create a new string object from the given encoded string. encoding defaults to the current default string encoding. errors can be 'strict', 'replace' or 'ignore' and defaults to 'strict'. Please fix the docstring words 'encoding' and 'errors' to have the capital initial letter, so that the docstring would look like this: str(string[, encoding[, errors]]) - str Create a new string object from the given encoded string. Encoding defaults to the current default string encoding. Errors can be 'strict', 'replace' or 'ignore' and defaults to 'strict'. Please fix other similar typos if you find them. Thank you. -- assignee: georg.brandl components: Documentation messages: 70996 nosy: Rambo007, georg.brandl severity: normal status: open title: Docstring typos versions: Python 3.0, Python 3.1 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3538 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3538] Docstring typos
Guilherme Polo [EMAIL PROTECTED] added the comment: 'encoding' and 'errors' refers to the names of the arguments accepted by str, this is not a typo. -- nosy: +gpolo resolution: - invalid status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3538 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3539] Problem with pgen make dependencies in certain circumstances
New submission from Skip Montanaro [EMAIL PROTECTED]: I usually build Python directly in my source repository (the directory containing the configure script). Accordingly, I have .o files scattered throughout my sandbox. Today I decided to build --with-pydebug, so I created a debug directory, then ran ../configure from within that directory, giving the arguments I wanted. When I ran make it croaked with a link error linking pgen. The linker complained that tokenizer_pgen.o and pgenmain.o weren't found. Messing around with make -d I figured out that when make ran it concluded that Parser/pgenmain.o didn't need to be rebuilt. It thought that ../Parser/pgenmain.o satisfied the dependency for Parser/pgenmain.o. I don't know if this is a problem with GNU make's VPATH processing or with the dependency specification in Python's makefile. I can work around the problem by avoiding builds directly in my sandbox but it would be nice if this worked. (I'm experiencing a sense of deja vu. Perhaps I've reported this problem sometime in the dim, dark past, but I can't find anything searching for either VPATH or makefile.) -- components: Build messages: 70998 nosy: skip.montanaro severity: normal status: open title: Problem with pgen make dependencies in certain circumstances versions: Python 2.6 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3539 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3499] Python 2.6 requires pre-installed Python to build
Jed Smith [EMAIL PROTECTED] added the comment: This happened in my fresh unpack of the 3.0b2 tarball, as well. Touching merely Include/Python-ast.h satisfied the dependency, and I did not have to touch Python-ast.c. Is the particular grammar-rebuild rule needed for production tarballs anyway? I can't think the majority of people downloading the package want to start hacking the grammar right away. -- nosy: +jedsmith versions: +Python 3.0 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3499 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1533164] Installed but not listed *.pyo break bdist_rpm
Changes by Tim Wegener [EMAIL PROTECTED]: -- nosy: +twegener versions: +Python 2.5 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1533164 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2389] Array pickling exposes internal memory representation of elements
Alexandre Vassalotti [EMAIL PROTECTED] added the comment: I don't see why this cannot be fixed easily. All we need to do is fix the __reduce__ method of array objects to emit a list--i.e. with array.tolist()--instead of a memory string. Since the reduce protocol is just a fancy way to store the constructor arguments, this won't break unpickling of array objects pickled by previous Python versions. And here is a patch against the trunk. -- keywords: +patch nosy: +alexandre.vassalotti Added file: http://bugs.python.org/file11096/fix_array_pickling.patch ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2389 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3514] pickle segfault with infinite loop in __getattr__
Alexandre Vassalotti [EMAIL PROTECTED] added the comment:
This is a bug in the C implementation of pickle (i.e., the _pickle
module). I think you're right about the missing exception check. At
first glance, it looks like the missing else-if case for setstate ==
NULL, in load_build(), is the cause of the problem:
static int
load_build(UnpicklerObject *self)
{
...
setstate = PyObject_GetAttrString(inst, __setstate__);
if (setstate == NULL PyErr_ExceptionMatches(PyExc_AttributeError)) {
PyErr_Clear();
}
/*---missing else-if case-
else if (setstate == NULL) {
return NULL;
}
--*/
else {
PyObject *result;
/* The explicit __setstate__ is responsible for everything. */
result = unpickler_call(self, setstate, state);
Py_DECREF(setstate);
if (result == NULL)
return -1;
Py_DECREF(result);
return 0;
}
...
--
nosy: +alexandre.vassalotti
priority: - normal
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3514
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
