On Wed, Oct 31, 2018 at 02:25:25AM +0200, Serhiy Storchaka wrote:
> 31.10.18 01:44, Giampaolo Rodola' пише:
> >Sorry in advance if this has been proposed in the past but I couldn't
> >find anything on python-ideas:
> >
> > >>> l = []
> > >>> l.pop(default=1)
> >1
[...]
> It is just
>
> l.pop
31.10.18 01:44, Giampaolo Rodola' пише:
Sorry in advance if this has been proposed in the past but I couldn't
find anything on python-ideas:
>>> l = []
>>> l.pop(default=1)
1
FWIW my use case consists in reading entries from /proc/diskstats where
lines can have a variable number of fields d
On Wed, 31 Oct 2018 at 00:20, David Mertz wrote:
> Counter doesn't QUITE do the same thing as this `mdict`. But it's pretty
> close.
>
> I think if .__add__() became a synonym for .update() that wouldn't break
> anything that currently works. But I'm probably wrong, and missing a case
> in my q
Sorry in advance if this has been proposed in the past but I couldn't find
anything on python-ideas:
>>> l = []
>>> l.pop(default=1)
1
FWIW my use case consists in reading entries from /proc/diskstats where
lines can have a variable number of fields depending on the kernel version:
https://github
Actually, they are definitely different as in-place mutation versus
returning a new Counter. But in some arithmetic way they look mostly the
same.
On Tue, Oct 30, 2018, 7:19 PM David Mertz Counter doesn't QUITE do the same thing as this `mdict`. But it's pretty
> close.
>
> I think if .__add__()
Counter doesn't QUITE do the same thing as this `mdict`. But it's pretty
close.
I think if .__add__() became a synonym for .update() that wouldn't break
anything that currently works. But I'm probably wrong, and missing a case
in my quick thought:
>>> from collections import Counter
>>> c = Cou
> In [12]: a= mdict(a=[2], b='a')
> In [13]: a+a
Aren't you reinventing the Counter type?
>>> from collections import Counter
>>> c = Counter(a=1,b=2)
>>> c + c
Counter({'b': 4, 'a': 2})
___
Python-ideas mailing list
Python-ideas@python.org
https://mail
On Tue, 30 Oct 2018 at 22:33, Greg Ewing
wrote:
> julien tayon wrote:
> > like the + of [] could be the + of "RecordAlgebrae"
>
> If you're proposing to change the behaviour of '+' on the
> built-in list type, that's not going to happen.
>
> I dont suggest to change something that already exists
julien tayon wrote:
like the + of [] could be the + of "RecordAlgebrae"
If you're proposing to change the behaviour of '+' on the
built-in list type, that's not going to happen.
--
Greg
___
Python-ideas mailing list
Python-ideas@python.org
https://ma
Thanks robert for the praise. It feels nice.
I may be bold, but I really hate to come empty handed to a discussion. So
this lib is nothing more than doing my homework when I don't have a PhD.
Actually, science (in my opinion) is about measuring. What I propose is
nothing more than (if you add Vec
Julien, your article is very pleasant to read (and funny) but as other say
the mailing list is not there to share some articles, but for proposition
to the standard python library,
do our own lib on github and pypi first if you want to Share some code to
the world !
And if project becomes super u
> What are your opinions ?
> I don't actually see a lot of use case except it was funny to build. But
> maybe it can be of use.
This list is for suggesting additions and changes to python. Broad usefulness
is a prerequisite. So please build your lib but this seems off topic on this
list.
/ A
Hello :)
the idea is described here:http://jul.github.io/cv/pres.html#printable
Summary of the idea :
Take a linear algebrae book, and implements all the rules as a
TDD.https://github.com/jul/archery/blob/master/consistent_algebrae.py
make it works based on abstract base class and sets of
Mixin
Python's coroutines are designed to make suspension points visible, which
enhances "local reasoning" about code. This concept has been written up
very well over here: https://glyph.twistedmatrix.com/2014/02/unyielding.html
On Tue, Oct 30, 2018 at 8:37 AM Ron Reiter wrote:
> You are right that th
On Tue, Oct 30, 2018 at 11:36 PM Ron Reiter wrote:
>
> You are right that they are different, I was actually assuming that
> developers by default don't try to parallelize and would rather go ahead and
> write code to yield one function at a time, which is fine. The need to
> separate "await" f
You are right that they are different, I was actually assuming that
developers by default don't try to parallelize and would rather go ahead
and write code to yield one function at a time, which is fine. The need to
separate "await" from the invocation is something which is rarely used. Not
sure wh
Clarifications:
1. I miswrote part of my first post where I wrote "I want to test if
symbol found in __dict__ is an attribute or not in python code".
I meant to write "is a DESCRIPTOR" or not.
2. The example in https://docs.python.org/3/howto/descriptor.html for
reproducing `type.__getattribut
Frequently, while globbing, one needs to work with multiple extensions. I’d
like to propose for fnmatch.filter to handle a tuple of patterns (while
preserving the single str argument functionality, alas str.endswith), as a
first step for glob.i?glob to accept multiple patterns as well.
Here is the
On Tue, Oct 30, 2018 at 6:01 PM Ron Reiter wrote:
>
> ... most developers would always mean they prefer to do this:
>
> result = [await fun(x) for fun in funcs]
>
> versus:
>
> result = [fun(x) for fun in funcs]
> await asyncio.gather(*result)
>
> Moreso, having it become the default makes stateme
On Tue, Oct 30, 2018 at 04:40:40AM -0400, Joy Diamond wrote:
> """
> For classes, the machinery is in type.__getattribute__() which transforms
> B.x into B.__dict__['x'].__get__(None, B). In pure Python, it looks like:
>
> def __getattribute__(self, key):
> "Emulate type_getattro() in Objects
Ron Reiter wrote:
I feel like having the await syntax trigger by default on any awaitable
invocation in a coroutine context makes much more sense.
Guido seems to regard the requirement to use 'await' as a
feature, not a bug. He says he likes to be able to see where
all the potential suspension
Greetings,
I am trying to emulate attribute lookup, and want to test if symbol found
in __dict__ is an attribute or not in python code (i.e.: does its have a
`tp_descr_get` slot?)
Reading the documentation carefully, I am supposed to test if the attribute
has a `.__get__` method; however, I see n
One of Golang's advantages is that goroutines act like gevent's coroutines
instead of relying on an async/await syntax. In my opinion, it makes Golang
code much more readable.
I feel like having the await syntax trigger by default on any awaitable
invocation in a coroutine context makes much more
23 matches
Mail list logo