[Note: I haven't looked thoroughly at our handling yet, so hence I raise the
question.]
This got posted on the Unicode list, does it seem interesting for Python
itself, the UTF-8 to UTF-16 transcoding might be?
http://bjoern.hoehrmann.de/utf-8/decoder/dfa/
--
Jeroen Ruigrok van der Werven / as
On Mon, Apr 13, 2009 at 12:56 AM, Antoine Pitrou wrote:
> Mart Sõmermaa gmail.com> writes:
> >
> > Proposal: add add_query_params() for appending query parameters to an URL
> to
> urllib.parse and urlparse.
>
> Is there anything to /remove/ a query parameter?
I'd say this is outside the scope o
Mart Sõmermaa gmail.com> writes:
>
> On Mon, Apr 13, 2009 at 12:56 AM, Antoine Pitrou pitrou.net>
wrote:
> Mart Sõmermaa gmail.com> writes:
> >
> > Proposal: add add_query_params() for appending query parameters to an URL
to
> urllib.parse and urlparse.
> Is there anything to /remove/ a query p
Antoine Pitrou wrote:
Mart Sõmermaa gmail.com> writes:
On Mon, Apr 13, 2009 at 12:56 AM, Antoine Pitrou pitrou.net>
wrote:
Mart Sõmermaa gmail.com> writes:
Proposal: add add_query_params() for appending query parameters to an URL
to
urllib.parse and urlparse.
Is
Michael Foord voidspace.org.uk> writes:
>
> Weird or not, is there actually a *need* to remove query parameters?
Say you are filtering or sorting data based on some URL parameters. If the user
wants to remove one of those filters, you have to remove the corresponding query
parameter.
Regards
A
On Mon, Apr 13, 2009 at 5:31 PM, Antoine Pitrou wrote:
> Say you are filtering or sorting data based on some URL parameters. If the
> user
> wants to remove one of those filters, you have to remove the corresponding
> query
> parameter.
This is a use-case and possibly a hypothetical one which a
Hi,
Senthil Kumaran wrote:
On Mon, Apr 13, 2009 at 5:31 PM, Antoine Pitrou wrote:
Say you are filtering or sorting data based on some URL parameters. If the user
wants to remove one of those filters, you have to remove the corresponding query
parameter.
This is a use-case and possibly a hypo
On Apr 11, 2009, at 8:20 AM, Mark Dickinson wrote:
On Fri, Apr 10, 2009 at 2:31 PM, Barry Warsaw
wrote:
bugs.python.org is apparently down right now, but I set issue 5724 to
release blocker for 2.6.2. This is waiting for input from Mark
Dickinson,
and it relates to test_cmath failing on S
On Apr 10, 2009, at 11:08 AM, James Y Knight wrote:
Until you write a parser for every header, you simply cannot decode
to unicode. The only sane choices are:
1) raw bytes
2) parsed structured data
The email package does not need a parser for every header, but it
should provide a framework
On Apr 10, 2009, at 2:00 PM, Glenn Linderman wrote:
If one name has to be longer than the other, it should be the bytes
version. Real user code is more likely to want to use the text
version, and hopefully there will be more of that type of code than
implementations using bytes.
Of cours
On Apr 11, 2009, at 8:39 AM, Chris Withers wrote:
Barry Warsaw wrote:
>>> message['Subject']
The raw bytes or the decoded unicode?
A header object.
Yep. You got there before I did. :)
Okay, so you've picked one. Now how do you spell the other way?
str(message['Subject'])
Yes for uns
> * What is the scope of a patch that requires a contributor
> agreement?
Van's advise is as follows:
There is no definite ruling on what constitutes "work" that is
copyright-protected; estimates vary between 10 and 50 lines.
Establishing a rule based on line limits is not supported by
On Mon, Apr 13, 2009 at 4:44 PM, "Martin v. Löwis" wrote:
> > * What is the scope of a patch that requires a contributor
> > agreement?
>
> Van's advise is as follows:
>
> There is no definite ruling on what constitutes "work" that is
> copyright-protected; estimates vary between 10 and
On Mon, 13 Apr 2009 at 10:28, Barry Warsaw wrote:
On Apr 11, 2009, at 8:39 AM, Chris Withers wrote:
Barry Warsaw wrote:
> > > > message['Subject']
> The raw bytes or the decoded unicode?
A header object.
Yep. You got there before I did. :)
+1
> Okay, so you've picked one. Now how do y
On Fri, Apr 10, 2009 at 10:06 PM, "Martin v. Löwis" wrote:
> However, I really think that this question cannot be answered by
> reading the RFC. It should be answered by verifying how people use
> the json library in 2.x.
>
I use the json module in 2.6 to communicate with a C# JSON library and a
C. Titus Brown wrote:
> [...]
> I have had a hard time getting a good sense of what core code is well
> tested and what is not well tested, across various platforms. While
> Walter's C/Python integrated code coverage site is nice, it would be
> even nicer to have a way to generate all that inform
Barry Warsaw writes:
> On Apr 11, 2009, at 8:39 AM, Chris Withers wrote:
>
> > Barry Warsaw wrote:
> >> >>> message['Subject']
> >> The raw bytes or the decoded unicode?
> >
> > A header object.
>
> Yep. You got there before I did. :)
>
> >> Okay, so you've picked one. Now how do yo
> I use the json module in 2.6 to communicate with a C# JSON library and a
> JavaScript JSON library. The C# and JavaScript libraries produce and
> consume the equivalent of str, not the equivalent of bytes.
I assume there is a TCP connection between the json module and the
C#/JavaScript librarie
On Mon, Apr 13, 2009 at 2:29 AM, Mart Sõmermaa wrote:
>
>
> On Mon, Apr 13, 2009 at 12:56 AM, Antoine Pitrou
> wrote:
>>
>> Mart Sõmermaa gmail.com> writes:
>> >
>> > Proposal: add add_query_params() for appending query parameters to an
>> > URL to
>> urllib.parse and urlparse.
>>
>> Is there an
On Tue, 14 Apr 2009 03:15:20 am Stephen J. Turnbull wrote:
> *People* see email as (rich-)text.
We do?
It's not clear what you actually mean by "(rich-)text". In the context
of email, I understand it to mean HTML in the body, web-bugs, security
exploits, 36pt hot-pink bold text on a lime-green
On Mon, Apr 13, 2009 at 12:19 PM, "Martin v. Löwis" wrote:
> > I use the json module in 2.6 to communicate with a C# JSON library and a
> > JavaScript JSON library. The C# and JavaScript libraries produce and
> > consume the equivalent of str, not the equivalent of bytes.
>
> I assume there is a
On Apr 13, 2009, at 10:11 AM, Barry Warsaw wrote:
The email package does not need a parser for every header, but it
should provide a framework that applications (or third party
libraries) can use to extend the built-in header parsers. A bare
minimum for functionality requires a Content-Type
> Yes, there's a TCP connection. Sorry for not making that clear to begin
> with.
>
> If so, it doesn't matter what representation these implementations chose
> to use.
>
>
> True, I can always convert from bytes to str or vise versa.
I think you are missing the point. It will not be n
On Mon, Apr 13, 2009 at 8:23 PM, Steven Bethard
wrote:
>
> On Mon, Apr 13, 2009 at 2:29 AM, Mart Sõmermaa wrote:
> >
> >
> > On Mon, Apr 13, 2009 at 12:56 AM, Antoine Pitrou
> > wrote:
> >>
> >> Mart Sõmermaa gmail.com> writes:
> >> >
> >> > Proposal: add add_query_params() for appending query
On Mon, Apr 13, 2009 at 1:02 PM, "Martin v. Löwis" wrote:
>> Yes, there's a TCP connection. Sorry for not making that clear to begin
>> with.
>>
>> If so, it doesn't matter what representation these implementations chose
>> to use.
>>
>>
>> True, I can always convert from bytes to str or
On Mon, Apr 13, 2009 at 3:28 PM, Bob Ippolito wrote:
> It's not a bug in dumps, it's a matter of not reading the
> documentation. The encoding parameter of dumps decides how byte
> strings should be interpreted, not what the output encoding is.
>
You're right; I apologize for not reading more cl
On Mon, Apr 13, 2009 at 3:02 PM, "Martin v. Löwis" wrote:
> > True, I can always convert from bytes to str or vise versa.
>
> I think you are missing the point. It will not be necessary to convert.
Sometimes I want bytes and sometimes I want str. I am going to be
converting some of the time. ;-
Antoine Pitrou wrote:
Say you are filtering or sorting data based on some URL parameters. If the user
wants to remove one of those filters, you have to remove the corresponding query
parameter.
For an application like that, I would be keeping the
parameters as a list or some other structured w
Barry Warsaw wrote:
The default
would probably be some unstructured parser for headers like Subject.
Only for headers known to be unstructured, I think.
Completely unknown headers should be available only
as bytes.
--
Greg
___
Python-Dev mailing lis
Barry Warsaw wrote:
For an
Originator or Destination address, what does str(header) return?
It should be an error, I think.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
ht
On Mon, Apr 13, 2009 at 5:25 PM, Daniel Stutzbach
wrote:
> On Mon, Apr 13, 2009 at 3:02 PM, "Martin v. Löwis"
> wrote:
>>
>> > True, I can always convert from bytes to str or vise versa.
>>
>> I think you are missing the point. It will not be necessary to convert.
>
> Sometimes I want bytes and s
On Tue, 14 Apr 2009 at 11:28, Greg Ewing wrote:
Barry Warsaw wrote:
For an Originator or Destination address, what does str(header) return?
It should be an error, I think.
That doesn't make sense to me. str() should return
_something_.
--David
___
R. David Murray wrote:
That doesn't make sense to me. str() should return
_something_.
Well, it might return something like "". But you shouldn't rely on it
to give you anything useful for an arbitrary header.
--
Greg
___
Python-Dev mailing list
Py
Bob Ippolito redivi.com> writes:
>
> The output of json/simplejson dumps for Python 2.x is either an ASCII
> bytestring (default) or a unicode string (when ensure_ascii=False).
> This is very practical in 2.x because an ASCII bytestring can be
> treated as either text or bytes in most situations,
Alexandre Vassalotti wrote:
print("Content-Type: application/json; charset=utf-8")
input_object = json.loads(sys.stdin.read())
output_object = do_some_work(input_object)
print(json.dumps(output_object))
print()
That assumes the encoding being used by stdout has
ascii as a subset.
--
Greg
Mark has uploaded our newest work to Rietveld, again at
http://codereview.appspot.com/33084/show. Since the last version, Mark
has added 387 support (and other fixes) and I've added localized
formatting ('n') back in as well as ',' formatting for float and int. I
think this addresses all open i
2009/4/13 Eric Smith :
> Mark has uploaded our newest work to Rietveld, again at
> http://codereview.appspot.com/33084/show. Since the last version, Mark has
> added 387 support (and other fixes) and I've added localized formatting
> ('n') back in as well as ',' formatting for float and int. I thin
Benjamin Peterson wrote:
Cool. Will you use svnmerge.py to integrate the branch? After having
some odd behavior merging the io-c branch, suggest you just apply a
patch to the py3k branch,
We're just going to apply 2 patches, without using svnmerge. First we'll
add new files and the configure c
On Mon, Apr 13, 2009 at 1:14 PM, Mart Sõmermaa wrote:
> On Mon, Apr 13, 2009 at 8:23 PM, Steven Bethard
> wrote:
>> On Mon, Apr 13, 2009 at 2:29 AM, Mart Sõmermaa wrote:
>> > As for the duplicate handling, I've implemented a threefold strategy that
>> > should address all use cases raised befor
In article <49e3d34e.8040...@trueblade.com>,
Eric Smith wrote:
> Before then, if anyone could build and test the py3k-short-float-repr
> branch on any of the following machines, that would be great:
>
[...]
> Something bigendian, like a G4 Mac
I'll crank up some OS X installer builds and run t
> Below is a basic CGI application that assumes that json module works
> with str, not bytes. How would you write it if the json module does not
> support returning a str?
In a CGI application, you shouldn't be using sys.stdin or print().
Instead, you should be using sys.stdin.buffer (or sys.stdi
Warning: Reply-To set to email-sig.
Greg Ewing writes:
> Only for headers known to be unstructured, I think.
> Completely unknown headers should be available only
> as bytes.
Why do I get the feeling that you guys are feeling up an
elephant?
There are four things you might want to do with a
42 matches
Mail list logo
