Re: Feature Request

On Wed, 23 Mar 2022 01:55:37 -0700 (PDT), Kazuya Ito declaimed the following: >Add "trun()" function to Python to truncate decimal part. You'll have to define what specific behavior you think is missing from the currently available functions? >>> plusover = 2.78 >>> plusunder = 3.14 >>>

Re: Feature Request

On 23/03/2022 03.55, Kazuya Ito wrote: Add "trun()" function to Python to truncate decimal part. Which of these should its behavior copy? from math import pi int(pi) 3 pi-int(pi) 0.14159265358979312 -- Michael F. Stemper This post contains greater than 95% post-consumer bytes by weight

Re: Feature Request: Reposition Execution

Am 15.05.15 um 05:58 schrieb Skybuck Flying: Thanks for the ideas, I haven't tried them yet. I wonder if they will work in a multi-threaded fashion. I doubt it. The run_script runs in it's own thread. It would be of enormous help if you would create a minimal script just like the above for

Re: Feature Request: Reposition Execution

"Steven D'Aprano" wrote in message news:5553145b$0$9$c3e8...@news.astraweb.com... On Wednesday 13 May 2015 17:27, Christian Gollwitzer wrote: A clean way to exit your script could be to raise an exception. It should propagate to the toplevel and halt your script. However it is not poss

Re: Feature Request: Reposition Execution

On Wednesday 13 May 2015 17:27, Christian Gollwitzer wrote: > A clean way to exit your script could be to raise an exception. It > should propagate to the toplevel and halt your script. However it is not > possible to back and resume the execution. while True: try: run_script() # May

Re: Feature Request: Reposition Execution

Am 12.05.15 um 22:18 schrieb Skybuck Flying: Thanks for suggestion, but I need a solution which can work in SikuliX as well. What the hell is that? Especially inside an observer handler that would be ideal. So far os.kill() is not supported in SikuliX as far as I can tell. OK a quick look

Re: Feature Request: Reposition Execution

"Dave Angel" wrote in message news:mailman.354.1431345441.12865.python-l...@python.org... On 05/11/2015 07:46 AM, Skybuck Flying wrote: Hello, Sometimes it can be handy to "interrupt/reset/reposition" a running script. For example something externally goes badly wrong. " os.kill() then

Re: Feature Request: Reposition Execution

On 2015-05-11, Steven D'Aprano wrote: > On Mon, 11 May 2015 09:57 pm, Dave Angel wrote: > >> On 05/11/2015 07:46 AM, Skybuck Flying wrote: >>> Hello, >>> >>> Sometimes it can be handy to "interrupt/reset/reposition" a running >>> script. >>> >>> For example something externally goes badly wrong. >

Re: Feature Request: Reposition Execution

On 05/11/2015 08:35 AM, Steven D'Aprano wrote: On Mon, 11 May 2015 09:57 pm, Dave Angel wrote: On 05/11/2015 07:46 AM, Skybuck Flying wrote: Hello, Sometimes it can be handy to "interrupt/reset/reposition" a running script. For example something externally goes badly wrong. os.kill() the

Re: Feature Request: Reposition Execution

On Mon, 11 May 2015 09:57 pm, Dave Angel wrote: > On 05/11/2015 07:46 AM, Skybuck Flying wrote: >> Hello, >> >> Sometimes it can be handy to "interrupt/reset/reposition" a running >> script. >> >> For example something externally goes badly wrong. >> > > os.kill() > > then in your process, handl

Re: Feature Request: Reposition Execution

Dave Angel : > On 05/11/2015 07:46 AM, Skybuck Flying wrote: >> Hello, >> >> Sometimes it can be handy to "interrupt/reset/reposition" a running script. >> For example something externally goes badly wrong. > > os.kill() > > then in your process, handle the exception, and do whatever you think > i

Re: Feature Request: Reposition Execution

On 05/11/2015 07:46 AM, Skybuck Flying wrote: Hello, Sometimes it can be handy to "interrupt/reset/reposition" a running script. For example something externally goes badly wrong. os.kill() then in your process, handle the exception, and do whatever you think is worthwhile. -- DaveA -

