Richard Jones richardjo...@optushome.com.au added the comment:
Committed in revision 83125.
--
assignee: - richard
resolution: - fixed
stage: - committed/rejected
status: open - closed
type: - feature request
___
Python tracker
Richard Jones richardjo...@optushome.com.au added the comment:
After discussing with core devs at the EuroPython sprint I will implement a
different approach: new attributes with the old, private attributes implemented
as properties over the new attributes. The properties responsible for this
Mark Lawrence breamore...@yahoo.co.uk added the comment:
Would this patch be acceptable, yes or no?
--
nosy: +BreamoreBoy
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.6
___
Python tracker rep...@bugs.python.org
Giampaolo Rodola' g.rod...@gmail.com added the comment:
The patch as-is can't be accepted if not for Python 4.x maybe, obviously
because it's just too breaking.
A proper patch would provide aliases for the removed attributes and raise a
DeprecationWarning in case they are accessed.
It would
Changes by Giampaolo Rodola' g.rod...@gmail.com:
--
versions: -Python 2.7, Python 3.1
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4184
___
___
Richard Jones richardjo...@optushome.com.au added the comment:
Giampaolo,
I think I can see where you're coming from: assuming that someone else must
have also had to resort to the name-mangling hack to extend the class? In that
case yes, my patch would break their code. I'll look at
Giampaolo Rodola' g.rod...@gmail.com added the comment:
Would that be acceptable?
I guess it would. Deciding to use that naming convention was a bad design
choice in the first place, hence your proposal is perfectly reasonable, in my
opinion.
What additional tests would you deem necessary?
Changes by Giampaolo Rodola' g.rod...@gmail.com:
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4184
___
___
Python-bugs-list mailing list
Giampaolo Rodola' g.rod...@gmail.com added the comment:
Would that be acceptable?
I guess it would. Deciding to use that naming convention was a bad design
choice in the first place, hence your proposal is perfectly reasonable, in my
opinion.
What additional tests would you deem necessary?
Antoine Pitrou pit...@free.fr added the comment:
The patch as-is can't be accepted if not for Python 4.x maybe,
obviously because it's just too breaking.
With all due respect, this sounds a bit silly. If the attributes were of the
__private kind, they weren't meant to be used by other
Giampaolo Rodola' g.rod...@gmail.com added the comment:
If the attributes were of the __private kind, they weren't meant to
be used by other classes, and so there's no problem in making them
public.
Generally I would agree with you but this case is different, imho.
The problem here is that
Changes by Doug Hellmann [EMAIL PROTECTED]:
--
nosy: +doughellmann
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4184
___
___
Python-bugs-list mailing
Changes by Giampaolo Rodola' [EMAIL PROTECTED]:
--
nosy: +giampaolo.rodola
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4184
___
___
Python-bugs-list
New submission from Richard Jones [EMAIL PROTECTED]:
Executive summary of the patch:
The attached patch removes the use of __private attributes in the smtpd
module allowing it to be extensible without needing to use the
_classname__attributename hack.
Summary of the patch's changes:
1.
14 matches
Mail list logo
