[issue13275] Recommend xml.etree for XML processing
New submission from Alexey Shamrin : There are many libraries in Python stdlib [1] xml.dom xml.dom.minidom xml.dom.pulldom xml.sax xml.etree Tutorial mentions xml.dom and xml.sax. [2] In my experience xml.etree is the best library to quickly load some xml and mess with it. It would be nice to recommend people xml.etree in the tutorial [2] and in the beginning of section 19, "Structured Markup Processing Tools". [1] [1]: http://docs.python.org/library/markup.html [2]: http://docs.python.org/tutorial/stdlib.html#batteries-included -- assignee: docs@python components: Documentation messages: 146484 nosy: ash, docs@python priority: normal severity: normal status: open title: Recommend xml.etree for XML processing ___ Python tracker <http://bugs.python.org/issue13275> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2931] optparse: various problems with unicode and gettext
New submission from Alexey Shamrin <[EMAIL PROTECTED]>: In the process of trying to use optparse with russian messages, I found several problems with gettext and unicode handling: 1. optparse.OptionParser.error function doesn't work with unicode argument 2. optparse doesn't work when its error messages are gettext-translated 3. optparse fails running 'prog.py --help > out.txt' with unicode help (at least on my system: Windows XP, Russian) I have attached a file demonstrating these problems: test_optparse.py. You can run it either using nose[1] or directly, manually uncommenting test_* functions one-by-one. [1]: http://www.somethingaboutorange.com/mrl/projects/nose/ Here's the result of running `nosetests test_optparse.py`: EEF == ERROR: OptionParser.error function doesn't work with unicode argument -- Traceback (most recent call last): File "c:\python25\lib\site-packages\nose-0.10.2-py2.5.egg\nose\case.py", line 182, in runTest self.test(*self.arg) File "C:\work\test_optparse.py", line 10, in test_unicode_error optparse.OptionParser().error(russian_text) File "C:\Python25\lib\optparse.py", line 1562, in error self.exit(2, "%s: error: %s\n" % (self.get_prog_name(), msg)) File "C:\Python25\lib\optparse.py", line 1551, in exit sys.stderr.write(msg) UnicodeEncodeError: 'ascii' codec can't encode characters in position 28-34: ordinal not in range(128) == ERROR: optparse doesn't work when its error messages are gettext-translated -- Traceback (most recent call last): File "c:\python25\lib\site-packages\nose-0.10.2-py2.5.egg\nose\case.py", line 182, in runTest self.test(*self.arg) File "C:\work\test_optparse.py", line 25, in test_translated_unicode_error_message optparse.OptionParser().parse_args(["--unknown"]) File "C:\Python25\lib\optparse.py", line 1380, in parse_args self.error(str(err)) UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-6: ordinal not in range(128) == FAIL: optparse fails running 'prog.py --help > out.txt' with unicode help -- Traceback (most recent call last): File "c:\python25\lib\site-packages\nose-0.10.2-py2.5.egg\nose\case.py", line 182, in runTest self.test(*self.arg) File "C:\work\test_optparse.py", line 42, in test_redirected_unicode_help assert '?' not in dummy_stdout.getvalue() AssertionError -- Ran 3 tests in 0.000s FAILED (errors=2, failures=1) -- components: Library (Lib) files: test_optparse.py messages: 67129 nosy: ash, gward severity: normal status: open title: optparse: various problems with unicode and gettext Added file: http://bugs.python.org/file10386/test_optparse.py __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2931> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2931] optparse: various problems with unicode and gettext
Alexey Shamrin <[EMAIL PROTECTED]> added the comment: I've also attached a patch that fixes all these issues and also allows the word "error" to be translated with gettext. Regarding the use of `locale.getpreferredencoding` instead of `sys.getdefaultencoding`. On my system (Windows XP, Russian) I get: Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import sys, locale >>> sys.getdefaultencoding() 'ascii' >>> locale.getpreferredencoding() 'cp1251' Using cp1251 on my system makes much more sense. It's used as a default encoding everywhere in the system. For example, in Notepad. -- keywords: +patch Added file: http://bugs.python.org/file10387/optparse.py.patch __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2931> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2931] optparse: various problems with unicode and gettext
Alexey Shamrin <[EMAIL PROTECTED]> added the comment: sampablokuper, I don't think your problem is relevant to this issue. In addition to encoding declaration you should use unicode strings: u"your non-ASCII text". Or wait for Python 3.0, where strings will be unicode by default. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2931> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2931] optparse: various problems with unicode and gettext
Alexey Shamrin added the comment: More than a year passed since I reported this... Could someone suggest how to move this forward? If needed, I can try to improve patch, test or description of this issue. Should I, for example, split this into separate issues? -- ___ Python tracker <http://bugs.python.org/issue2931> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6414] struct module : processor endianness descriptions misleading
Alexey Shamrin added the comment: Good suggestions, Mark! We should do both, I think. I didn't know about sys.byteorder before your message ;-) Thanks for education! How about this: "Native byte order is big-endian or little-endian, depending on the host system. For example, Intel x86 and AMD64 (x86-64) are little-endian; Motorola 68000 and PowerPC G5 are big-endian; some are even bi-endian (switchable endianess) - ARM and DEC Alpha. Use sys.byteorder to check the endianess of your system." Sorry for any spelling and styling mistakes... -- nosy: +ash ___ Python tracker <http://bugs.python.org/issue6414> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6414] struct module : processor endianness descriptions misleading
Alexey Shamrin added the comment: Little style: "Native byte order is big-endian or little-endian, depending on the host system. For example, Intel x86 and AMD64 (x86-64) are little-endian; Motorola 68000 and PowerPC G5 are big-endian; ARM and DEC Alpha feature switchable endianness (bi-endian). Use sys.byteorder to check the endianess of your system." -- ___ Python tracker <http://bugs.python.org/issue6414> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2931] optparse: various problems with unicode and gettext
Changes by Alexey Shamrin : -- versions: +Python 2.7 ___ Python tracker <http://bugs.python.org/issue2931> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4319] optparse and non-ascii help strings
Alexey Shamrin added the comment: There's nothing to fix here, I think... There's no point in allowing arbitrary byte strings in help strings. Especially because Python 3 features unicode strings by default. IMHO, this issue should be closed. And see also #2931 for remaining i18n problems with optparse. -- nosy: +ash ___ Python tracker <http://bugs.python.org/issue4319> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6658] typo in buffer api docs
New submission from Alexey Shamrin : Typo in PyObject_GetBuffer docs: "...handle all the complexibity..." Links: http://docs.python.org/c-api/buffer.html#buffer-related-functions http://docs.python.org/dev/c-api/buffer.html#buffer-related-functions http://docs.python.org/3.1/c-api/buffer.html#buffer-related-functions http://docs.python.org/dev/py3k/c-api/buffer.html#buffer-related-functions -- assignee: georg.brandl components: Documentation messages: 91355 nosy: ash, georg.brandl severity: normal status: open title: typo in buffer api docs versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2 ___ Python tracker <http://bugs.python.org/issue6658> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6658] typo in buffer api docs
Alexey Shamrin added the comment: Well, there's another typo in buffer documentation (PyBuffer_Release): "This shouldd be called..." Only in 2.x series: http://docs.python.org/c-api/buffer.html#PyBuffer_Release http://docs.python.org/dev/c-api/buffer.html#PyBuffer_Release -- ___ Python tracker <http://bugs.python.org/issue6658> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6659] buffer c-api: memoryview object documentation
New submission from Alexey Shamrin : "A memoryview object is an extended buffer object that could replace the buffer object (but doesn’t have to as that could be kept as a simple 1-d memoryview object)." Well, buffer object was dropped Python 3, wasn't it? http://docs.python.org/dev/py3k/c-api/buffer.html#memoryview-objects http://docs.python.org/3.1/c-api/buffer.html#memoryview-objects -- assignee: georg.brandl components: Documentation messages: 91357 nosy: ash, georg.brandl severity: normal status: open title: buffer c-api: memoryview object documentation versions: Python 3.1, Python 3.2 ___ Python tracker <http://bugs.python.org/issue6659> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6659] buffer c-api: memoryview object documentation
Alexey Shamrin added the comment: Antoine, it seems, this sentence was taken literally from PEP3118 (http://www.python.org/dev/peps/pep-3118/#new-c-api-calls-are-proposed). PEP authors discussed if __builtins__.buffer should be removed. I agree, old __builtins__.buffer should not be mentioned here at all. I think, the best way to fix is to describe what is memoryview at the C-level and properly document its C API. For example, PyMemoryView_GetContiguous is not documented here at all (some documentation is in header file - see memoryobject.h). I suggest rewriting the whole section (see below). Notes: 1. I haven't documented #define's from memoryview.h - do we need to? 2. I have renamed 'fort' to 'order'. It sounds much better now I think... Can we also change memoryview.h to use 'order'? I also want to rename 'obj' to 'buffer'. What do you think? It will simplify description of these functions... 3. I haven't documented 'buffertype'. Feel free to do so ;-) There's some text in PEP3118, in memoryview.h and memoryview.c. MemoryView objects == PyMemoryViewObject is a subtype of PyObject representing Python :class:`memoryview` object. .. cfunction:: PyObject* PyMemoryView_FromObject(PyObject *obj) Return a memoryview object from an object that defines the buffer interface. .. cfunction:: PyObject * PyMemoryView_GetContiguous(PyObject *obj, int buffertype, char order) Return a memoryview object to a contiguous chunk of memory (in either 'C' or 'F'ortran order) from an object that defines the buffer interface. If memory is contiguous, the memoryview object points to the original memory. Otherwise copy is made and the memoryview points to a new bytes object. -- ___ Python tracker <http://bugs.python.org/issue6659> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6663] re.findall does not always return a list of strings
Alexey Shamrin added the comment:
You've made three groups with parentheses. Just drop them:
>>> re.findall('-?\d+[.]\d+|-?\d+[.]?|-?[.]\d+', 'asdf6.77.33ff9')
['6.7', '7.33', '9']
Everything is according to documentation: "If one or more groups are
present in the pattern, return a list of groups; this will be a list of
tuples if the pattern has more than one group."
http://docs.python.org/library/re.html#re.findall
I would suggest to close this bug.
--
nosy: +ash
___
Python tracker
<http://bugs.python.org/issue6663>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3158] Doctest fails to find doctests in extension modules
Alexey Shamrin added the comment: I've added Tim Peters to the nosy list. Is there anyone else who should be considered as doctest maintainer? I've also checked further Python versions - a quick a look at latest doctest source shows that the problem is still there. There are some details (and a workaround) in Cython FAQ: http://wiki.cython.org/FAQ#HowcanIrundoctestsinCythoncode.28pyxfiles.29.3F -- nosy: +ash, tim_one versions: +Python 2.6, Python 2.7, Python 3.1, Python 3.2 ___ Python tracker <http://bugs.python.org/issue3158> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6648] codecs documentation does not mention surrogateescape
Alexey Shamrin added the comment: Georg, it would also be nice to give a link to 'surrogateescape' information in os module [1]. Yes, you gave a link to PEP 383, but PEP harder to follow and more lengthy. [1]: http://docs.python.org/3.1/library/os.html#file-names-command-line-arguments-and-environment-variables -- nosy: +ash ___ Python tracker <http://bugs.python.org/issue6648> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6722] collections.namedtuple: confusing example
New submission from Alexey Shamrin : Maybe it's just me, but it took me several attempts to understand namedtuple example in the documentation [1]. The problem is that the first example uses verbose=True. It's very unusual to get Python source as the output in Python shell. At first I thought there's some syntax error in documentation source. I know that several lines above one can read: "If verbose is true, the class definition is printed just before being built." But during first several attempts to understand namedtuple, I skipped it and directly scrolled to the first example. I think the first example on namedtuple usage shouldn't use verbose=True. You could argue I had to try using namedtuple inside Python shell. I agree. But unfortunately Python 2.6 was not installed on the computer I was at. [1]: http://docs.python.org/library/collections.html#collections.namedtuple -- assignee: georg.brandl components: Documentation messages: 91680 nosy: ash, georg.brandl severity: normal status: open title: collections.namedtuple: confusing example versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2 ___ Python tracker <http://bugs.python.org/issue6722> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6722] collections.namedtuple: confusing example
Alexey Shamrin added the comment:
Raymond, sorry if I wasn't clear. I'm fine with the API (haven't used it
yet though, because I was stuck after skimming through its documentation).
I suggest to make *first* example simple (without verbose=True) and to
move an example with verbose=True little furthere. I think it should be
something like this:
Example:
.. doctest::
:options: +NORMALIZE_WHITESPACE
>>> Point = namedtuple('Point', 'x y')
>>> p = Point(11, y=22) # instantiate with positional or keyword
arguments
>>> p[0] + p[1] # indexable like the plain tuple (11, 22)
33
>>> x, y = p# unpack like a regular tuple
>>> x, y
(11, 22)
>>> p.x + p.y # fields also accessible by name
33
>>> p # readable __repr__ with a name=value style
Point(x=11, y=22)
>>> namedtuple('Point', 'x y', verbose=True) # print class definition
class Point(tuple):
'Point(x, y)'
__slots__ = ()
_fields = ('x', 'y')
def __new__(_cls, x, y):
return _tuple.__new__(_cls, (x, y))
@classmethod
def _make(cls, iterable, new=tuple.__new__, len=len):
'Make a new Point object from a sequence or iterable'
result = new(cls, iterable)
if len(result) != 2:
raise TypeError('Expected 2 arguments, got %d' %
len(result))
return result
def __repr__(self):
return 'Point(x=%r, y=%r)' % self
def _asdict(t):
'Return a new dict which maps field names to their values'
return {'x': t[0], 'y': t[1]}
def _replace(_self, **kwds):
'Return a new Point object replacing specified fields
with new values'
result = _self._make(map(kwds.pop, ('x', 'y'), _self))
if kwds:
raise ValueError('Got unexpected field names: %r' %
kwds.keys())
return result
def __getnewargs__(self):
return tuple(self)
x = _property(_itemgetter(0))
y = _property(_itemgetter(1))
--
___
Python tracker
<http://bugs.python.org/issue6722>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6722] collections.namedtuple: confusing example
Alexey Shamrin added the comment: Roundup broke formatting... I've attached a text file with the proposed example. -- Added file: http://bugs.python.org/file14747/namedtuple_doc_example.txt ___ Python tracker <http://bugs.python.org/issue6722> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