Re: Feature Request: `operator.not_in`

On 4/19/13 2:27 PM, Terry Jan Reedy wrote: On 4/19/2013 10:27 AM, Matthew Gilson wrote: ) It seems to me that the operator module should have a `not_in` or `not_contains` function. It seems asymmetric that there exists a `is_not` function which implements `x is not y` but there isn't a functio

Re: Feature Request: `operator.not_in`

On 4/19/2013 10:27 AM, Matthew Gilson wrote: ) It seems to me that the operator module should have a `not_in` or `not_contains` function. It seems asymmetric that there exists a `is_not` function which implements `x is not y` but there isn't a function to represent `x not in y`. There is also

Re: [Feature Request] dict.setdefault()

On 04/11/2011 05:44 PM, Chris Angelico wrote: On Tue, Apr 12, 2011 at 8:41 AM, MRAB wrote: I'm not sure that "setdefault" should take **kw args for this because of its existing argument structure (key + optional value). A new method like "updatedefault" may be better, IMHO. It would act like "

Re: [Feature Request] dict.setdefault()

On 11/04/2011 23:44, Chris Angelico wrote: On Tue, Apr 12, 2011 at 8:41 AM, MRAB wrote: I'm not sure that "setdefault" should take **kw args for this because of its existing argument structure (key + optional value). A new method like "updatedefault" may be better, IMHO. It would act like "upd

Re: [Feature Request] dict.setdefault()

On Mon, Apr 11, 2011 at 2:35 PM, rantingrick wrote: > > setdefault should take **kw args in the case of needing to set > multiple defaults at one time. I would even settle for an *arg list if > i had to. What would the return value be? dict.setdefault() doesn't currently just return None you know

Re: [Feature Request] dict.setdefault()

On Tue, Apr 12, 2011 at 8:41 AM, MRAB wrote: > I'm not sure that "setdefault" should take **kw args for this because > of its existing argument structure (key + optional value). > > A new method like "updatedefault" may be better, IMHO. It would act > like "update" except that it wouldn't overwrit

Re: [Feature Request] dict.setdefault()

On 11/04/2011 23:16, Westley Martínez wrote: On Mon, 2011-04-11 at 14:35 -0700, rantingrick wrote: setdefault should take **kw args in the case of needing to set multiple defaults at one time. I would even settle for an *arg list if i had to. Anything is better than... d.setdefault(blah, blah)

Re: [Feature Request] dict.setdefault()

On Mon, 2011-04-11 at 14:35 -0700, rantingrick wrote: > setdefault should take **kw args in the case of needing to set > multiple defaults at one time. I would even settle for an *arg list if > i had to. Anything is better than... > > d.setdefault(blah, blah) > d.setdefault(blah, blah) > d.setdefa

Re: feature request: string.contains('...')

On 9/24/2010 2:45 PM, Tim Chase wrote: On 09/24/10 13:01, Ethan Furman wrote: John Posner wrote: Another "missing feature" candidate: sublist >>> 'bc' in 'abcde' True >>> list('bc') in list('abcde') False I'm not aware of any idioms, but how about a simple function? Foldable into a one

Re: feature request: string.contains('...')

On 09/24/10 13:01, Ethan Furman wrote: John Posner wrote: Another "missing feature" candidate: sublist >>> 'bc' in 'abcde' True >>> list('bc') in list('abcde') False I'm not aware of any idioms, but how about a simple function? def listinlist(list1, list2): "checks if

Re: feature request: string.contains('...')

John Posner wrote: Another "missing feature" candidate: sublist >>> 'bc' in 'abcde' True >>> list('bc') in list('abcde') False I'm not aware of any idioms, but how about a simple function? def listinlist(list1, list2): "checks if list1 is in list2" if not list1: re

Re: feature request: string.contains('...')

