[issue1858] Make .pypirc handle multiple servers

[Tarek Ziadé]

Tarek Ziadé <[EMAIL PROTECTED]> added the comment:

This is because the code uses a print statement when opening the .pypirc
file. This was already the case before this patch, but the code was not
covered by tests. (see in previous revision)

The test is not broken, it just ouputs to stdin. 

I would suggest closing this issue and opening a new one entitled:
"distutils should used the logging module to produce output" maybe ?

__
Tracker <[EMAIL PROTECTED]>

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

[issue1798] Add ctypes calling convention that allows safe access of errno

[Armin Rigo]

Armin Rigo <[EMAIL PROTECTED]> added the comment:

> However, even the TLS copy of errno may change because of this,
> if the finalizer of some object invokes ctypes, right?

Yes, it's annoying, but at least the Python programmer has a way to fix
this problem: he can save and restore the TLS copy of errno around the
call to ctypes done in the finalizer, using get_errno()/set_errno(). 
This matches what a C programmer would have to do if he wanted to write,
say, a debugging function that can be called from anywhere including
between an OS call and the following check for errno.

(Another note: the C-level errno and the TLS copy should also be
synchronized when the C code invokes a Python callback.)

In PyPy, when creating and using our own internal FFI, we started by
having a pair of functions that could directly read or change the
C-level errno.  Then we ran into various troubles (e.g. just stepping
through the Python code in a debugger messes things up because of the
debugger's own input/output) and finally reached the design I propose
here.  (Admittedly PyPy's internal FFI is a bit more low-level than
ctypes, so maybe it's more appropriate for ctypes to use a higher-level
approach that a return value checker.)

(A related issue that we may or may not care about: it's more than
likely that various people have already come up with various workarounds
to handle errno, and these workarounds will probably stop working after
ctypes is changed...)

__
Tracker <[EMAIL PROTECTED]>

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

[issue1858] Make .pypirc handle multiple servers

[Martin v. Löwis]

Martin v. Löwis <[EMAIL PROTECTED]> added the comment:

> This is because the code uses a print statement when opening the .pypirc
> file. This was already the case before this patch, but the code was not
> covered by tests. (see in previous revision)
> 
> The test is not broken, it just ouputs to stdin. 
> 
> I would suggest closing this issue and opening a new one entitled:
> "distutils should used the logging module to produce output" maybe ?

The test *is* (or was) broken - regrtest reported it as a failure.
It effectively, actually, caused a failure of the buildbot slaves.
In any case, I have now replaced the print with self.announce, in
r63575.

__
Tracker <[EMAIL PROTECTED]>

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

[issue1858] Make .pypirc handle multiple servers

[Tarek Ziadé]

Tarek Ziadé <[EMAIL PROTECTED]> added the comment:

Right, Thanks!

__
Tracker <[EMAIL PROTECTED]>

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

[issue2889] curses for windows (alternative patch)

[Martin v. Löwis]

Martin v. Löwis <[EMAIL PROTECTED]> added the comment:

The patch, in its current form, is incomplete. Can you please provide:

a) a VS 2008 project file, which builds both the curses module and the
   pdcurses library, fetching the sources for that from ../../pdcurses (or 
   some such); the project file should be structured similar to all the 
   other project files in PCbuild
b) a patch to PCbuild/readme.txt, with instructions on how to build the 
   extension

--
nosy: +loewis

__
Tracker <[EMAIL PROTECTED]>

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

[issue2956] 2to3 should have a way to disable some fixers

[Haoyu Bai]

New submission from Haoyu Bai <[EMAIL PROTECTED]>:

Sometime we need to enable all fixers but one or two, eg. the 'import'
fixer. So it would be fine if there's a way to do that.

--
assignee: collinwinter
components: 2to3 (2.x to 3.0 conversion tool)
messages: 67289
nosy: bhy, collinwinter
severity: normal
status: open
title: 2to3 should have a way to disable some fixers
type: feature request
versions: Python 3.0

__
Tracker <[EMAIL PROTECTED]>

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

[issue2957] recursion limit exceeded when importing .pyc module

[Haoyu Bai]

