On Dec 17, 2009, at 11:15 PM, Stefan Behnel wrote:
Greg Ewing, 18.12.2009 02:23:
Robert Bradshaw wrote:
Or will only def func(char*) accept unicode input?
Yep.
In my world that would only accept bytes.
Sounds cleaner to me, too.
Yeah, I can imagine neither of you would ever use that
Greg Ewing, 17.12.2009 00:14:
Will there be a different
handling for function signatures, or will it work the same everywhere? I.e.
will a def func(bytes b) function always accept unicode,
Not under my version of the proposal -- there is only
automatic conversion between unicode and a
On Dec 17, 2009, at 12:20 AM, Stefan Behnel wrote:
Greg Ewing, 17.12.2009 00:14:
Will there be a different
handling for function signatures, or will it work the same
everywhere? I.e.
will a def func(bytes b) function always accept unicode,
Not under my version of the proposal -- there is
On Dec 15, 2009, at 12:06 AM, Stefan Behnel wrote:
Robert Bradshaw, 15.12.2009 00:40:
I don't think users doing input validation are going to stop doing
input validation because of an easier str - char* conversion option.
I'm also skeptical that having to manually do str - byes - char*
Robert Bradshaw wrote:
I actually think unicode - bytes is weirder than unicode - char*
(because the latter is the best C has to offer for strings), though
it's messier from a null-bytes and memory-management perspective.
Another way of thinking about it is that unicode -
bytes is the
Robert Bradshaw wrote:
For example byteso is o would no longer always hold,
If you don't like that idea, then come up with another
syntax for in-line type coercions, like C++ has done.
Or will only def func(char*) accept unicode input?
Yep.
In my world that would only accept bytes.
--
Greg Ewing, 18.12.2009 02:23:
Robert Bradshaw wrote:
Or will only def func(char*) accept unicode input?
Yep.
In my world that would only accept bytes.
Sounds cleaner to me, too.
Stefan
___
Cython-dev mailing list
Cython-dev@codespeak.net
Speaking as a user that is still confused about many implementation
issues...
Greg Ewing wrote:
Suppose we have a way of expressing a type parameterised
with an encoding, maybe something like
encoding[name]
We could have a few predefined ones, such as
ctypedef encoding['ascii']
Christopher Barker wrote:
Robert Bradshaw wrote:
Would
def flump(utf8 s):
return s
return a bytes object?
I would expect it to return a unicode object -- in Python, I'd expect
bytes+encoding to be returned as a unicode object -- it's the only way
not to lose the encoding
Robert Bradshaw, 15.12.2009 00:40:
I don't think users doing input validation are going to stop doing
input validation because of an easier str - char* conversion option.
I'm also skeptical that having to manually do str - byes - char*
encourages input validation. Validation is good.
On Dec 13, 2009, at 3:11 AM, Stefan Behnel wrote:
Robert Bradshaw, 13.12.2009 10:51:
On Dec 12, 2009, at 11:35 PM, Stefan Behnel wrote:
So I think the right solution is to support automatic conversion
*only* at the Python call boundary, i.e. for Python function
parameters and return values.
On Dec 12, 2009, at 4:05 PM, Greg Ewing wrote:
The reason for the intermediate bytes object is that it neatly
solves the memory management issue that arises if you try to
go directly from str to char *, and it does it without having
to make a special case of function arguments.
I agree, that
Lisandro Dalcin wrote:
Just in case, did you mean
ctypedef encoding['ascii'] char* ascii
ctypedef encoding['utf8'] char* utf8
ctypedef encoding['latin1'] char* latin1
No, I didn't.
ctypedef encoding['utf8']utf8
This denotes a
Greg Ewing, 12.12.2009 11:44:
Lisandro Dalcin wrote:
Just in case, did you mean
ctypedef encoding['ascii'] char* ascii
ctypedef encoding['utf8'] char* utf8
ctypedef encoding['latin1'] char* latin1
No, I didn't.
ctypedef encoding['utf8']utf8
On Dec 11, 2009, at 6:02 PM, Greg Ewing wrote:
I've had an idea that might help with making the
encoding and decoding of unicode strings more
automatic.
Suppose we have a way of expressing a type parameterised
with an encoding, maybe something like
encoding[name]
We could have a few
Robert Bradshaw, 12.12.2009 22:49:
Another disadvantage of attaching the encoding to the C signature is
that for many declarations, especially ones that could be widely
shared (printf, fread, ...) or eventually auto-generated (from a C
header file) it doesn't make as much sense to
On Fri, Dec 11, 2009 at 11:02 PM, Greg Ewing
greg.ew...@canterbury.ac.nz wrote:
I've had an idea that might help with making the
encoding and decoding of unicode strings more
automatic.
Suppose we have a way of expressing a type parameterised
with an encoding, maybe something like
Hi Greg,
Greg Ewing, 12.12.2009 03:02:
I've had an idea that might help with making the
encoding and decoding of unicode strings more
automatic.
Suppose we have a way of expressing a type parameterised
with an encoding, maybe something like
encoding[name]
We could have a few
18 matches
Mail list logo