On 9/24/2010 4:21 AM, Peter Otten wrote: If you are not interested in the position of the substr use the "in" operator: if substr in s: print "found" else: print "not found" Another "missing feature" candidate: sublist >>> 'bc' in 'abcde' True >>> list('bc') in list('abc

Re: feature request: string.contains('...')

On Freitag 24 September 2010, Wim Feijen wrote: > would really like having a string.contains('...') function > which returns either True or False. I know I can mimick this > behaviour by saying string.find('...') != -1 , however, I > find this harder to read. >>> a = 'xy134' >>> '13' in a True >>

Re: feature request: string.contains('...')

Wim Feijen wrote: > I was wondering, how to make a feature request? You can post suggestions to improve python on the python-ideas mailing list or make feature requests on the bugtracker at bugs.python.org > I would really like having a string.contains('...') function which returns > either Tru

Re: feature request for a wget -r like implementation in python3

On Apr 17, 1:14 am, "Gabriel Genellina" wrote: > En Thu, 15 Apr 2010 16:37:37 -0300, gert escribió: > > > [a wget -r like implementation in python3] > > So I can make a recursive http download script > > What about calling wget itself? subprocess.call(['wget',...]) > The only dependency I would

Re: feature request for a wget -r like implementation in python3

On Apr 16, 3:41 am, alex23 wrote: > On Apr 16, 5:37 am, gert wrote: > > > So I can make a recursive http download script > > My goal is a one click instruction to install and launch my > > projecthttp://code.google.com/p/appwsgi/ > > Here's Guido's take on wget: > >     import sys, urllib >    

Re: feature request for a wget -r like implementation in python3

En Thu, 15 Apr 2010 16:37:37 -0300, gert escribió: [a wget -r like implementation in python3] So I can make a recursive http download script What about calling wget itself? subprocess.call(['wget',...]) -- Gabriel Genellina -- http://mail.python.org/mailman/listinfo/python-list

Re: feature request for a wget -r like implementation in python3

On Apr 16, 5:37 am, gert wrote: > So I can make a recursive http download script > My goal is a one click instruction to install and launch my > projecthttp://code.google.com/p/appwsgi/ Here's Guido's take on wget: import sys, urllib def reporthook(*a): print a for url in sys.argv[1

Re: Feature request: String-inferred names

Brad Harms a écrit : On Fri, 04 Dec 2009 18:05:03 +1100, Ben Finney wrote: (snip) 2.) Attributes whose values are determined or assigned dynamically by indirectly calling a function (like properties and instancemethods) Yes, the term “property” seems to do what you want. I wasn't asking what

Re: Feature request: String-inferred names

Ben Finney a écrit : Brad Harms writes: (snip) 2.) Attributes whose values are determined or assigned dynamically by indirectly calling a function (like properties and instancemethods) Yes, the term “property” seems to do what you want. The property type is just one possible application o

Re: Feature request: String-inferred names

Brad Harms a écrit : On Tue, 2009-12-01 at 16:58 +0100, Bruno Desthuilliers wrote: The Music Guy a écrit : (snip) Lie Ryan, I think I see what you're saying about using __dict__ to add members No "members" in Python - only attributes. to a class, but it's not quite the same. __dict__ is onl

Re: Feature request: String-inferred names

