On Wed, Aug 1, 2018 at 6:45 PM, Jonathan Fine wrote:
> Hi Chris
>
> Thank you for your reply. I think we're making good progress.
>
> You wrote
>
>>> 10) a ?. b ?. c
>>> 11) (a ?. b) ?. c
>>
>> I would parse those differently, but you may be right that they'll
>> always have the same final result.
On Wed, Aug 1, 2018 at 7:09 PM, Jonathan Fine wrote:
> Hi Chris
>
> We're discussing.
>> 10) a ?. b ?. c
>> 11) (a ?. b) ?. c
>
> I asked
>> So, are there any values of 'a' for which #10 and #11 don't give the
>> same result?
>
> You replied
>> I'm not prepared to put my neck out and say "They are
On Thu, Aug 2, 2018 at 12:04 AM, Jonathan Fine wrote:
> Hi Steve
>
> Thank you for your reply.
>
> We're discussing the abstract to PEP 505, which writes
> ===
> The "None-aware attribute access" operator ?. ("maybe dot") evaluates
> the complete expression if the left hand side evaluates to a va
On Sun, Aug 5, 2018 at 2:37 AM, Steven D'Aprano wrote:
> All this supposes that there is sufficient benefit to allowing custom
> infix operators, including overridable or/and/xor, which is not yet
> shown.
Part of the justification for that is that the bitwise operators have
different precedence
On Sun, Aug 5, 2018 at 4:40 AM, Todd wrote:
>
>
> On Sat, Aug 4, 2018 at 9:13 AM, Steven D'Aprano wrote:
>>
>> On Fri, Aug 03, 2018 at 03:17:42PM -0400, Todd wrote:
>>
>> > Boolean operators like the sort I am discussing have been a standard
>> > part
>> > of programming languages since forever.
On Wed, Aug 8, 2018 at 4:14 PM, Ken Hilton wrote:
> This mostly springs off of a comment I saw in some thread.
>
> The point of a with statement is that it ensures that some resource will be
> disposed of, yes? For example, this:
>
> with open(filename) as f:
> contents = f.read()
>
>
On Wed, Aug 8, 2018 at 5:05 PM, Barry Scott wrote:
> But so long as you do not leak the generator the file will be closed
> immediately after the loop as the ref count of the generater hits 0.
Technically that's not guaranteed (since refcounts aren't a language
feature), but if you're using this
On Wed, Aug 8, 2018 at 10:32 PM, Oscar Benjamin
wrote:
> Without the context manager you could write:
>
> def read_multiple(*filenames):
> for filename in filenames:
> f = open(filename)
> yield f.read()
> f.close()
>
> Which also only leaks one file
On Mon, Aug 13, 2018 at 1:31 PM, Abe Dillon wrote:
> [Steven D'Aprano]
>>
>> Just because I challenge your statements doesn't mean I'm attacking you.
>
>
> No. Telling me I'm having an extreme overreaction means you're attacking me.
If your reaction was extreme, saying so isn't attacking you.
>
On Mon, Aug 13, 2018 at 2:56 PM, Abe Dillon wrote:
> [Chris Angelico]
>>
>> Also, the signature is most decidedly NOT obvious from context
>
> Who decided this? It's been decided by some committee? When you write a key
> function, you don't know how man
On Tue, Aug 14, 2018 at 3:06 AM, Michael Selik wrote:
>
>
> On Mon, Aug 13, 2018, 5:59 AM Nicholas Chammas
> wrote:
>>
>> Maybe we need to revive that discussion? Overall, I don’t think we have a
>> people problem on this list as much as we have an administration tooling
>> problem.
>
>
> +1
>
>
On Tue, Aug 14, 2018 at 4:00 AM, Bruce Leban wrote:
> And as to saying a lambda function is an "anonymous function": the anonymity
> is not a property of the function. If I assign it to a name, it's no longer
> anonymous. Really a "lambda" or "lambda function" is just a function, but
> "lambda" is
On Tue, Aug 14, 2018 at 5:08 AM, Abe Dillon wrote:
> The whole point of a programming language is to bridge the gap between
> machine code and natural language (in Python's case English, as with most
> other languages). It's to make reading and writing code easier through
> abstraction, not to cre
On Tue, Aug 14, 2018 at 6:26 AM, Abe Dillon wrote:
> [Chris Angelico]
>>
>> > The whole point of a programming language is to bridge the gap between
>> > machine code and natural language (in Python's case English, as with
>> > most
>> > other
On Tue, Aug 14, 2018 at 7:58 AM, Greg Ewing wrote:
> Chris Angelico wrote:
>>
>> No, lambda calculus isn't on par with brakes - but anonymous functions
>> are, and if they're called "lambda", you just learn that.
>
>
> It's like saying
On Wed, Aug 15, 2018 at 9:09 AM, Chris Barker via Python-ideas
wrote:
> no, it's not -- None is keyword, and just like any other keyword, it can't
> be re-bound. However, every other keyword I tried to rebind results in a
> generic:
>
> SyntaxError: invalid syntax
>
> (except None, True, and False
On Thu, Aug 16, 2018 at 4:52 AM, Jacob Solinsky wrote:
> -Jumping to a function as opposed to calling a function
>
> When a function is jumped to, it inherits the variables in the caller’s local
> namespace and is free to modify them or add new local variables, unlike a
> normal function call, w
On Thu, Aug 16, 2018 at 7:40 AM, Abe Dillon wrote:
> Jumping into functions that mutate variables in the calling scope sounds a
> lot like "GoTo" which is notorious for leading to code that's very hard to
> reason about. Your functions would implicitly require that you assign
> variables in the ca
On Thu, Aug 16, 2018 at 8:53 AM, Jacob Solinsky wrote:
> What I had hoped to do was use a preamble code block to collect all of the
> most common queries called by the mutate function in the local namespace,
> for example
>
> C = 'bpgkdtszSZjCmnywh'
> M = 'mn'
>
>
> class Morpheme:
> #stuff
>
On Fri, Aug 17, 2018 at 5:32 AM, Chris Barker via Python-ideas
wrote:
> hmm -- made me think that generators are doing something different here --
> and indeed they are. If you use regular functions:
>
> In [30]: def local_modifying(loc):
> ...: """
> ...: adds a "fred" key to the
On Mon, Aug 20, 2018 at 12:43 AM, Kirill Balunov
wrote:
>
> чт, 16 авг. 2018 г. в 22:37, Chris Barker via Python-ideas
> :
>>
>>
>> I wonder why locals doesn't return a Mapping Proxy, or other read-only
>> mapping object?
>>
>> If it's not guaranteed to be THE locals dict, and changes *may* not af
On Mon, Aug 20, 2018 at 5:34 PM, Simon De Greve wrote:
> Do you mean that for loops inside an "async def" statements are always
> executed as 'async for' loops? That's what I wanted to acheive by writing
> the AsyncDict class (c.f. the CodeReview link).
The point of an 'async for' loop is that gr
On Tue, Aug 21, 2018 at 12:21 AM, Steven D'Aprano wrote:
> On Sun, Aug 19, 2018 at 06:18:56PM +0300, Kirill Balunov wrote:
>
> [...]
>> > > e) It leaves a room for a future changes (In fact, in some situations I
>> > > would like to have this possibility).
>
> [Chris]
>> > Related to (e) is that t
On Tue, Aug 21, 2018 at 2:16 AM, Chris Barker via Python-ideas
wrote:
> On Mon, Aug 20, 2018 at 7:21 AM, Steven D'Aprano
> wrote:
>>
>> * Introducing a warning makes it clear that this is not a de facto
>> language standard, but a mere implementation detail subject to
>> change if somebody co
On Wed, Aug 22, 2018 at 3:56 AM, Abe Dillon wrote:
> I've never hears someone say, "My child's name will be if it's a girl Sally
> otherwise Billy."
"My child's name depends on gender - if it's a girl, Sally, otherwise
Billy." Seems fine to me. You can always come up with something
awkward in a p
On Wed, Aug 22, 2018 at 2:55 AM, Jonathan Fine wrote:
> Nick Loadholtes wrote (elsewhere, quoted in this thread - by me).
>
>> Make your docs work as hard as your code does. Clear examples will
>> make your code stand out in a good way.
>
> With a bit more searching I found:
>
> https://www.reddi
On Wed, Aug 22, 2018 at 4:56 AM, Abe Dillon wrote:
> [Chris Angelico]
>>
>> Okay, let's read that.
>> hand = # we're assigning this to the name 'hand'
>> sorted( # calling the function named 'sorted'
>> cards, # positional argumen
On Wed, Aug 22, 2018 at 4:56 AM, Abe Dillon wrote:
> [Chris Angelico]
>>
>> In English, "card is not wild" can
>> be interpreted as a membership check, but in Python, it is only an
>> identity check; you're capitalizing on false readability by using thi
On Wed, Aug 22, 2018 at 6:24 AM, Abe Dillon wrote:
> [Chris Angelico]
>>
>> That right there is unacceptable. You should not have to know the
>> destination to understand what something fundamentally is.
>
>
> You don't *have* to know what the parameter "
On Wed, Aug 22, 2018 at 6:33 AM, Abe Dillon wrote:
> [Chris Angelico]
>>
>> I use decks of cards primarily for non-game
>> usage (for instance, teaching data structures and algorithms - cards
>> laid out on a table can represent a tree, heap, array, etc)
>
>
>
On Wed, Aug 22, 2018 at 8:45 AM, Abe Dillon wrote:
> [Chris Angelico]
>>
>> Python's parser is *deliberately* incapable of backtracking this far
>> in its definition of syntax.
>
>
> Can you explain how far the parser is capable of backtracking?
> It see
On Wed, Aug 22, 2018 at 12:48 PM, Abe Dillon wrote:
> [Steven D'Aprano]
>>
>> Replacing the keyword:
>> results = map(def a, b=2, c=3: a ** b / c, sequence)
>> widget.register(callback=def: spam.eggs())
>> Doesn't look so attractive now, I wager. Using "def" inside an
>> expression looks s
On Wed, Aug 22, 2018 at 12:57 PM, Abe Dillon wrote:
> [Chris Angelico]
>>
>> If you have a use-case for a lambda function that takes a callback and
>> has a default value for that callback, please submit it to The Daily
>> WTF. In Steve's example, the main function
On Thu, Aug 23, 2018 at 3:56 AM, Rhodri James wrote:
> On 22/08/18 14:38, Jonathan Fine wrote:
> def fn():
>>
>> ... if None:
>> ... yield
>> ...
>
> list(fn()) # Fails, unless fn is a generator function.
>>
>> []
Actually, it fails unless fn returns some sort of iterable.
On Thu, Aug 23, 2018 at 6:24 AM, David Mertz wrote:
> Oops. I blame the partial editing of copy/padte on doing it on my phone. I
> meant this, of course:
>
> widget.register(callback=spam.eggs)
This isn't quite the same, incidentally. It's (mostly) equivalent to:
widget.register(callback=lambda
On Thu, Aug 23, 2018 at 9:02 AM, Greg Ewing wrote:
> Rhodri James wrote:
>>
>> This, by the way, is why think using the same syntax for function
>> definition and generator definition was a mistake.
>
>
> I think I remember arguing the same thing back when generators
> were being devised.
>
> But
On Thu, Aug 23, 2018 at 10:44 AM, Abe Dillon wrote:
> The problem goes beyond just learning the term lambda, it can increase
> mental load on an already mentally demanding activity to have to translate
> an unfamiliar word every time you see it. It's lack of relation to anything
> else makes it ha
On Thu, Aug 23, 2018 at 11:59 AM, Abe Dillon wrote:
> [Chris Angelico]
>>
>> > I've also argued that the very form of lambda expressions is noisier
>> > than it
>> > otherwise needs to be. It's not like noise is only distracting to novice
>
On Sat, Aug 25, 2018 at 5:13 AM, Mike Barnett wrote:
> Here we go:
>
> Take 3 numbers as input (A, B, C). Add them together. Display the result in
> a simple pop-up window.
>
> That’s a pretty typical kind of problem for the first few weeks of beginning
> programming. Maybe first few days.
>
On Mon, Aug 27, 2018 at 10:50 PM, Steven D'Aprano wrote:
> On Mon, Aug 27, 2018 at 12:12:22PM +0100, Ivan Levkivskyi wrote:
>> Contract in 99% of cases is just another word for type (maybe a very
>> complex type like `DAG[T] <: Graph[T]`).
>> Everything else, like `x >= y` is better expressed as a
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
>
On Thu, Aug 30, 2018 at 4:30 PM, Jonathan Goble wrote:
> On Thu, Aug 30, 2018, 2:08 AM Greg Ewing
> wrote:
>>
>> Also, Fraction(1) for the second case would be flat-out wrong.
>
>
> How? Raising something to the 2/3 power means squaring it and then taking
> the cube root of it. -1 squared is 1, a
On Mon, Sep 3, 2018 at 5:23 PM, Jacco van Dorp wrote:
> This feels really useful to me to make some quick changes to a database -
> perhaps a database layer could return an class of type Recordclass, and then
> you just simply mutate it and shove it back into the database. Pseudocode:
>
> record =
On Mon, Sep 3, 2018 at 6:31 PM, Wes Turner wrote:
>
>
> On Mon, Sep 3, 2018 at 4:17 AM Chris Angelico wrote:
>>
>> On Mon, Sep 3, 2018 at 5:23 PM, Jacco van Dorp
>> wrote:
>> > This feels really useful to me to make some quick changes to a database
>&g
On Fri, Sep 7, 2018 at 4:11 AM, Franklin? Lee
wrote:
> On Tue, Aug 28, 2018 at 6:37 PM Greg Ewing
> wrote:
>>
>> 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
>>
On Fri, Sep 7, 2018 at 4:38 AM, Franklin? Lee
wrote:
> The following are equivalent and compile down to the same code:
> a, b, c = lst
> [a, b, c] = lst
>
> The left hand side is not an actual list (even though it looks like
> one). The brackets are optional. The docs call the left hand si
On Sat, Sep 8, 2018 at 10:21 PM, Anders Hovmöller wrote:
> It’s obvious but there is one easy way to shorten the code: using **kwargs.
> It’s way shorter but the down sides are:
>
> - the “real” function signature gets hidden so IDEs for example won’t pick it
> up
> - the error when you make a m
On Sat, Sep 8, 2018 at 11:41 PM, Jonathan Fine wrote:
> M.-A. Lemburg wrote:
>
>> Most likely yes, but they would not render RTL text by first
>> switching the direction and then printing them LTR again.
>>
>> Please also note that switching from LTR to RTL and back again
>> is possible within a U
On Sun, Sep 9, 2018 at 6:08 AM, Jonathan Fine wrote:
> Chris Angelico wrote:
>
>> Generally, problems with RTL text are *display* problems, and are not
>> solved by reversing strings.
>
> I very much agree with this statement, with one exception. If you wish
> to displa
On Sun, Sep 9, 2018 at 6:55 AM, Jonathan Fine wrote:
> Chris Angelico wrote:
>
>> Improving a rendering engine or console so it's capable of correct RTL
>> display is outside the scope of Python code, generally.
>
> I agree with you, generally.
>
> But there ar
On Sun, Sep 9, 2018 at 3:37 PM, Anders Hovmöller wrote:
>
>> You have carefully avoided explicitly accusing me of making a straw man
>> argument while nevertheless making a completely irrelevant mention of
>> it, associating me with the fallacy.
>
> I read that as him accusing you very directly.
>
On Sun, Sep 9, 2018 at 5:32 PM, Anders Hovmöller wrote:
>
>> I see it all the time in JavaScript, where ES2015 introduced a new
>> syntax {name} equivalent to {"name":name} - people will deliberately
>> change their variable names to match the desired object keys. So
>> saying "forcing" is an exag
On Tue, Sep 11, 2018 at 8:03 PM, Jonathan Fine wrote:
> In some case, the implementer might prefer
>
> def method(self, aaa, bbb, **kwargs):
>
> # Do something with aaa and bbb.
> super().method(**kwargs)
>
>
> However, the CALLER might wish that the implementer has a signature
On Tue, Sep 11, 2018 at 9:34 PM, Steven D'Aprano wrote:
> I think that __params__ as an implicitly created local variable is
> just barely justifiable, if you don't care about slowing down all
> function calls for the benefit of a tiny number of them. But exposing
> that information as an external
On Thu, Sep 13, 2018 at 10:16 PM, João Santos wrote:
> One important difference between master/slave and beautiful/ugly is that the
> first pair are concrete concepts that typically applies to people, and the
> second are abstract concepts that always applied also to objects and
> abstract concept
On Fri, Sep 14, 2018 at 3:57 AM, Mikhail V wrote:
> And I don't know what can be really 'beautiful'
> in _any_ code.
> Ugly - yes, it's often can be said about the code which is full of
> redundant punctuation, bad formatting, etc.
> But this sound strange: "this code is beautiful". Do people re
On Fri, Sep 14, 2018 at 1:41 PM, Tim Peters wrote:
> I presume "Zen" came to their mind because it's brief, and a critical
> reading reveals a number of seeming ambiguities and contradictions, yet it
> nevertheless _appears_ to say _something_ ;-)
"Somehow it seems to fill my head with ideas - on
On Fri, Sep 14, 2018 at 7:02 PM, Hans Polak wrote:
> I have recently updated my code to use the more pythonic f-string instead of
> '{}'.format()
Well there's your problem right there. Don't change your string
formatting choice on that basis. F-strings aren't "more Pythonic" than
either .format()
On Sat, Sep 15, 2018 at 6:09 AM, Davide Rizzo wrote:
> One way out of the impasse is to draw upon the feeling behind the
> adjective. We call "beautiful" something that appeals to us, makes us
> comfortable, or inspires us awe. Ugly is something that makes us
> uncomfortable, repels us, disconcert
On Sun, Sep 16, 2018 at 8:14 PM, Widom PsychoPath wrote:
> I hereby propose that the Language should be renamed to Cobra, after
> the brilliant military strategist Cobra Commander , who has been
> history's most efficient and brilliant strategist.
>
> Yours forever,
> Jack Daniels
Now THAT is the
On Mon, Sep 17, 2018 at 5:53 PM, Niki Spahiev wrote:
> On 14.09.2018 12:33, Chris Angelico wrote:
>>
>> On Fri, Sep 14, 2018 at 7:02 PM, Hans Polak wrote:
>>>
>>> I have recently updated my code to use the more pythonic f-string instead
>>> of
>>&g
On Wed, Sep 19, 2018 at 10:21 AM James Lu wrote:
>
> Not personally with Brett, but I have seen multiple people try to stop the
> “reword or remove beautiful is better than ugly in Zen of Python.” The
> discussion was going in circles and evolved into attacking each other’s use
> of logical fal
On Wed, Sep 19, 2018 at 10:43 AM Jan Claeys wrote:
>
> On Tue, 2018-09-18 at 18:07 -0400, David Mertz wrote:
> > Since 1972, there have been hundreds of reinventions of a means of
> > carying on electronic conversations intended to be "better than
> > email." The one thing they all have in common
8, 2018 at 5:57 PM Chris Angelico wrote:
> > For any proposal that actually has currency, this system does work
>
> The trouble is the ambiguity of knowing what "actually has currency"
> is and how to get it. PEP 1 states, "Following a discussion on
> python-ideas,
On Wed, Sep 19, 2018 at 3:55 PM Steve Barnes wrote:
> Surely the simpler solution is to specify in I18n any items within
> un-escaped {} pairs is excluded from the translation, lookups, etc., and
> that translation needs to take place, also leaving the {} content alone,
> before f string processin
On Wed, Sep 19, 2018 at 4:52 PM Anders Hovmöller wrote:
>
>
> > How about this: Have a script that runs over your code, looking for
> > "translatable f-strings":
> >
> > _(f'Hi {user}')
> >
> > and replaces them with actually-translatable strings:
> >
> > _('Hi %s') % (user,)
> > _('Hi {user}').fo
On Wed, Sep 19, 2018 at 11:23 PM Michel Desmoulin
wrote:
> - A is telling B this is a bad idea. It should be easy to tell if the
> person is experienced or not. You probably don't want to interact the
> same way with Victor and Yury, that have done numerous contributions to
> the Python core, and
On Fri, Sep 21, 2018 at 8:52 AM Kyle Lahnakoski wrote:
> Since the java.lang.Thread.stop() "debacle", it has been obvious that
> stopping code to run other code has been dangerous. KeyboardInterrupt
> (any interrupt really) is dangerous. Now, we can probably code a
> solution, but how about we re
On Tue, Sep 25, 2018 at 1:10 AM Erik Bray wrote:
>
> On Fri, Sep 21, 2018 at 12:58 AM Chris Angelico wrote:
> >
> > On Fri, Sep 21, 2018 at 8:52 AM Kyle Lahnakoski
> > wrote:
> > > Since the java.lang.Thread.stop() "debacle", it has been obvious tha
On Wed, Sep 26, 2018 at 3:19 AM Marko Ristin-Kaufmann
wrote:
>> Claiming that DbC annotations will improve the documentation of every
>> single library on PyPI is an extraordinary claim, and such claims
>> require extraordinary proof.
>
>
> I don't know what you mean by "extraordinary" claim and "
On Wed, Sep 26, 2018 at 6:09 AM Lee Braiden wrote:
>
> Eh. It's too easy to cry "show me the facts" in any argument. To do that too
> often is to reduce all discussion to pendantry.
>
> That verifying data against the contract a function makes code more reliable
> should be self evident to anyo
On Wed, Sep 26, 2018 at 7:59 AM Kyle Lahnakoski wrote:
> I use DbC occasionally to clarify my thoughts during a refactoring, and then
> only in the places that continue to make mistakes. In general, I am not in a
> domain that benefits from DbC.
>
> Contracts are code: More code means more bugs.
On Wed, Sep 26, 2018 at 12:35 PM Michael Selik wrote:
>
> On Tue, Sep 25, 2018 at 8:46 PM Mikhail V wrote:
> > I suggest allowing "while:" syntax for the infinite loop.
> > I.e. instead of "while 1:" and "while True:" notations.
> >
> > My opinion:
> > 1. I think it'd definitely improve clarity
On Wed, Sep 26, 2018 at 1:29 PM Mikhail V wrote:
>
> On Wed, Sep 26, 2018 at 5:38 AM Chris Angelico wrote:
> >
> >
> > I like saying while "something": where the string describes the loop's
> > real condition. For instance, while "moar
On Wed, Sep 26, 2018 at 2:47 PM Marko Ristin-Kaufmann
wrote:
>
> Hi Chris,
>
>> An extraordinary claim is like "DbC can improve *every single project*
>> on PyPI". That requires a TON of proof. Obviously we won't quibble if
>> you can only demonstrate that 99.95% of them can be improved, but you
>
On Wed, Sep 26, 2018 at 5:10 PM Marko Ristin-Kaufmann
wrote:
> The original objection was that DbC in general is not beneficial; not that
> there are lacking tools for it (this probably got lost in the many messages
> on this thread). If you assume that there are no suitable tools for DbC, then
On Wed, Sep 26, 2018 at 5:51 PM Marko Ristin-Kaufmann
wrote:
>
> Hi Chris,
>
>> It's easy to say that they're boolean expressions. But that's like
>> saying that unit tests are just a bunch of boolean expressions too.
>> Why do we have lots of different forms of test, rather than just a big
>> fat
On Wed, Sep 26, 2018 at 6:36 PM Paul Moore wrote:
>
> On Wed, 26 Sep 2018 at 06:41, Chris Angelico wrote:
> >
> > On Wed, Sep 26, 2018 at 2:47 PM Marko Ristin-Kaufmann
> > wrote:
> > > * The contracts written in documentation as human text inevitably rot a
On Wed, Sep 26, 2018 at 6:37 PM Chris Angelico wrote:
>
> On Wed, Sep 26, 2018 at 5:51 PM Marko Ristin-Kaufmann
> wrote:
> >
> > Hi Chris,
> >
> >> It's easy to say that they're boolean expressions. But that's like
> >> saying that unit
On Wed, Sep 26, 2018 at 11:04 PM Marko Ristin-Kaufmann
wrote:
> @Chris Angelico would annotating pathlib convince you that contracts are
> useful? Is it general enough to start with?
>
I won't promise it'll convince me, but it'll certainly be a
starting-point for real
On Thu, Sep 27, 2018 at 5:07 AM Chris Barker wrote:
>
> On Tue, Sep 25, 2018 at 10:10 PM Lee Braiden wrote:
>>
>> It's the reason why type checking exists, and why bounds checking exists,
>> and why unit checking exists too.
>
> And yet Python has none of those. They all provide safety, but also
On Thu, Sep 27, 2018 at 8:53 AM Robert Collins
wrote:
>
> On Thu, 27 Sep 2018 at 00:44, Marko Ristin-Kaufmann
> wrote:
> >
> > P.S. My offer still stands: I would be very glad to annotate with contracts
> > a set of functions you deem representative (e.g., from a standard library
> > or from so
On Thu, Sep 27, 2018 at 9:22 AM Robert Collins
wrote:
>
> On Thu., 27 Sep. 2018, 11:00 Chris Angelico, wrote:
>>
>> On Thu, Sep 27, 2018 at 8:53 AM Robert Collins
>> wrote:
>> >
>> > On Thu, 27 Sep 2018 at 00:44, Marko Ristin-Kaufmann
>> >
On Thu, Sep 27, 2018 at 10:07 AM Robert Collins
wrote:
>
> On 27 September 2018 at 11:50, Chris Angelico wrote:
>
> > Okay, but what is the contract that's being violated when you use
> > data= ? How would you define the contract that this would track?
> > Tha
On Thu, Sep 27, 2018 at 3:31 PM Greg Ewing wrote:
>
> Chris Angelico wrote:
> > if you let your API
> > docs rot when you make changes that callers need to be aware of, you
> > have failed your callers.
>
> Yes, I find that documentation auto-generated from code 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:
> te
On Fri, Sep 28, 2018 at 6:56 PM Jonathan Fine wrote:
> Finally, I note
>
> >>> a = 2
> >>> a **= 3
> >>> a
> 8
>
? Yes? That's what 2 ** 3 is, so that's what I would expect.
All other augmented assignment operators take an assignment target on
the left and a (single) value on the right.
ChrisA
On Fri, Sep 28, 2018 at 11:25 AM Marko Ristin-Kaufmann
wrote:
>
> 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 jus
On Fri, Sep 28, 2018 at 7:29 PM Jonathan Fine wrote:
>
> I like this discussion. I'd like to add another theme, namely what
> should happen when there is an error. (This is prompted by race
> hazards when performing file system operations.)
>
> Suppose fn_a() calls fn_b(), and fn_b() raises an exc
On Sat, Sep 29, 2018 at 7:19 AM Greg Ewing wrote:
>
> Chris Angelico wrote:
> > It is still fundamentally difficult to make assertions about the file
> > system as pre/post contracts.
>
> When you consider race conditions, I'd say it's impossible.
> A postcond
On Sat, Sep 29, 2018 at 10:22 AM Dan Sommers
<2qdxy4rzwzuui...@potatochowder.com> wrote:
>
> On 9/28/18 7:39 PM, Steven D'Aprano wrote:
> > But none of that compares to C undefined behaviour. People who think
> > that they are equivalent, don't understand C undefined behaviour.
>
> Well, yes: Some
On Sat, Sep 29, 2018 at 9:43 PM Steven D'Aprano wrote:
>
> On Sat, Sep 29, 2018 at 10:32:16AM +1000, Chris Angelico wrote:
>
> > What should happen here?
> >
> > >>> import ctypes
> > >>> ctypes.cast(id(1), ctypes.POINTER(ctypes.c_int))[6]
On Sun, Sep 30, 2018 at 12:43 AM Steven D'Aprano wrote:
>
> On Sat, Sep 29, 2018 at 10:15:42PM +1000, Chris Angelico wrote:
>
> [...]
> > As are all the things that are "undefined behaviour" in C, like the
> > result of integer overflow in a signed
On Sun, Sep 30, 2018 at 11:54 AM Steven D'Aprano wrote:
> This discussion is for those of us who would like to include DbC in our
> projects but don't like existing solutions. C++ being designed with a
> shovel is not relevant.
>
> (Except in the sense that we should always be careful about piling
On Sun, Sep 30, 2018 at 2:27 PM Steven D'Aprano wrote:
>
> On Sun, Sep 30, 2018 at 12:17:25PM +1000, Chris Angelico wrote:
> > On Sun, Sep 30, 2018 at 11:54 AM Steven D'Aprano
> > wrote:
> > > This discussion is for those of us who would like to include DbC
On Sun, Sep 30, 2018 at 6:03 PM Steven D'Aprano wrote:
>
> On Sun, Sep 30, 2018 at 02:50:28PM +1000, Chris Angelico wrote:
>
> > And yet all the examples I've seen have just been poor substitutes for
> > unit tests. Can we get some examples that actually do a bett
On Mon, Oct 1, 2018 at 12:18 AM David Mertz wrote:
>
> For similar reasons, I'd like an iInf too, FWIW. It's good for an overflow
> value, although it's hard to get there in Python ints (would
> 'NaNAwareInt(1)/0' be an exception or iInf?). Bonus points for anyone who
> knows the actual maxim
On Mon, Oct 1, 2018 at 12:44 AM David Mertz wrote:
>
> On Sun, Sep 30, 2018 at 10:23 AM Chris Angelico wrote:
>>
>> On Mon, Oct 1, 2018 at 12:18 AM David Mertz wrote:
>> > Bonus points for anyone who knows the actual maximum size of Python ints
>> > :-).
On Mon, Oct 1, 2018 at 12:45 AM Anders Hovmöller wrote:
> But making any change to the basic types truth table is a big -1 from me.
> This seems like a Python 2-3 transition to me.
>
Far FAR worse than anything that changed in Py2->Py3.
ChrisA
___
Pyt
On Mon, Oct 1, 2018 at 12:58 AM David Mertz wrote:
>> I'm not sure what's going on. I have a Py3 busily calculating
>> 2**(2**65) and it's pegging a CPU core while progressively consuming
>> memory, but it responds to Ctrl-C, which suggests that Python bytecode
>> is still being executed.
>
>
> I'
701 - 800 of 2716 matches
Mail list logo
