On Thu, Dec 11, 2014 at 6:55 PM, Roy Smith wrote:
>
> In article ,
> Ian Kelly wrote:
>
> > I never said that functions can't be used as namespaces. I said that
> > functions are *bad* namespaces, and I gave reasons why I think this is
true.
>
> An excellent example of functions acting as namesp
In article ,
Ian Kelly wrote:
> I never said that functions can't be used as namespaces. I said that
> functions are *bad* namespaces, and I gave reasons why I think this is true.
An excellent example of functions acting as namespaces is nosetest's
@attr() decorator. We use this, for example,
On Fri, Dec 12, 2014 at 10:28 AM, Steven D'Aprano
wrote:
> I think that there is a legitimate debate to be had as to whether this
> conservativeness and resistance to change is a good thing or a bad thing,
> but I don't think that there should be any debate about the reality of the
> Python commun
On Thu, Dec 11, 2014 at 4:28 PM, Steven D'Aprano <
steve+comp.lang.pyt...@pearwood.info> wrote:
>
> Ian Kelly wrote:
>
> > A function, on the
> > other hand, is not well suited to be a namespace, because it's not
> > expected to provide one.
>
>
> And that is exactly the point I am making about the
Ian Kelly wrote:
> A function, on the
> other hand, is not well suited to be a namespace, because it's not
> expected to provide one.
And that is exactly the point I am making about the inherent
conservativeness of Python developers.
Functions ARE namespaces, like instances of user-defined clas
On Wed, Dec 10, 2014 at 9:01 PM, Steven D'Aprano
wrote:
>
> On Wed, 10 Dec 2014 09:46:55 -0700, Ian Kelly wrote:
>
> > I don't particularly have a problem with functions having attributes,
> > e.g. I think itertools.chain.from_iterable is just peachy. There is a
> > downside though, which is that
On 12/10/2014 3:32 PM, Ian Kelly wrote:
So Idle gets it right. At least for static methods of classes, which
isn't very surprising. Does it complete a function attribute of a
function?
>>> def f(): pass
>>> f.a='attr'
>>> f. as possible completion.
Having used Komodo IDE for a number of y
On Wed, 10 Dec 2014 09:46:55 -0700, Ian Kelly wrote:
> I don't particularly have a problem with functions having attributes,
> e.g. I think itertools.chain.from_iterable is just peachy. There is a
> downside though, which is that making those functions attributes of
> another function rather than
On Wed, Dec 10, 2014 at 10:48 AM, Terry Reedy wrote:
>> Likewise the generated help for the help() function,
>> unless care is taken to explicitly mention the existence of those
>> functions in either the doc string for the module
>
>
> help(it.chain) lists
> | from_iterable(...) from builtins.t
On 12/10/2014 11:46 AM, Ian Kelly wrote:
I don't particularly have a problem with functions having attributes,
e.g. I think itertools.chain.from_iterable is just peachy. There is a
downside though, which is that making those functions attributes of
another function rather than of the module
It
On Wed, Dec 10, 2014 at 2:24 AM, Steven D'Aprano
wrote:
>
> Example: In the statistics module in Python 3.4, I added a `median`
> function to calculate the median by the traditional schoolbook algorithm.
> But that's only one out of a number of ways to calculate medium, and
> inspired by similar s
Steven D'Aprano :
> I've noticed this deep-seated conservatism in Python programmers
> before. Parts of the language are deeply under-utilised, because there
> are simple idioms that people refuse to use because they're
> "confusing" even though they are a trivial generalisation of things
> that w
On Wed, Dec 10, 2014 at 8:24 PM, Steven D'Aprano wrote:
> And if anyone has got the impression that I'm calling you a dummy because
> you don't see it my way, I'm not. I'm calling you nekulturny and somebody
> who can't recognise elegant code when it's staring you right in the
> face :-P
I love i
On Tue, 09 Dec 2014 21:44:54 -0500, Roy Smith wrote:
> In article <54878f8a$0$13010$c3e8da3$54964...@news.astraweb.com>,
> Steven D'Aprano wrote:
>
>> I really think you guys are trying too hard to make this function seem
>> more complicated than it is. If you find it so hard to understand a
>>
In article <54878f8a$0$13010$c3e8da3$54964...@news.astraweb.com>,
Steven D'Aprano wrote:
> I really think you guys are trying too hard to make this function seem more
> complicated than it is. If you find it so hard to understand a simple
> function with four short lines, one wonders how you wou
On 10/12/2014 00:10, Steven D'Aprano wrote:
Wait... is this like the Four Yorkshire Men sketch from Monty Python, only
instead of complaining about how hard you had it as children, you're all
trying to outdo each other about how difficult you find it to read this
function? If so, well done, you
On Wed, Dec 10, 2014 at 11:10 AM, Steven D'Aprano
wrote:
> On the other hand, *premature optimization*. In general, one shouldn't write
> more complex code so the compiler can optimize it, one should write simpler
> code and have a smarter compiler. If *we* are capable of recognising that
> iters
Terry Reedy wrote:
> On 12/9/2014 12:03 AM, Terry Reedy wrote:
>>> Roy Smith wrote:
>>>
Chris Angelico wrote:
>>
> def myzip(*args):
> iters = map(iter, args)
> while iters:
> res = [next(i) for i in iters]
> yield tuple(res)
Ugh. Whe
On 12/9/2014 12:03 AM, Terry Reedy wrote:
Roy Smith wrote:
Chris Angelico wrote:
def myzip(*args):
iters = map(iter, args)
while iters:
res = [next(i) for i in iters]
yield tuple(res)
Ugh. When I see "while foo", my brain says, "OK, you're about to see a
loop w
On Tue, 09 Dec 2014 00:03:33 -0500, Terry Reedy wrote:
> On 12/8/2014 9:50 PM, Steven D'Aprano wrote:
>> Roy Smith wrote:
>>
>>> Chris Angelico wrote:
>
def myzip(*args):
iters = map(iter, args)
while iters:
res = [next(i) for i in iters]
yield
On 12/8/2014 9:50 PM, Steven D'Aprano wrote:
Roy Smith wrote:
Chris Angelico wrote:
def myzip(*args):
iters = map(iter, args)
while iters:
res = [next(i) for i in iters]
yield tuple(res)
Ugh. When I see "while foo", my brain says, "OK, you're about to see a
loo
Roy Smith wrote:
> Chris Angelico wrote:
>> > I'm actually glad PEP 479 will break this kind of code. Gives a good
>> > excuse for rewriting it to be more readable.
>
> Steven D'Aprano wrote:
>> What kind of code is that? Short, simple, Pythonic and elegant? :-)
>>
>> Here's the code again, wit
In article <5485721c$0$2817$c3e8da3$76491...@news.astraweb.com>,
Steven D'Aprano wrote:
> On Mon, 08 Dec 2014 11:35:36 +1100, Chris Angelico wrote:
>
> > On Mon, Dec 8, 2014 at 11:27 AM, Roy Smith wrote:
> >> Although, to be honest, I'm wondering if this is more straight-forward
> >> (also not
On Mon, Dec 8, 2014 at 8:40 PM, Steven D'Aprano wrote:
> The first version is explicit and clear too. I'm sorry to say this, but
> it is true: if you (generic you) don't recognise that
>
> while iters:
> ...
>
>
> skips the while block if iters is an empty list, then *you* have a
> pro
On Mon, 08 Dec 2014 11:35:36 +1100, Chris Angelico wrote:
> On Mon, Dec 8, 2014 at 11:27 AM, Roy Smith wrote:
>> Although, to be honest, I'm wondering if this is more straight-forward
>> (also not tested):
>>
>> def myzip37(*args):
>> if not args:
>> return
>> iters = list(map(ite
Terry Reedy wrote:
However, this 'beautiful' code has a trap. If one gets rid of the
seemingly unneeded temporary list res by telescoping the last two lines
into a bit too much into
yield tuple(next(i) for i in iters)
we now have an infinite generator, because tuple() swallows th
Steven D'Aprano wrote:
I do not believe that good code must be obviously right. It's okay for code
to be subtly right.
If you write code as subtly as you can, you're not
subtle enough to debug it...
--
Greg
--
https://mail.python.org/mailman/listinfo/python-list
On 2014-12-08 01:00, Chris Angelico wrote:
On Mon, Dec 8, 2014 at 11:45 AM, Roy Smith wrote:
I take it as "result", which makes plenty of sense to me.
OK, so spell it out. Three more keystrokes (well, plus another three
when you use it on the next line). And one of them is a vowel; they
don
On 12/7/14 7:12 PM, Roy Smith wrote:
Chris Angelico wrote:
I'm actually glad PEP 479 will break this kind of code. Gives a good
excuse for rewriting it to be more readable.
Steven D'Aprano wrote:
What kind of code is that? Short, simple, Pythonic and elegant? :-)
Here's the code again, with
On Mon, Dec 8, 2014 at 11:45 AM, Roy Smith wrote:
>> I take it as "result", which makes plenty of sense to me.
>
> OK, so spell it out. Three more keystrokes (well, plus another three
> when you use it on the next line). And one of them is a vowel; they
> don't even cost much. The next guy who
In article ,
Chris Angelico wrote:
> > Next problem, what the heck is "res"? We're not back in the punch-card
> > days. We don't have to abbreviate variable names to save columns.
> > Variable names are supposed to describe what they hold, and thus help
> > you understand the code. I have no
On 12/7/2014 7:12 PM, Roy Smith wrote:
Chris Angelico wrote:
I'm actually glad PEP 479 will break this kind of code. Gives a good
excuse for rewriting it to be more readable.
Steven D'Aprano wrote:
What kind of code is that? Short, simple, Pythonic and elegant? :-)
Here's the code again, wi
On Mon, Dec 8, 2014 at 11:27 AM, Roy Smith wrote:
> Although, to be honest, I'm wondering if this is more straight-forward
> (also not tested):
>
> def myzip37(*args):
> if not args:
> return
> iters = list(map(iter, args))
Yes, I prefer this too. It's explicit and clear that pass
On Mon, Dec 8, 2014 at 11:12 AM, Roy Smith wrote:
> Ugh. When I see "while foo", my brain says, "OK, you're about to see a
> loop which is controlled by the value of foo being changed inside the
> loop". That's not at all what's happening here, so my brain runs into a
> wall.
I agree, with the
In article ,
Chris Angelico wrote:
> On Mon, Dec 8, 2014 at 10:33 AM, Steven D'Aprano
> wrote:
> > How would we re-write this to work in the future Python 3.7? Unless I have
> > missed something, I think we could write it like this:
> >
> > def myzip37(*args):
> > iters = list(map(iter, arg
Chris Angelico wrote:
> > I'm actually glad PEP 479 will break this kind of code. Gives a good
> > excuse for rewriting it to be more readable.
Steven D'Aprano wrote:
> What kind of code is that? Short, simple, Pythonic and elegant? :-)
>
> Here's the code again, with indentation fixed:
>
>
>
On Mon, Dec 8, 2014 at 10:33 AM, Steven D'Aprano
wrote:
> How would we re-write this to work in the future Python 3.7? Unless I have
> missed something, I think we could write it like this:
>
> def myzip37(*args):
> iters = list(map(iter, args))
> while iters:
> try:
>
Chris Angelico wrote:
> On Mon, Dec 8, 2014 at 5:27 AM, Ian Kelly wrote:
>> On Dec 7, 2014 8:31 AM, "Ned Batchelder" wrote:
>>> NOTE: THIS EXAMPLE IS HORRIBLE. This code is crazy-confusing, and
>>> should never have been used as an example of iteration. It layers at
>>> least three iterations o
On Mon, Dec 8, 2014 at 5:27 AM, Ian Kelly wrote:
> On Dec 7, 2014 8:31 AM, "Ned Batchelder" wrote:
>> NOTE: THIS EXAMPLE IS HORRIBLE. This code is crazy-confusing, and should
>> never have been used as an example of iteration. It layers at least three
>> iterations on top of each other, making i
On Dec 7, 2014 8:31 AM, "Ned Batchelder" wrote:
> NOTE: THIS EXAMPLE IS HORRIBLE. This code is crazy-confusing, and should
never have been used as an example of iteration. It layers at least three
iterations on top of each other, making it very difficult to see what is
going on. It uses "while i
On Mon, Dec 8, 2014 at 2:29 AM, Ned Batchelder wrote:
> 3. The only operation supported on iterators is next(). You cannot start
> them over, you cannot ask if there will be more values, you cannot find out
> how many values there will be, you can't ask what the last value was, etc.
> By supporti
ython-list@python.org
Subject: Re: Python Iterables struggling using map() built-in
On 12/6/14 11:44 AM, Ivan Evstegneev wrote:
> And as I've promised the question section:
>
> 1.What actually map() trying to do in Python 3.X?
>
> I mean, why is this works fine:
>
>>&g
On Sun, Dec 7, 2014 at 3:44 AM, Ivan Evstegneev wrote:
> (quoting from the book)
> Because this code uses iter and next, it works on any type of iterable. Note
> that there
> is no reason to catch the StopIteration raised by the next(it) inside the
> comprehension
> here when any one of the argume
Hello everyone,
I'm currently in the process of self-study journey, so I have some questions
arisen from time to time.
Today I would like to talk about iterables and iterators,(ask for your help
actually ^_^).
Before I'll continue, just wanted to draw your attention to the fact that I
di
44 matches
Mail list logo
