[issue3238] backport python 3.0 language functionality to python 2.6 by adding 7 opcodes to ceval.c
Changes by kai zhu [EMAIL PROTECTED]: Added file: http://bugs.python.org/file11844/py3to2.py ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3238 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3890] ssl.SSLSocket.recv() implementation may not work with non-blocking sockets
Changes by Dmitry Dvoinikov [EMAIL PROTECTED]: -- nosy: +ddvoinikov ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3890 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2231] Memory leak in itertools.chain()
Raymond Hettinger [EMAIL PROTECTED] added the comment: The affected code did not exist in Py2.5. The patch made it to both Py2.6 and Py3.0. Closing. -- status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2231 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3238] backport python 3.0 language functionality to python 2.6 by adding 7 opcodes to ceval.c
kai zhu [EMAIL PROTECTED] added the comment: hi, i'm happy i got a response on this :) anyway, can u elaborate on the reason y something like this was never done? yes, i kno the patch is rough right now ( will never get accepted in its current state), but its now proven to work, gives migrating developers *something* to test their py3k_syntax code while *still* maintaining compatibility w/ python2.x extension modules. isn't that the spirit of python 2.7? in the meantime, i'm in no hurry to have anything committed. Added file: http://bugs.python.org/file11845/example_py3k.py ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3238 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2980] Pickle stream for unicode object may contain non-ASCII characters.
Dan Dibagh [EMAIL PROTECTED] added the comment:
Your reasoning shows a lack of understanding how Python is actually used
from a programmers point of view.
Why do you think that noticing a problem is the same thing as entering
as a python bug report? In practice there are several steps between
noticing a problem in a python program and entering it as a bug report
in the python development system. It is very difficult so see why any of
these steps would happen automatically. Believe me, people have had real
problems due to this bug. They have just selected other solutions than
reporting it.
You are yourself reluctant so seek out the roots of this problem and fix
it. Why should other people behave differently and report it? A not so
uncommon fix to pickle problems out there is to not using pickle at
all. There are Python programmers who gives the advice to avoid pickle
since it's too shaky. It is a solution, but is it the solution you
desire?
The capability to serialize stuff into ASCII strings isn't just an
implementation detail that happens to be nice for human readability. It
is a feature people need for technical reasons. If the data is ASCII, it
can be dealt with in any ASCII-compatible context which might be network
protocols, file formats and database interfaces. There is the real use.
Programs depend on it to work properly.
The solution the change the documentation is in practice breaking
compatibility (which programming language designers normally tries to
avoid or do in a very controlled manner). How is a documentation fix
going to help all the code out there written with the assumption that
pickle protocol 0 is always ASCII? Is there a better solution around
than changing pickle to meet actual expectations?
Well, nobody has reported it as a bug in 8 years. How long do you think
that code will stay around based on the ASCII assumption? 8 years? 16
years? 24 years? Maybe all the time in the world for this to become an
issue again and again and again?
It is difficult to grasp why there is no way to fix it now. From a
programmers point of view an obvious fix is to ditch pickle and use
something that delivers a consistent result rather than debugging hours.
When I try to see it from the Python library developers point of view I
see code implemented in C which produces a result with reasonable
performance. It is perfectly possible to write the code which implements
the expected result within reasonable performance. What is the problem?
Perhaps it is the raw-unicode-escape encoding that should be fixed? I
failed to find exact information about what raw-unicode-escape means. In
particular, where is the information which states that
raw-unicode-escape is always an 8-bit format? The closest I've come is
PEP 100 and PEP 263 (which I notice is written by you guys), which
describes how to decode raw unicode escape strings from Python source
and how to define encoding formats for python source code. The sole
original purpose of both unicode-escape and raw-unicode-escape appears
to be representing unicode strings in Python source code as u' and ur'
strings respectively. It is clear that the decoding of a raw unicode
escaped or unicode escaped string depends on the actual encoding of the
python source, but how goes the logic that when something is _encoded_
into a raw unicode string then the target source must be of some 8-bit
encoding. Especially considering that the default python source encoding
is ASCII. For unicode-escape this makes sense:
f = file(test.py, wb)
f.write('s = u%s\n' % u\u0080.encode(unicode-escape))
f.close()
^Z
python test.py (executes silently without errors)
But for raw-unicode-escape the outcome is a different thing:
f = file(test.py, wb)
f.write('s = ur%s\n' % u\u0080.encode(raw-unicode-escape))
f.close()
^Z
python test.py
File test.py, line 1
SyntaxError: Non-ASCII character '\x80' in file test.py on line 1, but
no encoding declared; see http://www.python.org/peps/pep-0263.html for
details
Huh? For someone who trusts the Standard Encodings section Python
Library reference this isn't what one would expect. If the documentation
states Produce a string that is suitable as raw Unicode literal in
Python source code then why isn't it suitable?
--
nosy: +dddibagh
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2980
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2980] Pickle stream for unicode object may contain non-ASCII characters.
Marc-Andre Lemburg [EMAIL PROTECTED] added the comment:
On 2008-10-21 11:22, Dan Dibagh wrote:
Your reasoning shows a lack of understanding how Python is actually used
from a programmers point of view.
Hmm, I've been using Python for almost 15 years now and do believe
that I have an idea of how Python is being used.
Note that we cannot change the pickle format in retrospective, since
this would break pickle data exchange between different Python versions
relying on the same format (but using different pickle implementations).
What we could do is add a new pickle format which then escapes all
non-ASCII data. However, people have been more keen on getting
compact and fast loading pickles than pickles in ASCII which is why
all new versions of the pickle format are binary formats, so I don't
think it's worth the effort.
Note that the common way of dealing with binary data in ASCII streams
is using a base64 encoding and possibly also apply compression. The
pickle 0 format is really only useful for debugging purposes.
Perhaps it is the raw-unicode-escape encoding that should be fixed? I
failed to find exact information about what raw-unicode-escape means. In
particular, where is the information which states that
raw-unicode-escape is always an 8-bit format? The closest I've come is
PEP 100 and PEP 263 (which I notice is written by you guys), which
describes how to decode raw unicode escape strings from Python source
and how to define encoding formats for python source code. The sole
original purpose of both unicode-escape and raw-unicode-escape appears
to be representing unicode strings in Python source code as u' and ur'
strings respectively.
Right.
It is clear that the decoding of a raw unicode
escaped or unicode escaped string depends on the actual encoding of the
python source, but how goes the logic that when something is _encoded_
into a raw unicode string then the target source must be of some 8-bit
encoding. Especially considering that the default python source encoding
is ASCII. For unicode-escape this makes sense:
f = file(test.py, wb)
f.write('s = u%s\n' % u\u0080.encode(unicode-escape))
f.close()
^Z
python test.py (executes silently without errors)
But for raw-unicode-escape the outcome is a different thing:
f = file(test.py, wb)
f.write('s = ur%s\n' % u\u0080.encode(raw-unicode-escape))
f.close()
^Z
python test.py
File test.py, line 1
SyntaxError: Non-ASCII character '\x80' in file test.py on line 1, but
no encoding declared; see http://www.python.org/peps/pep-0263.html for
details
Huh? For someone who trusts the Standard Encodings section Python
Library reference this isn't what one would expect. If the documentation
states Produce a string that is suitable as raw Unicode literal in
Python source code then why isn't it suitable?
Because the raw-unicode-escape codec won't escape the \x80 character,
hence the name. As a result, the generated source code is not ASCII,
which is why you see the exception.
But this is off-topic w/r to the issue in question.
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2980
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4156] Docs for BaseHandler.protocol_xxx methods are unclear
New submission from Kent Johnson [EMAIL PROTECTED]: In the docs for urllib2.BaseHandler previous to Python 2.6, the names of the protocol_xxx() methods were spelled with 'protocol' in italics to indicate that it is a placeholder; the actual method name is e.g. http_opener(). http://www.python.org/doc/2.5.2/lib/base-handler-objects.html In the Python 2.6 docs this typographic distinction has been lost http://docs.python.org/library/urllib2.html#basehandler-objects so it is not so clear that e.g. protocol_open() is not an actual method. I suggest either restoring the italics or using a spelling such as protocol_open() for the method names. If this is difficult then the body of the descriptions should be rewritten to make it clear that the 'given protocol' is indicated by the name of the method. -- assignee: georg.brandl components: Documentation messages: 75023 nosy: georg.brandl, kjohnson severity: normal status: open title: Docs for BaseHandler.protocol_xxx methods are unclear versions: Python 2.6 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4156 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4157] Tuple not callable in platform.py
New submission from Feite Jaarsma [EMAIL PROTECTED]:
The function 'def _test_parse_release_file()' has a for statement with
a tuple as iter in it (examples of release file contents). This tuple
is not a tuple. There is a ',' missing on every line (marked by '*'):
for input, output in (
# Examples of release file contents:
('SuSE Linux 9.3 (x86-64)', ('SuSE Linux ', '9.3', 'x86-64'))*
('SUSE LINUX 10.1 (X86-64)', ('SUSE LINUX ', '10.1', 'X86-64'))*
('SUSE LINUX 10.1 (i586)', ('SUSE LINUX ', '10.1', 'i586'))*
('Fedora Core release 5 (Bordeaux)', ('Fedora
Core', '5', 'Bordeaux'))*
('Red Hat Linux release 8.0 (Psyche)', ('Red Hat
Linux', '8.0', 'Psyche'))*
('Red Hat Linux release 9 (Shrike)', ('Red Hat
Linux', '9', 'Shrike'))*
('Red Hat Enterprise Linux release 4 (Nahant)', ('Red Hat
Enterprise Linux', '4', 'Nahant'))*
('CentOS release 4', ('CentOS', '4', None))*
('Rocks release 4.2.1 (Cydonia)', ('Rocks', '4.2.1', 'Cydonia'))
):
--
components: Library (Lib)
messages: 75024
nosy: Feite
severity: normal
status: open
title: Tuple not callable in platform.py
type: compile error
versions: Python 2.6
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4157
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3238] backport python 3.0 language functionality to python 2.6 by adding 7 opcodes to ceval.c
Guido van Rossum [EMAIL PROTECTED] added the comment: This doesn't sound like it will ever be reliable. Kai Zhu, a better strategy would be for you to maintain your own experimental port of Python 2.6+3.0 based upon these patches. -- resolution: - rejected status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3238 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4157] Tuple not callable in platform.py
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment: Correct. Fortunately this is an internal function that is not used by any other code. It should be corrected and moved to the test suite. -- assignee: - amaury.forgeotdarc nosy: +amaury.forgeotdarc ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4157 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4158] import of sqlite3 fails
New submission from Jacques Lemire [EMAIL PROTECTED]: This is a dump of the error: Python 3.0rc1 (r30rc1:66499, Oct 6 2008, 12:44:02) [GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2 Type help, copyright, credits or license for more information. import sqlite3 Traceback (most recent call last): File stdin, line 1, in module File /home/devp/altBIN/Python3r/lib/python3.0/sqlite3/__init__.py, line 24, in module from sqlite3.dbapi2 import * File /home/devp/altBIN/Python3r/lib/python3.0/sqlite3/dbapi2.py, line 27, in module from _sqlite3 import * ImportError: No module named _sqlite3 -- components: Library (Lib) messages: 75027 nosy: jlp severity: normal status: open title: import of sqlite3 fails type: crash versions: Python 3.0 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4158 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4159] Table about Standard Encodings is cut off at the bottom - 35 entries missing
New submission from Winfried Plappert [EMAIL PROTECTED]: library.pdf - Chapter 8.8.3 deals with Standard Encodings. There is a long table which is massively overshooting the bottom of the page (page 110) in the PDF-A4 version. About 35 rows in the table get completely lost - compared to the HTML version at http://docs.python.org/library/codecs.html. -- assignee: georg.brandl components: Documentation messages: 75028 nosy: georg.brandl, wplappert severity: normal status: open title: Table about Standard Encodings is cut off at the bottom - 35 entries missing type: behavior versions: Python 2.6 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4159 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4160] library.pdf - Section 12.13.2 Connection Objects - example cut off at the right hand side
New submission from Winfried Plappert [EMAIL PROTECTED]: in the Python 2.6 PDF-documentation, the example followong the text_factory is incomplete, because it is cut off at the right hand side of the text. HTML-version: http://docs.python.org/library/sqlite3.html I include the relevant line from the HTML-version: cur.execute(select ?, (this is latin1 and would normally create errors + u\xe4\xf6\xfc.encode(latin1),)) . This line should probably be split, so the text cannot run off at the right edge. -- assignee: georg.brandl components: Documentation messages: 75029 nosy: georg.brandl, wplappert severity: normal status: open title: library.pdf - Section 12.13.2 Connection Objects - example cut off at the right hand side versions: Python 2.6 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4160 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4159] Table about Standard Encodings is cut off at the bottom - 35 entries missing
Winfried Plappert [EMAIL PROTECTED] added the comment: Can also be seen on 3.0rc1 if the PDF documents are built 'by hand'. -- versions: +Python 3.0 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4159 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4161] test_urllib fails with ValueError
New submission from Zsolt Cserna [EMAIL PROTECTED]: test_urllib regression test fails with ValueError on linux (kernel 2.4, glibc 2.3): test_urllib test test_urllib failed -- Traceback (most recent call last): File /tmp/x/Lib/test/test_urllib.py, line 112, in tearDown for k, v in self._saved_environ: ValueError: too many values to unpack I think the fix is trivial, but I've attached the patch. If this bug has been already fixed, sorry for reporting it. -- files: test_urllib.patch keywords: patch messages: 75031 nosy: csernazs severity: normal status: open title: test_urllib fails with ValueError type: behavior versions: Python 2.6 Added file: http://bugs.python.org/file11846/test_urllib.patch ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4161 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4159] Table about Standard Encodings is cut off at the bottom - 35 entries missing
Winfried Plappert [EMAIL PROTECTED] added the comment: Another example is chapter 16.8.3 GENERIC OPERATING SYSTEM SERVICES::curses — Terminal handling for character-cell displays::Constants. The table on page 442 again misses about 35 entries completely. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4159 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4162] library.pdf - Section 17.6.4 Examples - Multiprocessing - Formatting got lost
New submission from Winfried Plappert [EMAIL PROTECTED]: There is a very long (last) example following the paragraph which starts with the words: An example/demo of how to use the managers.SyncManager, Process and others The formatting that this an example somehow got lost and the PDF text becomes very sparse. I will attach a png file later. The HTML documentation recognizes it as an example and formats it correctly. -- assignee: georg.brandl components: Documentation messages: 75033 nosy: georg.brandl, wplappert severity: normal status: open title: library.pdf - Section 17.6.4 Examples - Multiprocessing - Formatting got lost type: behavior versions: Python 2.6 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4162 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4160] library.pdf - Section 12.13.2 Connection Objects - example cut off at the right hand side
Changes by Winfried Plappert [EMAIL PROTECTED]: -- components: +Documentation tools (Sphinx) -Documentation ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4160 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4159] Table about Standard Encodings is cut off at the bottom - 35 entries missing
Changes by Winfried Plappert [EMAIL PROTECTED]: -- components: +Documentation tools (Sphinx) -Documentation ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4159 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4162] library.pdf - Section 17.6.4 Examples - Multiprocessing - Formatting got lost
Changes by Winfried Plappert [EMAIL PROTECTED]: -- components: +Documentation tools (Sphinx) -Documentation ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4162 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4145] tabulary entries in PDF documentation
Changes by Winfried Plappert [EMAIL PROTECTED]: -- components: +Documentation tools (Sphinx) -Documentation ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4145 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4158] compilation of sqlite3 fails
Brett Cannon [EMAIL PROTECTED] added the comment: Looks like sqlite3 was not compiled for you. To verify, run ``make`` again and note what modules it lists at the very end as not built. I bet it lists sqlite3 there. -- nosy: +brett.cannon title: import of sqlite3 fails - compilation of sqlite3 fails type: crash - compile error ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4158 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4120] Do not embed manifest files in *.pyd when compiling with MSVC
Koen van de Sande [EMAIL PROTECTED] added the comment: Instead of reverting the patch for Issue 2563, I propose to strip the VC90 runtimes from the manifest (this will preserve other dependencies needed). I checked this by editing tk85.dll and replacing the dependency there with white-space - the Windows Common Controls dependency still worked properly after this. I've attached a patch to strip the runtime from the manifest when building Python extensions (through search/replace). I think somehow the manifests of the .pyd's in DLLs should also be edited, because leaving them out will cause problems if this is done when building tk85.dll. Or perhaps only special care is needed if there ever is a .pyd with additional dependencies? All files with the .pyd extension do not rely on anything else. I don't know enough about the build process to suggest a change for this, except that the build config for the .dll files inside DLLs might also need to be changed. Added file: http://bugs.python.org/file11847/msvc9compiler_stripruntimes.diff ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4120 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3997] zipfile and winzip
vali [EMAIL PROTECTED] added the comment: Thank you for the quick fix. I could verify that the issue is fixed in python 2.6 when I use WinZip to open an archive with more than 2^16 files created with attached script (bug.py). However the windows native compress utility does not seem to be able to recognize the files that have more than 2^16 files (the error says that the archive is not valid). However, if I try to create an archive using WinZip or 7zip with exactly the same files, windows compress utility is able to open the archive. The same thing would apply if I create the archive using zlib C# library. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3997 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4163] textwrap wordsep_re Unicode
New submission from Sebastian Kirsche [EMAIL PROTECTED]: The attached patch makes textwrap work with strings containing dashes and Unicode alphabetic characters. In addition, it fixes the test case for issue 1149508, which no longer failed after temporarily undoing the corresponding change. Example 1: print textwrap.fill(u'Die Empfänger-Auswahl', 13) Output without patch: Die Empf änger-Auswahl With patch: Die Empfänger- Auswahl Example 2: print textwrap.fill(u'aa ää-ää', 7) Output without patch: aa ää-ää With patch: aa ää- ää -- components: Library (Lib) files: textwrap-umlauts.patch keywords: patch messages: 75037 nosy: skirsche severity: normal status: open title: textwrap wordsep_re Unicode type: behavior versions: Python 2.5, Python 2.5.3, Python 2.6, Python 2.7 Added file: http://bugs.python.org/file11848/textwrap-umlauts.patch ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4163 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4164] String double quoted fatal problem
New submission from Felipe [EMAIL PROTECTED]: Hi I have a problem with python 2.6, when i try to process strings with triple-quoted string literal i get an error: a='a''a' #1 double quoted Ok a='aa' # 2 Ok a= 'a''a' # 3 doble quoted -- SyntaxError: EOF while scanning triple-quoted string literal a= 'aa' # 4 ok a='a''a' # 5 same error impair doble quoted a='aa' # 6 Ok... a... #7 error.. -- components: Library (Lib) messages: 75038 nosy: cliffdover88 severity: normal status: open title: String double quoted fatal problem type: compile error versions: Python 2.6 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4164 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4165] Failure building 64-bit Python on Leopard
New submission from Anand Patil [EMAIL PROTECTED]: Configuring with sihpc03:Python-2.6 anand$ ./configure --with-framework-name=Python64 -- with-universal-archs=all --enable-framework --enable- universalsdk=MACOSX_DEPLOYMENT_TARGET=10.5 on an Intel Mac Pro with the latest Leopard and Apple gcc 4.0, I get many errors like the following instructing me to report a bug. My config.log file is attached. checking errno.h presence... yes configure: WARNING: errno.h: present but cannot be compiled configure: WARNING: errno.h: check for missing prerequisite headers? configure: WARNING: errno.h: see the Autoconf documentation configure: WARNING: errno.h: section Present But Cannot Be Compiled configure: WARNING: errno.h: proceeding with the preprocessor's result configure: WARNING: errno.h: in the future, the compiler will take precedence configure: WARNING: ## - --- ## configure: WARNING: ## Report this to http://www.python.org/python- bugs ## configure: WARNING: ## - --- ## -- components: Macintosh files: config.log messages: 75039 nosy: anand severity: normal status: open title: Failure building 64-bit Python on Leopard type: compile error versions: Python 2.6 Added file: http://bugs.python.org/file11849/config.log ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4165 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3997] zipfile and winzip
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment: OK, it seems that the central directory size and central directory offset must contain their actual value if it can fit in a 32bit int, even though the spec says If an archive is in ZIP64 format and the value in this field is 0x, the value is in the corresponding zip64 end of central directory field. Attached a new patch. The file generated by bug.py seems very similar to one generated with WinZip, and the WindowsXP explorer can now open it. Added file: http://bugs.python.org/file11850/zip-64k-2.patch ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3997 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4070] python tests failure if builddir sourcedir
Roumen Petrov [EMAIL PROTECTED] added the comment: About issue4151 - clean up is in test_sysconfig.py and setup.py - it is fine with me. Modification for test_build_ext.py from above mentioned issue break non-posix builds. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4070 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4165] Failure building 64-bit Python on Leopard
Changes by Benjamin Peterson [EMAIL PROTECTED]: -- assignee: - ronaldoussoren nosy: +ronaldoussoren ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4165 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4161] test_urllib fails with ValueError
Benjamin Peterson [EMAIL PROTECTED] added the comment: Thanks for the report! Fixed in r66992. -- nosy: +benjamin.peterson resolution: - fixed status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4161 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4165] Failure building 64-bit Python on Leopard
Roumen Petrov [EMAIL PROTECTED] added the comment: configure:5602: checking errno.h usability configure:5619: gcc-4.0 -c -arch i386 -arch ppc -arch ppc64 -arch x86_64 -isysroot MACOSX_DEPLOYMENT_TARGET=10.5 -g -O2 conftest.c 5 Binary file conftest.er1 matches configure:5625: $? = 1 It is possible gcc to compile for multiple architectures at same time ? -- nosy: +rpetrov ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4165 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3238] backport python 3.0 language functionality to python 2.6 by adding 7 opcodes to ceval.c
kai zhu [EMAIL PROTECTED] added the comment: k ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3238 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4162] library.pdf - Section 17.6.4 Examples - Multiprocessing - Formatting got lost
Winfried Plappert [EMAIL PROTECTED] added the comment: example-17.6.4.png shows two pieces of Python code, the top being good and the bottom very sparse. Added file: http://bugs.python.org/file11851/example- 17.6.4.png ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4162 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4159] Table about Standard Encodings is cut off at the bottom - 35 entries missing
Winfried Plappert [EMAIL PROTECTED] added the comment: here is the screen copy of chapter 8.8.3 Added file: http://bugs.python.org/file11852/8.8.3.png ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4159 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4164] String double quoted fatal problem
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment:
All your samples explain easily if you consider that two adjacent string
literals are joined together. (You seem to consider that double quote
is a way to insert a quote character. It's not; Python is not Pascal or
SQL)
Your first two examples become:
a='a''a' two adjacent strings == 'aa'
a='aa' three adjacent strings ('a' + '' + 'a') == 'aa'
The third is an error:
a='a''a' one string ('a') followed by the beginning of a triple
quoted string (''') which content starts with the characters (''a') but
does not have a matching (''') to finish the string, hence the Syntax
error.
... and so on. Please have a look at
http://docs.python.org/reference/lexical_analysis.html#string-literals
--
nosy: +amaury.forgeotdarc
resolution: - invalid
status: open - closed
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4164
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4160] library.pdf - Section 12.13.2 Connection Objects - example cut off at the right hand side
Winfried Plappert [EMAIL PROTECTED] added the comment: The page of chapter 12.13.2 Added file: http://bugs.python.org/file11853/12.13.2.png ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4160 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4149] Py_BuildValue and y format unit
Benjamin Peterson [EMAIL PROTECTED] added the comment: Documented in r66993. -- nosy: +benjamin.peterson ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4149 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4149] Py_BuildValue and y format unit
Changes by Benjamin Peterson [EMAIL PROTECTED]: -- resolution: - fixed status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4149 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4166] extra \fi
Changes by Eric Firing [EMAIL PROTECTED]: -- assignee: georg.brandl components: Documentation tools (Sphinx) nosy: efiring, georg.brandl severity: normal status: open title: extra \fi ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4166 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4166] extra \fi in sphinx.sty, line 62
New submission from Eric Firing [EMAIL PROTECTED]: Building the matplotlib docs using Sphinx svn 66969 results in a Latex error ending in: ) (/usr/share/texmf-texlive/tex/latex/graphics/graphicx.sty (/usr/share/texmf-texlive/tex/latex/graphics/graphics.sty (/usr/share/texmf-texlive/tex/latex/graphics/trig.sty) (/etc/texmf/tex/latex/config/graphics.cfg))) (/usr/share/texmf-texlive/tex/plain/misc/pdfcolor.tex) ! Extra \fi. l.62 \fi\fi The line 62 turns out to be in sphinx.sty; removing one \fi allows the build to proceed. The svn diff is: [EMAIL PROTECTED]:~/programs/py/sphinx_svn$ svn -x '-w' diff Index: sphinx/texinputs/sphinx.sty === --- sphinx/texinputs/sphinx.sty (revision 66993) +++ sphinx/texinputs/sphinx.sty (working copy) @@ -59,7 +59,7 @@ \ifx\ifxetex\undefined\else\ifxetex [EMAIL PROTECTED],0.0,0.0}} [EMAIL PROTECTED] -\fi\fi +\fi % Increase printable page size (copied from fullpage.sty) \topmargin 0pt -- title: extra \fi - extra \fi in sphinx.sty, line 62 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4166 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4157] Tuple not callable in platform.py
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment: Fixed with r66994. Thanks for the report! -- resolution: - fixed status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4157 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4166] extra \fi in sphinx.sty, line 62
Changes by Winfried Plappert [EMAIL PROTECTED]: -- nosy: +wplappert ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4166 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1248] ftplib needs a rewrite to use bytes/buffers
STINNER Victor [EMAIL PROTECTED] added the comment: Function result type should be the same of the connection is in text mode or binary mode. As far as I remember, the text mode converts the newline byte sequence, not the charset. A text file could be stored as latin-1, utf-8, koi-8 or anything else. Am I wrong? ftplib should use byte strings (as I did for POP3, IMAP4 or some other libraries) because the FTP protocol doesn't send the charset. -- nosy: +haypo ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1248 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4092] inspect.getargvalues return type not ArgInfo
Benjamin Peterson [EMAIL PROTECTED] added the comment: Thanks for the report. Fixed in r66995. -- nosy: +benjamin.peterson resolution: - fixed status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4092 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3890] ssl.SSLSocket.recv() implementation may not work with non-blocking sockets
Josiah Carlson [EMAIL PROTECTED] added the comment: I agree with Giampaolo. In the case of non-blocking sockets, if reading from the ssl stream fails because there is no data on the socket, then sitting in a while loop is just going to busy-wait until data is discovered. Never mind that the reference to sendall should be replaced by recv. Whether to 'continue' or 'raise' should be determined by whether the socket is blocking. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3890 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2980] Pickle stream for unicode object may contain non-ASCII characters.
Dan Dibagh [EMAIL PROTECTED] added the comment: I am well aware why my example produces an error from a technical standpoint. What I'm getting at is the decision to implement PyUnicode_EncodeRawUnicodeEscape the way it is. Probably there is nothing wrong with it, but how am I supposed to know? I read the PEP, which serves as a specification of raw unicode escape (at least for the decoding bit) and the reference documentation. Then I read the source trying to map between specified behavior in the documentation and the implementation in the source code. When it comes to the part which causes the problem with non-ASCII characters, it is difficult to follow. Or in other words: what is the high level reason why the codec won't escape \x80 in my test program? To use a real-world term; an interface specification, in this case the pickle documentation, is the contract between the consumer of the library and the provider of the library. If it states ASCII, ASCII is expected. If it doesn't state for debugging only it will be used for non-debugging purposes. There isn't much you can do about it without breaking the contract. What makes you think that the problem cannot be fixed without changing the existing pickle format 0? Note that base64 is a common way to deal with binary data in ascii streams rather than the common. (But why should I care when my data is already ascii?) ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2980 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1248] ftplib needs a rewrite to use bytes/buffers
STINNER Victor [EMAIL PROTECTED] added the comment: - retrbinary() and storbinary() uses bytes (byte strings) - retrlines() and storlines() uses str (unicode strings) with charset=self.encoding - command is an unicode string converted to byte string with charset=self.encoding So it's already possible to receive/send raw bytes, and forget my previous message. I see a potential but minor problem: if the server is running a POSIX OS, it's not possible to open / rename / unlink a file with an invalid name. ftp might allow bytes filename, but I prefer to leave ftplib unchanged. If your FTP server is broken, fix your file system, fix your configuration or use an old FTP client to fix the problem. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1248 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3890] ssl.SSLSocket.recv() implementation may not work with non-blocking sockets
Bill Janssen [EMAIL PROTECTED] added the comment: I agree, too. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3890 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2980] Pickle stream for unicode object may contain non-ASCII characters.
Martin v. Löwis [EMAIL PROTECTED] added the comment: I read the PEP, which serves as a specification of raw unicode escape (at least for the decoding bit) and the reference documentation. Which PEP specifically? PEP 263 only mentions the unicode-escape encoding in its problem statement, i.e. as a pre-existing thing. It doesn't specify it, nor does it give a rationale for why it behaves the way it does. Then I read the source trying to map between specified behavior in the documentation and the implementation in the source code. When it comes to the part which causes the problem with non-ASCII characters, it is difficult to follow. What code are you looking at, and where do you find it difficult to follow it? Maybe you get confused between the unicode-escape codec, and the raw-unicode-escape codec, also. Or in other words: what is the high level reason why the codec won't escape \x80 in my test program? The raw-unicode-escape codec? It was designed to support parsing of Python 2.0 source code, and of raw unicode strings (ur) in particular. In Python 2.0, you only needed to escape characters above U+0100; Latin-1 characters didn't need escaping. Python, itself, only relied on the decoding directory. That the codec choses not to escape Latin-1 characters on encoding is an arbitrary choice (I guess); it's still symmetric with decoding. Even though the choice was arbitrary, you shouldn't change it now, because people may rely on how this codec works. What makes you think that the problem cannot be fixed without changing the existing pickle format 0? Applications might rely on what was implemented rather than what was specified. If they had implemented their own pickle readers, such readers might break if the pickle format is changed. In principle, even the old pickle readers of Python 2.0..2.6 might break if the format changes in 2.7 - we would have to go back and check that they don't break (although I do believe that they would work fine). So I personally don't see a problem with fixing this, but it appears MAL does (for whatever reasons - I can't quite buy the performance argument). OTOH, I don't feel that this issue deserves as much of my time to actually implement anythings. So contributions are welcome. If you find that the patch meets resistance, you also need to write a PEP, and ask for BDFL pronouncement. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2980 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4073] distutils build_scripts and install_data commands need 2to3 support
Mark Hammond [EMAIL PROTECTED] added the comment: I'm skeptical about adding build_data support, as it's not obvious what files would need conversion. All .py files should be converted. I can't think why a project would use this 2to3 capability for scripts and packages, but not .py files in data files. pywin32 uses data files to install 'demo' scripts. Would the motivation become clearer if we modified Demo/distutils/test2to3 to install a README.txt and a demo .py file (where the demo .py file should not be installed in the global 'scripts' directory, but instead in a 'demos' sub-directory of the package)? Users should adjust their build_data commands to invoke distutils.util.run_2to3. True - but the same justification could be used to avoid adding support to build_scripts. I guess the question is 'how common is it that .py files will be included in data_files?' My experience is that it is common enough to warrant support (but obviously others experiences may be different) I would appreciate a confirmation that this function has a useful API. I haven't actually applied the patch and modified pywin32 to use it, but the API certainly looks useful from reading the patch. +1 Thanks. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4073 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4073] distutils build_scripts and install_data commands need 2to3 support
Mark Hammond [EMAIL PROTECTED] added the comment: Thinking more about data_files, I'd agree that blindly converting all .py files and nothing more isn't as useful for install_data as the other commands. It might make more sense to allow data_files to specify a list of patterns that will be matched to perform the conversion, with the default being all .py files. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4073 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4073] distutils build_scripts and install_data commands need 2to3 support
Martin v. Löwis [EMAIL PROTECTED] added the comment: All .py files should be converted. I disagree. For example, people decided that all .py files in Tools should get converted, converting Tools/msi in the process. Now, Tools/msi is intended to be run in an *older* Python version than the one being packaged; I currently use 2.4 to do the packaging. It took me some time to undo this conversion. It's convenient if users can easily express which files they want to convert, but it must be a selective, explicit choice. I can't think why a project would use this 2to3 capability for scripts and packages, but not .py files in data files. See above. Would the motivation become clearer if we modified Demo/distutils/test2to3 to install a README.txt and a demo .py file (where the demo .py file should not be installed in the global 'scripts' directory, but instead in a 'demos' sub-directory of the package)? I understand the motivation fully (I think). I just question whether it is general. Packages that have this need (to 2to3-convert data files) would have to come up with their own command subclass still, which hopefully is very easy with what we provide. IMO, this is a case where we should err on the conservative side. If we don't provide the command in 3.0, people will write their own. If your assumption is correct that this is a common need, we can still add the command into 3.1. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4073 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