New submission from Haoyu Bai <[EMAIL PROTECTED]>:

To reproduce the bug, save the uploaded huge.py, then import the module
twice:

$ python3 -c 'import huge'
$ python3 -c 'import huge'
Traceback (most recent call last):
  File "", line 1, in 
ValueError: recursion limit exceeded

But there's no such problem in Python 2.5.2.

--
components: Interpreter Core
files: huge.py
messages: 67290
nosy: bhy
severity: normal
status: open
title: recursion limit exceeded when importing .pyc module
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file10423/huge.py

__
Tracker <[EMAIL PROTECTED]>

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

[issue2507] Exception state lives too long in 3.0

[Antoine Pitrou]

Antoine Pitrou <[EMAIL PROTECTED]> added the comment:

This is a complementary patch that should fix the remaining cases
(funnily doctest was relying on the old behaviour).
Unfortunately #2833 still remains, and would probably need some
discussion on the ML for proper resolution.

Added file: http://bugs.python.org/file10424/better_exc_cleanup.patch

__
Tracker <[EMAIL PROTECTED]>

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

[issue2956] 2to3 should have a way to disable some fixers

[Guilherme Polo]

Guilherme Polo <[EMAIL PROTECTED]> added the comment:

Once I wanted this too. I'm attaching two patches but I prefer the
former which allows the skipped fixer(s) to be logged.

--
keywords: +patch
nosy: +gpolo
Added file: http://bugs.python.org/file10425/fixer_skip.diff

__
Tracker <[EMAIL PROTECTED]>

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

[issue2956] 2to3 should have a way to disable some fixers

[Guilherme Polo]

Changes by Guilherme Polo <[EMAIL PROTECTED]>:


Added file: http://bugs.python.org/file10426/fixer_skip2.diff

__
Tracker <[EMAIL PROTECTED]>

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

[issue2507] Exception state lives too long in 3.0

[Benjamin Peterson]

Benjamin Peterson <[EMAIL PROTECTED]> added the comment:

For time being, should r62847 be reverted?

--
nosy: +benjamin.peterson

__
Tracker <[EMAIL PROTECTED]>

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

[issue2955] Python 2.5 Documentation error in Tutorial section 8.3

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:

What makes you think that the code does not match the description?

--
nosy: +amaury.forgeotdarc

__
Tracker <[EMAIL PROTECTED]>

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

[issue2507] Exception state lives too long in 3.0

[Antoine Pitrou]

Antoine Pitrou <[EMAIL PROTECTED]> added the comment:

I don't think so. As Amaury pointed in #2833, the original re-raising
behaviour which got changed by fixing the present bug was rather broken
in its own way.
Anyway, I think the question better be asked on the ML because any
solution for the re-raising behaviour will require some significant
trickery in the compiler and the eval loop.

__
Tracker <[EMAIL PROTECTED]>

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

[issue2806] Py30a5: Tk Menu Alt-f behaves differently Linux vs Windows

[Guilherme Polo]

Guilherme Polo <[EMAIL PROTECTED]> added the comment:

I just got an information here.. The new way is the recommended way
since Tk 8.0

__
Tracker <[EMAIL PROTECTED]>

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

[issue2955] Python 2.5 Documentation error in Tutorial section 8.3

[Georg Brandl]

Georg Brandl <[EMAIL PROTECTED]> added the comment:

Closing as "works for me".

--
resolution:  -> works for me
status: open -> closed

__
Tracker <[EMAIL PROTECTED]>

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

[issue2950] silly readline module problem

[Guilherme Polo]

Guilherme Polo <[EMAIL PROTECTED]> added the comment:

You need to install the development package of readline in order to have
the readline module compiled. And this is not a bug.

--
nosy: +gpolo
resolution:  -> invalid
status: open -> closed

__
Tracker <[EMAIL PROTECTED]>

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

[issue2806] Py30a5: Tk Menu Alt-f behaves differently Linux vs Windows

[Guilherme Polo]

Guilherme Polo <[EMAIL PROTECTED]> added the comment:

Using a frame and menubutton for creating a menubar has been deprecated
for a long time. I tried finding when exactly it got "marked as
deprecated", but I found just this page http://wiki.tcl.tk/4055 which
says about a decade ago.