On Thu, 03 Dec 2009 23:12:39 -0600, Brad Harms wrote: > On Tue, 2009-12-01 at 14:38 +, Steven D'Aprano wrote: [...] >> It's just special double-underscore methods like __init__ __add__ etc >> that have to be in the class rather than the instance. (To be precise, >> you can add such a method to

Re: Feature request: String-inferred names

On Fri, 04 Dec 2009 09:00:42 +, Steven D'Aprano wrote: > Not all such attributes are actually found in instance.__dict__. ...I hadn't even considered __slots__ yet. Hm... > Or dynamic attributes returned by __getattr__ or __getattribute__. I'm looking for a generic term, because it's too cum

Re: Feature request: String-inferred names

On Fri, 04 Dec 2009 18:05:03 +1100, Ben Finney wrote: > Brad Harms writes: > >> Anyway, it looks like the docs agree with you >> (http://docs.python.org/glossary.html#term-attribute), so I'm not going >> to argue. > > That's good, because the terms are quite well established in Python > termino

Re: Feature request: String-inferred names

On Fri, 04 Dec 2009 18:05:03 +1100, Ben Finney wrote: > Brad Harms writes: ... >> 1.) "Regular" attributes, ie. those that are shortcuts to items in the >> directly associated object's __dict__, > > I don't know what you mean by “shortcuts to items”. The names are looked > up in dictionaries; wh

Re: Feature request: String-inferred names

Brad Harms writes: > Anyway, it looks like the docs agree with you > (http://docs.python.org/glossary.html#term-attribute), so I'm not > going to argue. That's good, because the terms are quite well established in Python terminology. > However, for the purpose of clean communication, I'd still

Re: Feature request: String-inferred names

On Tue, 2009-12-01 at 14:38 +, Steven D'Aprano wrote: > On Mon, 30 Nov 2009 18:55:46 -0800, The Music Guy wrote: > > > Lie Ryan, I think I see what you're saying about using __dict__ to add > > members to a class, but it's not quite the same. __dict__ is only for > > attributes, NOT properties

Re: Feature request: String-inferred names

On Tue, 2009-12-01 at 16:58 +0100, Bruno Desthuilliers wrote: > The Music Guy a écrit : > (snip) > > Lie Ryan, I think I see what you're saying about using __dict__ to add > > members > > No "members" in Python - only attributes. > > to a class, but it's not quite the same. __dict__ is only for >

Re: Feature request: String-inferred names

On Tue, 2009-12-01 at 14:38 +, Steven D'Aprano wrote: > On Mon, 30 Nov 2009 18:55:46 -0800, The Music Guy wrote: > > > Lie Ryan, I think I see what you're saying about using __dict__ to add > > members to a class, but it's not quite the same. __dict__ is only for > > attributes, NOT properties

Re: Feature request: String-inferred names

On Dec 1, 10:21 am, Raymond Hettinger wrote: > [Gregory Ewing] > > > >>I just posted to my blog about a feature that I'd like to see added to > > >>Python. > > > >>http://alphaios.blogspot.com/2009/11/python-string-inferred-names-wor... > > > I don't think getattr and setattr are used anywhere nea

Re: Feature request: String-inferred names

[Gregory Ewing] > >>I just posted to my blog about a feature that I'd like to see added to > >>Python. > > >>http://alphaios.blogspot.com/2009/11/python-string-inferred-names-wor... > > I don't think getattr and setattr are used anywhere near > frequently enough to justify special syntax. Perhaps

Re: Feature request: String-inferred names

The Music Guy a écrit : (snip) Lie Ryan, I think I see what you're saying about using __dict__ to add members No "members" in Python - only attributes. to a class, but it's not quite the same. __dict__ is only for attributes, NOT properties, methods, etc. which all come from the class of an o

Re: Feature request: String-inferred names

On Mon, 30 Nov 2009 18:55:46 -0800, The Music Guy wrote: > Lie Ryan, I think I see what you're saying about using __dict__ to add > members to a class, but it's not quite the same. __dict__ is only for > attributes, NOT properties, methods, etc. which all come from the class > of an object rather

Re: Feature request: String-inferred names

> Brad Harms FearsomeDragonfly at gmail.com > Mon Nov 30 05:04:37 CET 2009 > > That was a relatively simple example; classes as simple as the ones > generated by the It is more likely that the class generation could would > appear in a metaclass's class constructor or decorator function, and there

Re: Feature request: String-inferred names

Brad Harms wrote: Well, yes, the names would have to be determined at run time. That's what getattr and setattr do, except that that do it in the context of an object rather than the local scope. However, I was under the impression that python's mechanism for looking up local names was the sam

Re: Feature request: String-inferred names

On 12/1/2009 3:35 AM, Bruno Desthuilliers wrote: Lie Ryan a écrit : On 11/28/2009 3:08 PM, The Music Guy wrote: (snip the part about the proposed feature - which I don't like but that's not the point) My projects rely on a lot of metaclassing for the automatic generation of properties and me

Re: Feature request: String-inferred names

Lie Ryan a écrit : On 11/28/2009 3:08 PM, The Music Guy wrote: (snip the part about the proposed feature - which I don't like but that's not the point) My projects rely on a lot of metaclassing for the automatic generation of properties and methods, which saves tremendous amounts of coding.

Re: Feature request: String-inferred names

P.S., not trying to start a flame war. It's just that I can't stand to keep silent on the matter any longer. -- Brad Harms -- http://mail.python.org/mailman/listinfo/python-list

Re: Feature request: String-inferred names

Cameron Simpson writes: > The Zen promotes the guideline that there should be only one (obvious) > way to do most things and that's a surprisingly effective design rule. It's also important to realise that the Zen places the “preferably only one” in a parenthetical, and note that “preferably” qu

Re: Feature request: String-inferred names

Lie Ryan a écrit : (snip) > setattr, getattr, and delattr are already sugar for accessing instance.__dict__. They are actually much more than that - else descriptors and inheritance wouldn't work. -- http://mail.python.org/mailman/listinfo/python-list

Re: Feature request: String-inferred names

On Sun, Nov 29, 2009 at 11:01 PM, Brad Harms wrote: > > May the Penguin in the sky bless your every subroutine, > Um...feel free to ignore that. >_> -- Brad Harms -- http://mail.python.org/mailman/listinfo/python-list

Re: Feature request: String-inferred names

On Sun, Nov 29, 2009 at 9:59 PM, Carl Banks wrote: > Another thing that can be determined through common sense is that if > you have object that you are calling getattr and setattr on so much > that you think you need special syntax, you should have been using a > dict. > (Re-send; original was s

Re: Feature request: String-inferred names

On Sun, Nov 29, 2009 at 7:49 PM, Lie Ryan wrote: > On 11/29/2009 12:22 PM, The Music Guy wrote: > >> When I first started seeing @ show up in Python code, I said "what the >> heck is that? It looks so weird and _ugly_.I would never try to mess >> with that." But I started seeing it more and more,

Re: Feature request: String-inferred names

On Nov 28, 3:38 am, The Music Guy wrote: > On Nov 28, 3:07 am, Lie Ryan wrote: > > If you use it a lot, it is likely 1) you have abused class syntax for > > what should have been a dict or 2) what you need is to override > > __getattr__/__getattribute__ and __setattr__ > > Oh boy...here we go. :|

Re: Feature request: String-inferred names

On Nov 26, 3:43 pm, The Music Guy wrote: > That aside, I still feel that a new syntax would be a better solution > than a new class. And, anyway, what I'm proposing isn't *quite* the > same as what Ben North proposed. Ben's idea was *strictly* to create > shorthand syntax to the getattr/setattr/de

Re: Feature request: String-inferred names

On 11/29/2009 12:22 PM, The Music Guy wrote: When I first started seeing @ show up in Python code, I said "what the heck is that? It looks so weird and _ugly_.I would never try to mess with that." But I started seeing it more and more, so I asked #python what it was. They told me about decorators

Re: Feature request: String-inferred names

The Music Guy wrote: When I first started seeing @ show up in Python code, I said "what the heck is that? For future reference, PySymbols.html at http://code.google.com/p/xploro/downloads/list answers all such symbol questions. -- http://mail.python.org/mailman/listinfo/python-list

Re: Feature request: String-inferred names

On Sun, Nov 29, 2009 at 6:58 AM, inhahe wrote: > Did you say you were using gmail to post?  I think mailing lists tend to > have issues with gmail because it puts html in the message or something like > that.  Btw I recently set up this mailing list to send me a message back > when I successfully

Re: Feature request: String-inferred names

On Sun, Nov 29, 2009 at 5:15 AM, The Music Guy wrote: > Okay, I'm having a really hard time telling which messages are getting > on to the list and which ones aren't. Some of the messages I send show > up in the comp.lang.python mirror in Google Groups, and some aren't. > Others show up on the Gro

Re: Feature request: String-inferred names

Okay, I'm having a really hard time telling which messages are getting on to the list and which ones aren't. Some of the messages I send show up in the comp.lang.python mirror in Google Groups, and some aren't. Others show up on the Groups mirror, but don't show up in Gmail, or show up in a differe

Re: Feature request: String-inferred names

> > On Sat, Nov 28, 2009 at 9:39 PM, Steven D'Aprano < st...@remove-this-cybersource.com.au> wrote: > > Removing code redundancy is all very well, but beware of turning into an > >> architecture astronaut: > >> > http://www.joelonsoftware.com/articles/fog18.html > >> > There is such a thin

Re: Feature request: String-inferred names

i like this idea (i posted some thoughts on it in the blog, but it's not approved yet as of this writing) in short, i suggested extending the idea to make it more a) generalized, b) simple, c) intuitive, and d) flexible. so instead of just using $ for attributes, you could use it anywhere you def

Re: Feature request: String-inferred names

On Sat, 28 Nov 2009 17:22:27 -0800, The Music Guy wrote: > As for my specific use case, it's somewhat difficult to explain. The > general idea was to isolate a pattern that I spotted repeated in several > unrelated parts of my project. The pattern manifested itself as a set of > 4-5 methods and/or

Re: Feature request: String-inferred names

On Nov 28, 6:10 am, Lie Ryan wrote: > On 11/28/2009 10:38 PM, The Music Guy wrote: > > >> If you use it a lot, it is likely 1) you have abused class syntax for > >> what should have been a dict or 2) what you need is to override > >> __getattr__/__getattribute__ and __setattr__ > > > Oh boy...here

