I often want to execute a chunk of code n times
for iter in range(n):
chunkofcode
Sometimes, the chunk of code doesn't care about which iteration
it's on. A week or two back, I would have sworn that I came across
a syntax for the above that eliminates the iteration counter.
This morning, I ha
On 28/06/2021 11.57, Stefan Ram wrote:
"Michael F. Stemper" writes:
for iter in range(n):
chunkofcode
When the counter does not matter, people sometimes write "_":
for _ in range( n ):
chunkofcode
That looks like what I wanted.
Thanks!
--
Michael F. Stemper
Indians scattered o
On 02Dec2014 02:17, Ethan Furman wrote:
On 12/01/2014 05:15 PM, Chris Angelico wrote:
On Tue, Dec 2, 2014 at 11:45 AM, Ethan Furman wrote:
Put the above somewhere in your path (e.g. /usr/local/bin), make it
executable, and then instead of shebanging your
scripts with `/usr/local/bin/python`
On 12/01/2014 05:15 PM, Chris Angelico wrote:
> On Tue, Dec 2, 2014 at 11:45 AM, Ethan Furman wrote:
>>
>> Put the above somewhere in your path (e.g. /usr/local/bin), make it
>> executable, and then instead of shebanging your
>> scripts with `/usr/local/bin/python` you can use `/usr/local/bin/py_m
On Tue, Dec 2, 2014 at 11:45 AM, Ethan Furman wrote:
> Put the above somewhere in your path (e.g. /usr/local/bin), make it
> executable, and then instead of shebanging your
> scripts with `/usr/local/bin/python` you can use `/usr/local/bin/py_main`,
> which will load and execute the script,
> ca
On 12/01/2014 03:19 PM, Ethan Furman wrote:
>
> Well, I've tried this out, and it's only okay. As soon as interesting things
> start happening, spurious errors about
> thread IDs start printing, which really messes up the user experience [...]
So here's another thought: Have a small python sc
On 11/13/2014 10:32 AM, Ethan Furman wrote:
> On 11/12/2014 01:51 PM, Ian Kelly wrote:
>> On Wed, Nov 12, 2014 at 2:33 PM, Chris Kaynor wrote:
>>>
>>> A decorator is an interesting idea, and should be easy to implement (only
>>> lightly tested):
>>>
>>> def main(func):
>>> if func.__module__ =
On Sun, Nov 16, 2014 at 3:39 AM, Vito De Tullio wrote:
> for the "right time" you can choose to spin a thread and wait to the end of
> the load of the module
Yuck. "Just add threads" is /not/ the answer to everything.
This case looks fairly harmless on the surface, although I could
imagine it br
Ian Kelly wrote:
>> def main(func):
>> if func.__module__ == "__main__":
>> func()
>> return func # The return could be omitted to block the function from
>> being manually called after import.
>>
>> Just decorate the "main" function of the script with that, and it will be
>> a
Steven D'Aprano wrote:
> Chris Kaynor wrote:
>
>> I was thinking along the lines of replacing:
>>
>> if __name__ == "__main__":
>> <<>>
>>
>> with
>>
>> @main
>> def myFunction()
>> <<<>
>>
>> Both blocks of code will be called at the same time.
>
>
> You can't guarantee that, because you c
Steven D'Aprano :
> if __name__ == '__main__' or condition():
> print "still executing"
> main()
>
> print "done loading"
>
> (I haven't ever done *all* of these things in a *single* file, but I
> have done all these things at one time or another.)
>
> There's no way that any automatic sys
Chris Kaynor wrote:
> I was thinking along the lines of replacing:
>
> if __name__ == "__main__":
> <<>>
>
> with
>
> @main
> def myFunction()
> <<<>
>
> Both blocks of code will be called at the same time.
You can't guarantee that, because you cannot tell ahead of time when the "if
__name__
John Ladasky wrote:
> I have taught Python to several students over the past few years. As I
> have worked with my students, I find myself bothered by the programming
> idiom that we use to determine whether a module is being executed or
> merely imported:
>
> "if __name__ == '__main__':"
>
>
On Thu, Nov 13, 2014 at 1:53 PM, Skip Montanaro
wrote:
> On Thu, Nov 13, 2014 at 2:44 PM, Skip Montanaro
> wrote:
>> What's not documented is
>> the behavior of calling atexit.register() while atexit._run_exitfuncs
>> is running. That's an implementation detail, and though unlikely to
>> change,
On Thu, Nov 13, 2014 at 1:44 PM, Skip Montanaro
wrote:
> On Thu, Nov 13, 2014 at 2:33 PM, Ian Kelly wrote:
>> ... other things decorated with atexit.register
>> might actually be called before the main function
>
> I don't think that will happen. The atexit module is documented to
> execute its e
On Thu, Nov 13, 2014 at 2:44 PM, Skip Montanaro
wrote:
> What's not documented is
> the behavior of calling atexit.register() while atexit._run_exitfuncs
> is running. That's an implementation detail, and though unlikely to
> change, it might be worthwhile getting that behavior documented.
http:/
On Thu, Nov 13, 2014 at 2:33 PM, Ian Kelly wrote:
> ... other things decorated with atexit.register
> might actually be called before the main function
I don't think that will happen. The atexit module is documented to
execute its exit functions in reverse order. What's not documented is
the beha
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/13/2014 12:33 PM, Ian Kelly wrote:
> On Thu, Nov 13, 2014 at 11:32 AM, Ethan Furman wrote:
>> On 11/12/2014 01:51 PM, Ian Kelly wrote:
>>>
>>> On Wed, Nov 12, 2014 at 2:33 PM, Chris Kaynor wrote:
A decorator is an interesting idea, a
On Thu, Nov 13, 2014 at 11:32 AM, Ethan Furman wrote:
> On 11/12/2014 01:51 PM, Ian Kelly wrote:
>>
>> On Wed, Nov 12, 2014 at 2:33 PM, Chris Kaynor wrote:
>>>
>>> A decorator is an interesting idea, and should be easy to implement (only
>>> lightly tested):
>>>
>>> def main(func):
>>> if fun
On 11/12/2014 01:51 PM, Ian Kelly wrote:
On Wed, Nov 12, 2014 at 2:33 PM, Chris Kaynor wrote:
A decorator is an interesting idea, and should be easy to implement (only
lightly tested):
def main(func):
if func.__module__ == "__main__":
func()
return func # The return coul
On Fri, Nov 14, 2014 at 12:33 AM, Roy Smith wrote:
> ... you also get to not worry
> about what order things are defined.
That's only as regards the interpreter, though. My point has nothing
to do with the order the interpreter sees things, it's all about how
they're laid out for humans to read.
In article ,
Chris Angelico wrote:
> On Thu, Nov 13, 2014 at 7:47 PM, Cameron Simpson wrote:
> > My view is that if there's a main (i.e. the module implements a small app
> > all on its own, however tiny), then the main program logic should come
> > first. The details follow later.
>
> Ah, I s
On Thu, Nov 13, 2014 at 7:47 PM, Cameron Simpson wrote:
> My view is that if there's a main (i.e. the module implements a small app
> all on its own, however tiny), then the main program logic should come
> first. The details follow later.
Ah, I see. Makes sense. It's kinda like an executable doc
On 13Nov2014 19:04, Chris Angelico wrote:
On Thu, Nov 13, 2014 at 6:23 PM, Cameron Simpson wrote:
Indeed. This aspect is a deal breaker for me; I'd never use it.
I make a point of putting the module's main function right up the top,
immediately after the imports and any "constants" (let's not
On Thu, Nov 13, 2014 at 6:23 PM, Cameron Simpson wrote:
> Indeed. This aspect is a deal breaker for me; I'd never use it.
>
> I make a point of putting the module's main function right up the top,
> immediately after the imports and any "constants" (let's not dither over
> that term). I _want_ the
On 12Nov2014 14:51, Ian Kelly wrote:
On Wed, Nov 12, 2014 at 2:33 PM, Chris Kaynor wrote:
A decorator is an interesting idea, and should be easy to implement (only
lightly tested): [...]
Just decorate the "main" function of the script with that, and it will be
automatically called when ran as
On Thu, Nov 13, 2014 at 11:35 AM, Terry Reedy wrote:
>> Safer - and more in line with the way
>> other such functions are written - would be a dunder function:
>>
>> if __name__ == '__main__': __main__()
>
>
> I presume you mean that calling __main__ implicitly would be both consistent
> and safer
On 11/12/2014 6:26 PM, Chris Angelico wrote:
On Thu, Nov 13, 2014 at 10:19 AM, Terry Reedy wrote:
Functions have an implicit 'return None' at the end (which, in CPython,
become an explicit pair of bytecodes, even when the function already ends
with return something'. The simplest proposal is t
On Thu, Nov 13, 2014 at 10:19 AM, Terry Reedy wrote:
> Functions have an implicit 'return None' at the end (which, in CPython,
> become an explicit pair of bytecodes, even when the function already ends
> with return something'. The simplest proposal is that modules have an
> implicit "if __name_
On 11/12/2014 4:02 PM, John Ladasky wrote:
I have taught Python to several students over the past few years. As
I have worked with my students, I find myself bothered by the
programming idiom that we use to determine whether a module is being
executed or merely imported:
"if __name__ == '__main
On Wed, Nov 12, 2014 at 3:09 PM, Chris Kaynor wrote:
> I was thinking along the lines of replacing:
>
> if __name__ == "__main__":
> <<>>
>
> with
>
> @main
> def myFunction()
> <<<>
>
> Both blocks of code will be called at the same time.
99% of the time the content of <<>> is just "main
On Wed, Nov 12, 2014 at 1:51 PM, Ian Kelly wrote:
> On Wed, Nov 12, 2014 at 2:33 PM, Chris Kaynor
> wrote:
> > A decorator is an interesting idea, and should be easy to implement (only
> > lightly tested):
> >
> > def main(func):
> > if func.__module__ == "__main__":
> > func()
>
> def main(func):
> if func.__module__ == "__main__":
> func()
> return func # The return could be omitted to block the function from
> being manually called after import.
>
> Just decorate the "main" function of the script with that, and it will be
> automatically called when r
John Ladasky :
> I find myself bothered by the programming idiom that we use to
> determine whether a module is being executed or merely imported:
>
> "if __name__ == '__main__':"
I find the idiom cute and loveably silly. A typing tongue twister of
sorts. That boilerplate is far less cumbersome
On Wed, Nov 12, 2014 at 2:33 PM, Chris Kaynor wrote:
> A decorator is an interesting idea, and should be easy to implement (only
> lightly tested):
>
> def main(func):
> if func.__module__ == "__main__":
> func()
> return func # The return could be omitted to block the function
On Wed, Nov 12, 2014 at 1:07 PM, Joel Goldstick
wrote:
> On Wed, Nov 12, 2014 at 4:02 PM, John Ladasky
> wrote:
> > I have taught Python to several students over the past few years. As I
> have worked with my students, I find myself bothered by the programming
> idiom that we use to determine w
On 11/12/2014 01:02 PM, John Ladasky wrote:
I would like to start a discussion about whether Python should include
a function which executes this evaluation, and hides all of the unfriendly
dunderish details. And if that's a good idea, I would invite a discussion
of how, exactly, it should b
It appears that I'm not the first person to have thoughts along these lines.
Here's a relevant article:
http://aliles.tumblr.com/post/7455032885/sugar-for-pythons-main
--
https://mail.python.org/mailman/listinfo/python-list
On Wed, Nov 12, 2014 at 4:02 PM, John Ladasky
wrote:
> I have taught Python to several students over the past few years. As I have
> worked with my students, I find myself bothered by the programming idiom that
> we use to determine whether a module is being executed or merely imported:
>
> "
I have taught Python to several students over the past few years. As I have
worked with my students, I find myself bothered by the programming idiom that
we use to determine whether a module is being executed or merely imported:
"if __name__ == '__main__':"
The use of two dunder tokens -- on
On Wed, Sep 28, 2011 at 07:01:11PM -0400, Terry Reedy wrote:
> On 9/28/2011 5:26 PM, Ethan Furman wrote:
>
> >I don't remember if 'def' is sugar for something besides lambda.
>
> That is a bit backwards.
> lambda x: expr(x)
> is syntactic sugar
On 9/28/2011 5:26 PM, Ethan Furman wrote:
I don't remember if 'def' is sugar for something besides lambda.
That is a bit backwards.
lambda x: expr(x)
is syntactic sugar for
def (x): return expr(x)
del
;-)
--
Terry Jan Reedy
--
http://mail.python.org/mailman/listinfo/python-list
ce.
Since 3.0, class statements are syntactic sugar for some extra steps
beyond "meta(...)" [1]. In CPython this is facilitated through the
"hidden" __build_class__() builtin[2]. We have the __import__()
builtin for customizing module creation. But, as you asked, what abou
En Wed, 28 Sep 2011 18:51:00 -0300, Chris Kaynor
escribió:
On Wed, Sep 28, 2011 at 2:37 PM, Arnaud Delobelle
wrote:
On 28 September 2011 22:26, Ethan Furman wrote:
I remember that 'class' is sugar for type().
I don't remember if 'def' is sugar for something besides lambda.
Any clue
On Wed, Sep 28, 2011 at 2:37 PM, Arnaud Delobelle wrote:
> On 28 September 2011 22:26, Ethan Furman wrote:
>> I remember that 'class' is sugar for type().
>>
>> I don't remember if 'def' is sugar for something besides lambda.
>>
>> Any clues for me? Heck, I'll even be grateful for outright a
On 28 September 2011 22:26, Ethan Furman wrote:
> I remember that 'class' is sugar for type().
>
> I don't remember if 'def' is sugar for something besides lambda.
>
> Any clues for me? Heck, I'll even be grateful for outright answers!
It's not really sugar. But I think you mean something l
On Wed, Sep 28, 2011 at 3:26 PM, Ethan Furman wrote:
> I remember that 'class' is sugar for type().
>
> I don't remember if 'def' is sugar for something besides lambda.
>
> Any clues for me? Heck, I'll even be grateful for outright answers!
If you mean is there a way to create functions usin
I remember that 'class' is sugar for type().
I don't remember if 'def' is sugar for something besides lambda.
Any clues for me? Heck, I'll even be grateful for outright answers!
~Ethan~
--
http://mail.python.org/mailman/listinfo/python-list
In article
<[email protected]>,
gc wrote:
> I frequently need to initialize several variables to the same
> value, as I'm sure many do. Sometimes the value is a constant, often
> zero; sometimes it's more particular, such as defaultdict(list). I us
On Aug 3, 2:45 am, gc wrote:
> Hi everyone! Longtime lurker, hardly an expert, but I've been using
> Python for various projects since 2007 and love it.
>
> I'm looking for either (A) suggestions on how to do a very common
> operation elegantly and Pythonically, or (B) input on whether my
> propos
:
Off on a tangent ...
On 16 August 2011 20:14, gc wrote:
>
> Let me address one smell from my particular example, which may be the
> one you're noticing. If I needed fifty parallel collections I would
> not use separate variables; I've coded a ghastly defaultdefaultdict
> just for this purpose,
gc wrote:
Target lists using comma separation are great, but they don't work
very well for this task. What I want is something like
a,b,c,d,e = *dict()
This isn't going to happen. From all the discussion so far I think your
best solution is a simple helper function (not tested):
def repeat
gc wrote:
> Maybe this is more visibly convenient with a complex class, like
>
> x, y, z = *SuperComplexClass(param1, param2, kwparam = "3", ...)
>
> where you need three separate objects but don't want to duplicate the
> class call (for obvious copy-paste reasons) and where bundling it in a
> l
On Wed, Aug 17, 2011 at 5:55 PM, MRAB wrote:
> x, y, z = lazy copies(SuperComplexClass(param1, etc, ...))
>
This assumes that you can construct it once and then copy it reliably,
which may mean that the class implement copying correctly. It also
wouldn't work with:
a, b, c, d = *random.randint(1
On 17/08/2011 10:26, gc wrote:
On Aug 17, 3:13 am, Chris Angelico wrote:
Minor clarification: You don't want to initialize them to the same
value, which you can do already:
a=b=c=d=e=dict()
Right. Call the proposed syntax the "instantiate separately for each
target" operator. (It can be pr
The issue behind this thread is that for immutable objects, binding to n
copies has the same effect as n bindings to one object (so one does not
really have to know which one is doing), whereas the two are different
for mutable objects (so one does have to know). In short, identity
matters for
On Aug 17, 5:45 am, Chris Angelico wrote:
(snip)
> > Right. Call the proposed syntax the "instantiate separately for each
> > target" operator.
>
(snip)
> It might just
> as easily be some other function call; for instance:
>
> head1,head2,head3=file.readline()
Hm--that's interesting! OK, call it
On Wed, Aug 17, 2011 at 10:26 AM, gc wrote:
> On Aug 17, 3:13 am, Chris Angelico wrote:
>
>> Minor clarification: You don't want to initialize them to the same
>> value, which you can do already:
>>
>> a=b=c=d=e=dict()
>
> Right. Call the proposed syntax the "instantiate separately for each
> tar
On Aug 17, 3:13 am, Chris Angelico wrote:
> Minor clarification: You don't want to initialize them to the same
> value, which you can do already:
>
> a=b=c=d=e=dict()
Right. Call the proposed syntax the "instantiate separately for each
target" operator. (It can be precisely defined as a * on th
On Wed, Aug 17, 2011 at 1:14 AM, gc wrote:
> Perfectly reasonable request! Maybe there aren't as many cases when
> multiple variables need to be initialized to the same value as I think
> there are.
>
Minor clarification: You don't want to initialize them to the same
value, which you can do alrea
On 17/08/2011 01:14, gc wrote:
On Aug 16, 4:39 pm, "Martin P. Hellwig"
wrote:
On 03/08/2011 02:45, gc wrote:
a,b,c,d,e = *dict()
where * in this context means something like "assign separately to
all.
. . . it has a certain code smell to it.
I would love to see an example where you wo
On Aug 16, 4:39 pm, "Martin P. Hellwig"
wrote:
> On 03/08/2011 02:45, gc wrote:
>
>
> > a,b,c,d,e = *dict()
>
> > where * in this context means something like "assign separately to
> > all.
> . . . it has a certain code smell to it.
> I would love to see an example where you would need such a
On 03/08/2011 02:45, gc wrote:
a,b,c,d,e = *dict()
where * in this context means something like "assign separately to
all.
Any thoughts? Thanks!
Well got a thought but I am afraid it is the opposite of helpful in the
direct sense. So if you don't want to hear it skip it :-)
Although I c
Thanks for all the discussion on this. Very illuminating. Sorry for
the long delay in responding--deadlines intervened.
I will use the list comprehension syntax for the foreseeable future.
Tim, I agree with you about the slurping in final position--it's
actually quite surprising. As I'm sure you
On 08/03/2011 03:36 AM, Katriel Cohn-Gordon wrote:
On Wed, Aug 3, 2011 at 9:25 AM, Steven D'Aprano wrote:
a, b, c, d, e = [dict() for i in range(5)]
I think this is good code -- if you want five different dicts,
then you should call dict five times. Otherwise Python will
magically call your ex
On 08/03/2011 03:25 AM, Steven D'Aprano wrote:
gc wrote:
Target lists using comma separation are great, but they don't work
very well for this task. What I want is something like
a,b,c,d,e = *dict()
a, b, c, d, e = [dict() for i in range(5)]
Unfortunately there is no way of doing so withou
On Wed, Aug 3, 2011 at 9:25 AM, Steven D'Aprano <
[email protected]> wrote:
> gc wrote:
>
> > Target lists using comma separation are great, but they don't work
> > very well for this task. What I want is something like
> >
> > a,b,c,d,e = *dict()
>
> a, b, c, d, e = [dict() for
gc wrote:
Alternatively, is there a version of iterable multiplication that
creates new objects rather than just copying the reference?
You can use a list comprehension:
a, b, c, d, e = [dict() for i in xrange(5)]
or a generator expression:
a, b, c, d, e = (dict() for i in xrange(5))
-
gc wrote:
> Target lists using comma separation are great, but they don't work
> very well for this task. What I want is something like
>
> a,b,c,d,e = *dict()
a, b, c, d, e = [dict() for i in range(5)]
Unfortunately there is no way of doing so without counting the assignment
targets. While sl
On Wed, Aug 3, 2011 at 2:45 AM, gc wrote:
> Anyway, I frequently need to initialize several variables to the same
> value, as I'm sure many do. Sometimes the value is a constant, often
> zero; sometimes it's more particular, such as defaultdict(list). I use
> dict() below.
If it's an immutable va
Hi everyone! Longtime lurker, hardly an expert, but I've been using
Python for various projects since 2007 and love it.
I'm looking for either (A) suggestions on how to do a very common
operation elegantly and Pythonically, or (B) input on whether my
proposal is PEP-able, assuming there's no answe
On 12/02/2010 10:39 AM, Mark Dickinson wrote:
On Nov 15, 12:46 pm, Tim Chase wrote:
On 11/15/2010 12:39 AM, Dmitry Groshev wrote:
x in range optimisation
I've often thought this would make a nice O(1)-test lookup on an
xrange() generator.
An O(1) test for 'x in' is implemented in Python 3
On Nov 15, 12:46 pm, Tim Chase wrote:
> On 11/15/2010 12:39 AM, Dmitry Groshev wrote:
>
> > x in range optimisation
>
> I've often thought this would make a nice O(1)-test lookup on an
> xrange() generator.
An O(1) test for 'x in ' is implemented in Python 3.2,
at least provided that x has type '
On Wed, 01 Dec 2010 15:18:32 -0800, Dmitry Groshev wrote:
> Here is a fresh example of what I meant by my first proposal. You need
> to build a matrix like this:
> 2 1 0 ...
> 1 2 1 ...
> 0 1 2 ...
> ...
> ... 1 2 1
> ... 0 1 2
> You could do this by one-liner:
> [[(2 - abs(x - y)) if it > 0 else
On Nov 22, 2:21 pm, Andreas Löscher wrote:
> > if x in range(a, b): #wrong!
> > it feels so natural to check it that way, but we have to write
> > if a <= x <= b
> > I understand that it's not a big deal, but it would be awesome to have
> > some optimisations - it's clearly possible to det
> if x in range(a, b): #wrong!
> it feels so natural to check it that way, but we have to write
> if a <= x <= b
> I understand that it's not a big deal, but it would be awesome to have
> some optimisations - it's clearly possible to detect things like that
> "wrong" one and fix it in a byt
Steven D'Aprano writes:
> >> Not everything needs to be a one liner. If you need this, do it the
> >> old- fashioned way:
> >>
> >> t = foo()
> >> if not pred(t): t = default_value
> >
> > I already explained how to write it as a one-liner:
> >
> > t = (lambda y: y if pred(y) else defau
On Thu, 18 Nov 2010 09:32:23 +, Mark Wooding wrote:
[...]
> You're wrong. Python evaluates these left-to-right, as I said.
> Parentheses override operator associativity; they don't affect
> evaluation order at all.
Fair enough. I concede your point.
[...]
>> Not everything needs to be a on
Steven D'Aprano writes:
> On Wed, 17 Nov 2010 16:31:40 +, Mark Wooding wrote:
>
> > But I don't think that's the big problem with this proposal. The real
> > problem is that it completely changes the evaluation rule for the
> > conditional expression. (The evaluation rule is already pretty
On Wed, 17 Nov 2010 16:31:40 +, Mark Wooding wrote:
> But I don't think that's the big problem with this proposal. The real
> problem is that it completely changes the evaluation rule for the
> conditional expression. (The evaluation rule is already pretty screwy:
> Python is consistently le
Christopher writes:
> i don't like magic names. what about:
>
> t = foo() as v if pred(v) else default_value
This is an improvement on `it'; anaphorics are useful in their place,
but they don't seem to fit well with Python.
But I don't think that's the big problem with this proposal. The real
On Wed, 17 Nov 2010 10:18:51 -0500 Mel wrote:
> Christopher wrote:
>
> >> ? Of course we can write it as
> >> t = foo() if pred(foo()) else default_value
> >> but here we have 2 foo() calls instead of one. Why can't we write
> >> just something like this:
> >> t = foo() if pred(it) else default_
Christopher wrote:
>> ? Of course we can write it as
>> t = foo() if pred(foo()) else default_value
>> but here we have 2 foo() calls instead of one. Why can't we write just
>> something like this:
>> t = foo() if pred(it) else default_value
>> where "it" means "foo() value"?
>
> i don't like mag
> ? Of course we can write it as
> t = foo() if pred(foo()) else default_value
> but here we have 2 foo() calls instead of one. Why can't we write just
> something like this:
> t = foo() if pred(it) else default_value
> where "it" means "foo() value"?
i don't like magic names. what about:
On Nov 14, 11:30 pm, alex23 wrote:
> On Nov 15, 4:39 pm, Dmitry Groshev wrote:
>
> > if x in range(a, b): #wrong!
>
> Only in Python 3.x, it's perfectly valid in Python 2.x. To achieve the
> same in Python 3.x, try:
>
> if x in list(range(a, b,)): # BUT SEE MY COMMENT BELOW
>
> > it feels
On Nov 15, 2:39 am, Dmitry Groshev wrote:
> Here are some proposals. They are quite useful at my opinion and I'm
> interested for suggestions. It's all about some common patterns.
> First of all: how many times do you write something like
> t = foo()
> t = t if pred(t) else default_value
On 11/16/2010 3:42 AM, Steven D'Aprano wrote:
On Mon, 15 Nov 2010 22:40:00 -0700, Ian Kelly wrote:
On 11/15/2010 10:26 PM, Steven D'Aprano wrote:
t = foo()+bar()+baz() if pred(it) else baz()-foo()-bar()
What does "it" mean here?
"it" would mean the result of the expression foo()+bar()+baz()
On Mon, 15 Nov 2010 22:40:00 -0700, Ian Kelly wrote:
> On 11/15/2010 10:26 PM, Steven D'Aprano wrote:
>> t = foo()+bar()+baz() if pred(it) else baz()-foo()-bar()
>>
>> What does "it" mean here?
>
> "it" would mean the result of the expression foo()+bar()+baz(). What
> else could it mean?
It cou
On 11/15/2010 10:26 PM, Steven D'Aprano wrote:
t = foo()+bar()+baz() if pred(it) else baz()-foo()-bar()
What does "it" mean here?
"it" would mean the result of the expression foo()+bar()+baz(). What
else could it mean? There are valid objections to the proposal, but the
intended semantics
On Sun, 14 Nov 2010 22:39:05 -0800, Dmitry Groshev wrote:
> Here are some proposals. They are quite useful at my opinion and I'm
> interested for suggestions. It's all about some common patterns. First
> of all: how many times do you write something like
> t = foo()
> t = t if pred(t) else
On 11/14/2010 11:30 PM, alex23 wrote:
On Nov 15, 4:39 pm, Dmitry Groshev wrote:
First of all: how many times do you write something like
Second, I saw a lot of questions about using dot notation for a
"object-like" dictionaries and a lot of solutions like this:
class dotdict(dict):
On Nov 15, 2010, at 1:39 AM, Dmitry Groshev wrote:
>if x in range(a, b): #wrong!
> it feels so natural to check it that way, but we have to write
>if a <= x <= b
> I understand that it's not a big deal, but it would be awesome to have
> some optimisations - it's clearly possible to detect
On 11/15/2010 1:39 AM, Dmitry Groshev wrote:
Here are some proposals. They are quite useful at my opinion and I'm
interested for suggestions. It's all about some common patterns.
First of all: how many times do you write something like
t = foo()
t = t if pred(t) else default_value
Nev
On 11/15/2010 12:39 AM, Dmitry Groshev wrote:
x in range optimisation
I've often thought this would make a nice O(1)-test lookup on an
xrange() generator. I don't have strong use-cases for it, but a
bit of well-tested code in the standard library would save me
from doing the math (along wit
Dmitry Groshev writes:
> First of all: how many times do you write something like
> t = foo()
> t = t if pred(t) else default_value
> ? Of course we can write it as
> t = foo() if pred(foo()) else default_value
> but here we have 2 foo() calls instead of one. Why can't we write just
>
Dmitry Groshev writes:
> which looks almost like a natural language. But there is some
> pitfalls:
> if x in range(a, b): #wrong!
> it feels so natural to check it that way, but we have to write
> if a <= x <= b
For the record, you have to write:
if a <= x < b:
Ranges are open on t
On Nov 15, 12:03 pm, alex23 wrote:
> On Nov 15, 5:50 pm, Dmitry Groshev wrote:
>
> > On Nov 15, 10:30 am, alex23 wrote:
> > > Personally, I like keeping object attribute references separate from
> > > dictionary item references.
>
> > Your Python doesn't - dot notation is just a sugar for __dict
On Nov 15, 5:50 pm, Dmitry Groshev wrote:
> On Nov 15, 10:30 am, alex23 wrote:
> > Personally, I like keeping object attribute references separate from
> > dictionary item references.
>
> Your Python doesn't - dot notation is just a sugar for __dict__ lookup
> with default metaclass.
That's a gr
tend you have some string foo and compiled regular
expression bar.
Naive code:
t = bar.findall(foo)
if len(t) < 3:
t = []
Code with proposed syntactic sugar:
t = bar.findall(foo) if len(it) > 2 else []
> > Second, I saw a lot of questions about using dot notation for a
On Nov 15, 5:30 pm, alex23 wrote:
> t = foo(x) if else default
This should read 'test' instead of 'text', sorry.
--
http://mail.python.org/mailman/listinfo/python-list
1 - 100 of 181 matches
Mail list logo
