Re: [Python-Dev] Misc re.match() complaint
On 7/17/2013 12:15 AM, Stephen J. Turnbull wrote: Terry Reedy writes: > On 7/15/2013 10:20 PM, Guido van Rossum wrote: > > >> Or is this something deeper, that a group *is* a new object in > >> principle? > > > > No, I just think of it as returning "a string" > > That is exactly what the doc says it does. See my other post. The problem is that IIUC '"a string"' is intentionally *not* referring to the usual "str or bytes objects" (at least that's one of the standard uses for scare quotes, to indicate an unusual usage). There are no 'scare quotes' in the doc. I put quote marks on things to indicated that I was quoting. I do not know how Guido regarded his marks. > Either the docstring is using "string" in a similarly ambiguous way, or else it's incorrect under the interpretation that buffer objects are *not* "strings", so they should be inadmissible as targets. Saying that input arguments can be "Unicode strings as well as 8-bit strings' (the wording is from 2.x, carried over to 3.x) does not necessary exclude other inputs. CPython is somethimes more more permissive than the doc requires. If the doc said str, bytes, butearray, or memoryview, then other implementations would have to do the same to be conforming. I do not know if that is intended or not. The question is whether CPython should be just as permissive as to the output types of .group(). (And what, if any requirement should be imposed on other implementations.) > Something should be fixed, and I suppose it should be the return type of group(). BTW, I suggest that Terry's usage of "string" (to mean "str or bytes" in 3.x, "unicode or str" in 2.x) be adopted, and Guido's "stringish" This word is an adjective, not a noun. be given expanded meaning, including buffer objects. Then we can say informally that in searching and matching a target is a stringish, the pattern is a stringish (?) or compiled re, but the group method returns a string. Guido's idea to fix (tighten up) the output in 3.4 is fine with me. -- Terry Jan Reedy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Misc re.match() complaint
Terry Reedy writes: > > "stringish" > > This word is an adjective, not a noun. Ah, a strict grammarian. That trumps any cards I could possibly play. ___ Python-Dev mailing list [email protected] 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: Add new parameters to configure the inherance of files and for non-blocking sockets
2013/7/7 Charles-François Natali : > Well, it complicates the signature and implementation. > If we go the same way, why stop there and not expose O_DSYNC, O_SYNC, > O_DIRECT... I added this counter-argument to the PEP. > If you want precise control over the open() sementics, os.open() is > the way to go (that's also the rationale behind io.open() opener > argument, see http://bugs.python.org/issue12105) Right. Victor ___ Python-Dev mailing list [email protected] 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: Add new parameters to configure the inherance of files and for non-blocking sockets
2013/7/7 Cameron Simpson : > On 06Jul2013 14:43, Victor Stinner wrote: > | 2013/7/6 Cameron Simpson : > | > Yes. Please forget I mentioned fork(); it is only relevant if you > | > were offering some facility to undo the addition of cloexec to a > | > Popen passed file descriptor. Which you are not. > | > | Oh... gotcha. I now understood your concern. > | > | There is a little "trick" here: at fork, file descriptors are > | duplicated in the child process and almost all properties (open state, > | flags, offset, etc.) are shared. There is one little exception: file > | attributes are not shared, and there is only one file attribute: > | O_CLOEXEC. Setting O_CLOEXEC in a child process does not affect the > | flag in the parent process ;-) I will add a unit test to check this. > > That's news to me. Interesting. > > I can't find UNIX doco to support this, though I haven't finished > looking. None of the POSIX, Linux or MacOSX fork() manual pages > seem to describe this. > > Can you point me at doco for this? I thought file descriptors were > a direct index into a per-process table of file handle structures, > and did not think the latter got part copies, part shared over a > fork. Sorry, I found this fact my mistake, not in the doc :-) You can verify this behaviour using the follownig script: hg.python.org/peps/file/tip/pep-0466/test_cloexec.py Output on Linux: initial state: fd=3, cloexec=False child process after fork, set cloexec: cloexec=True child process after exec: fd=3, cloexec= parent process after fork: cloexec=False parent process after exec: fd=3, cloexec=False "parent process after fork: cloexec=False" means that the flag was not modified in the parent process. > Also, is O_CLOEXEC really the only file attribute? So O_NONBLOCK > is a flag and not an attribute (guessing the terminology distinguishes > these)? Now you mention it, ISTR noticing that there were distinct > ioctls to adjust flags and something else. See the manual page: http://linux.die.net/man/2/fcntl There are "File descriptor flags " and "File status flags", it looks like they are inherited/shared differently between the parent and the child process. > Your change says: > > On Windows, the close-on-exec flag is ``HANDLE_FLAG_INHERIT``. > > I feel it would be clearer to say: > > On Windows, the close-on-exec flag is the inverse of > ``HANDLE_FLAG_INHERIT``. Ok, fixed in the PEP. Victor ___ Python-Dev mailing list [email protected] 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: Add new parameters to configure the inherance of files and for non-blocking sockets
2013/7/13 Cameron Simpson : > This sentence: > > The flag is cleared in the child process before executing the > program, the change does not change the flag in the parent process. > > needs a semicolon, not a comma. Fixed. Victor ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] String terminology [was Re: Misc re.match() complaint]
On 17/07/13 19:05, Terry Reedy wrote: Saying that input arguments can be "Unicode strings as well as 8-bit strings' (the wording is from 2.x, carried over to 3.x) does not necessary exclude other inputs. "8-bit strings" seems somewhat ambiguous to me. In UTF-8, many Unicode strings are 8-bit, as they can be with Python 3.3's flexible string format. I prefer to stick to Unicode or text string, versus byte string. Pedants who point out that "byte" does not necessarily mean 8-bits, and therefore we should talk about octets, will be slapped with a large halibut :-) -- Steven ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Misc re.match() complaint
16.07.13 20:21, Guido van Rossum написав(ла):
The situation is most egregious if the target string is a bytearray,
where there is currently no way to get the result as an immutable
bytes object without an extra copy. (There's no API that lets you
create a bytes object directly from a slice of a bytearray.)
m = memoryview(data)
if m:
return m.cast('B')[low:high].tobytes()
else:
# cast() doesn't work for empty memoryview
return b''
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Tweaking PEP 8 guidelines for use of leading underscores
On Tue, Jul 16, 2013 at 9:07 PM, Barry Warsaw wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On Jul 16, 2013, at 07:34 PM, Tres Seaver wrote: > > >On 07/16/2013 07:09 AM, Nick Coghlan wrote: > > > >> I did find it interesting that we *don't* explicitly advise against > >> the use of "import *" for anything other than optional accelerator > >> modules or republishing internal interfaces through a public API, > >> even though we advice against the practice in the tutorial. Perhaps > >> another oversight worth correcting? > > > >+1. 'from foo import *' (from any source other than another module in > >the same package) is a code stench far worse than anything else PEP8 > >proscribes. > > Maybe we should disable it for anything that isn't at the interactive > prompt > <0.5 wink>. > Or how about dropping the whole ``from ... import ...`` format entirely? <0.5 wink; seriously, it's implementation is a pain and it has wonky semantics> ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Tweaking PEP 8 guidelines for use of leading underscores
On Jul 17, 2013, at 09:35 AM, Brett Cannon wrote: >Or how about dropping the whole ``from ... import ...`` format entirely? ><0.5 wink; seriously, it's implementation is a pain and it has wonky >semantics> Yes, let's break *everything* :) -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Misc re.match() complaint
On 17/07/2013 05:15, Stephen J. Turnbull wrote: Terry Reedy writes: > On 7/15/2013 10:20 PM, Guido van Rossum wrote: > > >> Or is this something deeper, that a group *is* a new object in > >> principle? > > > > No, I just think of it as returning "a string" > > That is exactly what the doc says it does. See my other post. The problem is that IIUC '"a string"' is intentionally *not* referring to the usual "str or bytes objects" (at least that's one of the standard uses for scare quotes, to indicate an unusual usage). Either the docstring is using "string" in a similarly ambiguous way, or else it's incorrect under the interpretation that buffer objects are *not* "strings", so they should be inadmissible as targets. Something should be fixed, and I suppose it should be the return type of group(). BTW, I suggest that Terry's usage of "string" (to mean "str or bytes" in 3.x, "unicode or str" in 2.x) be adopted, and Guido's "stringish" be given expanded meaning, including buffer objects. Then we can say informally that in searching and matching a target is a stringish, the pattern is a stringish (?) or compiled re, but the group method returns a string. Instead of "stringish", how about "stringoid"? To me, "stringish" is an adjective, but "stringoid" can be a noun or an adjective. According to http://dictionary.reference.com: """ -oid —suffix forming adjectives, —suffix forming nouns indicating likeness, resemblance, or similarity: anthropoid """ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] String terminology [was Re: Misc re.match() complaint]
When precision is needed I say things like 'a str object' or 'a bytes object'. There is no shame in a bit of verbosity around such issues, especially in the reference docs (tutorials are a different issue). On Wed, Jul 17, 2013 at 4:50 AM, Steven D'Aprano wrote: > On 17/07/13 19:05, Terry Reedy wrote: > >> Saying that input arguments can be "Unicode strings as well as 8-bit >> strings' (the wording is from 2.x, carried over to 3.x) does not necessary >> exclude other inputs. > > > "8-bit strings" seems somewhat ambiguous to me. In UTF-8, many Unicode > strings are 8-bit, as they can be with Python 3.3's flexible string format. > I prefer to stick to Unicode or text string, versus byte string. > > Pedants who point out that "byte" does not necessarily mean 8-bits, and > therefore we should talk about octets, will be slapped with a large halibut > :-) > > > -- > Steven > > > > > > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Tweaking PEP 8 guidelines for use of leading underscores
On Tue, 16 Jul 2013 17:46:34 -0400, Terry Reedy wrote: > On 7/16/2013 9:39 AM, R. David Murray wrote: > > On Tue, 16 Jul 2013 23:19:21 +1000, Steven D'Aprano > > wrote: > > >> For example, pkgutil includes classes with single-underscore methods, > >> which I take as private. It also has a function simplegeneric, which is > >> undocumented and not listed in __all__. In in the absence of even a > >> comment saying "Don't use this", I take it as an oversight, not policy > >> that simplegeneric is private. > > > > I think you'd be wrong about that, though. simplegeneric should really be > > treated as private. I'm speaking here not about the general principle of > > the thing, but about my understanding of simplegeneric's specific history. > > I think Steven (valid) point is "Why not, then, say it is internal > either in docs or name?"-- which in this case would be in the docs. I don't think that's what he was saying; but yes, we should do that :) --David ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Tweaking PEP 8 guidelines for use of leading underscores
https://pypi.python.org/pypi/apipkg provides a much more effective way to denote API than an _ On Wed, Jul 17, 2013 at 12:20 PM, R. David Murray wrote: > On Tue, 16 Jul 2013 17:46:34 -0400, Terry Reedy wrote: >> On 7/16/2013 9:39 AM, R. David Murray wrote: >> > On Tue, 16 Jul 2013 23:19:21 +1000, Steven D'Aprano >> > wrote: >> >> >> For example, pkgutil includes classes with single-underscore methods, >> >> which I take as private. It also has a function simplegeneric, which is >> >> undocumented and not listed in __all__. In in the absence of even a >> >> comment saying "Don't use this", I take it as an oversight, not policy >> >> that simplegeneric is private. >> > >> > I think you'd be wrong about that, though. simplegeneric should really be >> > treated as private. I'm speaking here not about the general principle of >> > the thing, but about my understanding of simplegeneric's specific history. >> >> I think Steven (valid) point is "Why not, then, say it is internal >> either in docs or name?"-- which in this case would be in the docs. > > I don't think that's what he was saying; but yes, we should do that :) > > --David > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/dholth%40gmail.com ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
