Re: filename of calling function?
On Nov 28, 11:40 am, Phlip wrote: > On Nov 28, 8:19 am, Phlip wrote: > > > > > Consider these two python modules: > > > aa.py > > > def a(): > > print '?' > > > bb.py > > import aa > > > def bb(): > > aa.a() > > > bb() > > > How do I make the print line emit the filename of bb.py? (It could be > > anything.) > > try: > raise None > except: > import sys > from traceback import extract_tb, extract_stack > frame = sys.exc_info()[2].tb_frame.f_back > calling_file = extract_stack(frame, 2)[1][0] code works perfectly except on my system both the indexes need to be 0 (eg: "extract_stack(frame, 2)[0][0]") -- http://mail.python.org/mailman/listinfo/python-list
Unpacking Tuples
I hate to post such a simple Q and A here, but I seriously can't find it anywhere. Python (unsure of starting with which version) enables the remainder of the tuple to be placed in a "catch-all", for example: >> myTuple = (1,2,3,4) >> varOne, varTwo, *remaindingTuple = myTuple. where the values left unpacked get thrown into a tuple referenced to by "remaindingTuple" I included the asterix because it seems like I remember that being the operator that specifying the tuple's dumping ground. Which brings me to my two questions: 1) what's the syntax for this operation 2) what version does it start with? -- http://mail.python.org/mailman/listinfo/python-list
Partial list comprehensions
Is it possible to run a list comprehension over a certain portion of the list? My goals is to be able to run the comprehension on the innermost elements of the list, but leaving the outermost intact. -- http://mail.python.org/mailman/listinfo/python-list
Re: Partial list comprehensions
On Dec 4, 3:41 pm, Mensanator wrote: > On Dec 4, 2:22 pm, Joel Davis wrote: > > > Is it possible to run a list comprehension over a certain portion of > > the list? My goals is to be able to run the comprehension on the > > innermost elements of the list, but leaving the outermost intact. > > Something like this? > > >>> a > > [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] > > >>> b = [i for i in a[0:5]] > >>> b > [0, 1, 2, 3, 4] > >>> c = [i for i in a if i%2==0] > >>> c > [0, 2, 4, 6, 8] > > Yes, sort of like that but Hansen's code is actually exactly what I was getting at, not sure why he deleted it: >>> a = range(100) >>> a[2:-2] = [str(x) for x in a[2:-2]] >>> a [0, 1, '2', '3', '4', '5', '6', '7', '8', '9', '10', '11', '12', '13', '14', '15', '16', '17', '18', '19', '20', '21', '22', '23', '24', '25', '26', '27', '28', '29', '30', '31', '32', '33', '34', '35', '36', '37', '38', '39', '40', '41', '42', '43', '44', '45', '46', '47', '48', '49', '50', '51', '52', '53', '54', '55', '56', '57', '58', '59', '60', '61', '62', '63', '64', '65', '66', '67', '68', '69', '70', '71', '72', '73', '74', '75', '76', '77', '78', '79', '80', '81', '82', '83', '84', '85', '86', '87', '88', '89', '90', '91', '92', '93', '94', '95', '96', '97', 98, 99] -- http://mail.python.org/mailman/listinfo/python-list
getting name of passed reference
I'm just curious if anyone knows of a way to get the variable name of a reference passed to the function. Put another way, in the example: def MyFunc ( varPassed ): print varPassed; MyFunc(nwVar) how would I get the string "nwVar" from inside of "MyFunc"? is it possible? -- http://mail.python.org/mailman/listinfo/python-list
Re: getting name of passed reference
For posterity, I figured out a solution: > #!/usr/bin/python > import sys > from traceback import extract_stack > varPassed="varName get" > def MyFunc(varPassed): > try: > raise None > except: > frame = sys._getframe(1) > print extract_stack(frame,2)[0][3] > MyFunc(varPassed) the print statement returns the full function call including parameters as they were written in the script (variable names and all) On Dec 28, 8:10 pm, Emile van Sebille wrote: > On 12/28/2009 3:54 PM Joel Davis said... > > > I'm just curious if anyone knows of a way to get the variable name of > > a reference passed to the function. > > For curiosity, sure -- but it's real weak... > > > Put another way, in the example: > > > def MyFunc ( varPassed ): > > print varPassed; > > > MyFunc(nwVar) > > > how would I get the string "nwVar" from inside of "MyFunc"? > > Here are some ways of doing > this:http://www.python-forum.org/pythonforum/viewtopic.php?f=14&t=12659 > > > is it possible? > > Yes -- but only for a limited set of situations. Consider the following: > > MyFunc(3) > > a=[1,2,3,4] > MyFunc(a[2]) > > b=a > MyFunc(b[2]) > > def newval(): return 3 > MyFunc(newval()) > > MyFunc(range(3)[-1]) > > Emile at first glance the solution i came up with seems to be in general the same as the one presented there, are there any portability issues you're aware of? also, when can one _not_ get the name? -- http://mail.python.org/mailman/listinfo/python-list
Re: getting name of passed reference
On Dec 28, 8:40 pm, Steven D'Aprano wrote: > On Mon, 28 Dec 2009 17:27:21 -0800, Joel Davis wrote: > > For posterity, I figured out a solution: > > > > #!/usr/bin/python > > > > import sys > > > from traceback import extract_stack > > > > varPassed="varName get" > > > > def MyFunc(varPassed): > > > try: > > > raise None > > > except: > > > frame = sys._getframe(1) > > > print extract_stack(frame,2)[0][3] > > > > MyFunc(varPassed) > > Incorrect. Here's a copy-and-paste from an interactive session using that > code: > > >>> import sys > >>> from traceback import extract_stack > > >>> varPassed="varName get" > > >>> def MyFunc(varPassed): > > ... try: > ... raise None > ... except: > ... frame = sys._getframe(1) > ... print extract_stack(frame,2)[0][3] > ... > > >>> MyFunc(varPassed) > None > > > the print statement returns the full function call including parameters > > as they were written in the script (variable names and all) > > I'm afraid not. I don't know what testing you did, but it doesn't work as > you think it works. > > Also, I notice that you've called the variable local to the function the > same name as the variable in the outer scope. What happens when you do > this? > > >>> x = "something else" > >>> MyFunc(x) > > None > > > at first glance the solution i came up with seems to be in general the > > same as the one presented there, are there any portability issues > > you're aware of? > > Yes. > > sys._getframe is a PRIVATE function, which means it is subject to change > without notice. You're using an internal function clearly marked as > private. It is unlikely to even exist at all in other implementations of > Python (e.g. Jython, IronPython, PyPy, CLPython, etc.), and it might not > even exist in future versions of CPython. > > > also, when can one _not_ get the name? > > When the object doesn't have a name at all, or when it has multiple > names. Which is "the" name? > > -- > Steven steven, when I said that's what the code returned I was explaining what I saw when I ran it, if you're having trouble running it in the interactive terminal, then that's probably because it can't be ran in the interactive terminal. -- http://mail.python.org/mailman/listinfo/python-list
Re: getting name of passed reference
As far as more positive things are concerned, is anyone aware of what the support for _getframe(1) the way I used it is? Does steven have a newer (or older) version than me, maybe? (2.6.2) it seems like the sort of thing that ought to have pretty uniform behavior, but are their certain calls it varies on? -- http://mail.python.org/mailman/listinfo/python-list
Re: getting name of passed reference
On Dec 28, 9:37 pm, Joel Davis wrote:
> As far as more positive things are concerned, is anyone aware of what
> the support for _getframe(1) the way I used it is? Does steven have a
> newer (or older) version than me, maybe? (2.6.2) it seems like the
> sort of thing that ought to have pretty uniform behavior, but are
> their certain calls it varies on?
my thanks go out to Emile and Mr Hanson for their responses, I think
I've found the solution, much shorter as well:
> #!/usr/bin/python
> import traceback
> def testing ( varPassed ):
> print traceback.extract_stack()[0][3]
> testing("123")
and it seems the traceback module in general seems to have a lot of
history to it. This project is for CPython so compatibility with
Jython, Iron Python, et al isn't really that important right now. So
as far as functionality and compatibility I think I'm set as long as
traceback.extract_stack is 3.0 safe.
--
http://mail.python.org/mailman/listinfo/python-list
Re: getting name of passed reference
On Dec 29, 2:04 am, Steven D'Aprano
wrote:
> On Mon, 28 Dec 2009 19:28:32 -0800, Joel Davis wrote:
> > my thanks go out to Emile and Mr Hanson for their responses, I think
> > I've found the solution, much shorter as well:
>
> > > #!/usr/bin/python
>
> > > import traceback
>
> > > def testing ( varPassed ):
> > > print traceback.extract_stack()[0][3]
>
> > > testing("123")
>
> > and it seems the traceback module in general seems to have a lot of
> > history to it. This project is for CPython so compatibility with Jython,
> > Iron Python, et al isn't really that important right now. So as far as
> > functionality and compatibility I think I'm set as long as
> > traceback.extract_stack is 3.0 safe.
>
> I'm afraid that one fails again. Do you actually test your solutions
> before telling us you've solved the problem?
>
> >>> import traceback
> >>> def testing ( varPassed ):
>
> ... print traceback.extract_stack()[0][3]
> ...
>
> >>> testing("123")
> None
> >>> x = "123"
> >>> testing(x)
>
> None
>
> When a "solution" doesn't work under some circumstances (in this case,
> when run in the interactive interpreter) that's a warning that you need
> to understand when and where it will work before using it in production.
> Otherwise, how do you know that it will work under other circumstances?
>
> Or, find an alternative. What are you actually trying to do? "Get the
> name of a passed reference" is a means to an end. What are you expecting
> to do with it?
>
> --
> Steven
Steven I don't know what your issue is, but it works for me. If your
having trouble running the code, then that's your issue, and I would
appreciate it if you would just shut up until you know what the hell
you're talking about. I say that because if you paid the slightest
attention my first solution that you found so woefully inept IS
BASICALLY YOUR FIRST SOLUTION RECONFIGURED.
You also apparently can't read.
--
http://mail.python.org/mailman/listinfo/python-list
Re: getting name of passed reference
On Dec 29, 2:29 am, "Gabriel Genellina"
wrote:
> En Tue, 29 Dec 2009 00:28:32 -0300, Joel Davis
> escribió:
>
>
>
> > On Dec 28, 9:37 pm, Joel Davis wrote:
> > my thanks go out to Emile and Mr Hanson for their responses, I think
> > I've found the solution, much shorter as well:
>
> > > #!/usr/bin/python
>
> > > import traceback
>
> > > def testing ( varPassed ):
> > > print traceback.extract_stack()[0][3]
>
> > > testing("123")
>
> > and it seems the traceback module in general seems to have a lot of
> > history to it. This project is for CPython so compatibility with
> > Jython, Iron Python, et al isn't really that important right now. So
> > as far as functionality and compatibility I think I'm set as long as
> > traceback.extract_stack is 3.0 safe.
>
> Test with this:
>
> def f(): return g()
> def g(): return h()
> def h(): testing("123")
> f()
>
> You probably want traceback.extract_stack()[-2][3] instead.
>
> Note that your solution solves a different problem: you asked "the name of
> the passed object" and testing() above prints "the source line of the
> previous stack frame". This method may be good enough for you, but you
> should be aware of its limitations:
>
> - The source code (.py file) of the module containing the calling function
> must be present (a .pyc file is not enough).
> - It must be a plain text file in the filesystem, directly reachable in a
> directory along sys.path (it may not be contained in a .zip file, an .egg,
> or use any other kind of import mechanism).
> - The source retrieval may fail if your program changes the current
> directory
> - If the calling function is not actually inside a module, you can't
> retrieve its source (e.g. when using exec/eval, or from inside the
> interactive interpreter).
> - Only the last line of the function invocation is returned; you miss all
> its previous lines and/or arguments.
>
> I'm sure other limitations apply too -- don't rely on this technique for
> anything critical.
>
> --
> Gabriel Genellina
Gabriel,
thanks for your input, I had no idea that did that and it could have
been deployed without even being aware of it, caused consternation and
headaches galore.
--
http://mail.python.org/mailman/listinfo/python-list
Re: getting name of passed reference
On Dec 29, 10:08 am, Steve Holden wrote:
> Joel Davis wrote:
> > On Dec 29, 2:04 am, Steven D'Aprano
> > wrote:
> >> On Mon, 28 Dec 2009 19:28:32 -0800, Joel Davis wrote:
> >>> my thanks go out to Emile and Mr Hanson for their responses, I think
> >>> I've found the solution, much shorter as well:
> >>> > #!/usr/bin/python
> >>> > import traceback
> >>> > def testing ( varPassed ):
> >>> > print traceback.extract_stack()[0][3]
> >>> > testing("123")
> >>> and it seems the traceback module in general seems to have a lot of
> >>> history to it. This project is for CPython so compatibility with Jython,
> >>> Iron Python, et al isn't really that important right now. So as far as
> >>> functionality and compatibility I think I'm set as long as
> >>> traceback.extract_stack is 3.0 safe.
> >> I'm afraid that one fails again. Do you actually test your solutions
> >> before telling us you've solved the problem?
>
> >>>>> import traceback
> >>>>> def testing ( varPassed ):
> >> ... print traceback.extract_stack()[0][3]
> >> ...
>
> >>>>> testing("123")
> >> None
> >>>>> x = "123"
> >>>>> testing(x)
> >> None
>
> >> When a "solution" doesn't work under some circumstances (in this case,
> >> when run in the interactive interpreter) that's a warning that you need
> >> to understand when and where it will work before using it in production.
> >> Otherwise, how do you know that it will work under other circumstances?
>
> >> Or, find an alternative. What are you actually trying to do? "Get the
> >> name of a passed reference" is a means to an end. What are you expecting
> >> to do with it?
>
> >> --
> >> Steven
>
> > Steven I don't know what your issue is, but it works for me. If your
> > having trouble running the code, then that's your issue, and I would
> > appreciate it if you would just shut up until you know what the hell
> > you're talking about. I say that because if you paid the slightest
> > attention my first solution that you found so woefully inept IS
> > BASICALLY YOUR FIRST SOLUTION RECONFIGURED.
>
> > You also apparently can't read.
>
> Whereas you appear to have a problem maintaining good manners.
>
> regards
> Steve
> --
> Steve Holden +1 571 484 6266 +1 800 494 3119
> PyCon is coming! Atlanta, Feb 2010 http://us.pycon.org/
> Holden Web LLC http://www.holdenweb.com/
> UPCOMING EVENTS: http://holdenweb.eventbrite.com/
well not to engage in a he/she said, but in my own defense D'Aprano
did set the tone and I think I've been more than a little tolerant on
this. Someone posts a question, responds back with a "n/m I found the
solution, here it is" and his response is essentially to berate them,
telling them how crappy their code is and that they should at least
_try_ the code. Bear in mind that I even told him the reason he wasn't
able to run it is because he's pasting it into the interactive
terminal. He then responded back AGAIN with the same insults and the
same issue that shows he didn't really even read my last response.
If anything, I should be faulted for actually engaging him and not
just letting it go.
--
http://mail.python.org/mailman/listinfo/python-list
Re: getting name of passed reference
On Dec 29, 11:21 am, Emile van Sebille wrote: > On 12/29/2009 7:02 AM Joel Davis said... > > > On Dec 29, 2:29 am, "Gabriel Genellina" > > wrote: > >> I'm sure other limitations apply too -- don't rely on this technique for > >> anything critical. > > >> -- > >> Gabriel Genellina > > > Gabriel, > > > thanks for your input, I had no idea that did that and it could have > > been deployed without even being aware of it, caused consternation and > > headaches galore. > > In an extremely controlled situation you may avoid headaches when > deploying this kind of technique. Regardless, we all want to make you > aware that this _will_ likely cause headaches, and, idle curiosity > aside, none of us can imagine the problem to which this is the > appropriate solution. > > It's fun to work out, but you're probably better served if you describe > the problem you're solving and consider the alternatives suggested. > > Dependence on introspection belongs in programming tools, not in > applications deployed across versions and platforms. > > Emile Emile, essentially, the situation is that I'm trying to create an API for consumption scripting. As it stands now, in initial development they can pass callback function. The idea was to enable them to pass variables and have the handling function determine the type and just drop the value into it instead of calling function with the value as an argument. The problem with that approach is determining exactly which variable was passed. My idea was to use this to capture the name and then modify the globals for the executing frame so that the passed variable represents the new value. -- http://mail.python.org/mailman/listinfo/python-list
Re: python simply not scaleable enough for google?
On Nov 12, 10:07 am, mcherm wrote: > On Nov 11, 7:38 pm, Vincent Manis wrote: > > > 1. The statement `Python is slow' doesn't make any sense to me. > > Python is a programming language; it is implementations that have > > speed or lack thereof. > [...] > > 2. A skilled programmer could build an implementation that compiled > > Python code into Common Lisp or Scheme code, and then used a > > high-performance Common Lisp compiler... > > I think you have a fundamental misunderstanding of the reasons why > Python is > slow. Most of the slowness does NOT come from poor implementations: > the CPython > implementation is extremely well-optimized; the Jython and Iron Python > implementations use best-in-the-world JIT runtimes. Most of the speed > issues > come from fundamental features of the LANGUAGE itself, mostly ways in > which > it is highly dynamic. > > In Python, a piece of code like this: > len(x) > needs to watch out for the following: > * Perhaps x is a list OR > * Perhaps x is a dict OR > * Perhaps x is a user-defined type that declares a __len__ > method OR > * Perhaps a superclass of x declares __len__ OR > * Perhaps we are running the built-in len() function OR > * Perhaps there is a global variable 'len' which shadows the > built-in OR > * Perhaps there is a local variable 'len' which shadows the > built-in OR > * Perhaps someone has modified __builtins__ > > In Python it is possible for other code, outside your module to go in > and > modify or replace some methods from your module (a feature called > "monkey-patching" which is SOMETIMES useful for certain kinds of > testing). > There are just so many things that can be dynamic (even if 99% of the > time > they are NOT dynamic) that there is very little that the compiler can > assume. > > So whether you implement it in C, compile to CLR bytecode, or > translate into > Lisp, the computer is still going to have to to a whole bunch of > lookups to > make certain that there isn't some monkey business going on, rather > than > simply reading a single memory location that contains the length of > the list. > Brett Cannon's thesis is an example: he attempted desperate measures > to > perform some inferences that would allow performing these > optimizations > safely and, although a few of them could work in special cases, most > of the > hoped-for improvements were impossible because of the dynamic nature > of the > language. > > I have seen a number of attempts to address this, either by placing > some > restrictions on the dynamic nature of the code (but that would change > the > nature of the Python language) or by having some sort of a JIT > optimize the > common path where we don't monkey around. Unladen Swallow and PyPy are > two > such efforts that I find particularly promising. > > But it isn't NEARLY as simple as you make it out to be. > > -- Michael Chermside obviously the GIL is a major reason it's so slow. That's one of the _stated_ reasons why Google has decided to forgo CPython code. As far as how sweeping the directive is, I don't know, since the situation would sort of resolve itself if one committed to Jython application building or just wait until unladen swallow is finished. -- http://mail.python.org/mailman/listinfo/python-list
Re: python gui builders
On Nov 16, 5:06 am, me wrote: > Good People > > I do not write stuff for humans, as it has been my job to remove > humans from the loop. But I have to make a front end to a > component database where everything was built in Python. > > I have looked at the Tk stuff that is built into Python -> not > acceptable. So looking at wxGlade, Boa Constructor, Python Card. > Also looked at the frames/forms created with QtDesigner, which > can be used by Python via pyuic. BlackAdder IDE seems to have > this built-in, but am loathe to buy into another GUI tool for a > single job. > > I have not been able to find a decent Python gui builder. The > last time I did gui garbage was with Borland C++ Builder which > was ok because I was only using win boxen for that project. This > time I am using both Linux and Win. > > What Python gui builder is well supported, does not require me > to learn another framework/library, and can crank out stuff for > multiple platforms ? > > thanks much, > me Glade is pretty easy to use, especially for a simple front end, if you already know python, then the amount of GTK you'd have to learn would be very minimal (5-15 minute crash course in it should suffice.) build your GUI in Glade, link the python code to the xml file, and the go back to coding non-gui stuff in no time. The Glade utility is free software so there's no expense (unless you get charged by the byte on your downloads.) -- http://mail.python.org/mailman/listinfo/python-list
