[issue7188] optionxform documentation confusing

[Martin v . Löwis]

New submission from Martin v. Löwis :

In
http://stackoverflow.com/questions/1611799/preserve-case-in-configparser, 
somebody
is confused about adjusting ConfigParser.optionxform. The documentation
is indeed confusing, in particular by claiming that you should "set" it
to "str()". Even if you get what is meant by "setting" (i.e. not
"calling"), it's still nonsensical to suggest that it should be set to
an empty string.

--
assignee: georg.brandl
components: Documentation
messages: 94375
nosy: georg.brandl, loewis
severity: normal
status: open
title: optionxform documentation confusing

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7006] The replacement suggested for callable(x) in py3k is not equivalent

[Georg Brandl]

Georg Brandl  added the comment:

Not really, that was the last thing to get this issue closed.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7188] optionxform documentation confusing

[Georg Brandl]

Georg Brandl  added the comment:

Thanks, fixed in r75623.

--
resolution:  -> fixed
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6670] Printing the 'The Python Tutorial'

[brimac]

brimac  added the comment:

Georg, Ezio
Many Thanks
brimac

2009/10/22 Georg Brandl 

>
> Georg Brandl  added the comment:
>
> OK, fixed in Sphinx, and in the Python stylesheet in r75617.
>
> --
> resolution:  -> fixed
> status: open -> closed
>
> ___
> Python tracker 
> 
> ___
>

--
Added file: http://bugs.python.org/file15186/unnamed

___
Python tracker 

___Georg, EzioMany Thanksbrimac2009/10/22 
Georg Brandl rep...@bugs.python.org>

Georg Brandl ge...@python.org> 
added the comment:

OK, fixed in Sphinx, and in the Python stylesheet in r75617.

--
resolution:  -> fixed
status: open -> closed

___
Python tracker rep...@bugs.python.org>
http://bugs.python.org/issue6670>
___

___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7189] struct.calcsize returns strange size

[Igor Mikushkin]

New submission from Igor Mikushkin :

I think in second case struct size should be 53.

In [31]: struct.calcsize('ihhi35scc')
Out[31]: 49

In [32]: struct.calcsize('ihhi35scci')
Out[32]: 56

--
components: Library (Lib)
messages: 94379
nosy: igor.mikushkin
severity: normal
status: open
title: struct.calcsize returns strange size
type: behavior
versions: Python 2.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7189] struct.calcsize returns strange size

[Mark Dickinson]

Mark Dickinson  added the comment:

I think the calcsize result is correct here.  With the native struct 
format, padding is included in the struct.

In the second case, there are three bytes of padding after the 'cc' and 
before the 'i'.  This keeps the 'i' aligned on a 4-byte boundary.  If you 
look at the results of struct.pack, you can see the padding explicitly:

Python 2.6.1 (r261:67515, Jul  7 2009, 23:51:51) 
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import struct
>>> struct.pack('ihhi35scci', 123456789, 1, 1, 321456789, 
"abcdefghijklmnopqrstuvwxyz123456789", '+', '*', 231456789)
"\x15\xcd[\x07\x10'\x10'\x95\n)\x13abcdefghijklmnopqrstuvwxyz123456789+*\x
00\x00\x00\x15\xc0\xcb\r"

--
nosy: +mark.dickinson
resolution:  -> invalid
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7187] importlib/_bootstrap.py write_bytecode raises an IOError if it can't open the .pyc file for writing

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Wouldn't the problem disappear, though, if tkinter/__init__.py didn't
claim to be fresher than tkinter/__init__.pyc? Also, it would make the
pyc/pyo files actually useful, rather than having Python recompile the
source files again and again.
(see the modification dates in your listing)

--
nosy: +pitrou

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3488] Provide compress/uncompress functions on the gzip module

[Anand B Pillai]

Anand B Pillai  added the comment:

Can we include this for the next release ?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3488] Provide compress/uncompress functions on the gzip module

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
priority:  -> normal
stage:  -> patch review
versions: +Python 3.2 -Python 3.0

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6882] uuid creates zombies

