[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
On Mon, Apr 13, 2009 at 12:56 AM, Antoine Pitrou solip...@pitrou.netwrote:
Mart Sõmermaa mrts.pydev at 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
Mart Sõmermaa mrts.pydev at gmail.com writes:
On Mon, Apr 13, 2009 at 12:56 AM, Antoine Pitrou solipsis at pitrou.net
wrote:
Mart Sõmermaa mrts.pydev at gmail.com writes:
Proposal: add add_query_params() for appending query parameters to an URL
to
urllib.parse and urlparse.
Is there
Antoine Pitrou wrote:
Mart Sõmermaa mrts.pydev at gmail.com writes:
On Mon, Apr 13, 2009 at 12:56 AM, Antoine Pitrou solipsis at pitrou.net
wrote:
Mart Sõmermaa mrts.pydev at gmail.com writes:
Proposal: add add_query_params() for appending query parameters to an URL
Michael Foord fuzzyman at 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.
On Mon, Apr 13, 2009 at 5:31 PM, Antoine Pitrou solip...@pitrou.net 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
Hi,
Senthil Kumaran wrote:
On Mon, Apr 13, 2009 at 5:31 PM, Antoine Pitrou solip...@pitrou.net 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
On Apr 11, 2009, at 8:20 AM, Mark Dickinson wrote:
On Fri, Apr 10, 2009 at 2:31 PM, Barry Warsaw ba...@python.org
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
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
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
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
* 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 mar...@v.loewis.dewrote:
* 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
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 you
On Fri, Apr 10, 2009 at 10:06 PM, Martin v. Löwis mar...@v.loewis.dewrote:
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
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
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 you spell the other way?
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 libraries?
On Mon, Apr 13, 2009 at 2:29 AM, Mart Sõmermaa mrts.py...@gmail.com wrote:
On Mon, Apr 13, 2009 at 12:56 AM, Antoine Pitrou solip...@pitrou.net
wrote:
Mart Sõmermaa mrts.pydev at gmail.com writes:
Proposal: add add_query_params() for appending query parameters to an
URL to
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 mar...@v.loewis.dewrote:
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
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
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
On Mon, Apr 13, 2009 at 8:23 PM, Steven Bethard
steven.beth...@gmail.com wrote:
On Mon, Apr 13, 2009 at 2:29 AM, Mart Sõmermaa mrts.py...@gmail.com wrote:
On Mon, Apr 13, 2009 at 12:56 AM, Antoine Pitrou solip...@pitrou.net
wrote:
Mart Sõmermaa mrts.pydev at gmail.com writes:
On Mon, Apr 13, 2009 at 1:02 PM, Martin v. Löwis mar...@v.loewis.de 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 b...@redivi.com 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
On Mon, Apr 13, 2009 at 3:02 PM, Martin v. Löwis mar...@v.loewis.dewrote:
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
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
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
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:
On Mon, Apr 13, 2009 at 5:25 PM, Daniel Stutzbach
dan...@stutzbachenterprises.com wrote:
On Mon, Apr 13, 2009 at 3:02 PM, Martin v. Löwis mar...@v.loewis.de
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
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(arbitrary object) should return
_something_.
--David
R. David Murray wrote:
That doesn't make sense to me. str(arbitrary object) should return
_something_.
Well, it might return something like AddressList
object at 0x123456. But you shouldn't rely on it
to give you anything useful for an arbitrary header.
--
Greg
Bob Ippolito bob at 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
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
2009/4/13 Eric Smith e...@trueblade.com:
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
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
On Mon, Apr 13, 2009 at 1:14 PM, Mart Sõmermaa mrts.py...@gmail.com wrote:
On Mon, Apr 13, 2009 at 8:23 PM, Steven Bethard steven.beth...@gmail.com
wrote:
On Mon, Apr 13, 2009 at 2:29 AM, Mart Sõmermaa mrts.py...@gmail.com wrote:
As for the duplicate handling, I've implemented a threefold
In article 49e3d34e.8040...@trueblade.com,
Eric Smith e...@trueblade.com 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
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
41 matches
Mail list logo