Re: Feature request: String-inferred names

On Sat, 28 Nov 2009 03:38:38 -0800, The Music Guy wrote: > Please listen. In all the time I've spent in the coding community > (that's at least 7 years) and especially since I started paying > attention to the Python community (2 years), I have noticed a trend: > When one coder does something that

Re: Feature request: String-inferred names

On Nov 28, 6:10 am, Lie Ryan wrote: > On 11/28/2009 10:38 PM, The Music Guy wrote: > > >> If you use it a lot, it is likely 1) you have abused class syntax for > >> what should have been a dict or 2) what you need is to override > >> __getattr__/__getattribute__ and __setattr__ > > > Oh boy...here

Re: Feature request: String-inferred names

On 11/28/2009 10:38 PM, The Music Guy wrote: If you use it a lot, it is likely 1) you have abused class syntax for what should have been a dict or 2) what you need is to override __getattr__/__getattribute__ and __setattr__ Oh boy...here we go. :| ok, then what's your use case, AFAICT in the

Re: Feature request: String-inferred names

The Music Guy writes: > Please listen. In all the time I've spent in the coding community > (that's at least 7 years) and especially since I started paying > attention to the Python community (2 years), I have noticed a trend: > When one coder does something that another cannot understand, > freq

Re: Feature request: String-inferred names

