Steven D'Aprano wrote:
Think about a more complex assignment:
text .= encode(spam) + str(eggs)
I think the only sane thing would be to disallow that, and
require the RHS to have the form of a function call, which is
always interpreted as a method of the LHS.
--
Greg
On 2018-09-27 03:48, Ken Hilton wrote:
Would there be a dunder method handling this? Or since it's explicitly
just a syntax for "obj = obj.method()" is that not necessary?
My only qualm is that this might get PHP users confused; that's really
not an issue, though, since Python is not PHP.
I'm
On Thu, Sep 27, 2018 at 09:47:42PM -0400, James Lu wrote:
> > I agree that this adds ambiguity where we can't be sure whether text .=
> > encode('utf-8') is referring to the function or the method. We can infer
> > that it *ought* to be the method, and maybe even add a rule to force
> > that,
This seems like a fairly terrible idea. -100 from me.
Python simply does not tends to chain methods for mutation of objects. A
few libraries—e.g. Pandas—do this, but in those cases actual chaining is
more idiomatic.
This is very different from '+=' or '*=' or even '|=' where you pretty much
Hi,
I annotated pathlib with contracts:
https://github.com/mristin/icontract-pathlib-poc. I zipped the HTML docs
into
https://github.com/mristin/icontract-pathlib-poc/blob/master/contracts-pathlib-poc.zip,
you can just unpack and view the index.html.
One thing I did observe was that there were
On Thu, Sep 27, 2018 at 10:44:38PM +0300, Taavi Eomäe wrote:
> > Do you see how this creates an ambiguous situation?
>
> Name shadowing could create such ambiguous situations anyways even without
> the new operator?
How? Can you give an example?
Normally, there is no way for a bare name to
> As I see it, you are mixing very different things. Augmented operators in
Python work on objects, generally trying to mutate them in-place. So
usually after these operations you have the same object (with the same
type, with the same name and etc.) as before these operations. Of course
there are
As I see it, you are mixing very different things. Augmented operators in
Python work on objects, generally trying to mutate them in-place. So
usually after these operations you have the same object (with the same
type, with the same name and etc.) as before these operations. Of course
there are
> items = ["foo", "bar", "quux"]
> items[randrange(3)] .= upper()
>
> Is this equivalent to:
>
> items[randrange(3)] = items[randrange(3)].upper()
>
> ? That would call randrange twice, potentially grabbing one element
> and dropping it into another slot. If it isn't equivalent to that, how
> is
On Wed, Sep 26, 2018 at 9:14 PM Jasper Rebane wrote:
> When using Python, I find myself often using assignment operators, like 'a +=
> 1' instead of 'a = a + 1', which saves me a lot of time and hassle
>
> Unfortunately, this doesn't apply to methods, thus we have to write code like
> this:
>
> Do you see how this creates an ambiguous situation?
Name shadowing could create such ambiguous situations anyways even without
the new operator?
> In my opinion, it goes against the notion that explicit is better than
implicit.
By that logic all operation-assign operations violate that rule
On 2018-09-27 14:13, Calvin Spealman wrote:
Absolutely -1 on this. Consider the following example:
def encode(s, *args):
"""Force UTF 8 no matter what!"""
return s.encode('utf8')
text = "Hello, there!"
text .= encode('latin1')
Do you see how this creates an ambiguous situation?
I believe Calvin is right. .= Assumes that every function returns a value or
perhaps implies purity. In my opinion, it goes against the notion that explicit
is better than implicit.
Stelios Tymvios
> On 27 Sep 2018, at 4:13 PM, Calvin Spealman wrote:
>
> Absolutely -1 on this. Consider the
Absolutely -1 on this. Consider the following example:
def encode(s, *args):
"""Force UTF 8 no matter what!"""
return s.encode('utf8')
text = "Hello, there!"
text .= encode('latin1')
Do you see how this creates an ambiguous situation? Implicit attribute
lookup like this is really
Hi Jasper,
This seems like a great idea! It looks so much cleaner, too.
Would there be a dunder method handling this? Or since it's explicitly just
a syntax for "obj = obj.method()" is that not necessary?
My only qualm is that this might get PHP users confused; that's really not
an issue, though,
Why couldn’t we record the operations done to a special object and replay them?
>>> Actually, I think there is probably no way around a decorator that
>>> captures/snapshots the data before the function call with a lambda (or even
>>> a separate function). "Old" construct, if we are to parse
Hi Paul,
I only had a contracts library in mind (standardized so that different
modules with contracts can interact and that the ecosystem for automic
testing could emerge). I was never thinking about the philosophy or design
methodology (where you write _all_ the contracts first and then have the
On Thu, 27 Sep 2018 at 08:03, Greg Ewing wrote:
>
> David Mertz wrote:
> > the reality is that they really ARE NOT much different
> > from assertions, in either practice or theory.
>
> Seems to me that assertions is exactly what they are. Eiffel just
> provides some syntactic sugar for dealing
On 26/09/18 18:23, Michael Selik wrote:
Guido has repeatedly (haha) rejected this proposal [0]. He has written
that he considered it, but decided that in practical code one almost
always loops over data, and does not want an arbitrary number of
iterations. The range object solves this problem.
David Mertz wrote:
the reality is that they really ARE NOT much different
from assertions, in either practice or theory.
Seems to me that assertions is exactly what they are. Eiffel just
provides some syntactic sugar for dealing with inheritance, etc.
You can get the same effect in present-day
Mikhail V writes:
> In the first linked discussion, e.g. Mr. D'Aprano and Mr. Coghlan (from my
> impression both from dev team) unambiguosly claimed that adding e.g.
> "loop" as a loop token lead to necessity of excluding ALL
> variables and functions/methods named "loop" from all sources.
>
21 matches
Mail list logo
