Georg Brandl [EMAIL PROTECTED] added the comment:
Assigning to the 2.4/2.5 RM.
--
assignee: jhylton - loewis
nosy: +loewis
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1569356
___
Georg Brandl [EMAIL PROTECTED] added the comment:
Patch looks good.
--
nosy: +georg.brandl
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4558
___
___
Georg Brandl [EMAIL PROTECTED] added the comment:
Thanks, fixed the docs in r67605.
--
resolution: - fixed
status: open - closed
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4557
___
Georg Brandl [EMAIL PROTECTED] added the comment:
This can be seen as a reminder for #1717.
I've fixed the whatsnew in r67606.
--
assignee: georg.brandl - gvanrossum
nosy: +gvanrossum
resolution: - fixed
status: open - closed
superseder: - Get rid of more refercenes to __cmp__
Georg Brandl [EMAIL PROTECTED] added the comment:
cmp() the function is also still there.
--
priority: high - critical
resolution: fixed -
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1717
___
Christian Heimes [EMAIL PROTECTED] added the comment:
The updated patch moves the compiler option to the right place.
Added file: http://bugs.python.org/file12247/with_stdc89_2.patch
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4558
Martin v. Löwis [EMAIL PROTECTED] added the comment:
Because of the incompatibility in locals(), this patch cannot be backported.
--
versions: +Python 2.6 -Python 2.4
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1569356
New submission from Lennart Regebro [EMAIL PROTECTED]:
The whatsnew/3.0.rst document claims
It is not recommended to try to write source code that runs unchanged
under both Python 2.6 and 3.0; you’d have to use a very contorted coding
style, e.g. avoiding print statements, metaclasses, and much
Raymond Hettinger [EMAIL PROTECTED] added the comment:
No thanks. We need to STRONGLY discourage such efforts. The official
recommended approach is to run 2.6 with a -3 option to identify code
that cannot be automatically converted and then after making the
appropriate updates to use the
Lennart Regebro [EMAIL PROTECTED] added the comment:
That is not true, and statement as it stands now is still factually
incorrect.
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4559
___
Raymond Hettinger [EMAIL PROTECTED] added the comment:
Guido, the OP wants you to change your long-standing guidance on the
relationship between 2.6 and 3.0. Care to pronounce?
--
assignee: georg.brandl - gvanrossum
nosy: +gvanrossum
___
Python
New submission from Jonathan Feinberg [EMAIL PROTECTED]:
http://docs.python.org/3.0/whatsnew/3.0.html#library-changes
Some modules were renamed because their old name flaunted PEP 0008
should read Some modules were renamed because their old name flouted
PEP 0008.
--
assignee:
Georg Brandl [EMAIL PROTECTED] added the comment:
It's already disobeyed in SVN.
--
resolution: - fixed
status: open - closed
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4560
___
Raymond Hettinger [EMAIL PROTECTED] added the comment:
Updated again in r67607. Hopefully, this one has been put to rest. If
someone has further issues with the super() docs, please open a new
report (preferably with suggested wording).
--
resolution: - fixed
status: open - closed
Georg Brandl [EMAIL PROTECTED] added the comment:
You are quite right. I've given PIPE and STDOUT their own entries now in
r67608.
--
status: pending - closed
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4488
New submission from Christian Heimes [EMAIL PROTECTED]:
The new io library needs some serious profiling and optimization work.
I've already fixed a severe slowdown in _fileio.FileIO's read buffer
allocation algorithm (#4533).
More profiling tests have shown a speed problem in write() files
David M. Beazley [EMAIL PROTECTED] added the comment:
I've done some profiling and the performance of reading line-by-line is
considerably worse in Python 3 than in Python 2. For example, this
code:
for line in open(somefile.txt):
pass
Ran 35 times slower in Python 3.0 than Python 2.6
Christian Heimes [EMAIL PROTECTED] added the comment:
Your issue is most like caused by #4533. Please download the latest svn
version of Python 3.0 (branches/release30_maint) and try again.
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4561
Antoine Pitrou [EMAIL PROTECTED] added the comment:
There may be other places this can happen but I haven't checked yet.
PyByteArray_Resize() is called in various places in bytearrayobject.c,
some of them where it is mandatory to mutate the underlying storage
before reallocating it. The
Christian Heimes [EMAIL PROTECTED] added the comment:
Here is a patch againt the py3k branch that reduces the time for the
line ending detection from 0.55s to 0.22s for a 50MB file on my test
system.
--
keywords: +patch
Added file:
Santiago Gala [EMAIL PROTECTED] added the comment:
Note that if the error is in the documentation semantics, and not in the
implementation, then the benchmark code in the documentation is also
broken, and should be change to not use lock=True/False respectively...
I'm not sure if the patch here
Floris Bruynooghe [EMAIL PROTECTED] added the comment:
Hi, I'd like to confirm that Skip's last patch fixes the issue. Hope it
gets included soon!
Thanks
--
nosy: +flub
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4483
Santiago Gala [EMAIL PROTECTED] added the comment:
oops, there is a proper code patch in issue4449 , and the documentation
is right.
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3206
___
David M. Beazley [EMAIL PROTECTED] added the comment:
Tried this using projects/python/branches/release30-maint and using the
patch that was just attached. With a 66MB input file, here are the
results of this code fragment:
for line in open(BIGFILE):
pass
Python 2.6: 0.67s
Python 3.0:
David M. Beazley [EMAIL PROTECTED] added the comment:
Just as one other followup, if you change the code in the last example
to use binary mode like this:
for line in open(BIG,rb):
pass
You get the following results:
Python 2.6: 0.64s
Python 3.0: 42.26s (66 times slower)
New submission from Mariano M. Chouza [EMAIL PROTECTED]:
zip() function documentatio still shows the old behavior of the
function, returning a list.
http://docs.python.org/3.0/library/functions.html?highlight=zip#zip
--
assignee: georg.brandl
components: Documentation
messages: 77126
Georg Brandl [EMAIL PROTECTED] added the comment:
Fixed in r67609.
--
resolution: - fixed
status: open - closed
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4562
___
New submission from Ori Avtalion [EMAIL PROTECTED]:
The bulleted list of credits in the about page is turning people's
initials into numbering.
For example:
* A. Amoroso
* L. Peter Deutsch
appear as
* 1. Amoroso
* 12. Peter Deutsch
http://docs.python.org/about.html
--
Georg Brandl [EMAIL PROTECTED] added the comment:
David, the reading bug fix/optimization is not (yet?) on
release30-maint, only on branches/py3k.
--
nosy: +georg.brandl
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4561
New submission from Antoine Pitrou [EMAIL PROTECTED]:
The following code says it all:
class B(bytearray): pass
...
b = B.fromhex(0c0a)
b
bytearray(b'\x0c\n')
isinstance(b, B)
False
--
messages: 77130
nosy: pitrou
priority: normal
severity: normal
status: open
title:
David M. Beazley [EMAIL PROTECTED] added the comment:
Just checked it with branches/py3k and the performance is the same.
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4561
___
Changes by Mark Dickinson [EMAIL PROTECTED]:
--
assignee: - marketdickinson
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3439
___
___
New submission from Istvan Albert [EMAIL PROTECTED]:
The write performance into text files is substantially slower (5x-8x)
than that of python 2.5. This makes python 3.0 unsuited to any
application that needs to write larger amounts of data.
test code follows ---
New submission from Craig Holmquist [EMAIL PROTECTED]:
Applications on Windows that don't link to the MSVCR90.DLL via a
manifest are broken with Python 2.6.1. This includes apps that link
with the C library statically and apps that link with other versions of
it. These applications worked fine
Changes by Craig Holmquist [EMAIL PROTECTED]:
Added file: http://bugs.python.org/file12249/testpy.c
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4566
___
___
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment:
- the add_ast_fields() function seems to be added by this patch, but it
is already in svn.
- Are 1-tuple supported?
t = [1]
global a, = t
--
nosy: +amaury.forgeotdarc
___
Python
Antoine Pitrou [EMAIL PROTECTED] added the comment:
New bytearray patch at http://codereview.appspot.com/10049. I think I've
covered all bases. array.array will need another patch (I must admit I
care a bit less about it, since it's not a builtin type).
The patch will have to be backported for
Craig Holmquist [EMAIL PROTECTED] added the comment:
I've attached the test program I was using. The commands I used to
compile it are:
cl /MT /c /IC:\Python26\include testpy.c
link /LIBPATH:C:\Python26\libs testpy.obj
___
Python tracker [EMAIL PROTECTED]
Mark Dickinson [EMAIL PROTECTED] added the comment:
Applied to py3k in r67610.
--
status: open - closed
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4445
___
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment:
This is expected: the I/O stack has been completely rewritten... in
almost pure-python code.
There is a project to rewrite it in C. It started at
http://svn.python.org/view/sandbox/trunk/io-c/
--
assignee: - amaury.forgeotdarc
Mark Dickinson [EMAIL PROTECTED] added the comment:
The segfault is a little worrying; I don't understand that at all.
Skip, can you come up with a configure patch that would allow isinf to be
detected on Solaris?
I'll also patch Py_IS_INFINITY to make sure that it forces its argument
into
Roumen Petrov [EMAIL PROTECTED] added the comment:
There is no reason to overload configure script.
Please look into pyport.h :
#define Py_LOCAL(type) static type
#define Py_LOCAL_INLINE(type) static inline type
Someone add USE_INLINE - not finished.
I guess that other source files has to use
Craig Holmquist [EMAIL PROTECTED] added the comment:
I've attached a manifest file that references the C runtime; adding this
file to the Apache bin folder seems to workaround this issue.
Added file: http://bugs.python.org/file12250/httpd.exe.manifest
___
Guido van Rossum [EMAIL PROTECTED] added the comment:
Bah. That means we'll have to start deprecating cmp() in 3.1, and won't
be able to remove it until 3.2 or 3.3. :-)
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1717
Mark Dickinson [EMAIL PROTECTED] added the comment:
Skip, Jean:
Could you try the attached patch to see if it fixes the math.log and
math.log10 test failures. (The patch is generated against the trunk, but
should apply cleanly to py3k or either of the 2.6 or 3.0 maintenance
branches.
Added
Roumen Petrov [EMAIL PROTECTED] added the comment:
P.S. About C++ comments ( // ) I think that another issue is already
opened (problem on AIX ? ) .
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4558
___
Christian Heimes [EMAIL PROTECTED] added the comment:
Python core code must be compliant with the C89 standard but we don't
have any checks for C89 compatibility. This patch adds a clean way to
check our code base.
You can verify my patch by adding a // comment somewhere in the code and
Mark Dickinson [EMAIL PROTECTED] added the comment:
Damien, if you're still there:
Please could you try the patch math_log.patch attached to issue 3167,
and let me know whether it fixes the test failure?
___
Python tracker [EMAIL PROTECTED]
n03702 [EMAIL PROTECTED] added the comment:
There is port of cross-2.6-0.7.diff patch for python 3.0 final
--
nosy: +n03702
Added file: http://bugs.python.org/file12252/cross-3.0-0.7.diff
___
Python tracker [EMAIL PROTECTED]
Skip Montanaro [EMAIL PROTECTED] added the comment:
Mark Could you try the attached patch to see if it fixes the math.log
Mark and math.log10 test failures. (The patch is generated against the
Mark trunk, but should apply cleanly to py3k or either of the 2.6 or
Mark 3.0 maintenance
Benoit Boissinot [EMAIL PROTECTED] added the comment:
Why does it need to be in 2.6? mimetools is still there.
Because it outputs a warning with python2.6 -3, it's annoying for people
trying to port their application to python3k
--
nosy: +bboissin
Skip Montanaro [EMAIL PROTECTED] added the comment:
Fix checked in for py3k (r67612), release26-maint (r67613),
release30-maint (r67615) branches as well as trunk (r67614).
--
resolution: - fixed
status: open - closed
___
Python tracker [EMAIL
New submission from Stuart Axon [EMAIL PROTECTED]:
If the msi is installed with /quiet it installs to the default location,
but the registry key is not set, making it harder for other programs to
find the installation.
- in my case I had to make a batch file that installed it, then read
the
Roumen Petrov [EMAIL PROTECTED] added the comment:
make EXTRA_CFLAGS='-std=c89' works for me.
Added file: http://bugs.python.org/file12253/python-trunk-20081206-c89.patch
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4558
Guido van Rossum [EMAIL PROTECTED] added the comment:
It is true for 2.6 unless you use various from __future__ imports, which
I consider a form of contortion.
Even with 2.6 I don't see how you can specify a metaclass without doing
something weird like
foo = MyMetaclass('foo', bases_tuple,
Istvan Albert [EMAIL PROTECTED] added the comment:
Well I would strongly dispute that anyone other than the developers
expected this. The release documentation states:
The net result of the 3.0 generalizations is that Python 3.0 runs the
pystone benchmark around 10% slower than Python 2.5.
Benjamin Peterson [EMAIL PROTECTED] added the comment:
I think I may have been merging add_ast_fields when I wrote the patch.
Here's a new patch that handles global x, = (5,). To do it, I added a
new flag* to the Global and Nonlocal AST objects that indicates whether
the value needs to be
Changes by Mark Dickinson [EMAIL PROTECTED]:
--
versions: +Python 3.1
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4084
___
___
Python-bugs-list
David M. Beazley [EMAIL PROTECTED] added the comment:
bash-3.2$ uname -a
Darwin david-beazleys-macbook.local 9.5.1 Darwin Kernel Version 9.5.1: Fri
Sep 19 16:19:24 PDT 2008; root:xnu-1228.8.30~1/RELEASE_I386 i386
bash-3.2$ ./python.exe -c import sys; print(sys.version)
3.1a0 (py3k:67609, Dec 6
Lennart Regebro [EMAIL PROTECTED] added the comment:
A future import is not much of a contortion, and metaclasses is not
exactly an everyday occurrence, after 9 years of python I have yet to
write a metaclass...
Of course I don't like that it specifically mentiones 2.6, while 2.6 has
lot's of
Skip Montanaro [EMAIL PROTECTED] added the comment:
can you come up with a configure patch that would allow isinf to be
detected on Solaris?
The plot thickens. I know squat about autoconf sorts of things so I
asked on the autoconf mailing list. Eric Drake responded (in part):
The Python
Guido van Rossum [EMAIL PROTECTED] added the comment:
You're misrepresenting or misunderstanding the goal of 2.6. Its goal
isn't to make it easy to write code that runs under both. Its stated
goal is to make it easy to write code that can easily be *ported* to
3.0. That's a very different
Lennart Regebro [EMAIL PROTECTED] added the comment:
I've never said that is the goal. You are misrepresenting or
misinterpreting my standpoint.
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4559
___
Guido van Rossum [EMAIL PROTECTED] added the comment:
Then what did you mean by just to make it possible to write code
that runs under both ?
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4559
___
Lennart Regebro [EMAIL PROTECTED] added the comment:
Well, that *is* the intention of a from __future__ import, isn't it?
That doesn't mean that's the intention of 2.6 as a whole, just that
statement.
___
Python tracker [EMAIL PROTECTED]
Guido van Rossum [EMAIL PROTECTED] added the comment:
But that's all part of the make it easy to port strategy.
I stick to my claim that trying to write code that runs unchanged in 3.0
is a non-goal of Python 2.6, and I do not want to suggest that this is a
good idea in the official
Roumen Petrov [EMAIL PROTECTED] added the comment:
now 2008-12-06 trunk fail on linux
--
nosy: +rpetrov
versions: +Python 2.7
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4483
___
Roumen Petrov [EMAIL PROTECTED] added the comment:
may be patch is not applied correctly :
http://svn.python.org/view/python/trunk/setup.py?rev=67614view=auto
libraries = gdbm_libs ) )
? exts.append( Extension('dbm', ['dbmmodule.c'],
? define_macros=[('HAVE_GDBM_NDBM_H',None)],
?
Changes by Giampaolo Rodola' [EMAIL PROTECTED]:
--
nosy: +giampaolo.rodola
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4565
___
___
Python-bugs-list
Changes by Giampaolo Rodola' [EMAIL PROTECTED]:
--
nosy: +giampaolo.rodola
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4561
___
___
Python-bugs-list
Changes by Giampaolo Rodola' [EMAIL PROTECTED]:
--
nosy: +giampaolo.rodola
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4528
___
___
Python-bugs-list
Changes by Antoine Pitrou [EMAIL PROTECTED]:
--
nosy: +pitrou
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4561
___
___
Python-bugs-list mailing list
Antoine Pitrou [EMAIL PROTECTED] added the comment:
Hi Amaury,
There is a project to rewrite it in C
Thanks for publicizing this. I'm a bit surprised by the adopted
approach. It seems you are merely translating the Python code into C. I
think the proper approach for the buffered IO classes
Christian Heimes [EMAIL PROTECTED] added the comment:
For more bug reports see #4533 and #4561.
I suggest we close this bug report as duplicate and keep the discussion
in #4561.
--
nosy: +christian.heimes
___
Python tracker [EMAIL PROTECTED]
Changes by Christian Heimes [EMAIL PROTECTED]:
Removed file: http://bugs.python.org/file12248/count_linenendings.patch
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4561
___
Georg Brandl [EMAIL PROTECTED] added the comment:
I hope the smiley really indicates a joke...
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1717
___
___
Guido van Rossum [EMAIL PROTECTED] added the comment:
Well what would you suggest we do?
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1717
___
___
Georg Brandl [EMAIL PROTECTED] added the comment:
I'd release 3.0.1 quickly, maybe also with the in-development
improvements to the io library that alleviate the factor-1000 slowdowns.
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1717
Antoine Pitrou [EMAIL PROTECTED] added the comment:
I don't think this is a public API, so the function should probably be
renamed _count_lineendings.
Also, are there some benchmark numbers?
___
Python tracker [EMAIL PROTECTED]
Christian Heimes [EMAIL PROTECTED] added the comment:
I'll come up with some reading benchmarks tomorrow. For now here is a
benchmark of write(). You can clearly see the excessive usage of closed,
len() and isinstance().
Added file: http://bugs.python.org/file12256/test_write.log
Changes by Christian Heimes [EMAIL PROTECTED]:
Removed file: http://bugs.python.org/file12256/test_write.log
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4561
___
Christian Heimes [EMAIL PROTECTED] added the comment:
Roundup doesn't display .log files as plain text files.
Added file: http://bugs.python.org/file12257/test_write.txt
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4561
Brett Cannon [EMAIL PROTECTED] added the comment:
Benoit has a good point, so I have opened this issue again so we can get
2.7 even closer to 3.x compatibility.
--
resolution: fixed -
status: closed - open
___
Python tracker [EMAIL PROTECTED]
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment:
I'm a bit surprised by the adopted approach.
It seems you are merely translating the Python code into C.
I think the proper approach for the buffered IO classes would be
to use a fixed-size buffer which never gets reallocated.
You
Changes by Raymond Hettinger [EMAIL PROTECTED]:
--
nosy: +rhettinger
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1717
___
___
Python-bugs-list
Martin v. Löwis [EMAIL PROTECTED] added the comment:
I would claim that this is not a bug. There is simpler no other way to
deal with this entire SxS mess.
--
nosy: +loewis
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4566
Raymond Hettinger [EMAIL PROTECTED] added the comment:
Since cmp() was documented as removed in whatsnew3.0, it may be fair
game to complete the removal, treating it as a bugfix.
If as Georg suggests it is done *very* quickly in 3.0.1 (say in the next
week or so), it is likely harmless and
Christian Heimes [EMAIL PROTECTED] added the comment:
A mess it is :/
--
nosy: +christian.heimes
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4566
___
Christian Heimes [EMAIL PROTECTED] added the comment:
A quick ballot on #python-dev resulted in 3 of 3 votes for removing
cmp() in a quick bug fix release.
About the io misery:
My quick fix for the buffer reallocation schema has made the situation a
bit better. For the 3.0.x series I like to
New submission from Gregg Lind [EMAIL PROTECTED]:
In the trunk (r67617) documentation for *optparse* callback example 6
doesn't handle negative number arguments, and fixing it is left as an
exercise for the reader. Well, I'm a reader, and I've attached my stab
at it. Caveat: It relies in
gumpy [EMAIL PROTECTED] added the comment:
It turns out the problems in array are more serious than I thought and
allow writing to unallocated memory through a memoryview leading to
memory corruption, segfaults and possibly exploits. The following
example extends an array enough to trigger a
Guido van Rossum [EMAIL PROTECTED] added the comment:
OK, remove it in 3.0.1, provided that's released this year.
Performance fixes are always fair game for bugfix releases.
Please don't fix the what's new document (or undo the fix).
I do hope cmp() was already undocumented elsewhere.
Martin v. Löwis [EMAIL PROTECTED] added the comment:
Can you please be more explicit? What exact command line have you been
using, and what exact registry do you think should have been set but wasn't?
--
nosy: +loewis
___
Python tracker [EMAIL
Changes by Barry A. Warsaw [EMAIL PROTECTED]:
--
priority: deferred blocker - release blocker
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4449
___
Changes by Barry A. Warsaw [EMAIL PROTECTED]:
--
priority: critical - release blocker
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1717
___
___
Changes by Barry A. Warsaw [EMAIL PROTECTED]:
--
priority: high - release blocker
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4561
___
___
Changes by Barry A. Warsaw [EMAIL PROTECTED]:
--
priority: high - release blocker
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4565
___
___
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment:
Do the API functions PyObject_Compare() and PyObject_Cmp() also go away?
--
nosy: +amaury.forgeotdarc
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1717
Stuart Axon [EMAIL PROTECTED] added the comment:
Sure, no problem - sorry for the lack of detail...
The windows installer (tested on 2.5.2) normally puts some values in
the windows registry at:
HKEY_LOCAL_MACHINE\SOFTWARE\Python\PythonCore\version
(where version is the python version).
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment:
Do we also get rid of the tp_compare type slot? 6 types still use it,
they should convert this to a tp_richcompare slot
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1717
1 - 100 of 124 matches
Mail list logo
