On 8/25/17 12:10 AM, Paul Rubin wrote:
> Steve D'Aprano writes:
>> Did __next__ cache the most recently generated value?
> No but if they're going to change stuff, they might as well actually
> improve it instead of just renaming it to break code gratutiously.
The vast majority of iteration has n
On Fri, Aug 25, 2017 at 2:10 PM, Paul Rubin wrote:
> Steve D'Aprano writes:
>> Did __next__ cache the most recently generated value?
>
> No but if they're going to change stuff, they might as well actually
> improve it instead of just renaming it to break code gratutiously.
Any code that called
Steve D'Aprano writes:
> Did __next__ cache the most recently generated value?
No but if they're going to change stuff, they might as well actually
improve it instead of just renaming it to break code gratutiously.
--
https://mail.python.org/mailman/listinfo/python-list
On Fri, 25 Aug 2017 01:19 pm, Paul Rubin wrote:
> Steve D'Aprano writes:
>> the public API is to call the next() built-in function, and the
>> implementation is the __next__ dunder.
>
> In that case it would have been nice to make next() cache the most
> recently generated value from the iterato
Steve D'Aprano writes:
> the public API is to call the next() built-in function, and the
> implementation is the __next__ dunder.
In that case it would have been nice to make next() cache the most
recently generated value from the iterator. That would make lots of
code simpler.
--
https://mail.
Op 24-08-17 om 04:02 schreef Steve D'Aprano:
>
> Unfortunately the interwebs are full of people, even mathematicians, that
> have a
> lot of misapprehensions and misunderstandings of Gödel's Incompleteness
> Theorems. For example, there's a comment here:
>
> "It's easy to prove that ZFC is consist
On Thu, 24 Aug 2017 06:21 pm, Paul Rubin wrote:
> Peter Otten <__pete...@web.de> writes:
>> Python 3 where the next() method has been renamed to __next__().
>
> Oh cripes, you're right, it never occurred to me that py3 had broken
> .next(). I thought it was called .next() instead of .__next()
>
Chris Angelico writes:
> On Thu, Aug 24, 2017 at 8:40 PM, Ben Finney
> wrote:
> > Paul Rubin writes:
> >> Is something wrong with:
> >>
> >> >>> g = itertools.count().next
>
> It's on all iterators; it's the Py2 equivalent for __next__.
Yeah, when people are talking today about “Python”,
On Thu, Aug 24, 2017 at 8:40 PM, Ben Finney wrote:
> Paul Rubin writes:
>
>> Ben Finney writes:
>> > generate_id = functools.partial(next, itertools.count())
>>
>> Is something wrong with:
>>
>> >>> g = itertools.count().next
>
> I wasn't looking for a ‘next’ method on the iterator. Is t
Paul Rubin writes:
> Ben Finney writes:
> > generate_id = functools.partial(next, itertools.count())
>
> Is something wrong with:
>
> >>> g = itertools.count().next
I wasn't looking for a ‘next’ method on the iterator. Is that special to
the ‘itertools.count’ type?
If so, I was attempt
Paul Rubin :
> Ben Finney writes:
>> generate_id = functools.partial(next, itertools.count())
>
> Is something wrong with:
>
> >>> g = itertools.count().next
I don't like lambda in Python. However, I like it better than
functools.partial.
Best of all, define an inner function.
Marko
-
Peter Otten <__pete...@web.de> writes:
> Python 3 where the next() method has been renamed to __next__().
Oh cripes, you're right, it never occurred to me that py3 had broken
.next(). I thought it was called .next() instead of .__next()
so that it wouldn't be a dunder method.
--
https://mail.pyt
Paul Rubin wrote:
> Ben Finney writes:
>> generate_id = functools.partial(next, itertools.count())
>
> Is something wrong with:
>
> >>> g = itertools.count().next
That question seems to be the topic of this subthread.
Other than the principle "never call a dunder method" (that I do no
Steve D'Aprano writes:
> I've read a few people claim that disallowing multiplication from
> standard arithmetic renders it weak enough that you can prove it
> complete and correct, but since they give no proof or even evidence I
> have my doubts.
That system is called Presburger arithmetic (see
On Thu, Aug 24, 2017 at 5:47 PM, Paul Rubin wrote:
> Ben Finney writes:
>> generate_id = functools.partial(next, itertools.count())
>
> Is something wrong with:
>
> >>> g = itertools.count().next
> >>> g()
> 0
> >>> g()
> 1
> >>> g()
> 2
> >>> ...
That's the P
Ben Finney writes:
> generate_id = functools.partial(next, itertools.count())
Is something wrong with:
>>> g = itertools.count().next
>>> g()
0
>>> g()
1
>>> g()
2
>>> ...
--
https://mail.python.org/mailman/listinfo/python-list
On Tue, 22 Aug 2017 07:41 pm, Marko Rauhamaa wrote:
> BTW, the main take of the metamathematical "fiasco" was that you can't
> get rid of the meta-level. There's no consistent logical system that is
> closed and encompasses everything including itself. You will always have
> to step outside your f
Op 2017-08-23, Ben Finney schreef :
> Could you be convinced to instead do::
>
> import functools
> import itertools
>
> generate_id = functools.partial(next, itertools.count())
I certainly could be, but I was so far unaware of the desirability to do so.
Stephan
--
https://mail.pytho
On Tue, 22 Aug 2017 11:42 pm, Ian Kelly wrote:
> The last line is the reason why the rich comparison methods should
> have been designed to raise NotImplementedException rather than return
> NotImplemented, but it's too late to change that.
Only if you want operators to be slow as molasses.
*win
Since this erm… discussion has also brought in Haskell
and in this case, the name, the history etc are related I thought I'd mention
the following
Around 2015 there was a major upheaval in the Haskell community around the
socalled FTP (foldable-traversable-prelude) controversy.
In many respects
Gregory Ewing :
> Marko Rauhamaa wrote:
>> You will always have to step outside your formal system and resort to
>> hand-waving in a natural language.
>
> If the hand-waving is rigorous, this amounts to expanding your formal
> system by adding new axioms and/or rules to it.
Ultimately, it's not r
Stephan Houben writes:
> I have often done things like:
>
> generate_id = itertools.count().__next__
Could you be convinced to instead do::
import functools
import itertools
generate_id = functools.partial(next, itertools.count())
--
\“The right to search for truth imp
Marko Rauhamaa wrote:
You will always have
to step outside your formal system and resort to hand-waving in a
natural language.
If the hand-waving is rigorous, this amounts to expanding your
formal system by adding new axioms and/or rules to it.
If the hand-waving is not rigorous, then you have
On Wed, Aug 23, 2017 at 1:12 AM, Stephan Houben
wrote:
> Op 2017-08-22, Ian Kelly schreef :
>> Careful! Python's dunder methods are reserved for use by Python.
>> They're exposed so that we can override them. Calling them directly is
>> generally considered bad style. And in this case specifically
Op 2017-08-22, Ian Kelly schreef :
> Careful! Python's dunder methods are reserved for use by Python.
> They're exposed so that we can override them. Calling them directly is
> generally considered bad style. And in this case specifically, it's
> not equivalent.
Mmm, you are correct. That's kind
On Tue, Aug 22, 2017 at 3:58 AM, Stephan Houben
wrote:
> Op 2017-08-11, Paul Rubin schreef :
>> I don't think we need this since we have itertools.takewhile:
>>
>> from operator import gt
>> from functools import partial
>> from itertools import takewhile
>>
>> [x + 1 for x in takewhile(pa
On 8/21/17, Chris Angelico wrote:
> On Mon, Aug 21, 2017 at 12:19 PM, MRAB wrote:
>> On 2017-08-21 03:00, Steve D'Aprano wrote:
>>>
>>> On Fri, 18 Aug 2017 04:55 pm, Marko Rauhamaa wrote:
>>>
Is a Python implementation
allowed to parallelize or otherwise reorder the evaluation loop?
>>>
Op 2017-08-11, Paul Rubin schreef :
> I don't think we need this since we have itertools.takewhile:
>
> from operator import gt
> from functools import partial
> from itertools import takewhile
>
> [x + 1 for x in takewhile(partial(gt,5), (0,1,2,999,3,4))]
>
No need for partial and gt.
Paul Rubin :
> As you mention, Russell was the one who recognized the inconsistency
> in Frege's system, though I don't know how Frege took it at a personal
> level.
I read (can't remember where) that Frege was just finishing his third
and final volume when Russell's paradox was brought to his att
Steve D'Aprano wrote:
from io import StringIO # simulate reading from a file
myfile = StringIO('Is this the room for an argument?')
values = [myfile.read(1) for i in range(33)]
print(''.join(values))
Which is a very contrived and longwinded way to write
print(myfile.read(33))
and would b
Rustom Mody writes:
> Do you mean Frege or Cantor?
Frege. Cantor was concerned with set theory, while Frege was concerned
with logic in general. Frege's notation was different from what we use
now but the issue was about the same: unrestricted comprehension led to
contradiction. As you mention
On Sunday, August 20, 2017 at 11:00:22 AM UTC+5:30, Paul Rubin wrote:
> Rustom Mody writes:
> > Specifically the term 'comprehension' used today as a programming construct
> > traces somewhat tenuously to an axiom that Zermelo/Fraenkel formulated
> > in the 1920s
>
> I thought went back to Frege.
On 8/20/2017 12:28 AM, Rustom Mody wrote:
Lives today in python in the fact that the russel-set gives a straightforward
syntax error and nothing more grandly profound
R = {x if x not in x}
R = {x for x not in x}
Try the actual Python syntax set builder expression and you get
executable co
On Fri, 18 Aug 2017 04:16 pm, Paul Rubin wrote:
[...]
> Similarly we occasionally have to be aware of the procedural nature
> of Python list comprehensions, but most of the time we think of them
> in terms of the mathematical abstraction they are designed to resemble.
Thanks Paul, you've given m
On Mon, Aug 21, 2017 at 12:19 PM, MRAB wrote:
> On 2017-08-21 03:00, Steve D'Aprano wrote:
>>
>> On Fri, 18 Aug 2017 04:55 pm, Marko Rauhamaa wrote:
>>
>>> Is a Python implementation
>>> allowed to parallelize or otherwise reorder the evaluation loop?
>>
>>
>> No.
>>
> [snip]
>
> Well, I suppose a
On 2017-08-21 03:00, Steve D'Aprano wrote:
On Fri, 18 Aug 2017 04:55 pm, Marko Rauhamaa wrote:
Is a Python implementation
allowed to parallelize or otherwise reorder the evaluation loop?
No.
[snip]
Well, I suppose an implementation _could_ parallelise, or whatever,
_provided that_ it gave
On Fri, 18 Aug 2017 04:55 pm, Marko Rauhamaa wrote:
> Is a Python implementation
> allowed to parallelize or otherwise reorder the evaluation loop?
No.
I initially was going to just say "Read the PEP, read the What's New from 2.0,
read the docs, notice the deliberate use of the same terminology
On Sun, 20 Aug 2017 02:28 pm, Rustom Mody wrote:
>> >> | S = {2·x | x ∈ ℕ, x ≤ 10}
[...]
> There's more than just a nit-pick wrong with that expression
The expression is fine. It is a mathematical expression, not Haskell code, so
your example of Haskell code is irrelevant to judging maths notatio
On Sun, Aug 20, 2017 at 2:28 PM, Rustom Mody wrote:
> So if Chris can answer how to teach music to a tone-deaf person, I can
> consider how to answer the question of how to teach programming to a
> math-challenged one
You don't HAVE to understand math to be a programmer. Plenty of
math-challenge
Rustom Mody writes:
> Specifically the term 'comprehension' used today as a programming construct
> traces somewhat tenuously to an axiom that Zermelo/Fraenkel formulated
> in the 1920s
I thought went back to Frege. Also, it appears in Zermelo set theory Z.
ZF is Z with the Axiom of Replacement
On Saturday, August 19, 2017 at 9:45:48 AM UTC+5:30, Steve D'Aprano wrote:
> On Sat, 19 Aug 2017 12:59 am, Chris Angelico wrote:
>
> > On Fri, Aug 18, 2017 at 11:46 PM, Rustom Mody wrote:
> >> Compare the well-known haskell tutorial
> >> http://learnyouahaskell.com/starting-out
> >> whose compreh
On Sat, 19 Aug 2017 03:42 pm, Chris Angelico wrote:
>> [1] Assuming that mathematics actually is sound, which thanks to Gödel we
>> [know
>> is unprovable.
>
> Harmony in audio signals is based on frequency ratios. Therefore sound
> is mathematics, and by the reflexive principle of equality,
> ma
On Sat, Aug 19, 2017 at 2:15 PM, Steve D'Aprano
wrote:
> Indeed. People find imperative (recipe) algorithms easy to follow, and pure
> functional reasoning hard. I'm glad that functional programming is fashionable
> again, and hope that people will learn good habits from it, but I think that
> mat
On Sat, 19 Aug 2017 12:59 am, Chris Angelico wrote:
> On Fri, Aug 18, 2017 at 11:46 PM, Rustom Mody wrote:
>> Compare the well-known haskell tutorial
>> http://learnyouahaskell.com/starting-out
>> whose comprehension intro starts:
>>
>> | If you've ever taken a course in mathematics, you've proba
On Fri, 18 Aug 2017 11:46 pm, Rustom Mody wrote:
> My issue is that the tutorial introduces comprehensions backwards, as though
> they are a macro for the for-loop
Python doesn't have macros as such, but if it did, that would be a good way to
describe comprehensions.
Another way would be to say
On Thu, 17 Aug 2017 03:54 pm, Marko Rauhamaa wrote:
> Ben Finney :
>
>> The Python list comprehension syntax does not specify control flow.
>
> I understand your point, but how do you know your statement is true?
>
> I didn't check this, but I would imagine the list comprehension:
>
>[ f(x
On Fri, Aug 18, 2017 at 11:46 PM, Rustom Mody wrote:
> Compare the well-known haskell tutorial
> http://learnyouahaskell.com/starting-out
> whose comprehension intro starts:
>
> | If you've ever taken a course in mathematics, you've probably run into set
> | comprehensions. They're normally used f
There is code and there are machines
There are Turing machines and Universal Turing machines
There are programs and there are programming languages
There are (il)legal programs and best/worst (software engineering) practices
As best as I can see most of us are talking of the respective latters abo
Marko Rauhamaa writes:
> The question is, is it bad style—or even an error—to rely on the
> execution order of the comprehension loops?
Bad style: IMO, yes, most of the time. I've made use of it at
particular times. If it's done in an obscure way it at least
deserves a code commment.
Error: n
Paul Rubin :
> Steve D'Aprano writes:
>> For loops and comprehensions (in Python) are inherently procedural,
>
> Sure, and floating point arithmetic is inherently imprecise and
> doesn't follow the associative laws for either addition or
> multiplication. There are times when we have to be aware
Steve D'Aprano writes:
> For loops and comprehensions (in Python) are inherently procedural,
Sure, and floating point arithmetic is inherently imprecise and doesn't
follow the associative laws for either addition or multiplication.
There are times when we have to be aware of those details. Usual
On 8/17/17, Marko Rauhamaa wrote:
> Pavol Lisy :
>
>> On 8/17/17, Gregory Ewing wrote:
>>> I don't agree that the word "for" necessarily implies proceduralness.
>>
>> With this logic (I humbly think that) word "while" neither
>> necessarilly implies proceduralness.
>
> I don't see the logic.
>
>
On Thu, Aug 17, 2017 at 11:05 PM, Steve D'Aprano
wrote:
> On Fri, 18 Aug 2017 06:28 am, Ian Kelly wrote:
>> "while" implies a condition that is currently true and may at some
>> point stop being true. To me, that sequentiality does imply
>> proceduralness.
>
> For loops and comprehensions (in Pyth
On Fri, 18 Aug 2017 06:28 am, Ian Kelly wrote:
> On Thu, Aug 17, 2017 at 1:19 PM, Pavol Lisy wrote:
>> On 8/17/17, Gregory Ewing wrote:
>>> Steve D'Aprano wrote:
If he wanted declarative semantics, why didn't he argue for declarative
syntax
like "select...where", instead of choosi
On Fri, 18 Aug 2017 01:11 am, Lew Pitcher wrote:
> Marko Rauhamaa wrote:
>> I guess we have C to blame for the redefinition of the word "for" in
>> programmers' minds.
>
> Sorry, but that use of "for" was part of the programmer's lexicon well
> before the invention of C. Computer languages have
On Fri, Aug 18, 2017 at 11:13 AM, Steve D'Aprano
wrote:
> Within a single language, it is common to have both procedural and declarative
> statements. E.g. in Python for statements are clearly procedural flow control.
> But "import" can be read as a declarative statement:
>
> "Load this module, I
On Thu, 17 Aug 2017 10:47 pm, Gregory Ewing wrote:
> Steve D'Aprano wrote:
>> Do you consider:
>>
>> for foo in bar:
>> if baz(foo):
>> f(foo) # append to a list, or print, or yield, as needed
>>
>> declarative?
>
> No. But the reason for that is not because it has the word
> "for"
On Thu, Aug 17, 2017 at 1:19 PM, Pavol Lisy wrote:
> On 8/17/17, Gregory Ewing wrote:
>> Steve D'Aprano wrote:
>>> If he wanted declarative semantics, why didn't he argue for declarative
>>> syntax
>>> like "select...where", instead of choosing procedural syntax which matches
>>> the
>>> actual p
Pavol Lisy :
> On 8/17/17, Gregory Ewing wrote:
>> I don't agree that the word "for" necessarily implies proceduralness.
>
> With this logic (I humbly think that) word "while" neither
> necessarilly implies proceduralness.
I don't see the logic.
Here's a random page from an algebra textbook:
On 8/17/17, Gregory Ewing wrote:
> Steve D'Aprano wrote:
>> If he wanted declarative semantics, why didn't he argue for declarative
>> syntax
>> like "select...where", instead of choosing procedural syntax which matches
>> the
>> actual procedural semantics given?
>
> I don't agree that the word "
Marko Rauhamaa wrote:
> Gregory Ewing :
>> I don't agree that the word "for" necessarily implies proceduralness.
>
> Programming languages stole the word from math, where it is
> nonprocedural.
>
> Really, "for" is just a preposition. In Algol, for example,
> proceduralness was not in the word "
On Thursday, August 17, 2017 at 8:13:24 PM UTC+5:30, Marko Rauhamaa wrote:
> Gregory Ewing :
> > I don't agree that the word "for" necessarily implies proceduralness.
>
> Programming languages stole the word from math, where it is
> nonprocedural.
>
> Really, "for" is just a preposition. In Algol
Gregory Ewing :
> I don't agree that the word "for" necessarily implies proceduralness.
Programming languages stole the word from math, where it is
nonprocedural.
Really, "for" is just a preposition. In Algol, for example,
proceduralness was not in the word "for" but in "do":
for p := 1 step
On Thursday, August 17, 2017 at 5:51:45 PM UTC+5:30, Gregory Ewing wrote:
> Steve D'Aprano wrote:
> > If he wanted declarative semantics, why didn't he argue for declarative
> > syntax
> > like "select...where", instead of choosing procedural syntax which matches
> > the
> > actual procedural sem
Steve D'Aprano wrote:
Do you consider:
for foo in bar:
if baz(foo):
f(foo) # append to a list, or print, or yield, as needed
declarative?
No. But the reason for that is not because it has the word
"for" in it. The reason is that it's made up of statements.
Statements are procedur
Steve D'Aprano wrote:
If he wanted declarative semantics, why didn't he argue for declarative syntax
like "select...where", instead of choosing procedural syntax which matches the
actual procedural semantics given?
I don't agree that the word "for" necessarily implies proceduralness.
--
Greg
-
Ben Finney :
> The Python list comprehension syntax does not specify control flow.
I understand your point, but how do you know your statement is true?
I didn't check this, but I would imagine the list comprehension:
[ f(x) for x in I if c(x) ]
was defined as syntactic sugar for:
list(f
Steve D'Aprano writes:
> On Thu, 17 Aug 2017 12:28 am, Ben Finney wrote:
>
> > Steve D'Aprano writes:
> >
> >> If he wanted declarative semantics, why didn't he argue for
> >> declarative syntax like "select...where", instead of choosing
> >> procedural syntax which matches the actual procedura
On Wed, 16 Aug 2017 11:53 pm, jmp wrote:
> On 08/10/2017 04:28 PM, Steve D'Aprano wrote:
>> Every few years, the following syntax comes up for discussion, with some
>> people saying it isn't obvious what it would do, and others disagreeing and
>> saying that it is obvious. So I thought I'd do an i
On Thu, 17 Aug 2017 12:28 am, Ben Finney wrote:
> Steve D'Aprano writes:
>
>> If he wanted declarative semantics, why didn't he argue for
>> declarative syntax like "select...where", instead of choosing
>> procedural syntax which matches the actual procedural semantics given?
>
> The syntax “f(
On 10/08/2017 16:28, Steve D'Aprano wrote:
What would you expect this syntax to return?
[x + 1 for x in (0, 1, 2, 999, 3, 4) while x < 5]
[1, 2, 3]
For comparison, what would you expect this to return? (Without actually trying
it, thank you.)
[x + 1 for x in (0, 1, 2, 999, 3, 4) if x < 5]
Steve D'Aprano writes:
> If he wanted declarative semantics, why didn't he argue for
> declarative syntax like "select...where", instead of choosing
> procedural syntax which matches the actual procedural semantics given?
The syntax “f(foo) for foo in bar if baz(foo)” is nicely declarative.
> I
On 08/10/2017 04:28 PM, Steve D'Aprano wrote:
Every few years, the following syntax comes up for discussion, with some people
saying it isn't obvious what it would do, and others disagreeing and saying
that it is obvious. So I thought I'd do an informal survey.
What would you expect this syntax
On Tue, 15 Aug 2017 09:10 am, Ben Finney wrote:
> Steve D'Aprano writes:
>
>> On Mon, 14 Aug 2017 07:59 pm, Ben Finney wrote:
>> > You began by asking what people would expect syntax to mean.
>> >
>> > Then you expressed surprise that anyone would think a comprehension
>> > would be interpreted
Gregory Ewing writes:
> The whole reason to write something as a comprehension is because you
> want to express it declaratively. You're saying "this is the list I
> want, I don't care how you compute it."
That's certainly a strong reason for my choosing comprehension
expressions: when I don't w
Steve D'Aprano wrote:
I take issue with your statement that relying on order of evaluation is always
"a very bad idea".
Perhaps what I should say is that relying on side effects in
an expression occurring in a particular order is a bad idea.
Boolean operators are a well-understood special case
On Tue, 15 Aug 2017 08:26 am, Gregory Ewing wrote:
> Ben Finney wrote:
>> That the comprehension
>> syntax *does not* necessarily connote a procedural loop, but instead can
>> quite reasonably be interpreted as its designer intended, a single
>> conceptual operation.
>
> To put it another way: Co
On Tuesday, August 15, 2017 at 5:48:43 PM UTC+5:30, Steve D'Aprano wrote:
> On Tue, 15 Aug 2017 02:54 pm, Rustom Mody wrote:
>
> > On Monday, August 14, 2017 at 10:35:22 PM UTC+5:30, Terry Reedy wrote:
> [...]
> >> Suppose stdin contains "a\nb\nc\nd\ne\nf\ng\n".
> >> What is the meaning of
> >> [i
On Tue, 15 Aug 2017 02:54 pm, Rustom Mody wrote:
> On Monday, August 14, 2017 at 10:35:22 PM UTC+5:30, Terry Reedy wrote:
[...]
>> Suppose stdin contains "a\nb\nc\nd\ne\nf\ng\n".
>> What is the meaning of
>> [input(f"response{i}") for i in range(6)]?
>> In Python, the predictable result is
>> ['a'
On Tue, 15 Aug 2017 01:26 pm, Paul Rubin wrote:
> Steve D'Aprano writes:
[...]
>> In Haskell, you cannot get the last N elements of a list without
>> allocating memory for the previous ones.
>
> lastn n xxs@(x:xs)
> | length (take n xs) == n-1 = xxs
> | otherwise = lastn n xs
>
Paul Rubin wrote:
Historically (in "naive set theory") we didn't bother with any of this.
We could write { S : S \not\in S } for the set of all sets that are not
members of themselves. Is S a member of itself ("Russell's paradox")?
Either way leads to contradiction. So the comprehension axiom s
On Mon, Aug 14, 2017 at 8:24 PM, Steve D'Aprano
wrote:
> I think the closest analogy in Python terms would be a generator expression
> with
> a cache. That's not *quite* the same, because Python is eagerly evaluated and
> Haskell is lazily evaluated, but the critical fact (which Ian seems to have
On Monday, August 14, 2017 at 10:35:22 PM UTC+5:30, Terry Reedy wrote:
> On 8/14/2017 5:59 AM, Ben Finney wrote:
>
> > At what point will you accept the feedback: That the comprehension
> > syntax *does not* necessarily connote a procedural loop, but instead can
> > quite reasonably be interpreted
On Tuesday, August 15, 2017 at 3:57:22 AM UTC+5:30, Gregory Ewing wrote:
> Ben Finney wrote:
> > That the comprehension
> > syntax *does not* necessarily connote a procedural loop, but instead can
> > quite reasonably be interpreted as its designer intended, a single
> > conceptual operation.
>
>
Paul Rubin writes:
> FORALL P. [ P(0) and P(n) -> P(n+1) ]
Sorry, that was supposed to say
FORALL P. [ (P(0) and P(n) -> P(n+1)) -> forall n. P(n) ]
FORALL quantifies over formulas and forall quantifies over numbers.
Maybe something is still missing from the above ;-).
--
https://mail.pyt
Marko Rauhamaa writes:
> For the non-logicians in the audience, an "axiom schema" is a generator
> pattern that produces an infinity of actual axioms.
For non-logicians this is not worth worrying about: schemas are
basically a technical hack to get around the inability of first-order
logic to qu
Steve D'Aprano writes:
> It's quite clever, actually, in that it gives *pseudo* random-access
> with lazy evaluation. You can evaluate the Nth element without
> evaluating the earlier ones. But you can't do so without *storing* the
> previous ones, they have to be allocated, with only the actual
>
On Tue, 15 Aug 2017 01:40 am, Chris Angelico wrote:
[...]
>> A Haskell list comprehension is not a loop at all.
>
> What if you don't take the first four, but instead take just the tenth
> element? Will the preceding elements be calculated too, or do you have
> a sparse list?
Both. Or neither.
Steve D'Aprano writes:
> On Mon, 14 Aug 2017 07:59 pm, Ben Finney wrote:
> > You began by asking what people would expect syntax to mean.
> >
> > Then you expressed surprise that anyone would think a comprehension
> > would be interpreted by the reader as a single operation.
>
> Yes, and I stand
Ben Finney wrote:
That the comprehension
syntax *does not* necessarily connote a procedural loop, but instead can
quite reasonably be interpreted as its designer intended, a single
conceptual operation.
To put it another way: Consider that a comprehension is an
expression, and I think most peop
On 8/14/2017 5:59 AM, Ben Finney wrote:
At what point will you accept the feedback: That the comprehension
syntax *does not* necessarily connote a procedural loop, but instead can
quite reasonably be interpreted as its designer intended, a single
conceptual operation.
In a world where function
http://www.cosc.canterbury.ac.nz/greg.ewing/python/listcomp/
Greg's 1999 announcement.
If you see the "semantics are equivalent" Steven wins.
If you focus on "like other languages" then it's... well not quite equivalent!
We can take our pick!
For myself, as I earlier said, if python disagrees
On Tue, Aug 15, 2017 at 1:54 AM, Ian Kelly wrote:
> On Mon, Aug 14, 2017 at 9:40 AM, Chris Angelico wrote:
>> On Tue, Aug 15, 2017 at 1:33 AM, Ian Kelly wrote:
>>> On Sun, Aug 13, 2017 at 8:36 AM, Steve D'Aprano
Sure. In Haskell, comprehensions are *implicit* loops, rather than
explic
On Mon, Aug 14, 2017 at 9:40 AM, Chris Angelico wrote:
> On Tue, Aug 15, 2017 at 1:33 AM, Ian Kelly wrote:
>> On Sun, Aug 13, 2017 at 8:36 AM, Steve D'Aprano
>>> Sure. In Haskell, comprehensions are *implicit* loops, rather than explicit
>>> like
>>> in Python.
>>
>> No, they aren't. Haskell lis
On Tue, Aug 15, 2017 at 1:33 AM, Ian Kelly wrote:
> On Sun, Aug 13, 2017 at 8:36 AM, Steve D'Aprano
>> Sure. In Haskell, comprehensions are *implicit* loops, rather than explicit
>> like
>> in Python.
>
> No, they aren't. Haskell list comprehensions use lazy evaluation.
> Here's an example of an
On Sun, Aug 13, 2017 at 8:36 AM, Steve D'Aprano
wrote:
> On Sat, 12 Aug 2017 01:02 am, Ian Kelly wrote:
>
>> On Thu, Aug 10, 2017 at 11:45 PM, Steve D'Aprano
>> wrote:
>
>>> Comprehension syntax makes the sequential loop explicit: the loop is right
>>> there in the syntax:
>>>
>>> [expr for x in
On Mon, 14 Aug 2017 07:59 pm, Ben Finney wrote:
> Steven D'Aprano writes:
>
>> On Sun, 13 Aug 2017 21:06:08 -0700, Rustom Mody wrote:
>>
>> > Here's a bunch of different ways in which a mapping comprehension
>> > could be implemented:
>>
>> Not in Python they couldn't be
>
> You began by asking
On Mon, 14 Aug 2017 09:03 pm, Rustom Mody wrote:
> For myself, if the python docs contradict the last 100 years or prior art/math
> history, the latter takes precedence
When theory disagrees with the facts, you ignore the facts?
> All I want to say is the gratuitous incidental resemblance of fo
On Monday, August 14, 2017 at 3:30:39 PM UTC+5:30, Ben Finney wrote:
> Steven D'Aprano writes:
>
> > On Sun, 13 Aug 2017 21:06:08 -0700, Rustom Mody wrote:
> >
> > > Here's a bunch of different ways in which a mapping comprehension
> > > could be implemented:
> >
> > Not in Python they couldn't be
Steven D'Aprano writes:
> On Sun, 13 Aug 2017 21:06:08 -0700, Rustom Mody wrote:
>
> > Here's a bunch of different ways in which a mapping comprehension
> > could be implemented:
>
> Not in Python they couldn't be
You began by asking what people would expect syntax to mean.
Then you expressed s
1 - 100 of 154 matches
Mail list logo