On Nov 28, 3:07 am, Lie Ryan wrote: > On 11/28/2009 3:08 PM, The Music Guy wrote: > > > As for your code, I haven't seen it, so it would be hard for me to say > > exactly how the new syntax would come into play. What I can tell you, > > however, is that the parts of your code that would use it wou

Re: Feature request: String-inferred names

On Fri, 27 Nov 2009 20:02:31 -0800, The Music Guy wrote: > That PEP seems to pretty clearly state that it applies only to the 3.x > branch and not to the 2.x branch. Is there maybe a slim chance of > getting my idea added to 2.7, or even 2.8? :D The only new features being added to 2.7 are featu

Re: Feature request: String-inferred names

On 11/28/2009 3:08 PM, The Music Guy wrote: As for your code, I haven't seen it, so it would be hard for me to say exactly how the new syntax would come into play. What I can tell you, however, is that the parts of your code that would use it would probably be easier to read and change to anyone

Re: Feature request: String-inferred names

Gred, thanks for your comments. On Nov 26, 7:49 pm, Gregory Ewing wrote: > > [...] Also, many of the uses of getattr in the std lib appear > to be of the 3-argument form, which your suggested syntax > doesn't cover. [...] Good point. After excluding those, only ~435 uses would work for my propos

Re: Feature request: String-inferred names