[Eric Smith]

Eric Smith  added the comment:

Changed py3k version to use contextlib.closing in r75625.

--
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6882] uuid creates zombies

[Eric Smith]

Changes by Eric Smith :


--
priority:  -> normal
type:  -> behavior

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7150] datetime operations spanning MINYEAR give bad results

[Anand B Pillai]

Anand B Pillai  added the comment:

The issue is present in Python 3.0 and 2.5 as well.

Python 2.5.1 (r251:54863, Jul 17 2008, 13:21:31)
[GCC 4.3.1 20080708 (Red Hat 4.3.1-4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import datetime
>>> t0=datetime.datetime(1,1,1)
>>> d1,d2,d3=map(datetime.timedelta, range(1,4))
>>> t0-d1
Traceback (most recent call last):
  File "", line 1, in 
OverflowError: date value out of range
>>> t0-d2
datetime.datetime(1, 0, 255, 0, 0)

I think this is bug in datetime for all Python versions

--
nosy: +pythonhacker

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7190] TCP/IP?

[Justin]

New submission from Justin :

Mac OS X
IBook G4 PowerPC

when running target.py it works fine until i close the app without
ending the process. (before 'q' is entered by the user). sometimes
python will not allow the user to click in the window and have the
ability to type after running the target window. sometimes the mouse
clicks affect a part of IDLE up and left of where the actual click was.
when i ignore this error (this is the only thing i have open in IDLE) i
must fist close out of python and reopen target.py i have used this
approach to test and find that there are no bugs in my program (at least
it works above and beyond the specifications of my class assignment),
but every once in while i will get an error when trying to use 'q' to
end the program and python will state that win.getMouse() is not a
viable term to use, because (win) is already closed yet when 'q' is used
the if statement has the close command right underneath the get mouse
command.
*note* i have coded another program specifically from John Zelle's
"Python Programming: An Introduction to Computer Science" p.160
programming exercise #1 and my get display text, get mouse, then close
window is verbatim from that in target.py and it never showed an error
in the #1's program

IDLE can't bind TCP/IP port 8833, which is necessary to communicate with
its Python execution server. Either no networking is installed on this
computer or another process (another IDLE?) is using the port. Run IDLE
with the -n command line switch to start without a subprocess and refer
to Help/IDLE Help 'Running without a subprocess' for further details.

--
assignee: ronaldoussoren
components: Macintosh
files: target.py
messages: 94385
nosy: jlr2383, ronaldoussoren
severity: normal
status: open
title: TCP/IP?
type: crash
versions: Python 2.6
Added file: http://bugs.python.org/file15187/target.py

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7191] Odd behaviour with zlib.decompressobj optional parameter "wbits"

[Anand B Pillai]

New submission from Anand B Pillai :

>>> import zlib
>>> help(zlib.decompressobj)
Help on built-in function decompressobj in module zlib:

decompressobj(...)
decompressobj([wbits]) -- Return a decompressor object.

Optional arg wbits is the window buffer size.

I experimented with this parameter and by trial and
error found out that it accepts only values from 8 to
15 inclusive. 

>>> z=zlib.decompressobj(1)
Traceback (most recent call last):
  File "", line 1, in 
ValueError: Invalid initialization option
>>> z=zlib.decompressobj(7)
Traceback (most recent call last):
  File "", line 1, in 
ValueError: Invalid initialization option
>>> z=zlib.decompressobj(16)
Traceback (most recent call last):
  File "", line 1, in 
ValueError: Invalid initialization option

>>> z1=zlib.decompressobj(8)
>>> z2=zlib.decompressobj(15)

Now to the odd part. Let us create another decompressobj without any
parameter. 

>>> z3=zlib.decompressobj()

Now compress some data.
>>> c=zlib.compress("This is a medium line of text")

Decompress with z2 works fine.
>>> z3.decompress(c)
b'This is a medium line of text'

