Re: [Python-Dev] Python 3000 Status Update (Long!)
Guido van Rossum schrieb: > I've written up a comprehensive status report on Python 3000. Please read: > > http://www.artima.com/weblogs/viewpost.jsp?thread=208549 Thank you! Now I have something to show to interested people except "read the PEPs". A minuscule nit: the rot13 codec has no library equivalent, so it won't be supported anymore :) Georg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3000 Status Update (Long!)
Georg Brandl wrote:
> Guido van Rossum schrieb:
>> I've written up a comprehensive status report on Python 3000. Please read:
>>
>> http://www.artima.com/weblogs/viewpost.jsp?thread=208549
>
> Thank you! Now I have something to show to interested people except "read
> the PEPs".
>
> A minuscule nit: the rot13 codec has no library equivalent, so it won't be
> supported anymore :)
Given that there are valid use cases for bytes-to-bytes translations,
and a common API for them would be nice, does it make sense to have an
additional category of codec that is invoked via specific recoding
methods on bytes objects? For example:
encoded = data.encode_bytes('bz2')
decoded = encoded.decode_bytes('bz2')
assert data == decoded
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http://www.boredomandlaziness.org
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Inspect Patch for IronPython (and Jython?) Compatibility
Hello all, I've just submitted a patch on sourceforge to make inspect compatible with IronPython (and Jython I think). This patch originally comes from the IPCE ( http://fepy.sf.net ) project by Seo Sanghyeon. It is a trivial change really. The patch is number 1739696 http://sourceforge.net/tracker/index.php?func=detail&aid=1739696&group_id=5470&atid=305470 It moves getting a reference to 'code.co_code' into the body of the loop responsible for inspecting anonymous (tuple) arguments. In IronPython, accessing 'co_code' raises a NotImplementedError - meaning that inspect.get_argspec is broken. This patch means that *except* for functions with anonymous tuple arguments, it will work again on IronPython - whilst maintaining full compatibility with the previous behaviour. Jython has a similar patch to overcome the same issue by the way. See http://jython.svn.sourceforge.net/viewvc/jython?view=rev&revision=3200 As it is a bugfix - backporting to 2.5 would be great. Should I generate a separate patch? All the best, Michael Foord ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Multi-line comments - a case for PEP 3099?
Hi, we got another feature request for multi-line comments. While it is nice to comment out multiple lines at once, every editor that deserves that name can add a '#' to multiple lines. And there's always "if 0" and triple-quoted strings... Georg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Python 3000 Status Update (Long!)
Georg Brandl wrote:
> Nick Coghlan schrieb:
>> Georg Brandl wrote:
>>> Guido van Rossum schrieb:
I've written up a comprehensive status report on Python 3000. Please read:
http://www.artima.com/weblogs/viewpost.jsp?thread=208549
>>> Thank you! Now I have something to show to interested people except "read
>>> the PEPs".
>>>
>>> A minuscule nit: the rot13 codec has no library equivalent, so it won't be
>>> supported anymore :)
>> Given that there are valid use cases for bytes-to-bytes translations,
>> and a common API for them would be nice, does it make sense to have an
>> additional category of codec that is invoked via specific recoding
>> methods on bytes objects? For example:
>>
>>encoded = data.encode_bytes('bz2')
>>decoded = encoded.decode_bytes('bz2')
>>assert data == decoded
>
> This is exactly what I proposed a while before under the name
> bytes.transform().
>
> IMO it would make a common use pattern much more convenient and
> should be given thought.
>
> If a PEP is called for, I'd be happy to at least co-author it.
Codecs are a major exception to Guido's law: Never have a parameter
whose value switches between completely unrelated algorithms.
Why don't we put all string transformation functions into a common
module (the string module might be a good place):
>>> import string
>>> string.rot13('abc')
Servus,
Walter
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Python 3000 Status Update (Long!)
On 2007-06-19 14:40, Walter Dörwald wrote:
> Georg Brandl wrote:
A minuscule nit: the rot13 codec has no library equivalent, so it won't be
supported anymore :)
>>> Given that there are valid use cases for bytes-to-bytes translations,
>>> and a common API for them would be nice, does it make sense to have an
>>> additional category of codec that is invoked via specific recoding
>>> methods on bytes objects? For example:
>>>
>>>encoded = data.encode_bytes('bz2')
>>>decoded = encoded.decode_bytes('bz2')
>>>assert data == decoded
>> This is exactly what I proposed a while before under the name
>> bytes.transform().
>>
>> IMO it would make a common use pattern much more convenient and
>> should be given thought.
>>
>> If a PEP is called for, I'd be happy to at least co-author it.
>
> Codecs are a major exception to Guido's law: Never have a parameter
> whose value switches between completely unrelated algorithms.
I don't see much of a problem with that. Parameters are
per-se intended to change the behavior of a function or
method.
Note that you are referring to the .encode() and .decode()
methods - these are just easy to use interfaces to the codecs
registered in the system.
The codec design allows for different input and output
types as it doesn't impose restrictions on these. Codecs
are more general in that respect: they don't just deal
with Unicode encodings, it's a more general approach
that also works with other kinds of data types.
The access methods, OTOH, can impose restrictions and probably
should to restrict the return types to a predicable set.
> Why don't we put all string transformation functions into a common
> module (the string module might be a good place):
>
import string
string.rot13('abc')
I think the string module will have to go away. It doesn't
really separate between text and bytes data.
Adding more confusion will not really help with making
this distinction clear, either, I'm afraid.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Jun 19 2007)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/
2007-07-09: EuroPython 2007, Vilnius, Lithuania19 days to go
Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free !
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Calling Methods from Pythons C API with Keywords
Hey Guys, My first post on this list so I hope this is the right place to post and relevant. Im rewriting parts of the Blender3D python API that has got a bit old and needs an update. Im making a PyList subtype with the C/Python API, this involves intercepting calls to standard list methods to make sure Blenders array data is in Sync with the list's data. Iv got it working for tp_as_sequence, tp_as_mapping, iter and dealloc etc but methods are a problem. I want to add my own call's before and after PyLists standard functions but have a proplem with functons that use keywords and have no API equivalent. For example, I cant use the API's PyList_Sort because that dosnt support keywords like... ls.sort(key=lambda a: a.foo)) And the Problem with PyObject_CallMethod is that it dosnt accept keywords. PyObject_CallMethod((PyObject *)mylist, "sort", "O", args); Looking at abstract.c, PyObject_CallMethod uses call_function_tail, which calls "PyObject_Call(callable, args, NULL);" - so Its not currently possible with PyObject_CallMethod. But I cant find any way to do this in a few lines. I could use PyEval_CallObjectWithKeywords but that would mean Id need to get the method from the list manually which Ill look into, but unless Im missing something here, it seems PyObject_CallMethodWithKeywords would be a nice addition to the Python API that cant be done in a straight forward way at the moment. - Thanks ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Issues with PEP 3101 (string formatting)
Wrt http://www.python.org/dev/peps/pep-3101/ PEP 3101 says Py3K should allow item and attribute access syntax within string templating expressions but "to limit potential security issues", access to underscore prefixed names within attribute/item access expressions will be disallowed. I am a person who has lived with the aftermath of a framework designed to prevent data access by restricting access to underscore- prefixed names (Zope 2, ahem), and I've found it's very hard to explain and justify. As a result, I feel that this is a poor default policy choice for a framework. In some cases, underscore names must become part of an object's external interface. Consider a URL with one or more underscore- prefixed path segment elements (because prefixing a filename with an underscore is a perfectly reasonable thing to do on a filesystem, and path elements are often named after file names) fed to a traversal algorithm that attempts to resolve each path element into an object by calling __getitem__ against the parent found by the last path element's traversal result. Perhaps this is poor design and __getitem__ should not be consulted here, but I doubt that highly because there's nothing particularly special about calling a method named __getitem__ as opposed to some method named "traverse". The only precedent within Python 2 for this sort of behavior is limiting access to variables that begin with __ and which do not end with __ to the scope defined by a class and its instances. I personally don't believe this is a very useful feature, but it's still only an advisory policy and you can worm around it with enough gyrations. Given that security is a concern at all, the only truly reasonable way to "limit security issues" is to disallow item and attribute access completely within the string templating expression syntax. It seems gratuituous to me to encourage string templating expressions with item/attribute access, given that you could do it within the format arguments just as easily in the 99% case, and we've (well... I've) happily been living with that restriction for years now. But if this syntax is preserved, there really should be no *default* restrictions on the traversable names within an expression because this will almost certainly become a hard-to-explain, hard-to-justify bug magnet as it has become in Zope. - C ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Python 3000 Status Update (Long!)
Georg Brandl wrote:
> Walter Dörwald schrieb:
>> Georg Brandl wrote:
>>> Nick Coghlan schrieb:
Georg Brandl wrote:
> Guido van Rossum schrieb:
>> I've written up a comprehensive status report on Python 3000. Please
>> read:
>>
>> http://www.artima.com/weblogs/viewpost.jsp?thread=208549
> Thank you! Now I have something to show to interested people except "read
> the PEPs".
>
> A minuscule nit: the rot13 codec has no library equivalent, so it won't be
> supported anymore :)
Given that there are valid use cases for bytes-to-bytes translations,
and a common API for them would be nice, does it make sense to have an
additional category of codec that is invoked via specific recoding
methods on bytes objects? For example:
encoded = data.encode_bytes('bz2')
decoded = encoded.decode_bytes('bz2')
assert data == decoded
>>> This is exactly what I proposed a while before under the name
>>> bytes.transform().
>>>
>>> IMO it would make a common use pattern much more convenient and
>>> should be given thought.
>>>
>>> If a PEP is called for, I'd be happy to at least co-author it.
>> Codecs are a major exception to Guido's law: Never have a parameter
>> whose value switches between completely unrelated algorithms.
>
> I don't think that applies here. This is more like __import__():
> depending on the first parameter, completely different things can happen.
> Yes, the same import algorithm is used, but in the case of
> bytes.encode_bytes, the same algorithm is used to find and execute the
> codec.
What would a registry of tranformation algorithms buy us compared to a
module with transformation functions?
The function version is shorter:
transform.rot13('foo')
compared to:
'foo'.transform('rot13')
If each transformation has its own function, these functions can have
their own arguments, e.g.
transform.bz2encode(data: bytes, level: int=6) -> bytes
Of course str.transform() could pass along all arguments to the
registered function, but that's worse from a documentation viewpoint,
because the real signature is hidden deep in the registry.
Servus,
Walter
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Multi-line comments - a case for PEP 3099?
On 6/19/07, Georg Brandl <[EMAIL PROTECTED]> wrote: > we got another feature request for multi-line comments. > > While it is nice to comment out multiple lines at once, every editor > that deserves that name can add a '#' to multiple lines. > > And there's always "if 0" and triple-quoted strings... I'd als say that the case for TOOWTDI is pretty clear on that. But perhaps we can keep the Py3k discussions on the [EMAIL PROTECTED] list? -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issues with PEP 3101 (string formatting)
Those are valid concerns. I'm cross-posting this to the python-3000 list in the hope that the PEP's author and defendents can respond. I'm sure we can work something out. Please keep further discussion on the [EMAIL PROTECTED] list. --Guido On 6/19/07, Chris McDonough <[EMAIL PROTECTED]> wrote: > Wrt http://www.python.org/dev/peps/pep-3101/ > > PEP 3101 says Py3K should allow item and attribute access syntax > within string templating expressions but "to limit potential security > issues", access to underscore prefixed names within attribute/item > access expressions will be disallowed. > > I am a person who has lived with the aftermath of a framework > designed to prevent data access by restricting access to underscore- > prefixed names (Zope 2, ahem), and I've found it's very hard to > explain and justify. As a result, I feel that this is a poor default > policy choice for a framework. > > In some cases, underscore names must become part of an object's > external interface. Consider a URL with one or more underscore- > prefixed path segment elements (because prefixing a filename with an > underscore is a perfectly reasonable thing to do on a filesystem, and > path elements are often named after file names) fed to a traversal > algorithm that attempts to resolve each path element into an object > by calling __getitem__ against the parent found by the last path > element's traversal result. Perhaps this is poor design and > __getitem__ should not be consulted here, but I doubt that highly > because there's nothing particularly special about calling a method > named __getitem__ as opposed to some method named "traverse". > > The only precedent within Python 2 for this sort of behavior is > limiting access to variables that begin with __ and which do not end > with __ to the scope defined by a class and its instances. I > personally don't believe this is a very useful feature, but it's > still only an advisory policy and you can worm around it with enough > gyrations. > > Given that security is a concern at all, the only truly reasonable > way to "limit security issues" is to disallow item and attribute > access completely within the string templating expression syntax. It > seems gratuituous to me to encourage string templating expressions > with item/attribute access, given that you could do it within the > format arguments just as easily in the 99% case, and we've (well... > I've) happily been living with that restriction for years now. > > But if this syntax is preserved, there really should be no *default* > restrictions on the traversable names within an expression because > this will almost certainly become a hard-to-explain, hard-to-justify > bug magnet as it has become in Zope. > > - C > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Inspect Patch for IronPython (and Jython?) Compatibility
Let's definitely add this to the trunk (2.6). It sounds fine to me as a bugfix too, since (from your description) it doesn't change the behavior at all in CPython. I won't have the time to submit this, but I'm sure there are others here who do. --Guido On 6/19/07, Michael Foord <[EMAIL PROTECTED]> wrote: > Hello all, > > I've just submitted a patch on sourceforge to make inspect compatible > with IronPython (and Jython I think). This patch originally comes from > the IPCE ( http://fepy.sf.net ) project by Seo Sanghyeon. It is a > trivial change really. > > The patch is number 1739696 > http://sourceforge.net/tracker/index.php?func=detail&aid=1739696&group_id=5470&atid=305470 > > It moves getting a reference to 'code.co_code' into the body of the loop > responsible for inspecting anonymous (tuple) arguments. > > In IronPython, accessing 'co_code' raises a NotImplementedError - > meaning that inspect.get_argspec is broken. > > This patch means that *except* for functions with anonymous tuple > arguments, it will work again on IronPython - whilst maintaining full > compatibility with the previous behaviour. > > Jython has a similar patch to overcome the same issue by the way. See > http://jython.svn.sourceforge.net/viewvc/jython?view=rev&revision=3200 > > As it is a bugfix - backporting to 2.5 would be great. Should I generate > a separate patch? > > All the best, > > Michael Foord > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Python 3000 Status Update (Long!)
Walter Dörwald schrieb:
If a PEP is called for, I'd be happy to at least co-author it.
>>> Codecs are a major exception to Guido's law: Never have a parameter
>>> whose value switches between completely unrelated algorithms.
>>
>> I don't think that applies here. This is more like __import__():
>> depending on the first parameter, completely different things can happen.
>> Yes, the same import algorithm is used, but in the case of
>> bytes.encode_bytes, the same algorithm is used to find and execute the
>> codec.
>
> What would a registry of tranformation algorithms buy us compared to a
> module with transformation functions?
Easier registering of custom transformations. Without a registry, you'd have
to monkey-patch a module.
> The function version is shorter:
>
>transform.rot13('foo')
>
> compared to:
>
>'foo'.transform('rot13')
Yes, that's a very convincing argument :)
> If each transformation has its own function, these functions can have
> their own arguments, e.g.
>transform.bz2encode(data: bytes, level: int=6) -> bytes
>
> Of course str.transform() could pass along all arguments to the
> registered function, but that's worse from a documentation viewpoint,
> because the real signature is hidden deep in the registry.
I don't think transformation functions need arguments.
Georg
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Multi-line comments - a case for PEP 3099?
Guido van Rossum schrieb: > On 6/19/07, Georg Brandl <[EMAIL PROTECTED]> wrote: > >> we got another feature request for multi-line comments. >> >> While it is nice to comment out multiple lines at once, every editor >> that deserves that name can add a '#' to multiple lines. >> >> And there's always "if 0" and triple-quoted strings... > I'd als say that the case for TOOWTDI is pretty clear on that. > > But perhaps we can keep the Py3k discussions on the [EMAIL PROTECTED] list? I haven't really seen this as a python-3000 specific issue. Or are you referring to the other cross-posting thread? Georg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Multi-line comments - a case for PEP 3099?
On 6/19/07, Georg Brandl <[EMAIL PROTECTED]> wrote: > Guido van Rossum schrieb: > > On 6/19/07, Georg Brandl <[EMAIL PROTECTED]> wrote: > > > >> we got another feature request for multi-line comments. > >> > >> While it is nice to comment out multiple lines at once, every editor > >> that deserves that name can add a '#' to multiple lines. > >> > >> And there's always "if 0" and triple-quoted strings... > > I'd als say that the case for TOOWTDI is pretty clear on that. > > > > But perhaps we can keep the Py3k discussions on the [EMAIL PROTECTED] list? > > I haven't really seen this as a python-3000 specific issue. Or are you > referring to the other cross-posting thread? That too, but at this point *any* feature request is a Py3k request. If it's not good for Py3k there's no point in having it in 2.6. And I'd like new functionality in 2.6 to be restricted to backported Py3k features. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Inspect Patch for IronPython (and Jython?) Compatibility
Guido van Rossum wrote: > Let's definitely add this to the trunk (2.6). It sounds fine to me as > a bugfix too, since (from your description) it doesn't change the > behavior at all in CPython. Great. It looks to me like the patch will apply fine against release25-maint. No behaviour change. Thanks Michael Foord > > I won't have the time to submit this, but I'm sure there are others > here who do. > > --Guido > > On 6/19/07, Michael Foord <[EMAIL PROTECTED]> wrote: >> Hello all, >> >> I've just submitted a patch on sourceforge to make inspect compatible >> with IronPython (and Jython I think). This patch originally comes from >> the IPCE ( http://fepy.sf.net ) project by Seo Sanghyeon. It is a >> trivial change really. >> >> The patch is number 1739696 >> http://sourceforge.net/tracker/index.php?func=detail&aid=1739696&group_id=5470&atid=305470 >> >> >> >> It moves getting a reference to 'code.co_code' into the body of the loop >> responsible for inspecting anonymous (tuple) arguments. >> >> In IronPython, accessing 'co_code' raises a NotImplementedError - >> meaning that inspect.get_argspec is broken. >> >> This patch means that *except* for functions with anonymous tuple >> arguments, it will work again on IronPython - whilst maintaining full >> compatibility with the previous behaviour. >> >> Jython has a similar patch to overcome the same issue by the way. See >> http://jython.svn.sourceforge.net/viewvc/jython?view=rev&revision=3200 >> >> As it is a bugfix - backporting to 2.5 would be great. Should I generate >> a separate patch? >> >> All the best, >> >> Michael Foord >> ___ >> Python-Dev mailing list >> [email protected] >> http://mail.python.org/mailman/listinfo/python-dev >> Unsubscribe: >> http://mail.python.org/mailman/options/python-dev/guido%40python.org >> > > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Python 3000 Status Update (Long!)
>> What would a registry of tranformation algorithms buy us compared to a >> module with transformation functions? > > Easier registering of custom transformations. Without a registry, you'd have > to monkey-patch a module. Or users would have to invoke the module directly. I think a convention would be enough: rot13.encode(foo) rot13.decode(bar) Then, "registration" would require to put the module on sys.path, which it would for any other kind of registry as well. My main objection to using an encoding is that for these, the algorithm name will *always* be a string literal, completely unlike "real" codecs, where the encoding name often comes from the environment (either from the process environment, or from some kind of input). Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