On Nov 26, 9:10 pm, "Gabriel Genellina" wrote: > En Thu, 26 Nov 2009 20:43:04 -0300, The Music Guy   > escribió: > > > Nonetheless, the fact remains that the feature I'm proposing closely > > resembles one that has already been rejected... Well, it's been a few > > years since then. Maybe its abo

Re: Feature request: String-inferred names

Testing, testing...is this thing on? Hang on guys, I'm having some trouble posting to the mailing list suddenly. -- http://mail.python.org/mailman/listinfo/python-list

Re: Feature request: String-inferred names

En Thu, 26 Nov 2009 20:43:04 -0300, The Music Guy escribió: Nonetheless, the fact remains that the feature I'm proposing closely resembles one that has already been rejected... Well, it's been a few years since then. Maybe its about time for another PEP to be proposed? You'll have to wait a

Re: Feature request: String-inferred names

The Music Guy wrote: As for it not being useful enough to justify new syntax, well, I think Ben showed pretty well that it actually is. Approximately 600 uses of the get*r functions were used in the Python 2.5 standard library alone. The standard library isn't necessarily representative of Pyt

Re: Feature request: String-inferred names

On 25Nov2009 21:45, Brad wrote: | On Nov 25, 10:49 pm, Chris Rebert wrote: | > On Wed, Nov 25, 2009 at 6:35 PM, The Music Guy | > wrote: | > > I just posted to my blog about a feature that I'd like to see added to | > > Python. Before I go through the trouble of learning how to write a PEP or |

Re: Feature request: String-inferred names

The Music Guy writes: > Nonetheless, the fact remains that the feature I'm proposing closely > resembles one that has already been rejected... Well, it's been a few > years since then. The passage of time is insufficient. The idea also needs to have greater merit now than before. You haven't dem

Re: Feature request: String-inferred names

On Nov 27, 10:43 am, The Music Guy wrote: [snip] > Nonetheless, the fact remains that the feature I'm proposing closely > resembles one that has already been rejected... Well, it's been a few > years since then. Maybe its about time for another PEP to be proposed? Judging by the response you've

Re: Feature request: String-inferred names

On Nov 26, 12:30 am, "Gabriel Genellina" wrote: > En Wed, 25 Nov 2009 23:35:06 -0300, The Music Guy   > escribió: > > > I just posted to my blog about a feature that I'd like to see added to > > Python. Before I go through the trouble of learning how to write a PEP or > > how to extend the Python

Re: Feature request: String-inferred names

Gregory Ewing wrote: On Wed, 25 Nov 2009 20:44:36 -0600, The Music Guy declaimed the following in gmane.comp.python.general: I just posted to my blog about a feature that I'd like to see added to Python. http://alphaios.blogspot.com/2009/11/python-string-inferred-names-working.html I don'

Re: Feature request: String-inferred names

On Wed, 25 Nov 2009 20:44:36 -0600, The Music Guy declaimed the following in gmane.comp.python.general: I just posted to my blog about a feature that I'd like to see added to Python. http://alphaios.blogspot.com/2009/11/python-string-inferred-names-working.html I don't think getattr and seta

Re: Feature request: String-inferred names

Brad wrote: On Nov 25, 10:49 pm, Chris Rebert wrote: On Wed, Nov 25, 2009 at 6:35 PM, The Music Guy wrote: Hello all, I just posted to my blog about a feature that I'd like to see added to Python. Before I go through the trouble of learning how to write a PEP or how to extend the Python inte

Re: Feature request: String-inferred names

En Wed, 25 Nov 2009 23:35:06 -0300, The Music Guy escribió: I just posted to my blog about a feature that I'd like to see added to Python. Before I go through the trouble of learning how to write a PEP or how to extend the Python interpreter, I want to know what people in the community have t

Re: Feature request: String-inferred names

P.S., my apologies for sending replies with different email addresses. This is an unintentional technical issue and I am currently trying to get it fixed. On Wed, Nov 25, 2009 at 11:45 PM, Brad wrote: > On Nov 25, 10:49 pm, Chris Rebert wrote: > > On Wed, Nov 25, 2009 at 6:35 PM, The Music Guy

Re: Feature request: String-inferred names

