Syntactic sugar

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

Re: Syntactic sugar

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

[issue5149] syntactic sugar: type coercion on pointer assignment

Change by Irit Katriel : -- versions: +Python 3.10 -Python 3.2 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

Re: How about some syntactic sugar for __name__ == '__main__' ?

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_main`,

Re: How about some syntactic sugar for __name__ == '__main__' ?

On 02Dec2014 02:17, Ethan Furman et...@stoneleaf.us 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

Re: How about some syntactic sugar for __name__ == '__main__' ?

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__ == __main__:

Re: How about some syntactic sugar for __name__ == '__main__' ?

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

Re: How about some syntactic sugar for __name__ == '__main__' ?

On Tue, Dec 2, 2014 at 11:45 AM, Ethan Furman et...@stoneleaf.us 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

Re: How about some syntactic sugar for __name__ == '__main__' ?

Steven D'Aprano wrote: Chris Kaynor wrote: I was thinking along the lines of replacing: if __name__ == __main__: block of code with @main def myFunction() block of code Both blocks of code will be called at the same time. You can't guarantee that, because you cannot tell

Re: How about some syntactic sugar for __name__ == '__main__' ?

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 automatically called

Re: How about some syntactic sugar for __name__ == '__main__' ?

On Sun, Nov 16, 2014 at 3:39 AM, Vito De Tullio vito.detul...@gmail.com 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

Re: How about some syntactic sugar for __name__ == '__main__' ?

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__': The use

Re: How about some syntactic sugar for __name__ == '__main__' ?

Chris Kaynor wrote: I was thinking along the lines of replacing: if __name__ == __main__: block of code with @main def myFunction() block of code 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

Re: How about some syntactic sugar for __name__ == '__main__' ?

Steven D'Aprano steve+comp.lang.pyt...@pearwood.info: 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

Re: How about some syntactic sugar for __name__ == '__main__' ?

On Thu, Nov 13, 2014 at 6:23 PM, Cameron Simpson c...@zip.com.au 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

Re: How about some syntactic sugar for __name__ == '__main__' ?

On 13Nov2014 19:04, Chris Angelico ros...@gmail.com wrote: On Thu, Nov 13, 2014 at 6:23 PM, Cameron Simpson c...@zip.com.au 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

Re: How about some syntactic sugar for __name__ == '__main__' ?

On Thu, Nov 13, 2014 at 7:47 PM, Cameron Simpson c...@zip.com.au 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

Re: How about some syntactic sugar for __name__ == '__main__' ?

In article mailman.15769.1415869145.18130.python-l...@python.org, Chris Angelico ros...@gmail.com wrote: On Thu, Nov 13, 2014 at 7:47 PM, Cameron Simpson c...@zip.com.au 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

Re: How about some syntactic sugar for __name__ == '__main__' ?

On Fri, Nov 14, 2014 at 12:33 AM, Roy Smith r...@panix.com 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

Re: How about some syntactic sugar for __name__ == '__main__' ?

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 could

Re: How about some syntactic sugar for __name__ == '__main__' ?

On Thu, Nov 13, 2014 at 11:32 AM, Ethan Furman et...@stoneleaf.us 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

Re: How about some syntactic sugar for __name__ == '__main__' ?

-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 et...@stoneleaf.us 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,

Re: How about some syntactic sugar for __name__ == '__main__' ?

On Thu, Nov 13, 2014 at 2:33 PM, Ian Kelly ian.g.ke...@gmail.com 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

Re: How about some syntactic sugar for __name__ == '__main__' ?

On Thu, Nov 13, 2014 at 2:44 PM, Skip Montanaro skip.montan...@gmail.com 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

Re: How about some syntactic sugar for __name__ == '__main__' ?

On Thu, Nov 13, 2014 at 1:44 PM, Skip Montanaro skip.montan...@gmail.com wrote: On Thu, Nov 13, 2014 at 2:33 PM, Ian Kelly ian.g.ke...@gmail.com wrote: ... other things decorated with atexit.register might actually be called before the main function I don't think that will happen. The atexit

Re: How about some syntactic sugar for __name__ == '__main__' ?

On Thu, Nov 13, 2014 at 1:53 PM, Skip Montanaro skip.montan...@gmail.com wrote: On Thu, Nov 13, 2014 at 2:44 PM, Skip Montanaro skip.montan...@gmail.com wrote: What's not documented is the behavior of calling atexit.register() while atexit._run_exitfuncs is running. That's an implementation

How about some syntactic sugar for __name__ == '__main__' ?

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 -- one

Re: How about some syntactic sugar for __name__ == '__main__' ?

On Wed, Nov 12, 2014 at 4:02 PM, John Ladasky john_lada...@sbcglobal.net 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

Re: How about some syntactic sugar for __name__ == '__main__' ?

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

Re: How about some syntactic sugar for __name__ == '__main__' ?

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

Re: How about some syntactic sugar for __name__ == '__main__' ?

On Wed, Nov 12, 2014 at 1:07 PM, Joel Goldstick joel.goldst...@gmail.com wrote: On Wed, Nov 12, 2014 at 4:02 PM, John Ladasky john_lada...@sbcglobal.net 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

Re: How about some syntactic sugar for __name__ == '__main__' ?

On Wed, Nov 12, 2014 at 2:33 PM, Chris Kaynor ckay...@zindagigames.com 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

Re: How about some syntactic sugar for __name__ == '__main__' ?

John Ladasky john_lada...@sbcglobal.net: 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

Re: How about some syntactic sugar for __name__ == '__main__' ?

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 ran as a

Re: How about some syntactic sugar for __name__ == '__main__' ?

On Wed, Nov 12, 2014 at 1:51 PM, Ian Kelly ian.g.ke...@gmail.com wrote: On Wed, Nov 12, 2014 at 2:33 PM, Chris Kaynor ckay...@zindagigames.com wrote: A decorator is an interesting idea, and should be easy to implement (only lightly tested): def main(func): if func.__module__ ==

Re: How about some syntactic sugar for __name__ == '__main__' ?

On Wed, Nov 12, 2014 at 3:09 PM, Chris Kaynor ckay...@zindagigames.com wrote: I was thinking along the lines of replacing: if __name__ == __main__: block of code with @main def myFunction() block of code Both blocks of code will be called at the same time. 99% of the time the

Re: How about some syntactic sugar for __name__ == '__main__' ?

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__ ==

Re: How about some syntactic sugar for __name__ == '__main__' ?

On Thu, Nov 13, 2014 at 10:19 AM, Terry Reedy tjre...@udel.edu 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

Re: How about some syntactic sugar for __name__ == '__main__' ?

On 11/12/2014 6:26 PM, Chris Angelico wrote: On Thu, Nov 13, 2014 at 10:19 AM, Terry Reedy tjre...@udel.edu 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

Re: How about some syntactic sugar for __name__ == '__main__' ?

On Thu, Nov 13, 2014 at 11:35 AM, Terry Reedy tjre...@udel.edu 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

Re: How about some syntactic sugar for __name__ == '__main__' ?

On 12Nov2014 14:51, Ian Kelly ian.g.ke...@gmail.com wrote: On Wed, Nov 12, 2014 at 2:33 PM, Chris Kaynor ckay...@zindagigames.com 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

Re: syntactic sugar for def?

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 for def lambda(x): return expr(x) del lambda

syntactic sugar for def?

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

Re: syntactic sugar for def?

On Wed, Sep 28, 2011 at 3:26 PM, Ethan Furman et...@stoneleaf.us 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

Re: syntactic sugar for def?

On 28 September 2011 22:26, Ethan Furman et...@stoneleaf.us 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

Re: syntactic sugar for def?

On Wed, Sep 28, 2011 at 2:37 PM, Arnaud Delobelle arno...@gmail.com wrote: On 28 September 2011 22:26, Ethan Furman et...@stoneleaf.us 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

Re: syntactic sugar for def?

En Wed, 28 Sep 2011 18:51:00 -0300, Chris Kaynor ckay...@zindagigames.com escribió: On Wed, Sep 28, 2011 at 2:37 PM, Arnaud Delobelle arno...@gmail.com wrote: On 28 September 2011 22:26, Ethan Furman et...@stoneleaf.us wrote: I remember that 'class' is sugar for type(). I don't

Re: syntactic sugar for def?

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 about functions? Currently there isn't a way

Re: syntactic sugar for def?

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 lambda(x): return expr(x) del lambda ;-) -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo

[issue5149] syntactic sugar: type coercion on pointer assignment

Vlad Riscutia riscutiav...@gmail.com added the comment: I believe there is a deeper issue here in ctypes design. Basically we provide both c_char_p and POINTER(c_char) which should behave exactly the same since both are the equivalent of char* in C but internally they have different

[issue5149] syntactic sugar: type coercion on pointer assignment

Meador Inge mead...@gmail.com added the comment: Vlad, I agree that having both 'c_char_p' and 'POINTER(c_char)' will just be more work for two seemingly identical constructs. I don't fully understand why both would be needed either (or the implications of removing one of them or making them

[issue5149] syntactic sugar: type coercion on pointer assignment

Meador Inge mead...@gmail.com added the comment: This is busted for plain old assignment too: Python 3.3.0a0 (default:6374b4ffe00c, Sep 2 2011, 23:50:39) [GCC 4.6.0 20110603 (Red Hat 4.6.0-10)] on linux Type help, copyright, credits or license for more information. from ctypes import * buff

Re: Syntactic sugar for assignment statements: one value to multiple targets?

On Aug 3, 2:45 am, gc gc1...@gmail.com 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

Re: Syntactic sugar for assignment statements: one value to multiple targets?

In article 16ea4848-db0c-489a-968c-ca40700f5...@m5g2000prh.googlegroups.com, gc gc1...@gmail.com 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

Re: Syntactic sugar for assignment statements: one value to multiple targets?

On Wed, Aug 17, 2011 at 1:14 AM, gc gc1...@gmail.com 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

Re: Syntactic sugar for assignment statements: one value to multiple targets?

On Aug 17, 3:13 am, Chris Angelico ros...@gmail.com 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

Re: Syntactic sugar for assignment statements: one value to multiple targets?

On Wed, Aug 17, 2011 at 10:26 AM, gc gc1...@gmail.com wrote: On Aug 17, 3:13 am, Chris Angelico ros...@gmail.com 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

Re: Syntactic sugar for assignment statements: one value to multiple targets?

On Aug 17, 5:45 am, Chris Angelico ros...@gmail.com 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,

Re: Syntactic sugar for assignment statements: one value to multiple targets?

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

Re: Syntactic sugar for assignment statements: one value to multiple targets?

On 17/08/2011 10:26, gc wrote: On Aug 17, 3:13 am, Chris Angelicoros...@gmail.com 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.

Re: Syntactic sugar for assignment statements: one value to multiple targets?

On Wed, Aug 17, 2011 at 5:55 PM, MRAB pyt...@mrabarnett.plus.com 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,

Re: Syntactic sugar for assignment statements: one value to multiple targets?

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 list

Re: Syntactic sugar for assignment statements: one value to multiple targets?

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

Re: Syntactic sugar for assignment statements: one value to multiple targets?

: Off on a tangent ... On 16 August 2011 20:14, gc gc1...@gmail.com 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

Re: Syntactic sugar for assignment statements: one value to multiple targets?

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

Re: Syntactic sugar for assignment statements: one value to multiple targets?

On 03/08/2011 02:45, gc wrote: cut a,b,c,d,e = *dict() where * in this context means something like assign separately to all. CUT 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 :-)

Re: Syntactic sugar for assignment statements: one value to multiple targets?

On Aug 16, 4:39 pm, Martin P. Hellwig martin.hell...@gmail.com wrote: On 03/08/2011 02:45, gc wrote: cut a,b,c,d,e = *dict() where * in this context means something like assign separately to all. snip . . . it has a certain code smell to it. snip I would love to see an example where

Re: Syntactic sugar for assignment statements: one value to multiple targets?

On 17/08/2011 01:14, gc wrote: On Aug 16, 4:39 pm, Martin P. Hellwigmartin.hell...@gmail.com wrote: On 03/08/2011 02:45, gc wrote: cut a,b,c,d,e = *dict() where * in this context means something like assign separately to all. snip . . . it has a certain code smell to it.snip I would

[issue5149] syntactic sugar: type coercion on pointer assignment

Vlad Riscutia riscutiav...@gmail.com added the comment: The main reason for this issue is that internally ctypes doesn't consider c_char_p as a pointer type. This is a bit counter-intuitive, but c_char_p is treated as a simple type and has some other sugar built-in, like easier integration

Re: Syntactic sugar for assignment statements: one value to multiple targets?

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

Re: Syntactic sugar for assignment statements: one value to multiple targets?

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))

Re: Syntactic sugar for assignment statements: one value to multiple targets?

On Wed, Aug 3, 2011 at 9:25 AM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info 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

Re: Syntactic sugar for assignment statements: one value to multiple targets?

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

Re: Syntactic sugar for assignment statements: one value to multiple targets?

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

Syntactic sugar for assignment statements: one value to multiple targets?

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

Re: Syntactic sugar for assignment statements: one value to multiple targets?

On Wed, Aug 3, 2011 at 2:45 AM, gc gc1...@gmail.com 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

Re: Some syntactic sugar proposals

On Nov 15, 12:46 pm, Tim Chase python.l...@tim.thechases.com 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 range_object' is implemented in Python 3.2,

Re: Some syntactic sugar proposals

On 12/02/2010 10:39 AM, Mark Dickinson wrote: On Nov 15, 12:46 pm, Tim Chasepython.l...@tim.thechases.com 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

Re: Some syntactic sugar proposals

On Nov 22, 2:21 pm, Andreas Löscher andreas.loesc...@s2005.tu- chemnitz.de 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 -

Re: Some syntactic sugar proposals

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 0 for x in

Re: Some syntactic sugar proposals

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 bytecode.

Re: Some syntactic sugar proposals

Steven D'Aprano steve-remove-t...@cybersource.com.au 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

Re: Some syntactic sugar proposals

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 one

Re: Some syntactic sugar proposals

Steven D'Aprano st...@remove-this-cybersource.com.au 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

Re: Some syntactic sugar proposals

? 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: t =

Re: Some syntactic sugar proposals

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 magic names. what

Re: Some syntactic sugar proposals

On Wed, 17 Nov 2010 10:18:51 -0500 Mel mwil...@the-wire.com 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

Re: Some syntactic sugar proposals

Christopher nadiasver...@gmail.com 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

Re: Some syntactic sugar proposals

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

Re: Some syntactic sugar proposals

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 could mean the

Re: Some syntactic sugar proposals

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().

Re: Some syntactic sugar proposals

On Nov 15, 2:39 am, Dmitry Groshev lambdadmi...@gmail.com 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)

Re: Some syntactic sugar proposals

On Nov 14, 11:30 pm, alex23 wuwe...@gmail.com wrote: On Nov 15, 4:39 pm, Dmitry Groshev lambdadmi...@gmail.com 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

Re: Some syntactic sugar proposals

On Nov 15, 5:50 pm, Dmitry Groshev lambdadmi...@gmail.com wrote: On Nov 15, 10:30 am, alex23 wuwe...@gmail.com 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

Re: Some syntactic sugar proposals

On Nov 15, 12:03 pm, alex23 wuwe...@gmail.com wrote: On Nov 15, 5:50 pm, Dmitry Groshev lambdadmi...@gmail.com wrote: On Nov 15, 10:30 am, alex23 wuwe...@gmail.com wrote: Personally, I like keeping object attribute references separate from dictionary item references. Your Python

Re: Some syntactic sugar proposals

Dmitry Groshev lambdadmi...@gmail.com 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

Re: Some syntactic sugar proposals

Dmitry Groshev lambdadmi...@gmail.com 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

Re: Some syntactic sugar proposals

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

Re: Some syntactic sugar proposals

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

Re: Some syntactic sugar proposals

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 things

  1   2   >