I believe that one of the most popular Python domains that benefit from
"abusing" indexes is data analysis in the numpy/Pandas world.
I am not familiar enough with Pandas to make useful speculation on how
named indexes could enhance the usage of dataframes, - maybe someone more
familiar can
You know you can simply pass functions as parameters, right?
def lock(func, *args):
# ...setup
result = func(*args)
#... teardown
return result.
And then, with 3 more lines you do a decorator out of that
def locked(func):
# <'lock' body as above>
return lock
in the end:
On Sat, 4 Jul 2020 at 12:51, Random832 wrote:
> On Fri, Jul 3, 2020, at 03:57, Wes Turner wrote:
> > Can a Sequence be infinite? If so, an equality test of two
> > nonterminating sequences would be a nonterminating operation.
>
> I think not - an infinite sequence would make len, contains, and
On Sat, 4 Jul 2020 at 16:51, Serhiy Storchaka wrote:
> 30.06.20 18:58, Joao S. O. Bueno пише:
> > I ended up writting an __eq__ - and in the process I found it is not
> > _that_ straightforward due
> > to having to check subclasses types when comparing.
> > (given B
On Fri, 3 Jul 2020 at 03:07, Random832 wrote:
> On Wed, Jul 1, 2020, at 08:23, Joao S. O. Bueno wrote:
> > collections.mixins.SlicedSequence that would override `__delitem__`,
> > `__setitem__` and `__getitem__` and
> > handle slices could pair up with the "ComparableSe
TreeDict(*((i, key) for i, key in enumerate(a)))
# Using numeric keys for range from 'a' keys:
[(key, a[key]) for key in b[1:4]]
out: [('def', 'foo'), ('ghi', 'baz')]
```
On Mon, 29 Jun 2020 at 08:59, Hans Ginzel wrote:
> Thank you.
>
> On Fri, Jun 26, 2020 at 02:50:22PM -0300, Joao S. O. Bueno
Thre are already projects that build Python using Web Assembly -
But as far as I know, these do not have a good
interface with the document DOM.
https://hacks.mozilla.org/2019/04/pyodide-bringing-the-scientific-python-stack-to-the-browser/
Maybe you'd like to take a look at Brython instead -
it
On Fri, 26 Jun 2020 at 14:30, Hans Ginzel wrote:
> Date: Fri, 26 Jun 2020 18:47:44 +0200
> From: Hans Ginzel
> To: Hans Ginzel
> Subject: Access (ordered) dict by index; insert slice
>
> Hello,
>
> thank you for making dict ordered.
> Is it planned to access key,value pair(s) by index? See
>
On Mon, 29 Jun 2020 at 17:03, Joao S. O. Bueno
wrote:
> If you need custom sort-orders and slicing for dicts, I've implemented
> a b-tree backed mapping that can do just that a couple weeks ago -
> you are welcome to use it:
>
> https://github.com/jsbueno
On Mon, 22 Jun 2020 at 13:08, Michael Christensen
wrote:
> Concerning parameters in the as section: I think using `with` would make
> it easier to understand.
>
> try match result:
> as Dog:
> print("Dog")
> as Cat with lives:
> print(f"Cat with {lives} lives")
> as
One should never underestimate the power of Guido's time machine.
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
On Thu, 12 Mar 2020 at 14:09, Paul Moore wrote:
>
> On Thu, 12 Mar 2020 at 16:57, Eric Wieser wrote:
> >
> > It looks like actually this can be be built as a function today:
> >
> > def move(name):
> > return inspect.currentframe().f_back.f_locals.pop(name)
> >
> > Which works as
That is definitely not language-behavior material - and should be a worry
of the authors of whatever projects have objects that demand so much
processing to generate a "repr".
It certainly is not a common problema met with - I often have to deal
with cumbersome repr's (even in my own projects),
Anyway, that is feasible via a decorator.
Since it can't be done the wya you are proposing as is, since
having a function as a default argument is valid Python
(and the function is not called) - and
having new syntax for this would be more cumbersome
than using a decorator, I think that closes
I agree - the three builtin methods are almost the same (not sure if
there is any difference at all), while there is no trivial way to check for
a valid
float, or otherwise a chosen representation of a decimal number without
resorting
to a try-except statement, or complicated verification schemes
On Sun, 27 Dec 2020 at 19:31, Chris Angelico wrote:
> On Mon, Dec 28, 2020 at 9:22 AM Joao S. O. Bueno
> wrote:
> >
> > I agree - the three builtin methods are almost the same (not sure if
> > there is any difference at all),
>
> Yes - they all check if the s
A while back I could make a proof of concept of this with current Python,
no modifications needed.
The text is in portuguese -by I believe automatic translation should be
enough for the non-code
parts.
And how would Python compute the "full basename of the file to be
imported"?
How could it guess among all directories on sys.path the one containing
the "file", and check if it is a file or a package without going through
the existing mechanism?
Maybe this proposal is good - but possibly, just
On Wed, 9 Dec 2020 at 09:27, Mathew Elman wrote:
> I agree that if you are using them as iterables, then the type is usually
> not important because you are treating their type as just iter-able. The
> lazy iterable would more or less just be the same as passing in
> `iter(sequence)`.
>
> This
Is it really worth it?
Fact is, while it can shave off some lines of code,
I think it is interesting to know _which_ lines of code -
Usually when one writes a decorator, it is expected that they
will know what they are writing, and will want to be in control of
their code. Delegating this to a
I still like the approach of doing `import typing as t` - (or other short
name of ones preference).
Bcause in the end, any argument used to bring "Any" as a built-in could be
used in favor
of any other element in typing anway.
Typing "t.Any, t.Union, t.Optional" is not a hassle and immediately
Although that is not a pattern I recall I had needed, but for the first
item in a generator,
I recognize it is more complicated than it should to be able to do that.
However, not only that would be too big a change for all this objects
I think one would expect an object providing index access
Sorry - personally I think this is absolutely ugly :-) So I will bikeshed.
If this thread even go ahead - since the idea is not that bad, maybe
allowing `try` on the same line?
Then it would be inline with `elif` - but still structured "English like"
try:
statement
except ValueError try:
On Fri, 14 May 2021 at 09:24, Martin Teichmann
wrote:
> Hi list,
>
> when dividing two integers, the result is a float, which means we
> immediately lose precision. This is not good if you want to use code which
> supports higher precision. Decimals come to mind, but also sympy. This loss
> of
You can just use nonlocal variables:
def stator():
static_var_1 = 0
def myfunc(n):
nonlocal static_var_1
static_var_1 += n
return static_var_1
return myfunc
myfunc = stator()
del stator
Or you can attach any variable to the function itself:
def myfunc(n):
On Thu, 27 May 2021 at 10:39, Paul Moore wrote:
[...]
> the performance aspect, function
> attributes provide this functionality, but there's a significant
> problem with using them because you can't access them other than by
> referencing the *name* of the function being defined.
> [...]
>
> It
I started seeing this, as the objecting people are putting, something that
is
really outside of the scope.
But it just did occur to me that having to use str.join _inside_ an
f-string
expression is somewhat cumbersome
I mean, think of a typical repr for a sequence class:
return f"MyClass({',
I've missed this feature on occasion as well. +1 for whatever that counts;
On Mon, 22 Mar 2021 at 17:30, Caleb Donovick
wrote:
> Never needed this for lists but definitely had the pain for kwargs. Seems
> very reasonable for that use case, +0.5.
>
> In libraries I control I can make sure to
Sorry - previous reply was sent empty.
So, you probably can do with `asyncio.run`:
```
In [26]: import asyncio
In [27]: asyncio.run(asyncio.sleep(2))
```
https://docs.python.org/3/library/asyncio-task.html#asyncio.run
On Wed, 24 Mar 2021 at 06:44, wrote:
> It is not the same, it will work in
On Wed, 24 Mar 2021 at 06:44, wrote:
> It is not the same, it will work in interactive mode But I want to
> run application without interactive mode
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to
On Wed, 17 Feb 2021 at 15:31, Ethan Furman wrote:
> On 2/17/21 8:47 AM, Random832 wrote:
> > On Tue, Feb 16, 2021, at 23:24, Stephen J. Turnbull wrote:
>
> >> except a couple of characters. So what currently looks like
> >>
> >> some_list.sort(key=lambda e: e[3].priority)
> >>
> >> would
e 7th: "Readability
counts".
If you don't want readability at all in exchange for typing a few keywords
(which more and more automatic tools can auto-complete), I'd suggest going
for the "forth" language.
Abdulla
>
> On 17 Feb 2021, at 10:59 PM, Joao S. O. Bueno
>
So,
It is out of scope of Pythonmultiprocessing, and, as I perceive it, from
the stdlib as a whole to be able to allocate specific cores for each
subprocess -
that is automatically done by the O.S. (and of course, the O.S. having an
interface
for it, one can write a specific Python library which
On Tue, 14 Sept 2021 at 22:59, David Mertz, Ph.D.
wrote:
> I think this would be convenient.
>
> And yes, it's not thread safe. But neither is os.chdir() to start with.
> Someone whose script, or library, wants to chdir can already shoot
> themselves in the foot. This makes that slightly less
All that is needed is a descriptor which calls the decorated functiosn
without any parameters.
This could serve to use classes as namespaces for "live" globals - if one
will do some sort
of reactive programing, it might even find some use.
A descriptor with a for that would be something like:
On Thu, 9 Dec 2021 at 17:54, deavid wrote:
> Hi, I would like to hear the opinion of Python's community on enforcing
> types in the future for the language.
>
here goes opinion: "no"!
strong no.
while _using_ tooling that have correct typing is a bit easier, it can make
it hard to write
code,
Just a short one, for everyone agreeing type.Annotated does the job,
but thinks we need new syntax, because it is verbose:
You can already do:
from typing import Annotated as A
And:
attr: A[type, "docstring goes here"]
I see no need for any new syntax.
(and maybe adding typing.Docstring
On Mon, Mar 14, 2022 at 9:49 AM Chris Angelico wrote:
> On Mon, 14 Mar 2022 at 23:35, wrote:
> >
> > Currently:
> > l = [] # new empty list
> > t = () # new empty tuple
> > s = set() # new empty set (no clean and consistent way of initializing
> regarding the others) <<<
> > d = {} # new empty
Do you know what else would work for being able
to enter empty sets?
A prefix to {} , like "s"
a = s{}
and
b = f{}
for an empty frozenset
(/me ducks, and hides in a place Chris won't find me)
On Mon, Mar 14, 2022 at 10:29 AM Chris Angelico wrote:
> On Tue, 15 Mar 2022 at 00:
I'd be in favor of a nice syntax for named mapping unpacking.
But while we are at discussion - I'd point out it is "possible" (not easy)
with
current day syntax, by abusing the command "import" -
One can set appropriate import hooks that would enable
either for the current module, or maybe, in a
TL;DR:
You know you can call the method on any class you want just by
explicitly writting the class name instead os "super()" don't you?
That said, the current MRO (and super) behavior is what folks arrived at
almost 20 years ago, the "C3 algorithm", in Python 2.3 after a little tweak
from the
On Fri, Mar 25, 2022 at 12:17 AM Brendan Barnwell
wrote:
> On 2022-03-24 10:43, Andrew Svetlov wrote:
> > The proposal doesn't work well with type hints: atuple(a=1, b=2) and
> > atuple(a="a", b="b") generates the same type.
>
> I'm neither here nor there on the original proposal, but I
> but I don't think we should underestimate the cost of even this small
complexity increase in the language.
Actually, I think _maybe_ in this case the "complexity increase" cost is
_negative_. People might waste
more time looking for a way of spelling a frozenset literal than just
filling in
>
> Yes, but have you _seen_ the bickering about the existing bracket
>
> choices just for frozenset? Eww. Hence the going for a distinct operator
> altogether. Yes, I'd prefer brackets of some kind too, but they're
> taken.
>
> If one uses prefixes, you start from 53 valid (all latin areas,
>
> I don't understand polynomials as frozensets. What's the point of
> representing them that way? Particularly if you're converting to and
> from dicts all the time, why not represent them as dicts? Or as some
> custom mapping type, if you need it to be hashable?
Sorry for deviating here, but
Maybe the "special optimizable method" will solve some of the problems, and
appraise the "no new syntax" folks. But IMHO, it (1) it is more verbose
than the prefix/suffix new syntax alternatives, to the point of getting
in the way of reading
mysets = [{1 ,2 ,3 }.freeze(), {4,5,6}.freeze()]
X
>
> Also, it is standard in Python to avoid properties if the computation
> could be expensive. Copying a large set or millions of elements into a
> frozenset could be expensive, so we should keep it a method call.
Here is another hint that this usage would not resolve the problem of
having a
On Mon, Apr 11, 2022 at 3:39 AM Chris Angelico wrote:
On Mon, 11 Apr 2022 at 15:25, Stephen J. Turnbull
> wrote:
> > [1] They don't have to be big problems or proprietary code; computing
> > Fibonacci sequences will do, if you can find a way to make MI relevant
> > to that task.
> >
>
>
> We
On Tue, Apr 12, 2022 at 1:59 PM malmiteria wrote:
> Ronald Oussoren writes:
>
> > To be blunt: That’s not going to happen because this is big backward
> compatibility break. Either that, or this adds a
> > second way to define classes. Both are good reasons to keep the status
> quo.
>
> the
On Fri, Apr 15, 2022 at 2:44 PM malmiteria wrote:
> I got an idea that *should* allow for some (keyword : some) of the
changes
> i want without any breaks, i kinda wanna take the time to think about it,
and
> once i'm a bit more sure of it, i'll talk about it in details.
Since you are thinking
Should it emit a warning (or TypeError) when decorating anything but a
function named `__init__ ` ?
On Wed, Apr 20, 2022 at 3:14 PM Joao S. O. Bueno
wrote:
>
>
> On Wed, Apr 20, 2022 at 12:30 PM Pablo Alcain
> wrote:
>
>>
>> Regarding the usage of a decorator
On Thu, Apr 21, 2022 at 5:17 PM Pablo Alcain wrote:
> Hey Joao! For what it's worth, I'm not a big fan of the proposal to be
> honest, for the reasons I have already mentioned. I'm not heavily against
> it, but I would most likely not use it. Nevertheless, I believe it would
> need a PEP since
a solution to this problem
> that is clean and robust without adding new syntax with it. I would like to
> hear your thoughts on this (and everyone else's of course!)
>
> Cheers,
> Pablo
>
> On Mon, Apr 18, 2022 at 9:55 PM Christopher Barker
> wrote:
>
>> O
There is no need for a whole new syntax for what can trivially be
accomplished by a decorator,
and a simple one, in this cases.
I for one am all for the inclusion of a decorator targeting either the
__init__ method
or the class itself to perform this binding of known arguments to instance
Hi. I've replied to the first e-mail on this thread, more than 10 days ago.
I am back, though I've read most of what was written.
I don't think things have improved, but you sure are consuming everyone's
time
You are still repeating this:
"more in line with the expectation of the majority, "
On Fri, Jun 24, 2022 at 10:05 PM Chris Angelico wrote:
>
> Hmmm, I think possibly you're misunderstanding the nature of class
> slots, then. The most important part is that they are looked up on the
> *class*, not the instance; but there are some other quirks too:
Sorry, no. I know how those
On Fri, Jun 24, 2022 at 5:38 AM Chris Angelico wrote:
>
> On Fri, 24 Jun 2022 at 16:34, Joao S. O. Bueno
wrote:
> > On Fri, Jun 24, 2022 at 1:06 AM Chris Angelico wrote:
> >> How much benefit would this be? You're proposing a syntactic construct
> >> for something
On Fri, Jun 24, 2022 at 1:06 AM Chris Angelico wrote:
> On Fri, 24 Jun 2022 at 13:26, Joao S. O. Bueno
> wrote:
> >
> >
> >
> > On Thu, Jun 23, 2022 at 2:53 AM Chris Angelico wrote:
> >>
> >> On Thu, 23 Jun 2022 at 11:35, Joao S. O. Bue
On Thu, Jun 23, 2022 at 2:53 AM Chris Angelico wrote:
> On Thu, 23 Jun 2022 at 11:35, Joao S. O. Bueno
> wrote:
> >
> > Martin Di Paola wrote:
> > > Three cases: Dask/PySpark, Django's ORM and selectq. All of them
> > > implement deferred expressions bu
Martin Di Paola wrote:
> Three cases: Dask/PySpark, Django's ORM and selectq. All of them
> implement deferred expressions but all of them "compute" them in very
> specific ways (aka, they plan and execute the computation differently).
So - I've been hit with the "transparency execution of
Still - the "filter" call is almost as simple as it can get for a generic
enough way to do what you are requesting.
There is some boiler plate needed around it if you want an actual eager
result or a default value, if no match is found, that is true - but still,
given a list like
On Sat, May 7,
Although ENUMs are already complicated enough, this proposals frees up
messing with the EnumMeta metaclass in some cases -
it makes sense.
I've subclassed EnumMeta once for adding some feature in a project, and it
never feels the "quite right" thing to do.
On Tue, Apr 26, 2022 at 6:12 PM Stefan
Anyway, there is something dataclasses do today that prevent you from jsut
adding a @dataclass for binding __init__ attributes from an otherwise
"complete class that does things": it overwrites __init__ itself - one hass
to resort to write "__post_init__" instead,¨
That means that if some class
Actually, there is a good motive IMO for a partial function to have
__name__ and __qualname__: the code one is passing a partial function
might expect these attributes to be presented in the callable it get.
It is just a matter of unifying the interface for callables that are often
used as
I am not enthusiastic about this idea at all: as I perceive it it is an IDE
problem, external to the language, and
should be resolved there - maybe with a recommendation PEP.
But on the other hand, I had seem tens of e-mails discussing
string-subclassing, so that
annotations could suffice as a
Well - one can already do:
x = bytes.fromhex
x("01 23 45 67 89")
As for base64, I really, really, don't see a use case where allowing base64
native strings as
part oif the syntax could be useful - less so when decoding is one call
away.
Base64 was already created to allow one to convey arbitrary
I hope you are at least aware that over the years various multi-year
attempts to create Python sandboxes ultimately failed to the point of being
altogether abandoned.
Python and Javascript differ fundamentally that Python runtime is
intrinsically bound to I/O, like filesystem access - which is a
On Mon, Mar 6, 2023 at 12:51 AM David Mertz, Ph.D.
wrote:
> Is it really that much longer to write `f"{s1} {s2}"` when you want that?
>
As for being that much longer: yes it is.
The more important factor is, I think, the increase in complexity +
readabiity for default strings is worth it in
On Mon, Mar 6, 2023 at 7:37 AM Steven D'Aprano wrote:
> (...)
> I like the look of the & operator for concatenation, so I want to like
> this proposal. But I think I will need to see real world code to
> understand when it would be useful.
>
I'd say we paint the shed blue.
I mean - maybe "|"
On Sat, Apr 22, 2023 at 10:06 AM Damian Cross wrote:
> That would have the effect that every use of str.format for everyone would
> start producing partially-formatted strings if an argument is accidentally
> omitted instead of raising an error. Some people might not like that.
>
"it's a bit more challenging to obtain a separate asyncio loop."
Just call `asyncio.new_event_loop` and you can have as many event loops in
the same thread as you want.
On Thu, Jun 8, 2023 at 10:58 AM Dom Grigonis wrote:
> Hey there! I'm curious to know what this group thinks about the
On Fri, Jun 23, 2023 at 2:35 AM Jelle Zijlstra
wrote:
>
>
> El jue, 22 jun 2023 a las 8:22, Randolf Scholz ()
> escribió:
>
>> Dataclasses should provide a way to ignore a type hinted attributes, and
>> not consider them as fields.
>>
>> For example, some attributes might be derived during
If you use Python's own arrays and generator expressions instead of list
comprehension (by just dropping the `[ ]`s),
you will get each number converted to the target type in memory as soon as
it is calculated. (It will be a full
Python float/int instance during the calculation itself, though).
On Fri, Jun 23, 2023 at 12:18 PM Eric V. Smith wrote:
>
>
> On Jun 23, 2023, at 9:34 AM, Joao S. O. Bueno wrote:
>
>
>
>
> On Fri, Jun 23, 2023 at 2:35 AM Jelle Zijlstra
> wrote:
>
>>
>>
>> El jue, 22 jun 2023 a las 8:22, Randolf Scholz (
101 - 174 of 174 matches
Mail list logo