--
nosy: +gpolo
status: open -> closed

__
Tracker <[EMAIL PROTECTED]>

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

[issue2958] update Lib/test/README

[Benjamin Peterson]

New submission from Benjamin Peterson <[EMAIL PROTECTED]>:

A good bug day task:

Lib/test/README is a bit dated. It still talks about old-style Python
tests which have been almost completely removed in 2.6 (and none more
should be written.) The assert* methods of unittest should also be
stressed instead of test_support.verify etc.

--
components: Tests
keywords: easy
messages: 67300
nosy: benjamin.peterson
priority: low
severity: normal
status: open
title: update Lib/test/README
type: feature request
versions: Python 2.6

__
Tracker <[EMAIL PROTECTED]>

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

[issue2507] Exception state lives too long in 3.0

[Antoine Pitrou]

Changes by Antoine Pitrou <[EMAIL PROTECTED]>:


Removed file: http://bugs.python.org/file10424/better_exc_cleanup.patch

__
Tracker <[EMAIL PROTECTED]>

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

[issue2507] Exception state lives too long in 3.0

[Antoine Pitrou]

Antoine Pitrou <[EMAIL PROTECTED]> added the comment:

Patch removed, there are still some unsolved cases :-)

__
Tracker <[EMAIL PROTECTED]>

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

[issue2833] __exit__ silences the active exception

[Antoine Pitrou]

Antoine Pitrou <[EMAIL PROTECTED]> added the comment:

Just found another funny example. This one fails also before r62847.

def except_yield():
try:
raise Exception("foo")
except:
yield 1
raise
list(except_yield())

In Py3k (with or without r62487), we get "RuntimeError: No active
exception to reraise".
In Python 2.5, we get "TypeError: exceptions must be classes, instances,
or strings (deprecated), not NoneType".

__
Tracker <[EMAIL PROTECTED]>

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

[issue2944] asyncore doesn't handle connection refused correctly

