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
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.
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 wit
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
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 it
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,
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 confusi
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 fo
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? Impli
> 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 (e
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:
> te
> 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 it
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 ex
> 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
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 shado
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 co
> 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, but this works only for the simple cases. It is risky and error
> p
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
expec
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, bu
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
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
__
21 matches
Mail list logo
