__getslice__ usage in sre_parse
Hello, Python language reference 3.3.6 deprecates __getslice__. I think it's okay that UserList.py has it, but sre_parse shouldn't use it, no? __getslice__ is not implemented in IronPython and this breaks usage of _sre.py, a pure-Python implementation of _sre, on IronPython: http://ubique.ch/code/_sre/ _sre.py is needed for me because IronPython's own regex implementation using underlying .NET implementation is not compatible enough for my applications. I will write a separate bug report for this. It should be a matter of removing __getslice__ and adding isinstance(index, slice) check in __getitem__. I would very much appreciate it if this is fixed before Python 2.5. Seo Sanghyeon
On 4/28/06, Sanghyeon Seo
Hello,
Python language reference 3.3.6 deprecates __getslice__. I think it's okay that UserList.py has it, but sre_parse shouldn't use it, no?
Well, as long as the deprecated code isn't removed, there's no reason why other library code shouldn't use it. So I disagree that technically there's a reason why sre_parse shouldn't use it.
__getslice__ is not implemented in IronPython and this breaks usage of _sre.py, a pure-Python implementation of _sre, on IronPython: http://ubique.ch/code/_sre/
_sre.py is needed for me because IronPython's own regex implementation using underlying .NET implementation is not compatible enough for my applications. I will write a separate bug report for this.
It should be a matter of removing __getslice__ and adding isinstance(index, slice) check in __getitem__. I would very much appreciate it if this is fixed before Python 2.5.
You can influence the fix yourself -- please write a patch (relative to Python 2.5a2 that was just released), submit it to Python's patch tracker on SourceForge (read python.org/dev first), and then sending an email here to alert the developers. This ought to be done well before the planned 2.5b1 release (see PEP 256 for the 2.5 release timeline). You should make sure that the patched Python 2.5 passes all unit tests before submitting your test. Good luck! -- --Guido van Rossum (home page: http://www.python.org/~guido/)
I've also opened a bug for supporting __getslice__ in IronPython.
Do you want to help develop Dynamic languages on CLR? (http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0...)
-----Original Message-----
From: python-dev-bounces+dinov=microsoft.com@python.org [mailto:python-dev-bounces+dinov=microsoft.com@python.org] On Behalf Of Guido van Rossum
Sent: Sunday, April 30, 2006 8:31 AM
To: Sanghyeon Seo
Cc: Discussion of IronPython; python-dev@python.org
Subject: Re: [Python-Dev] __getslice__ usage in sre_parse
On 4/28/06, Sanghyeon Seo
Hello,
Python language reference 3.3.6 deprecates __getslice__. I think it's okay that UserList.py has it, but sre_parse shouldn't use it, no?
Well, as long as the deprecated code isn't removed, there's no reason why other library code shouldn't use it. So I disagree that technically there's a reason why sre_parse shouldn't use it.
__getslice__ is not implemented in IronPython and this breaks usage of _sre.py, a pure-Python implementation of _sre, on IronPython: http://ubique.ch/code/_sre/
_sre.py is needed for me because IronPython's own regex implementation using underlying .NET implementation is not compatible enough for my applications. I will write a separate bug report for this.
It should be a matter of removing __getslice__ and adding isinstance(index, slice) check in __getitem__. I would very much appreciate it if this is fixed before Python 2.5.
You can influence the fix yourself -- please write a patch (relative to Python 2.5a2 that was just released), submit it to Python's patch tracker on SourceForge (read python.org/dev first), and then sending an email here to alert the developers. This ought to be done well before the planned 2.5b1 release (see PEP 256 for the 2.5 release timeline). You should make sure that the patched Python 2.5 passes all unit tests before submitting your test. Good luck! -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ 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/dinov%40microsoft.com
participants (3)
-
Dino Viehland -
Guido van Rossum -
Sanghyeon Seo