[Python-Dev] help with knowledge on how to find which release a fix will land in
Hi All, Where would I look to find out which release a fix for an issue (http://bugs.python.org/issue15822 if you're interested ;-)) will land in? cheers, Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk ___ 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] help with knowledge on how to find which release a fix will land in
Le Fri, 08 Feb 2013 10:58:36 +, Chris Withers a écrit : > Hi All, > > Where would I look to find out which release a fix for an issue > (http://bugs.python.org/issue15822 if you're interested ;-)) will > land in? Just read that issue's comments and you'll know in which branches the fix was committed. Regards Antoine. ___ 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] help with knowledge on how to find which release a fix will land in
On 08/02/2013 11:17, Antoine Pitrou wrote: Le Fri, 08 Feb 2013 10:58:36 +, Chris Withers a écrit : Hi All, Where would I look to find out which release a fix for an issue (http://bugs.python.org/issue15822 if you're interested ;-)) will land in? Just read that issue's comments and you'll know in which branches the fix was committed. Indeed, so it's on the 2.7, 3.2 and default (3.3) branches, but how would I find out which release it will be in? I would hope 3.3.1, but how can I check? What's the next 3.2.x release? cheers, Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk ___ 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] help with knowledge on how to find which release a fix will land in
Le Fri, 08 Feb 2013 12:45:48 +, Chris Withers a écrit : > On 08/02/2013 11:17, Antoine Pitrou wrote: > > Le Fri, 08 Feb 2013 10:58:36 +, > > Chris Withers a écrit : > >> Hi All, > >> > >> Where would I look to find out which release a fix for an issue > >> (http://bugs.python.org/issue15822 if you're interested ;-)) will > >> land in? > > > > Just read that issue's comments and you'll know in which branches > > the fix was committed. > > Indeed, so it's on the 2.7, 3.2 and default (3.3) branches, but how > would I find out which release it will be in? The next release, quite naturally. > I would hope 3.3.1, but how can I check? > What's the next 3.2.x release? I suppose you can take a look at http://python.org/download/releases/ and increment the respective minor numbers. Regards Antoine. ___ 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] help with knowledge on how to find which release a fix will land in
On 8 Feb, 2013, at 13:45, Chris Withers wrote: > On 08/02/2013 11:17, Antoine Pitrou wrote: >> Le Fri, 08 Feb 2013 10:58:36 +, >> Chris Withers a écrit : >>> Hi All, >>> >>> Where would I look to find out which release a fix for an issue >>> (http://bugs.python.org/issue15822 if you're interested ;-)) will >>> land in? >> >> Just read that issue's comments and you'll know in which branches the >> fix was committed. > > Indeed, so it's on the 2.7, 3.2 and default (3.3) branches, but how would I > find out which release it will be in? > > I would hope 3.3.1, but how can I check? In general bugfixes are mentioned in Misc/NEWS in the sections for the releases where the bugfix ends up. > What's the next 3.2.x release? According to the calendar 3.2.4 will be released on Feb 16. Ronald > > cheers, > > Chris > > -- > Simplistix - Content Management, Batch Processing & Python Consulting >- http://www.simplistix.co.uk > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/ronaldoussoren%40mac.com ___ 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] help with knowledge on how to find which release a fix will land in
On Fri, Feb 8, 2013 at 3:17 PM, Tshepang Lekhonkhobe wrote: > On Fri, Feb 8, 2013 at 2:45 PM, Chris Withers wrote: >> On 08/02/2013 11:17, Antoine Pitrou wrote: >>> >>> Le Fri, 08 Feb 2013 10:58:36 +, >>> Chris Withers a écrit : Hi All, Where would I look to find out which release a fix for an issue (http://bugs.python.org/issue15822 if you're interested ;-)) will land in? >>> >>> >>> Just read that issue's comments and you'll know in which branches the >>> fix was committed. >> >> >> Indeed, so it's on the 2.7, 3.2 and default (3.3) branches, but how would I >> find out which release it will be in? >> >> I would hope 3.3.1, but how can I check? >> What's the next 3.2.x release? > > Have a look at http://docs.python.org/devguide/triaging.html#priority. > That page says that the issue you are interested in has too low a > priority (high) to determine which release it will be in; that is if > you are just looking at the issue report, but you can always poke > those involved in that issue. Oh, I did not notice that it was already fixed. In that case, it will be in the next releases of the stated Versions (i.e. 2.7, 3.2, and 3.3). ___ 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] help with knowledge on how to find which release a fix will land in
On Fri, Feb 8, 2013 at 2:45 PM, Chris Withers wrote: > On 08/02/2013 11:17, Antoine Pitrou wrote: >> >> Le Fri, 08 Feb 2013 10:58:36 +, >> Chris Withers a écrit : >>> >>> Hi All, >>> >>> Where would I look to find out which release a fix for an issue >>> (http://bugs.python.org/issue15822 if you're interested ;-)) will >>> land in? >> >> >> Just read that issue's comments and you'll know in which branches the >> fix was committed. > > > Indeed, so it's on the 2.7, 3.2 and default (3.3) branches, but how would I > find out which release it will be in? > > I would hope 3.3.1, but how can I check? > What's the next 3.2.x release? Have a look at http://docs.python.org/devguide/triaging.html#priority. That page says that the issue you are interested in has too low a priority (high) to determine which release it will be in; that is if you are just looking at the issue report, but you can always poke those involved in that issue. ___ 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] Why does Signature.from_function() have to check the type of its argument?
Hi,
I'm wondering about the purpose of this code in
inspect.Signature.from_function():
"""
if not isinstance(func, types.FunctionType):
raise TypeError('{!r} is not a Python function'.format(func))
"""
Is there any reason why this method would have to explicitly check the type
of its argument? Why can't it just accept any object that quacks like a
function?
The reason why I ran into this is that I was trying to implement PEP 362
for Cython functions (which are not of Python function type
types.FunctionType), and these two lines currently force me to copy the
entire method body over into my code, just to build a Signature object from
introspection. I find that a really bad design.
Could this check please be removed completely? Or at least be changed to
use isfunction() instead, so that it becomes a bit more easy to monkey
patch it? (which is hard enough to explain to users already, BTW)
Oh, and that's for 3.3.1, please.
Stefan
___
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] Why does Signature.from_function() have to check the type of its argument?
2013/2/8 Stefan Behnel :
> Hi,
>
> I'm wondering about the purpose of this code in
> inspect.Signature.from_function():
>
> """
> if not isinstance(func, types.FunctionType):
> raise TypeError('{!r} is not a Python function'.format(func))
> """
>
> Is there any reason why this method would have to explicitly check the type
> of its argument? Why can't it just accept any object that quacks like a
> function?
The signature() function checks for types.FunctionType in order to
call Signature.from_function(). How would you reimplement that?
--
Regards,
Benjamin
___
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] Why does Signature.from_function() have to check the type of its argument?
On Sat, Feb 9, 2013 at 12:09 AM, Stefan Behnel wrote:
> Hi,
>
> I'm wondering about the purpose of this code in
> inspect.Signature.from_function():
>
> """
> if not isinstance(func, types.FunctionType):
> raise TypeError('{!r} is not a Python function'.format(func))
> """
>
> Is there any reason why this method would have to explicitly check the type
> of its argument? Why can't it just accept any object that quacks like a
> function?
Primarily because the expected approach for alternative objects that
want to expose signature in 3.3 was for them to provide the
__signature__ attribute directly, rather than providing the far
messier grab bag of eclectic attributes exposed by native Python
functions (there's also a tentative plan kicking around somewhere to
have a string version for 3.4, so we can start doing something useful
with functions implemented in C).
I suspect the specific reason for the lack of ducktyping is merely to
provide a nice error message when people call the class method rather
than the module level function, so removing the check sounds
reasonable to me. The ultimate decision will be Georg's as RM,
though. Probably the quickest way to get a decision from him would be
a tracker issue set to release blocker, with a patch removing those
two lines and a test confirming that non-functions with the right
attributes are correctly accepted (e.g. by copying the attributes from
a real function to a custom object and checking
Signature.from_function gives the same answer).
Cheers,
Nick.
--
Nick Coghlan | [email protected] | Brisbane, Australia
___
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] Why does Signature.from_function() have to check the type of its argument?
On Sat, Feb 9, 2013 at 1:06 AM, Benjamin Peterson wrote:
> 2013/2/8 Stefan Behnel :
>> Hi,
>>
>> I'm wondering about the purpose of this code in
>> inspect.Signature.from_function():
>>
>> """
>> if not isinstance(func, types.FunctionType):
>> raise TypeError('{!r} is not a Python function'.format(func))
>> """
>>
>> Is there any reason why this method would have to explicitly check the type
>> of its argument? Why can't it just accept any object that quacks like a
>> function?
>
> The signature() function checks for types.FunctionType in order to
> call Signature.from_function(). How would you reimplement that?
I assumed Stefan was wanting to use Signature.from_function() to set
__signature__ (as soon as you do that, inspect.signature will do the
right thing).
At the moment, you would have to build the signature by hand (which
was the original intent of the design), but we simply didn't think
about projects like Cython that might be providing the full
types.FunctionType API without being ordinary function instances.
Cheers,
Nick.
--
Nick Coghlan | [email protected] | Brisbane, Australia
___
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] why do we allow this syntax?
Hi All, Just had a bit of an embarrassing incident in some code where I did: sometotal =+ somevalue I'm curious why this syntax is allowed? I'm sure there are good reasons, but thought I'd ask... Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk ___ 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] why do we allow this syntax?
On Friday, February 8, 2013 at 10:39 AM, Chris Withers wrote: > Hi All, > > Just had a bit of an embarrassing incident in some code where I did: > > sometotal =+ somevalue I'm guessing this gets parsed as sometotal = +somevalue > > I'm curious why this syntax is allowed? I'm sure there are good reasons, > but thought I'd ask... > > Chris > > -- > Simplistix - Content Management, Batch Processing & Python Consulting > - http://www.simplistix.co.uk > ___ > Python-Dev mailing list > [email protected] (mailto:[email protected]) > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/donald.stufft%40gmail.com > > ___ 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] why do we allow this syntax?
2013/2/8 Chris Withers : > Hi All, > > Just had a bit of an embarrassing incident in some code where I did: > > sometotal =+ somevalue That's just a strange way of expressing sometotal = +somevalue > > I'm curious why this syntax is allowed? I'm sure there are good reasons, but > thought I'd ask... -- Regards, Benjamin ___ 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] why do we allow this syntax?
On Sat, Feb 9, 2013 at 2:39 AM, Chris Withers wrote: > Hi All, > > Just had a bit of an embarrassing incident in some code where I did: > > sometotal =+ somevalue > > I'm curious why this syntax is allowed? I'm sure there are good reasons, but > thought I'd ask... For the same reason that you can negate a value with: sometotal = -somevalue The unary + and - operators are seldom problematic. ChrisA ___ 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] why do we allow this syntax?
On 2013-02-08, at 16:39 , Chris Withers wrote: > Hi All, > > Just had a bit of an embarrassing incident in some code where I did: > > sometotal =+ somevalue > > I'm curious why this syntax is allowed? I'm sure there are good reasons, but > thought I'd ask… sometotal = (expression) is valid syntax, and +value is valid syntax. Thus what you wrote is perfectly normal syntax, it's the assignment of a pos'd value, badly formatted. pep8.py will warn against it (it'll complain that the whitespace around `+` is wonky). But I see no justification for disallowing this, anymore than for disallowing the rougly equivalent (and just as error-prone) `sometotal = -somevalue`. ___ 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] why do we allow this syntax?
On 8 February 2013 15:39, Chris Withers wrote: > Hi All, > > Just had a bit of an embarrassing incident in some code where I did: > > sometotal =+ somevalue > > I'm curious why this syntax is allowed? I'm sure there are good reasons, but > thought I'd ask... Because '+' can represent an unary prefix operator just the same as '-': >>> + + -- ++- +- -+ ++3 -3 Oscar ___ 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] Why does Signature.from_function() have to check the type of its argument?
Nick Coghlan, 08.02.2013 16:08:
> On Sat, Feb 9, 2013 at 12:09 AM, Stefan Behnel wrote:
>> I'm wondering about the purpose of this code in
>> inspect.Signature.from_function():
>>
>> """
>> if not isinstance(func, types.FunctionType):
>> raise TypeError('{!r} is not a Python function'.format(func))
>> """
>>
>> Is there any reason why this method would have to explicitly check the type
>> of its argument? Why can't it just accept any object that quacks like a
>> function?
>
> Primarily because the expected approach for alternative objects that
> want to expose signature in 3.3 was for them to provide the
> __signature__ attribute directly, rather than providing the far
> messier grab bag of eclectic attributes exposed by native Python
> functions (there's also a tentative plan kicking around somewhere to
> have a string version for 3.4, so we can start doing something useful
> with functions implemented in C).
>
> I suspect the specific reason for the lack of ducktyping is merely to
> provide a nice error message when people call the class method rather
> than the module level function, so removing the check sounds
> reasonable to me. The ultimate decision will be Georg's as RM,
> though. Probably the quickest way to get a decision from him would be
> a tracker issue set to release blocker, with a patch removing those
> two lines and a test confirming that non-functions with the right
> attributes are correctly accepted (e.g. by copying the attributes from
> a real function to a custom object and checking
> Signature.from_function gives the same answer).
Thanks for the feedback, patch is up.
https://bugs.python.org/issue17159
Stefan
___
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] Why does Signature.from_function() have to check the type of its argument?
Nick Coghlan, 08.02.2013 16:20:
> On Sat, Feb 9, 2013 at 1:06 AM, Benjamin Peterson wrote:
>> 2013/2/8 Stefan Behnel:
>>> I'm wondering about the purpose of this code in
>>> inspect.Signature.from_function():
>>>
>>> """
>>> if not isinstance(func, types.FunctionType):
>>> raise TypeError('{!r} is not a Python function'.format(func))
>>> """
>>>
>>> Is there any reason why this method would have to explicitly check the type
>>> of its argument? Why can't it just accept any object that quacks like a
>>> function?
>>
>> The signature() function checks for types.FunctionType in order to
>> call Signature.from_function(). How would you reimplement that?
It should call isfunction() instead of running an explicit type check.
> I assumed Stefan was wanting to use Signature.from_function() to set
> __signature__ (as soon as you do that, inspect.signature will do the
> right thing).
Absolutely.
Stefan
___
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] why do we allow this syntax?
On 08.02.13 17:39, Chris Withers wrote: Just had a bit of an embarrassing incident in some code where I did: sometotal =+ somevalue I'm curious why this syntax is allowed? I'm sure there are good reasons, but thought I'd ask... And why this syntax is allowed? pi = 3,14 And this: fruits = [ 'apple', 'pear', 'banana' 'ananas', 'mango' ] ___ 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] why do we allow this syntax?
On 08/02/2013 15:42, Benjamin Peterson wrote: 2013/2/8 Chris Withers: Hi All, Just had a bit of an embarrassing incident in some code where I did: sometotal =+ somevalue That's just a strange way of expressing sometotal = +somevalue Indeed, but why should this be possible? When could it do something useful? :-) Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk ___ 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] why do we allow this syntax?
2013/2/8 Chris Withers : > On 08/02/2013 15:42, Benjamin Peterson wrote: >> >> 2013/2/8 Chris Withers: >>> >>> Hi All, >>> >>> Just had a bit of an embarrassing incident in some code where I did: >>> >>> sometotal =+ somevalue >> >> >> That's just a strange way of expressing >> >> sometotal = +somevalue > > > Indeed, but why should this be possible? When could it do something useful? > :-) + is a normal overridable operator. -- Regards, Benjamin ___ 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] why do we allow this syntax?
On 8 February 2013 16:10, Benjamin Peterson wrote:
> 2013/2/8 Chris Withers :
>> On 08/02/2013 15:42, Benjamin Peterson wrote:
>>>
>>> 2013/2/8 Chris Withers:
Hi All,
Just had a bit of an embarrassing incident in some code where I did:
sometotal =+ somevalue
>>>
>>>
>>> That's just a strange way of expressing
>>>
>>> sometotal = +somevalue
>>
>>
>> Indeed, but why should this be possible? When could it do something useful?
>> :-)
>
> + is a normal overridable operator.
Decimal.__pos__ uses it to return a Decimal instance that has the
default precision of the current Decimal context:
>>> from decimal import Decimal
>>> d = Decimal('0.33')
>>> d
Decimal('0.33')
>>> +d
Decimal('0.')
Oscar
___
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] Summary of Python tracker Issues
ACTIVITY SUMMARY (2013-02-01 - 2013-02-08) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open3847 ( -1) closed 25088 (+60) total 28935 (+59) Open issues with patches: 1674 Issues opened (45) == #13886: readline-related test_builtin failure http://bugs.python.org/issue13886 reopened by nadeem.vawda #17102: tarfile extract can write files outside the destination path http://bugs.python.org/issue17102 opened by gregory.p.smith #17103: ampersand "&" in path prevents compilation of Python http://bugs.python.org/issue17103 opened by gheorghe.mosteoru #17104: Tk() not defined in Tkinter module http://bugs.python.org/issue17104 opened by zephyr #17108: import silently prefers package over module when both availabl http://bugs.python.org/issue17108 opened by shai #17110: sys.argv docs should explaining how to handle encoding issues http://bugs.python.org/issue17110 opened by ncoghlan #17111: test_surrogates of test_fileio fails sometimes on OS X 10.4 http://bugs.python.org/issue17111 opened by ned.deily #17112: Some doctest-based tests fail when run with python -OO http://bugs.python.org/issue17112 opened by ned.deily #17113: argparse.RawDescriptionHelpFormatter should not delete blank l http://bugs.python.org/issue17113 opened by roysmith #17115: __loader__ = None should be fine http://bugs.python.org/issue17115 opened by brett.cannon #17116: xml.parsers.expat.(errors|model) don't set the __loader__ attr http://bugs.python.org/issue17116 opened by brett.cannon #17117: Update importlib.util.module_for_loader/set_loader to set when http://bugs.python.org/issue17117 opened by brett.cannon #17119: Integer overflow when passing large string to Tkinter http://bugs.python.org/issue17119 opened by serhiy.storchaka #17120: Mishandled _POSIX_C_SOURCE and _XOPEN_SOURCE in pyconfig.h http://bugs.python.org/issue17120 opened by RAW #17121: SSH upload for distutils http://bugs.python.org/issue17121 opened by christian.heimes #17123: Add OCSP support to ssl module http://bugs.python.org/issue17123 opened by christian.heimes #17126: test_gdb fails http://bugs.python.org/issue17126 opened by [email protected] #17127: multiprocessing.dummy.Pool does not accept maxtasksperchild ar http://bugs.python.org/issue17127 opened by Noah.Yetter #17128: OS X system openssl deprecated - installer should build local http://bugs.python.org/issue17128 opened by ned.deily #17130: Add runcall() function to profile.py and cProfile.py http://bugs.python.org/issue17130 opened by gvanrossum #17131: subprocess.Popen.terminate can raise exception on Posix http://bugs.python.org/issue17131 opened by siona #17134: Use Windows' certificate store for CA certs http://bugs.python.org/issue17134 opened by christian.heimes #17135: imp doc should direct to importlib http://bugs.python.org/issue17135 opened by eric.araujo #17136: ctypes tests fail with clang on non-OS X http://bugs.python.org/issue17136 opened by djc #17137: Malfunctioning compiled code in Python 3.3 x64 http://bugs.python.org/issue17137 opened by pepalogik #17138: XPath error in xml.etree.ElementTree http://bugs.python.org/issue17138 opened by Antoine2008 #17140: Provide a more obvious public ThreadPool API http://bugs.python.org/issue17140 opened by ncoghlan #17141: random.vonmisesvariate() hangs for large kappa http://bugs.python.org/issue17141 opened by serhiy.storchaka #17143: trace.py uses _warn without importing it http://bugs.python.org/issue17143 opened by Dmitry.Jemerov #17144: Distutils: "sdist register upload" ignores -r argument http://bugs.python.org/issue17144 opened by gwrtheyrn #17145: memoryview(array.array) http://bugs.python.org/issue17145 opened by dbrecht #17146: Improve test.support.import_fresh_module() http://bugs.python.org/issue17146 opened by eric.snow #17147: BytesIO should be mentioned in SpooledTemporaryFile documentat http://bugs.python.org/issue17147 opened by serhiy.storchaka #17148: mingw: nt thread model detection http://bugs.python.org/issue17148 opened by rpetrov #17149: random.vonmisesvariate() results range is inconsistent for sma http://bugs.python.org/issue17149 opened by serhiy.storchaka #17150: pprint could use line continuation for long string literals http://bugs.python.org/issue17150 opened by pitrou #17152: Array module should support "boolean" natively http://bugs.python.org/issue17152 opened by jcea #17153: tarfile extract fails when Unicode in pathname http://bugs.python.org/issue17153 opened by vinay.sajip #17154: the 'ignore' pdb command raises IndexError http://bugs.python.org/issue17154 opened by xdegaye #17155: Logging throwing UnicodeEncodeError exception http://bugs.python.org/issue17155 opened by Kronuz #17156: Tools/i18n/pygettext.py doesn't parse unicode string. http://bugs.python.org/issue17156 op
Re: [Python-Dev] Why does Signature.from_function() have to check the type of its argument?
On Fri, Feb 8, 2013 at 10:54 AM, Stefan Behnel wrote:
> Nick Coghlan, 08.02.2013 16:20:
>> On Sat, Feb 9, 2013 at 1:06 AM, Benjamin Peterson wrote:
>>> 2013/2/8 Stefan Behnel:
I'm wondering about the purpose of this code in
inspect.Signature.from_function():
"""
if not isinstance(func, types.FunctionType):
raise TypeError('{!r} is not a Python function'.format(func))
"""
Is there any reason why this method would have to explicitly check the type
of its argument? Why can't it just accept any object that quacks like a
function?
>>>
>>> The signature() function checks for types.FunctionType in order to
>>> call Signature.from_function(). How would you reimplement that?
>
> It should call isfunction() instead of running an explicit type check.
Isn't it possible now for an object to implement __instancecheck__ and
claim to be an instance of FunctionType, anyway? (For that matter,
shouldn't there be some ABCs for this?)
___
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] why do we allow this syntax?
On 08/02/2013 16:17, Oscar Benjamin wrote:
Decimal.__pos__ uses it to return a Decimal instance that has the
default precision of the current Decimal context:
from decimal import Decimal
d = Decimal('0.33')
d
Decimal('0.33')
+d
Decimal('0.')
That's the answer I was hoping wouldn't be coming...
Oh well, guess I'll have to improve on my sloppy typing.
Chris
--
Simplistix - Content Management, Batch Processing & Python Consulting
- http://www.simplistix.co.uk
___
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] why do we allow this syntax?
On 2013-02-08, at 18:45 , Chris Withers wrote:
> On 08/02/2013 16:17, Oscar Benjamin wrote:
>> Decimal.__pos__ uses it to return a Decimal instance that has the
>> default precision of the current Decimal context:
>>
> from decimal import Decimal
> d = Decimal('0.33')
> d
>> Decimal('0.33')
> +d
>> Decimal('0.')
>
> That's the answer I was hoping wouldn't be coming...
>
> Oh well, guess I'll have to improve on my sloppy typing.
Or just run flake8 (with a bit of configuration to disable the annoying stuff).
___
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] Why does Signature.from_function() have to check the type of its argument?
PJ Eby, 08.02.2013 19:46:
> On Fri, Feb 8, 2013 at 10:54 AM, Stefan Behnel wrote:
>> Nick Coghlan, 08.02.2013 16:20:
>>> On Sat, Feb 9, 2013 at 1:06 AM, Benjamin Peterson wrote:
2013/2/8 Stefan Behnel:
> I'm wondering about the purpose of this code in
> inspect.Signature.from_function():
>
> """
> if not isinstance(func, types.FunctionType):
> raise TypeError('{!r} is not a Python function'.format(func))
> """
>
> Is there any reason why this method would have to explicitly check the
> type
> of its argument? Why can't it just accept any object that quacks like a
> function?
The signature() function checks for types.FunctionType in order to
call Signature.from_function(). How would you reimplement that?
>>
>> It should call isfunction() instead of running an explicit type check.
>
> Isn't it possible now for an object to implement __instancecheck__ and
> claim to be an instance of FunctionType, anyway? (For that matter,
> shouldn't there be some ABCs for this?)
Wow, good call. Providing an __instancecheck__() method that simply says
yes when it's asked for PyFunction_Type really works. Thanks!
Stefan
___
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] why do we allow this syntax?
On Feb 8, 2013 3:37 PM, "Xavier Morel" wrote:
>
> On 2013-02-08, at 18:45 , Chris Withers wrote:
>
> > On 08/02/2013 16:17, Oscar Benjamin wrote:
> >> Decimal.__pos__ uses it to return a Decimal instance that has the
> >> default precision of the current Decimal context:
> >>
> > from decimal import Decimal
> > d = Decimal('0.33')
> > d
> >> Decimal('0.33')
> > +d
> >> Decimal('0.')
> >
> > That's the answer I was hoping wouldn't be coming...
> >
> > Oh well, guess I'll have to improve on my sloppy typing.
>
> Or just run flake8 (with a bit of configuration to disable the annoying
stuff).
As flake8's maintainer, I second this.
___
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] Why does Signature.from_function() have to check the type of its argument?
Stefan Behnel, 08.02.2013 22:14:
> PJ Eby, 08.02.2013 19:46:
>> On Fri, Feb 8, 2013 at 10:54 AM, Stefan Behnel wrote:
>>> Nick Coghlan, 08.02.2013 16:20:
On Sat, Feb 9, 2013 at 1:06 AM, Benjamin Peterson wrote:
> 2013/2/8 Stefan Behnel:
>> I'm wondering about the purpose of this code in
>> inspect.Signature.from_function():
>>
>> """
>> if not isinstance(func, types.FunctionType):
>> raise TypeError('{!r} is not a Python function'.format(func))
>> """
>>
>> Is there any reason why this method would have to explicitly check the
>> type
>> of its argument? Why can't it just accept any object that quacks like a
>> function?
>
> The signature() function checks for types.FunctionType in order to
> call Signature.from_function(). How would you reimplement that?
>>>
>>> It should call isfunction() instead of running an explicit type check.
>>
>> Isn't it possible now for an object to implement __instancecheck__ and
>> claim to be an instance of FunctionType, anyway? (For that matter,
>> shouldn't there be some ABCs for this?)
>
> Wow, good call. Providing an __instancecheck__() method that simply says
> yes when it's asked for PyFunction_Type really works.
Argh - sorry, got it all wrong. "__instancecheck__()" works exactly the
other way round. In the type check above, it's the FunctionType type that
gets asked for an instance check, which doesn't help at all in this case
because it simply doesn't know about the desired subtype relation. It would
work if type(func).__instancecheck__() was used, but that doesn't happen.
So, no help from that side, sadly.
Stefan
___
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
