09.04.20 00:54, Andrew Barnert via Python-ideas пише:
Could you go so far as to remove the variable from the locals if its only
assignment(s) are optimized out? I’m not sure how much benefit that would
provide. (Surely it would sometimes mean an f_locals array fits into one cache
line instead
09.04.20 03:46, Henk-Jaap Wagenaar пише:
I like the idea of formalizing "unused variables".
How about having a syntax for it? Allowing a "." instead of an
identifier to signify this behaviour [reusing Serhiy's examples]:
head, ., rest = path.partition('/')
first, second, *. = line.split()
for
To put it simple, unpacking raises ValueError:
>>> x, = ()
Traceback (most recent call last):
File "", line 1, in
ValueError: not enough values to unpack (expected 1, got 0)
>>> x, = (1, 2)
Traceback (most recent call last):
File "", line 1, in
ValueError: too many values to unpack (expecte
[Muchly snipped]
On 09/04/2020 12:27, Soni L. wrote:
To put it simple, unpacking raises ValueError:
But if the iterator raises ValueError, there's no way to tell it apart
from the unpacking:
I don't see how this is any different from any other case when you get
the same exception for differe
On 2020-04-09 8:48 a.m., Rhodri James wrote:
[Muchly snipped]
On 09/04/2020 12:27, Soni L. wrote:
To put it simple, unpacking raises ValueError:
But if the iterator raises ValueError, there's no way to tell it
apart from the unpacking:
I don't see how this is any different from any other c
Soni L. wrote:
> On 2020-04-09 8:48 a.m., Rhodri James wrote:
> > [Muchly snipped]
> > On 09/04/2020 12:27, Soni L. wrote:
> > To put it simple, unpacking raises
> > ValueError:
> > But if the iterator raises ValueError, there's no way to tell it
> > apart from the unpacking:
> > I don't see how t
On Thu, Apr 09, 2020 at 08:27:14AM -0300, Soni L. wrote:
> To put it simple, unpacking raises ValueError:
[...]
> But if the iterator raises ValueError, there's no way to tell it apart
> from the unpacking:
>
> >>> def foo():
> ... yield None
> ... raise ValueError
You could start by re
What about nested functions? I am not sure how we can predict if that
variable is going to be used or not.
I think this is a nice idea to have such an analysis, but I don't think is
feasible.
On Thu, 9 Apr 2020 at 04:29, Caleb Donovick
wrote:
> This would almost certainly break my code. As a
On Apr 8, 2020, at 23:53, Wes Turner wrote:
>
> Could something just heuristically add del statements with an AST
> transformation that we could review with source control before committing?
>
> When the gc pause occurs is something I don't fully understand. For example:
Your examples don’t ha
Sometimes, you have an API:
@abc.abstractmethod
def get_property_value(self, prop):
"""Returns the value associated with the given property.
Args:
prop (DataProperty): The property.
Returns:
The value associated with the given property.
On Thu, Apr 9, 2020 at 5:31 PM Soni L. wrote:
> Sometimes, you have an API:
>
> SNIP
> Raises:
> PropertyError: If the property is not supported by this config
> source.
> LookupError: If the property is supported, but isn't
> available.
>
Hello,
On Thu, 9 Apr 2020 17:40:26 -0300
André Roberge wrote:
> On Thu, Apr 9, 2020 at 5:31 PM Soni L. wrote:
>
> > Sometimes, you have an API:
> >
> > SNIP
>
> > Raises:
> > PropertyError: If the property is not supported by
> > this config source.
> > Lo
Thanks for removing the mystery.
FWIW, here are some of the docs and resources for memory management in
Python;
I share these not to be obnoxious or to atoen, but to point to the docs
that would need updating to explain what is going on if this is not
explicit.
- https://docs.python.org/3/referen
On Apr 9, 2020, at 15:13, Wes Turner wrote:
>
> - > And then take a look at how @ApacheArrow
> "supports zero-copy reads for lightning-fast data access without
> serialization overhead."
> - .@blazingsql … #cuDF … @ApacheArrow
> https://docs.blazingdb.com/docs/blazingsql
This isn’t relevan
On Wed, Apr 8, 2020, 10:37 AM Antoine Pitrou wrote:
> On Wed, 8 Apr 2020 10:18:47 -0700
> Guido van Rossum wrote:
> >
> > > But when I leave "large" temp objects hanging and
> > > give a rip, I already stick in "del" statements anyway. Very rarely,
> > > but it happens.
> > >
> >
> > I recall t
15 matches
Mail list logo
