[issue14181] Support getbuffer redirection scheme in memoryview
New submission from Stefan Krah stefan-use...@bytereef.org: Supporting chained objects that redirect getbuffer requests to a single exporter rather than re-exporting the buffer is a matter of removing an assert, but it needs tests and documentation updates. -- assignee: skrah messages: 154826 nosy: ncoghlan, pitrou, scoder, skrah priority: normal severity: normal stage: test needed status: open title: Support getbuffer redirection scheme in memoryview type: behavior versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14181 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14182] collections.Counter equality test thrown-off by zero counts
New submission from Raymond Hettinger raymond.hettin...@gmail.com: from collections import Counter x=Counter(a=10,b=0,c=3) y=Counter(a=10,c=3) x == y False all(x[k]==y[k] for k in set(x) | set(y)) True -- assignee: rhettinger components: Library (Lib) messages: 154827 nosy: rhettinger priority: normal severity: normal status: open title: collections.Counter equality test thrown-off by zero counts type: behavior versions: Python 3.2, Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14182 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12659] Add tests for packaging.tests.support
Francisco Martín Brugué franci...@email.de added the comment: I've updated the patch with a test case for 'create_distribution' and one minor rename. I personally don't like too much the structure of 'LoggingCatcherTestCase' so improvements are welcome. Cheers, francis -- Added file: http://bugs.python.org/file24718/issue12659_e67b3a9bd2dc.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12659 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14176] Fix unicode literals
Jean-Michel Fauth wxjmfa...@gmail.com added the comment:
2012/3/3 Terry J. Reedy rep...@bugs.python.org
Terry J. Reedy tjre...@udel.edu added the comment:
That would mean in Python 3, '...' works and u'...' will not work.
You misunderstand the PEP: in 3.3, '...' and u'...' will be *exactly* the
same. The only change is that the interpreter will ignore the u prefix
instead of raising SyntaxError. It will be as if 'u' were not there. The
only purpose is to let 2.x code run in 3.x without requiring the user to
erase the 'u'.
I can see how you could misunderstand and think that the 'u' prefix must
have some meaning. But is does not. The addition is a bit controversial but
Guido approved it with the expectation that it will encourage more
conversion of 2.x libraries to run on 3.3. In any case, the tracker is not
the place for further discussion of the value of the PEP.
Once again, an *illustration* with IDLE / Py2.
...
Of course, this is actually a no problem with Py 3.
...
It still remains that this is a serious problem on Py 2.
We are painfully aware that 2.x has problems with unicode. You do not need
to tell us. I believe that most of the problems that could be sensibly
fixed in 2.x have been fixed. 3.0 fixed more problems by changing the
language. 3.3 fixes still more problems by changing the internal
implementation of unicode, along with the C api, and the meaning of the
language on some systems. People who want to avoid all the problems that
have been fixed should use 3.3 either from the repository or when it is
released.
So, if this (u'...') works in Py 3.3, the problem can
be considered as solved.
I am glad you agree and I will close the issue.
Preliminary remark. I'm sending this via gmail, so it
may happen the glyphs you see are illformed or
transfomred by Google. Be ensured I'm typing the
right glyphs.
No, no and no. This is not a tkinter issue. This
strange behaviour, I do not find a better word,
happens with many libraries, can be Python core libs
or external libs.
To tell you the truth and dispite my experience,
I never succeeded to narrow excatly the problem.
In Python 2 sometimes, understand with some pieces
of code / software, it works and somtimes it
simply does not. The libs used here a just the
first ones, that came to my mind.
-
wxPython 2.8-ansi build.
Traceback (most recent call last):
File input, line 1, in module
File c:\python27\lib\site-packages\wx-2.8-msw-ansi\wx\py\shell.py, line
1242, in writeOut
self.write(text)
File c:\python27\lib\site-packages\wx-2.8-msw-ansi\wx\py\shell.py, line
1000, in write
self.AddText(text)
File c:\python27\lib\site-packages\wx-2.8-msw-ansi\wx\stc.py, line
1425, in AddText
return _stc.StyledTextCtrl_AddText(*args, **kwargs)
File c:\python27\lib\encodings\cp1252.py, line 12, in encode
return codecs.charmap_encode(input,errors,encoding_table)
UnicodeEncodeError: 'charmap' codec can't encode characters in position
4-5: character maps to undefined
abc需
PySide, passing unicode to a text widdget.
Passing u'abc需' works.
Passing unicode('abc需', 'cp1252') works.
Passing 'abc逜' doesn't ! 'œ€' are missing.
---
My interactive wx interpreter using wxPython. Strings
as frame title.
True
ok
Traceback (most recent call last):
File psi last command, line 1, in module
File
c:\Python27\lib\site-packages\wx-2.8-msw-ansi\wx\_windows.py,
line 505, in __init__
_windows_.Frame_swiginit(self,_windows_.new_Frame(*args,
**kwargs))
File c:\Python27\lib\encodings\cp1252.py, line 12, in encode
return codecs.charmap_encode(input,errors,encoding_table)
UnicodeEncodeError: 'charmap' codec can't encode characters in
position 5-6: character maps to undefined
True
ok
---
And so on with many libs.
You may argue that these libs are guilty.
I may argue that Python is somehow guilty, because it
let users write non working code.
And practically in all the cases, the main problem is due
to the usage of unicode literals.
Just to show you, I'm quite comfortable with all this
coding stuff. The results my interactive intepreter.
Special hack, unfortunatelly non portable, works
only with Windows and cp1252.
abcé??
unicode('abc需', sys.stdout.encoding)
abc需
print u'abc需'
abcé??
print unicode('abc需', sys.stdout.encoding)
abc需
As I am aware of this feature, all my code is
perfectly working. I'm paying attention to the
necessity of the usage of u'...' or unicode(...).
Unfortunatelly, this not a general case in a lot of
code I see, supposed to deal with texts.
To draw a conclusion.
You are wise enough to understand that, when I'm
saying Python just does not work, I'm unforunatelly
not so far away form the reality.
I really, very really, expect all this mess (sorry
for the word) will not reappear in Py 3.3.
Let's wait.
'abc需'
print('abc需')
abc需
Regards,
Jean-Michel Fauth
PS The u() trick does not help.
--
nosy: +jmfauth
[issue14144] urllib2 HTTPRedirectHandler not forwarding POST data in redirect
Éric Araujo mer...@netwok.org added the comment: However, an added option which leaves the current behavior as the default shouldn't hurt. My opinion too. urllib is sometimes a client, sometimes a library used to build clients, which need a knob to implement their own decisions or possibly ask the user for confirmation. A new argument being a new feature, this patch must target 3.3. Some comments on the patch: +# NOTE: Setting redirect_post_data to True *can* introduce security +# issues and is not recommended unless you are sure of where the +# POST data is being redirected! I would tone down this note, for example: # setting redirect_post_data to True can introduce security # issues, use with caution +redirect_post_data = False Is an attribute okay or should methods (__init__, maybe methods that do the requests too) grow a new parameter? -- stage: - patch review type: behavior - enhancement versions: +Python 3.3 -Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14144 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14144] urllib2 HTTPRedirectHandler not forwarding POST data in redirect
Éric Araujo mer...@netwok.org added the comment: Also, new tests and a doc update would be needed, but you may want to wait for Senthil’s approval before doing more work on this. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14144 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6784] byte/unicode pickle incompatibilities between python2 and python3
Changes by Merlijn van Deen valhall...@gmail.com: Removed file: http://bugs.python.org/file24567/test_bytestrpickle.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6784 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6784] byte/unicode pickle incompatibilities between python2 and python3
Merlijn van Deen valhall...@gmail.com added the comment:
OK, and now a version that's not broken... I forgot to initialize self-bytestr
for PicklerObject/UnpicklerObject. *puts on the you-broke-the-build-hat*
Except for test_packaging.test_caches, this version passes all tests --
test_packaging.test_caches, which seems to fail because I make install'd python
and installed {distribute,pip,setuptools,virtualenv}.
--
Added file: http://bugs.python.org/file24719/pickle_bytestr.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6784
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6784] byte/unicode pickle incompatibilities between python2 and python3
Changes by Merlijn van Deen valhall...@gmail.com: Removed file: http://bugs.python.org/file24714/pickle_bytestr.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6784 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14036] urlparse insufficient port property validation
zulla d...@defendassist.com added the comment: u(http://www.google.com:99;).port 99L -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14036 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14176] Fix unicode literals
Georg Brandl ge...@python.org added the comment:
I'd like to encourage you to not try this sort of thing out from an interactive
interpreter (incidentally, where does psi last command come from? It
doesn't look like Python's REPL).
As David and Terry noted, interactions with such a console, be it Windows'
cmd or IDLE, have their very own idiosyncrasies and bugs.
That said, in Python 2.x *source files* the following two expressions are
identical:
* u'abcœé€'
* unicode('abcœé€', 'encoding the file is in')
Both result in a Unicode string with the six characters/codepoints you
mentioned. There won't be any code that works with one but not the other.
Of course there are libraries that do not handle Unicode strings in general
(nothing to do with literals!) correctly, but as you yourself said, that is a
problem with the libraries.
Lastly, please read PEP 414 if you are not completely sure what it is
proposing. You will see that it merely affects the available syntax for
Unicode literals and allows the u again.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14176
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4773] HTTPMessage not documented and has inconsistent API across Py2/Py3
Éric Araujo mer...@netwok.org added the comment: Now that two Python 3 releases have been made, I don’t know if changing the code is still an option. The doc can certainly still be improved. Adding Ezio to nosy; I think it’s you who opened a bug report about removing superfluous getter methods in the addinfourl class (and other ugliness). -- nosy: +ezio.melotti resolution: accepted - stage: test needed - patch review title: HTTPMessage not documented and has inconsistent API across 2.6/3.0 - HTTPMessage not documented and has inconsistent API across Py2/Py3 versions: +Python 2.7, Python 3.2, Python 3.3 -Python 2.6, Python 3.0 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4773 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4773] HTTPMessage not documented and has inconsistent API across Py2/Py3
Changes by Éric Araujo mer...@netwok.org: Removed file: http://bugs.python.org/file13430/unnamed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4773 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14122] operator: div() instead of truediv() in documention since 3.1.2
Ezio Melotti ezio.melo...@gmail.com added the comment: This was fixed in 8de95f3b2404 (3.2) and d4b17c478e49 (default). Thanks for the report and the patch! -- resolution: - fixed stage: patch review - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14122 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14171] warnings from valgrind about openssl as used by CPython
Stefan Krah stefan-use...@bytereef.org added the comment: # generated on buildbot.rubenkerkhof.com, which had, according to Ruben # Fedora's package openssl-1.0.1-0.1.beta2.fc17.x86_64 I think openssl needs to be compiled with -DPURIFY to avoid this. -- nosy: +skrah ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14171 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14126] Speed up list comprehensions by preallocating the list where possible
Ezio Melotti ezio.melo...@gmail.com added the comment: You should try to port the patch to 3.3 and do some benchmark there. Having some additional tests to make sure that it works fine in all the cases would be nice too (even if listcomps are already used elsewhere in the code/tests). -- nosy: +ezio.melotti stage: - needs patch versions: +Python 3.3 -Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14126 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14135] check for locale changes in test.regrtest
Changes by Ezio Melotti ezio.melo...@gmail.com: -- nosy: +ezio.melotti stage: - needs patch type: - enhancement ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14135 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14183] Test coverage for lib/packaging.install and lib/packaging/pypi/wrapper
New submission from Francisco Martín Brugué franci...@email.de: I've added a test to Lib/packaging/tests/test_install.py to increase the line test coverage of lib/packaging.install (and lib/packaging/pypi/wrapper indirectly from 14% to 80%). -- components: Tests files: packaging_get_infos_coverage_e67b3a9bd2dc.patch keywords: patch messages: 154839 nosy: francismb priority: normal severity: normal status: open title: Test coverage for lib/packaging.install and lib/packaging/pypi/wrapper versions: Python 3.3 Added file: http://bugs.python.org/file24720/packaging_get_infos_coverage_e67b3a9bd2dc.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14183 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14183] Test coverage for lib/packaging.install and lib/packaging/pypi/wrapper
Changes by Francisco Martín Brugué franci...@email.de: -- type: - enhancement ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14183 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14183] Test coverage for lib/packaging.install and lib/packaging/pypi/wrapper
Changes by Nadeem Vawda nadeem.va...@gmail.com: -- nosy: +eric.araujo, nadeem.vawda stage: - patch review ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14183 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14183] Test coverage for packaging.install and packaging.pypi.wrapper
Éric Araujo mer...@netwok.org added the comment: Thanks for the patch. -# Test that the isntalled raises an exception if the project does not +# Test that the installed raises an exception if the project does not It took me many seconds to find the change :) +def test_installation_get_infos_with_ClientWrapper(self): +# Test the use of get_infos default index Hm, I don’t like the method name, and don’t really understand from the comment what it is exactly that you’re testing (I’m not very familiar with p7g.pypi). -install.install_dists = lambda x, y=None: None +install.install_dists = lambda x, y = None: None PEP 8: Never put spaces in a function (or lambda) signature. Let me remark that even if we get to 100% line coverage, or even 100% branch coverage, that won’t mean that we have covered everything. Two personal anecdotes to illustrate my point. In one project, I had a branch covered but actually untested, because I used a ternary operator (something like “flags = 0 if case_sensitive else re.I”). Another project was a Pylons web app; I had full coverage, and then I tried using non-ASCII and saw that my app was incomplete. So I think that full code coverage is mainly useful in a new project, where you can have 100% all the time and use that metric to avoid adding code without sufficient tests. For a codebase like distutils2 that’s half legacy, half new stuff, it’s harder to achieve that, and maybe less useful than working on other things. If you grep packaging tests for XXX|TODO|FIXME, you’ll find 22 entries. Fixing those may not have an impact on coverage numbers, but will definitely improve things. There are also XXX notes in the code itself, open bugs on this tracker, and some dozen more in my todo lists. For example, packaging.database is supposed to handle zipped eggs, but does it? I really appreciate your contributions, and think that you know enough of the code now to take on a larger bug if you want to. :) -- assignee: - eric.araujo components: +Distutils2 -Tests nosy: +alexis, tarek title: Test coverage for lib/packaging.install and lib/packaging/pypi/wrapper - Test coverage for packaging.install and packaging.pypi.wrapper versions: +3rd party ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14183 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14183] Test coverage for packaging.install and packaging.pypi.wrapper
Francisco Martín Brugué franci...@email.de added the comment:
Hi Éric,
- # Test that the isntalled raises an exception if the project does not
+ # Test that the installed raises an exception if the project does not
It took me many seconds to find the change :)
The editor told me :)
+def test_installation_get_infos_with_ClientWrapper(self):
+# Test the use of get_infos default index
Hm, I don’t like the method name, and don’t really understand from the
comment what it is exactly that you’re testing (I’m not very familiar with
p7g.pypi).
All the test with get_infos use the index=something. The default is for that
parameter is None. If that ocurrs than ClientWrapper will be used.
You're right, is not interesting here. May be a new name could be
test_installation_get_infos_with_default_index ... or what you wish :)
-install.install_dists = lambda x, y=None: None
+install.install_dists = lambda x, y = None: None
PEP 8: Never put spaces in a function (or lambda) signature.
I cannot find that exactly in pep8. Are you saying is now OK or it was
OK? (if it was OK then the editor pep8 has a bug because that was
changed when saving)
Let me remark that even if we get to 100% line coverage, or even 100%
branch coverage, that won’t mean that we have covered everything.
I'm aware of that but it's a good exercise to learn something about the package.
Two personal anecdotes to illustrate my point. In one project, I had a
branch covered but actually untested, because I used a ternary
operator (something like “flags = 0 if case_sensitive else re.I”).
Pairwise Testing could help :) but of course getting all combinations tested
can be impossible.
Another project was a Pylons web app; I had full coverage, and then I
tried using non-ASCII and saw that my app was incomplete.
Well if non-ASCII was part of the specification then is a bug in the
implementation but if not then is a feature :P
So I think that full code coverage is mainly useful in a new project,
where you can have 100% all the time and use that metric to avoid
adding code without sufficient tests. For a codebase like distutils2 that’s
half legacy, half new stuff, it’s harder to achieve that,
and maybe less useful than working on other things.
If you grep packaging tests for XXX|TODO|FIXME, you’ll find 22
entries. Fixing those may not have an
impact on coverage numbers, but will definitely improve things.
There are also XXX notes in the code itself,
open bugs on this tracker, and some dozen more in my todo lists. For
example, packaging.database is supposed to
handle zipped eggs, but does it? I really appreciate your
contributions, and think that you know enough of the code
now to take on a larger bug if you want to. :)
Well I wanted to try with more line coverage (packging.run) and I got to a
point where I have to ask about (just adding another XXX and I prefer to ask
first before opening a bug): I'm getting 0 or None as return value for help
(and the behavior is different from the command
line or from subprocess and directly calling main).
-8-8-8-8-8-
diff -r e67b3a9bd2dc Lib/packaging/tests/test_run.py
--- a/Lib/packaging/tests/test_run.py Sat Mar 03 02:38:37 2012 +0100
+++ b/Lib/packaging/tests/test_run.py Sat Mar 03 18:01:35 2012 +0100
@@ -2,6 +2,7 @@
import os
import sys
+import logging
from io import StringIO
from packaging import install
@@ -9,6 +10,7 @@
from packaging.run import main
from test.script_helper import assert_python_ok
+from test.support import captured_stdout, captured_stderr
# setup script that uses __file__
setup_using___file__ = \
@@ -67,6 +69,16 @@
self.assertGreater(out, b'')
self.assertEqual(err, b'')
+# from main directly
+args = ('--help',)
+with captured_stdout() as out, captured_stderr() as err:
+status = main(args)
+self.assertGreater(out.getvalue(), '')
+self.assertEqual(err.getvalue(), '')
+# XXX shouldn't be 0 (no error) to be consistent with the above?
+# notice also that the all the messages are in stdout not error
+self.assertEqual(status, None)
+
def test_list_commands(self):
status, out, err = assert_python_ok('-m', 'packaging.run', 'run',
'--list-commands')
@@ -84,6 +96,23 @@
# TODO test that custom commands don't break --list-commands
+def test_no_commands(self):
+self.assertEqual(main(), 1)
+
+def test_no_existent_action(self):
+args = ('NO_EXISTENT',)
+self.assertEqual(main(args), 1)
+self.assertIn('NO_EXISTENT', self.get_logs(level=logging.ERROR)[-1])
+
+def test_command_help(self):
+args = ('list', '--help')
+with captured_stdout() as out, captured_stderr() as err:
+status = main(args)
+# XXX shouldn't be 0 (no error) to be
[issue14126] Speed up list comprehensions by preallocating the list where possible
Philip Jenvey pjen...@underboss.org added the comment: iter(range(1)) should also see a speedup because range's iter supports __length_hint__ -- nosy: +pjenvey ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14126 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14183] Test coverage for packaging.install and packaging.pypi.wrapper
Nadeem Vawda nadeem.va...@gmail.com added the comment: -install.install_dists = lambda x, y=None: None +install.install_dists = lambda x, y = None: None PEP 8: Never put spaces in a function (or lambda) signature. I cannot find that exactly in pep8. From the section Whitespace in Expressions and Statements: - Don't use spaces around the '=' sign when used to indicate a keyword argument or a default parameter value. Yes: def complex(real, imag=0.0): return magic(r=real, i=imag) No: def complex(real, imag = 0.0): return magic(r = real, i = imag) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14183 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14184] test_recursion_limit
Changes by Dionysios Kalofonos peite...@gmail.com: -- nosy: dk priority: normal severity: normal status: open title: test_recursion_limit ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14184 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14184] test_recursion_limit
New submission from Dionysios Kalofonos peite...@gmail.com: python compiled with ./configure --with-pydebug CC=clang MACOSX_DEPLOYMENT_TARGET=10.7 make EXTRA_CFLAGS=-Wno-unused-value -Wno-empty-body -Qunused-arguments -- components: +Tests versions: +Python 3.3 Added file: http://bugs.python.org/file24721/test ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14184 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14185] Failure to build _dbm with ndbm on Arch Linux
New submission from Westley Martínez aniko...@gmail.com: When building Python I get this: building dbm using ndbm *** WARNING: renaming _dbm since importing it failed: build/lib.linux-i686-3.3-pydebug/_dbm.cpython-33dm.so: undefined symbol: dbm_nextkey Failed to build these modules: _dbm I'm running Arch and I have gdbm installed so shouldn't it be building dbm with gdbm? -- messages: 154845 nosy: anikom15 priority: normal severity: normal status: open title: Failure to build _dbm with ndbm on Arch Linux type: compile error versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14185 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14183] Test coverage for packaging.install and packaging.pypi.wrapper
Francisco Martín Brugué franci...@email.de added the comment: Nadeem: - Don't use spaces around the '=' sign when used to indicate a keyword argument or a default parameter value. ok, code formating is not working as expected (at least for lambdas...) Éric : If you grep packaging tests for XXX|TODO|FIXME, you’ll find 22 entries. Fixing those may not have an impact on coverage numbers, but will definitely improve things. There are also XXX notes in the code itself, open bugs on this tracker, and some dozen more in my todo lists. I've, at least one of your wishes under the radar: 14140 but right now I lack of the time for it and I prefer to get the open issues where I'm helping closed or rejected first (otherwise these is too much open “fronts” :) ). That one was just curiosity: I've tried with coverage against the whole stdlib and then sorted things in ascending coverage % order and took one: Lib/packaging/pypi/wrapper :) . After looking a bit I came to the default parameter of 'get_infos' ... Cheers, francis -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14183 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14166] private dispatch table for picklers
Antoine Pitrou pit...@free.fr added the comment: That looks like a good idea. I don't understand the following code: +try: +self._dispatch_table = self.dispatch_table +except AttributeError: +self._dispatch_table = dispatch_table ... since self.dispatch_table is a property returning self._dispatch_table. Did you mean type(self).dispatch_table? Also, you need to update the docs (which will also make the intended semantics of the patch clearer :-)). -- stage: - patch review ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14166 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13951] Seg Fault in .so called by ctypes causes the interpreter to Seg Fault
Westley Martínez aniko...@gmail.com added the comment: Hi I found this bug randomly and have made two small patches to change the documentation. One assumes that the faulthandler module is available for 3.3. The other patch is for earlier versions of Python. -- keywords: +patch nosy: +anikom15 versions: +Python 3.3 Added file: http://bugs.python.org/file24722/cpython-13951.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13951 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13951] Seg Fault in .so called by ctypes causes the interpreter to Seg Fault
Changes by Westley Martínez aniko...@gmail.com: Added file: http://bugs.python.org/file24723/cpython-13951-pre3.3.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13951 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12328] multiprocessing's overlapped PipeConnection on Windows
Antoine Pitrou pit...@free.fr added the comment: Hmm, I tried to apply the latest patch to the default branch and it failed. It also seems the patch was done against a changeset (508bc675af63) which doesn't exist in the repo... -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12328 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4773] HTTPMessage not documented and has inconsistent API across Py2/Py3
Ezio Melotti ezio.melo...@gmail.com added the comment: Yep, #12707. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4773 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14186] Link to PEP 3107 in def part of Language Reference
New submission from Chris Rebert pyb...@rebertia.com: The part of the Language Reference concerning the `def` statement (http://docs.python.org/dev/reference/compound_stmts.htm#function-definitions ) should include a See Also link to PEP 3107 Function Annotations. -- assignee: docs@python components: Documentation messages: 154851 nosy: cvrebert, docs@python priority: normal severity: normal status: open title: Link to PEP 3107 in def part of Language Reference versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14186 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14187] add annotation entry to Glossary
New submission from Chris Rebert pyb...@rebertia.com: The Glossary should include an entry for annotation and/or function annotation regarding the language feature introduced by PEP 3107. -- assignee: docs@python components: Documentation messages: 154852 nosy: cvrebert, docs@python priority: normal severity: normal status: open title: add annotation entry to Glossary versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14187 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13703] Hash collision security issue
Chris Rebert pyb...@rebertia.com added the comment: The Design and History FAQ (will) need a minor corresponding update: http://docs.python.org/dev/faq/design.html#how-are-dictionaries-implemented -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13703 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14126] Speed up list comprehensions by preallocating the list where possible
Mark Shannon m...@hotpy.org added the comment: Could you run the benchamrks at http://hg.python.org/benchmarks/ and report the results, for 3.3 (rather than 2.7), please? Adding a new bytecode because it speeds up one 4 line program does not seem such a good idea. -- nosy: +Mark.Shannon ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14126 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13797] Allow objects implemented in pure Python to export PEP 3118 buffers
Stefan Behnel sco...@users.sourceforge.net added the comment: FWIW, Cython lets user code implement the buffer interface for extension types using the special methods __getbuffer__() and __releasebuffer__(), so providing the same methods (although with a different signature) also for normal Python types would IMHO fit nicely. -- nosy: +scoder ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13797 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14135] check for locale changes in test.regrtest
Westley Martínez aniko...@gmail.com added the comment: Here's a test that checks for changes to the locale. -- nosy: +anikom15 Added file: http://bugs.python.org/file24724/test_14135.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14135 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14135] check for locale changes in test.regrtest
Ezio Melotti ezio.melo...@gmail.com added the comment: Thanks for the patch, but I think Brett meant to say that this should be added to Lib/test/regrtest.py:750, among the other resources. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14135 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14171] warnings from valgrind about openssl as used by CPython
STINNER Victor victor.stin...@gmail.com added the comment: It remembers me a funny story. http://wiki.debian.org/SSLkeys -- nosy: +haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14171 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14126] Speed up list comprehensions by preallocating the list where possible
Changes by STINNER Victor victor.stin...@gmail.com: -- nosy: +haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14126 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14188] Sharing site-packages between Apply and python.org builds breaks extensions
New submission from Barry Alan Scott barry-sc...@users.sourceforge.net: I'm testing on Mac OS X 10.7.3 http://bugs.python.org/issue4865 added /Library/Python/2.7/site-packages to the path for python.org built 2.7. This will work for .py files but .so cannot be shared. pysvn will SEGV python.org 2.7 when it is built against apple 2.7. Because /Library/Python/2.7/site-packages is before /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages it is not possible to work around by install two binary kits. To reproduce: Install pysvn 1.7.6 for python.org Then run python.org 2.7 and import pysvn. This will work. Install pysvn 1.7.6 for Apple python. python.org 2.7 import pysvn is now broken. $ /usr/bin/python Python 2.7.1 (r271:86832, Jun 16 2011, 16:59:05) [GCC 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00)] on darwin Type help, copyright, credits or license for more information. import pysvn pysvn module 'pysvn' from '/Library/Python/2.7/site-packages/pysvn/__init__.pyc' ^D $ /usr/local/bin/python2.7 Python 2.7.2 (v2.7.2:8527427914a2, Jun 11 2011, 15:22:34) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin Type help, copyright, credits or license for more information. import pysvn Segmentation fault: 11 -- components: None messages: 154859 nosy: barry-scott priority: normal severity: normal status: open title: Sharing site-packages between Apply and python.org builds breaks extensions type: crash versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14188 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13964] os.utimensat() and os.futimes() should accept (sec, nsec), drop os.futimens()
STINNER Victor victor.stin...@gmail.com added the comment: utime.patch: ugly draft to add support of (sec, nsec) tuple to os.*utime*() functions. -- Added file: http://bugs.python.org/file24725/utime.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13964 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14188] Sharing site-packages between Apply and python.org builds breaks extensions
Barry Alan Scott barry-sc...@users.sourceforge.net added the comment: Pysvn binary kits can be downloaded from http://pysvn.tigris.org/files/documents/1233/49180/py27_python_org_pysvn_svn1617-1.7.6-1457-intel.dmg and http://pysvn.tigris.org/files/documents/1233/49178/py27_apple_com_pysvn_svn1617-1.7.6-1457-intel.dmg -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14188 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13964] os.utimensat() and os.futimes() should accept (sec, nsec), drop os.futimens()
Larry Hastings la...@hastings.org added the comment: After Guido rejected 410 and said let's just do nanoseconds, take it to the bug tracker I created issue #14127. Your having changed this issue to be the same thing means that at least one of 'em is redundant. Could you engage on that issue, or close it, or something? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13964 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14127] os.stat and os.utime: allow preserving exact metadata
STINNER Victor victor.stin...@gmail.com added the comment: Because the use case is to copy the access and modification time from a file to another, I would prefer to use the timespec structure: (sec: int, nsec: int). st_atime_ns and st_mtime_ns fields would be added to os.stat() structure: int in range [0; 9]. Copy atime and mtime from src to dst: st = os.stat(src) atime = (math.floor(st.st_atime), st.st_atime_ns) mtime = (math.floor(st.st_mtime), st.st_mtime_ns) os.utime(dst, (atime, mtime)) os.utime() would accept int, float or (sec: int, nsec: int) for atime and mtime. Examples: os.utime(name, (1, 1)) os.utime(name, (1.0, 1.0)) os.utime(name, ((1, 0), (1, 0))) -- nosy: +haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14127 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14127] os.stat and os.utime: allow preserving exact metadata
Antoine Pitrou pit...@free.fr added the comment: os.utime() would accept int, float or (sec: int, nsec: int) for atime and mtime. That's not future-proof for when we have better-than-nanosecond timestamps. See my suggestion above. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14127 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14127] os.stat and os.utime: allow preserving exact metadata
Larry Hastings la...@hastings.org added the comment: Actually, I'm hoping that by the time we get better than nanosecond resolution, we can also switch to 128-bit floats, and then the existing st_[acm]time field will become the preferred representation once more. What goes around comes around! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14127 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14127] os.stat and os.utime: allow preserving exact metadata
Antoine Pitrou pit...@free.fr added the comment: Actually, I'm hoping that by the time we get better than nanosecond resolution, we can also switch to 128-bit floats, and then the existing st_[acm]time field will become the preferred representation once more. What if your hope isn't fulfilled? That doesn't sound like a reasonable decision-making strategy. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14127 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14085] PyUnicode_WRITE: comparison is always true warnings
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset ba0bd949ddf5 by Victor Stinner in branch 'default': Close #14085: remove assertions from PyUnicode_WRITE macro http://hg.python.org/cpython/rev/ba0bd949ddf5 -- nosy: +python-dev resolution: - fixed stage: - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14085 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14127] os.stat and os.utime: allow preserving exact metadata
Larry Hastings la...@hastings.org added the comment: Well, Guido has already nixed future-proof formats, see his comments above: I take full responsibility for fixing the precision at ns. So hope is all I have left. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14127 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14127] os.stat and os.utime: allow preserving exact metadata
Antoine Pitrou pit...@free.fr added the comment: Well, Guido has already nixed future-proof formats, see his comments above: I don't think Guido is *against* future-proof formats per se, he's against them when they have a cost compared to non future-proof ones. The proposal I made (a (integral part, float fractional part) tuple) doesn't have a cost compared to the plain (int seconds, int nanoseconds) tuple proposal. (of course, you can also have nanoseconds as a float, but that starts being weird) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14127 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14127] os.stat and os.utime: allow preserving exact metadata
Larry Hastings la...@hastings.org added the comment: I grant you that (int, float) is probably, theoretically better than (int, int). But it's academic as Guido has ruled against anything but a straight int representing nanoseconds, and I doubt he's gonna change his mind. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14127 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14127] os.stat and os.utime: allow preserving exact metadata
Guido van Rossum gu...@python.org added the comment: Any solution involving tuple is too ugly. Please stick with the plan. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14127 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14127] os.stat and os.utime: allow preserving exact metadata
Antoine Pitrou pit...@free.fr added the comment: I grant you that (int, float) is probably, theoretically better than (int, int). But it's academic as Guido has ruled against anything but a straight int representing nanoseconds, and I doubt he's gonna change his mind. Why not let Guido speak out? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14127 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14127] os.stat and os.utime: allow preserving exact metadata
Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com added the comment: The following solution might be compatible with Guido's suggestion: os.stat(path).st_atime_ns - nanoseconds_since_epoch_as_int os.stat(path).st_ctime_ns - nanoseconds_since_epoch_as_int os.stat(path).st_mtime_ns - nanoseconds_since_epoch_as_int atime = os.stat(path).st_atime_ns mtime = os.stat(path).st_mtime_ns os.utime(path, (atime, mtime), resolution=ns) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14127 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14127] os.stat and os.utime: allow preserving exact metadata
Guido van Rossum gu...@python.org added the comment: I don't see how that's better than os.utime(path, ns=(atime, mtime)) If you think that in the future you could add resolution=fs, well, you could just as easily add fs=(atime, mtime). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14127 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14188] Sharing site-packages between Apply and python.org builds breaks extensions
Ned Deily n...@acm.org added the comment: Sorry, I can't reproduce the problem. By default and by design, Library/Python/2.7/site-packages comes last in sys.path for the python.org installed Pythons. Are you sure you aren't overriding sys.path with a PYTHONPATH environment variable or some change to site.py? $ /usr/bin/python2.7 Python 2.7.1 (r271:86832, Jun 16 2011, 16:59:05) [GCC 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00)] on darwin Type help, copyright, credits or license for more information. import sys; from pprint import pprint as pp ; pp(sys.path) ['', '/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python27.zip', '/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7', '/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-darwin', '/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-mac', '/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-mac/lib-scriptpackages', '/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python', '/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-tk', '/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-old', '/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload', '/Users/pyi/Library/Python/2.7/lib/python/site-packages', '/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/PyObjC', '/Library/Python/2.7/site-packages'] import pysvn pysvn module 'pysvn' from '/Library/Python/2.7/site-packages/pysvn/__init__.py' ^D pyb7:~ pyi$ /usr/local/bin/python2.7 Python 2.7.2 (v2.7.2:8527427914a2, Jun 11 2011, 15:22:34) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin Type help, copyright, credits or license for more information. import sys; from pprint import pprint as pp ; pp(sys.path) ['', '/Library/Frameworks/Python.framework/Versions/2.7/lib/python27.zip', '/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7', '/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-darwin', '/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-mac', '/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-mac/lib-scriptpackages', '/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-tk', '/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-old', '/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload', '/Users/pyi/Library/Python/2.7/lib/python/site-packages', '/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages', '/Library/Python/2.7/site-packages'] import pysvn pysvn module 'pysvn' from '/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/pysvn/__init__.py' -- assignee: - ned.deily nosy: +ned.deily resolution: - works for me stage: - committed/rejected ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14188 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14188] Sharing site-packages between Apply and python.org builds breaks extensions
Changes by Ned Deily n...@acm.org: -- status: open - pending ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14188 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14184] test_recursion_limit fails on OS X when compiled with clang
Changes by Ned Deily n...@acm.org: -- assignee: - ned.deily nosy: +ned.deily stage: - needs patch title: test_recursion_limit - test_recursion_limit fails on OS X when compiled with clang ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14184 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14128] _elementtree should expose types and factory functions consistently with ElementTree
Eli Bendersky eli...@gmail.com added the comment: I'll go on and commit this. The test suite of ET is not bad and all tests keep passing. Stylistic issues and best practices can be fixed later. I want to have other work done on _elementtree, and having several patches to the same source file is very inconvenient. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14128 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14189] Documentation for some C APIs is missing clear specification of the type of reference they return
New submission from Baruch Sterin pyt...@bsterin.com: In addition to the description text, most C API functions have a one-line, emphasized specification whether they return a new or a borrowed reference. (e.g. 'Return value: New reference.'). The following API functions are missing that. Some of them, like PyMemoryView_FromBuffer(), have descriptions that are clear, but it would still be nice to have an unambiguous statement like most other API functions have. The list has been generated automatically, so it might contain some errors. Doc/c-api/arg.rst: Py_VaBuildValue Doc/c-api/buffer.rst: PyMemoryView_FromBuffer Doc/c-api/buffer.rst: PyMemoryView_FromObject Doc/c-api/buffer.rst: PyMemoryView_GetContiguous Doc/c-api/bytearray.rst: PyByteArray_Concat Doc/c-api/bytearray.rst: PyByteArray_FromObject Doc/c-api/bytearray.rst: PyByteArray_FromStringAndSize Doc/c-api/code.rst: PyCode_New Doc/c-api/codec.rst: PyCodec_BackslashReplaceErrors Doc/c-api/codec.rst: PyCodec_Decode Doc/c-api/codec.rst: PyCodec_Decoder Doc/c-api/codec.rst: PyCodec_Encode Doc/c-api/codec.rst: PyCodec_Encoder Doc/c-api/codec.rst: PyCodec_IgnoreErrors Doc/c-api/codec.rst: PyCodec_IncrementalDecoder Doc/c-api/codec.rst: PyCodec_IncrementalEncoder Doc/c-api/codec.rst: PyCodec_LookupError Doc/c-api/codec.rst: PyCodec_ReplaceErrors Doc/c-api/codec.rst: PyCodec_StreamReader Doc/c-api/codec.rst: PyCodec_StreamWriter Doc/c-api/codec.rst: PyCodec_StrictErrors Doc/c-api/codec.rst: PyCodec_XMLCharRefReplaceErrors Doc/c-api/exceptions.rst: PyUnicodeDecodeError_Create Doc/c-api/exceptions.rst: PyUnicodeDecodeError_GetEncoding Doc/c-api/exceptions.rst: PyUnicodeDecodeError_GetObject Doc/c-api/exceptions.rst: PyUnicodeDecodeError_GetReason Doc/c-api/exceptions.rst: PyUnicodeEncodeError_Create Doc/c-api/exceptions.rst: PyUnicodeTranslateError_Create Doc/c-api/float.rst: PyFloat_GetInfo Doc/c-api/import.rst: PyImport_GetImporter Doc/c-api/import.rst: PyImport_ImportModuleNoBlock Doc/c-api/import.rst: _PyImport_FindExtension Doc/c-api/import.rst: _PyImport_FixupExtension Doc/c-api/init.rst: PyEval_GetCallStats Doc/c-api/int.rst: PyInt_FromSize_t Doc/c-api/long.rst: PyLong_FromSize_t Doc/c-api/long.rst: PyLong_FromSsize_t Doc/c-api/number.rst: PyNumber_Index Doc/c-api/number.rst: PyNumber_ToBase Doc/c-api/object.rst: PyObject_Bytes Doc/c-api/object.rst: PyObject_GenericGetAttr Doc/c-api/unicode.rst: PyUnicode_AsUTF32String Doc/c-api/unicode.rst: PyUnicode_DecodeMBCSStateful Doc/c-api/unicode.rst: PyUnicode_DecodeUTF32 Doc/c-api/unicode.rst: PyUnicode_DecodeUTF32Stateful Doc/c-api/unicode.rst: PyUnicode_DecodeUTF7 Doc/c-api/unicode.rst: PyUnicode_DecodeUTF7Stateful Doc/c-api/unicode.rst: PyUnicode_EncodeUTF32 Doc/c-api/unicode.rst: PyUnicode_EncodeUTF7 Doc/c-api/veryhigh.rst: PyEval_EvalCodeEx Doc/c-api/veryhigh.rst: PyEval_EvalFrame Doc/c-api/veryhigh.rst: PyEval_EvalFrameEx -- assignee: docs@python components: Documentation messages: 154877 nosy: baruch.sterin, docs@python priority: normal severity: normal status: open title: Documentation for some C APIs is missing clear specification of the type of reference they return type: behavior versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14189 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14128] _elementtree should expose types and factory functions consistently with ElementTree
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset ce1c26cbe5fb by Eli Bendersky in branch 'default': Issue #14128: Exposing Element as an actual type from _elementtree, rather than a factory function. http://hg.python.org/cpython/rev/ce1c26cbe5fb -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14128 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14190] Minor C API documentation bugs
New submission from Baruch Sterin pyt...@bsterin.com: The following functions are documented, but do not exist in the code: * PyCodec_KnownEncoding * PyRun_SimpleFileFlags The following function is documented and exists in the code, but is not exposed through any of the header files: PyParser_SimpleParseStringFlagsFilename The prototype in the documentation is incorrect: * PyOS_stricmp returns int, not char* * PyOS_strnicmp returns int, not char* * PyCode_GetNumFree accepts a PyCodeObject* not PyObject* * PyCode_NewEmpty returns a PyCodeObject* not PyObject* * PyFile_SetBufSize accepts a PyObject*, not PyCodeObject * PyGILState_GetThisThreadState returns PyThreadState* not PyThreadState * PyUnicode_EncodeRawUnicodeEscape accepts 2, not 3 arguments * PyUnicode_RichCompare returns PyObject*, not int * PyType_IS_GC needs a PyTypeObject*, not PyObject* * PyType_HasFeature needs a PyTypeObject*, not PyObject* In addition, PyLong_FromSsize_t and PyLong_FromSsize_t are documented twice in long.html. -- assignee: docs@python components: Documentation messages: 154879 nosy: baruch.sterin, docs@python priority: normal severity: normal status: open title: Minor C API documentation bugs type: behavior versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14190 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11477] Bug in code dispatching based on internal slots
Changes by Eric Snow ericsnowcurren...@gmail.com: -- nosy: +eric.snow ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11477 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14191] argparse: nargs='*' doesn't parse all positional parameters
New submission from Glenn Linderman v+pyt...@g.nevcal.com:
To me, all positional parameters mean whether they are in the front, back or
middle, as long as they are not diriectly preceded by an option that can accept
an unlimited number of parameters.
from argparse import ArgumentParser, SUPPRESS, REMAINDER
import sys
print( sys.version )
parser = ArgumentParser()
parser.add_argument('--foo', dest='foo')
parser.add_argument('--bar', dest='bar')
parser.add_argument('baz', nargs='*')
print( parser.parse_args('a b --foo x --bar 1 c d'.split()))
# expected: Namespace(bar='1', baz=['a', 'b', 'c', 'd'], foo='x')
# actual: error: unrecognized arguments: c d
Above also supplied as a test file, t12.py
--
components: Library (Lib)
files: t12.py
messages: 154880
nosy: v+python
priority: normal
severity: normal
status: open
title: argparse: nargs='*' doesn't parse all positional parameters
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file24726/t12.py
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14191
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
