I agree that the stated use cases are better handled with ExitStack. One
area where `defer` might be useful is in lazy-evaluating global constants.
For example in a genomics library used at my work, one module involves
compiling a large number of regular expressions, and setting them as global
con
On 4 June 2017 at 10:00, Greg Ewing wrote:
> Is this really much of a security issue? Seems to me that
> for someone to exploit it, they would have to inject a
> malicious .py file alongside one of my script files. If
> they can do that, they can probably do all kinds of bad
> things directly.
Th
On Sun, Jun 4, 2017 at 12:23 AM, Lucas Wiman wrote:
> I agree that the stated use cases are better handled with ExitStack. One
> area where `defer` might be useful is in lazy-evaluating global constants.
> For example in a genomics library used at my work, one module involves
> compiling a large
On 4 June 2017 at 17:37, Nathaniel Smith wrote:
> I think in general I'd recommend making the API for accessing these
> things be a function call interface, so that it's obvious to the
> caller that some expensive computation might be going on. But if
> you're stuck with an attribute-lookup based
Daniel Bershatsky
writes:
> ...
> Proposal
>
> There is not any mechanism to defer the execution of function in
> python. In
> order to mimic defer statement one could use either try/except
> construction or
> use context manager in with statement.
> ...
Related: "Python equivalent of g
Hello,
2017-06-04 Nathaniel Smith dixit:
> class LazyConstants:
> def __getattr__(self, name):
> value = compute_value_for(name)
> setattr(self, name, value)
> return value
>
> __getattr__ is only called as a fallback, so by setting the computed
> value on the object
AFAK it was in whatever PEP introduced Unicode identifiers.
On Jun 3, 2017 11:24 PM, "Nick Coghlan" wrote:
> On 4 June 2017 at 05:02, Dan Sommers wrote:
> > On Sat, 03 Jun 2017 17:45:43 +, Brett Cannon wrote:
> >
> >> On Fri, 2 Jun 2017 at 15:56 Guido van Rossum wrote:
> >>
> >>> I would l
I really don't want people to start using the "from . import foo" idiom for
their first steps into programming. It seems a reasonable "defensive
programming" maneuver to put in scripts and apps made by professional
Python programmers for surprise-free wide distribution, but (like many of
those) sh
On Sun, Jun 4, 2017 at 6:51 PM, Guido van Rossum wrote:
> I really don't want people to start using the "from . import foo" idiom
> for their first steps into programming. It seems a reasonable "defensive
> programming" maneuver to put in scripts and apps made by professional
> Python programmer
I'd like to throw some cold water on this one, for the same reason I always add
"." to the path in my shell, when some well-meaning soul has removed it. Why?
It's 2017 and I've not shared a machine since the 1980's. I use immutable
containers in the cloud that are not at this particular risk
On 5 June 2017 at 07:00, Guido van Rossum wrote:
> AFAK it was in whatever PEP introduced Unicode identifiers.
Ah, indeed it is: https://www.python.org/dev/peps/pep-3131/#policy-specification
Interestingly, that's stricter than my draft PR for PEP 8, and I'm not
entirely sure we follow the "stri
I think the strictness comes from the observation that the stdlib is read
and edited using *lots* of different tools and not every tool is with the
program. That argument may be weaker now than when that PEP was written,
but I still get emails and see websites with mojibake. (Most recently, the
US-
12 matches
Mail list logo
