[Python-ideas] Support floating-point values in collections.Counter

2017-12-18 Thread Joel Croteau
It would be useful in many scenarios for values in collections.Counter to
be allowed to be floating point. I know that Counter nominally emulates a
multiset, which would suggest only integer values, but in a more general
sense, it could be an accumulator of either floating point or integer data.
As near as I can tell, Collection already does support float values in both
Python 2.7 and 3.6, and the way the code is implemented, this change should
be a no-op. All that is required is to update the documentation to say
floating-point values are allowed, as it currently says only integers are
allowed.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/


Re: [Python-ideas] Repr of lambda

2017-12-18 Thread Steve Barnes


On 18/12/2017 11:43, Steven D'Aprano wrote:
> On Mon, Dec 18, 2017 at 07:54:17AM +, Steve Barnes wrote:
> 
>> Isn't this exactly the sort of information already available via
>> inspect.getardspec, inspect.getsourcelines & inspect.getsource?
> 
> [snip ipython interactive session showing that the answer is "Yes"]
> 
> You answered your own question: yes it is. What's your point? That's not
> a rhetorical question -- I genuinely don't understand why you raise
> this. Do you see the existence of inspect.* as negating the usefulness
> of giving functions a more useful repr? As proof that the information is
> available? Something else?
> 
> 

Hi Steve,

I see it as showing that the information is already available to anybody 
who needs it so I question the usefulness of changing repr (for 
everybody) which is bound to break something somewhere. Now if you were 
to suggest adding a verbose flag to repr or a print format, maybe both - 
so that people don't have to import inspect then I would say that you 
have a lot less chance of breaking any code/test cases that is in the wild.

Sorry I should have made my point(s) clearer.

-- 
Steve (Gadget) Barnes
Any opinions in this message are my personal opinions and do not reflect 
those of my employer.

---
This email has been checked for viruses by AVG.
http://www.avg.com

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/


Re: [Python-ideas] Repr of lambda

2017-12-18 Thread Ivan Levkivskyi
Serhiy,

I like the idea, but in typeshed we have an agreement to always show a
default value by an ellipsis.
For example, definition like this:

def fun(x, y, z=0):
return x + y + z

can be represented like this

fun(x, y, z=...)

or if one has annotations in the definition, then

fun(x: int, y: int, z: int = ...) -> int

So if you would make this change, I would prefer the existing "style".

--
Ivan
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/


Re: [Python-ideas] Repr of lambda

2017-12-18 Thread Steven D'Aprano
On Mon, Dec 18, 2017 at 07:54:17AM +, Steve Barnes wrote:

> Isn't this exactly the sort of information already available via 
> inspect.getardspec, inspect.getsourcelines & inspect.getsource?

[snip ipython interactive session showing that the answer is "Yes"]

You answered your own question: yes it is. What's your point? That's not 
a rhetorical question -- I genuinely don't understand why you raise 
this. Do you see the existence of inspect.* as negating the usefulness 
of giving functions a more useful repr? As proof that the information is 
available? Something else?


-- 
Steve
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/


Re: [Python-ideas] Repr of lambda

2017-12-18 Thread Steve Barnes


On 18/12/2017 06:11, Ivan Pozdeev via Python-ideas wrote:
> On 17.12.2017 22:20, Serhiy Storchaka wrote:
>> Currently repr of doesn't contain much of information besides that it 
>> is a lambda.
>>
>> >>> lambda x: x**2
>>  at 0x7f3479b74488>
>>
>> All lambdas have the same repr, different only by unreadable 
>> hexadecimal address.
>>
>> What if include the signature and the expression of the lambda in its 
>> repr?
>>
>> >>> lambda x: x**2
>> 
>>
> It's the same for named functions:
> 
>      In [1]: def ditto(a): return a
> 
>      In [2]: ditto
>      Out[2]: 
> 
> Are you intending to do the same for them?
>> This would return an old feature of Python 0.9.1 
>> (https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2Fdabeaz%2Fstatus%2F934835068043956224=02%7C01%7C%7C44a37122957d43015aa308d545de3321%7C84df9e7fe9f640afb435%7C1%7C0%7C636491742990321352=iAE6MDdsZJDHfUqlHlPjnf2XV%2BiRZ%2BrP%2FL%2BIQ8kKoKo%3D=0).
>>  
>>
>>
>> Repr of function could contain just the signature.
>>
>> 
>>
>> But there is a problem with default values. Their reprs can be very 
>> long, especially in the following case with mutable default value:
>>
>> def foo(x, _cache={}):
>>     try:
>>     return _cache[x]
>>     except KeyError:
>>     pass
>>     _cache[x] = y = expensive_calculation(x)
>>     return y
>>
>> Maybe the placeholder should be always used instead of default values.
>>
>> ___

Isn't this exactly the sort of information already available via 
inspect.getardspec, inspect.getsourcelines & inspect.getsource?

In [19]: import inspect

In [20]: l = lambda x: x**2

In [21]: inspect.getargspec(l)
Out[21]: ArgSpec(args=['x'], varargs=None, keywords=None, defaults=None)

In [22]: inspect.getsource(l)
Out[22]: u'l = lambda x: x**2\n'

In [23]:
 ...: def foo(x, _cache={}):
 ...: try:
 ...: return _cache[x]
 ...: except KeyError:
 ...: pass
 ...: _cache[x] = y = expensive_calculation(x)
 ...: return y
 ...:

In [24]: inspect.getargspec(foo)
Out[24]: ArgSpec(args=['x', '_cache'], varargs=None, keywords=None, 
defaults=({},))

In [25]: inspect.getsource(foo)
Out[25]: u'def foo(x, _cache={}):\ntry:\nreturn _cache[x]\n 
   except KeyError:\npass\n_cache[x] = y = 
expensive_calculation(x)\nreturn y \n'

In [26]: inspect.getsourcelines(foo)
Out[26]:
([u'def foo(x, _cache={}):\n',
   u'try:\n',
   u'return _cache[x]\n',
   u'except KeyError:\n',
   u'pass\n',
   u'_cache[x] = y = expensive_calculation(x)\n',
   u'return y \n'],
  2)



-- 
Steve (Gadget) Barnes
Any opinions in this message are my personal opinions and do not reflect 
those of my employer.

---
This email has been checked for viruses by AVG.
http://www.avg.com

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/


Re: [Python-ideas] Repr of lambda

2017-12-18 Thread Serhiy Storchaka

17.12.17 22:55, Terry Reedy пише:
What if include the signature and the expression of the lambda in its 
repr?


 >>> lambda x: x**2



Printing the return value requires adding a code or function attribute.


Yes, this requires adding an optional constant code attribute.

The return expression(s), possibly None, would be just as useful for 
named functions.


In case of named functions the body is not an expression and usually is 
multiline.


But there is a problem with default values. Their reprs can be very 
long, especially in the following case with mutable default value:


I would not expect the representation to change; just use the expression.


This is a solution, thanks.


Maybe the placeholder should be always used instead of default values.


Do you mean 'a placeholder'?


Yes, sorry.

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/