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-
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'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 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 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
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
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
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
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
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 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
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
12 matches
Mail list logo
