Tracy Chang added the comment:
Is this issue only to update the doc or need to update the Error message as
well? For error message, is it part of Sphinx?
--
nosy: +tracy.chang
___
Python tracker rep...@bugs.python.org
STINNER Victor added the comment:
I don't understand why /etc/services would miss. What is the current behaviour?
What is the error message?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20868
Changes by STINNER Victor victor.stin...@gmail.com:
--
nosy: +haypo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20868
___
___
Python-bugs-list
New submission from STINNER Victor:
I installed Python 3.4rc3 on Windows 7, I downgraded pip (from 1.5.3) to 1.5.3
and then I uninstalled Python 3.4rc3. Some files of pip and setuptools remaing
in C:\Python34, is it expected?
C:\Python34\Scripts:
easy_install-3.4.exe
easy_install.exe
pip.exe
Changes by STINNER Victor victor.stin...@gmail.com:
--
components: +Windows
versions: +Python 3.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20878
___
Changes by priya priyapappachan...@gmail.com:
--
keywords: +patch
Added file: http://bugs.python.org/file34324/__objclass__.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19281
___
New submission from STINNER Victor:
According to tracemalloc, import base64 allocates 920.6 kB of memory. The 3
top locations are:
Lib/base64.py:414: size=420 KiB, count=7226, average=59 B
_b85chars2 = [(a + b) for a in _b85chars for b in _b85chars]
Lib/base64.py:306: size=420 KiB,
New submission from Mark Lawrence:
The upgrade from 3.3.4 to 3.3.5 has removed py[w].exe from c:\windows. Tim
Golden has given a possible explanation here
https://mail.python.org/pipermail/python-list/2014-March/668674.html.
--
components: Installation, Windows
messages: 213019
nosy:
Martin v. Löwis added the comment:
I don't think Tim's theory is true, but I can't suggest a better explanation.
This would need to be debugged, by running
msiexec /i name-of-installer.msi /l*v python.log
and submitting the resulting python.log here.
--
nosy: +loewis
Martin v. Löwis added the comment:
This is indeed expected, and applies to any other packages you have installed
from PyPI as well (and also to any files that you manually created in the
installation directory). Python only removes what it installed itself.
--
resolution: - invalid
Xavier de Gaye added the comment:
Documentation update attached.
--
Added file: http://bugs.python.org/file34326/pdb_doc.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16596
___
Martin v. Löwis added the comment:
It's a classical time-space trade-off. I'm not sure this is a bug; if it is,
the reasonable change (IMO) is to just revert the introduction of these *2
tables, and loop through the output character-by-character.
I'd personally be in favor of such a change
Martin v. Löwis added the comment:
I'm also -0 on delayed creation of the tables. If these encodings are used, the
memory overhead will still occur.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20879
STINNER Victor added the comment:
I'd personally be in favor of such a change (drop the tables).
I didn't propose to drop the table, but create a table the first time that it
is needed.
I never used ascii85 nor base85 nor base32 in my applications. Maybe because
ascii85 and base85 are new
Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com:
--
nosy: +Arfrever
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20879
___
STINNER Victor added the comment:
base64_on_demand.patch: create tables the first time they are needed.
b85decode() already uses such trick to build _b85dec.
Note: a85decode() doesn't use a precomputed table.
If people think that these functions are too slow, they should propose an
Changes by R. David Murray rdmur...@bitdance.com:
--
nosy: +r.david.murray
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20879
___
___
New submission from Jey Narasimhan:
I was using Ubuntu 11.04 and Python 2.7.1+. The dev code was checkout from hg
clone http://hg.python.org/cpython.
Here is the full traceback of the crash report:
== CPython 3.4.0rc1+ (default:3ae2cd85a908, Mar 9 2014, 10:38:52) [GCC 4.5.2]
==
Serhiy Storchaka added the comment:
I was more interested in the import time, and it has slightly increased. Memory
consumption ((32**2+2*85**2)*sys.getsizeof(b'xx')/2**10 +
sys.getsizeof(dict.fromkeys(range(32**2))) +
2*sys.getsizeof(dict.fromkeys(range(85**2))) +
Serhiy Storchaka added the comment:
And here is similar patch for urllib.parse.
--
Added file: http://bugs.python.org/file34329/urlparse_lazy_init.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20879
STINNER Victor added the comment:
Here is simpler patch.
Your patch only changes _*tab2, not the smaller tables.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20879
___
Serhiy Storchaka added the comment:
Yes, because small tables consume two orders less memory.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20879
___
Zachary Ware added the comment:
For 2.7 and 3.3, the error message just needs to be fixed (s/3.0/3.x/); it
lives in the sphinx-build.py script somewhere in Doc/. For default, though,
since we now rely on an installed version of Sphinx rather than a checked out
version, the whole version
Zachary Ware added the comment:
Doc/README.txt will also probably need an update, at least on default.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20090
___
Mark Lawrence added the comment:
I did this. Install 3.4.0.rc3 and check that the py[w].exe files were in
c:\windows. Uninstall 3.3.5, the py[w].exe files had been deleted. Reinstall
3.3.5, py[w].exe were in c:\windows but I noticed that they were different
sizes from the 3.4 versions.
New submission from Adolph Atkins:
In Windows 7 64 bits,I can't install pip-1.5.4, nor ez_setup.py.
--
messages: 213034
nosy: Adolph.Atkins
priority: normal
severity: normal
status: open
title: Can't install pip-1.5.4, ez_setup.py
versions: Python 3.5
Zachary Ware added the comment:
You can rewrite about as much you want. The biggest restriction on that is
trying to keep existing links intact, which means either avoiding renaming or
removing sections, or being sure to keep a reference to the old name.
I have reservations about suggesting
R. David Murray added the comment:
3.5 doesn't exist yet. Neither pip nor ez_setup are part of the python standard
library. 3.4 *does* ship a version of pip for ease of initial installation,
but since you are saying you are failing to install pip itself, it doesn't
sound like you are testing
priya added the comment:
I added __objclass__ to the datamodel section. Patch is submitted for the same.
Can you clarify about the link to be provided from this section? I couldn't
find the classification function in Documentation.
--
nosy: +priyapappachan
New submission from Éric Araujo:
The OpenHatch project created this page for would-be GSoC/OPW participants:
https://openhatch.org/wiki/Contributing_to_Python (it’s also useful for anyone
wanting to contribute).
It contains platform-specific advice to install an IRC client and navigate
using
David Naylor added the comment:
As requested, please find attached the unit tests that check `flags' can handle
a u_short and `fflags' can handle a u_int.
--
keywords: +patch
Added file: http://bugs.python.org/file34330/test_kqueue.py.diff
___
David Naylor added the comment:
As requested, please find attached the unit tests that check `flags' can handle
a u_short and `fflags' can handle a u_int.
--
Added file: http://bugs.python.org/file34331/test_kqueue.py.diff
___
Python tracker
David Naylor added the comment:
As requested, please find attached the unit tests that check `flags' can handle
a u_short and `fflags' can handle a u_int.
--
Added file: http://bugs.python.org/file34333/test_kqueue.py.diff
___
Python tracker
David Naylor added the comment:
As requested, please find attached the unit tests that check `flags' can handle
a u_short and `fflags' can handle a u_int.
--
Added file: http://bugs.python.org/file34332/test_kqueue.py.diff
___
Python tracker
David Naylor added the comment:
As requested, please find attached the unit tests that check `flags' can handle
a u_short and `fflags' can handle a u_int.
--
Added file: http://bugs.python.org/file34335/test_kqueue.py.diff
___
Python tracker
New submission from Jurko Gospodnetić:
When running the Python Windows installer 'for all users', the 32-bit
installation and the 64-bit installation each gets a separate registration in
the Windows registry. E.g. under:
HKEY_LOCAL_MACHINE\Software\Python\PythonCore\3.4
and:
David Naylor added the comment:
As requested, please find attached the unit tests that check `flags' can handle
a u_short and `fflags' can handle a u_int.
--
Added file: http://bugs.python.org/file34334/test_kqueue.py.diff
___
Python tracker
Jurko Gospodnetić added the comment:
A possible solution would be to update installers and runners to use
HKEY_CURRENT_USER\Software\Wow6432Node registry entries for 32-bit 'for current
user only' installations on a 64-bit Windows OS.
To preserve backward compatibility, runners could fall
Changes by STINNER Victor victor.stin...@gmail.com:
--
nosy: +loewis, tim.golden
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20883
___
___
New submission from Jurko Gospodnetić:
Python 3.4 introduced a change to Lib/importlib/__init__.py that added the
following code to it:
else:
# importlib._bootstrap is the built-in import, ensure we don't create
# a second copy of the module.
_bootstrap.__name__ =
R. David Murray added the comment:
So you aren't running into problems with issue 20778? (That issue exists in
3.3 as well).
--
nosy: +brett.cannon, eric.snow, r.david.murray
___
Python tracker rep...@bugs.python.org
Brett Cannon added the comment:
Not having __file__ defined is an odd issue as importlib.__init__ always comes
from a file in CPython. I have no issue making the setting of the attribute
conditional, though.
--
___
Python tracker
Don Dwiggins added the comment:
Varun, thanks for the patch; sounds like the right way to go, in that it should
work whether the usage is single-connection or multiple-connection. Ideally,
the documentation would be expanded a bit to clarify just which attributes get
reset on close().
Jurko Gospodnetić added the comment:
David: Nope, the issue does not exist with 3.3.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20884
___
Changes by Barry A. Warsaw ba...@python.org:
--
nosy: +barry
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20884
___
___
Python-bugs-list mailing
M. Volz added the comment:
I've written and attached a patch for the list mutation question. I took a
little bit of a different tack on this and addressed a more general question
whilst still including list mutation as an example. I know the language can get
a little fussy on these sorts of
Martin v. Löwis added the comment:
This is not a bug in Python, but either intentional, or a bug in Windows.
Processing of Wow64Node is done by Windows, see
http://msdn.microsoft.com/en-us/library/windows/desktop/aa384253(v=vs.85).aspx
As you can see, the SOFTWARE key is redirected in
Éric Araujo added the comment:
Note that 3.4 finally removes getting Sphinx from a subversion repository, so
the installation instructions will need a version-specific part for that.
--
___
Python tracker rep...@bugs.python.org
Georg Brandl added the comment:
Thanks for your patience. I believe I have addressed all issues raised.
--
nosy: +georg.brandl
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15605
___
Roundup Robot added the comment:
New changeset f32569ddc2db by Georg Brandl in branch 'default':
Closes #15605: update and refurbish doc building section of the devguide.
http://hg.python.org/devguide/rev/f32569ddc2db
--
nosy: +python-dev
resolution: - fixed
stage: -
Éric Araujo added the comment:
Resources: http://nedbatchelder.com/text/names.html
http://python.net/~mwh/hacks/objectthink.html
--
nosy: +eric.araujo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20135
Roundup Robot added the comment:
New changeset 0ae254c11921 by Georg Brandl in branch '2.7':
Closes #20090: update Doc/README and the error message in sphinx-build.py to
make
http://hg.python.org/cpython/rev/0ae254c11921
--
nosy: +python-dev
resolution: - fixed
stage: -
Éric Araujo added the comment:
I think there was another issue discussing a separation between object.__str__
and someobject.__bytes__, to make it clear which are existing methods of the
object class and which are methods that one may implement in their classes.
--
Éric Araujo added the comment:
Updated text is clear and comprehensive, thanks!
Another edit could be done after the packaging docs is revamped to add links to
the pyvenv and pip sections of the doc, to avoid users reading “install Sphinx
and its deps” and not knowing how to do that.
Roundup Robot added the comment:
New changeset d975f50de5aa by Georg Brandl in branch '3.3':
Closes #20090: update Doc/README and the error message in sphinx-build.py to
make
http://hg.python.org/cpython/rev/d975f50de5aa
New changeset 43820a4fcaba by Georg Brandl in branch 'default':
Closes
Georg Brandl added the comment:
I think this should be sufficient.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20090
___
___
Python-bugs-list
Changes by Éric Araujo mer...@netwok.org:
--
nosy: +eric.araujo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19407
___
___
Python-bugs-list
New submission from David Edelsohn:
PowerLinux is shifting to Little Endian with a new ABI (ELFv2). Upstream libffi
includes support for the new ABI. What is the recommended method to merge
support into CPython? Will CPython update the base libffi or
_ctypes/libffi.diff should be updated?
Paul Moore added the comment:
OK, fair enough (I agree that the Windows behaviour here is the root cause of
the problem). However, it *would* have been possible for the registry keys to
be HKEY_LOCAL_MACHINE\Software\Python\PythonCore\3.4-32 and
Jurko Gospodnetić added the comment:
I'm against removing local user installation support because that is the only
way Python can be installed without write access to shared system locations
like the Windows system folder or the HKEY_LOCAL_MACHINE registry hive.
--
Paul Moore added the comment:
Agreed, that is not necessary. Nor was Martin suggesting it as far as I can
tell, he was simply saying that it would be less disruptive in the broader
scheme of things than messing with the Python registry scheme to work around
the limitation that 32 and 64 bit
Lita Cho added the comment:
I will go ahead and try to add the link to the page from the devguide. Thanks!
--
nosy: +Lita.Cho
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20882
___
Jurko Gospodnetić added the comment:
And as for simultaneous 64/32-bit Python installations on a single 64-bit
machine - as Paul said, whichever way Microsoft implemented its automatic
registry key redirection, it is up to Python to decide how its installer should
behave.
So the question is
Claudiu.Popa added the comment:
Updated the patch to catch dbm.dumb.error in tests (reverting a change added in
c2f1bb56760d).
--
Added file: http://bugs.python.org/file34337/issue19385.patch
___
Python tracker rep...@bugs.python.org
Jurko Gospodnetić added the comment:
Nor was Martin suggesting it as far as I can tell
I'm sorry if I came across too strongly. I can assure you I meant no disrespect
nor have I at any point felt affronted by anything anyone else said in this
thread/issue. :-)
--
Changes by Jessica McKellar jesst...@mit.edu:
--
nosy: +jesstess
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20882
___
___
Python-bugs-list
Éric Araujo added the comment:
Thanks for the patch. Could you make sure the text wraps at 80 characters?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19281
___
Éric Araujo added the comment:
I think Nick was referring to this function:
http://docs.python.org/3.4/library/inspect#inspect.ismethod
--
versions: +Python 2.7, Python 3.3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19281
R. David Murray added the comment:
I'm in favor of moving the FAQ answer Ezio identified to the Programming
section, myself, but I'd like concurrence from at least one other committer
before we do it.
--
___
Python tracker rep...@bugs.python.org
Claudiu.Popa added the comment:
Thanks for your patch, Fabrice!
I've uploaded a change to your patch, by adding a .webp test file and adding
the .webp format in imghdr's test suite.
--
Added file: http://bugs.python.org/file34338/issue20197.patch
Changes by Claudiu.Popa pcmantic...@gmail.com:
Added file: http://bugs.python.org/file34339/issue16104.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16104
___
Antoine Pitrou added the comment:
Victor's approach looks fine to me.
--
type: performance - resource usage
versions: +Python 3.5 -Python 3.3, Python 3.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20879
Changes by Xavier Combelle xavier.combe...@gmail.com:
--
nosy: +xcombelle
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20197
___
___
Lita Cho added the comment:
I added a link to the OpenHatch's Contributing to Python page right next to
the Getting Started link. I thought about adding it to Additional Resources,
but someone on the mailing list suggested it go somewhere on the top. I also
wanted to place it where it would
Changes by Claudiu.Popa pcmantic...@gmail.com:
Added file: http://bugs.python.org/file34341/issue20197_v1.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20197
___
Steve Dower added the comment:
I would be in favour of having separate keys for 32-bit and 64-bit installs (in
addition to the current one, if dropping it completely is not an option). We
use the registry keys in PTVS (http://pytools.codeplex.com/) to detect
installed interpreters, so the
Éric Araujo added the comment:
I think it would make sense to have the link at the top of the setup.rst file
instead, so that people being directly linked to that page would see the link
too.
--
___
Python tracker rep...@bugs.python.org
New submission from Sworddragon:
I have noticed that since Python 3.4 the interactive mode does log all commands
to ~/.python_history. This caused me to switch into normal user mode and look
for a solution. With Google I have found the related entry in the documentation:
On systems that
Lita Cho added the comment:
Hello! I would like to tackle this. Does that mean the documentation needs to
change such that it states that the TestSuite object is returned? It looks you
can iterate over the unittest.suite.TestSuite object, as I am getting something
like this:
Lita Cho added the comment:
Sure! I've changed it so that it is in the setup.rst. Does that work?
--
Added file: http://bugs.python.org/file34342/openhatch_setup.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20882
R. David Murray added the comment:
readline (all uses of readline, not just by python) can be controlled via the
'.inputrc' file, which is documented in the readline man page, which should be
available if readline is available :) Perhaps this should be mentioned in the
paragraph(s) where we
R. David Murray added the comment:
It should say that it finds all the test modules and returns a TestSuite
containing them.
--
nosy: +r.david.murray
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20030
Changes by Éric Araujo mer...@netwok.org:
--
assignee: docs@python - eric.araujo
stage: needs patch - commit review
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20882
___
Arfrever Frehtes Taifersar Arahesis added the comment:
I would suggest to support PYTHONHISTFILE variable (similar to HISTFILE and
LESSHISTFILE) and to not replace file pointed by this variable.
This shows that file is being currently replaced:
# cp /dev/null .python_history
# LC_ALL=C stat -c
Ned Deily added the comment:
I hope this can be resolved before the 3.4 final release or it will not be
possible to use cxFreeze with Python 3.4 without additional workarounds in
cxFreeze.
It's too late for this to go into 3.4.0 unless someone can make a really good
case to the release
Changes by Ned Deily n...@acm.org:
--
nosy: +amaury.forgeotdarc, belopolsky, meador.inge
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20885
___
New submission from mattip:
Files must be explicitly closed on pypy, and switch to use test_support.rmtree
which tries harder on Windows.
only test_zipfile.py is patched.
--
components: Tests
files: zipfile_patch
messages: 213086
nosy: mattip
priority: normal
severity: normal
status:
Changes by Brian Kearns bdkea...@gmail.com:
--
nosy: +bdkearns
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20887
___
___
Python-bugs-list
Nadja Deininger added the comment:
I tried to reproduce this by disabling my network connection and running these
tests, but they worked for me.
--
nosy: +ndeininger
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20483
Nick Coghlan added the comment:
It's at least a deferred blocker, and that's my instinct as to the right
setting (especially since we're assuming that 3.4.1 will happen a month or so
after the PyCon US sprints).
I'll dig into a bit more to see if I can provoke the misbehaviour (e.g. we may
Éric Araujo added the comment:
Thanks, I will change one detail and push this.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20882
___
___
Jurko Gospodnetić added the comment:
I'll try to set up and post a reproducible use case tomorrow. Then you can
decide. It could turn out that the use case we ran into has an easy workaround.
--
___
Python tracker rep...@bugs.python.org
Lita Cho added the comment:
Thank you!!
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20882
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Nick Coghlan ncogh...@gmail.com:
--
priority: normal - deferred blocker
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20884
___
___
Changes by Claudiu.Popa pcmantic...@gmail.com:
Added file: http://bugs.python.org/file34344/issue20197_v2.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20197
___
R. David Murray added the comment:
As far as I can tell from scanning this ticket, there was no agreement on
deprecating the parser argument to iterparse, but it has been documented as
deprecated with no documentation about what to replace it with, nor any
DeprecationWarning in the code that
Roundup Robot added the comment:
New changeset e6d862886e5c by R David Murray in branch 'default':
whatsnew: urllib Request objects are now reusable.
http://hg.python.org/cpython/rev/e6d862886e5c
--
___
Python tracker rep...@bugs.python.org
Roundup Robot added the comment:
New changeset fe1804387687 by R David Murray in branch 'default':
whatsnew: logging.config.listen *verify* (#15452).
http://hg.python.org/cpython/rev/fe1804387687
--
___
Python tracker rep...@bugs.python.org
Roundup Robot added the comment:
New changeset 2b1d5caf63ca by R David Murray in branch 'default':
whatsnew: filecmp.DEFAULT_IGNORES (#15442)
http://hg.python.org/cpython/rev/2b1d5caf63ca
--
___
Python tracker rep...@bugs.python.org
Roundup Robot added the comment:
New changeset e6d862886e5c by R David Murray in branch 'default':
whatsnew: urllib Request objects are now reusable.
http://hg.python.org/cpython/rev/e6d862886e5c
--
___
Python tracker rep...@bugs.python.org
1 - 100 of 123 matches
Mail list logo