Decompress with z2 is also fine.

>>> z2.decompress(c)
b'This is a medium line of text'

However with z1 it fails.
>>> z1.decompress(c)
Traceback (most recent call last):
  File "", line 1, in 
zlib.error: Error -3 while decompressing: invalid window size

In fact, only the optional value of 15 seems to work 
for wbits, every other legal value (8-14) fails giving
the same error. I tried this with other random strings
with same effect.

Either there is no need to expose this as a parameter
or there could be a bug with how this parameter is used,
which has to be fixed. In either case, documentation
on this parameter has to be improved and legal range
of values should be provided.

--
components: Library (Lib)
messages: 94386
nosy: pythonhacker
severity: normal
status: open
title: Odd behaviour with zlib.decompressobj optional parameter "wbits"
type: behavior
versions: Python 3.0

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7192] webbrowser.get("firefox") does not work on Mac with installed Firefox

[Andrew Dalke]

New submission from Andrew Dalke :

I have Firefox and Safari installed on my Mac. Safari is the default.

I wanted to try out Crunchy (http://code.google.com/p/crunchy/). It's 
developed under Firefox and does not work under Safari. I tried. ;)

It starts the web browser with the following.

try:
client = webbrowser.get("firefox")
client.open(url)
return
except:
try:
client = webbrowser.get()
client.open(url)
return
except:
print('Please open %s in Firefox.' % url)

On my Mac, webbrowser.get("firefox") fails, so this ends up opening in 
Safari. Which does not work to view the code.

Thing is, I have Firefox installed, so it should work. But the Mac code in 
webbrowser appears to only open in the default browser.

The following bit of code works well enough to get crunchy to work

class MacOSXFirefox(BaseBrowser):
def open(self, url, new=0, autoraise=True):
subprocess.check_call(["/usr/bin/open", "-b", 
"org.mozilla.firefox", url])

register("firefox", None, MacOSXFirefox('firefox'), -1)

but I don't know enough about the Mac nor about webbrowser to know if I'm 
the right path. For example, I don't know if there are ways to support 
'new' and 'autoraise' through /usr/bin/open or if there's a better 
solution.

Attached is the full diff.

--
components: Library (Lib)
files: webbrowser.py.diff
keywords: patch
messages: 94387
nosy: dalke
severity: normal
status: open
title: webbrowser.get("firefox") does not work on Mac with installed Firefox
type: feature request
Added file: http://bugs.python.org/file15188/webbrowser.py.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7187] importlib/_bootstrap.py write_bytecode raises an IOError if it can't open the .pyc file for writing

[Dave Malcolm]

Dave Malcolm  added the comment:

Aha!  Thanks pitrou, looks like I managed to mess up my packaging (I was
wondering why no no-one else had run into this, looks like no-one else
made this mistake!).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7193] Popen blocks program from another thread

[Dan Griffin]

New submission from Dan Griffin :

When I create a thread that does a Popen it blocks the entire program. I
have attached a simple sample program. Whether I do Popen.wait or
Popen.poll the program blocks. I have done this on OSX 10.5 and 10.6. I
have not yet tried ussing the multiprocessing module.

--
components: Library (Lib)
files: subproc.py
messages: 94389
nosy: dgriff1
severity: normal
status: open
title: Popen blocks program from another thread
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file15189/subproc.py

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7193] Popen blocks program from another thread

[R. David Murray]

R. David Murray  added the comment:

You are calling the 'run' method of your test class, which runs the
subprocess in the main thread.  Try calling t.start() instead.

--
nosy: +r.david.murray
priority:  -> low
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7193] Popen blocks program from another thread

[Dan Griffin]

Dan Griffin  added the comment:

You are right, sorry to waste your time.

--
status: closed -> open

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7193] Popen blocks program from another thread

[Dan Griffin]

Changes by Dan Griffin :


--
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7194] test_thread is flaky

[Antoine Pitrou]

