Thanks, Chris, for the useful comments. Comments in line (with snipping of
unnecessary content):
> > some more variants which *don't* use tuple unpacking, on the theory
> that the coding patterns may be useful in
> > other cases where unpacking doesn't apply.
>
> When doesn't it apply? Can you el
On Wed, Sep 23, 2020 at 3:52 AM Stavros Macrakis wrote:
>
> Thanks to everyone for the comments, especially Tim Chase for the simple
> and elegant tuple unpacking solution, and Léo El Amri for the detailed
> comments on the variants. Below are some more variants which *don't *use
> tuple unpacking
Thanks to everyone for the comments, especially Tim Chase for the simple
and elegant tuple unpacking solution, and Léo El Amri for the detailed
comments on the variants. Below are some more variants which *don't *use
tuple unpacking, on the theory that the coding patterns may be useful in
other cas
Thanks, Tim! I didn't realize that you could write (x,) on the LHS!
Very nice, very Pythonic!
-s
On Mon, Sep 21, 2020 at 9:15 AM Tim Chase
wrote:
> On 2020-09-20 18:34, Stavros Macrakis wrote:
> > Consider a simple function which returns the first element of an
> > iterable if it
On 9/20/2020 6:34 PM, Stavros Macrakis wrote:
I'm trying to improve my Python style.
Consider a simple function which returns the first element of an iterable
if it has exactly one element, and throws an exception otherwise. It should
work even if the iterable doesn't terminate. I've written thi
On 2020-09-21 3:46 PM, Chris Angelico wrote:
On Mon, Sep 21, 2020 at 11:37 PM Tim Chase
wrote:
On 2020-09-20 18:34, Stavros Macrakis wrote:
Consider a simple function which returns the first element of an
iterable if it has exactly one element, and throws an exception
otherwise. It should wor
On 2020-09-21 09:48, Stavros Macrakis wrote:
>> def fn(iterable):
>> x, = iterable
>> return x
>
> Thanks, Tim! I didn't realize that you could write (x,) on the LHS!
> Very nice, very Pythonic!
It also expands nicely for other cases, so you want the 3-and-only-3
first values with errors
On 21/09/2020 15:15, Tim Chase wrote:
> You can use tuple unpacking assignment and Python will take care of
> the rest for you:
>
> so you can do
>
> def fn(iterable):
> x, = iterable
> return x
>
> I'm not sure it qualifies as Pythonic, but it uses Pythonic features
> like tuple unpac
On Mon, Sep 21, 2020 at 11:37 PM Tim Chase
wrote:
>
> On 2020-09-20 18:34, Stavros Macrakis wrote:
> > Consider a simple function which returns the first element of an
> > iterable if it has exactly one element, and throws an exception
> > otherwise. It should work even if the iterable doesn't ter
On 2020-09-20 18:34, Stavros Macrakis wrote:
> Consider a simple function which returns the first element of an
> iterable if it has exactly one element, and throws an exception
> otherwise. It should work even if the iterable doesn't terminate.
> I've written this function in multiple ways, all of
On 21/09/2020 00:34, Stavros Macrakis wrote:
> I'm trying to improve my Python style.
>
> Consider a simple function which returns the first element of an iterable
> if it has exactly one element, and throws an exception otherwise. It should
> work even if the iterable doesn't terminate. I've writ
On Fri, 29 Apr 2016 10:48 am, Gregory Ewing wrote:
> MRAB wrote:
>
>> Is it worthy of being in the Zen of Python?
>
> +1. Maybe something along the lines of:
>
> Dunder methods are for defining, not calling.
> Unless you're a dunderhead[1].
>
> [1] Meant in the sense of an enthusiast,
On Fri, Apr 29, 2016 at 4:12 PM, Gregory Ewing
wrote:
> Chris Angelico wrote:
>>
>> I thought the twentieth zen would never be found?
>
>
> Yes. This will have to be numbered the 21st zen
> to maintain that invariant.
>
Python for the 21st Century.
In a hundred years, another zen!
ChrisA
--
ht
Chris Angelico wrote:
I thought the twentieth zen would never be found?
Yes. This will have to be numbered the 21st zen
to maintain that invariant.
--
Greg
--
https://mail.python.org/mailman/listinfo/python-list
On Fri, Apr 29, 2016 at 10:48 AM, Gregory Ewing
wrote:
> MRAB wrote:
>
>> Is it worthy of being in the Zen of Python?
>
>
> +1. Maybe something along the lines of:
>
>Dunder methods are for defining, not calling.
>Unless you're a dunderhead[1].
>
> [1] Meant in the sense of an enthusiast,
MRAB wrote:
Is it worthy of being in the Zen of Python?
+1. Maybe something along the lines of:
Dunder methods are for defining, not calling.
Unless you're a dunderhead[1].
[1] Meant in the sense of an enthusiast, cf. gearhead.
--
Greg
--
https://mail.python.org/mailman/listinfo/pytho
On Thu, Apr 28, 2016, at 01:16, Rustom Mody wrote:
> On Thursday, April 28, 2016 at 9:26:21 AM UTC+5:30, Chris Angelico wrote:
> > My rule of thumb is: Dunders are for defining, not for calling. It's
> > not a hard-and-fast rule, but it'll get you through 99%+ of
> > situations.
>
> Neat and cleve
On 2016-04-28 06:16, Rustom Mody wrote:
On Thursday, April 28, 2016 at 9:26:21 AM UTC+5:30, Chris Angelico wrote:
My rule of thumb is: Dunders are for defining, not for calling. It's
not a hard-and-fast rule, but it'll get you through 99%+ of
situations.
Neat and clever.
Should get in the docs
On Thursday 28 April 2016 13:23, Ben Finney wrote:
> Christopher Reimer writes:
>
>> In short, my original code before I turned it into a separate
>> dictionary. *sigh*
>
> No, I think that misses the points that were being made. The discussion
> you're talking about was *not* to say “attribut
On Thursday, April 28, 2016 at 9:26:21 AM UTC+5:30, Chris Angelico wrote:
> My rule of thumb is: Dunders are for defining, not for calling. It's
> not a hard-and-fast rule, but it'll get you through 99%+ of
> situations.
Neat and clever.
Should get in the docs somewhere
--
https://mail.python.org
On 4/27/2016 8:52 PM, Ethan Furman wrote:
The point Ben was trying to make is this: you should never* call
__dunder__ methods in normal code; there is no need to do so:
- use len(), not __len__()
- use next(), not __next__()
- use some_instance.an_attribute, not
some_instance.__dict__['an_a
On 4/27/2016 8:23 PM, Ben Finney wrote:
If you want items in a mapping, explicitly use a Python ‘dict’ instance.
If you want attributes that describe an object, explicitly use
attributes of that object. Deliberately choose which one makes more
sense.
Okay, that makes sense.
Thank you,
Chris R
On Thu, Apr 28, 2016 at 1:52 PM, Ethan Furman wrote:
>
> The point Ben was trying to make is this: you should never* call __dunder__
> methods in normal code; there is no need to do so:
>
> - use len(), not __len__()
> - use next(), not __next__()
> - use some_instance.an_attribute, not some_inst
On 04/27/2016 08:07 PM, Christopher Reimer wrote:
On 4/27/2016 7:07 PM, Ben Finney wrote:
>> Ian Kelly wrote:
self.__dict__ = {'key', 'value'}
is essentially equivalent to:
self.key = value
>>
I would say the latter is more Pythonic, because it:
>>
>> [snip]
>>
* Uses the built
Christopher Reimer writes:
> In short, my original code before I turned it into a separate
> dictionary. *sigh*
No, I think that misses the points that were being made. The discussion
you're talking about was *not* to say “attribute access is better than
dictionary access”, or vice versa. Each
On 4/27/2016 7:07 PM, Ben Finney wrote:
I would say the latter is more Pythonic, because it:
* Better conveys the intention (“set the value of the ‘self.key’
attribute”).
* Uses the built-in mechanisms of Python (don't invoke magic attributes,
instead use the system that makes use of them
Hi,
I think that tuples are the best and simplest approach for small
structures.
>>> songs = [("Paranoid", "http://...";), ("Christian Woman", "http://...";)]
>>> for title, url in songs:
... print "%s: %s" % (title, url)
...
Paranoid: http://...
Christian Woman: http://...
I think that python'
metaperl wrote:
> The above program started out as a list of dictionaries, but I
> like the current approach much better.
There is even a common idiom for this...
class Record(object):
def __init__(self, **kwargs):
self.__dict__.update(kwargs)
This way you can use
user
28 matches
Mail list logo
