[issue20807] 3.4 cherry pick: 82ec02db7fe6 ec42ab5e0cb3 Windows installer fixes, pip uninstall failure

Martin v. Löwis added the comment: Victor: all correct. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20807 ___ ___ Python-bugs-list mailing

[issue20853] pdb args crashes when an arg is not printable

New submission from Jurjen N.E. Bos: The args command in pdb crashes when an argument cannot be printed. Fortunately, this is easy to fix. For version 3.3.3: In function Pdb.do_args (lib/pdb.py, line 1120) Change line 1131 self.message('%s = %r' % (name, dict[name])) to try: r =

[issue20853] pdb args crashes when an arg is not printable

R. David Murray added the comment: Why is the object not printable? Can you provide a reproducer? Also, the bare except is buggy, it would catch things like KeyboardInterrupt that should not be caught there. 'except Exception' would be appropriate in this case. -- nosy:

[issue14758] SMTPServer of smptd does not support binding to an IPv6 address

Milan Oberkirch added the comment: I was going to work on #3461 where IPv6-tests are missing for smtplib and stumbled over this bug. I would be willing to work on this, since it's quiet clear what needs to be done to me: implement what (vsergeev) suggested and write tests (which includes

[issue19274] make zipfile.PyZipFile more usable

R. David Murray added the comment: For future reference, the update Christian refers to in the previous message is 4f1121ae1cb5. -- nosy: +r.david.murray ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19274

[issue20854] multiprocessing.managers.Server: problem with returning proxy of registered object

New submission from Allis Tauri: 1. I have a tree-like recursive class MyClass. It's method 'get_child(i)' returns an instanse of that same class. 2. I register this class with BaseManager as follows: class MyManager(BaseManager): pass MyManager.register('MyClass', MyClass,

[issue14758] SMTPServer of smptd does not support binding to an IPv6 address

Milan Oberkirch added the comment: The cleaning up of smtpd.socket was already implemented, so there was nothing to do there. What I did: - Write two TestCases to check if the IP version is chosen depending on the host-parameter - Testing, that everything still works with an IPv6 address by

[issue10415] readline.insert_text documentation incomplete

Matheus Portela added the comment: Apparently, the documentation was already changed to reflect the behaviour of startup_hook. Should this issue be closed? -- nosy: +Matheus.Portela ___ Python tracker rep...@bugs.python.org

[issue20799] Turn on all tests in test.test_importlib.source.test_file_loader

Matheus Vieira Portela added the comment: Apparently, the methods with leading underscore are being tested by two classes (SourceLoaderBadBytecodeTest and SourcelessLoaderBadBytecodeTest) that implement methods with similar names (but without the underscore). Simply removing the underscore

[issue10415] readline.insert_text documentation incomplete

Berker Peksag added the comment: Documentations of insert_test and set_startup_hook functions are unchanged since 2007. See revision 9e1529bf0442 (warning, huge diff!). -- nosy: +berker.peksag versions: +Python 3.3, Python 3.4 -Python 3.1, Python 3.2

[issue20799] Turn on all tests in test.test_importlib.source.test_file_loader

Brett Cannon added the comment: Thanks for checking, Matheus! Closing this as invalid then. -- resolution: - invalid status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20799

[issue20854] multiprocessing.managers.Server: problem with returning proxy of registered object

Changes by Ned Deily n...@acm.org: -- nosy: +sbt ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20854 ___ ___ Python-bugs-list mailing list

[issue20283] Wrong keyword parameter name in regex pattern methods

Serhiy Storchaka added the comment: Here is a test. -- Added file: http://bugs.python.org/file34290/test_re_keyword_parameters.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20283 ___

[issue20811] str.format for fixed width float can return a string longer than the maximum specified

Mark Dickinson added the comment: I think you always want the leading zero. Mark (Dickinson), what do yo think? Agreed that we want to keep the leading zero for normal uses. I wouldn't object to some way to opt out of the leading zero, but I'm not sure what that way (w/c)ould be.

[issue13936] datetime.time(0, 0, 0) evaluates to False despite being a valid time

Changes by Chris Rebert pyb...@rebertia.com: -- nosy: +cvrebert ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13936 ___ ___ Python-bugs-list

[issue17911] Extracting tracebacks does too much work

