If we're bike shedding, I'd go for "mutableobject". It's not terribly
short, but it is built on familiar python terminology and does exactly what
it says in the box: like object() but mutable
On Wed, 17 Feb 2021, 23:01 Chris Angelico, wrote:
> On Thu, Feb 18, 2021 at 8:53 AM Brendan Barnwell
>
I'm not sure if you're reading the right document, but PEP 634 refers to
636 in its second paragraph
On Tue, 4 May 2021, 19:56 Shreyan Avigyan,
wrote:
> Ok. Now I'm able to understand. PEP 634 should have a reference to PEP 636
> or else it's pretty hard to understand because the syntax section
ns that if you want to restart discussion, reviving
>> PEP 316 is likely the best approach.
>>
>> Paul
>> ___
>> Python-ideas mailing list
>> Python-ideas@python.org
>> https://mail.python.org/mailman/lis
Sorry, should have replied to the list too
On Sat, 3 Nov 2018, 23:55 Daniel Moisset If I understood correctly what you want, it's possible with a metaclass.
> Check the __prepare__ method at
> https://docs.python.org/3/reference/datamodel.html#preparing-the-class-namespace
> and P
urn result
>
> """
>
> With:
>
> """
> def __new__(cls, name, bases, classdict):
>
> result = type.__new__(cls, name, bases, classdict)
> result.member_names = classdict.member_names
> return result
>
> """
>
> Rem
I think a solution nobody has proposed in this thread is relaxing the next
builtin, so it calls iter() on the argument when it doesn't implement the
iterator protocol. That would make next([1, 2]) == 1, and also make next([],
"missing") == "missing". After that all that is needed is educating the
u
This idea is something I could have used many times. I agree with many
people here that the strict=True API is at least "unusual" in Python. I was
thinking of 2 different API approaches that could be used for this and I
think no one has mentioned:
- we could add a callable filler_factory keywo
If you find PEP-634 a bit dry, you might give a try to PEP-636 (written in
an explanatory style rather than a hard-spec style). You can always go back
to PEP-634 for the precise details.
On Fri, 23 Oct 2020 at 13:48, Ricky Teachey wrote:
> Fwiw, although I see how PEP 634 has the potential to be
For the likely rare situation where I'd want to do this rather than
refactoring into a function, I might try with something like this without
requiring changes to the language:
from contextlib import contextmanager
@contextmanager
def breakable():
class Break(Exception): pass
def breaker(
Both this discussion, PEP 505, and the one a year ago, tend to mix up 2
related but separate proposals:
w
(A) Add a None-coalescing operator (like C# a ?? b, what you would write in
Python as "a or b" if it didn't have the falsy gotcha)
(B) Add some None-aware navigation operators ( The "?.", "?()"
Something else that may look confusing can be a break statement; in a
for i in range(5) for j in range(5) for k in range(5):
...
break
does it break the inner "k" loop, going to the next "j" (as it would happen
with 3 nested loops), or does it end the whole for statement? Similar
question w
On 17 October 2016 at 21:22, Random832 wrote:
>
> No, it's not.
>
> For a more concrete example:
>
> [*range(x) for x in range(4)]
> [*(),*(0,),*(0,1),*(0,1,2)]
> [0, 0, 1, 0, 1, 2]
>
> There is simply no way to get there by using flatten(range(4)).
the equivalent flatten for that is:
flatten(r
On 12 November 2016 at 17:01, Gary Godfrey wrote:
> Hi,
>
> This is a little more readable, but still a bit ugly. What I'm proposing
> here is:
>
> mydf = df[ w'field1 field2 field3' ]
>
> This would be identical in all ways (compile-time) to:
>
> mydf = df[ ('field1', 'field2', 'field3') ]
>
Hi Terry, the functionality you have provided is already covered by the
random.uniform function
On 2 February 2017 at 12:01, wrote:
> Hi, my name is Terry, and I’d like to propose a small function that could
> be added into the Python’s “random” module.
>
>
>
> This function is for generating a
Just as a reference, I think the most recent reincarnation of this thread
was:
https://mail.python.org/pipermail/python-ideas/2016-September/042270.html
On 23 February 2017 at 13:46, Paul Moore wrote:
> On 23 February 2017 at 13:37, Henk-Jaap Wagenaar
> wrote:
> > Note that this has been sugges
That's not the same, in the OP example you can assert d[0] is not d[1],
while in your code that assertion fails (the list comprehension evaluates
the expression each time creating a new list, your code makes 10 references
to a single 5 element list)
On 30 March 2017 at 14:51, Mark E. Haase wrote
I actually saw a decorator like that last week,
https://twitter.com/judy2k/status/854330478068977664
On 25 April 2017 at 08:56, Paul Moore wrote:
> On 25 April 2017 at 03:53, Steven D'Aprano wrote:
> > On Tue, Apr 25, 2017 at 02:08:05AM +0100, Erik wrote:
> >
> >> I often find myself writing __
Expanding on the comments of the OP (to give more information, not
necessarily to support or be against it):
The "$" operator in Haskell is not a composition operator, it's essentially
the same as python's apply builtin (the python2 builtin, removed for python
3), but with an operator syntax; the
On 27 November 2017 at 06:40, Chris Angelico wrote:
> Here are a few syntaxes that I believe have been proposed at various
> times:
>
> x, y = islice(iter, 2) # status quo
> x, y = iter # your proposal
> x, y, = iter # omit last destination
>
Just to clear the list, this one (trailing comma) wou
As reference of prior art, there is https://pypi.python.org/pypi/munch in
PyPI
On 29 November 2017 at 05:52, Serhiy Storchaka wrote:
> In 3.7 I have removed an old-deprecated plistlib.Dict. [1] Actually it
> already was deprecated when the plistlib module was added to the regular
> stdlib in Pyt
In which way would this be different to {**mapping1, **mapping2,
**mapping3} ?
On 8 April 2018 at 22:18, Andrés Delfino wrote:
> Hi!
>
> I thought that maybe dict could accept several mappings as positional
> arguments, like this:
>
> class Dict4(dict):
>> def __init__(self, *args, **kwargs)
I didn't know that kwargs unpacking in dictionaries displays don't
> raise a TypeError exception.
>
> On Mon, Apr 9, 2018 at 8:23 AM, Daniel Moisset
> wrote:
>
>> In which way would this be different to {**mapping1, **mapping2,
>> **mapping3} ?
>>
>> O
I'm not sure I understand the benefit of this, perhaps you can clarify.
What I see is two scenarios
Scenario A) External files are present
In this case, the data is loaded from the pyc and then from external file,
so there are no savings in memory, startup time, disk space, or network
load time,
One implementation difficulty specifically related to annotations, is that
they are quite hard to find/extract from the code objects. Both docstrings
and lnotab are within specific fields of the code object for their
function/class/module; annotations are spread as individual constants
(assuming PE
n the singleton that cpython normally uses for "1", although most
duplicates are some small strings, tuples with argument names, or .
Something that could be interesting to write is a "pyc optimizer" that
removes duplicates, this should be a gain at a minimal preprocessing cost.
On
Note that most languages that you mentioned as references are functional
(so they don't have a statement/expression distinction like Python has),
and those that are not, have matching statements. The only exception is
Javascript, but in Javascript the distinction is not that
hard given that it has
This email from Steve has some good questions, let me try to help organize
ideas:
On 4 May 2018 at 13:11, Steven D'Aprano wrote:
> I'll make a start, and you can correct me if I get any of it wrong.
>
> (1) Pattern matching takes a value, and compares it to a series of
> *patterns* until the fir
rsal way to solve name clashes between
python keywords and libraries that use some external concept that overlaps
with python
(from https://pythonhosted.org/pyquery/attributes.html ):
>>> *import* pyquery *as* pq
>>> p = pq(*''*)(*'p'*)
>>> p.attr(id=*'hello&
On 14 May 2018 at 15:02, Clint Hepner wrote:
>
> > On 2018 May 14 , at 6:47 a, Daniel Moisset
> wrote:
> >
> > Following up some of the discussions about the problems of adding
> keywords and Guido's proposal of making tokenization context-dependent, I
> wante
On 14 May 2018 at 15:02, Clint Hepner wrote:
>
> > On 2018 May 14 , at 6:47 a, Daniel Moisset
> wrote:
> >
> > Following up some of the discussions about the problems of adding
> keywords and Guido's proposal of making tokenization context-dependent, I
> wante
ax won't give me.
>
>
That use case should be covered by
for v in iter(get_something, INCOVENIENT_SENTINEL):
do_something(v)
--
<https://www.machinalis.co.uk>
Daniel Moisset
UK COUNTRY MANAGER
A: 1 Fore Street, EC2Y 9DT London <https://goo.gl/maps/pH9BBLgE8dG2>
ore ideas?
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
--
<https://www.machinalis.com/>
Daniel Moi
32 matches
Mail list logo
