[Python-Dev] py3k: accept unicode for 'c' and byte for 'C' in getarg?
Hi,
I realised with the issue #3446 that getarg('c') (get a byte) accepts not only
a byte string of 1 byte, but also an unicode string of 1 character (if the
character code is in [0; 255]). I don't think that it's a good idea to accept
unicode here. Example: b"x".center(5, "\xe9") should be a TypeError.
The "C" format (get a character) has the opposite problem: it accepts both
byte and unicode, whereas byte should be rejected. Example:
mmap.write_byte('é') should be a TypeError.
The problem was already discuss in the email thread "What type of object
mmap.read_byte should return on py3k?" started by Hirokazu Yamamoto related
to issue #5391.
Short history:
- r55109: Guido changes 'c' format to accept unicode (struni branch).
getarg('c') => char accepts byte and character
- r56044: walter.doerwald changes the 'c' format to return an int (an
unicode character) for datetime.datetime.isoformat().
getarg('c') => int accepts byte and character
- r56140: Revert r56044 and creates 'C' format
getarg('c') => char accepts byte and character
getarg('C') => int accepts byte and character
So we have:
- getarg('c') -> one byte (integer in [0; 255])
- getarg('C') -> one character (code in [0; INTMAX])
Note: Why not using Py_UNICODE instead of int?
Usage of "C" format:
datetime.datetime.isoformat(sep)
array.array(type, data): type
Usage of "c" format:
msvcrt.putch(char)
msvcrt.ungetch(char)
.write_byte(char)
--
Victor Stinner aka haypo
http://www.haypocalc.com/blog/
___
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] py3k: accept unicode for 'c' and byte for 'C' in getarg?
Le Tuesday 17 March 2009 13:52:16 Victor Stinner, vous avez écrit :
> I realised with the issue #3446 that getarg('c') (get a byte) accepts not
> only a byte string of 1 byte, but also an unicode string of 1 character (if
> the character code is in [0; 255]). I don't think that it's a good idea to
> accept unicode here. Example: b"x".center(5, "\xe9") should be a TypeError.
>
> The "C" format (get a character) has the opposite problem: it accepts both
> byte and unicode, whereas byte should be rejected. Example:
> mmap.write_byte('é') should be a TypeError.
I opened an issue (with a patch) for my request:
http://bugs.python.org/issue5499
Note: except of the bytes.{center,ljust,rjust} tests, all other tests are ok.
It should not break the standard library, but maybe 3rd party library.
--
Victor Stinner aka haypo
http://www.haypocalc.com/blog/
___
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] What level of detail wanted for import and the language reference?
Steve Holden wrote: > Why not just put a section in both places that says "can't be bothered > to spell this out right now" and put a URL in referring to this thread > on Google ... that appears to have been the traditional approach to > import semantics :) Well, first we point to Guido's original package essay, then to PEP 302, then to PEP 338, then to PEP 366... and then we count the number of people that slogged through all that without needing to take our shoes off :) On a more helpful note, Brett, you may find the write-up I did of the import system a year or two ago helpful: http://svn.python.org/view/sandbox/trunk/userref/ODF/Chapter07_ModulesAndApplications.odt?view=log (some parts are a little dated now obviously, but you may still find it better than starting with a blank page) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ 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 377 - allow __enter__() methods to skip the statement body
Greg Ewing wrote: > Um, no -- it says explicitly right at the very top of > PEP 343 that it's only about factoring out try/finally > statements. > > There's no way that > > try: > code_block > finally: > ... > > can fail to enter the code block if you get as far as > the "try". So it's not reasonable to expect the with > statement to provide this ability. We were working on the PEP for over a year though - expectations changed a bit when the ability to suppress exceptions was added (that wasn't in the original version of the PEP which was when most of the first few sections was written). I agree that try/finally was by far the main use case - it just isn't the only use case or we would never have included the option to suppress exceptions at all. Still, I'm happy to let this rest indefinitely - I doubt the daemonisation use case is going to be enough to change Guido's mind, and it really is rather difficult to come up with practical examples where the current behaviour is a genuine problem. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ 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
[Python-Dev] python-3000 is still mentioned on the mailing lists page
I just noticed that the python-3000 list is still mentioned on http://www.python.org/community/lists/. I searched around a bit but it isn't obvious to me where other than here I should report this, so I'm reporting it here :). -- R. David Murray http://www.bitdance.com ___ 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] python-3000 is still mentioned on the mailing lists page
David> I just noticed that the python-3000 list is still mentioned on David> http://www.python.org/community/lists/. Thanks. I passed your note along to the postmaster(s). Skip ___ 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] py3k: accept unicode for 'c' and byte for 'C' in getarg?
On Tue, Mar 17, 2009 at 5:52 AM, Victor Stinner
wrote:
> I realised with the issue #3446 that getarg('c') (get a byte) accepts not only
> a byte string of 1 byte, but also an unicode string of 1 character (if the
> character code is in [0; 255]). I don't think that it's a good idea to accept
> unicode here. Example: b"x".center(5, "\xe9") should be a TypeError.
Agreed.
> The "C" format (get a character) has the opposite problem: it accepts both
> byte and unicode, whereas byte should be rejected. Example:
> mmap.write_byte('é') should be a TypeError.
YEah, mmap should be defined exclusively in terms of bytes.
> The problem was already discuss in the email thread "What type of object
> mmap.read_byte should return on py3k?" started by Hirokazu Yamamoto related
> to issue #5391.
>
> Short history:
> - r55109: Guido changes 'c' format to accept unicode (struni branch).
> getarg('c') => char accepts byte and character
> - r56044: walter.doerwald changes the 'c' format to return an int (an
> unicode character) for datetime.datetime.isoformat().
> getarg('c') => int accepts byte and character
> - r56140: Revert r56044 and creates 'C' format
> getarg('c') => char accepts byte and character
> getarg('C') => int accepts byte and character
>
> So we have:
> - getarg('c') -> one byte (integer in [0; 255])
> - getarg('C') -> one character (code in [0; INTMAX])
> Note: Why not using Py_UNICODE instead of int?
>
> Usage of "C" format:
> datetime.datetime.isoformat(sep)
> array.array(type, data): type
>
> Usage of "c" format:
> msvcrt.putch(char)
> msvcrt.ungetch(char)
ISTM that putch() and ungetch() are text operations so should use 'C'.
> .write_byte(char)
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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] What level of detail wanted for import and the language reference?
On Tue, Mar 17, 2009 at 06:55, Nick Coghlan wrote: > Steve Holden wrote: > > Why not just put a section in both places that says "can't be bothered > > to spell this out right now" and put a URL in referring to this thread > > on Google ... that appears to have been the traditional approach to > > import semantics :) > > Well, first we point to Guido's original package essay, then to PEP 302, > then to PEP 338, then to PEP 366... and then we count the number of > people that slogged through all that without needing to take our shoes > off :) > The See Also section in importlib probably has the most links of any other module in the stdlib. > > On a more helpful note, Brett, you may find the write-up I did of the > import system a year or two ago helpful: > > http://svn.python.org/view/sandbox/trunk/userref/ODF/Chapter07_ModulesAndApplications.odt?view=log > > (some parts are a little dated now obviously, but you may still find it > better than starting with a blank page) > I'll have a look. -Brett ___ 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] py3k: accept unicode for 'c' and byte for 'C' in getarg?
Le Tuesday 17 March 2009 17:27:39, vous avez écrit :
> > The "C" format (get a character) has the opposite problem: it accepts
> > both byte and unicode, whereas byte should be rejected. Example:
> > mmap.write_byte('é') should be a TypeError.
>
> YEah, mmap should be defined exclusively in terms of bytes.
It's already the fix (only use bytes) choosen for the mmap issue:
http://bugs.python.org/issue5391
(the problem is bigger than mmap.write_byte, other methods have to be changed)
> > Usage of "c" format:
> > msvcrt.putch(char)
> > msvcrt.ungetch(char)
>
> ISTM that putch() and ungetch() are text operations so should use 'C'.
The low level functions use the C type "char":
_putch(char)=>void
_ungetch(char)=>char
For text, we have unicode versions of these functions:
msvcrt.ungetwch(unicode string of 1 character)
msvcrt.putwch(unicode string of 1 character)
So "c" looks to be the right format for putch() and ungetch().
See also http://bugs.python.org/issue5410
--
Victor Stinner aka haypo
http://www.haypocalc.com/blog/
___
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] py3k: accept unicode for 'c' and byte for 'C' in getarg?
On Tue, Mar 17, 2009 at 10:03 AM, Victor Stinner
wrote:
> Le Tuesday 17 March 2009 17:27:39, vous avez écrit :
>> > The "C" format (get a character) has the opposite problem: it accepts
>> > both byte and unicode, whereas byte should be rejected. Example:
>> > mmap.write_byte('é') should be a TypeError.
>>
>> YEah, mmap should be defined exclusively in terms of bytes.
>
> It's already the fix (only use bytes) choosen for the mmap issue:
> http://bugs.python.org/issue5391
> (the problem is bigger than mmap.write_byte, other methods have to be changed)
>
>> > Usage of "c" format:
>> > msvcrt.putch(char)
>> > msvcrt.ungetch(char)
>>
>> ISTM that putch() and ungetch() are text operations so should use 'C'.
>
> The low level functions use the C type "char":
> _putch(char)=>void
> _ungetch(char)=>char
Where did you find these signatures? I looked them up on microsoft.com
and found definitions for _putch() taking an int and _getch()
returning an int.
http://msdn.microsoft.com/en-us/library/azb6c04e.aspx
http://msdn.microsoft.com/en-us/library/078sfkak.aspx
AFAIK the versions without leading underscores are the same.
Also, just because it only takes an ASCII character doesn't mean it's
meant for binary I/O. putch() and getch() are clearly meant for text
I/O.
> For text, we have unicode versions of these functions:
> msvcrt.ungetwch(unicode string of 1 character)
> msvcrt.putwch(unicode string of 1 character)
>
> So "c" looks to be the right format for putch() and ungetch().
>
> See also http://bugs.python.org/issue5410
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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
[Python-Dev] In-place operators
Does anyone think it was not a good idea to put in-place operations in the operator module? For some objects, they don't map() as well as their regular counterparts. Some in-place operations rely on the interpreter to take care of the actual assignment. I've not yet seen good use cases for operator.isub() for example. Raymond ___ 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] In-place operators
2009/3/17 Raymond Hettinger : > Does anyone think it was not a good idea to put in-place operations in the > operator module? For some objects, they don't map() as well as their > regular counterparts. Some in-place operations rely on the interpreter to > take care of the actual assignment. I've not yet seen good use cases for > operator.isub() for example. I thought the point of the operator module (unlike most modules) was to provide a comprehensive set of Python operators as functions for consistency even if there usefulness was questionable. -- Regards, Benjamin ___ 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] In-place operators
On Tue, Mar 17, 2009 at 2:54 PM, Benjamin Peterson wrote: > 2009/3/17 Raymond Hettinger : >> Does anyone think it was not a good idea to put in-place operations in the >> operator module? For some objects, they don't map() as well as their >> regular counterparts. Some in-place operations rely on the interpreter to >> take care of the actual assignment. I've not yet seen good use cases for >> operator.isub() for example. > > I thought the point of the operator module (unlike most modules) was > to provide a comprehensive set of Python operators as functions for > consistency even if there usefulness was questionable. Right. Since Python doesn't have a notation like "operator +" for turning operators into functions, the operator module provides this functionality. Better safe than sorry. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] In-place operators
Right. Since Python doesn't have a notation like "operator +" for turning operators into functions, the operator module provides this functionality. Better safe than sorry. It doesn't really expose this functionality because some of the functionality is buried in ceval.c and is not exposed by operator.isub() for example. I don't see that it offers anything useful that can't be accomplished by calling a magic method directly. I'm sure that consistency/completeness/safe_vs_sorry was the reason they were added. But, if they aren't useful, they never should have been (IMO). It wastes the time of people who try to use them and then find-out that they don't act as expected (the assignment doesn't take place) or that you can't use them with containers s[k] += x etc.) Maybe someone somewhere has some interesting use for these in-place operator function. I hope so. Raymond ___ 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] In-place operators
Raymond Hettinger rcn.com> writes: > > I'm sure that consistency/completeness/safe_vs_sorry > was the reason they were added. But, if they aren't useful, > they never should have been (IMO). It wastes the time of > people who try to use them and then find-out that they don't > act as expected (the assignment doesn't take place) >>> l = [] >>> operator.iadd(l, [5]) [5] >>> l [5] The operation /does/ occur in-place for mutable types. Yes, the semantics are non-obvious for non-mutable types, but that doesn't make it completely useless. ___ 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] In-place operators
> I'm sure that consistency/completeness/safe_vs_sorry was the reason they > were added. But, if they aren't useful, they never should have been > (IMO). Why is that? [you are then giving a reason:] > It wastes the time of people who try to use them and then > find-out that they don't act as expected What people in particular? Certainly, the doc string is wrong: isub(a, b) -- Same as a -= b. That's not quite the same - you would have to write a = isub(a, b) -- Same as a -= b. (right?) However, anybody who understands what isub does already knows that property. I can't imagine users browsing through the operator module and thinking "hmm, what might that isub function do?". > or that you can't use them with containers s[k] += x etc.) Why not? s[k] = iadd(s[k], x) works fine, no? > Maybe someone somewhere has some interesting use for > these in-place operator function. I hope so. It could be important if you want apply it to mutable objects, i.e. where the assignment doesn't do anything. Regards, Martin ___ 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] In-place operators
Maybe someone somewhere has some interesting use for these in-place operator function. I hope so. It could be important if you want apply it to mutable objects, i.e. where the assignment doesn't do anything. I give up. My original question was whether anyone thought these were a good idea. Look's like the answer is yes, everyone is happy with the functions and are glad they were added in 2.5. Raymond ___ 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] In-place operators
> I give up. My original question was whether anyone thought these > were a good idea. Look's like the answer is yes, Correct. > everyone is happy with > the functions and are glad they were added in 2.5. No. I don't really care - I don't use them, nor do I use anything else of the operator module (so I wouldn't miss it if it was removed entirely). I would object to their removal, though, because it would hurt my sense of symmetry. Regards, Martin P.S. If anything was to be removed, I would remove the in-place operations altogether; i.e. a+=b should always be a=a+b. Allowing them to be in-place complicates matters for little added value. ___ 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] In-place operators
[Martin v. Löwis] I would object to their removal, though, because it would hurt my sense of symmetry. I wasn't going to propose removal. If everyone had agreed that the operator in-place functions were problematic, I was going to suggest moving their docs to a second page and documenting their limatations (like we had done long ago with some of the builtins that were no longer essential and had become obsolete). That would leave the main page full of the operator functions that have real utility. But, if we want them to remain first-class citizens, they are probably fine where they are. Raymond ___ 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] In-place operators
Raymond Hettinger wrote: Does anyone think it was not a good idea to put in-place operations in the operator module? For some objects, they don't map() as well as their regular counterparts. Some in-place operations rely on the interpreter to take care of the actual assignment. I've not yet seen good use cases for operator.isub() for example. Given that Python has augmented assignment delimiters, but no 'in-place operators', and that the 'in-place operations' used to partially implemented them cannot be 'in-place' for immutables (and hence are actually aliases for the corresponding 'regular' operations, I agree that they are a bit odd and mostly useless. About the only use case I can think of is something like map(operator.iadd, mutable_seqs, items), where mutable_seqs includes instances of user classes than defind .__iadd__ but not .append ;-) On the other hand, the kitchen-sink policy saves debate. tjr ___ 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
