Re: [Python-Dev] format, int, and IntEnum
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 see format in that area.
How often will one type in `{}.format(some_var)` to find out what type
of object one has? Myself, I would just type `some_var`.
--
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] format, int, and IntEnum
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 Enum type was the pretty
str and repr, I don't see format in that area.
How often will one type in `{}.format(some_var)` to find out what type
of object one has? Myself, I would just type `some_var`.
So, these are some of the ways we have to display an object:
str() calls obj.__str__()
repr() calls obj.__repr__()
%scalls obj.__str__()
%rcalls obj.__repr__()
%dcalls... not sure, but we see the int value
{}.format() should (IMO) also display the value of the object
Using int as the case study, its presentation types are ['b', 'd', 'n',
'o', 'x', 'X']. Notice there is no 's' nor 'r' in there, as int expects
to display a number, not arbitrary text.
So, for mixed-type Enumerations, I think any format calls should simply
be forwarded to the mixed-in type (unless, of course, a custom
__format__ was specified in the new Enumeration).
--
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] hg verify warnings
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 can be safely ignored it seems. A bientôt, Armin. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 446: issue with sockets
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 the UNIX concept everything is file!) 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 socket handles. Anti-virus software and firewalls can stop SetHandleInformation() from working properly on sockets: http://stackoverflow.com/questions/12058911/can-tcp-socket-handles-be-set-not-inheritable -- Richard ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Status of 3.2 in Hg repository?
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 type. 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 adding the v3,2.5 tag to .hgtags. The only active branches remaining would be `default` and 2.7, which is what I expected when I started this ;-) While I would think Georg can object if he wants, I see no reason to help visibly shutter the 3.2 branch by doing null merges. It isn't like it makes using hg harder or the history harder to read. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 446: issue with sockets
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 socket handles. Anti-virus software and firewalls can stop SetHandleInformation() from working properly on sockets: http://stackoverflow.com/questions/12058911/can-tcp-socket-handles-be-set-not-inheritable Yeah, I know, I already added the link to the PEP. I improved the implementation of the PEP 446: it now uses the WSA_FLAG_NO_HANDLE_INHERIT flag when it is available (Windows 7 SP1 and Windows Server 2008 R2 SP1, which is probably a minor percentage of Windows installations). On older Windows versions, I don't see what Python can do to workaround the issue except of calling SetHandleInformation() on the result of WSASocket(). Victor ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 446: issue with sockets
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 by os.get/set_handle_inheritable(), accept socket handles. Anti-virus software and firewalls can stop SetHandleInformation() from working properly on sockets: http://stackoverflow.com/questions/12058911/can-tcp-socket-handles-be-set-not-inheritable Yeah, I know, I already added the link to the PEP. I improved the implementation of the PEP 446: it now uses the WSA_FLAG_NO_HANDLE_INHERIT flag when it is available (Windows 7 SP1 and Windows Server 2008 R2 SP1, which is probably a minor percentage of Windows installations). On older Windows versions, I don't see what Python can do to workaround the issue except of calling SetHandleInformation() on the result of WSASocket(). Victor If the socket methods are not guaranteed to work then they should come with a nice big warning to that effect. It seems that the only reliable way for a parent process to give a socket to a child process is to use WSADuplicateSocket(). (But that requires communication between parent and child after the child has started.) -- Richard ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Status of 3.2 in Hg repository?
[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 adding the v3,2.5 tag to .hgtags. The only active branches remaining would be `default` and 2.7, which is what I expected when I started this ;-) [Brett Cannon] While I would think Georg can object if he wants, I see no reason to help visibly shutter the 3.2 branch by doing null merges. It isn't like it makes using hg harder or the history harder to read. Well, why do we _ever_ do a null merge? Then why don't the reasons apply in this case? What happened here doesn't match the documented workflow - so one or the other should be changed. It has proved tedious to find out why this exception exists, and the only reason I've found so far amounts to the RM didn't want to bother -- and the only record of that is someone's memory of an IRC chat. As mentioned before, if a security hole is found in 3.2 and gets repaired there, the poor soul who fixes 3.2 will have all the same questions when they try to forward-merge the fix to 3.3 and default. Because the merge wasn't done when 3.2.5 was released, they'll have a pile of files show up in their merge attempt that have nothing to do with their fix. Not only the release artifacts, but also a critical fix Antoine applied to ssl.py a week after the 3.2.5 release. It turns out that one was already applied to later branches, but I know that only because Antoine said so here. Do the null merge, and none of those questions will arise. And, indeed, that's _why_ we want to do null merges (when applicable) in general - right? So that future merges become much easier. 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 commands successfully), but that's mighty obscure ;-) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Status of 3.2 in Hg repository?
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? I'd be happy to do that. I'd throw away all the merge changes except for adding the v3,2.5 tag to .hgtags. The only active branches remaining would be `default` and 2.7, which is what I expected when I started this ;-) [Brett Cannon] While I would think Georg can object if he wants, I see no reason to help visibly shutter the 3.2 branch by doing null merges. It isn't like it makes using hg harder or the history harder to read. Well, why do we _ever_ do a null merge? Then why don't the reasons apply in this case? 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. What happened here doesn't match the documented workflow - so one or the other should be changed. It has proved tedious to find out why this exception exists, and the only reason I've found so far amounts to the RM didn't want to bother -- and the only record of that is someone's memory of an IRC chat. As mentioned before, if a security hole is found in 3.2 and gets repaired there, the poor soul who fixes 3.2 will have all the same questions when they try to forward-merge the fix to 3.3 and default. Because the merge wasn't done when 3.2.5 was released, they'll have a pile of files show up in their merge attempt that have nothing to do with their fix. Not only the release artifacts, but also a critical fix Antoine applied to ssl.py a week after the 3.2.5 release. It turns out that one was already applied to later branches, but I know that only because Antoine said so here. Do the null merge, and none of those questions will arise. And, indeed, that's _why_ we want to do null merges (when applicable) in general - right? So that future merges become much easier. 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 commands successfully), but that's mighty obscure ;-) Yes it is. =) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Status of 3.2 in Hg repository?
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 - they can still use v3.2.5 in hg commands successfully), but that's mighty obscure ;-) IIRC Mercurial looks at the union of .hgtags in all unmerged heads to produce the list of existing tags. :-) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Status of 3.2 in Hg repository?
[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 defending what's currently documented - tests my understanding, and lets me annoy people at the same time ;-) 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 commit and then much the same steps to merge 3.3 into default. BTW, null merging this way is annoying, because at least in my installation kdiff3 pops up for every uselessly conflicting file. Anyone know a reason not to do: hg -y merge --tool=internal:fail 3.2 instead? I saw that idea on some Hg wiki. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Status of 3.2 in Hg repository?
[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 commands successfully), but that's mighty obscure ;-) [Éric Araujo] IIRC Mercurial looks at the union of .hgtags in all unmerged heads to produce the list of existing tags. :-) Right! That's the obscure reason why v3.2.5 works even on branches where .hgtags doesn't contain a v3.2.5 entry - but will fail if 3.2 ceases to have a topological head (unless 3.2's .hgtags is merged to a still-active branch). ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Status of 3.2 in Hg repository?
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 I've been inactive for a long time, it's good for me to practice vigorously defending what's currently documented - tests my understanding, and lets me annoy people at the same time ;-) 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 commit You'll need a push here, too. And at that point it may fail. It may be the case that only Georg can push to 3.2, I don't remember for sure. (Note that it may not have been Antoine who did the push of that patch to 3.2...if Georg used transplant, for example, it would show as Antoine's commit, IIUC.) I agree that it would cause less developer mind-overhead if the branch were merged. Georg has been scarce lately...if the branch is locked, there are people besides him who can unlock it (Antoine, for one). --David ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Status of 3.2 in Hg repository?
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. Sorry about that. No problem! Since I've been inactive for a long time, it's good for me to practice vigorously defending what's currently documented - tests my understanding, and lets me annoy people at the same time ;-) 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 commit You'll need a push here, too. And at that point it may fail. It may be the case that only Georg can push to 3.2, I don't remember for sure. Where is the push to 3.2? I only see changes to 3.3 (to be repeated with 3.4). I agree that it would cause less developer mind-overhead if the branch were merged. -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Status of 3.2 in Hg repository?
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 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 defending what's currently documented - tests my understanding, and lets me annoy people at the same time ;-) 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 commit You'll need a push here, too. And at that point it may fail. It may be the case that only Georg can push to 3.2, I don't remember for sure. Where is the push to 3.2? I only see changes to 3.3 (to be repeated with 3.4). Ah, good point. --David ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Status of 3.2 in Hg repository?
[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 commit [R. David Murray] You'll need a push here, too. And at that point it may fail. It may be the case that only Georg can push to 3.2, I don't remember for sure. [Terry Reedy] Where is the push to 3.2? I only see changes to 3.3 (to be repeated with 3.4). Hi, Terry - long time no type :-) Merging 3.2 into 3.3 does make the original 3.2 head a parent of the merge changeset - I don't know whether whatever restrictions are in place would prevent that. I'd sure be _surprised_ if it prevented it, though ;-) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Status of 3.2 in Hg repository?
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 http://mercurial.selenic.com/wiki/TipsAndTricks#Keep_.22My.22_or_.22Their.22_files_when_doing_a_merge. I think it's a perfectly reasonable approach. I expanded on it a little to make it more general (to choose which parent to discard) in http://stackoverflow.com/questions/14984793/mercurial-close-default-branch-and-replace-with-a-named-branch-as-new-default/14991454#14991454 . Tim Delaney ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
