Re: [Python-Dev] format, int, and IntEnum

2013-08-21 Thread Ethan Furman
On 08/14/2013 09:27 PM, Nick Coghlan wrote: For enums, I believe they should be formatted like their base types (so !s and !r will show the enum name, anything without coercion will show the value) . I agree. While one of the big reasons for an Enum type was the pretty str and repr, I don't

Re: [Python-Dev] format, int, and IntEnum

2013-08-21 Thread Ethan Furman
On 08/20/2013 11:15 PM, Ethan Furman wrote: On 08/14/2013 09:27 PM, Nick Coghlan wrote: For enums, I believe they should be formatted like their base types (so !s and !r will show the enum name, anything without coercion will show the value) . I agree. While one of the big reasons for an

Re: [Python-Dev] hg verify warnings

2013-08-21 Thread Armin Rigo
Hi Tim, On Tue, Aug 20, 2013 at 5:12 PM, Tim Peters tim.pet...@gmail.com wrote: Try running hg verify -v - these warnings only appear when verify is run in verbose mode. Indeed. Ignore what I said then about a broken copy of the repository: any copy will show these three warnings, and they

Re: [Python-Dev] PEP 446: issue with sockets

2013-08-21 Thread Richard Oudkerk
On 21/08/2013 1:19am, Victor Stinner wrote: 2013/8/21 Guido van Rossum gu...@python.org: Also, are you sure the things returned by socket.fleno() are really Windows handles? I thought they were some other artificial namespace used just by sockets. (You know what? I know understand and love

Re: [Python-Dev] Status of 3.2 in Hg repository?

2013-08-21 Thread Brett Cannon
On Tue, Aug 20, 2013 at 8:33 PM, Tim Peters tim.pet...@gmail.com wrote: [Tim, wondering why the 3.2 branch isn't inactive] ... What is gained by _not_ merging here? I don't see it. [Antoine Pitrou] Perhaps Georg doesn't like merges? ;-) I suppose what's gained is one less command to

Re: [Python-Dev] PEP 446: issue with sockets

2013-08-21 Thread Victor Stinner
2013/8/21 Richard Oudkerk shibt...@gmail.com: On 21/08/2013 1:19am, Victor Stinner wrote: I don't know if a socket handle is similar to file handles or if they are specials. At least, GetHandleInformation() and SetHandleInformation() functions, used by os.get/set_handle_inheritable(), accept

Re: [Python-Dev] PEP 446: issue with sockets

2013-08-21 Thread Richard Oudkerk
On 21/08/2013 1:50pm, Victor Stinner wrote: 2013/8/21 Richard Oudkerk shibt...@gmail.com: On 21/08/2013 1:19am, Victor Stinner wrote: I don't know if a socket handle is similar to file handles or if they are specials. At least, GetHandleInformation() and SetHandleInformation() functions, used

Re: [Python-Dev] Status of 3.2 in Hg repository?

2013-08-21 Thread Tim Peters
[Tim, wondering why the 3.2 branch isn't inactive] ... So let's try a different question ;-) Would anyone _object_ to completing the process described in the docs: merge 3.2 into 3.3, then merge 3.3 into default? I'd be happy to do that. I'd throw away all the merge changes except for

Re: [Python-Dev] Status of 3.2 in Hg repository?

2013-08-21 Thread Brett Cannon
On Wed, Aug 21, 2013 at 2:22 PM, Tim Peters tim.pet...@gmail.com wrote: [Tim, wondering why the 3.2 branch isn't inactive] ... So let's try a different question ;-) Would anyone _object_ to completing the process described in the docs: merge 3.2 into 3.3, then merge 3.3 into default?

Re: [Python-Dev] Status of 3.2 in Hg repository?

2013-08-21 Thread Éric Araujo
Le 21/08/2013 14:22, Tim Peters a écrit : BTW, it's not quite a null-merge. The v3.2.5 release tag doesn't currently exist in the 3.3 or default .hgtags files. So long as 3.2 has a topological head, people on the 3.3 and default branches won't notice (unless they look directly at .hgtags -

Re: [Python-Dev] Status of 3.2 in Hg repository?

2013-08-21 Thread Tim Peters
[Brett] ... After reading that sentence I realize there is a key not missing: I see no reason NOT to help visibly shutter the 3.2. branch IOW I say do the null merge. Sorry about that. No problem! Since I've been inactive for a long time, it's good for me to practice vigorously

Re: [Python-Dev] Status of 3.2 in Hg repository?

2013-08-21 Thread Tim Peters
[Tim] BTW, it's not quite a null-merge. The v3.2.5 release tag doesn't currently exist in the 3.3 or default .hgtags files. So long as 3.2 has a topological head, people on the 3.3 and default branches won't notice (unless they look directly at .hgtags - they can still use v3.2.5 in hg

Re: [Python-Dev] Status of 3.2 in Hg repository?

2013-08-21 Thread R. David Murray
On Wed, 21 Aug 2013 14:34:33 -0500, Tim Peters tim.pet...@gmail.com wrote: [Brett] ... After reading that sentence I realize there is a key not missing: I see no reason NOT to help visibly shutter the 3.2. branch IOW I say do the null merge. Sorry about that. No problem! Since

Re: [Python-Dev] Status of 3.2 in Hg repository?

2013-08-21 Thread Terry Reedy
On 8/21/2013 4:52 PM, R. David Murray wrote: On Wed, 21 Aug 2013 14:34:33 -0500, Tim Peters tim.pet...@gmail.com wrote: [Brett] ... After reading that sentence I realize there is a key not missing: I see no reason NOT to help visibly shutter the 3.2. branch IOW I say do the null merge.

Re: [Python-Dev] Status of 3.2 in Hg repository?

2013-08-21 Thread R. David Murray
On Wed, 21 Aug 2013 16:59:36 -0400, Terry Reedy tjre...@udel.edu wrote: On 8/21/2013 4:52 PM, R. David Murray wrote: On Wed, 21 Aug 2013 14:34:33 -0500, Tim Peters tim.pet...@gmail.com wrote: [Brett] ... After reading that sentence I realize there is a key not missing: I see no reason

Re: [Python-Dev] Status of 3.2 in Hg repository?

2013-08-21 Thread Tim Peters
[Tim] ... Here's what I intend to do (unless an objection appears): hg up 3.3 hg merge 3.2 # merge in the v3.2.5 tag definition from .hgtags, # but revert everything else hg revert -a -X .hgtags -r . hg resolve -a -m hg diff # to ensure that only the v3.2.5 tag in .hgtags changed hg

Re: [Python-Dev] Status of 3.2 in Hg repository?

2013-08-21 Thread Tim Delaney
On 22 August 2013 05:34, Tim Peters tim.pet...@gmail.com wrote: Anyone know a reason not to do: hg -y merge --tool=internal:fail 3.2 instead? I saw that idea on some Hg wiki. That would be from