On Nov 25, 10:49 pm, Chris Rebert wrote: > On Wed, Nov 25, 2009 at 6:35 PM, The Music Guy > > wrote: > > Hello all, > > > I just posted to my blog about a feature that I'd like to see added to > > Python. Before I go through the trouble of learning how to write a PEP or > > how to extend the Pyth

Re: Feature request: String-inferred names

On Wed, Nov 25, 2009 at 6:35 PM, The Music Guy wrote: > Hello all, > > I just posted to my blog about a feature that I'd like to see added to > Python. Before I go through the trouble of learning how to write a PEP or > how to extend the Python interpreter, I want to know what people in the > comm

Re: Feature request: String-inferred names

I just posted to my blog about a feature that I'd like to see added to Python. Before I go through the trouble of learning how to write a PEP or how to extend the Python interpreter, I want to know what people in the community have to say about it. http://alphaios.blogspot.com/2009/11/python-strin

Re: Feature request: New string conversion type to ignore list item

pelon wrote: > On Jun 5, 6:27 am, [EMAIL PROTECTED] wrote: >> On 5 Jun., 13:12, Peter Otten <[EMAIL PROTECTED]> wrote: >> >>> or like this: >> "%s %.s %s" % ("first", "second", "third") >>> 'first third' >> Hey, that's great, thanks Peter! >> >> Tom > > Why not be consistent with other aspect

Re: Feature request: New string conversion type to ignore list item

On Jun 5, 6:27 am, [EMAIL PROTECTED] wrote: > On 5 Jun., 13:12, Peter Otten <[EMAIL PROTECTED]> wrote: > > > or like this: > > > >>> "%s %.s %s" % ("first", "second", "third") > > > 'first third' > > Hey, that's great, thanks Peter! > > Tom Why not be consistent with other aspects of the language

Re: Feature request: New string conversion type to ignore list item

On 5 Jun., 13:12, Peter Otten <[EMAIL PROTECTED]> wrote: > or like this: > > >>> "%s %.s %s" % ("first", "second", "third") > > 'first third' Hey, that's great, thanks Peter! Tom -- http://mail.python.org/mailman/listinfo/python-list

Re: Feature request: New string conversion type to ignore list item

[EMAIL PROTECTED] wrote: > let's assume you want to nicely print the content of a list except for > one (or some) individual item. You could do it like this: > t = ["foo", "skip me", 1, 2, 3] > print("text: %s\nvalues: %i %i %i" % (t[0], t[2], t[3], t[4])) or like this: >>> "%s %.s %s" % ("fir

Re: Feature Request: Py_NewInterpreter to create separate GIL (branch)

Hi allStrange enough, there does not even seem to be interest in removing the GIL in Python 3000.For some interesting answers on this topic you may read through the thread "Kill GIL" on the py3k mailing list archives: .kind re

Re: Feature request: sorting a list slice

John Machin wrote: > Context? The whole message asked for a new feature. Please tell me what > context I should have supplied. When you reply to a message, please quote part of that message. That's what was meant by context. -- Robert Kern "I have come to believe that the whole world is an enig

Re: Feature request: sorting a list slice

Am Sonntag 21 Mai 2006 18:55 schrieb Raymond Hettinger: > If the perf gain is small and the use cases are infrequent, the > addition is likely unwarranted. There is an entire class of feature > requests that are more appropriate as recipes than for inclusion in the > language. The thing is: havi

Re: Feature request: sorting a list slice

Getting a patch ready for checkin (corrected, documented, reviewed, and tested) is only part of the battle. The real challenge of language design is figuring out whether something should be done. Adding optional parameters to a method makes its invocation slower and makes the API harder to learn

Re: Feature request: sorting a list slice

Feature? regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Love me, love my blog http://holdenweb.blogspot.com Recent Ramblings http://del.icio.us/steve.holden -- http://mail.python.org/mailman/listinfo/python-list

Re: Feature request: sorting a list slice

Context? The whole message asked for a new feature. Please tell me what context I should have supplied. -- http://mail.python.org/mailman/listinfo/python-list

  1   2   >