New submission from Antoine Pitrou :

test_thread sometimes tries to release an unacquired mutex. It is easier
to reproduce when using the "-j" option (on trunk and py3k, since the
option doesn't exist on 2.6/3.1):

./python -m test.regrtest -j4 test_thread test_thread test_thread
test_thread
test_thread
test_thread
test_thread
Unhandled exception in thread started by >
Traceback (most recent call last):
  File "/home/antoine/py3k/__svn__/Lib/test/test_thread.py", line 49, in
task
self.done_mutex.release()
_thread.error: release unlocked lock
test_thread

--
components: Library (Lib), Tests
messages: 94392
nosy: pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: test_thread is flaky
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7194] test_thread is flaky

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Fixed in trunk, py3k and 3.1. Waiting for 2.6 to unfreeze before merging
there.

--
assignee:  -> pitrou
resolution:  -> accepted
stage: needs patch -> committed/rejected
versions:  -Python 2.7, Python 3.1, Python 3.2

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7195] Value error 'path is on drive c: start on drive d:' in os.path.relpath

[Jason R. Coombs]

New submission from Jason R. Coombs :

A simple test fails:

Python 2.6.3 (r263rc1:75186, Oct 2, 2009, 20:40:30) [MSC v.1500 32 bit
(Intel)] on win32
>>> import os
>>> os.path.relpath('\\bar', 'd:\\')
Traceback (most recent call last):
  File "", line 1, in 
  File "C:\python\lib\ntpath.py", line 487, in relpath
% (path_list[0], start_list[0]))
ValueError: path is on drive C:, start on drive d:

If I change the current directory to 'E:\', the error changes to "path
is on drive E:, start on drive d:".

Clearly, relpath is doing some calculations based on the current
directory, although the documentation states that it should be
performing a relative path calculation based on the supplied start
("D:\" in this case).

In Python 3.1.1, the error is "path is on mount 'C:', start on mount 'd:'"

os.path.relpath should be able to perform relative path calculations
regardless of the current directory, or the documentation should explain
why the current directory is relevant when start is supplied.

--
components: Windows
messages: 94394
nosy: jaraco
severity: normal
status: open
title: Value error 'path is on drive c: start on drive d:' in os.path.relpath
type: behavior
versions: Python 2.6, Python 3.1

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1578269] Add os.link() and os.symlink() and os.path.islink() support for Windows

[Jason R. Coombs]

Jason R. Coombs  added the comment:

After some in-depth analysis, I determined the following:

1) The new symlink-aware os.stat has to find the target of a symlink to
properly function.
2) The previously-proposed patch uses GetFilenameByHandle in os.stat to
find the target, but this fails when a handle can't be obtained (such as
when a symlink points to pagefile.sys.
3) Explorer doesn't use GetFilenameByHandle. I used ProcMon to monitor
the API calls when it looks up the properties for a symlink to
pagefile.sys. It appears to use CreateFile and DeviceIoControl to trace
through the symlink chain.

So, I've written a proof of concept that determines a symlink target
using these API calls. The code is in jaraco.windows.filesystem at
https://svn.jaraco.com/jaraco/python/jaraco.windows/jaraco/windows/filesystem.py:trace_symlink_target
.  For convenience, I've pasted the most relevant code segments at
http://paste.turbogears.org/paste/122986 .

I'd like to get comments on this implementation before porting this to
the C code and adding it to the os.stat call. One of the aspects that
makes me uncomfortable is the fact that I have to call relpath between
each iteration.

I have tested this approach fairly thoroughly. It appears to work under
all circumstances (through multiple symlinks across drives and
ultimately pointing at pagefile.sys).

If no one can suggest a better approach, I plan to code this into the patch.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6986] _json crash on scanner/encoder initialization error

[STINNER Victor]

STINNER Victor  added the comment:

pitrou> Unit tests are definitely desireable!

done

pitou> I would also like the "alternate approach" fix, 
pitou> it would probably be cleaner.