[Giampaolo Rodola']

Changes by Giampaolo Rodola' <[EMAIL PROTECTED]>:


--
nosy: +giampaolo.rodola, josiah.carlson, josiahcarlson

__
Tracker <[EMAIL PROTECTED]>

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

[issue2888] pprint produces different output in 2.6 and 3.0

[Facundo Batista]

Facundo Batista <[EMAIL PROTECTED]> added the comment:

It's not a 2.6 bug, as it behaves exactly as the documentation states.

In Py3 it *is* different the result than the documentation. However,
it's not clear to me if this behaviour is changed deliberately or by
mistake (personally, I prefer this new way of showing it, so the
documentation should be fixed).

What do you think?

--
nosy: +facundobatista
versions:  -Python 2.6

__
Tracker <[EMAIL PROTECTED]>

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

[issue2904] Cross-referencing to a method using an alternate title don't work with add_function_parentheses=True

[Georg Brandl]

Georg Brandl <[EMAIL PROTECTED]> added the comment:

This should now be fixed in r63580.

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

__
Tracker <[EMAIL PROTECTED]>

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

[issue2852] sidebar directive fails

[Georg Brandl]

Georg Brandl <[EMAIL PROTECTED]> added the comment:

This should now be fixed in SVN.

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

__
Tracker <[EMAIL PROTECTED]>

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

[issue2944] asyncore doesn't handle connection refused correctly

[Giampaolo Rodola']

Giampaolo Rodola' <[EMAIL PROTECTED]> added the comment:

By trying your script on Linux and Windows I notice different behaviors.
On Windows handle_expt is always called.
On Linux, no matter if using select or poll, handle_accept is called,
then an exception is thrown at the time the data is going to be sent:

Traceback (most recent call last):
  File "index.py", line 34, in 
test()
  File "index.py", line 31, in test
asyncore.loop(use_poll=1)
  File "/usr/lib/python2.5/asyncore.py", line 205, in loop
poll_fun(timeout, map)
  File "/usr/lib/python2.5/asyncore.py", line 190, in poll2
readwrite(obj, flags)
  File "/usr/lib/python2.5/asyncore.py", line 101, in readwrite
obj.handle_error()
  File "/usr/lib/python2.5/asyncore.py", line 93, in readwrite
obj.handle_read_event()
  File "/usr/lib/python2.5/asyncore.py", line 400, in handle_read_event
self.handle_connect()
  File "index.py", line 17, in handle_connect
self.send("hello world")
  File "/usr/lib/python2.5/asyncore.py", line 481, in send
self.initiate_send()
  File "/usr/lib/python2.5/asyncore.py", line 468, in initiate_send
num_sent = dispatcher.send(self, self.out_buffer[:512])
  File "/usr/lib/python2.5/asyncore.py", line 345, in send
result = self.socket.send(data)
socket.error: (111, 'Connection refused')


In my opinion both behaviors are wrong since neither handle_expt nor
handle_connect should be called in case of a "connection refused" event.
Especially handle_connect should not be called at all since no
connection takes place.
The correct behavior here must be identifying when such event occurs,
raise the proper exception (ECONNREFUSED) and let it propagate until
handle_error which will take care of it.

__
Tracker <[EMAIL PROTECTED]>

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

[issue2926] Revert SocketServer rename in 2.6

[Georg Brandl]

Georg Brandl <[EMAIL PROTECTED]> added the comment:

Okay, moved the module and applied the patch in r63586, r63587 and r63589.

--
nosy: +georg.brandl
resolution:  -> accepted
status: open -> closed

__
Tracker <[EMAIL PROTECTED]>

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

[issue2944] asyncore doesn't handle connection refused correctly

[Alexander Shigin]

Alexander Shigin <[EMAIL PROTECTED]> added the comment:

Oh, fine. May be handle_error should have been called, but anyway not 
handle_connect. 

But in my mind, handle_expt is better.

__
Tracker <[EMAIL PROTECTED]>

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

[issue2636] Regexp 2.6 (modifications to current re 2.2.2)

[Jeffrey C. Jacobs]

Changes by Jeffrey C. Jacobs <[EMAIL PROTECTED]>:


Added file: http://bugs.python.org/file10428/issue2636-05-only.diff

__
Tracker <[EMAIL PROTECTED]>

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

[issue2636] Regexp 2.6 (modifications to current re 2.2.2)

[Jeffrey C. Jacobs]

Jeffrey C. Jacobs <[EMAIL PROTECTED]> added the comment:

I am finally making progress again, after a month of changing my 
patches from my local svn repository to bazaar hosted on launchpad.net, 
as stated in my last update.  I also have more or less finished the 
probably easiest item, #5, so I have a full patch for that available 
now.  First, though, I want to update my "No matter what" patch, which 
is to say these are the changes I want to make if any changes are made 
to the Regexp code.

Added file: http://bugs.python.org/file10427/issue2636.diff

__
Tracker <[EMAIL PROTECTED]>

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

[issue2636] Regexp 2.6 (modifications to current re 2.2.2)

[Jeffrey C. Jacobs]

Changes by Jeffrey C. Jacobs <[EMAIL PROTECTED]>:


Added file: http://bugs.python.org/file10429/issue2636-05.diff

__
Tracker <[EMAIL PROTECTED]>

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

[issue2636] Regexp 2.6 (modifications to current re 2.2.2)

[Jeffrey C. Jacobs]

Changes by Jeffrey C. Jacobs <[EMAIL PROTECTED]>:


Removed file: http://bugs.python.org/file10056/issue2636-05.patch

__
Tracker <[EMAIL PROTECTED]>

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

[issue2871] store thread.get_ident() thread identifier inside threading.Thread objects

[Antoine Pitrou]

Antoine Pitrou <[EMAIL PROTECTED]> added the comment:

Well, it's true that get_ident() will always give you a reliable number
while currentThread() can play dirty games on you at shutdown. The thing
is the Thread object is dereferenced before the OS thread actually
terminates, so it may be that a Python callback is called by some C code
in those last moments and gets the wrong answer from currentThread()
(because currentThread() returns a new dummy thread when it can't find a
Thread object corresponding to the get_ident() value).

So finally your request sounds quite reasonable :-)

__
Tracker <[EMAIL PROTECTED]>

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

[issue2507] Exception state lives too long in 3.0

[Antoine Pitrou]

Antoine Pitrou <[EMAIL PROTECTED]> added the comment:

Here is a hopefully complete patch using the same approach as before.

However I'm now convinced that another approach would be better in order
to solve both this bug and the various re-raising issues. It would
involve replacing most of the set_exc_info() / reset_exc_info()
mechanism in ceval.c with something different, probably based on
saving/restoring exception state values onto/from the frame stack.
Problem is, I'm not sure I'll have time for it very soon.

Added file: http://bugs.python.org/file10430/better_exc_cleanup.patch

__
Tracker <[EMAIL PROTECTED]>

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

[issue2871] store thread.get_ident() thread identifier inside threading.Thread objects

[Gregory P. Smith]

Gregory P. Smith <[EMAIL PROTECTED]> added the comment:

This seems like a useful addition and is easy enough.

Patch with tests and documentation attached.  Unless I hear objections I
will commit it to trunk later this week.

Patch available for review here:  http://codereview.appspot.com/1301

--
assignee:  -> gregory.p.smith
keywords: +patch
nosy: +gregory.p.smith
priority:  -> normal

__
Tracker <[EMAIL PROTECTED]>

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

[issue2775] Implement PEP 3108

[Brett Cannon]

Changes by Brett Cannon <[EMAIL PROTECTED]>:


--
dependencies:  -Revert SocketServer rename in 2.6

__
Tracker <[EMAIL PROTECTED]>

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

[issue2775] Implement PEP 3108

[Brett Cannon]

Changes by Brett Cannon <[EMAIL PROTECTED]>:


Removed file: http://bugs.python.org/file10267/socketserver_rename.patch

__
Tracker <[EMAIL PROTECTED]>

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

[issue2959] calling GzipFile close() more than once causes exception

[Michael Magin]

New submission from Michael Magin <[EMAIL PROTECTED]>:

Built-in file objects allow repeated calls to .close(), even the
documentation states, "Calling close() more than once is allowed."
(http://docs.python.org/lib/bltin-file-objects.html)

GzipFile does not obey this aspect of the file interface:
>>> import gzip
>>> f = gzip.GzipFile('testfile1.gz', 'ab')
>>> f.close()
>>> f.close()
Traceback (most recent call last):
  File "", line 1, in ?
  File
"/Library/Frameworks/Python.framework/Versions/2.4//lib/python2.4/gzip.py",
line 315, in close
self.fileobj.write(self.compress.flush())
AttributeError: 'NoneType' object has no attribute 'write'

The gzip documentation does not document this (mis-)behavior.

(Trivial) patch against 2.4.3 gzip.py attached.

--
components: Library (Lib)
files: gzip.py.patch
keywords: patch
messages: 67313
nosy: mmagin
severity: normal
status: open
title: calling GzipFile close() more than once causes exception
versions: Python 2.4, Python 2.5
Added file: http://bugs.python.org/file10431/gzip.py.patch

__
Tracker <[EMAIL PROTECTED]>

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

[issue2871] store thread.get_ident() thread identifier inside threading.Thread objects

[Irmen de Jong]

Irmen de Jong <[EMAIL PROTECTED]> added the comment:

Thanks Gregory, for taking the time to make a patch.

__
Tracker <[EMAIL PROTECTED]>

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

[issue2925] Revert Queue rename in 2.6

[Brett Cannon]

Changes by Brett Cannon <[EMAIL PROTECTED]>:


__
Tracker <[EMAIL PROTECTED]>

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

[issue2925] Revert Queue rename in 2.6

[Brett Cannon]

Brett Cannon <[EMAIL PROTECTED]> added the comment:

r63104 moved the stud module from Lib to Lib/lib-old.

r63080 changed some docs and added a test for the rename.

r63077 changed imports.

__
Tracker <[EMAIL PROTECTED]>

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

[issue2925] Revert Queue rename in 2.6

[Brett Cannon]

Brett Cannon <[EMAIL PROTECTED]> added the comment:

After performing a ``svn rename`` on Lib/queue.py to Lib/Queue.py the 
attached patch should revert all other changes related to the rename.

As per usual, I am on OS X so I can't do the case-sensitive rename. If 
someone could do the svn rename, apply the patch, and run regrtest that 
would be appreciated.

--
keywords: +patch
Added file: http://bugs.python.org/file10432/revert_queue.diff

__
Tracker <[EMAIL PROTECTED]>

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

[issue2923] Revert ConfigParser rename in 2.6

[Brett Cannon]

Brett Cannon <[EMAIL PROTECTED]> added the comment:

I have uploaded a patch that when applied after a ``svn rename`` for 
Lib/configparser.py to Lib/ConfigParser.py, should revert the rename. 
Since I am on OS X I can't do the rename myself.

--
keywords: +patch
Added file: http://bugs.python.org/file10433/revert_configparser.diff

__
Tracker <[EMAIL PROTECTED]>

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

[issue2960] bsddb/test/test_replication.py bus error, segfault, assertion error, pass

[Gregory P. Smith]

New submission from Gregory P. Smith <[EMAIL PROTECTED]>:

Using Linux with BerkeleyDB 4.7.25 the bsddb/test/test_replication.py
test is very flaky.  It alternately passes, raises an AssertionError
because of the timeout or gets a segmentation fault or bus error.

(side note: i updated test_replication to not use hard coded port numbers)

I have not tried this test using other BerkeleyDB versions.

--
assignee: jcea
components: Extension Modules
messages: 67318
nosy: gregory.p.smith, jcea
priority: high
severity: normal
status: open
title: bsddb/test/test_replication.py bus error, segfault, assertion error, pass
versions: Python 2.6

__
Tracker <[EMAIL PROTECTED]>

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

[issue2961] Two error messages inconsistent

[Chester]

New submission from Chester <[EMAIL PROTECTED]>:

Hello,

I would like to report that two error messages of the Python parser are
not consistent. Please take a look at this:


>>> a = "hello"

>>> a + 1
Traceback (most recent call last):
  File "", line 1, in 
TypeError: cannot concatenate 'str' and 'int' objects

>>> 1 + a
Traceback (most recent call last):
  File "", line 1, in 
TypeError: unsupported operand type(s) for +: 'int' and 'str'


When the order of the objects is changed, that should only change the
order of the 'str' and 'int' words in the message.

So if a+1, then
TypeError: cannot concatenate 'str' and 'int' objects

and if 1+a, then
TypeError: cannot concatenate 'int' and 'str' objects

--
messages: 67319
nosy: chester
severity: normal
status: open
title: Two error messages inconsistent
versions: Python 3.0

__
Tracker <[EMAIL PROTECTED]>

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

[issue2887] bsddb 4.6.4 needs to be ported to Python 3.0

[Gregory P. Smith]

Gregory P. Smith <[EMAIL PROTECTED]> added the comment:

I believe Jesus wants to do this is such a way that bsddb.h and _bsddb.c
are a single code base with #ifdef's that compiles on 2.x and 3.x at once.

--
assignee:  -> jcea

__
Tracker <[EMAIL PROTECTED]>

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

[issue2961] Two error messages inconsistent

[Chester]

Chester <[EMAIL PROTECTED]> added the comment:

For the case  a + 1  I recommend:
TypeError: can't concatenate 'str' and 'int' objects

And for the case  1 + a  I recommend:
TypeError: can't concatenate 'int' and 'str' objects


Consistency matters!

__
Tracker <[EMAIL PROTECTED]>

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

[issue2962] Goodbye, 'global' statement!

[Chester]

New submission from Chester <[EMAIL PROTECTED]>:

The 'global' statement is used to mark a variable as global. It is
used in functions to allow statements in the function body to rebind
global variables. Using the 'global' statement is generally
considered poor style and should be avoided whenever possible.
Example:

count = 1
def inc():
global count
count = count + 1


Since the use of the 'global' statement is frowned upon, it should be
removed from Python 3.0.

--
components: Interpreter Core
messages: 67322
nosy: chester
severity: normal
status: open
title: Goodbye, 'global' statement!
type: feature request
versions: Python 3.0

__
Tracker <[EMAIL PROTECTED]>

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