New submission from Torsten Becker :
I have started an implementation of PEP 393 -- Flexible String Representation
[1] on bitbucket [2]. Not all code is ported to use the new API yet, but the
interpreter starts with the new unicode representation, all unit tests pass,
and some micro
Torsten Becker added the comment:
Hi, Jesús, I merged the patch up in the branches
"startswith-slices-issue11828-3.2" [1] and "startswith-slices-issue11828-3.3"
[2] in my hg repository.
[1]: https://bitbucket.org/t0rsten/cpython/changeset/49028581e43a
[2]: https://b
Changes by Torsten Becker :
Removed file: http://bugs.python.org/file21706/2b48fd451c85.diff
___
Python tracker
<http://bugs.python.org/issue11828>
___
___
Python-bug
Changes by Torsten Becker :
--
hgrepos: +22
___
Python tracker
<http://bugs.python.org/issue11828>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Torsten Becker :
Added file: http://bugs.python.org/file21706/2b48fd451c85.diff
___
Python tracker
<http://bugs.python.org/issue11828>
___
___
Python-bug
Torsten Becker added the comment:
I pushed my changes to a hg repository, they are in the two branches
"startswith-slices-issue11828-2.7" and "startswith-slices-issue11828-3.1".
--
hgrepos: +21
___
Python tracker
<http://bug
Torsten Becker added the comment:
Hi, here is my revised patch with email.utils.getaddresses() also decoding IDNs.
I decided to integrate IDN decoding in AddrlistClass.getaddress() instead of
AddrlistClass.getaddrlist() since that function is one level lower and if
somebody should ever all
Torsten Becker added the comment:
> (The word anybody made me think.
> But "fix properly" ... i'm sure you cannot refer to myself.
> :))
"fix properly" referred to my inferior implementation and "anybody"
should probably have been wor
Torsten Becker added the comment:
> OK, so when I went to apply this, I figured out that the patch isn't quite
> right. I've redone the doc updates, and am attaching a version of the patch
> containing them.
>
> The issue is that the place that the IDNA decode
Changes by Torsten Becker :
Added file: http://bugs.python.org/file21656/issue-11828-v4-2.7.patch
___
Python tracker
<http://bugs.python.org/issue11828>
___
___
Python-bug
Torsten Becker added the comment:
> I got your comments, Torsten. I finds funny too that the tracker is
> not notified.
> I wrote new comments too, but not using "the right way", so now I am
> the one not sure you got them... :-)
That time I actually got a separate mail.
Torsten Becker added the comment:
> Some comments posted in the review.
I'm not sure if my review reply got mailed as I did not get a copy and nothing
showed up here. I added some responses/follow up questions in the review.
> Could you possibly post a patch for 2.7 too?.
Sure,
Torsten Becker added the comment:
Hi, since nobody stopped me by complaining about the approach or the first
patch, I now fixed this for bytes and bytearray as well. :)
I renamed the old _ParseTupleFinds function to stringlib_parse_tuple_finds,
added a parameter for function name, and
Changes by Torsten Becker :
Removed file:
http://bugs.python.org/file21623/issue-8282-error-message-tests.patch
___
Python tracker
<http://bugs.python.org/issue11
Changes by Torsten Becker :
Added file: http://bugs.python.org/file21627/issue-11828-error-msg-tests.patch
___
Python tracker
<http://bugs.python.org/issue11828>
___
___
Torsten Becker added the comment:
Just realized that part of my v1 patch did not conform to PEP 7, I hope, I
fixed that in v2.
Please also excuse for the wrong name of the error message patch, it was
supposed to be named "issue-11828-error-msg-tests.patch".
--
Added
Torsten Becker added the comment:
While working on this, I discovered anther problem. find(), etc. all use the
same parsing function (_ParseTupleFinds()). So when an error occurs, the
exception message will always start with "find()" even though index() or
rfind() might have
Torsten Becker added the comment:
Hi, I started working on a first patch for this. A function _ParseTupleFinds()
exists which does the proper parsing for this kind of arguments in
unicodeobject.c, I adapted it to be usable for startswith() and endswith()
besides find() and friends.
In
Torsten Becker added the comment:
> modulo some English wording that I'll fix up when I commit it.
Yeah, sorry for that, I seem to have trouble with writing good documentation.
:) I'll have a look at the documents referenced by [1] to improve my writing.
> The issue with th
Torsten Becker added the comment:
> Have a nice weekend!
Thank you for the wishes, I hope yours is going well, too!
I added IDNA awareness to formataddr() and parseaddr(), updated the docs and
wrote 2 tests for it.
I wasn't sure if the IDNA awareness should be optional via a arg
Torsten Becker added the comment:
I was about to look into this over the weekend, but of course I don't
want to steal your fun, Steffen. :)
--
___
Python tracker
<http://bugs.python.org/is
Torsten Becker added the comment:
Hi David, thank you for polishing up the patch and committing it. :)
I am glad I could help and I was actually about to ask you if you knew
any follow-up issues. I'll definitely continue contributing as time
allows. I did not submit the agreement yet
Torsten Becker added the comment:
Hi, I read through unicodeobject.c and added the (IMO) proper reference counts
to the missing functions. I attached a first patch which adds this to
Doc/data/refcounts.dat.
The patch also fixes 2 minor glitches in Doc/c-api/unicode.rst
Torsten Becker added the comment:
I incorporated that change as well. My rationale behind the previous version
was to be consistent with how Lib/email/header.py handled this, unfortunately I
did not look around in the other classes and didn't think about that kind of
compatibility.
Torsten Becker added the comment:
I incorporated the changes as you suggested and added the text to the docs.
Just out of curiosity, why are the docs repeated in email.util.rst when they
are already in the docstrings?
--
Added file: http://bugs.python.org/file21434/issue-1690608-v3
Torsten Becker added the comment:
> However, there should be a test for that, and I'm curious to know what
> happens if you use such an address in an address field in the unmodified
> email package.
I added a test to check if the exceptions get thrown when a address is invalid.
Torsten Becker added the comment:
I implemented a basic test for the issue and an attempt for a fix.
I am not entirely sure with my implementation, specifically I would like to get
comments concerning the following points:
- Is is OK that formataddr() will now check if address is ascii
27 matches
Mail list logo
