I
Op wo 29 aug. 2018 07:53 schreef Greg Ewing :
> Wes Turner wrote:
> > I'm going to re-write that in a pseudo-Eiffel like syntax:
>
> Maybe some magic could be done to make this work:
>
> def __init__(self, img: np.ndarray, x: int, y: int, width: int,
> height: int) ->
Wes Turner wrote:
I'm going to re-write that in a pseudo-Eiffel like syntax:
Maybe some magic could be done to make this work:
def __init__(self, img: np.ndarray, x: int, y: int, width: int,
height: int) -> None:
def __require__():
x >= 0
How are conditions relaxed/overridden in Eiffel without a named reference?
That looks much more readable.
Expressions within such blocks are implicitly assertTrue(s).
What sort of test generation from said nameless expressions would be most
helpful?
On Tuesday, August 28, 2018, Steven D'Aprano
On Tue, Aug 28, 2018 at 07:46:02AM +0200, Marko Ristin-Kaufmann wrote:
> Hi,
> To clarify the benefits of the contracts, let me give you an example from
> our code base:
>
> @icontract.pre(lambda x: x >= 0)
> @icontract.pre(lambda y: y >= 0)
> @icontract.pre(lambda width: width >= 0)
>
I admit that I don't care that much about pre- and post-conditions. Like a
lot of people I've written a you library to handle some cases, but was
never motivates to make it better or use ones folks have refined. I
definitely oppose dedicated syntax.
Nonetheless, I'll say that it's really not hard
Guido van Rossum wrote:
we might propose (as the OP did) that this:
a, b, c += x, y, z
could be made equivalent to this:
a += x
b += y
c += z
But not without violating the principle that
lhs += rhs
is equivalent to
lhs = lhs.__iadd__(lhs)
Granted, this rule inevitably
>
>
> By the same logic, wouldn't such a naive user also expect:
>
> a, b, c = 0
>
> to set three variables to 0?
>
>
Let's notice that this syntax is valid:
a = b = c = 0
But for += there is no such direct translation.
___
Python-ideas mailing
On 2018-08-28 18:57, Guido van Rossum wrote:
So we currently have iterable unpacking:
a, b, c = x # x better be an iterable of exactly 3 values
as well as tuple packing:
x = a, b, c # sets x to a tuple of 3 values (a, b, c)
and we can combine these, e.g.:
a, b, c = x, y, z
and
Guido wrote
> Perhaps someone can do some research and unearth real code that contains
> series of += assignments that would become more readable by collapsing them
> into a single line using the proposed construct.
Here's some notes towards finding (or constructing) such examples.
First note
On Tue, Aug 28, 2018 at 12:57 PM Guido van Rossum wrote:
> However, a user who doesn't typically think about the actual semantics of
> iterable unpacking and tuple packing might think this would instead mean
> the following:
>
> a += x
> b += x
> c += x
>
> IOW they might think that this
So we currently have iterable unpacking:
a, b, c = x # x better be an iterable of exactly 3 values
as well as tuple packing:
x = a, b, c # sets x to a tuple of 3 values (a, b, c)
and we can combine these, e.g.:
a, b, c = x, y, z
and this still creates an intermediate, anonymous tuple
Chris Angelico writes:
> When you have completely different variables, sure. But what if - like
> in the swap example - they're the same variables?
>
> a, b, c += b, c, a
Good point.
a, b, c = a + b, b + c, c + a
is "good enough" for this particular case, I'd say, and has the
I now fully understand your use case.
IIUC, what would make this easier is a syntax for defining preconditions,
post conditions, and invariants that supports:
* inheritance, composition (mixins)
This isn't possible with decorators because there's no reference to the
post-decorated
On Tue, Aug 28, 2018 at 6:05 PM, Stephen J. Turnbull
wrote:
> In the case in point, the destructuring assignments
>
> a, b = b, a
> w, x, y, z = z, w, y, x
>
> can be interpreted as "swapping" or "permuting", and AIUI that's why
> they were included. They express the intent better than
>
Executive summary: Much of this is my opinion, and as a newer poster,
your opinion is *more* valuable than mine (fresh eyes and all that).
What I hope you'll take from this post is a more precise understanding
of the customary criteria that are used in evaluating a proposed
feature on
Tim Peters writes:
> [Stephen J. Turnbull[
> > No. It's equivalent to
> >
> > =
> > =
> > =
> >
> > and the order matters because the s may have side effects.
>
> This is tricky stuff.
Thank you, and Guido, for the correction.
Op ma 27 aug. 2018 om 23:18 schreef James Lu :
> > As Matthew points out, you could use numpy.array. Or code your own
> > class, by providing __add__ and __iadd__ methods.
> >
> > >>> import numpy
> > >>> a = numpy.array([1, 2])
> > >>> b = numpy.array([3, 4])
> > >>> a + b
> > array([4, 6])
> >
Didn't see the Qt version of the adding together with GUI yet, so here I
have a minimalist version:
import sys
from PyQt5.QtWidgets import QWidget, QSpinBox, QLabel, QApplication,
QHBoxLayout
app = QApplication(sys.argv)
w = QWidget()
w.setLayout(QHBoxLayout())
spinOne = QSpinBox(w)
spinTwo =
18 matches
Mail list logo
