Change by Eric Lafontaine <eric.lafontai...@gmail.com>:
--
pull_requests: +5028
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Eric Lafontaine added the comment:
Hi All,
Should I try to make this a github PR instead to accelerate the review?
Regards,
Eric Lafontaine
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Eric Lafontaine added the comment:
Hi,
Could someone put this ticket on "waiting for review"?
Regards,
Eric Lafontaine
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.py
Eric Lafontaine added the comment:
(first time trying to reply through email)
thanks for the example and you are right :
class Foo_emptylist(object):
def __contains__(self,item): return []
class Foo_emptydict(object):
def __contains__(self,item): return {}
class Foo_emptystring(object
Eric Lafontaine added the comment:
oh, I've got what you meant!
Proposed change :
For user-defined classes which define the __contains__() method, the in
operator will convert to False "x in y" if y.__contains__(x) return False, 0 or
None. Otherwise, the in operator will return Tr
Eric Lafontaine added the comment:
Hi David, sorry for the delay on my part for providing how I was getting to
that conclusion. I've also resurrected an old post as I want to start
contributing more seriously :).
As this is documentation only (not changing the code behavior), I didn't take
Eric Lafontaine added the comment:
Hi all,
Here are the test I've made to understand the behavior :
class Foo_42(object):
def __contains__(self,item): return 42
class Foo_neg(object):
def __contains__(self,item): return -42
class Foo_None(object):
def __contains__(self
Eric Lafontaine added the comment:
Hi,
For user-defined class, it's up to the class to do the right implementation in
my opinion. It's true the description is wrong though.
x in y means that x exist inside of y (so that the execution of
y.__contain__(x) is executed successfully and (I guess
Eric Lafontaine added the comment:
Hi all,
What do we do with this ticket?
Patch were provided, People have agreed (I think). So what's missing to close
it (or pass to the next step)? It's going to be a year that a high priority
ticket has no update and I would like to accelerate it if I
Eric Lafontaine added the comment:
Hi,
I've just watched the old David Beazley video about the packaging system in
python and got me thinking about this issue.
I'm throwing the idea, please critize it!
If we were to make a "hook" for the .rst files of the modules to go and scan
th
Eric Lafontaine added the comment:
Hi all,
Here you go :).
Regards,
Eric Lafontaine
--
Added file: http://bugs.python.org/file46459/issue28879_v5.patch
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Eric Lafontaine added the comment:
Resent-heuristic
--
Added file: http://bugs.python.org/file46460/Resent_heuristic.patch
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Eric Lafontaine added the comment:
Hi,
I've implemented the heuristic, but it's messy with the issue of this ticket.
I'm going to do some clean-up and separate the issue from the heuristic and
post them separated.
Date issue ;
Test Case
Documentation
Implementation
Heuristic of Resent
Eric Lafontaine added the comment:
Hi all,
I've received an answer from the IETF Pete Resnick. The answer does say
however that there is no guaranteed way of getting the right headers if the
message doesn't respect the standard;
"[...]
In this case, if the trace fields were not pr
Eric Lafontaine added the comment:
Hi all,
The IETF didn't answer yet :(.
I'll await your news regarding this patch ("issue_28879_V4.patch").
I would like to have feedback if I need to change something.
Thanks a lot in advance,
Eric
Eric Lafontaine added the comment:
Hi all,
The fix is already provided in issue28945 . Please review it and I would like
to flag it as needing more test on more version of python...
The patch would just require more Test Case that would check for the
filename for preventing re-occurence
Changes by Eric Lafontaine <eric.lafontai...@gmail.com>:
--
nosy: +Eric Lafontaine
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Eric Lafontaine added the comment:
Hi,
I would like to thank you for keeping up with me. I may not be easy at times,
but please make me understand if it doesn't make sense :).
Thanks bpoaugust and David,
Eric Lafontaine
--
___
Python tracker <
Eric Lafontaine added the comment:
Hi,
I would like to have a bigger set of user testing this patch before it gets
approve... I really don't know all the extent to which it's a good/bad idea.
The proposition was to not do the unquote in the rfc2231 collapse method. It
doesn't break
Eric Lafontaine added the comment:
overkill file
--
Added file: http://bugs.python.org/file46002/issue_28879_python2_overkill.patch
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Eric Lafontaine added the comment:
Hi David, Henning,
Sorry for the delay. Here is the patch for python 2... but I find that adding
an "example" just for RFC 5322 is kind of over-kill...
So I've made both :) please choose which one you prefer and let me know. I
personnally pre
Eric Lafontaine added the comment:
N.B., I've tried to do the keyword parameter on the get_param inside the
get_boundary as well as I though it was a good Idea as well, but it was
breaking some test cases (multiple ones). So I didn't pursue.
N.B. I'm guessing (guessing) unquote must've been
Eric Lafontaine added the comment:
Hi all,
I hate this proposition. I feel it's a "victory" for the people who don't want
to follow RFC standard and allow "triple"-quoting on things that aren't
supposed to...
Now that my opinion is said, I made 2 test case
Eric Lafontaine added the comment:
Hi all,
I believe this is the right behavior and what ever generated the boundary
"<<>>" is the problem ;
RFC 2046 page 22:
_
The only mandatory global parameter for the "multipart" media type is the
bo
Eric Lafontaine added the comment:
Hi all,
@David, the "Resent-" block should be added by the user and he needs to know
what he's doing. Hell, I work with emails all the time and never knew about
this. The Worse part of it is that I have to communicate with the IETF just to
know
Eric Lafontaine added the comment:
forgot to re-post the to-do, and to correct the documentation :
List of things to do :
- Implement a patch for the code to add a missing "Date" field if it doesn't
exist . (in review)
- Modify the documentation at the SMTPLib for the send_message
Eric Lafontaine added the comment:
Hi all,
this is not a short answer, like I hoped it would be ;). But skip to the last
section if you don't want to read it all.
the heuristic problem :
For the heuristic of the resent headers, it's clearly say in the RFC5322
Eric Lafontaine added the comment:
Hi all, I was looking at the code of the function and also noticed multiple
"itching".
1- Why raise an error when 2 resent-date exist? it may exist and completely
legitimate as per RFC5322. The code should always take the first one it sees
as p
Eric Lafontaine added the comment:
Hi all,
Thanks for the enlightment. I never figured that there was a send_message
function XD. Never needed it and it's true that the example in the email
library use sendmail and not send_message.
https://docs.python.org/2/library/smtplib.html
Eric Lafontaine added the comment:
Hi,
I believe it's already done. The only thing that people tends to forget is
that doing python -m "module.script(.py)" is only doing the equivalent of
"python module/script.py".
I believe it's clear though ;
https://docs.python.org/
Eric Lafontaine added the comment:
Hi, Not sure this is where the comment goes...
I work with the smtplib and email libraries. I understand Henning von Bargen
when he say that we should have a way to support RFC 5322 without asking the
user to understand how to support it. The issue
31 matches
Mail list logo