done. See the new patch.

--
Added file: http://bugs.python.org/file15190/json-crash.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1087418] long int bitwise ops speedup (patch included)

[Tracy Poff]

Changes by Tracy Poff :


--
nosy: +sopoforic

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6986] _json crash on scanner/encoder initialization error

[Antoine Pitrou]

Antoine Pitrou  added the comment:

There is actually a Lib/json/tests/ directory contain all JSON tests,
you should add yours there.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6986] _json crash on scanner/encoder initialization error

[STINNER Victor]

STINNER Victor  added the comment:

pitrou> There is actually a Lib/json/tests/ directory contain all 
pitrou> JSON tests, you should add yours there.

My patch creates the file Lib/json/tests/test__json.py. Do you mean
that I should add the new tests to an existing file? Which one?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6986] _json crash on scanner/encoder initialization error

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Ah, my bad, I thought it created the file in Lib/test.
The tests probably need to be skipped if _json can't be imported, though.
(the _json accelerators are just an implementation detail)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1087418] long int bitwise ops speedup (patch included)

[Gregory Smith]

Gregory Smith  added the comment:

Actually, my view for 3.x is this: I do agree hugely with the 'top
level' decision to only have one type that handles everything, and
obviously the easiest way to get there is to just use the existing long
type. However, though the rad-2^15 implementation of the 'long' type was
a fine thing for the 2.x python where it's only used for relatively
unusual cases, I think it's too inefficient to use as the primary
integer type, so I'm wondering if there's a plan to replace it with
something more efficient (thus rendering this particular issue irrelevant).

I did spend some time delving into python internals years ago, but
haven't really looked into 3.x, so bear with me. I am aware of the
following 'speed tweaks' in Python 2.x integers, aren't these lost now?

   (1) integers all same size, allocated from linked-list pool instead
of from malloc
   (2) 'add' and 'sub' byte codes do special check in interpreter core
to see if ints being added, and will go direct to PyInt_FromLong where
possible

It would seem to me that a more suitable implementation would be to
store numbers as 32*k-bit 2's complement integers; I've used this in C++
libraries. Compared to the rad-15 sign/magnitude approach, it may seem
trickier to do carries but in practice it's not that big a deal. It also
basically assumes you have a decently fast 64-bit operation to do
multiplies and divides with, which I think is now reasonable. This
implementation will be much easier to optimize for the (now) extremely
common case where numbers fit into 32 bits.
It could also be possible to store 'wee' integers in a special pool and
only use malloc for larger ones. 

I know there's a lot of code in that module, virtually all of which
would be affected by this. But isn't this type now a big performance
factor in 3.x?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7196] Clarify str.split() behavior

[Gabriel Genellina]

New submission from Gabriel Genellina :

Clarify str.split() behavior; see discussion at http://
comments.gmane.org/gmane.comp.python.general/641120

--
assignee: georg.brandl
components: Documentation
files: stdtypes.diff
keywords: patch
messages: 94401
nosy: gagenellina, georg.brandl
severity: normal
status: open
title: Clarify str.split() behavior
versions: Python 2.7, Python 3.0, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file15191/stdtypes.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7196] Clarify str.split() behavior

[Raymond Hettinger]

Changes by Raymond Hettinger :


--
assignee: georg.brandl -> rhettinger
nosy: +rhettinger

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1087418] long int bitwise ops speedup (patch included)

[Antoine Pitrou]

Antoine Pitrou  added the comment:

The type is an important performance factor but most uses of it are for
small ints (< 2**32 or 2**64), so your approach wouldn't make much of a
difference.
Besides, there are already some improvements in the py3k branch (for
example, longs now use 30-bit "digits" on 64-bit systems).

> I am aware of the
> following 'speed tweaks' in Python 2.x integers, aren't these lost now?

Yes, they are. As a result, calculations on small ints have become a bit
slower.

--
nosy: +pitrou
versions: +Python 3.2 -Python 2.6, Python 3.1

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com