Vinay Sajip vinay_sa...@yahoo.co.uk added the comment:
Attached is a patch for distutils/sysconfig.py.
--
keywords: +patch
Added file: http://bugs.python.org/file18866/distutils_sysconfig.diff
___
Python tracker rep...@bugs.python.org
Vinay Sajip vinay_sa...@yahoo.co.uk added the comment:
Attached is a patch for sysconfig.py.
--
Added file: http://bugs.python.org/file18867/sysconfig.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6087
Vinay Sajip vinay_sa...@yahoo.co.uk added the comment:
N.B. without the sysconfig.py patch, sysconfig.get_path() fails, but
differently.
With the patch, sysconfig.get_path('stdlib') and sysconfig.get_path('include')
give the expected values, but _CONFIG_VARS['srcdir'] still seems wrong:
New submission from Eli Bendersky eli...@gmail.com:
The Py_Main function has a section under #ifdef __INSURE__ at the end, where it
does:
_Py_ReleaseInternedStrings();
_Py_ReleaseInternedUnicodeStrings();
The first function doesn't exist in Python 3K, so there will be a compile error
Martin v. Löwis mar...@v.loewis.de added the comment:
You may find this hard to believe, but we do in fact embed python
into other applications.
This is actually very easy to believe.
appMalloc, is in this case, the canonical memory allocator in
UnrealEngine. But it could be any other
Alex alex.gay...@gmail.com added the comment:
I doubt there is a good usecase for it, nevertheless we should attempt to fix
it, as segfaults are no good.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9743
Martin v. Löwis mar...@v.loewis.de added the comment:
It seems we need to clarify the return value of PyThread_create_key. The patch
returns 0 in case of failure, which is clearly wrong as 0 is also a valid key.
I think it's safe to return -1: TlsAlloc returns TLS_OUT_OF_INDEXES, which is
Kay Hayen kayha...@gmx.de added the comment:
Why did you remove Python2.7 from the versions list? Isn't this supposed to
track the affected versions? (This is not the first time I encountered that.)
I understand that you may not fix all bugs in 2.x, but is it already
unsupported in the sense
Marc-Andre Lemburg m...@egenix.com added the comment:
We can reconsider this at some later time, when Python 2.x is not really used
much anymore.
--
resolution: - postponed
status: open - closed
___
Python tracker rep...@bugs.python.org
Kristján Valur Jónsson krist...@ccpgames.com added the comment:
The malloc
implementation just has no business looking at the thread state.
Of course it does, if it you want to have any hope of instrumenting your python
memory usage with detailed python runtime information.
Your statement
Kristján Valur Jónsson krist...@ccpgames.com added the comment:
I've changed the function as you suggest, although there are in fact no failure
detection semantics defined for PyThread_create_key(). See e.g. thread.c:294
/* Return a new key. This must be called before any other functions in
Martin v. Löwis mar...@v.loewis.de added the comment:
Note that we are not making any new requirements on python here.
But you are. So far, there was no guarantee whatsoever about the state
of Python when malloc is called. You are now introducing a requirement
that Python must be in a certain
Florent Xicluna florent.xicl...@gmail.com added the comment:
now the PendingDeprecationWarnings are checked in the test suite, with r84772
(for 2.7).
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7994
Sébastien Sablé sa...@users.sourceforge.net added the comment:
Yes, no problem; I will update the Misc/AIX-NOTES file with all the information
I have been collecting recently on Python with AIX.
I will do that when I will have solved some remaining issues I have on AIX, and
also when I will
Martin v. Löwis mar...@v.loewis.de added the comment:
Am 13.09.2010 10:00, schrieb Kristján Valur Jónsson:
Kristján Valur Jónsson krist...@ccpgames.com added the comment:
I've changed the function as you suggest, although there are in fact no
failure detection semantics defined for
Steven Bethard steven.beth...@gmail.com added the comment:
Are you sure this is an argparse issue, and not a terminal issue? Here's what I
see:
parser = argparse.ArgumentParser(description=u'Rus Рус')
print(parser.description)
Rus Рус
sys.stderr.write(parser.description)
Traceback (most
R. David Murray rdmur...@bitdance.com added the comment:
We use versions to track which versions we are going to fix, not which versions
are affected (which is why we don't list any versions pre-2.5...2.5 and 2.6
occasionally get security fixes, but no earlier versions even get those).
Now,
STINNER Victor victor.stin...@haypocalc.com added the comment:
I fail to see why removing incorrect file names from the result
list is any better than keeping them. The result list will
be incorrect either way.
It depends if you focus on displaying the content of the directory, or on
STINNER Victor victor.stin...@haypocalc.com added the comment:
I think trying to emulate, in Python, what the *A functions
do is futile.
My problem is that some functions will use mbcs in strict mode (functions using
PyUnicode_EncodeFSDefault): raise UnicodeEncodeError, and other will use
Baptiste Carvello baptiste...@free.fr added the comment:
Eric: the bug does not exist with 2.7, as the Makefile is read as bytes.
It exists with 3.1.2.
By the way, when I say the bug is solved on 3.2, I only mean the narrow
problem of using a
non-ascii prefix that *is* decodable with the
R. David Murray rdmur...@bitdance.com added the comment:
After the decision to ignore undecodable file names in os.listdir but before
PEP 383 there was a long discussion on python-dev (in which I was a
participant) about how horrible just ignoring the undecodable filenames was.
This applies
R. David Murray rdmur...@bitdance.com added the comment:
But in the case of BZ2File and ssl.SSLContext.load_cert_chain(), isn't it the
case that they are trying to open the files? So producing an early error about
the decoding problem makes sense. Are there any functions other than listdir
New submission from Tarek Ziadé ziade.ta...@gmail.com:
Right now you have to override Request or patch its get_method() method to be
able to send HTTP requests where the method is not GET or POST.
This is making some assumptions on what the users wants to do with the request.
The way
Tarek Ziadé ziade.ta...@gmail.com added the comment:
sorry - Removed the assignment (the name is not followed by *)
--
assignee: orsenthil -
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9845
Nick Coghlan ncogh...@gmail.com added the comment:
I assume Brett marked this 3.x only because we currently don't support builtin
packages at all, so making this work crosses way over into feature request
territory. That makes it unsuitable for a branch in maintenance mode (i.e. 2.7).
Added
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
Would issue9527 address your request? Note that datetime.strftime already
supports %z:
from datetime import *
datetime.now(timezone.utc).strftime('%c %z')
'Mon Sep 13 13:43:19 2010 +'
(I assume you meant to write
Changes by Jon Anglin jang...@fortresgrand.com:
--
nosy: +janglin
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9784
___
___
Python-bugs-list
Changes by Jon Anglin jang...@fortresgrand.com:
--
nosy: +janglin
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9783
___
___
Python-bugs-list
Changes by Jon Anglin jang...@fortresgrand.com:
--
nosy: +janglin
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9782
___
___
Python-bugs-list
Changes by Antoine Pitrou pit...@free.fr:
--
stage: unit test needed -
type: behavior - feature request
versions: -Python 2.7, Python 3.1
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1076515
Changes by jan matejek jmate...@suse.cz:
--
nosy: +matejcik
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6706
___
___
Python-bugs-list mailing
Antoine Pitrou pit...@free.fr added the comment:
Can you try using CC=cc -m64 OPT=-O3 instead?
(replace cc with the proper compiler name, of course)
--
nosy: +pitrou
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9181
Changes by Jon Anglin jang...@fortresgrand.com:
--
nosy: +janglin
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9566
___
___
Python-bugs-list
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
The full path *could* be easily passed, but I think we should
address this problem from regrtest.py's side.
I disagree. There may be other scripts that rely on __main__.__file__ being an
absolute path and we cannot
Changes by Jon Anglin jang...@fortresgrand.com:
--
nosy: +janglin
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9614
___
___
Python-bugs-list
Antoine Pitrou pit...@free.fr added the comment:
Fix committed in r84774. Thank you!
--
resolution: - fixed
stage: - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9828
Changes by Chris Gerhard chris.gerh...@oracle.com:
--
nosy: +Chris.Gerhard
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4761
___
___
Charles Solar charlesso...@gmail.com added the comment:
I just recompiled using your suggested flags and it is now properly linking my
extensions. I guess using CFLAGS and LDFLAGS was causing the problem.
Is specifying CC the recommended way to build 64 bit python? If so when I
guess this
Antoine Pitrou pit...@free.fr added the comment:
Is specifying CC the recommended way to build 64 bit python?
Currently, yes. LDFLAGS is supposed to work, but it doesn't (open bug: #9437).
--
___
Python tracker rep...@bugs.python.org
Barry A. Warsaw ba...@python.org added the comment:
How is this different than overwriting pyc files, except that there's probably
less of a use case for pycs? IOW, if we were to do something about this, it
should probably be an option to ignore any existing pyc (or pyo if -O is used)
files
Barry A. Warsaw ba...@python.org added the comment:
My (I think fairly straightforward) idea is to just compile the useful values
in Makefile and config.h into _sysconfig.c and arrange for sysconfig to import
that and check it first (fallback to parsing mf and conf.h).
I'll see if I can whip
Antoine Pitrou pit...@free.fr added the comment:
Is there any point in creating another extension module?
We already have Modules/getpath.c which receives various configuration values
at compile-time, themselves exposed as sys.prefix and friends. The simpler the
better, IMO.
sysconfig can
sorin sorin.sbar...@gmail.com added the comment:
Please reopen the bug, current documentation change is not a proper solution
and also it does not work (see below).
Python's openssl repository contain pregenerated mak files (/ms/*.mak), when it
should not.
If you check openssl repository
Amaury Forgeot d'Arc amaur...@gmail.com added the comment:
What also worries me is the difference between the class statement and the
type() function.
class M_A(type):
def __new__(mcls, name, bases, ns):
print('M_A.__new__', mcls, name, bases)
return super().__new__(mcls,
Toshio Kuratomi a.bad...@gmail.com added the comment:
- RPM spec files, which use ASCII or UTF-8 according to
http://en.opensuse.org/openSUSE:Specfile_guidelines#Specfile_Encoding but
it’s not confirmed in
http://www.rpm.org/max-rpm/s1-rpm-build-creating-spec-file.html (linked
from the LSB
Tarek Ziadé ziade.ta...@gmail.com added the comment:
That's what I wanted to do first but it turned out to be a bad idea.
This duplication is unfortunate but the freeze is also to prevent third party
code that patches distutils to break.
For instance, there's a lot of code out there that just
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
Hmm, it looks like patches 5 and 6 lost the fix for the class name issue. I'll
check if I can merge in patch 4.
--
___
Python tracker rep...@bugs.python.org
sorin sorin.sbar...@gmail.com added the comment:
I made a small but important update to quote_command(), now it does quote the
command line only under Windows because doing this under other platforms may
break the command line.
--
___
Python
Florent Xicluna florent.xicl...@gmail.com added the comment:
I've made the wrong assumption that test.regrtest.__file__ is always absolute.
Here is a patch which should fix it.
--
nosy: +ezio.melotti
Added file: http://bugs.python.org/file18870/issue9323_regrtest.diff
New submission from John Admanski jadman...@gmail.com:
When creating a ZipExtFile through ZipFile.open, the if the original ZipFile
object was created with a filename then a new file object will be opened and
given to the ZipExtFile to use for its file operations. There is no explicit
Brett Cannon br...@python.org added the comment:
Both David and Nick are correct as to why I did what I did.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9716
___
Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com added the comment:
compileall module supports -f (force) option, so you can use:
python3.2 -O -m compileall -f ${files}
--
nosy: +Arfrever
___
Python tracker rep...@bugs.python.org
Barry A. Warsaw ba...@python.org added the comment:
Uh, duh. Thanks for reminding me about that Arfrever! :) That should be
everything Toshio needs I think. Plus this request is 4 years old.
Closing as won't fix.
--
resolution: - wont fix
status: open - closed
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
Committed with minor changes in r84777.
Eli, please keep lines under 80 characters.
Leaving the issue open pending py3k port.
--
resolution: - accepted
stage: patch review - committed/rejected
Toshio Kuratomi a.bad...@gmail.com added the comment:
It doesn't fix the problem as it falls into the third class of solutions (one
that requires cooperation by the system administrator to diagnose and fix).
OTOH, at this point in time I'm putting all of my packages in system packages
where
Antoine Pitrou pit...@free.fr added the comment:
Indeed. However, the ZipFile itself knows whether to close the file
(self._filePassed). By adding a constructor argument to ZipExtFile and a
__del__ method, it would solve the issue.
--
nosy: +pitrou
stage: - needs patch
versions:
Changes by Eli Bendersky eli...@gmail.com:
--
nosy: +eli.bendersky
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1397474
___
___
Python-bugs-list
Eli Bendersky eli...@gmail.com added the comment:
Terry,
I'm attaching a patch for 2.7, however it's more proof-of-concept than final,
because I have a few comments. The patch generally implements your
documentation suggestion without the `import *` warning and without adding the
final
New submission from James Hutchison jamesghutchi...@gmail.com:
Tested on Python 3.1.2 Windows XP 32-bit
Binary strings (such as what is returned by filereader.readline()) are never
equal to raw or normal strings, even when both strings are empty
if(b == ):
print(Strings are equal);
Eli Bendersky eli...@gmail.com added the comment:
Barry, I've taken the liberty to add you to the nosy list because I found in
the logs you've originally added this code (in 2001!!)
I hope it's OK with you :-)
--
nosy: +barry
___
Python tracker
Florent Xicluna florent.xicl...@gmail.com added the comment:
regrtest fixed with r84776 (3.x) and r84779 (2.7)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9323
___
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
Eli, while porting your tests to py3k, I had to change expected output for list
comprehension testing. This is not really surprising because 3.x
comprehensions differ from 2.x (they don't leak the loop variable anymore).
Barry A. Warsaw ba...@python.org added the comment:
Thanks Toshio, I get it now. I think pre-generating the proper pyo's is
probably the best solution.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1538778
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
Committed in:
py3k: r84780
release31-maint: r84783
release27-maint: r84777
Need a separate issue for the problem highlighted in msg116336.
--
status: open - closed
___
Python
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
Since noone have spoken in favor of 2.7 backport, I am closing this issue as
committed to py3k.
--
keywords: -needs review
resolution: - accepted
stage: patch review - committed/rejected
status: pending - closed
Florent Xicluna florent.xicl...@gmail.com added the comment:
You probably missed Lib/test/tracedmodules/ in r84780 ;)
--
keywords: +buildbot
nosy: +flox
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9315
New submission from Arfrever Frehtes Taifersar Arahesis
arfrever@gmail.com:
_weakref module is a built-in module in Python 3 since r58602, but references
to _weakref module in setup.py haven't been removed. They can be removed in
py3k and 3.1 branches.
setup.py in 2.7 branch (since
Changes by Santoso Wijaya santa@me.com:
--
nosy: +santa4nt
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6706
___
___
Python-bugs-list mailing
Mark Dickinson dicki...@gmail.com added the comment:
Of course, there are subtle implications of how it will be implemented
Indeed. Ideally, as you mention, the implementation would only use __lt__ (as
with sort and bisect). I think that constraint only leaves one reasonable
choice:
Changes by STINNER Victor victor.stin...@haypocalc.com:
Removed file: http://bugs.python.org/file18841/test_pep277.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue767645
___
Martin v. Löwis mar...@v.loewis.de added the comment:
Perhaps we can simply call Py_FatalError() instead? There's not much we
can do when such a failure occurs anyway.
Sounds fine as well. Python's own usage definitely shouldn't fail. If
extension modules use this in an aggressive manner,
Martin v. Löwis mar...@v.loewis.de added the comment:
My (I think fairly straightforward) idea is to just compile the
useful values in Makefile and config.h into _sysconfig.c and arrange
for sysconfig to import that and check it first (fallback to parsing
mf and conf.h).
You seem to suggest
STINNER Victor victor.stin...@haypocalc.com added the comment:
r84784 sets os.path.supports_unicode_filenames to True on Mac OS X (macpath
module).
About test_supports_unicode_filenames.patch. test_unicode_listdir() is wrong:
os.listdir(str) always return str (see r84701). verify that the new
STINNER Victor victor.stin...@haypocalc.com added the comment:
I backported r84701 and r84784 to Python 2.7 (r84787).
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue767645
___
R. David Murray rdmur...@bitdance.com added the comment:
Assuming we can break backward compatibility, it sounds fine to me.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9360
___
Changes by Giampaolo Rodola' g.rod...@gmail.com:
--
nosy: +giampaolo.rodola
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9360
___
___
Eric Smith e...@trueblade.com added the comment:
Manually merged to py3k in r84790. I'll leave this open until I create the 3.3
issue to change it to a DeprecationWarning.
--
keywords: -needs review
versions: -Python 3.3
___
Python tracker
Alexander Belopolsky alexander.belopol...@gmail.com added the comment:
You must be right. I thought I did all the svn adds, but may have missed
something. I'll take care of this tonight, but I am off the grid for the next
3-4 hours.
On Sep 13, 2010, at 3:13 PM, Florent Xicluna
Daniel Stutzbach dan...@stutzbachenterprises.com added the comment:
Committed as r84791.
Question: should this bugfix be backported to Python 3.1 and to xrange objects
in Python 2.7? Since it's a bugfix that adds new methods, it's a gray-area.
(same question applies to the closely related
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
Committed in r84792.
--
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9840
Ned Deily n...@acm.org added the comment:
There seems to be some confusion about the macpath.py module. I'm not sure why
it even exists in Python 3. Note it has to do with obsolete Classic
MacOS-style paths (colon-separated paths) which are available on Mac OS X only
through deprecated
New submission from Jason Baker amnorv...@gmail.com:
This is referring to argparse 1.1 installed under Python 2.6. When I was
passing in an nargs flag, I figured that since '+' and '*' are valid options, I
should pass in strings. So when I tried passing in the string '1' instead of
the
John Admanski jadman...@gmail.com added the comment:
I'm not sure that's much of an improvement on the existing behavior, though; as
I mentioned you can already work around it by killing all the references to the
ZipExtFile and the underlying file object will get automatically closed if the
Ned Deily n...@acm.org added the comment:
Note, argparse is not part of the Python standard library in 2.6 but the 2.7
and 3.2 versions exhibit the same behavior.
--
assignee: - bethard
nosy: +bethard, ned.deily
versions: +Python 2.7, Python 3.2 -Python 2.6
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
You probably missed Lib/test/tracedmodules/
fixed in r84794.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9315
Hirokazu Yamamoto ocean-c...@m2.ccsnet.ne.jp added the comment:
I propose following solution.
* svn copy http://svn.python.org/projects/external/bzip2-1.0.5
http://svn.python.org/projects/external/bzip2-1.0.5.0
* fix makefile in
http://svn.python.org/projects/external/bzip2-1.0.5
* svn
Hirokazu Yamamoto ocean-c...@m2.ccsnet.ne.jp added the comment:
I tried test_tar_pipe_open_read_error_v2.py on py3k,
I saw 3 uncollectable objects are reported. But they
are *collected* by gc.collect() without
gc.set_debug(gc.DEBUG_LEAK). (I'm not familiar to gc,
so maybe this is normal)
I
R. David Murray rdmur...@bitdance.com added the comment:
Antoine, any reason not to put the close in the ZipFileExt close method instead
of a __del__ method? (And document it, of course).
--
nosy: +r.david.murray
___
Python tracker
Martin v. Löwis mar...@v.loewis.de added the comment:
Another solution would be not to make clean, but del *.obj.
However, I would prefer if we stopped using makefile.msc altogether,
and explicitly included the source files of bzip2 into bz2.vcproj, similar to
the way _bsddb is built (in 2.7).
New submission from Ned Deily n...@acm.org:
The macpath module in the standard library purports to supply the Mac OS 9
(and earlier) implementation of the os.path module. It can be used to
manipulate old-style Macintosh pathnames on Mac OS X (or any other platform).
The following functions
Ned Deily n...@acm.org added the comment:
The macpath module in the standard library purports to supply the Mac OS 9
(and earlier) implementation of the os.path module. It can be used to
manipulate old-style Macintosh pathnames on Mac OS X (or any other platform).
The following functions
91 matches
Mail list logo
