Hey,
Can I get a review for GH-1690[1]? It fixes bpo-12978 and
has been sitting for a handful of years now. This adds
support for os.*xattr on DragonflyBSD, FreeBSD and NetBSD.
Thanks!
[1] https://github.com/python/cpython/pull/1690
___
Python-Dev mail
On 4 September 2016 at 20:57, Christian Heimes wrote:
> On 2016-09-01 23:15, Victor Stinner wrote:
>> 2016-08-31 22:31 GMT+02:00 Christian Heimes :
>>> https://bugs.python.org/issue27744
>>> Add AF_ALG (Linux Kernel crypto) to socket module
>>
>> This patch adds a new socket.sendmsg_afalg() method
On 2016-09-01 23:15, Victor Stinner wrote:
> 2016-08-31 22:31 GMT+02:00 Christian Heimes :
>> https://bugs.python.org/issue27744
>> Add AF_ALG (Linux Kernel crypto) to socket module
>
> This patch adds a new socket.sendmsg_afalg() method on Linux.
>
> "afalg" comes from AF_ALG which means "Addres
2016-08-31 22:31 GMT+02:00 Christian Heimes :
> https://bugs.python.org/issue27744
> Add AF_ALG (Linux Kernel crypto) to socket module
This patch adds a new socket.sendmsg_afalg() method on Linux.
"afalg" comes from AF_ALG which means "Address Family Algorithm". It's
documented as "af_alg: User-s
On 2016-08-31 22:31, Christian Heimes wrote:
> Hi,
>
> I have 7 patches for 3.6 ready for merging. The new features were
> discussed on Security-SIG and reviewed by Victor or GPS. The patches
> just need one final review and an ACK. The first three patches should
> land in 2.7, 3.4 and 3.5, too.
>
Hi,
I have 7 patches for 3.6 ready for merging. The new features were
discussed on Security-SIG and reviewed by Victor or GPS. The patches
just need one final review and an ACK. The first three patches should
land in 2.7, 3.4 and 3.5, too.
http://bugs.python.org/issue26470
Make OpenSSL module com
If there is anyone here with an interest in web-spiders,
it would be nice if someone else could take a look at
http://bugs.python.org/issue21469
which addresses the risk of false positives with the robots.txt parser.
Raymond
___
Python-Dev maili
Sent from my Windows Phone___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/11/2014 08:04 AM, Matěj Cepl wrote:
> On 2014-02-11, 12:27 GMT, you wrote:
>>> This is my first attempt to contribute to Python itself, so
>>> please be gentle with me. Yes, I know that I miss unit tests
>>> and port to other branches of Python
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2014-02-11, 12:27 GMT, you wrote:
>> This is my first attempt to contribute to Python itself, so
>> please be gentle with me. Yes, I know that I miss unit tests
>> and port to other branches of Python (this is against 2.7),
>> but I would like fi
On 2/11/2014 6:03 AM, Matěj Cepl wrote:
Suggested fix for bug# 19494
This is my first attempt to contribute to Python itself, so please be
gentle with me. Yes, I know that I miss unit tests and port to other
branches of Python (this is against 2.7), but I would like first some
feedback to see w
Many websites (e.g. GitHub API) on the Internet are intentionally not
following RFC with regards to the Basic Authorization and require
Authorization header in the initial request and they never return 401
error. Therefore it is not possible to authorize with such websites just
using urllib2.py HTT
patch
Description: Binary data
___
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
On Sat, Dec 10, 2011 at 13:15, Ben Finney wrote:
> Guido van Rossum writes:
>
>> On Fri, Dec 9, 2011 at 12:26 PM, Cedric Sodhi wrote:
>>
>> > IF YOU THINK YOU MUST REPLY SOMETHING WITTY, ITERATE THAT THIS HAD
>> > BEEN DISCUSSED BEFORE, REPLY THAT "IT'S SIMPLY NOT GO'NNA HAPPEN",
>> > THAT "WHO
On 2011-12-10, at 12:14 , francis wrote:
>
> (I thing that 'go' has some
> autoformater or a standard way of formatting).
`gofmt` yes, it simply reformats all the code to match the style
decided by the core go team, it does not provide support formatting-
independent edition.
Think of it as pep8.
10.12.11 13:14, francis написав(ла):
Formatting is like food, everyone has it's own taste. One has
to use spicery to change it (if possible). For me the view of
the code (the layout) by the programmer should be automatically
changed by the tool that reads the code. Here you could have
a python wi
Hi Cedric,
On 12/09/2011 09:26 PM, Cedric Sodhi wrote:
It is widely known among the programmer's community that spaces and tabs
are remarkably similar to eachother. So similar even, that people fight
wars about which to use in a non-py context. It might strike one as an
equally remarkably nonsen
On Sat, Dec 10, 2011 at 4:15 AM, Ben Finney wrote:
> Guido van Rossum writes:
>
> > On Fri, Dec 9, 2011 at 12:26 PM, Cedric Sodhi wrote:
> >
> > > IF YOU THINK YOU MUST REPLY SOMETHING WITTY, ITERATE THAT THIS HAD
> > > BEEN DISCUSSED BEFORE, REPLY THAT "IT'S SIMPLY NOT GO'NNA HAPPEN",
> > > THA
Guido van Rossum writes:
> On Fri, Dec 9, 2011 at 12:26 PM, Cedric Sodhi wrote:
>
> > IF YOU THINK YOU MUST REPLY SOMETHING WITTY, ITERATE THAT THIS HAD
> > BEEN DISCUSSED BEFORE, REPLY THAT "IT'S SIMPLY NOT GO'NNA HAPPEN",
> > THAT "WHO DOESN'T LIKE IT IS FREE TO CHOOSE ANOTHER LANGUAGE" OR
> >
Ditch the colon too. Also you're a troll.
On Dec 10, 2011 9:58 AM, "Cedric Sodhi" wrote:
> I reply to your contribution mainly because I see another, valid
> argument hidden in what you formulated as an opinion:
>
> Readability would be reduced by such "noise". To anticipate other people
> agreei
Guido van Rossum wrote:
Point of order (repeated), please move this thread to python-ideas.
Isn't that cruel to the people reading python-ideas?
--
Steven
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/pyt
Point of order (repeated), please move this thread to python-ideas.
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailma
I reply to your contribution mainly because I see another, valid
argument hidden in what you formulated as an opinion:
Readability would be reduced by such "noise". To anticipate other people
agreeing with that, let me say, that it would be exactly one more
character, and the same amount of key pr
If braces were introduced I would switch to Haskell, I can't stand the
noise. If you want to see a language that allows both whitespace, semi
colons and braces take a look at it. Nails it.
On Dec 10, 2011 9:31 AM, "Cedric Sodhi" wrote:
> On Fri, Dec 09, 2011 at 02:21:42PM -0800, Guido van Rossum
On Fri, Dec 09, 2011 at 02:21:42PM -0800, Guido van Rossum wrote:
>On Fri, Dec 9, 2011 at 12:26 PM, Cedric Sodhi <[1]man...@gmx.net> wrote:
>
> IF YOU THINK YOU MUST REPLY SOMETHING WITTY, ITERATE THAT THIS HAD BEEN
> DISCUSSED BEFORE, REPLY THAT "IT'S SIMPLY NOT GO'NNA HAPPEN", THAT
On Fri, Dec 9, 2011 at 12:26 PM, Cedric Sodhi wrote:
> IF YOU THINK YOU MUST REPLY SOMETHING WITTY, ITERATE THAT THIS HAD BEEN
> DISCUSSED BEFORE, REPLY THAT "IT'S SIMPLY NOT GO'NNA HAPPEN", THAT "WHO
> DOESN'T LIKE IT IS FREE TO CHOOSE ANOTHER LANGUAGE" OR SOMETHING
> SIMILAR, JUST DON'T.
>
Eve
You've really only given one reason why braces are a good idea:
"I also appreciate single lined conditional or loops once in a while."
Not only is this argument even weaker than the two you yourself gave in
defense of whitespace, these two features are already supported in Python.
If you're not a
I don't always post to python-dev, but when I do I ask for braces.
On Friday, December 9, 2011 at 4:43 PM, Antoine Pitrou wrote:
>
> Dear Cedric,
>
> I'm guessing you drank too much (perhaps you are training for New Year's
> Eve), ate some bad sausages or are simply very self-complacent.
> py
This belongs on python-ideas. Please take it there.
~Ethan~
___
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
Dear Cedric,
I'm guessing you drank too much (perhaps you are training for New Year's
Eve), ate some bad sausages or are simply very self-complacent.
python-dev is not the place where to post long unstructured ramblings
with no practical value. Consider writing on your personal blog
instead.
Tha
On Fri, Dec 09, 2011 at 01:11:29PM -0800, Mike Meyer wrote:
> On Fri, 9 Dec 2011 21:26:29 +0100
> Cedric Sodhi wrote:
> > Readable code, is it really an advantage?
> > Of course it is.
>
> Ok, you got that right.
Thank you. It doesn't go unnoticed that you learned your Feedback Rules.
>
> > For
On Fri, 9 Dec 2011 21:26:29 +0100
Cedric Sodhi wrote:
> Readable code, is it really an advantage?
> Of course it is.
Ok, you got that right.
> Forcing the programmer to write readable code, is that an advantage?
> No suspense, the answer is Of course not.
This is *not* an "Of course". Readable
Cedric Sodhi writes:
> IF YOU THINK YOU MUST REPLY SOMETHING WITTY, ITERATE THAT THIS HAD BEEN
> DISCUSSED BEFORE, REPLY THAT "IT'S SIMPLY NOT GO'NNA HAPPEN", THAT "WHO
> DOESN'T LIKE IT IS FREE TO CHOOSE ANOTHER LANGUAGE" OR SOMETHING
> SIMILAR, JUST DON'T.
If you're going to post a long screed
On 2011-12-09, at 21:26 , Cedric Sodhi wrote:
> IF YOU THINK YOU MUST REPLY SOMETHING WITTY, ITERATE THAT THIS HAD BEEN
> DISCUSSED BEFORE, REPLY THAT "IT'S SIMPLY NOT GO'NNA HAPPEN", THAT "WHO
> DOESN'T LIKE IT IS FREE TO CHOOSE ANOTHER LANGUAGE" OR SOMETHING
> SIMILAR, JUST DON'T.
>
> Otherwise,
On Friday, December 9, 2011 at 3:26 PM, Cedric Sodhi wrote:
> IF YOU THINK YOU MUST REPLY SOMETHING WITTY, ITERATE THAT THIS HAD BEEN
> DISCUSSED BEFORE, REPLY THAT "IT'S SIMPLY NOT GO'NNA HAPPEN", THAT "WHO
> DOESN'T LIKE IT IS FREE TO CHOOSE ANOTHER LANGUAGE" OR SOMETHING
> SIMILAR, JUST DON'T
On Fri, Dec 9, 2011 at 14:26, Cedric Sodhi wrote:
> IF YOU THINK YOU MUST REPLY SOMETHING WITTY, ITERATE THAT THIS HAD BEEN
> DISCUSSED BEFORE, REPLY THAT "IT'S SIMPLY NOT GO'NNA HAPPEN", THAT "WHO
> DOESN'T LIKE IT IS FREE TO CHOOSE ANOTHER LANGUAGE" OR SOMETHING
> SIMILAR, JUST DON'T.
>
> Otherw
IF YOU THINK YOU MUST REPLY SOMETHING WITTY, ITERATE THAT THIS HAD BEEN
DISCUSSED BEFORE, REPLY THAT "IT'S SIMPLY NOT GO'NNA HAPPEN", THAT "WHO
DOESN'T LIKE IT IS FREE TO CHOOSE ANOTHER LANGUAGE" OR SOMETHING
SIMILAR, JUST DON'T.
Otherwise, read on.
I know very well that this topic has been discu
Hi,
> I recently got some patches accepted for inclusion in 3.3, and each time,
> the patch metadata (such as my name and my commit comment) were stripped by
> applying the patch manually, instead of hg importing it. This makes it
> clear in the history who eventually reviewed and applied the p
In article
,
Dirkjan Ochtman wrote:
> On Sat, Nov 19, 2011 at 20:41, Petri Lehtinen wrote:
> >> Generally speaking, it's more useful for the checkin metadata to
> >> reflect who actually did the checkin, since that's the most useful
> >> information for the tracker and buildbot integration.
> >
On Sat, Nov 19, 2011 at 20:41, Petri Lehtinen wrote:
>> Generally speaking, it's more useful for the checkin metadata to
>> reflect who actually did the checkin, since that's the most useful
>> information for the tracker and buildbot integration.
>
> At least in git, the commit metadata contains
Nick Coghlan wrote:
> Generally speaking, it's more useful for the checkin metadata to
> reflect who actually did the checkin, since that's the most useful
> information for the tracker and buildbot integration.
At least in git, the commit metadata contains both author and
committer (at least if t
On Sat, Nov 19, 2011 at 2:52 AM, Nick Coghlan wrote:
> On Sat, Nov 19, 2011 at 6:42 PM, Stefan Behnel wrote:
>> Hi,
>>
>> I recently got some patches accepted for inclusion in 3.3, and each time,
>> the patch metadata (such as my name and my commit comment) were stripped by
>> applying the patch
On Sat, Nov 19, 2011 at 6:42 PM, Stefan Behnel wrote:
> Hi,
>
> I recently got some patches accepted for inclusion in 3.3, and each time,
> the patch metadata (such as my name and my commit comment) were stripped by
> applying the patch manually, instead of hg importing it. This makes it clear
> i
On Sat, 19 Nov 2011 09:42:49 +0100
Stefan Behnel wrote:
>
> I didn't see this mentioned in the dev-guide. Is it being considered the
> Right Way To Do It?
That said, to answer your question more generally, I think it's simply
how we worked with SVN, and we haven't found any compelling reason to
On Sat, 19 Nov 2011 09:42:49 +0100
Stefan Behnel wrote:
> Hi,
>
> I recently got some patches accepted for inclusion in 3.3, and each time,
> the patch metadata (such as my name and my commit comment) were stripped by
> applying the patch manually, instead of hg importing it. This makes it
> c
Hi,
I recently got some patches accepted for inclusion in 3.3, and each time,
the patch metadata (such as my name and my commit comment) were stripped by
applying the patch manually, instead of hg importing it. This makes it
clear in the history who eventually reviewed and applied the patch, b
the py3k debug build has been broken in Cython's integration tests for a
couple of weeks now due to a use-after-decref bug. Here's the fix,
please apply.
Oops, I introduced this bug when I added "check_content" option to
_PyUnicode_CheckUnicode().
BTW, is there a reason unicode_subtype_new()
Hi,
the py3k debug build has been broken in Cython's integration tests for a
couple of weeks now due to a use-after-decref bug. Here's the fix, please
apply.
BTW, is there a reason unicode_subtype_new() copies the buffer of the
unicode object it just created, instead of just stealing it?
S
On Oct 20, 2010, at 05:50 PM, Michael Foord wrote:
>Wow, that's very interesting. Whilst a lot of people on this list will have
>an interest in knowing about this it still isn't the right list for
>discussing it. The python-porting list *is* an entirely appropriate list and
>it would be great to s
On 20/10/2010 17:43, David Malcolm wrote:
(my apologies, if necessary, for top-posting)
FWIW Neal asked about this on Fedora's development mailing list as well:
http://lists.fedoraproject.org/pipermail/devel/2010-October/144535.html
If I'm reading:
http://pypi.python.org/pypi/fpconst/
corre
(my apologies, if necessary, for top-posting)
FWIW Neal asked about this on Fedora's development mailing list as well:
http://lists.fedoraproject.org/pipermail/devel/2010-October/144535.html
If I'm reading:
http://pypi.python.org/pypi/fpconst/
correctly, that project hasn't had an upstream upda
fpconst developers?
2010/10/19 Neal Becker :
> Where should I send this patch?
>
> diff -u fpconst-0.7.2/fpconst.py fpconst-0.7.2.new/fpconst.py
> --- fpconst-0.7.2/fpconst.py 2005-02-24 12:42:03.0 -0500
> +++ fpconst-0.7.2.new/fpconst.py 2010-10-19 20:55:07.407765664 -0400
> @@
Where should I send this patch?
diff -u fpconst-0.7.2/fpconst.py fpconst-0.7.2.new/fpconst.py
--- fpconst-0.7.2/fpconst.py2005-02-24 12:42:03.0 -0500
+++ fpconst-0.7.2.new/fpconst.py2010-10-19 20:55:07.407765664 -0400
@@ -40,18 +40,18 @@
ident = "$Id: fpconst.py,v 1.16 2005/02
Steven D'Aprano writes:
> I don't think anyone has ever suggested change for change's sake. If
> they have, I'd love to read the PEP for it.
Not to mention the BDFL's pronouncement message!
___
Python-Dev mailing list
Python-Dev@python.org
http://mai
On Wed, 13 Oct 2010 03:01:57 am l...@rmi.net wrote:
> So my point is just this: Change for change's sake is truly not
> what most Python users want. If Python core developers want 3.X
> to become as popular as 2.X, they should be less concerned with
> posts on this list or hands at a conference, t
rmi.net/~lutz)
> Date: Fri, 8 Oct 2010 14:20:32 -0400
> From: Barry Warsaw
> To: python-dev@python.org
> Subject: Re: [Python-Dev] Patch making the current email package (mostly)
> support bytes
>
> On Oct 08, 2010, at 03:44 PM, l...@rmi.net wrote:
>
> >Ultimately,
Barry Warsaw writes:
> On Oct 09, 2010, at 02:48 AM, Stephen J. Turnbull wrote:
>
> >Right. That's where I was going with my comment to Barry about the
> >Received headers. Even if email isn't going to serve clients working
> >with wire format, it needs to deal with those headers. But wher
On Sat, 09 Oct 2010 02:48:23 +0900, "Stephen J. Turnbull"
wrote:
> R. David Murray writes:
> > On Sat, 09 Oct 2010 01:06:29 +0900, "Stephen J. Turnbull"
> wrote:
> > > That mess is entirely unnecessary in Python 3. Text and wire format
> > > can be easily distinguished with three different
On Oct 09, 2010, at 02:48 AM, Stephen J. Turnbull wrote:
>Right. That's where I was going with my comment to Barry about the
>Received headers. Even if email isn't going to serve clients working
>with wire format, it needs to deal with those headers. But where I
>think the headers defined by RF
On Oct 08, 2010, at 03:44 PM, l...@rmi.net wrote:
>Ultimately, development in the open source world is driven by the
>very few with time to show up, rather than by the very many who
>depend on it. This can unfortunately lead to the perception
>of thrashing by end users. Some even come to see t
R. David Murray writes:
> On Sat, 09 Oct 2010 01:06:29 +0900, "Stephen J. Turnbull"
> wrote:
> > That mess is entirely unnecessary in Python 3. Text and wire format
> > can be easily distinguished with three different representations of
> > email: Unicode for the conceptual RFC 822 layer (o
On Fri, 08 Oct 2010 12:37:38 +0900, "Stephen J. Turnbull"
wrote:
> *If* you have an 8-bit value of unknown encoding on input, this will
> appear in the Header's value as a surrogate. Hm, OK, I see the
> problem ... as usual, it's that the only efficient thing to do is
> encode using surrogate-es
On Fri, 08 Oct 2010 23:55:37 +0900, "Stephen J. Turnbull"
wrote:
> I should think you *want* addresses and suchlike structured headers
> (Content-Type with several RFC 2231 parameters, anyone?) to line up
> nicely, too. So generic folding algorithms are really only applicable
> to unstructured t
On Fri, 08 Oct 2010 15:44:45 -, l...@rmi.net wrote:
> Thanks for both your reply and work, David. I'm going to have
> to test my email clients under the 3.2 patch when it gels. It's
> good to hear that email5 API support remains a goal.
I just landed the patch (though without the MIME encodi
On Sat, 09 Oct 2010 01:06:29 +0900, "Stephen J. Turnbull"
wrote:
> That mess is entirely unnecessary in Python 3. Text and wire format
> can be easily distinguished with three different representations of
> email: Unicode for the conceptual RFC 822 layer (of course this is an
> extension, becaus
On Fri, 08 Oct 2010 15:51:45 -, l...@rmi.net wrote:
> For my part, one week from now I'll be standing up again in front
> of a group of 20 Python beginners, and basically apologizing for
> both the present and ongoing 3.X changes they must conform to in
> the near future. Python may not be
Barry Warsaw writes:
> On Oct 07, 2010, at 04:40 AM, Stephen J. Turnbull wrote:
> I'm fairly certain that most of the modern causes of [Unicode
> errors in Mailman] are post-parse modifications of the message.
> IOW, in Mailman's architecture, we try to parse the raw data into a
> Message obj
t will break their code.
(Yes, sarcasm intended.)
--Mark Lutz (http://learning-python.com, http://rmi.net/~lutz)
> -Original Message-
> From: "Stephen J. Turnbull"
> To: l...@rmi.net
> Subject: Re: [Python-Dev] Patch making the current email package
> (most
ally given the still tentative state of 3.X, stability matters.
--Mark Lutz (http://learning-python.com, http://rmi.net/~lutz)
> -Original Message-
> From: "R. David Murray"
> To: l...@rmi.net
> Subject: Re: [Python-Dev] Patch making the current email package (mo
Barry Warsaw writes:
> Header wrapping sucks even more because it's supposed to take the
> semantic context into account, which means that a generic Header
> wrapping algorithm cannot work for everything. E.g. Received:
> headers are supposed to wrap after the semicolon.
Received headers are
On Oct 08, 2010, at 12:37 PM, Stephen J. Turnbull wrote:
>Ouch. RFC 822 line wrapping is a bytes->bytes transformation, and the
>client shouldn't see it at all unless it inspects the wire format.
Header wrapping sucks even more because it's supposed to take the semantic
context into account, whi
l...@rmi.net writes:
> To put that more strongly, the Python user base is much larger than
> this list's readership.
Agreed. Nevertheless, this is the channel (not "channel") that the
developers listen on, and substantial effort is made to let Python
users know that. I think they do know it,
R. David Murray writes:
> > The MIME-charset = UNKNOWN dodge might be a better way of handling
> > this.
>
> That is a very interesting idea. It is the *right* thing to do, since it
> would mean that a message parsed as bytes could be generated via Generator
> and passed to, say, smtplib w
On Oct 07, 2010, at 04:40 AM, Stephen J. Turnbull wrote:
> > And the email API currently promises not to raise during parsing,
> > which is a contract my patch does not change.
>
>Which is a contract that has historically been broken frequently.
>Unhandled UnicodeErrors have been one of the most c
On Thu, 07 Oct 2010 16:03:18 -, l...@rmi.net wrote:
> I'm forwarding a link to the code of these clients to David by
> private email in case they might be useful as a test case (O'Reilly
> has already posted them ahead of the book, but they may be a bit too
> heavy for use in formal testing).
Stephen J. Turnbull wrote (giving me an opening to jump in here):
> R. David Murray writes:
> > In other words, my proposed patch only makes email5 1/8 to 1/4
> > broken, instead of half broken as it is now. But not un-broken
> > enough for Mailman, it sounds like.
>
> IMO, not in the long run. B
On Thu, 07 Oct 2010 15:00:04 +0900, "Stephen J. Turnbull"
wrote:
> R. David Murray writes:
>
> > > But that's not interesting; you did that with Python 3. We want to
> > Of course I did it with Python3. It's the Python3 email codebase
> > I'm working with (and have to work *around*).
>
> S
Stephen J. Turnbull xemacs.org> writes:
> R. David Murray writes:
> > We're (in the current patch) not punting on handling non-conforming
> > email, we're punting on handling non-conforming bytes *if the headers
> > that contain them need to be modified*. The headers can still be
> > modified
On Thu, 07 Oct 2010 03:31:34 +0900, "Stephen J. Turnbull"
wrote:
> R. David Murray writes:
>
> > 5. Return the content, with non-ASCII bytes replaced with ?
> > characters.
>
> That hadn't occurred to me (and it makes me sick to contemplate it).
>
> That said, this is probably good enou
R. David Murray writes:
> So the only parsing issue is if Mailman cares about *the non-ASCII
> bytes* in the headers it cares about. If it has to modify headers that
> contain non-ASCII bytes (for example, addresses and Subject) and cares
> about preserving the non-ASCII bytes, then there is
R. David Murray writes:
> 5. Return the content, with non-ASCII bytes replaced with ?
> characters.
That hadn't occurred to me (and it makes me sick to contemplate it).
That said, this is probably good enough for Mailman-like apps to limp
along for "most" users. It's certainly good enoug
On Wed, 06 Oct 2010 22:55:00 +0900, "Stephen J. Turnbull"
wrote:
> R. David Murray writes:
>
> > version of headers to the email5 API, but since any such data would
> > be non-RFC compliant anyway, [access to non-conforming headers by
> > reparsing the bytes] will just have to be good enough
On Wed, 06 Oct 2010 12:22:18 +0900, "Stephen J. Turnbull"
wrote:
> Nick Coghlan writes:
>
> > - if you pass in bytes data and know what you are doing, then you can
> > access that raw bytes data and do your own decoding
>
> At what level, though?
>
> To take an interesting example I used to
R. David Murray writes:
> version of headers to the email5 API, but since any such data would
> be non-RFC compliant anyway, [access to non-conforming headers by
> reparsing the bytes] will just have to be good enough for now.
But that's potentially unpleasant for, say, Mailman. AFAICS, what
Nick Coghlan writes:
> - if you pass in bytes data and know what you are doing, then you can
> access that raw bytes data and do your own decoding
At what level, though?
To take an interesting example I used to see frequently:
From: t...@tokyo.jp
(Taro Yamada in 8-bit Shift JIS)
So I g
On Tue, 05 Oct 2010 22:05:33 +1000, Nick Coghlan wrote:
> On Tue, Oct 5, 2010 at 3:41 PM, Stephen J. Turnbull
> wrote:
> > R. David Murray writes:
> > > Only if the email package contains a coding error would the
> > > surrogates escape and cause problems for user code.
> >
> > I don't think it i
On Tue, Oct 5, 2010 at 3:41 PM, Stephen J. Turnbull wrote:
> R. David Murray writes:
> > Only if the email package contains a coding error would the
> > surrogates escape and cause problems for user code.
>
> I don't think it is reasonable to internalize surrogates that way;
> some applications
R. David Murray writes:
> On Mon, 04 Oct 2010 12:32:26 -0400, Scott Dial
> wrote:
> > On 10/2/2010 7:00 PM, R. David Murray wrote:
> > > The clever hack (thanks ultimately to Martin) is to accept 8bit data
> > > by encoding it using the ASCII codec and the surrogateescape error
> > > handle
On Oct 02, 2010, at 07:00 PM, R. David Murray wrote:
>The advantage of this patch is that it means Python3.2 can have an
>email module that is capable of handling a significant proportion of
>the applications where the ability to process binary email data is
>required.
Like others, I'm concerned
On Mon, 04 Oct 2010 12:32:26 -0400, Scott Dial
wrote:
> On 10/2/2010 7:00 PM, R. David Murray wrote:
> > The clever hack (thanks ultimately to Martin) is to accept 8bit data
> > by encoding it using the ASCII codec and the surrogateescape error
> > handler.
>
> I've seen this idea pop up in a nu
On 10/2/2010 7:00 PM, R. David Murray wrote:
> The clever hack (thanks ultimately to Martin) is to accept 8bit data
> by encoding it using the ASCII codec and the surrogateescape error
> handler.
I've seen this idea pop up in a number of threads. I worry that you are
all inventing a new kind of du
On Sun, Oct 3, 2010 at 9:00 AM, R. David Murray wrote:
> I do not propose that this is a *good* API, since it has the classic
> problem that if there are coding bugs in the email module strings may
> "escape" that have surrogates in them and we end up with programs that
> work most of the time
On Sat, 02 Oct 2010 19:15:57 -0500, Benjamin Peterson
wrote:
> 2010/10/2 R. David Murray :
> > Regardless of whether or not this patch or a descendant thereof is
> > accepted I still intend to continue working on email6. =C2=A0There are ma=
> ny
> > other bugs in the current email package that re
2010/10/2 R. David Murray :
> Regardless of whether or not this patch or a descendant thereof is
> accepted I still intend to continue working on email6. There are many
> other bugs in the current email package that require a rewrite of parts
> of its infrastructure, and the email-sig is agreed th
A while back on some issue or another I remember telling someone that
if there was any sort of clever hack that would allow the current email
package (email5) to work with bytes we would have implemented it.
Well, I've come up with a clever hack.
The idea came out of a conversation with Antoine.
On 7/25/2010 2:58 PM, Leonhard Vogt wrote:
I have made a documentation patch for issue 7447.
I cannot change the stage to patch-review - is this intentional?
Would be great if someone could comment on the patch.
Done x 3
--
Terry Jan Reedy
___
Pyth
Hi
I have made a documentation patch for issue 7447.
I cannot change the stage to patch-review - is this intentional?
Would be great if someone could comment on the patch.
Leonhard
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.
> I see the confusion. I think Martin meant more about open issues that
> required discussion, not simply issues that had a patch ready to go.
I actually think it is perfectly fine to point out that specific issues
are need committer action on this list. This is what the list is there for.
Waitin
I am aware my email has gone out multiple times. My phone kept saying that
it was not sent, so I kept trying to force it to send. Sorry about the extra
emails.
On Fri, Apr 16, 2010 at 10:50, Brett Cannon wrote:
> Yes, we have different opinions. My personal take is to wait a week before
> you em
Yes, we have different opinions. My personal take is to wait a week before
you email python-dev if there has been no activity. That is enough time for
people interested in the patch to get to it as we all have different
schedules. Any faster and it feels like noise on the list to me.
Brett (from h
1 - 100 of 498 matches
Mail list logo