Changes by Eric Snow ericsnowcurren...@gmail.com: -- nosy: +eric.snow ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17911 ___ ___ Python-bugs-list

[issue13936] RFE: change bool(datetime.time(0, 0, 0)) to evaluate as True

Nick Coghlan added the comment: Rewording the issue title and reopening based on the python-ideas thread. The rationale for making this change is that the current behaviour converts a stylistic problem in checking values against a sentinel via bool(value) instead of value is not None into a

[issue13936] RFE: change bool(datetime.time(0, 0, 0)) to evaluate as True

Changes by Donald Stufft don...@stufft.io: -- nosy: +dstufft ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13936 ___ ___ Python-bugs-list mailing

[issue20855] RFE: change bool(0.0) to evaluate as True

New submission from Alexander Belopolsky: The rationale for making this change is that the current behaviour converts a stylistic problem in checking values against a sentinel via bool(value) instead of value is not None into a subtle data driven behavioural bug that only occurs exactly at

[issue20855] RFE: change bool(0.0) to evaluate as True

Donald Stufft added the comment: Being passive aggressive is pointless, if you disagree then discuss on the actual issue or on the mailing list thread. Opening up random issues because you're mad just makes you look like a child. -- nosy: +dstufft resolution: - invalid status: open -

[issue20855] RFE: change bool(0.0) to evaluate as True

Changes by Alexander Belopolsky alexander.belopol...@gmail.com: -- nosy: -belopolsky ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20855 ___ ___

[issue13936] RFE: change bool(datetime.time(0, 0, 0)) to evaluate as True

Changes by Alexander Belopolsky alexander.belopol...@gmail.com: -- nosy: -belopolsky ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13936 ___ ___

[issue20855] RFE: change bool(0.0) to evaluate as True

Changes by Yury Selivanov yselivanov...@gmail.com: -- nosy: +yselivanov ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20855 ___ ___

[issue20855] RFE: change bool(0.0) to evaluate as True

Alexander Belopolsky added the comment: I thought literal copying was enough of a hint to humor without a smiley in the title. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20855 ___

[issue13936] RFE: change bool(datetime.time(0, 0, 0)) to evaluate as True

Changes by Yury Selivanov yselivanov...@gmail.com: -- nosy: +yselivanov ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13936 ___ ___

[issue20855] RFE: change bool(0.0) to evaluate as True

Tim Peters added the comment: Excellent idea! But then we should change bool(0.1) to be False too ;-) -- nosy: +tim.peters ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20855 ___

[issue20855] RFE: change bool(0.0) to evaluate as True

Nick Coghlan added the comment: Alexander, my goal is to flip the default assumption in the time discussion. It is clear from the documentation that the current behaviour is intentional, but there is no concrete *use case* given for it. This is in stark contrast to the other types where

[issue13936] RFE: change bool(datetime.time(0, 0, 0)) to evaluate as True

Nick Coghlan added the comment: Discussion in #20855 made me realise that any deprecation warning should explain how to convert a time object to seconds since midnight. That model of time of day is the most likely origin of the current behaviour, and explicit conversion to that form would be

[issue13936] RFE: change bool(datetime.time(0, 0, 0)) to evaluate as True

Stefan Krah added the comment: I like the current behavior. We have modulo arithmetic here and bool(96%24) is false, too. -- nosy: +skrah ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13936

[issue13936] RFE: change bool(datetime.time(0, 0, 0)) to evaluate as True

Donald Stufft added the comment: It's not modulo arithmetic. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13936 ___ ___ Python-bugs-list

[issue694339] IDLE: Dedenting with Shift+Tab

Changes by Terry J. Reedy tjre...@udel.edu: -- nosy: +terry.reedy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue694339 ___ ___ Python-bugs-list

[issue2704] IDLE: Patch to make PyShell behave more like a Terminal interface

Sean Wolfe added the comment: I just tried this out on osx 10.9.0 and python 2.7.5 : * cursor persisting on the input line works * up/down history works This is much better! A big irritation gone for me and makes things much easier for beginners IMO -- one less thing to get surprised by.

[issue2704] IDLE: Patch to make PyShell behave more like a Terminal interface

Sean Wolfe added the comment: installation steps for me: * apply PyShell.py patch (I had to do some bits manually) * add Terminal.py to idlelib directory * add changes to config-extensions.def as detailed in Terminal.py comments This was in the osx 10.9 system python directories, so there was

