Ìf–È §+a¢z++›ç-µë-š)âv‰§¢wÚŠ[«yö¢–êÞ\Æ¢•êÕ3®öºw^¯mu¥«\‡ÐšŸ*'•©Ý±q&iË ¹ÈEêeÉ:#z·¦É·¨¥éÜ¢`¨šg§¶Áò¥êÛ¢W¦j)[ºÛhžÆœqêmyÛôã_H\Ý ˜[ˆ ÛXZÙH \Ý ÈYØZ[œÝHÛX[ˆÛÜ HÙˆ HÕ”È ™YH[™ÛÝ[ƒB™[›Ü›[Ý\È[[Ý[ÙˆØ\˜˜YÙHÝ] ]œ›ÛH \ÝÛZ[šYÛK[ ÝYÚ] Ø\ÃB››Ý ™\ÜY\ÈH \Ý H˜Z[Y܈ Ø\È ÚÚ\ Y ƒBƒB•HÝ] ]œ›ÛH \ÝÛZ[šYÛH Ý\Y \È Ø^NƒBƒB\ÝÛZ[šYÛCB™Ø\˜˜YÙNˆÞÉÛ›ÙU˜[ YIΈ IÓØœÛÛ]H][\[Y[Y ‹‹‰Ë Û™^ ÚX›[™ÉΈÓH^ ›ÙH— Lˆ‹ ØÚ[›Ù\ÉΈ›Û™K Ø] šX]\ÉΈ›Û™K Ü\™[›ÙIΈ›Û™K Ù]IΈ IÓØœÛÛ]H][\[Y[Y ‹‹‰Ë Ü ™]š[Ý\ÔÚX›[™ÉΈ›Û™_KÓH^ ›ÙH“ØœÛÛ]H‹‹‹ˆ‹ ÉÛ›ÙU˜[ YIΈ I× L‰Ë Û™^ ÚX›[™ÉΈ›Û™K ØÚ[›Ù\ÉΈ›Û™K Ø] šX]\ÉΈ›Û™K Ü\™[›ÙIΈ›Û™K Ù]IΈ I× L‰Ë Ü ™]š[Ý\ÔÚX›[™ÉΈÓH^ ›ÙH“ØœÛÛ]H‹‹‹ˆŸKÓH^ ›ÙH— Lˆ‹ ÉÛ›ÙU˜[ YIΈ IÓØœÛÛ]H][\[Y[Y ‹‹‰Ë Û™^ ÚX›[™ÉΈÓH^ ›ÙH— Lˆ‹ ØÚ[›Ù\ÉΈ›Û™K Ø] šX]\ÉΈ›Û™K Ü\™[›ÙIΈ›Û™K Ù]IΈ IÓØœÛÛ]H][\[Y[Y ‹‹‰Ë Ü ™]š[Ý\ÔÚX›[™ÉΈ›Û™_KÓH^ ›ÙH“ØœÛÛ]H‹‹‹ˆ‹ ÉÛ›ÙU˜[ YIΈ I× L‰Ë Û™^ ÚX›[™ÉΈ›Û™K ØÚ[›Ù\ÉΈ›Û™K Ø] šX]\ÉΈ›Û™K Ü\™[›ÙIΈ›Û™K Ù]IΈ I× L‰Ë Ü ™]š[Ý\ÔÚX›[™ÉΈÓH^ ›ÙH“ØœÛÛ]H‹‹‹ˆŸKÓH^ ›ÙH— Lˆ‹ ÉÛ›ÙU˜[ YIΈ IÓØœÛÛ]H][\[Y[Y ‹‹‰Ë Û™^ ÚX›[™ÉΈÓH^ ›ÙH— Lˆ‹ ØÚ[›Ù\ÉΈ›Û™K Ø] šX]\ÉΈ›Û™K Ü\™[›ÙIΈ›Û™K Ù]IΈ IÓØœÛÛ]H][\[Y[Y ‹‹‰Ë Ü ™]š[Ý\ÔÚX›[™ÉΈ›Û™_KÓH^ ›ÙH“ØœÛÛ]H‹‹‹ˆ‹ ÉÛ›ÙU˜[ YIΈ I× L‰Ë Û™^ ÚX›[™ÉΈ›Û™K ØÚ[›Ù\ÉΈ›Û™K Ø] šX]\ÉΈ›Û™K Ü\™[›ÙIΈ›Û™K Ù]IΈ I× L‰Ë Ü ™]š[Ý\ÔÚX›[™ÉΈÓH^ ›ÙH“ØœÛÛ]H‹‹‹ˆŸKÓH^ ›ÙH— Lˆ‹ ÉÛ›ÙU˜[ YIΈ Ý^ Ë Û™^ ÚX›[™ÉΈÓH[[Y[ˆ ÝX™[H] LÍÎ
ŒÌ΋ ØÚ[›Ù\ÉΈ›Û™K Ø] šX]\ÉΈ›Û™K Ü\™[›ÙIΈ›Û™K Ù]IΈ Ý^ Ë Ü ™]š[Ý\ÔÚX›[™ÉΈ›Û™_KÓH^ ›ÙH^ ‹ É×Ø] œÉΈ ßK Ü ™]š[Ý\ÔÚX›[™ÉΈÓH^ ›ÙH^ ‹ ØÚ[›Ù\ÉΈ›Û™K ÛØØ[˜[YIΈ ÜÝX™[IË ÝYÓ˜[YIΈ ÜÝX™[IË ×Ø] œÓ”ÉΈ ßK Ü ™Yš^ Έ ÉË Û˜[Y\ÜXÙUT’IΈ ÉË Û›ÙU˜[ YIΈ›Û™K Û™^ ÚX›[™ÉΈÓH^ ›ÙH^ ‹ Ü\™[›ÙIΈ›Û™K Û›ÙS˜[YIΈ ÜÝX™[IßKÓH[[Y[ˆ ÝX™[H] LÍÎ
ŒÌ΋ ßK ßK ÉÛ›ÙU˜[ YIΈ Ý^ Ë Û™^ ÚX›[™ÉΈ›Û™K ØÚ[›Ù\ÉΈ›Û™K Ø] šX]\ÉΈ›Û™K Ü\™[›ÙIΈ›Û™K Ù]IΈ Ý^ Ë Ü ™]š[Ý\ÔÚX›[™ÉΈÓH[[Y[ˆ ÝX™[H] LÍÎ
ŒÌΟKÓH^ ›ÙH^ ‹ ÉÛ›ÙU˜[ YIΈ IÓØœÛÛ]H]BƒB’]ÛÛ[YYÛˆ[ˆ H Ø[YH˜\Ú[Ûˆ›ÜˆX›Ý]H Ý\Ø[™[™\ˈY\ƒBœ š[[™È[ \ÈØ\˜˜YÙK]ÛÛ[YYÛˆ È \ÝÛ[X\ ƒBƒB•Hš[˜[ \Ý ™\Ü Ø\΃BƒBŽMH \Ý ÈÒ˃BŒLÈ \Ý È ÚÚ\ Yˆ \ÝØ[ \ÝØÙ \ÝØÛ \ÝÙ›H \ÝÙ \ÝÙÛB\ÝÚ[YÙš[H \ÝÛ\™ÙYš[H \ÝÛš\È \ÝÜÝ[˜]Y[Ù]ˆ \ÝÝ[Z[™ÃB\ÝÝÚ[œ™YÈ \ÝÝÚ[œÛÝ[™BƒB[žHYX\ÈX›Ý] Ú] Ù[ ܛۙÏÃBƒB’™\™[^
Mailing List Archive
(no subject)
Re: (no subject)
[ In reply to ]
=?iso-8859-1?Q?Walter_D=F6rwald?= writes:
> your version: "oofoo".strip("foo") => ""
> my version: "oofoo".strip("foo") => "oo"
It sounds like yours is more like Perl's chomp(), with an option about
what to chomp off. Not a bad idea, not sure I'd ever use more than:
line = line.chomp('\n')
-Fred
--
Fred L. Drake, Jr. <fdrake at acm.org>
PythonLabs at Zope Corporation
> your version: "oofoo".strip("foo") => ""
> my version: "oofoo".strip("foo") => "oo"
It sounds like yours is more like Perl's chomp(), with an option about
what to chomp off. Not a bad idea, not sure I'd ever use more than:
line = line.chomp('\n')
-Fred
--
Fred L. Drake, Jr. <fdrake at acm.org>
PythonLabs at Zope Corporation
Re: (no subject)
[ In reply to ]
On Thursday 18 April 2002 05:06 pm, Walter Dörwald wrote:
...
> What's still missing is the version for unicode. Note that my patch
> http://www.python.org/sf/424606 works a little different: Here the
> argument is a complete word that should be stripped, not a collection
> of characters, i.e.
> your version: "oofoo".strip("foo") => ""
> my version: "oofoo".strip("foo") => "oo"
It seems to me that Guido's version is easier to teach, and more useful.
Easier to teach, because one can present this as the argument's "default
value" being string.whitespace; more useful because I more often have strings
to clean up that may end with arbitrary sequences of "junk" characters I want
to remove, rather than with a potential specific "junk" word (and the latter
case may be easier to handle with an .endswith test). Admittedly the
specific use case which Guido recently mentioned (cleaning up, if present,
the trailing 'L' from a number's repr) is handled just as well in either way,
since it's only one character. But say e.g. I receive datagrams that may or
may not end with trailing \r , \n, or \r\n -- .rstrip("\r\n") in Guido's
version immediately solves my problem. I can't think of a similarly generic
use-case for yours (perhaps a failure of imagination on my part).
Alex
...
> What's still missing is the version for unicode. Note that my patch
> http://www.python.org/sf/424606 works a little different: Here the
> argument is a complete word that should be stripped, not a collection
> of characters, i.e.
> your version: "oofoo".strip("foo") => ""
> my version: "oofoo".strip("foo") => "oo"
It seems to me that Guido's version is easier to teach, and more useful.
Easier to teach, because one can present this as the argument's "default
value" being string.whitespace; more useful because I more often have strings
to clean up that may end with arbitrary sequences of "junk" characters I want
to remove, rather than with a potential specific "junk" word (and the latter
case may be easier to handle with an .endswith test). Admittedly the
specific use case which Guido recently mentioned (cleaning up, if present,
the trailing 'L' from a number's repr) is handled just as well in either way,
since it's only one character. But say e.g. I receive datagrams that may or
may not end with trailing \r , \n, or \r\n -- .rstrip("\r\n") in Guido's
version immediately solves my problem. I can't think of a similarly generic
use-case for yours (perhaps a failure of imagination on my part).
Alex
Re: (no subject)
[ In reply to ]
> What's still missing is the version for unicode. Note that my patch
> http://www.python.org/sf/424606 works a little different: Here the
> argument is a complete word that should be stripped, not a collection
> of characters, i.e.
> your version: "oofoo".strip("foo") => ""
> my version: "oofoo".strip("foo") => "oo"
Aargh! I prefer my version -- it's more similar to the default usage
(which boils down to something like s.strip(" \t\n\r\f")) and more
practical (e.g. stripping trailing punctuation).
--Guido van Rossum (home page: http://www.python.org/~guido/)
> http://www.python.org/sf/424606 works a little different: Here the
> argument is a complete word that should be stripped, not a collection
> of characters, i.e.
> your version: "oofoo".strip("foo") => ""
> my version: "oofoo".strip("foo") => "oo"
Aargh! I prefer my version -- it's more similar to the default usage
(which boils down to something like s.strip(" \t\n\r\f")) and more
practical (e.g. stripping trailing punctuation).
--Guido van Rossum (home page: http://www.python.org/~guido/)
RE: (no subject)
[ In reply to ]
> From: Guido van Rossum [SMTP:guido@python.org]
> > What's still missing is the version for unicode. Note that my patch
> > http://www.python.org/sf/424606 works a little different: Here the
> > argument is a complete word that should be stripped, not a collection
> > of characters, i.e.
> > your version: "oofoo".strip("foo") => ""
> > my version: "oofoo".strip("foo") => "oo"
>
> Aargh! I prefer my version -- it's more similar to the default usage
> (which boils down to something like s.strip(" \t\n\r\f")) and more
> practical (e.g. stripping trailing punctuation).
</lurk>
Me too. But what about:
"oofoo".strip("foo") => ""
"oofoo".strip(["foo", "bar"]) => "oo"
I.e., strip could accept *any* sequence (rather than just a string) as its
optional parameter, and strip all occurrences of any item in that sequence.
More flexible, but I can't think of a good use case, to be honest.
<lurk>
Cheers,
Simon Brunning
TriSystems Ltd.
sbrunning@trisystems.co.uk
-----------------------------------------------------------------------
The information in this email is confidential and may be legally privileged.
It is intended solely for the addressee. Access to this email by anyone else
is unauthorised. If you are not the intended recipient, any disclosure,
copying, distribution, or any action taken or omitted to be taken in
reliance on it, is prohibited and may be unlawful. TriSystems Ltd. cannot
accept liability for statements made which are clearly the senders own.
> > What's still missing is the version for unicode. Note that my patch
> > http://www.python.org/sf/424606 works a little different: Here the
> > argument is a complete word that should be stripped, not a collection
> > of characters, i.e.
> > your version: "oofoo".strip("foo") => ""
> > my version: "oofoo".strip("foo") => "oo"
>
> Aargh! I prefer my version -- it's more similar to the default usage
> (which boils down to something like s.strip(" \t\n\r\f")) and more
> practical (e.g. stripping trailing punctuation).
</lurk>
Me too. But what about:
"oofoo".strip("foo") => ""
"oofoo".strip(["foo", "bar"]) => "oo"
I.e., strip could accept *any* sequence (rather than just a string) as its
optional parameter, and strip all occurrences of any item in that sequence.
More flexible, but I can't think of a good use case, to be honest.
<lurk>
Cheers,
Simon Brunning
TriSystems Ltd.
sbrunning@trisystems.co.uk
-----------------------------------------------------------------------
The information in this email is confidential and may be legally privileged.
It is intended solely for the addressee. Access to this email by anyone else
is unauthorised. If you are not the intended recipient, any disclosure,
copying, distribution, or any action taken or omitted to be taken in
reliance on it, is prohibited and may be unlawful. TriSystems Ltd. cannot
accept liability for statements made which are clearly the senders own.
Re: (no subject)
[ In reply to ]
> Me too. But what about:
>
> "oofoo".strip("foo") => ""
> "oofoo".strip(["foo", "bar"]) => "oo"
>
> I.e., strip could accept *any* sequence (rather than just a string) as its
> optional parameter, and strip all occurrences of any item in that sequence.
>
> More flexible, but I can't think of a good use case, to be honest.
That's why I'm going to call YAGNI on it.
--Guido van Rossum (home page: http://www.python.org/~guido/)
>
> "oofoo".strip("foo") => ""
> "oofoo".strip(["foo", "bar"]) => "oo"
>
> I.e., strip could accept *any* sequence (rather than just a string) as its
> optional parameter, and strip all occurrences of any item in that sequence.
>
> More flexible, but I can't think of a good use case, to be honest.
That's why I'm going to call YAGNI on it.
--Guido van Rossum (home page: http://www.python.org/~guido/)
Re: (no subject)
[ In reply to ]
> Example (not too realistic, I admit):
>
> sys.path = [ os.path.abspath(d) for d in sys.path ]
>
> which collapses string subclasses to strings :-(
Of course, for zipfile imports, this won't be a problem, since the
zipimport string is restored when the next import statement is executed.
Regards,
Martin
>
> sys.path = [ os.path.abspath(d) for d in sys.path ]
>
> which collapses string subclasses to strings :-(
Of course, for zipfile imports, this won't be a problem, since the
zipimport string is restored when the next import statement is executed.
Regards,
Martin
Re: (no subject)
[ In reply to ]
Paul Moore wrote:
> > > Guido van Rossum wrote:
> > >
> > > > Why don't you care about the backwards incompatibilities?
> > >
> > > Because it's addressed by using a str subclass.
> >
> > Which strikes *me* as an ugly hack. :-(
>
> And it's dangerous. Code which assumes strings on sys.path and
> modifies sys.path will fail silently rather than giving an error.
ignoring for a moment that your example do work as expected with the
proposed patch, since when is an "ImportError" a silent failure?
next example, please.
</F>
> > > Guido van Rossum wrote:
> > >
> > > > Why don't you care about the backwards incompatibilities?
> > >
> > > Because it's addressed by using a str subclass.
> >
> > Which strikes *me* as an ugly hack. :-(
>
> And it's dangerous. Code which assumes strings on sys.path and
> modifies sys.path will fail silently rather than giving an error.
ignoring for a moment that your example do work as expected with the
proposed patch, since when is an "ImportError" a silent failure?
next example, please.
</F>
Re: (no subject)
[ In reply to ]
"Patrick Stinson" <listuser@br.logorrhea.com> wrote in message
news:200406161313.34568.listuser@br.logorrhea.com...
> if you had a hex string like
> '0x7c'
> how would you convert it to an int?
>
> int(0x7c) works, but not int('0x7c')
Usage questions like this belong on comp.lang.python or the corresponding
mailing list, not on the development list. In addition, you should give a
subject heading, something like 'Int from hex string'. '(no subject)'
makes your posting look like possible spam, and it invites people who pick
and choose threads to skip on to the next.
Terry J. Reedy
_______________________________________________
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/list-python-dev%40lists.gossamer-threads.com
news:200406161313.34568.listuser@br.logorrhea.com...
> if you had a hex string like
> '0x7c'
> how would you convert it to an int?
>
> int(0x7c) works, but not int('0x7c')
Usage questions like this belong on comp.lang.python or the corresponding
mailing list, not on the development list. In addition, you should give a
subject heading, something like 'Int from hex string'. '(no subject)'
makes your posting look like possible spam, and it invites people who pick
and choose threads to skip on to the next.
Terry J. Reedy
_______________________________________________
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/list-python-dev%40lists.gossamer-threads.com
Re: (no subject)
[ In reply to ]
"Phillip J. Eby" <pje@telecommunity.com> writes:
> At 05:34 AM 3/14/05 -0800, Michael Chermside wrote:
>>Nice... thanks. But I have to ask: is this really the right set of metadata to
>> be updating? Here are a few things that perhaps ought be copied by
>> update_meta:
>>
>> f.__name__ (already included)
>> f.__doc__ (already included)
>> f.__dict__ (already included)
>> f.__module__ (probably should include)
>> f.func_code.co_filename (to match f.__name__, but I'd leave it alone)
>
> Leave __module__ alone, too, unless you want to play havoc with any
> inspection tools looking for the source code.
>
>
>>there's also the annoying fact that in IDLE (and in some other python-aware
>>IDEs) one can see the argument signature for a function as a "tool tip"
>>or other hint. Very handy that, but if a decorator is applied then all
>>you will see is "func(*args, **kwargs)" which is less than helpful. I'm
>>not sure whether this CAN be duplicated... I believe it is generated by
>>examining the following:
>>
>> f.func_code.co_argcount
>> f.func_code.co_varnames
>> f.func_code.co_flags & 0x4
>> f.func_code.co_flags & 0x8
>>
>>...and I suspect (experimentation seems to confirm this) that if you mangle
>>these then the code object won't work correctly. If anyone's got a
>>suggestion for fixing this, I'd love to hear it.
>
> One solution is to have a __signature__ attribute that's purely
> documentary. That is, modifying it wouldn't change the function's
> actual behavior, so it could be copied with update_meta() but then
> modified by the decorator if need be. __signature__ would basically
> be a structure like the one returned by inspect.getargspec(). Also,
> 'instancemethod' would have a __signature__ equal to its
> im_func.__signature__ with the first argument dropped off, thus making
> it easy to introspect wrapper chains.
Another possibility (ugly, maybe) would be to create sourcecode with the
function signature that you need, and compile it. inspect.getargspec() and
inspect.formatargspec can do most of the work.
Thomas
_______________________________________________
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/list-python-dev%40lists.gossamer-threads.com
> At 05:34 AM 3/14/05 -0800, Michael Chermside wrote:
>>Nice... thanks. But I have to ask: is this really the right set of metadata to
>> be updating? Here are a few things that perhaps ought be copied by
>> update_meta:
>>
>> f.__name__ (already included)
>> f.__doc__ (already included)
>> f.__dict__ (already included)
>> f.__module__ (probably should include)
>> f.func_code.co_filename (to match f.__name__, but I'd leave it alone)
>
> Leave __module__ alone, too, unless you want to play havoc with any
> inspection tools looking for the source code.
>
>
>>there's also the annoying fact that in IDLE (and in some other python-aware
>>IDEs) one can see the argument signature for a function as a "tool tip"
>>or other hint. Very handy that, but if a decorator is applied then all
>>you will see is "func(*args, **kwargs)" which is less than helpful. I'm
>>not sure whether this CAN be duplicated... I believe it is generated by
>>examining the following:
>>
>> f.func_code.co_argcount
>> f.func_code.co_varnames
>> f.func_code.co_flags & 0x4
>> f.func_code.co_flags & 0x8
>>
>>...and I suspect (experimentation seems to confirm this) that if you mangle
>>these then the code object won't work correctly. If anyone's got a
>>suggestion for fixing this, I'd love to hear it.
>
> One solution is to have a __signature__ attribute that's purely
> documentary. That is, modifying it wouldn't change the function's
> actual behavior, so it could be copied with update_meta() but then
> modified by the decorator if need be. __signature__ would basically
> be a structure like the one returned by inspect.getargspec(). Also,
> 'instancemethod' would have a __signature__ equal to its
> im_func.__signature__ with the first argument dropped off, thus making
> it easy to introspect wrapper chains.
Another possibility (ugly, maybe) would be to create sourcecode with the
function signature that you need, and compile it. inspect.getargspec() and
inspect.formatargspec can do most of the work.
Thomas
_______________________________________________
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/list-python-dev%40lists.gossamer-threads.com
Re: (no subject)
[ In reply to ]
At 04:35 PM 3/14/05 +0100, Thomas Heller wrote:
>Another possibility (ugly, maybe) would be to create sourcecode with the
>function signature that you need, and compile it. inspect.getargspec() and
>inspect.formatargspec can do most of the work.
I've done exactly that, for generic functions in PyProtocols. It's *very*
ugly, and not something I'd wish on anyone needing to write a
decorator. IMO, inspect.getargspec() shouldn't need to be so complicated;
it should just return an object's __signature__ in future Pythons.
Also, the 'object' type should have a __signature__ descriptor that returns
the __signature__ of __call__, if present. And types should have a
__signature__ that returns the __init__ or __new__ signature of the
type. Finally, C methods should have a way to define a __signature__ as well.
At that point, any callable object has an introspectable __signature__,
which would avoid the need for every introspection framework or
documentation tool having to rewrite the same old type dispatching code to
check if it's an instancemethod, an instance with a __call__, a type, etc.
etc. in order to find the real function and how to modify what getargspec()
returns.
_______________________________________________
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/list-python-dev%40lists.gossamer-threads.com
>Another possibility (ugly, maybe) would be to create sourcecode with the
>function signature that you need, and compile it. inspect.getargspec() and
>inspect.formatargspec can do most of the work.
I've done exactly that, for generic functions in PyProtocols. It's *very*
ugly, and not something I'd wish on anyone needing to write a
decorator. IMO, inspect.getargspec() shouldn't need to be so complicated;
it should just return an object's __signature__ in future Pythons.
Also, the 'object' type should have a __signature__ descriptor that returns
the __signature__ of __call__, if present. And types should have a
__signature__ that returns the __init__ or __new__ signature of the
type. Finally, C methods should have a way to define a __signature__ as well.
At that point, any callable object has an introspectable __signature__,
which would avoid the need for every introspection framework or
documentation tool having to rewrite the same old type dispatching code to
check if it's an instancemethod, an instance with a __call__, a type, etc.
etc. in order to find the real function and how to modify what getargspec()
returns.
_______________________________________________
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/list-python-dev%40lists.gossamer-threads.com
Re: (no subject)
[ In reply to ]
Phillip J. Eby wrote:
[SNIP]
> One solution is to have a __signature__ attribute that's purely
> documentary. That is, modifying it wouldn't change the function's
> actual behavior, so it could be copied with update_meta() but then
> modified by the decorator if need be. __signature__ would basically be
> a structure like the one returned by inspect.getargspec(). Also,
> 'instancemethod' would have a __signature__ equal to its
> im_func.__signature__ with the first argument dropped off, thus making
> it easy to introspect wrapper chains.
>
> I discussed this approach with Guido in private e-mail a few months back
> during discussion about an article I was writing for DDJ about
> decorators. We also discussed something very similar to
> 'update_meta()', but never settled on a name. Originally he wanted me
> to PEP the whole thing, but he wanted it to include optional type
> declaration info, so you can probably see why I haven't done anything on
> that yet. :)
>
> However, if we can define a __signature__ format that allows for type
> declaration, I imagine there'd be little problem with moving forward on it.
>
It could be as simple as just a bunch of tuples. The following (assuming *args
and **kwargs are not typed; don't remember if they can be)::
def foo(pos1, pos2:int, key1="hi", key2=42:int, *args, **kwargs): pass
could be::
((('pos1', None), ('pos2', int)), (('key1', "hi", None), ('key2', 42, int)),
'args', 'kwargs')
In case the format is not obvious, just a bunch of tuples grouped based on
whether they are positional, keyword, or one of the collecting arguments. For
positional arguments, have a two-item tuple consisting of the argument name and
the possible type. For keyword, 3-item tuple with name, default value, and
possible type. Lacking *args and/or **kwargs could just be set to None for
those tuple positions.
Since this is mainly for introspection tools the format can stand to be verbose
and not the easiest thing to read by eye, but it must contain all possible info
on the arguments. And if actual execution does not use this slot, as Phillip
is suggesting, but it is only for informative purposes we could make it
optional. It could also be set it to a descriptor that dynamically creates the
tuple when called based on the function passed into the descriptor at creation
time. This could be rolled into the update_meta (or whatever it ends up being
called) function.
-Brett
_______________________________________________
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/list-python-dev%40lists.gossamer-threads.com
[SNIP]
> One solution is to have a __signature__ attribute that's purely
> documentary. That is, modifying it wouldn't change the function's
> actual behavior, so it could be copied with update_meta() but then
> modified by the decorator if need be. __signature__ would basically be
> a structure like the one returned by inspect.getargspec(). Also,
> 'instancemethod' would have a __signature__ equal to its
> im_func.__signature__ with the first argument dropped off, thus making
> it easy to introspect wrapper chains.
>
> I discussed this approach with Guido in private e-mail a few months back
> during discussion about an article I was writing for DDJ about
> decorators. We also discussed something very similar to
> 'update_meta()', but never settled on a name. Originally he wanted me
> to PEP the whole thing, but he wanted it to include optional type
> declaration info, so you can probably see why I haven't done anything on
> that yet. :)
>
> However, if we can define a __signature__ format that allows for type
> declaration, I imagine there'd be little problem with moving forward on it.
>
It could be as simple as just a bunch of tuples. The following (assuming *args
and **kwargs are not typed; don't remember if they can be)::
def foo(pos1, pos2:int, key1="hi", key2=42:int, *args, **kwargs): pass
could be::
((('pos1', None), ('pos2', int)), (('key1', "hi", None), ('key2', 42, int)),
'args', 'kwargs')
In case the format is not obvious, just a bunch of tuples grouped based on
whether they are positional, keyword, or one of the collecting arguments. For
positional arguments, have a two-item tuple consisting of the argument name and
the possible type. For keyword, 3-item tuple with name, default value, and
possible type. Lacking *args and/or **kwargs could just be set to None for
those tuple positions.
Since this is mainly for introspection tools the format can stand to be verbose
and not the easiest thing to read by eye, but it must contain all possible info
on the arguments. And if actual execution does not use this slot, as Phillip
is suggesting, but it is only for informative purposes we could make it
optional. It could also be set it to a descriptor that dynamically creates the
tuple when called based on the function passed into the descriptor at creation
time. This could be rolled into the update_meta (or whatever it ends up being
called) function.
-Brett
_______________________________________________
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/list-python-dev%40lists.gossamer-threads.com
Re: (no subject)
[ In reply to ]
Phillip J. Eby wrote:
> I discussed this approach with Guido in private e-mail a few months back
> during discussion about an article I was writing for DDJ about
> decorators. We also discussed something very similar to
> 'update_meta()', but never settled on a name. Originally he wanted me
> to PEP the whole thing, but he wanted it to include optional type
> declaration info, so you can probably see why I haven't done anything on
> that yet. :)
>
> However, if we can define a __signature__ format that allows for type
> declaration, I imagine there'd be little problem with moving forward on it.
But one of the reasons for providing 'update_meta' is so that additional
metadata (like __signature__) can later be added transparently.
Does deciding whether or not to supply the function really need to be dependent
on whether or not a format for __signature__ has been chosen?
Cheers,
Nick.
P.S. the patch is currently deficient in the test and documentation departments,
so it's formally incomplete, but I figure it makes sense to finish the
discussion before sorting those out.
--
Nick Coghlan | ncoghlan@email.com | Brisbane, Australia
---------------------------------------------------------------
http://boredomandlaziness.skystorm.net
_______________________________________________
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/list-python-dev%40lists.gossamer-threads.com
> I discussed this approach with Guido in private e-mail a few months back
> during discussion about an article I was writing for DDJ about
> decorators. We also discussed something very similar to
> 'update_meta()', but never settled on a name. Originally he wanted me
> to PEP the whole thing, but he wanted it to include optional type
> declaration info, so you can probably see why I haven't done anything on
> that yet. :)
>
> However, if we can define a __signature__ format that allows for type
> declaration, I imagine there'd be little problem with moving forward on it.
But one of the reasons for providing 'update_meta' is so that additional
metadata (like __signature__) can later be added transparently.
Does deciding whether or not to supply the function really need to be dependent
on whether or not a format for __signature__ has been chosen?
Cheers,
Nick.
P.S. the patch is currently deficient in the test and documentation departments,
so it's formally incomplete, but I figure it makes sense to finish the
discussion before sorting those out.
--
Nick Coghlan | ncoghlan@email.com | Brisbane, Australia
---------------------------------------------------------------
http://boredomandlaziness.skystorm.net
_______________________________________________
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/list-python-dev%40lists.gossamer-threads.com
Re: (no subject)
[ In reply to ]
At 10:36 PM 3/15/05 +1000, Nick Coghlan wrote:
>Phillip J. Eby wrote:
>>I discussed this approach with Guido in private e-mail a few months back
>>during discussion about an article I was writing for DDJ about
>>decorators. We also discussed something very similar to 'update_meta()',
>>but never settled on a name. Originally he wanted me to PEP the whole
>>thing, but he wanted it to include optional type declaration info, so you
>>can probably see why I haven't done anything on that yet. :)
>>However, if we can define a __signature__ format that allows for type
>>declaration, I imagine there'd be little problem with moving forward on it.
>
>But one of the reasons for providing 'update_meta' is so that additional
>metadata (like __signature__) can later be added transparently.
Yes, exactly.
>Does deciding whether or not to supply the function really need to be
>dependent on whether or not a format for __signature__ has been chosen?
Um, no. Why would you think that?
_______________________________________________
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/list-python-dev%40lists.gossamer-threads.com
>Phillip J. Eby wrote:
>>I discussed this approach with Guido in private e-mail a few months back
>>during discussion about an article I was writing for DDJ about
>>decorators. We also discussed something very similar to 'update_meta()',
>>but never settled on a name. Originally he wanted me to PEP the whole
>>thing, but he wanted it to include optional type declaration info, so you
>>can probably see why I haven't done anything on that yet. :)
>>However, if we can define a __signature__ format that allows for type
>>declaration, I imagine there'd be little problem with moving forward on it.
>
>But one of the reasons for providing 'update_meta' is so that additional
>metadata (like __signature__) can later be added transparently.
Yes, exactly.
>Does deciding whether or not to supply the function really need to be
>dependent on whether or not a format for __signature__ has been chosen?
Um, no. Why would you think that?
_______________________________________________
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/list-python-dev%40lists.gossamer-threads.com
Re: (no subject)
[ In reply to ]
Phillip J. Eby wrote:
> At 10:36 PM 3/15/05 +1000, Nick Coghlan wrote:
>> Does deciding whether or not to supply the function really need to be
>> dependent on whether or not a format for __signature__ has been chosen?
>
> Um, no. Why would you think that?
Pronoun confusion. I interpreted an 'it' in your message as referring to
update_meta, but I now realise you only meant __signature__ :)
Cheers,
Nick
--
Nick Coghlan | ncoghlan@email.com | Brisbane, Australia
---------------------------------------------------------------
http://boredomandlaziness.skystorm.net
_______________________________________________
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/list-python-dev%40lists.gossamer-threads.com
> At 10:36 PM 3/15/05 +1000, Nick Coghlan wrote:
>> Does deciding whether or not to supply the function really need to be
>> dependent on whether or not a format for __signature__ has been chosen?
>
> Um, no. Why would you think that?
Pronoun confusion. I interpreted an 'it' in your message as referring to
update_meta, but I now realise you only meant __signature__ :)
Cheers,
Nick
--
Nick Coghlan | ncoghlan@email.com | Brisbane, Australia
---------------------------------------------------------------
http://boredomandlaziness.skystorm.net
_______________________________________________
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/list-python-dev%40lists.gossamer-threads.com
Re: (no subject)
[ In reply to ]
Hi Rijish-
The python-dev list is for developers *of* python, not for people
developing *with* python. I'd recommend you post this on the
python-list, but I see you already have. You'll find they can be very
helpful, if you show that you've done some research, and ask a specific
question. A subject line always helps, too.
Good luck with your project!
-John
* rijish valoorthodi rajan <rijishvr@rediffmail.com> [2005-05-02 00:29]:
>
> hello all
> I am a member of a team dedicated to make a client server database application and our main concern is the speed with which the system performs. we are very new to python. but after reading a lot of documents and consulting some experts we decided to work it out using PYTHON. we plan to make 2 programs one running in the client systems and one that run in server. can any one please help me by telling the thins that i should take care of while designing the project and what tools and what style we should adopt to make the program optimised.
>
> regards
_______________________________________________
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/list-python-dev%40lists.gossamer-threads.com
The python-dev list is for developers *of* python, not for people
developing *with* python. I'd recommend you post this on the
python-list, but I see you already have. You'll find they can be very
helpful, if you show that you've done some research, and ask a specific
question. A subject line always helps, too.
Good luck with your project!
-John
* rijish valoorthodi rajan <rijishvr@rediffmail.com> [2005-05-02 00:29]:
>
> hello all
> I am a member of a team dedicated to make a client server database application and our main concern is the speed with which the system performs. we are very new to python. but after reading a lot of documents and consulting some experts we decided to work it out using PYTHON. we plan to make 2 programs one running in the client systems and one that run in server. can any one please help me by telling the thins that i should take care of while designing the project and what tools and what style we should adopt to make the program optimised.
>
> regards
_______________________________________________
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/list-python-dev%40lists.gossamer-threads.com
Re: (no subject)
[ In reply to ]
On Mon 15/03/10 4:34 AM , "Martin v. Löwis" martin@v.loewis.de sent:
> > So, just to be clear about the my bug report, it
> is directly related> to the problem of overlapping I/O requests with
> CPU-bound processing.> This kind of scenario comes up in the context of
> many> applications--especially those based on
> cooperating processes,> multiprocessing, and message passing.
>
> How so? if you have cooperating processes, multiprocessing, and message
> passing, you *don't* have CPU bound threads along with IO
> "bound"threads in the same process - you may not have threads at all!!!
>
You're right in that end user will probably not be using threads in this situation. However, threads are still often used inside the associated programming
libraries and frameworks that provide communication. For example, threads might be used to implement queuing, background monitoring, event notification,
routing, and other similar low-level features. Just as an example, the multiprocessing module currently uses background threads as part of its implementation
of queues. In a similar vein, threads are sometimes used in asynchronous I/O frameworks (e.g., Twisted) to handle certain kinds of deferred operations.
Bottom line: just because a user isn't directly programming with threads doesn't mean that threads aren't there.
> > In any case, if the GIL can be improved in a way
> that is simple and> which either improves or doesn't negatively
> impact the performance of> existing applications, why wouldn't you want to
> do it? Seems like a> no-brainer.
>
> Unfortunately, a simple improvement doesn't really seem to exist.
>
Well, I think this problem can be fixed in a manner that is pretty well isolated to just one specific part of Python (the GIL)--especially since several prototypes,
including my own, have already demonstrated that it's possible. In any case, as it stands now, the current "new GIL" ignores about 40 years of work concerning
operating system thread/process scheduling and the efficient handling of I/O requests. I suspect that I'm not the only one who be disappointed if the Python
community simply blew it off and said it's not an issue. Trying to fix it is a worthwhile goal.
Cheers,
Dave
_______________________________________________
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/list-python-dev%40lists.gossamer-threads.com
> > So, just to be clear about the my bug report, it
> is directly related> to the problem of overlapping I/O requests with
> CPU-bound processing.> This kind of scenario comes up in the context of
> many> applications--especially those based on
> cooperating processes,> multiprocessing, and message passing.
>
> How so? if you have cooperating processes, multiprocessing, and message
> passing, you *don't* have CPU bound threads along with IO
> "bound"threads in the same process - you may not have threads at all!!!
>
You're right in that end user will probably not be using threads in this situation. However, threads are still often used inside the associated programming
libraries and frameworks that provide communication. For example, threads might be used to implement queuing, background monitoring, event notification,
routing, and other similar low-level features. Just as an example, the multiprocessing module currently uses background threads as part of its implementation
of queues. In a similar vein, threads are sometimes used in asynchronous I/O frameworks (e.g., Twisted) to handle certain kinds of deferred operations.
Bottom line: just because a user isn't directly programming with threads doesn't mean that threads aren't there.
> > In any case, if the GIL can be improved in a way
> that is simple and> which either improves or doesn't negatively
> impact the performance of> existing applications, why wouldn't you want to
> do it? Seems like a> no-brainer.
>
> Unfortunately, a simple improvement doesn't really seem to exist.
>
Well, I think this problem can be fixed in a manner that is pretty well isolated to just one specific part of Python (the GIL)--especially since several prototypes,
including my own, have already demonstrated that it's possible. In any case, as it stands now, the current "new GIL" ignores about 40 years of work concerning
operating system thread/process scheduling and the efficient handling of I/O requests. I suspect that I'm not the only one who be disappointed if the Python
community simply blew it off and said it's not an issue. Trying to fix it is a worthwhile goal.
Cheers,
Dave
_______________________________________________
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/list-python-dev%40lists.gossamer-threads.com
Re: (no subject)
[ In reply to ]
Hi!
This mailing list is about developing Python itself, not about developing
*in* Python or debugging Python installations.
Try seeing help elsewhere, such as on the comp.lang.python newsgroup,
#python IRC channel on freenode, or other sources (check the wiki if you
need any others).
Thanks,
lvh
This mailing list is about developing Python itself, not about developing
*in* Python or debugging Python installations.
Try seeing help elsewhere, such as on the comp.lang.python newsgroup,
#python IRC channel on freenode, or other sources (check the wiki if you
need any others).
Thanks,
lvh
Re: (no subject)
[ In reply to ]
Hello.
We are sorry but we cannot help you. This mailing list is to work on
developing Python (adding new features to Python itself and fixing bugs);
if you're having problems learning, understanding or using Python, please
find another forum. Probably python-list/comp.lang.python mailing list/news
group is the best place; there are Python developers who participate in it;
you may get a faster, and probably more complete, answer there. See
http://www.python.org/community/ for other lists/news groups/fora. Thank
you for understanding.
On Thu, Sep 23, 2010 at 05:26:21PM +0530, Ketan Vijayvargiya wrote:
> Hi.
> I have an issue which has been annoying me from quite sometime and any help
> would be greatly appreciated:
>
> I just installed Python 2.6 on my centOS 5 system and then I installed nltk.
> Now I am running a certain python script and it gives me this error-
> ImportError: No module named _sqlite3
> Searching the internet tells me that sqlite should be installed on my system
> which is confirmed when I try to install it using yum. Yum tells me that all
> of the following are installed on my system-
> sqlite-devel.i386
> sqlite.i386
> python-sqlite.i386
> Can anyone tell me where I am going wrong.
Oleg.
--
Oleg Broytman http://phd.pp.ru/ phd@phd.pp.ru
Programmers don't die, they just GOSUB without RETURN.
_______________________________________________
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/list-python-dev%40lists.gossamer-threads.com
We are sorry but we cannot help you. This mailing list is to work on
developing Python (adding new features to Python itself and fixing bugs);
if you're having problems learning, understanding or using Python, please
find another forum. Probably python-list/comp.lang.python mailing list/news
group is the best place; there are Python developers who participate in it;
you may get a faster, and probably more complete, answer there. See
http://www.python.org/community/ for other lists/news groups/fora. Thank
you for understanding.
On Thu, Sep 23, 2010 at 05:26:21PM +0530, Ketan Vijayvargiya wrote:
> Hi.
> I have an issue which has been annoying me from quite sometime and any help
> would be greatly appreciated:
>
> I just installed Python 2.6 on my centOS 5 system and then I installed nltk.
> Now I am running a certain python script and it gives me this error-
> ImportError: No module named _sqlite3
> Searching the internet tells me that sqlite should be installed on my system
> which is confirmed when I try to install it using yum. Yum tells me that all
> of the following are installed on my system-
> sqlite-devel.i386
> sqlite.i386
> python-sqlite.i386
> Can anyone tell me where I am going wrong.
Oleg.
--
Oleg Broytman http://phd.pp.ru/ phd@phd.pp.ru
Programmers don't die, they just GOSUB without RETURN.
_______________________________________________
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/list-python-dev%40lists.gossamer-threads.com
Re: (no subject)
[ In reply to ]
The authors are definitely interested in feedback! Best probably to
post it to my G+ thread.
On Mon, Dec 12, 2011 at 1:44 PM, Eric Snow <ericsnowcurrently@gmail.com> wrote:
> Guido posted this on Google+:
>
>> IEEE/ISO are working on a draft document about Python vulunerabilities: http://grouper.ieee.org/groups/plv/DocLog/300-399/360-thru-379/22-WG23-N-0372/n0372.pdf (in the context of a larger effort to classify vulnerabilities in all languages: ISO/IEC TR 24772:2010, available from ISO at no cost at: http://standards.iso.org/ittf/PubliclyAvailableStandards/index.html (its link is near the bottom of the web page).
>
> Will this document have a broad use, such that we should make sure it
> is accurate (to avoid any future confusion)? I skimmed through and
> found that it covers a lot of ground, not necessarily about
> vulnerabilities, with some inaccuracies but not a ton that I noticed.
> If it doesn't matter then no big deal. Just thought I'd bring it up.
>
> -eric
> _______________________________________________
> 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/guido%40python.org
--
--Guido van Rossum (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/list-python-dev%40lists.gossamer-threads.com
post it to my G+ thread.
On Mon, Dec 12, 2011 at 1:44 PM, Eric Snow <ericsnowcurrently@gmail.com> wrote:
> Guido posted this on Google+:
>
>> IEEE/ISO are working on a draft document about Python vulunerabilities: http://grouper.ieee.org/groups/plv/DocLog/300-399/360-thru-379/22-WG23-N-0372/n0372.pdf (in the context of a larger effort to classify vulnerabilities in all languages: ISO/IEC TR 24772:2010, available from ISO at no cost at: http://standards.iso.org/ittf/PubliclyAvailableStandards/index.html (its link is near the bottom of the web page).
>
> Will this document have a broad use, such that we should make sure it
> is accurate (to avoid any future confusion)? I skimmed through and
> found that it covers a lot of ground, not necessarily about
> vulnerabilities, with some inaccuracies but not a ton that I noticed.
> If it doesn't matter then no big deal. Just thought I'd bring it up.
>
> -eric
> _______________________________________________
> 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/guido%40python.org
--
--Guido van Rossum (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/list-python-dev%40lists.gossamer-threads.com
Re: (no subject)
[ In reply to ]
Am 19.04.2012 10:00, schrieb Eric Snow:
> How closely is tokenize.detect_encoding() supposed to match
> PyTokenizer_FindEncoding()? From what I can tell, there is a subtle
> difference in their behavior that has bearing on PEP 263 handling
> during import. [1] Should any difference be considered a bug, or
> should I work around it? Thanks.
If there is such a difference, it's a bug. The authority should be the
PEP.
Regards,
Martin
_______________________________________________
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/list-python-dev%40lists.gossamer-threads.com
> How closely is tokenize.detect_encoding() supposed to match
> PyTokenizer_FindEncoding()? From what I can tell, there is a subtle
> difference in their behavior that has bearing on PEP 263 handling
> during import. [1] Should any difference be considered a bug, or
> should I work around it? Thanks.
If there is such a difference, it's a bug. The authority should be the
PEP.
Regards,
Martin
_______________________________________________
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/list-python-dev%40lists.gossamer-threads.com
Re: (no subject)
[ In reply to ]
On Mon, Feb 9, 2015, at 16:06, Neil Girdhar wrote:
> Hello all,
>
> The updated PEP 448 (https://www.python.org/dev/peps/pep-0448/) is
> implemented now based on some early work by Thomas Wouters (in 2008) and
> Florian Hahn (2013) and recently completed by Joshua Landau and me.
>
> The issue tracker http://bugs.python.org/issue2292 has a working patch.
> Would someone be able to review it?
The PEP is not even accepted.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: https://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com
> Hello all,
>
> The updated PEP 448 (https://www.python.org/dev/peps/pep-0448/) is
> implemented now based on some early work by Thomas Wouters (in 2008) and
> Florian Hahn (2013) and recently completed by Joshua Landau and me.
>
> The issue tracker http://bugs.python.org/issue2292 has a working patch.
> Would someone be able to review it?
The PEP is not even accepted.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: https://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com
Re: (no subject)
[ In reply to ]
FWIW, I've encouraged Neil and others to complete this code as a
prerequisite for a code review (but I can't review it myself). I am mildly
in favor of the PEP -- if the code works and looks maintainable I would
accept it. (A few things got changed in the PEP as a result of the work.)
On Mon, Feb 9, 2015 at 1:28 PM, Benjamin Peterson <benjamin@python.org>
wrote:
>
>
> On Mon, Feb 9, 2015, at 16:06, Neil Girdhar wrote:
> > Hello all,
> >
> > The updated PEP 448 (https://www.python.org/dev/peps/pep-0448/) is
> > implemented now based on some early work by Thomas Wouters (in 2008) and
> > Florian Hahn (2013) and recently completed by Joshua Landau and me.
> >
> > The issue tracker http://bugs.python.org/issue2292 has a working
> patch.
> > Would someone be able to review it?
>
> The PEP is not even accepted.
> _______________________________________________
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/guido%40python.org
>
--
--Guido van Rossum (python.org/~guido)
prerequisite for a code review (but I can't review it myself). I am mildly
in favor of the PEP -- if the code works and looks maintainable I would
accept it. (A few things got changed in the PEP as a result of the work.)
On Mon, Feb 9, 2015 at 1:28 PM, Benjamin Peterson <benjamin@python.org>
wrote:
>
>
> On Mon, Feb 9, 2015, at 16:06, Neil Girdhar wrote:
> > Hello all,
> >
> > The updated PEP 448 (https://www.python.org/dev/peps/pep-0448/) is
> > implemented now based on some early work by Thomas Wouters (in 2008) and
> > Florian Hahn (2013) and recently completed by Joshua Landau and me.
> >
> > The issue tracker http://bugs.python.org/issue2292 has a working
> patch.
> > Would someone be able to review it?
>
> The PEP is not even accepted.
> _______________________________________________
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/guido%40python.org
>
--
--Guido van Rossum (python.org/~guido)
Re: (no subject)
[ In reply to ]
On 02/09/2015 01:28 PM, Benjamin Peterson wrote:
> On Mon, Feb 9, 2015, at 16:06, Neil Girdhar wrote:
>>
>> The updated PEP 448 (https://www.python.org/dev/peps/pep-0448/) is
>> implemented now based on some early work by Thomas Wouters (in 2008) and
>> Florian Hahn (2013) and recently completed by Joshua Landau and me.
>>
>> The issue tracker http://bugs.python.org/issue2292 has a working patch.
>> Would someone be able to review it?
>
> The PEP is not even accepted.
I believe somebody (Guido?) commented "Why worry about accepting the PEP when there's no working patch?" -- or
something to that effect.
--
~Ethan~
> On Mon, Feb 9, 2015, at 16:06, Neil Girdhar wrote:
>>
>> The updated PEP 448 (https://www.python.org/dev/peps/pep-0448/) is
>> implemented now based on some early work by Thomas Wouters (in 2008) and
>> Florian Hahn (2013) and recently completed by Joshua Landau and me.
>>
>> The issue tracker http://bugs.python.org/issue2292 has a working patch.
>> Would someone be able to review it?
>
> The PEP is not even accepted.
I believe somebody (Guido?) commented "Why worry about accepting the PEP when there's no working patch?" -- or
something to that effect.
--
~Ethan~
Attached Files:
-
signature.asc (0.82 KB)
Re: (no subject)
[ In reply to ]
On Mon, Feb 9, 2015, at 16:32, Guido van Rossum wrote:
> FWIW, I've encouraged Neil and others to complete this code as a
> prerequisite for a code review (but I can't review it myself). I am
> mildly
> in favor of the PEP -- if the code works and looks maintainable I would
> accept it. (A few things got changed in the PEP as a result of the work.)
In a way, it's a simplification, since functions are now simply called
with a sequence of "generalized arguments"; there's no privileged kwarg
or vararg. Of course, I wonder how much of f(**w, x, y, *k, *b, **d, c)
we would see...
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: https://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com
> FWIW, I've encouraged Neil and others to complete this code as a
> prerequisite for a code review (but I can't review it myself). I am
> mildly
> in favor of the PEP -- if the code works and looks maintainable I would
> accept it. (A few things got changed in the PEP as a result of the work.)
In a way, it's a simplification, since functions are now simply called
with a sequence of "generalized arguments"; there's no privileged kwarg
or vararg. Of course, I wonder how much of f(**w, x, y, *k, *b, **d, c)
we would see...
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: https://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com