Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!newsfeed.xs4all.nl!newsfeed3.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail Return-Path: X-Original-To: python-list@python.org Delivered-To: python-list@mail.python.org X-Spam-Status: OK 0.010 X-Spam-Evidence: '*H*': 0.98; '*S*': 0.00; 'programmer': 0.03; 'subject:file': 0.07; 'string': 0.09; 'python': 0.11; 'bug': 0.12; 'windows': 0.15; '*with': 0.16; 'buffers,': 0.16; 'former,': 0.16; 'latter,': 0.16; 'overwriting': 0.16; 'subject:String': 0.16; 'windows?': 0.16; 'sat,': 0.16; 'wrote:': 0.18; 'tests': 0.22; 'pointer': 0.24; 'unicode': 0.24; 'fine': 0.24; 'question': 0.24; '>': 0.26; 'right.': 0.26; 'header:In-Reply-To:1': 0.27; 'chris': 0.29; 'am,': 0.29; 'message-id:@mail.gmail.com': 0.30; "i'm": 0.30; 'code': 0.31; 'ctypes': 0.31; 'sep': 0.31; 'supposed': 0.32; 'fri,': 0.33; 'actual': 0.34; 'subject:the': 0.34; "can't": 0.35; 'created': 0.35; 'objects': 0.35; 'but': 0.35; 'received:google.com': 0.35; 'interact': 0.36; 'sequence': 0.36; 'expected': 0.38; 'checks': 0.38; 'to:addr:python-list': 0.38; 'pm,': 0.38; 'does': 0.39; 'bad': 0.39; 'sure': 0.39; 'to:addr:python.org': 0.39; 'either': 0.39; 'how': 0.40; 'skip:u 10': 0.60; 'default': 0.69; 'everywhere.': 0.84; 'reading,': 0.84; '2013,': 0.91; '2013': 0.98 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=nZLhM4KgUe31qeGPbg7S3xyZ0vRPDt6hdXJHo00dh68=; b=pq+oAhm+h0xoslNkCaGx/xIwVB7TXKSo7busS3xvT+y365bYa/GYz4C5v/+D1DAnM5 C5LHlR6bmAJ9dqObJOAVQoL+U8kTDj0GqFTaGWI84Z96xj0unGrptcTW7B6yTwjfS6sq KdhiHB7Se/wyoTOGI1FFEcuPEU0aWaiYcDKElXV0Xj6cHNs0ZZjGqiKM201hn4oZ5abQ ta8PaoVlbB53WnM6dPYAve+A1ae7AtOESonQpQfyth4TWEduwpqTNOA2KzYY1PN8Fsvb 6IkdcGYjGO7ZXB7HEdeaNlXY4libEoaw0FtSqvFNu/164IwefKjR+D5HPndpmyQMGmTL ds+A== MIME-Version: 1.0 X-Received: by 10.66.161.38 with SMTP id xp6mr4891568pab.145.1378753423809; Mon, 09 Sep 2013 12:03:43 -0700 (PDT) In-Reply-To: <1378751676.20097.19809157.789868C5@webmail.messagingengine.com> References: <4ce85ea8-4a4c-46cf-a546-ad999576a5f7@googlegroups.com> <1378486748.10472.18800565.3DE728D7@webmail.messagingengine.com> <1378751676.20097.19809157.789868C5@webmail.messagingengine.com> Date: Mon, 9 Sep 2013 13:03:43 -0600 Subject: Re: Chardet, file, ... and the Flexible String Representation From: Ian Kelly To: Python Content-Type: multipart/alternative; boundary=047d7b6d87b20f276304e5f80ca7 X-BeenThere: python-list@python.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion list for the Python programming language List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Newsgroups: comp.lang.python Message-ID: Lines: 75 NNTP-Posting-Host: 2001:888:2000:d::a6 X-Trace: 1378753433 news.xs4all.nl 15980 [2001:888:2000:d::a6]:33213 X-Complaints-To: abuse@xs4all.nl Xref: csiph.com comp.lang.python:53885 --047d7b6d87b20f276304e5f80ca7 Content-Type: text/plain; charset=ISO-8859-1 On Sep 9, 2013 12:36 PM, wrote: > > On Fri, Sep 6, 2013, at 13:04, Chris Angelico wrote: > > On Sat, Sep 7, 2013 at 2:59 AM, wrote: > > > Incidentally, how does all this interact with ctypes unicode_buffers, > > > which slice as strings and must be UTF-16 on windows? This was fine > > > pre-FSR when unicode objects were UTF-16, but I'm not sure how it would > > > work now. > > > > That would be pre-FSR *with a Narrow build*, which was the default on > > Windows but not everywhere. But I don't know or use ctypes, so an > > answer to your actual question will have to come from someone else. > > I did a couple tests - it works as well as can be expected for reading, > but completely breaks for writing (due to sequence size checks not > matching) Do you mean that it breaks when overwriting Python string object buffers, or when overwriting arbitrary C strings either received from C code or created with create_unicode_buffer? If the former, I think that is to be expected since ctypes ultimately can't know what is the actual type of the pointer it was handed -- much as in C, that's up to the programmer to get right. I also think it's very bad practice to be overwriting those anyway, since Python strings are supposed to be immutable. If the latter, that sounds like a bug in ctypes to me. --047d7b6d87b20f276304e5f80ca7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Sep 9, 2013 12:36 PM, <rando= m832@fastmail.us> wrote:
>
> On Fri, Sep 6, 2013, at 13:04, Chris Angelico wrote:
> > On Sat, Sep 7, 2013 at 2:59 AM, =A0<random832@fastmail.us> wrote:
> > > Incidentally, how does all this interact with ctypes unicode= _buffers,
> > > which slice as strings and must be UTF-16 on windows? This w= as fine
> > > pre-FSR when unicode objects were UTF-16, but I'm not su= re how it would
> > > work now.
> >
> > That would be pre-FSR *with a Narrow build*, which was the defaul= t on
> > Windows but not everywhere. But I don't know or use ctypes, s= o an
> > answer to your actual question will have to come from someone els= e.
>
> I did a couple tests - it works as well as can be expected for reading= ,
> but completely breaks for writing (due to sequence size checks not
> matching)

Do you mean that it breaks when overwriting Python string ob= ject buffers, or when overwriting arbitrary C strings either received from = C code or created with create_unicode_buffer?

If the former, I think that is to be expected since ctypes u= ltimately can't know what is the actual type of the pointer it was hand= ed -- much as in C, that's up to the programmer to get right. I also th= ink it's very bad practice to be overwriting those anyway, since Python= strings are supposed to be immutable.

If the latter, that sounds like a bug in ctypes to me.

--047d7b6d87b20f276304e5f80ca7--