[issue13936] RFE: change bool(datetime.time(0, 0, 0)) to evaluate as True

Stefan Krah added the comment: Unix time modulo 86400 gives the number of elapsed seconds in a day and is zero at midnight. Also, modular arithmetic is colloquially called clock arithmetic for a reason. -- ___ Python tracker rep...@bugs.python.org

[issue13936] RFE: change bool(datetime.time(0, 0, 0)) to evaluate as True

Amber Yust added the comment: Yes, but a datetime.time object is definitely not UNIX time. -- nosy: +Amber.Yust ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13936 ___

[issue13936] RFE: change bool(datetime.time(0, 0, 0)) to evaluate as True

Changes by Stefan Krah stefan-use...@bytereef.org: -- nosy: -skrah ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13936 ___ ___ Python-bugs-list

[issue13936] RFE: change bool(datetime.time(0, 0, 0)) to evaluate as True

Alexander Belopolsky added the comment: #20855 was meant as a joke, so I'll keep serious responses here. Nick wrote: Alexander, my goal is to flip the default assumption in the time discussion. It is clear from the documentation that the current behaviour is intentional, but there is no

[issue13936] RFE: change bool(datetime.time(0, 0, 0)) to evaluate as True

Donald Stufft added the comment: I am not even sure what that is supposed to be doing... You're trying to count midnight as the previous day instead of the actual day? That seems extremely contrived. -- ___ Python tracker rep...@bugs.python.org

[issue13936] RFE: change bool(datetime.time(0, 0, 0)) to evaluate as True

Alexander Belopolsky added the comment: Nick wrote: any deprecation warning should explain how to convert a time object to seconds since midnight. I would like to see such an explanation regardless of the outcome here. The best I can think of is timedelta(hours=t.hour, minutes=t.minute,

[issue13936] RFE: change bool(datetime.time(0, 0, 0)) to evaluate as True

Alexander Belopolsky added the comment: You're trying to count midnight as the previous day instead of the actual day? yes That seems extremely contrived Why? Midnight can be considered to be the last moment of the day or the first moment of the day. In ISO standard there are separate

[issue13936] RFE: change bool(datetime.time(0, 0, 0)) to evaluate as True

Donald Stufft added the comment: If Midnight is considered the last moment of the day then it evaluating to false makes even less sense since the rationale given is time is seconds since midnight. However if you're considering it the last moment then time would be seconds since 12:01. So in

[issue13936] RFE: change bool(datetime.time(0, 0, 0)) to evaluate as True

Donald Stufft added the comment: Infact I would argue that ``if dt.time() != datetime.time(0):`` *would* be an improvement to that code because it is more accurately describing what you actually intend in the same way that ``if time_or_none is None`` would be an improvement to that code

[issue13936] RFE: change bool(datetime.time(0, 0, 0)) to evaluate as True

Alexander Belopolsky added the comment: If Midnight is considered the last moment of the day then it evaluating to false makes even less sense since the rationale given is time is seconds since midnight. You are erecting a straw-man. Python clearly considers time(0) to be the first moment

[issue13936] RFE: change bool(datetime.time(0, 0, 0)) to evaluate as True

Alexander Belopolsky added the comment: So in that case your example using midnight as false is even more confusing and even more wrong than not using ``is None`` on the conditional check. I should have added that dt is a datetime instance and therefore dt.time() is None is always false.

[issue20825] containment test for ip_network in ip_network

Eric V. Smith added the comment: There is some history for using in for containment. I'm porting some code from IPy (https://pypi.python.org/pypi/IPy/), and it uses in. It would make my life easier if in worked in ipaddress, but then again it would have to be a previously release version of

[issue15618] turtle.pencolor() chokes on unicode

Roundup Robot added the comment: New changeset 1be39dc4409a by Terry Jan Reedy in branch '2.7': Issue #15618: Make turtle.py itself work when run from a module with http://hg.python.org/cpython/rev/1be39dc4409a -- nosy: +python-dev ___ Python tracker

[issue15618] turtle.pencolor() chokes on unicode

Terry J. Reedy added the comment: I tested by changing a few strings in the demo at the end of the file to unicode. Any problems with os.path.isfile or Tk are different issues. Thanks for the patch. -- resolution: - fixed stage: patch review - committed/rejected status: open -