exec within function
hi,
I'm not sure how I can use exec within a function correctly
here is the code i'm using:
def a():
exec('b=1')
print(b)
a()
this will raise an error, but I would like to see it outputting 1
thanks
smk
--
http://mail.python.org/mailman/listinfo/python-list
simple and fast platform independent IPC
Hi, I wondered what IPC library might be best simplest for following task? I'm having a few python scripts all running on the same host (linux or win), which are started manually in random order. (no common parent process) Each process might be identified by an integer (1,2,3) or by a symbolic name ( 'dad' , 'mom' , 'dog' ) these scripts want to send short messages to each other ( mostly integers, max a few bytes, short string), which would be enqueued in message queues of the receiving process. example: 'dad' wants to tell 'mom': 'cook' 'dog' wants to tell 'dad' : 'feedme' 'mom' wants to tell 'dad' : 'cookyourself' the receiver dos not necesarily have to know who sent the message a message shall be dropped silently if the receiving process is not running a message shall be reliably delivered if the receiving process is up xmlrpc seems to be a little heavy for such tasks. signals don't allow to exchange data a shared memory message queue would probably a good solution, but python's Multiprocessing.Queue seems to require a common parent process thanks a lot for any ideas / suggestions N N -- http://mail.python.org/mailman/listinfo/python-list
Re: Logging oddity: handlers mandatory in every single logger?
On 2 Feb 2010, at 17:52 , Jean-Michel Pichavant wrote:
>
> Masklinn wrote:
>> Jean-Michel Pichavant wrote:
>>
>>> To add a custom level, I would proceed that way:
>>>
>>> logging.ALERT = 45
>>> logging.addLevelName(logging.ALERT, 'ALERT !!')
>>> logging.getLogger().log(logging.ALERT, 'test')
>>>
>>> Passing a string to the log method as you did is incorrect.
>>>
>>
>> I know it's currently incorrect. My point was more along the line that there
>> was *no reason* for it to be incorrect. logging already contains all the
>> tools for log('PANTS_ON_FIRE') to be allowed
>>
> The reason is that log takes an *int* as first argument that defines the
> logging level. You gave a string. So There is definitely a reason for it to
> be incorrect.
That's not a reason, that's just what currently happens. I know it doesn't
work, and I know why, I went and checked the code. But there's no fundamental
reason why you couldn't use a level *name* instead of a level code. And indeed,
in most parts of logging you can (including but not limited to the
configuration of handlers and loggers)
>>
>>> Regarding your first point, I guess it's anti pattern. One way to do it:
>>> 1/ Configure the root logger with the lowest value 0, so the root logger
>>> does not filter any level.
>>> 2/ Configure each of your logger with the correct level
>>>
>>> That way you can configure your '0' logger as you (badly :o)) named it with
>>> one level, and configure a potential '1' logger with another level. Don't
>>> bother with propagation. That way you won't need to duplicate your handlers
>>> on every logger.
>>>
>>
>> re logger 0, no need for complex name for a test case (and it allowed me to
>> create easy-to-remember 0.1 and 0.1.2 if needed)
>>
>> Re your answer, from what I understand you want the root logger to NOTSET
>> and then each child logger with its correct level? But that's not a
>> solution, each and every level will *still* require a handler explicitly
>> configured on it. That's in fact very much my issue: logging refuses that a
>> logger be handler-less in a config file, it's mandatory to configure a
>> handler any time a logger is configured.
>>
> the field handlers must be defined even if empty.
Ah, interesting, I didn't think it could be defined as empty.
Which makes the requirement to have an empty ``handler`` completely
nonsensical, doesn't it?
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python and Ruby
On Jan 28, 2:29 am, Jonathan Gardner
wrote:
> On Jan 27, 5:47 am, Simon Brunning wrote:
>
>
>
> > I think Python is a little cleaner, but I'm sure you'd find Ruby fans
> > who'd argue the complete opposite.
>
> Are you sure about that?
>
> There's a lot of line noise in Ruby. How are you supposed to pronounce
> "@@"? What about "{|..| ... }"?
>
> There's a lot of "magic" in Ruby as well. For instance, function calls
> are made without parentheses. Blocks can only appear as the first
> argument. There's a lot more, if you put your mind to it.
>
> Indentation is also optional in Ruby. You can quickly fool a newbie by
> not indenting your code properly, which is impossible in Python.
>
> Python is much, much cleaner. I don't know how anyone can honestly say
> Ruby is cleaner than Python.
I will. I developed on both (Python was first) and I think that ruby I
very clean and maybe cleaner than Python. Also I don't know any
situation where you need to pronounce your code symbol by symbol. You
might need to pronounce some semantics.
And you're wrong with blocks.
About indent your right. It helps newbies indent code becouse they
must to. But most of professional developers started with Pascal and
then C and they all indent well :) it is about culture and it is what
about teacher should say.
--
http://mail.python.org/mailman/listinfo/python-list
Re: simple and fast platform independent IPC
En Wed, 03 Feb 2010 05:32:58 -0300, News123 escribió: I'm having a few python scripts all running on the same host (linux or win), which are started manually in random order. (no common parent process) Each process might be identified by an integer (1,2,3) or by a symbolic name ( 'dad' , 'mom' , 'dog' ) these scripts want to send short messages to each other ( mostly integers, max a few bytes, short string), which would be enqueued in message queues of the receiving process. example: 'dad' wants to tell 'mom': 'cook' 'dog' wants to tell 'dad' : 'feedme' 'mom' wants to tell 'dad' : 'cookyourself' Try using a named pipe between each pair of processes (os.mkfifo + open on Linux, open(r"\\.\pipe\desired_name", ...) on Windows) -- Gabriel Genellina -- http://mail.python.org/mailman/listinfo/python-list
Re: simple and fast platform independent IPC
On Feb 3, 8:32 am, News123 wrote: > Hi, > > I wondered what IPC library might be best simplest for following task? > > I'm having a few python scripts all running on the same host (linux or > win), which are started manually in random order. (no common parent process) > Each process might be identified by an integer (1,2,3) or by a symbolic > name ( 'dad' , 'mom' , 'dog' ) > > these scripts want to send short messages to each other ( mostly > integers, max a few bytes, short string), which would be enqueued in > message queues of the receiving process. > > example: > > 'dad' wants to tell 'mom': 'cook' > 'dog' wants to tell 'dad' : 'feedme' > 'mom' wants to tell 'dad' : 'cookyourself' > > the receiver dos not necesarily have to know who sent the message > > a message shall be dropped silently if the receiving process is not running > > a message shall be reliably delivered if the receiving process is up > > xmlrpc seems to be a little heavy for such tasks. > > signals don't allow to exchange data > > a shared memory message queue would probably a good solution, but > python's Multiprocessing.Queue seems to require a common parent process > > thanks a lot for any ideas / suggestions > > N > > N Gabriel's suggestion is very good; if you need something which is a little more like RPC but still quite lightweight, consider Pyro (http://pyro.sourceforge.net/) Regards, Vinay Sajip -- http://mail.python.org/mailman/listinfo/python-list
pyfltk ducumentation question
I have just installed pyfltk version 1.1.4 on my xubuntu 9.10 system, it's working OK and a fairly trivial little program I have written is able to pop up a GUI window. However I'm now a bit stuck as the documentation seems a little sparse. For example I'm using FL_Multiline_Output and can't find enough detail to enable me to use its methods. I start from:- http://pyfltk.sourceforge.net/docs/CH3_Common.html This tells me that there is a FL_Multiline_Output widget and that it has a value() method, this is what I have used to display some text in my little application. When I click on the FL_Multiline_Output link in the above page it takes me to:- http://pyfltk.sourceforge.net/docs/fltk.html#Fl_Multiline_Output which lists all the methods and other bits and pieces belonging to Fl_Multiline_Output but as far as I can see that's it, there is no further information. The methods are links but they only link to themselves, when you click on them the browser moves the method to the top of the display window. Am I missing something obvious or do I need the FLTK documentation to give me the detail I need? -- Chris Green -- http://mail.python.org/mailman/listinfo/python-list
Re: simple and fast platform independent IPC
On 3 feb, 09:34, Vinay Sajip wrote: > On Feb 3, 8:32 am, News123 wrote: > > > > > Hi, > > > I wondered what IPC library might be best simplest for following task? > > > I'm having a few python scripts all running on the same host (linux or > > win), which are started manually in random order. (no common parent process) > > Each process might be identified by an integer (1,2,3) or by a symbolic > > name ( 'dad' , 'mom' , 'dog' ) > > > these scripts want to send short messages to each other ( mostly > > integers, max a few bytes, short string), which would be enqueued in > > message queues of the receiving process. > > > example: > > > 'dad' wants to tell 'mom': 'cook' > > 'dog' wants to tell 'dad' : 'feedme' > > 'mom' wants to tell 'dad' : 'cookyourself' > > > the receiver dos not necesarily have to know who sent the message > > > a message shall be dropped silently if the receiving process is not running > > > a message shall be reliably delivered if the receiving process is up > > > xmlrpc seems to be a little heavy for such tasks. > > > signals don't allow to exchange data > > > a shared memory message queue would probably a good solution, but > > python's Multiprocessing.Queue seems to require a common parent process > > > thanks a lot for any ideas / suggestions > > > N > > > N > > Gabriel's suggestion is very good; if you need something which is a > little more like RPC but still quite lightweight, consider Pyro > (http://pyro.sourceforge.net/) > > Regards, > > Vinay Sajip I've read that Pyro is not safe. Anyway, you have in mind that respect to speed: shared memory > named pipes > Unix domain socket > TCP socket I don't sure about if the message queues would be faster that Unix domain sockets Another thing. Using shared memory would be as to use a single thread but using message queues would be as multiple-threading. -- http://mail.python.org/mailman/listinfo/python-list
Re: simple and fast platform independent IPC
Hi Gabriel, I'll look at it. I wasn't aware about named pipes for windows. bye N Gabriel Genellina wrote: > En Wed, 03 Feb 2010 05:32:58 -0300, News123 escribió: > >> I'm having a few python scripts all running on the same host (linux or >> win), which are started manually in random order. (no common parent >> process) >> Each process might be identified by an integer (1,2,3) or by a symbolic >> name ( 'dad' , 'mom' , 'dog' ) >> >> these scripts want to send short messages to each other ( mostly >> integers, max a few bytes, short string), which would be enqueued in >> message queues of the receiving process. >> >> example: >> >> 'dad' wants to tell 'mom': 'cook' >> 'dog' wants to tell 'dad' : 'feedme' >> 'mom' wants to tell 'dad' : 'cookyourself' > > Try using a named pipe between each pair of processes (os.mkfifo + open > on Linux, open(r"\\.\pipe\desired_name", ...) on Windows) > -- http://mail.python.org/mailman/listinfo/python-list
Re: Logging oddity: handlers mandatory in every single logger?
The reason is that log takes an *int* as first argument that defines the logging level. You gave a string. So There is definitely a reason for it to be incorrect. That's not a reason, that's just what currently happens. I know it doesn't work, and I know why, I went and checked the code. But there's no fundamental reason why you couldn't use a level *name* instead of a level code. And indeed, in most parts of logging you can (including but not limited to the configuration of handlers and loggers) You don't neeed to check the code for that ! It is written in the documentation. The logging module designer choose to ask for a level, not a level name, possibly because 2 different levels can have the same name. the field handlers must be defined even if empty. Ah, interesting, I didn't think it could be defined as empty. Which makes the requirement to have an empty ``handler`` completely nonsensical, doesn't it? 'completeley nonsensical' is overstating. It make sense to state that your handler list is empty, when it is empty. Having no field at all could possibly mean the same, but it's often better that have one consisten way to interface with a module. JM -- http://mail.python.org/mailman/listinfo/python-list
Re: simple and fast platform independent IPC
[News123] I wondered what IPC library might be best simplest for following task? ... xmlrpc seems to be a little heavy for such tasks. signals don't allow to exchange data a shared memory message queue would probably a good solution, but python's Multiprocessing.Queue seems to require a common parent process [Vinay Sajip] Gabriel's suggestion is very good; if you need something which is a little more like RPC but still quite lightweight, consider Pyro (http://pyro.sourceforge.net/) [pelok...@gmail.com] I've read that Pyro is not safe. That's a fairly broad thing to say. I've read lots of things. What does "is not safe" mean, in any case? I assume you've got a valid concern in mind which is worth passing on to a would-be user, but what exactly is it? FWIW I've used Pyro on and off over the years without any problems. Certainly my computer's never blown up as a result of using it. Obviously Pyro is Python-only so interaction with non-Python code would be problematic. But the OP only mentions Python scripts so hopefully that wouldn't be an issue... Anyway, you have in mind that respect to speed: shared memory> named pipes> Unix domain socket> TCP socket True, but the OP didn't mention speed; rather simplicity. Not saying it isn't a consideration but premature optimisation and all that... Another thing. Using shared memory would be as to use a single thread but using message queues would be as multiple-threading. And therefore...? I think you need to make your points more clearly. TJG -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP 3147 - new .pyc format
>>> I like seeing them in the same place as the source file, because when I >>> start developing a module, I often end up renaming it multiple times >>> before it settles on a final name. When I rename or move it, I delete >>> the .pyc file, and that ensures that if I miss changing an import, and >>> try to import the old name, it will fail. >>> >>> By hiding the .pyc file elsewhere, it is easy to miss deleting one, and >>> then the import won't fail, it will succeed, but use the old, obsolete >>> byte code. >> >> >> Okay, I see your point but I think your argument about importing shows >> that python is doing something suboptimal because I have to worry about >> .pyc files. Ideally, I only would need to worry about python source >> files. > > That's no different from any language that is compiled: you have to worry > about keeping the compiled code (byte code or machine language) in sync > with the source code. True. > Python does most of that for you: it automatically recompiles the source > whenever the source code's last modified date stamp is newer than that of > the byte code. So to a first approximation you can forget all about > the .pyc files and just care about the source. True, but the .pyc file is lying around and I always have to do 'ls -al | grep -v pyc' in my python source directory. > But that's only a first approximation. You might care about the .pyc > files if: > > (1) you want to distribute your application in a non-human readable > format; Sure, I do care about pyc files, of course, I just would prefer to have them at a separate location. > (2) if you care about clutter in your file system; You mean having an extra directory structure for the pyc files? This I think would be better than having the pyc files in the source directory, but we are getting into 'gut feelings' territory :) > (3) if you suspect a bug in the compiler; If the pyc files are somewhere else you can still inspect them if you want. > (4) if you are working with byte-code hacks; Again, just because they are somewhere else doesn't mean you can't get to them. > (5) if the clock on your PC is wonky; Same as above. > (6) if you leave random .pyc files floating around earlier in the > PYTHONPATH than your source files; > > etc. > > > > >> There is now a chance to 'fix' (quotation marks because maybe >> there is nothing to fix, according to some) this issue and make all pyc >> files go away and having python magically doing the right thing. > > Famous last words... > > The only ways I can see to have Python magically do the right thing in > all cases would be: > > (1) Forget about byte-code compiling, and just treat Python as a purely > interpreted language. If you think Python is slow now... I'm not advocating this option, naturally. > (2) Compile as we do now, but only keep the byte code in memory. This > would avoid all worries about scattered .pyc files, but would slow Python > down significantly *and* reduce functionality (e.g. losing the ability to > distribute non-source files). I'm not advocating this option either. > Neither of these are seriously an option. Agreed. >> A >> central pyc repository would be something I was thinking about, but I >> admit it's a half baked or not even that, probably quarter baked idea. > > A central .pyc repository doesn't eliminate the issues developers may > have with byte code files, it just puts them somewhere else, out of > sight, where they are more likely to bite. Here is an example: shared object files. If your code needs them, you can use them easily, you can access them easily if you want to, but they are not in the directory where you keep your C files. They are somewhere in /usr/lib for example, where they are conveniently collected, you can inspect them, look at them, distribute them, do basically whatever you want, but they are out of the way, and 99% of the time while you develop your code, you don't need them. In the 1% of the case you can easily get at them in the centralized location, /usr/lib in our example. Of course the relationship between C source files and shared objects is not parallel to the relationship to python source files and the created pyc files, please don't nitpick on this point. The analogy is in the sense that your project inevitable needs for whatever reason some binary files which are rarely needed at hand, only the linker/compiler/interpreter/etc needs to know where they are. These files can be stored separately, but at a location where one can inspect them if needed (which rarely happens). Cheers, Daniel -- Psss, psss, put it down! - http://www.cafepress.com/putitdown -- http://mail.python.org/mailman/listinfo/python-list
Re: simple and fast platform independent IPC
On 03.02.2010 09:32, News123 wrote: Hi, I wondered what IPC library might be best simplest for following task? Consider using Thrift (http://incubator.apache.org/thrift/). It is multiplatform multilanguage RPC and IPC solution. I implemented it in couple of my projects and it works seamlessly. -- www.vikendi.net -/- www.supergrupa.com -- http://mail.python.org/mailman/listinfo/python-list
Dreaming of new generation IDE
Hello, I am sitting here for quite some time, but usually keep silent ;-) I use Python since 2003 both "professionally" and for my hobby projects and love it a much. I notice however, that "maintaining" existing/older python code is may be not so enjoyable task. It may be even harder than supporting old code written in some type of "static" languages (like Java or C++). Surely "dynamic" nature of python comes with price. Finally I develop a feeling that strong instrumentation / tools can bring us the best of two worlds. That I am dreaming on is an absolute new type/class of IDE suitable for Python and potentially for other dynamic-type languages. Instead of current text-oriented IDEs, it should be a database-centric and resemble current CAD systems instead of being just "fancy text editor". Source text should be an output product of that CAD and not a "source material" itself. Well. I understand that it is a very ambitious and experimental stuff. Great efforts and motivation needed even to get something "runnable". So I am looking for someone to get in kind of "virtual partnership". If someone interesting it that soft of stuff, I would like to talk and discuss this system. Vladimir Ignatov -- http://mail.python.org/mailman/listinfo/python-list
Re: simple and fast platform independent IPC
On 3 feb, 10:54, Tim Golden wrote: > [News123] > > >>> I wondered what IPC library might be best simplest for following task? > > ... > > >>> xmlrpc seems to be a little heavy for such tasks. > > >>> signals don't allow to exchange data > > >>> a shared memory message queue would probably a good solution, but > >>> python's Multiprocessing.Queue seems to require a common parent process > > [Vinay Sajip] > > >> Gabriel's suggestion is very good; if you need something which is a > >> little more like RPC but still quite lightweight, consider Pyro > >> (http://pyro.sourceforge.net/) > > [pelok...@gmail.com] > > > I've read that Pyro is not safe. > > That's a fairly broad thing to say. I've read lots > of things. What does "is not safe" mean, in any case? > I assume you've got a valid concern in mind which is > worth passing on to a would-be user, but what exactly > is it? FWIW I've used Pyro on and off over the years > without any problems. Certainly my computer's never > blown up as a result of using it. >From its own page: "Pyro has never been truly designed to provide a secure communication mechanism, nor has it had a security review or -test by a security expert." http://pyro.sourceforge.net/features.html > Obviously Pyro is Python-only so interaction with non-Python > code would be problematic. But the OP only mentions Python > scripts so hopefully that wouldn't be an issue... -- http://mail.python.org/mailman/listinfo/python-list
Re: Logging oddity: handlers mandatory in every single logger?
On 3 Feb 2010, at 11:50 , Jean-Michel Pichavant wrote: > > >>> The reason is that log takes an *int* as first argument that defines the >>> logging level. You gave a string. So There is definitely a reason for it to >>> be incorrect. >>> >> That's not a reason, that's just what currently happens. I know it doesn't >> work, and I know why, I went and checked the code. But there's no >> fundamental reason why you couldn't use a level *name* instead of a level >> code. And indeed, in most parts of logging you can (including but not >> limited to the configuration of handlers and loggers) >> > You don't neeed to check the code for that ! It is written in the > documentation. The logging module designer choose to ask for a level, not a > level name, possibly because 2 different levels can have the same name. > Nope, 2 different levels cannot have the same name: levels are currently stored in a dict of string:level and level:string, so you can't have 2 names for the same level, and you can't have 2 levels with the same name either. >>> >>> the field handlers must be defined even if empty. >>> >> Ah, interesting, I didn't think it could be defined as empty. >> >> Which makes the requirement to have an empty ``handler`` completely >> nonsensical, doesn't it? > 'completeley nonsensical' is overstating. It make sense to state that your > handler list is empty, when it is empty. Programmatically, that's implied in the fact that you aren't specifying it. Why wouldn't it be in the config file? Why the asymetry here? -- http://mail.python.org/mailman/listinfo/python-list
Re: python admin abuse complaint
Xah Lee writes: > (12:12:30 PM) You have been kicked by dash: (No.) Oh noes, someone is harrassing poor Xah the Usenet spammer. You have been and still are a major pain in the ass to a lot of Usenet users, and still surprised that you're not making friends. I mean, what did you want to do on IRC? Copy paste line by line one of your "fine" articles, followed by a link to your site. And what the hell were you doing, asking a Python question in #python? Shouldn't that be asked the Xah way in #perl or #lisp? -- John Bokma j3b Hacking & Hiking in Mexico - http://johnbokma.com/ http://castleamber.com/ - Perl & Python Development -- http://mail.python.org/mailman/listinfo/python-list
Re: test -- please ignore
kj writes: > (my replies in a different comp.lang.python thread are getting > rejected by the server; i have no problem posting to alt.test; and > i'm trying to toubleshoot the problem further.) Thank you for this explanation. It is important to know that you've tried the less obtrusive diagnostics first. Good hunting. -- \ “To have the choice between proprietary software packages, is | `\ being able to choose your master. Freedom means not having a | _o__)master.” —Richard M. Stallman, 2007-05-16 | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
test -- please ignore
(my replies in a different comp.lang.python thread are getting rejected by the server; i have no problem posting to alt.test; and i'm trying to toubleshoot the problem further.) -- http://mail.python.org/mailman/listinfo/python-list
Re: simple and fast platform independent IPC
News123 writes: > I'm having a few python scripts all running on the same host (linux or > win), which are started manually in random order. (no common parent process) > Each process might be identified by an integer (1,2,3) or by a symbolic > name ( 'dad' , 'mom' , 'dog' ) If they are running on the same host with no untrusted local users, you can use unix-domain sockets instead of TCP sockets and then the server should be unreachable from the internet. Then you're less exposed to possible security issues with libraries like Pyro. Personally I've just used SocketServer/SimpleHTTPServer on the listening side and simplejson for serialization, but that was for low-rent, low-performance applications. If you want something faster, zeromq (www.zeromq.org) looks interesting. -- http://mail.python.org/mailman/listinfo/python-list
Re: Dreaming of new generation IDE
Vladimir Ignatov writes: > I notice however, that "maintaining" existing/older python code is may > be not so enjoyable task. It may be even harder than supporting old > code written in some type of "static" languages (like Java or C++). > Surely "dynamic" nature of python comes with price. Yes, this is a well known drawback of dynamic typing. The usual remedy is lots and lots of test automation (a full suite of unit and integration tests that you run on every build, that check the properties of basically every function in your program). > Instead of current text-oriented IDEs, it > should be a database-centric and resemble current CAD systems I've never used a current CAD system, so I can't make any sense of this. I don't see how databases would help. -- http://mail.python.org/mailman/listinfo/python-list
Re: Dreaming of new generation IDE
On Wed, 2010-02-03 at 14:10 +0300, Vladimir Ignatov wrote: > Hello, > I am sitting here for quite some time, but usually keep silent ;-) I > use Python since 2003 both "professionally" and for my hobby projects > and love it a much. > I notice however, that "maintaining" existing/older python code is may > be not so enjoyable task. It may be even harder than supporting old > code written in some type of "static" languages (like Java or C++). > Surely "dynamic" nature of python comes with price. Yes, it certainly does. Not that you'll get many Pythonistas to confess to that fact. Somehow those who brag about the readability and expressiveness of source code just cannot admit that: class.method(sting name, int count) - is *obviously* more expressive than - class.method(name, count) Oh, well. This is obvious even in the Python documentation itself where one frequently asks oneself "Uhh... so what is parameter X supposed to be... a string... a list... ?" Not knocking Python; Python is great. I maintain a rapidly growing Python code base. But the above is almost comically funny sometimes [sand.insert_head(pythonista)]. > Finally I develop a feeling that strong instrumentation / tools can > bring us the best of two worlds. That I am dreaming on is an absolute > new type/class of IDE suitable for Python and potentially for other > dynamic-type languages. Instead of current text-oriented IDEs, it > should be a database-centric and resemble current CAD systems instead > of being just "fancy text editor". Source text should be an output > product of that CAD and not a "source material" itself. Ugh, please NO! This has been attempted many many times in many environments - it always fails *terribly*. > Well. I understand that it is a very ambitious and experimental stuff. > Great efforts and motivation needed even to get something "runnable". > So I am looking for someone to get in kind of "virtual partnership". > If someone interesting it that soft of stuff, I would like to talk and > discuss this system. -- http://mail.python.org/mailman/listinfo/python-list
Re: Dreaming of new generation IDE
Paul Rubin, 03.02.2010 14:07: >> Instead of current text-oriented IDEs, it >> should be a database-centric and resemble current CAD systems > > I've never used a current CAD system, so I can't make any sense of this. > I don't see how databases would help. Just like they help in current IDEs to index the source code. Stefan -- http://mail.python.org/mailman/listinfo/python-list
Re: Logging oddity: handlers mandatory in every single logger?
Masklinn wrote:
On 3 Feb 2010, at 11:50 , Jean-Michel Pichavant wrote:
You don't neeed to check the code for that ! It is written in the
documentation. The logging module designer choose to ask for a level, not a
level name, possibly because 2 different levels can have the same name.
Nope, 2 different levels cannot have the same name: levels are currently stored
in a dict of string:level and level:string, so you can't have 2 names for the
same level, and you can't have 2 levels with the same name either.
import logging
logging.addLevelName(5, 'test')
logging.addLevelName(6, 'test')
logging._levelNames
{0: 'NOTSET',
5: 'test',
6: 'test',
10: 'DEBUG',
20: 'INFO',
30: 'WARNING',
40: 'ERROR',
50: 'CRITICAL',
'CRITICAL': 50,
'DEBUG': 10,
'ERROR': 40,
'INFO': 20,
'NOTSET': 0,
'WARN': 30,
'WARNING': 30,
'test': 6}
now quoting the doc:
logging.addLevelName(/lvl/, /levelName/)
Associates level /lvl/ with text /levelName/ in an internal
dictionary, which is *used to map numeric levels to a textual
representation*, for example when a Formatter
formats a message. This function can also be used to define your own
levels. The only constraints are that all levels used must be
registered using this function, levels should be positive integers
and they should increase in increasing order of severity.
int -> string is the public association
string- > int is an internal hack to map easilty map Level name to their
int identifier. This is used for the config file, where you specify a
string not an int (you vrite level=DEBUG, not level=10)
Look at the builtin WARNING & WARN level, two different names for the
same level.
In any case, you have to trust the documentation and public interface
signature. Introspecting the code can be misleading. Now I better
understand your initial concern.
the field handlers must be defined even if empty.
Ah, interesting, I didn't think it could be defined as empty.
Which makes the requirement to have an empty ``handler`` completely
nonsensical, doesn't it?
'completeley nonsensical' is overstating. It make sense to state that your
handler list is empty, when it is empty.
Programmatically, that's implied in the fact that you aren't specifying it. Why
wouldn't it be in the config file? Why the asymetry here?
Note how progammatically the list of handlers is set to an empty list.
The attribute handlers is always set, so the config file field shall be :o)
In [11]: logger = logging.getLogger('test')
In [12]: logger.handlers
Out[12]: []
JM
--
http://mail.python.org/mailman/listinfo/python-list
Re: Dreaming of new generation IDE
Adam Tauno Williams, 03.02.2010 14:18: > This is obvious even in the Python documentation itself where one > frequently asks oneself "Uhh... so what is parameter X supposed to be... > a string... a list... ?" > > Not knocking Python; Python is great. I maintain a rapidly growing > Python code base. But the above is almost comically funny sometimes > [sand.insert_head(pythonista)]. So, what's "pythonista" in the above? A dummy? Stefan -- http://mail.python.org/mailman/listinfo/python-list
Re: Dreaming of new generation IDE
Adam Tauno Williams wrote: Yes, it certainly does. Not that you'll get many Pythonistas to confess to that fact. Somehow those who brag about the readability and expressiveness of source code just cannot admit that: class.method(sting name, int count) - is *obviously* more expressive than - class.method(name, count) class.method(string name, int count): """Return the cap'tain's age. name: a string giving the name of the cap'tain daughter count: an int giving the number of fingers left in the cap'tain right hand """ In python, attributes/parameters have no type (but you know that). By specifying them in the method signature, you're just duplicating the information hold in the docstring. JM -- http://mail.python.org/mailman/listinfo/python-list
Re: Dreaming of new generation IDE
> This is obvious even in the Python documentation itself where one > frequently asks oneself "Uhh... so what is parameter X supposed to be... > a string... a list... ?" Exactly. Often I don't need to know the exact type, but to figure out that "kind of type" it is. >> should be a database-centric and resemble current CAD systems instead >> of being just "fancy text editor". Source text should be an output >> product of that CAD and not a "source material" itself. > > Ugh, please NO! This has been attempted many many times in many > environments - it always fails *terribly*. Can you give some examples of such systems? (maybe just names for googling for) I don't see anything dirt in storing some additional meta-information about the code under development and using it later for all kind of benefits (easy refactoring for example). As with your example with "parameter x", some additional information can be "attached" to this paramer. Later it can be used during code-generation phase and placed as "comment" in source code or placed in popup tag in html-style presentation. Vladimir Ignatov -- http://mail.python.org/mailman/listinfo/python-list
Re: How to guard against bugs like this one?
Steve, I apologize for the snarkiness of my previous reply to you. After all, I started the thread by asking the forum for advice on how to avoid a certain kind of bugs, you were among those who gave me advice. So nothing other than thanking you for it was in order. I just let myself get carried away by my annoyance with the Python import scheme. I'm sorry about it. Even though I don't think I can put to practice all of your advice, I can still learn a good deal from it. Cheers, ~kj Steve Holden writes: >kj wrote: >> >>> First, I don't shadow built in modules. Its really not very hard to avoid. >> >> ...*if* you happen to be clairvoyant. I still don't see how the rest of us >> could have followed this fine principle in the case of numbers.py >> prior to Python 2.6. >> >Clearly the more you know about the standard library the less likely >this is to be a problem. Had you been migrqating from an earlier version > the breakage would have alerted you to look for some version-dependent >difference. -- http://mail.python.org/mailman/listinfo/python-list
Re: Dreaming of new generation IDE
On Feb 3, 12:10 pm, Vladimir Ignatov wrote: > Hello, > > I am sitting here for quite some time, but usually keep silent ;-) I > use Python since 2003 both "professionally" and for my hobby projects > and love it a much. > I notice however, that "maintaining" existing/older python code is may > be not so enjoyable task. It may be even harder than supporting old > code written in some type of "static" languages (like Java or C++). > Surely "dynamic" nature of python comes with price. > > Finally I develop a feeling that strong instrumentation / tools can > bring us the best of two worlds. That I am dreaming on is an absolute > new type/class of IDE suitable for Python and potentially for other > dynamic-type languages. Instead of current text-oriented IDEs, it > should be a database-centric and resemble current CAD systems instead > of being just "fancy text editor". Source text should be an output > product of that CAD and not a "source material" itself. > > Well. I understand that it is a very ambitious and experimental stuff. > Great efforts and motivation needed even to get something "runnable". > So I am looking for someone to get in kind of "virtual partnership". > If someone interesting it that soft of stuff, I would like to talk and > discuss this system. > > Vladimir Ignatov The maintenance thing may be true but for me that doesn't outweigh the clear benefits I get from using Python i.s.o. e.g. C++: the fact that I have much less code that is more compact and for me more directly readable is a clear advantage when doing maintance on code I didnt touch for a while. Documenting the essential parameters used with some examples and some logging helps (for me at least...). The type of IDE you are looking for is more something like Rational Rose (e.g. RRT?) type of tooling perhaps? There you "CAD" components and their statebehavior and the system generates C or C++ code. Regards, Marco -- http://mail.python.org/mailman/listinfo/python-list
Re: Dreaming of new generation IDE
Jean-Michel Pichavant writes: > class.method(string name, int count): > """Return the cap'tain's age. > >name: a string giving the name of the cap'tain daughter >count: an int giving the number of fingers left in the cap'tain > right hand > """ > > In python, attributes/parameters have no type (but you know that). By > specifying them in the method signature, you're just duplicating the > information hold in the docstring. It's not enough to just document (except as an aid to remembering) since the compiler and runtime don't enforce the documentation. You have to use static typing or write tests, to flag all the call sites if you change the signature. One nice trick with static types is if you change what the method does (even if its type signature doesn't change), you can rename the method: class.method2(string name, int count): # change 'method' to 'method2' and recompile your codebase. Every place in the code that called 'method' now gets a compile time "undefined method" error that you can examine to see if you need to update it. This is something you can't catch with unit tests because the call sites can be in distant modules. -- http://mail.python.org/mailman/listinfo/python-list
Re: Dreaming of new generation IDE
> The maintenance thing may be true but for me that doesn't outweigh the > clear benefits I get from using Python i.s.o. e.g. C++: the fact that > I have much less code that is more compact and for me more directly > readable is a clear advantage when doing maintance on code I didnt > touch for a while. Documenting the essential parameters used with some > examples and some logging helps (for me at least...). Python is very easy to write. But with code grow and time passes, things get worse. Currently I tries to reanimate one of my old freeware project and faced it again. > The type of IDE you are looking for is more something like Rational > Rose (e.g. RRT?) type of tooling perhaps? There you "CAD" components > and their statebehavior and the system generates C or C++ code. Perhaps. I newer use Rational Rose but hear about it. But I use some other Rational* products and they scare me a lot. So maybe Rose can be used for "inspiration" but not much more. Actually I don't want to put programmer in GUI-fashioned env. with a lot of buttons and switches. I think about "classic" text-like view but that actually "understands" that are you doing (typing) on. So your types goes in "datastore" first and then renders back as a text representation. Something like this. Vladimir Ignatov -- http://mail.python.org/mailman/listinfo/python-list
Re: Need help with a program
On Tue, 02 Feb 2010 15:07:05 -0800, Aahz wrote: >>If you have a problem and you think that regular expressions are the >>solution then now you have two problems. Regex is really overkill for >>the OP's problem and it certainly doesn't improve readability. > > If you're going to use a quote, it works better if you use the exact > quote and attribute it: > > 'Some people, when confronted with a problem, think "I know, I'll use > regular expressions." Now they have two problems.' --Jamie Zawinski He may have mixed that one up with a different (and more generic) saying: "If you think that X is the solution to your problem, then you don't understand X and you don't understand your problem." For most values of X. -- http://mail.python.org/mailman/listinfo/python-list
Re: Dreaming of new generation IDE
> Yes, it certainly does. Not that you'll get many Pythonistas to confess > to that fact. Somehow those who brag about the readability and > expressiveness of source code just cannot admit that: > > class.method(sting name, int count) > > - is *obviously* more expressive than - > > class.method(name, count) > > Oh, well. > > This is obvious even in the Python documentation itself where one > frequently asks oneself "Uhh... so what is parameter X supposed to be... > a string... a list... ?" > > But I thought that was the one of beauties of Python, you don't need to know if the input parameter is a list or a string. cheers, Stef -- http://mail.python.org/mailman/listinfo/python-list
Re: Dreaming of new generation IDE
On Wed, Feb 3, 2010 at 10:18 PM, Adam Tauno Williams wrote: > On Wed, 2010-02-03 at 14:10 +0300, Vladimir Ignatov wrote: >> Hello, >> I am sitting here for quite some time, but usually keep silent ;-) I >> use Python since 2003 both "professionally" and for my hobby projects >> and love it a much. >> I notice however, that "maintaining" existing/older python code is may >> be not so enjoyable task. It may be even harder than supporting old >> code written in some type of "static" languages (like Java or C++). >> Surely "dynamic" nature of python comes with price. > > Yes, it certainly does. Not that you'll get many Pythonistas to confess > to that fact. Somehow those who brag about the readability and > expressiveness of source code just cannot admit that: Static typing sounds "obviously" better only if you assume everything else being equal. But the typing system also often goes in the way when developing large codebases, when you need to refactor things, etc... So if for a *given* codebase, you get type information, it is almost certainly very helpful. But when you need to change this codebase, maybe not so much. There was a nice paper from people at Adobe which mentioned this very aspect, focusing on how to maintain a significant codebase, from prototype-kind of development to maintenance-kind of development: http://www.ecmascript.org/es4/spec/evolutionary-programming-tutorial.pdf. It strikes me as a good way to look at this tradeoff between static and dynamic typing, where the dynamic typing for some "mostly frozen" code areas has diminishing returns, David -- http://mail.python.org/mailman/listinfo/python-list
Re: Dreaming of new generation IDE
Finally I develop a feeling that strong instrumentation / tools can > bring us the best of two worlds. That I am dreaming on is an absolute > new type/class of IDE suitable for Python and potentially for other > dynamic-type languages. Instead of current text-oriented IDEs, it > should be a database-centric I don't see what the advantage of the use of a database is in a fairly linear hierarchical structure like python objects and modules. and resemble current CAD systems instead > of being just "fancy text editor". Source text should be an output > product of that CAD and not a "source material" itself. > You mean something like LabView ? cheers, Stef (btw, my dreams ends up in the same needs) -- http://mail.python.org/mailman/listinfo/python-list
Re: Dreaming of new generation IDE
On Wed, 2010-02-03 at 16:23 +0100, Stef Mientki wrote: > Yes, it certainly does. Not that you'll get many Pythonistas > to confess > to that fact. Somehow those who brag about the readability > and > expressiveness of source code just cannot admit that: > class.method(sting name, int count) > - is *obviously* more expressive than - > class.method(name, count) > Oh, well. > This is obvious even in the Python documentation itself where > one > frequently asks oneself "Uhh... so what is parameter X > supposed to be... > a string... a list... ?" > But I thought that was the one of beauties of Python, you don't need > to know if the input parameter is a list or a string. You don't need to know; unless of course you want the expected result. -- http://mail.python.org/mailman/listinfo/python-list
Re: Dreaming of new generation IDE
> I don't see what the advantage of the use of a database is in a fairly > linear hierarchical structure like python objects and modules. Imagine simple operation like "method renaming" in a simple "dumb" environment like text editor + grep. Now imagine how simple it can be if system "knows" all your identifiers and just regenerates relevant portions of text from internal database-alike representation. > You mean something like LabView ? No, I don't think so. I never use LabView but imagine it something very "graphical-oriented". No, I think about more "classic" text view. But back-ended with "smart" underlying system - not just obvious "text". Vladimir Ignatov -- http://mail.python.org/mailman/listinfo/python-list
Background Zones in Pylab Plot
I would like to add background zones in pylab plots. Colored sections of the background that the curves pass through. Is this possible? My google searches don't turn up anything but maybe my search terms aren't the right ones. Thanks -- http://mail.python.org/mailman/listinfo/python-list
Re: Dreaming of new generation IDE
On 03-02-2010 16:48, Vladimir Ignatov wrote: I don't see what the advantage of the use of a database is in a fairly linear hierarchical structure like python objects and modules. Imagine simple operation like "method renaming" in a simple "dumb" environment like text editor + grep. Now imagine how simple it can be if system "knows" all your identifiers and just regenerates relevant portions of text from internal database-alike representation. I think every IDE (not older than 20 years) does that already. cheers, Stef -- http://mail.python.org/mailman/listinfo/python-list
Re: converting XML to hash/dict/CustomTreeCtrl
On Wed, 03 Feb 2010 08:07:50 +1100, Astan Chee wrote:
> Sorry for being vague but here my question about converting an xml into
> a dict. I found some examples online but none gives the dict/result I
> want.
> Which is kinda wrong. I expect the dict to have the "Space usage
> summary", but it doesn't (duplicate?). What am I doing wrong here?
> I am attempting to keep the attribute value of an XML as key (if it
> doesn't have a value, then just the tag name will do) and associate it
> with the text value of that tag/attribute value as well as reflecting
> the hierarchy structure of the XML in the dict. Does this make sense?
> Anyway, the python script above is just the first step or an example for me.
The code you're using expects the XML to follow a particular format, and
yours doesn't.
You might want to start with a fairly direct translation, e.g.:
def xmldict(e):
d = {}
d['tag'] = e.tag
d.update(e.attrib)
children = map(xmldict, e)
if children:
d['children'] = children
text = e.text.strip()
if text:
d['text'] = text
return d
tree = ElementTree.parse('test.xml')
root = tree.getroot()
d = xmldict(root)
pprint.pprint(d)
then refine this as needed.
--
http://mail.python.org/mailman/listinfo/python-list
RE: Dreaming of new generation IDE
-Original Message- From: Vladimir Ignatov Sent: 03/02/2010 7:24:26 pm Subject: Re: Dreaming of new generation IDE > This is obvious even in the Python documentation itself where one > frequently asks oneself "Uhh... so what is parameter X supposed to be... > a string... a list... ?" Exactly. Often I don't need to know the exact type, but to figure out that "kind of type" it is. >> should be a database-centric and resemble current CAD systems instead >> of being just "fancy text editor". Source text should be an output >> product of that CAD and not a "source material" itself. > > Ugh, please NO! This has been attempted many many times in many > environments - it always fails *terribly*. Can you give some examples of such systems? (maybe just names for googling for) I don't see anything dirt in storing some additional meta-information about the code under development and using it later for all kind of benefits (easy refactoring for example). As with your example with "parameter x", some additional information can be "attached" to this paramer. Later it can be used during code-generation phase and placed as "comment" in source code or placed in popup tag in html-style presentation. BD> probably close to Java annotations perhaps? And as for the CAD approach, would a UML reverse engg tool help ? If yes, perhaps you could give BOUML a shot. Regards, Banibrata -- http://mail.python.org/mailman/listinfo/python-list
Re: How to guard against bugs like this one?
In kj writes: >Steve, I apologize for the snarkiness of my previous reply to you. >After all, I started the thread by asking the forum for advice on >how to avoid a certain kind of bugs, you were among those who gave >me advice. So nothing other than thanking you for it was in order. >I just let myself get carried away by my annoyance with the Python >import scheme. I'm sorry about it. Even though I don't think I >can put to practice all of your advice, I can still learn a good >deal from it. Boy, that was dumb of me. The above apology was meant for Stephen Hansen, not Steve Holden. I guess this is now a meta-apology... (Sheesh.) ~kj -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: GMPY 1.11 released
On Feb 2, 10:03 pm, Mensanator wrote: > On Feb 2, 12:45 am, casevh wrote: > > > > > Everyone, > > > I'm pleased to annouce the final release of GMPY 1.11. > > GMPY is a wrapper for the MPIR or GMP multiple-precision > > arithmetic library. GMPY 1.11 is available for download from: > > >http://code.google.com/p/gmpy/ > > > In addition to support for Python 3.x, there are several new > > features in this release: > > > - Even faster conversion to/from Python longs. > > - Performance improvements by reducing function overhead. > > - Performance improvements by improved caching. > > - Support for cdivmod, fdivmod, and tdivmod. > > - Unicode strings are accepted on Python 2.x and 3.x. > > - Fixed regression in GMPY 1.10 where True/False were no > > longer recognized. > > > Changes since 1.11rc1: > > - Recognizes GMP 5. > > - Bugs fixed in Windows binaries (MPIR 1.3.0rc3 -> 1.3.1). > > > Comments on provided binaries > > > The 32-bit Windows installers were compiled with MinGW32 using MPIR > > 1.3.1 and will automatically recognize the CPU type and use code > > optimized for the CPU at runtime. The 64-bit Windows installers were > > compiled Microsoft's SDK compilers using MPRI 1.3.1. Detailed > > instructions are included if you want to compile your own binary. > > > Please report any issues! > > My previous replies didn't show up. Something to do the .announce > group? I'll trim that and try again. Sorry if they show up eventually. > > Two issues: > > 1] why does both gmpy 1.11 and gmpy 1.11rc1 both reply > > >>> gmpy.version() > > '1.11' > > Aren't these different versions? How are we supposed to tell them > apart? Check the name of source tarball? gmpy._cvsid() will return the internal source code revision number. The changes made in each revision number are listed at http://code.google.com/p/gmpy/source/list. I know some applications check gmpy.version(). I don't know if they'll work if the format of the string changes. > > 2] Is it true that the only changes since 1.11rc1 are not > applicable to me since > > - I'm not using Windows > - whether it recognizes GMP 5 is moot as GMP 5 cannot be > compiled on a Mac (according to GMP site) Yes. The only change for GMP 5 was to recognize the new version number when running the tests. > > Is it possible GMP's problems with getting GMP 5 to compile > are the same ones I had with 3.1 on Snow Leopard? (They bemoan > not having a set of every Mac system.) Think it would behoove > me to try it? According to comments on GMP's mailing list, the latest snapshot should work. ftp://ftp.gmplib.org/pub/snapshot/ > > > > > casevh > > -- http://mail.python.org/mailman/listinfo/python-list
Re: Wrap a function
In article , Dennis Lee Bieber wrote: > > I shall blaspheme, and suggest that maybe the language you want to >use is REXX (ooREXX or Regina). > > By default, ANY statement that can not be confused for a REXX >language statement is sent to the currently defined command handler >(Which on most OSs is equivalent to Python's os.system() call; the late >Amiga, and IBM's mainframe OS had features that support defining other >applications as command handlers). How is that different from bash scripting? -- Aahz (a...@pythoncraft.com) <*> http://www.pythoncraft.com/ import antigravity -- http://mail.python.org/mailman/listinfo/python-list
Re: test -- please ignore
In article , kj wrote: > >I figured out the immediate reason for the failure: when replying >to *certain posts*, my newsreader omits the Newsgroups header from >the response. Why it does this is still a mystery to me, but at >least now I know what to look out for. Then again, I use the >"venerable" (i.e. decrepit) nn as newsreader, so this discovery >probably won't help many of those reading this... Perhaps it's similar to problems in the even-more-venerable trn3.6 that come from excessively long References: headers? -- Aahz (a...@pythoncraft.com) <*> http://www.pythoncraft.com/ import antigravity -- http://mail.python.org/mailman/listinfo/python-list
Re: How to guard against bugs like this one?
On Tue, 02 Feb 2010 10:38:53 -0800, Carl Banks wrote: >> I don't know if that's necessary. Only supporting the "foo.h" case would >> work fine if Python behaved like gcc, i.e. if the "current directory" >> referred to the directory contain the file performing the import rather >> than in the process' CWD. >> >> As it stands, imports are dynamically scoped, when they should be >> lexically scoped. > > Mostly incorrect. The CWD is in sys.path only for interactive > sessions, and when started with -c switch. When running scripts, the > directory where the script is located is used instead, not the > process's working directory. Okay, so s/CWD/directory containing __main__ script/, but the general argument still holds. > So, no, it isn't anything like dynamic scoping. That's what it looks like to me. The way that an import name is resolved depends upon the run-time context in which the import occurs. >> The only situation where the process' CWD should be used is for an import >> statement in a non-file source (i.e. stdin or the argument to the -c >> switch). > > It already is that way, chief. > > I think you're misunderstanding what's wrong here; the CWD doesn't > have anything to do with it. Even if CWD isn't in the path you still > get the bad behavior kj noted. So now what? Search for imports first in the directory containing the file performing the import. This is essentially the situation with gcc; the directory containing the current file takes precedence over directories specified by -I switches. If you want to override this, you have to use the -I- switch, which makes it very unlikely to happen by accident. -- http://mail.python.org/mailman/listinfo/python-list
Re: Dreaming of new generation IDE
>> Imagine simple operation like "method renaming" in a simple "dumb" >> environment like text editor + grep. Now imagine how simple it can be >> if system "knows" all your identifiers and just regenerates relevant >> portions of text from internal database-alike representation. >> > > I think every IDE (not older than 20 years) does that already. And fix every reference to it in all files? For python? I don't think so. I even don't think this is possible at all. That if several different objects have a similar named method? How will IDE "classify" calls and renames only some of calls and not others? Vladimir Ignatov -- http://mail.python.org/mailman/listinfo/python-list
Trouble with os.system
Hi there, I'm having some trouble with os.system on Fedora 12. I have a bunch of .tex files in tmp/ and I want to compile them. In my shell, the following commands work perfectly : 'for file in tmp/ *.tex; do pdflatex "$file"; done'. But if I use the same command using os.system(), it will compile correctly every file except the last one, for which it raises an error (I get a prompt, as if I did a syntax error in tex document). I suspected some kind of escaping issue, but it won't even work with files such as : foo.txt, bar.txt. Any idea ? Thanks, Cpa -- http://mail.python.org/mailman/listinfo/python-list
Re: Trouble with os.system
Can you post your code? On Wed, Feb 3, 2010 at 12:47 PM, Cpa wrote: > Hi there, > > I'm having some trouble with os.system on Fedora 12. > I have a bunch of .tex files in tmp/ and I want to compile them. > In my shell, the following commands work perfectly : 'for file in tmp/ > *.tex; do pdflatex "$file"; done'. > > But if I use the same command using os.system(), it will compile > correctly every file except the last one, for which it raises an error > (I get a prompt, as if I did a syntax error in tex document). > > I suspected some kind of escaping issue, but it won't even work with > files such as : foo.txt, bar.txt. > > Any idea ? > Thanks, > Cpa > -- > http://mail.python.org/mailman/listinfo/python-list > -- Gerald Britton -- http://mail.python.org/mailman/listinfo/python-list
Re: Trouble with os.system
Sure.
import sys,re,os
files2create = sys.argv[1:]
os.system('mkdir tmp')
# Some code to create the .tex
# Compile tex files
os.system('for file in tmp/*; do pdflatex "$file"; done')
Pretty simple, alas.
--
Cpa
On 3 fév, 18:54, Gerald Britton wrote:
> Can you post your code?
>
>
>
> On Wed, Feb 3, 2010 at 12:47 PM, Cpa wrote:
> > Hi there,
>
> > I'm having some trouble with os.system on Fedora 12.
> > I have a bunch of .tex files in tmp/ and I want to compile them.
> > In my shell, the following commands work perfectly : 'for file in tmp/
> > *.tex; do pdflatex "$file"; done'.
>
> > But if I use the same command using os.system(), it will compile
> > correctly every file except the last one, for which it raises an error
> > (I get a prompt, as if I did a syntax error in tex document).
>
> > I suspected some kind of escaping issue, but it won't even work with
> > files such as : foo.txt, bar.txt.
>
> > Any idea ?
> > Thanks,
> > Cpa
> > --
> >http://mail.python.org/mailman/listinfo/python-list
>
> --
> Gerald Britton
--
http://mail.python.org/mailman/listinfo/python-list
Passing parameters in URL
I have a web-page where each row in a grid has edit/delete buttons to enable the user to maintain a selected record on another page. The buttons are in the form of a link with href='/item_edit?id=123', but this string appears in the URL and gives clues as to how to bypass the correct sequence of events, and could be risky if they entered the URL directly (especially when it comes to deleting records). Is there another way of passing a record-id to a method a) without it appearing in the URL? b) without the user being able to fathom-out how to attach which id to which URL? As each link contains row-id, I guess there is nothing to stop someone from getting the id from the page source-code. Is it safe to use the above href method if I test for authorised credentials (user/password stored as session variables, perhaps?) before performing the edit/delete action? I am currently using CherryPy 3.2, but I guess the theory could apply to any HTTP framework or web app.. Any help would be appreciated. Alan Harris-Reid -- http://mail.python.org/mailman/listinfo/python-list
Re: Trouble with os.system
It kinda worked for me but I had to change it a little:
os.system('for file in /tmp/*.tex; do pdflatex "$file"; done')
Maybe you're picking up other files in /tmp that are not .tex files?
On Wed, Feb 3, 2010 at 12:58 PM, Cpa wrote:
> Sure.
>
> import sys,re,os
> files2create = sys.argv[1:]
> os.system('mkdir tmp')
>
> # Some code to create the .tex
>
> # Compile tex files
> os.system('for file in tmp/*; do pdflatex "$file"; done')
>
> Pretty simple, alas.
>
> --
> Cpa
>
>
> On 3 fév, 18:54, Gerald Britton wrote:
>> Can you post your code?
>>
>>
>>
>> On Wed, Feb 3, 2010 at 12:47 PM, Cpa wrote:
>> > Hi there,
>>
>> > I'm having some trouble with os.system on Fedora 12.
>> > I have a bunch of .tex files in tmp/ and I want to compile them.
>> > In my shell, the following commands work perfectly : 'for file in tmp/
>> > *.tex; do pdflatex "$file"; done'.
>>
>> > But if I use the same command using os.system(), it will compile
>> > correctly every file except the last one, for which it raises an error
>> > (I get a prompt, as if I did a syntax error in tex document).
>>
>> > I suspected some kind of escaping issue, but it won't even work with
>> > files such as : foo.txt, bar.txt.
>>
>> > Any idea ?
>> > Thanks,
>> > Cpa
>> > --
>> >http://mail.python.org/mailman/listinfo/python-list
>>
>> --
>> Gerald Britton
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>
--
Gerald Britton
--
http://mail.python.org/mailman/listinfo/python-list
Re: Dreaming of new generation IDE
On Feb 3, 3:10 am, Vladimir Ignatov wrote: > Finally I develop a feeling that strong instrumentation / tools can > bring us the best of two worlds. That I am dreaming on is an absolute > new type/class of IDE suitable for Python and potentially for other > dynamic-type languages. Instead of current text-oriented IDEs, it > should be a database-centric and resemble current CAD systems instead > of being just "fancy text editor". Source text should be an output > product of that CAD and not a "source material" itself. That's fine so long as I can also treat the source as source, at need. You may have just reinvented Smalltalk's Squeak editor (reputedly the testbed for all of modern GUIs...). Current editors suck because they can't see into the code and browse it - unless it's so statically typed it's painful. That's why I wrote this: http://www.oreillynet.com/onlamp/blog/2008/05/dynamic_languages_vs_editors.html -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: GMPY 1.11 released
On Feb 3, 10:37 am, casevh wrote: > On Feb 2, 10:03 pm, Mensanator wrote: > > > > > > > On Feb 2, 12:45 am, casevh wrote: > > > > Everyone, > > > > I'm pleased to annouce the final release of GMPY 1.11. > > > GMPY is a wrapper for the MPIR or GMP multiple-precision > > > arithmetic library. GMPY 1.11 is available for download from: > > > >http://code.google.com/p/gmpy/ > > > > In addition to support for Python 3.x, there are several new > > > features in this release: > > > > - Even faster conversion to/from Python longs. > > > - Performance improvements by reducing function overhead. > > > - Performance improvements by improved caching. > > > - Support for cdivmod, fdivmod, and tdivmod. > > > - Unicode strings are accepted on Python 2.x and 3.x. > > > - Fixed regression in GMPY 1.10 where True/False were no > > > longer recognized. > > > > Changes since 1.11rc1: > > > - Recognizes GMP 5. > > > - Bugs fixed in Windows binaries (MPIR 1.3.0rc3 -> 1.3.1). > > > > Comments on provided binaries > > > > The 32-bit Windows installers were compiled with MinGW32 using MPIR > > > 1.3.1 and will automatically recognize the CPU type and use code > > > optimized for the CPU at runtime. The 64-bit Windows installers were > > > compiled Microsoft's SDK compilers using MPRI 1.3.1. Detailed > > > instructions are included if you want to compile your own binary. > > > > Please report any issues! > > > My previous replies didn't show up. Something to do the .announce > > group? I'll trim that and try again. Sorry if they show up eventually. > > > Two issues: > > > 1] why does both gmpy 1.11 and gmpy 1.11rc1 both reply > > > >>> gmpy.version() > > > '1.11' > > > Aren't these different versions? How are we supposed to tell them > > apart? > > Check the name of source tarball? > > gmpy._cvsid() will return the internal source code revision number. > The changes made in each revision number are listed > athttp://code.google.com/p/gmpy/source/list. So, '$Id: gmpy.c 237 2010-01-10 03:46:37Z casevh $' would be Revision 237 on that source list? > > I know some applications check gmpy.version(). I don't know if they'll > work if the format of the string changes. Then gmpy.version() isn't really intended to be a version per se, it's just a level of compatibility for those programs that care? > > > > > 2] Is it true that the only changes since 1.11rc1 are not > > applicable to me since > > > - I'm not using Windows > > - whether it recognizes GMP 5 is moot as GMP 5 cannot be > > compiled on a Mac (according to GMP site) > > Yes. The only change for GMP 5 was to recognize the new version number > when running the tests. Good. > > > > > Is it possible GMP's problems with getting GMP 5 to compile > > are the same ones I had with 3.1 on Snow Leopard? (They bemoan > > not having a set of every Mac system.) Think it would behoove > > me to try it? > > According to comments on GMP's mailing list, the latest snapshot > should work.ftp://ftp.gmplib.org/pub/snapshot/ > I'll have to see if I can get it to work this weekend. I sure hope I don't muck it up after after all the trouble I had getting the previous one to work. Thanks for the links. > > > > > > > casevh -- http://mail.python.org/mailman/listinfo/python-list
Re: Dreaming of new generation IDE
Vladimir Ignatov writes: > Finally I develop a feeling that strong instrumentation / tools can > bring us the best of two worlds. That I am dreaming on is an absolute > new type/class of IDE suitable for Python and potentially for other > dynamic-type languages. Instead of current text-oriented IDEs, it > should be a database-centric and resemble current CAD systems instead > of being just "fancy text editor". Source text should be an output > product of that CAD and not a "source material" itself. Your idea is certainly not new. Moreover, I've been using such an IDE and implemented support for a (small) language in it: Programs are hierarchical compositions of formulae satisfying structural and extra-structural relationships. A program editor can use knowledge of such relationships to detect and provide immediate feedback about violations of them. The Synthesizer Generator is a tool for creating such editors from language descriptions. An editor designer specifies the desired relationships and the feedback to be given when they are violated, as well as a user interface; from the specification, the Synthesizer Generator creates a full-screen editor for manipulating programs in the language. http://portal.acm.org/citation.cfm?id=390010.808247 It might be a good start to read as much as possible on the Synthesizer Generator if you want to write such an IDE for Python. I am sure you could write such an IDE in the Synthesizer Generator, but I have no idea if it's still available. And back when I used it (at university) one had to pay for it, and most likely was closed source as well. See also: http://www.google.com/search?q=synthesizer%20generator -- John Bokma j3b Hacking & Hiking in Mexico - http://johnbokma.com/ http://castleamber.com/ - Perl & Python Development -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: GMPY 1.11 released
On Feb 3, 10:22 am, Mensanator wrote: > On Feb 3, 10:37 am, casevh wrote: > > > > > On Feb 2, 10:03 pm, Mensanator wrote: > > > > On Feb 2, 12:45 am, casevh wrote: > > > > > Everyone, > > > > > I'm pleased to annouce the final release of GMPY 1.11. > > > > GMPY is a wrapper for the MPIR or GMP multiple-precision > > > > arithmetic library. GMPY 1.11 is available for download from: > > > > >http://code.google.com/p/gmpy/ > > > > > In addition to support for Python 3.x, there are several new > > > > features in this release: > > > > > - Even faster conversion to/from Python longs. > > > > - Performance improvements by reducing function overhead. > > > > - Performance improvements by improved caching. > > > > - Support for cdivmod, fdivmod, and tdivmod. > > > > - Unicode strings are accepted on Python 2.x and 3.x. > > > > - Fixed regression in GMPY 1.10 where True/False were no > > > > longer recognized. > > > > > Changes since 1.11rc1: > > > > - Recognizes GMP 5. > > > > - Bugs fixed in Windows binaries (MPIR 1.3.0rc3 -> 1.3.1). > > > > > Comments on provided binaries > > > > > The 32-bit Windows installers were compiled with MinGW32 using MPIR > > > > 1.3.1 and will automatically recognize the CPU type and use code > > > > optimized for the CPU at runtime. The 64-bit Windows installers were > > > > compiled Microsoft's SDK compilers using MPRI 1.3.1. Detailed > > > > instructions are included if you want to compile your own binary. > > > > > Please report any issues! > > > > My previous replies didn't show up. Something to do the .announce > > > group? I'll trim that and try again. Sorry if they show up eventually. > > > > Two issues: > > > > 1] why does both gmpy 1.11 and gmpy 1.11rc1 both reply > > > > >>> gmpy.version() > > > > '1.11' > > > > Aren't these different versions? How are we supposed to tell them > > > apart? > > > Check the name of source tarball? > > > gmpy._cvsid() will return the internal source code revision number. > > The changes made in each revision number are listed > > athttp://code.google.com/p/gmpy/source/list. > > So, '$Id: gmpy.c 237 2010-01-10 03:46:37Z casevh $' would be Revision > 237 > on that source list? > Correct. > > > > I know some applications check gmpy.version(). I don't know if they'll > > work if the format of the string changes. > > Then gmpy.version() isn't really intended to be a version per se, > it's just a level of compatibility for those programs that care? Historically, gmpy really didn't have alpha/beta/rc versions and gmpy.version() just had the version "number" and didn't indicate the status. If I change it, I'd rather go to "1.1.1rc1" or "1.2.0a0" but that might break some applications. > > > > > > 2] Is it true that the only changes since 1.11rc1 are not > > > applicable to me since > > > > - I'm not using Windows > > > - whether it recognizes GMP 5 is moot as GMP 5 cannot be > > > compiled on a Mac (according to GMP site) > > > Yes. The only change for GMP 5 was to recognize the new version number > > when running the tests. > > Good. > > > > > > Is it possible GMP's problems with getting GMP 5 to compile > > > are the same ones I had with 3.1 on Snow Leopard? (They bemoan > > > not having a set of every Mac system.) Think it would behoove > > > me to try it? > > > According to comments on GMP's mailing list, the latest snapshot > > should work.ftp://ftp.gmplib.org/pub/snapshot/ > > I'll have to see if I can get it to work this weekend. I sure hope I > don't muck it up after after all the trouble I had getting the > previous > one to work. > > Thanks for the links. > > > > > > > casevh > > -- http://mail.python.org/mailman/listinfo/python-list
Re: Trouble with os.system
No, the tmp folder only contains files, and your modification still
won't work for me.
By the way I have the same error if I do:
files2compile = os.listdir('./tmp/')
for f in files2compile:
os.system('pdflatex '+f)
--
Cp
On 3 fév, 19:08, Gerald Britton wrote:
> It kinda worked for me but I had to change it a little:
>
> os.system('for file in /tmp/*.tex; do pdflatex "$file"; done')
>
> Maybe you're picking up other files in /tmp that are not .tex files?
>
>
>
> On Wed, Feb 3, 2010 at 12:58 PM, Cpa wrote:
> > Sure.
>
> > import sys,re,os
> > files2create = sys.argv[1:]
> > os.system('mkdir tmp')
>
> > # Some code to create the .tex
>
> > # Compile tex files
> > os.system('for file in tmp/*; do pdflatex "$file"; done')
>
> > Pretty simple, alas.
>
> > --
> > Cpa
>
> > On 3 fév, 18:54, Gerald Britton wrote:
> >> Can you post your code?
>
> >> On Wed, Feb 3, 2010 at 12:47 PM, Cpa wrote:
> >> > Hi there,
>
> >> > I'm having some trouble with os.system on Fedora 12.
> >> > I have a bunch of .tex files in tmp/ and I want to compile them.
> >> > In my shell, the following commands work perfectly : 'for file in tmp/
> >> > *.tex; do pdflatex "$file"; done'.
>
> >> > But if I use the same command using os.system(), it will compile
> >> > correctly every file except the last one, for which it raises an error
> >> > (I get a prompt, as if I did a syntax error in tex document).
>
> >> > I suspected some kind of escaping issue, but it won't even work with
> >> > files such as : foo.txt, bar.txt.
>
> >> > Any idea ?
> >> > Thanks,
> >> > Cpa
> >> > --
> >> >http://mail.python.org/mailman/listinfo/python-list
>
> >> --
> >> Gerald Britton
>
> > --
> >http://mail.python.org/mailman/listinfo/python-list
>
> --
> Gerald Britton
--
http://mail.python.org/mailman/listinfo/python-list
Selenium/SauceLabs OpenSpace at Pycon
For those who are interested, the Sauce Labs team, http://saucelabs.com/about/team, is hosting two free tutorial open space sessions at Pycon in Atlanta. In the short session, people bringing their laptops should be able to record a web session in their browser, convert the recorded activity to a Python script, modify the script to accept a number of inputs , and replay the script locally on their laptops. Once you've learned how to fully automate your own browser, submit the same script to the Sauce Labs cloud to run the tests in parallel across multiple browsers and operating systems, and view the results with instant video playback. The tutorials should be of interest to web developers wanting fast, cross-browser testing and it should be of general interest to anyone wanting to use Python to automate browser sessions. The tutorials are being led by Jason Huggins, the creator of Selenium (an open source web app testing tool http://seleniumhq.org/ ). Several familiar names from the Python community will also be on-hand: http://saucelabs.com/about/news/feb-03-2010 Raymond -- http://mail.python.org/mailman/listinfo/python-list
Re: Dreaming of new generation IDE
On 03-02-2010 18:21, Vladimir Ignatov wrote: Imagine simple operation like "method renaming" in a simple "dumb" environment like text editor + grep. Now imagine how simple it can be if system "knows" all your identifiers and just regenerates relevant portions of text from internal database-alike representation. I think every IDE (not older than 20 years) does that already. And fix every reference to it in all files? For python? I don't think so. I even don't think this is possible at all. with tools like inspect it certainly should be possible That if several different objects have a similar named method? How will IDE "classify" calls and renames only some of calls and not others? yep, you're right, the IDE's I use have as the beste "search / select / rename". But how often do you must/want to rename something (mature) ? cheers, Stef Vladimir Ignatov -- http://mail.python.org/mailman/listinfo/python-list
Re: Dreaming of new generation IDE
On Wed, 2010-02-03 at 10:05 -0800, Phlip wrote:
> On Feb 3, 3:10 am, Vladimir Ignatov wrote:
> > Finally I develop a feeling that strong instrumentation / tools can
> > bring us the best of two worlds. That I am dreaming on is an absolute
> > new type/class of IDE suitable for Python and potentially for other
> > dynamic-type languages. Instead of current text-oriented IDEs, it
> > should be a database-centric and resemble current CAD systems instead
> > of being just "fancy text editor". Source text should be an output
> > product of that CAD and not a "source material" itself.
> That's fine so long as I can also treat the source as source, at need.
> You may have just reinvented Smalltalk's Squeak editor (reputedly the
> testbed for all of modern GUIs...).
> Current editors suck because they can't see into the code and browse
> it - unless it's so statically typed it's painful.
? I edit Python in MonoDevelop 2.2; and I can browse my file,
classes, etc... So I don't know what you mean by "can't see into the
code". It works pretty well.
Of course it can't tell that I've set x = {an integer}, as that only
happens at runtime.
> That's why I wrote this:
> http://www.oreillynet.com/onlamp/blog/2008/05/dynamic_languages_vs_editors.html
--
http://mail.python.org/mailman/listinfo/python-list
Python-URL! - weekly Python news and links (Feb 3)
QOTW: "I think, in the spirit of the topic, they should hold it at both places at the same time." - Brian Blais, on whether the Python Concurrency Workshop, v2.0, should be in Chicago or Denver (in January!) The fastest way to consume an iterable until exhaustion: http://groups.google.com/group/comp.lang.python/t/c1ae3513a31eb63e/ When inheriting from a built-in class, it isn't obvious which of __new__ / __init__ should be overriden: http://groups.google.com/group/comp.lang.python/t/a453c65be4e0f355/ When importing a module, Python may pick the wrong one due to name clashes -- is this avoidable? http://groups.google.com/group/comp.lang.python/t/fe6430e7980e2a96/ Setting a default encoding for 'print' statements: http://groups.google.com/group/comp.lang.python/t/2fb77c8989f63f9d/ Despite its name, the iglob function (in module glob) isn't completely lazy: http://groups.google.com/group/comp.lang.python/t/d9a8617ec85e926d/ list.pop(0) has very poor performance; collections.deque works better in some cases; patch to allow lists to free elements from head (not just from tail): http://groups.google.com/group/comp.lang.python/t/9221d87f93748b3f/ How to parse ill-formed postal addresses: http://groups.google.com/group/comp.lang.python/t/76a4ab9fd7279a4e/ The future of Python 3: Adoption by Linux distros and package maintainers: http://groups.google.com/group/comp.lang.python/t/69463c4b9b1ecd8f/ Library support: http://groups.google.com/group/comp.lang.python/t/ae138cefffed0d6b/ Myths and fallacies: http://groups.google.com/group/comp.lang.python/t/8b8f4a9f999e33e8/ Why choose Python (and not Ruby) in an introductory course to programming: http://groups.google.com/group/comp.lang.python/t/dfe4f6c60032755e/ How an extension module (written in C) may perform cleaning tasks: http://groups.google.com/group/comp.lang.python/t/fbcb22b4401eaef1/ "Really, the built-in scope is just a built-in module called builtins, but you have to import builtins to query built-ins because the name builtins is not itself built-in..." (Lutz & Ascher, 'Programming Python') http://groups.google.com/group/comp.lang.python/t/dc719a4d922f2f87/ A new implementation of the GIL allows for much better performance in multicore architectures: http://groups.google.com/group/comp.lang.python/t/586ef2d3685fa7ea/ After a year of work with relative success, Unladen Swallow (a Google sponsored CPython improvement project) asks to be officially recognized: http://comments.gmane.org/gmane.comp.python.devel/109919 Everything Python-related you want is probably one or two clicks away in these pages: Python.org's Python Language Website is the traditional center of Pythonia http://www.python.org Notice especially the master FAQ http://www.python.org/doc/FAQ.html PythonWare complements the digest you're reading with the marvelous daily python url http://www.pythonware.com/daily Just beginning with Python? This page is a great place to start: http://wiki.python.org/moin/BeginnersGuide/Programmers The Python Papers aims to publish "the efforts of Python enthusiasts": http://pythonpapers.org/ The Python Magazine is a technical monthly devoted to Python: http://pythonmagazine.com Readers have recommended the "Planet" site: http://planet.python.org comp.lang.python.announce announces new Python software. Be sure to scan this newsgroup weekly. http://groups.google.com/group/comp.lang.python.announce/topics Python411 indexes "podcasts ... to help people learn Python ..." Updates appear more-than-weekly: http://www.awaretek.com/python/index.html The Python Package Index catalogues packages. http://www.python.org/pypi/ Much of Python's real work takes place on Special-Interest Group mailing lists http://www.python.org/sigs/ Python Success Stories--from air-traffic control to on-line match-making--can inspire you or decision-makers to whom you're subject with a vision of what the language makes practical. http://www.pythonology.com/success The Python Software Foundation (PSF) has replaced the Python Consortium as an independent nexus of activity. It has official responsibility for Python's development and maintenance. http://www.python.org/psf/ Among the ways you can support PSF is with a donation. http://www.python.org/psf/donations/ The Summary of Python Tracker Issues is an automatically generated report summarizing new bugs, closed ones, and patch submissions.
Re: converting XML to hash/dict/CustomTreeCtrl
Nobody wrote:
The code you're using expects the XML to follow a particular format, and
yours doesn't.
You might want to start with a fairly direct translation, e.g.:
def xmldict(e):
d = {}
d['tag'] = e.tag
d.update(e.attrib)
children = map(xmldict, e)
if children:
d['children'] = children
text = e.text.strip()
if text:
d['text'] = text
return d
tree = ElementTree.parse('test.xml')
root = tree.getroot()
d = xmldict(root)
pprint.pprint(d)
then refine this as needed.
Thanks, that is simple enough for me to understand. I think I got it now.
Thanks again
--
http://mail.python.org/mailman/listinfo/python-list
Re: Trouble with os.system
On Wed, Feb 3, 2010 at 12:58 PM, Cpa wrote:
> Sure.
>
> import sys,re,os
> files2create = sys.argv[1:]
> os.system('mkdir tmp')
>
> # Some code to create the .tex
>
> # Compile tex files
> os.system('for file in tmp/*; do pdflatex "$file"; done')
>
> Pretty simple, alas.
I think your bug is in the lines you chose not to share with us. I
bet you've forgotten to close the last file you create, so that file
has changes that haven't been flushed out to the disk yet. Make sure
you call close() on each of the files when you're done writing them.
--
Jerry
--
http://mail.python.org/mailman/listinfo/python-list
Re: Trouble with os.system
That was it ! What a stupid error...
Thank you !
--
Cp
On Wed, Feb 3, 2010 at 20:13, Jerry Hill wrote:
> On Wed, Feb 3, 2010 at 12:58 PM, Cpa wrote:
>> Sure.
>>
>> import sys,re,os
>> files2create = sys.argv[1:]
>> os.system('mkdir tmp')
>>
>> # Some code to create the .tex
>>
>> # Compile tex files
>> os.system('for file in tmp/*; do pdflatex "$file"; done')
>>
>> Pretty simple, alas.
>
> I think your bug is in the lines you chose not to share with us. I
> bet you've forgotten to close the last file you create, so that file
> has changes that haven't been flushed out to the disk yet. Make sure
> you call close() on each of the files when you're done writing them.
>
> --
> Jerry
>
--
http://mail.python.org/mailman/listinfo/python-list
Re: How to guard against bugs like this one?
Don't give it another thought. I'd much rather you cared than you didn't ... regards Steve kj wrote: > > Steve, I apologize for the snarkiness of my previous reply to you. > After all, I started the thread by asking the forum for advice on > how to avoid a certain kind of bugs, you were among those who gave > me advice. So nothing other than thanking you for it was in order. > I just let myself get carried away by my annoyance with the Python > import scheme. I'm sorry about it. Even though I don't think I > can put to practice all of your advice, I can still learn a good > deal from it. > > Cheers, > > ~kj > > > Steve Holden writes: > >> kj wrote: First, I don't shadow built in modules. Its really not very hard to avoid. >>> ...*if* you happen to be clairvoyant. I still don't see how the rest of us >>> could have followed this fine principle in the case of numbers.py >>> prior to Python 2.6. >>> >> Clearly the more you know about the standard library the less likely >> this is to be a problem. Had you been migrqating from an earlier version >> the breakage would have alerted you to look for some version-dependent >> difference. > > > -- 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/ -- http://mail.python.org/mailman/listinfo/python-list
Re: How to guard against bugs like this one?
kj wrote: > In kj writes: > > >> Steve, I apologize for the snarkiness of my previous reply to you. >> After all, I started the thread by asking the forum for advice on >> how to avoid a certain kind of bugs, you were among those who gave >> me advice. So nothing other than thanking you for it was in order. >> I just let myself get carried away by my annoyance with the Python >> import scheme. I'm sorry about it. Even though I don't think I >> can put to practice all of your advice, I can still learn a good >> deal from it. > > > Boy, that was dumb of me. The above apology was meant for Stephen > Hansen, not Steve Holden. I guess this is now a meta-apology... > (Sheesh.) > Oh, so you don't like *my* advice? ;-) 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/ -- http://mail.python.org/mailman/listinfo/python-list
The best library to create charting application
The application will display (elaborate) financial charts. Pygame? Smth else? dotnet? Regards, mk -- http://mail.python.org/mailman/listinfo/python-list
Re: Dreaming of new generation IDE
On Feb 3, 10:57 am, Adam Tauno Williams
wrote:
> > Current editors suck because they can't see into the code and browse
> > it - unless it's so statically typed it's painful.
>
> ? I edit Python in MonoDevelop 2.2; and I can browse my file,
> classes, etc... So I don't know what you mean by "can't see into the
> code". It works pretty well.
>
> Of course it can't tell that I've set x = {an integer}, as that only
> happens at runtime.
>
> > That's why I wrote this:
> > http://www.oreillynet.com/onlamp/blog/2008/05/dynamic_languages_vs_editors.html
You just said that your code browsing "works pretty well, except when
it doesn't".
Hence my blog entry. If your editor analyzed your code at runtime,
instead of just static analysis, then it could see that x = an
integer, or an object, no matter how dynamic your language.
--
Phlip
http://zeekland.zeroplayer.com/Uncle_Wiggilys_Travels/1
--
http://mail.python.org/mailman/listinfo/python-list
Re: The best library to create charting application
mk wrote: The application will display (elaborate) financial charts. Pygame? Smth else? Back in the day it was Python BLT. Are you on the Web or the Desktop? -- Phlip http://www.oreillynet.com/onlamp/blog/2008/05/dynamic_languages_vs_editors.html -- http://mail.python.org/mailman/listinfo/python-list
Re: The best library to create charting application
Phlip wrote: mk wrote: The application will display (elaborate) financial charts. Pygame? Smth else? Back in the day it was Python BLT. Are you on the Web or the Desktop? Desktop, really (there should be some nominal web interface but the main application will be desktop) Regards, mk -- http://mail.python.org/mailman/listinfo/python-list
Re: exec within function
On 2/3/2010 3:30 AM, Simon zack wrote:
hi,
I'm not sure how I can use exec within a function correctly
here is the code i'm using:
def a():
exec('b=1')
print(b)
a()
this will raise an error, but I would like to see it outputting 1
Always **copy and paste** **complete error tracebacks** when asking a
question like this. (The only exception would be if it is v e r y long,
as with hitting the recursion depth limit of 1000.)
--
http://mail.python.org/mailman/listinfo/python-list
Re: simple and fast platform independent IPC
On 2/3/2010 6:31 AM, Joan Miller wrote: I've read that Pyro is not safe. That's a fairly broad thing to say. I've read lots of things. What does "is not safe" mean, in any case? I assume you've got a valid concern in mind which is worth passing on to a would-be user, but what exactly is it? FWIW I've used Pyro on and off over the years without any problems. Certainly my computer's never blown up as a result of using it. From its own page: "Pyro has never been truly designed to provide a secure communication mechanism, nor has it had a security review or -test by a security expert." http://pyro.sourceforge.net/features.html For communication between processes on one machine, that hardly seems to be a worry. If it were, I would expect that sending encrypted strings would substantially improve things. That aside, I would wonder whether you could use a master process with a gui to haphazardly launch subprocess, so as to avail oneself of multiprocessing.Queue. Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: Dreaming of new generation IDE
Phlip writes:
> On Feb 3, 10:57 am, Adam Tauno Williams
> wrote:
>
>> > Current editors suck because they can't see into the code and browse
>> > it - unless it's so statically typed it's painful.
>>
>> ? I edit Python in MonoDevelop 2.2; and I can browse my file,
>> classes, etc... So I don't know what you mean by "can't see into the
>> code". It works pretty well.
>>
>> Of course it can't tell that I've set x = {an integer}, as that only
>> happens at runtime.
>>
>> > That's why I wrote this:
>> > http://www.oreillynet.com/onlamp/blog/2008/05/dynamic_languages_vs_editors.html
>
> You just said that your code browsing "works pretty well, except when
> it doesn't".
>
> Hence my blog entry. If your editor analyzed your code at runtime,
> instead of just static analysis, then it could see that x = an
> integer, or an object, no matter how dynamic your language.
In Perl:
my $x = ( 5, "hello", sub {}, [], {} )[ int rand 5 ];
what's $x? The answer is: it depends.
Moreover, even if your editor analyzes your code at runtime (which is
certainly not always desirable) it might not be able to find out what
the type is of x, simply because it would take too much time to find it
out. (It sounds like you want an editor that solves the halting problem
;-) )
I agree with you that to /some extent/ and editor can do analyses, if it
does compilation as well (and even runs the code, but the latter is not
always desirable). I mentioned the Synthesizer Generator before, which
can do compilation on the fly, if you implement it (or if it has been
implemented for the language you edit with it). I've written a very
simple assembler in it, ages ago, which did assembling on the fly.
--
John Bokma j3b
Hacking & Hiking in Mexico - http://johnbokma.com/
http://castleamber.com/ - Perl & Python Development
--
http://mail.python.org/mailman/listinfo/python-list
Re: The best library to create charting application
mk writes: > The application will display (elaborate) financial charts. > > Pygame? Smth else? You might want to check out the book "Beginning Python Visualisation". -- John Bokma j3b Hacking & Hiking in Mexico - http://johnbokma.com/ http://castleamber.com/ - Perl & Python Development -- http://mail.python.org/mailman/listinfo/python-list
Re: expy 0.5.2 released
On 2/3/2010 1:43 AM, Yingjie Lan wrote: Hi, expy is an expressway to extend python. in release 0.5.2, expy now supports custom exceptions, besides all built-in ones, and exception handling is made easy. for more info, see http://expy.sourceforge.net/ What Python versions does it work with? There is no indication either above or on the sf page. tjr -- http://mail.python.org/mailman/listinfo/python-list
Re: exec within function
I get no error:
>>> def a():
... exec('b=1')
... print(b)
...
>>> a()
1
>>>
On Wed, Feb 3, 2010 at 2:59 PM, Terry Reedy wrote:
> On 2/3/2010 3:30 AM, Simon zack wrote:
>>
>> hi,
>> I'm not sure how I can use exec within a function correctly
>> here is the code i'm using:
>>
>> def a():
>> exec('b=1')
>> print(b)
>>
>> a()
>>
>> this will raise an error, but I would like to see it outputting 1
>
> Always **copy and paste** **complete error tracebacks** when asking a
> question like this. (The only exception would be if it is v e r y long, as
> with hitting the recursion depth limit of 1000.)
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>
--
Gerald Britton
--
http://mail.python.org/mailman/listinfo/python-list
Re: Wrap a function
Joan Miller wrote:
On 28 ene, 21:40, Jonathan Gardner
wrote:
On Jan 28, 10:20 am, Joan Miller wrote:
I've to call to many functions with the format:
run("cmd")
were "cmd" is a command with its arguments to pass them to the shell
and run it, i.e.
run("pwd")
or
run("ls /home")
Does anybody knows any library to help me to avoid the use of the main
quotes, and brackets?
I would to use anything as:
$ ls /home => run("ls /home")
or, at least
run pwd => run("pwd")
How about this?
def pwd(): return run("pwd")
pwd()
def ls(l=False, files=()):
args = []
if l: args.insert(0, '-l')
args.append(files)
return run("ls", args)
ls(l=True, "/foo")
There would be to make a function for each system command to use so it
would be too inefficient, and follow the problem with the quotes.
The best is make a parser into a compiled language
'disagree.
Best is to have a text file outside your program, in which you define
commands and symbolic names for those commands.
Then you have a python module which reads these commands and names, and
creates functions that invoke them via the specified name.
This way you get concise syntax, don't have to type as much boilerplate,
and don't add line noise.
Mixing two languages as though they were the same language greatly
increases the complexity of the original language with little gain.
Consider PowerShell - it's almost like two different languages smushed
together, and you have to know how a command was implemented to know how
to read it.
Also, what if someday The Powers That Be (the python language core
designers) decide they need to use $ for something? I hope they won't,
but if they do, your preprocessor might make quite a mess of it.
--
http://mail.python.org/mailman/listinfo/python-list
Re: newbie qns : how do i use xmldiff?
On 2/3/2010 1:38 AM, sWrath swrath wrote: Hi , I am pretty new to python , and reading up on it. Basically I am trying to compare xml files . I know difflib have it but it does not work out as expected. I was looking at xmldiff , unfortunately I am not able to find documentation how to call it from python. Anyone knows a link or doc to it as I have been looking high and low for few days? When asking such a question, it is good to explain what sort of thing, in this case, 'xmldiff' is and where it is is from. Let us assume you meant xmldiff from http://www.logilab.org/859 It says it is a python tool that can "be used be used as a library or as a command line tool." It includes a README file. Have you read that? That says "USAGE ... Read the HELP.txt file.". Have you read *that*? HELP.txt seems to focus on command line usage. I would start with that. To use it as a library (via import ...), you might have to look at the source code as I did not see importing covered in my quick look at that file. Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: GMPY 1.11 released
On Feb 3, 12:36 pm, casevh wrote: > On Feb 3, 10:22 am, Mensanator wrote: > > > Historically, gmpy really didn't have alpha/beta/rc versions and > gmpy.version() just had the version "number" and didn't indicate the > status. If I change it, I'd rather go to "1.1.1rc1" or "1.2.0a0" but > that might break some applications. Ok. And historically, we never had Python 2.5, 2.6, 2.7 & 3.1 to support simultaneously with Windows Xp, Vista and 7 along with Mac OSX 10.4, 10.5,& 10.6 as well as whatever flavors Linnux comes it. Not to mention that there's now two flavors of GMP. How many different permutations do you suppose that is? Thinking about it makes my head hurt. I certainly fell sympathy towards you developers. -- http://mail.python.org/mailman/listinfo/python-list
Re: Wrap a function
Ben Finney wrote:
Dennis Lee Bieber writes:
On Thu, 28 Jan 2010 11:24:28 -0800 (PST), Joan Miller:
On 28 ene, 19:16, Josh Holland wrote:
Check the docs on os.system().
No. I've a function that uses subprocess to run commands on the same
shell and so substitute to bash scrips. But a script full of run
("shell_command --with --arguments") is too verbose.
I shall blaspheme, and suggest that maybe the language you want
to use is REXX (ooREXX or Regina).
Heh. That isn't blasphemy, because no true Pythonista [0] would claim
Python to be the god of that domain.
It's no sin to say that Python isn't a good choice for specific things;
and “I want to write programs by indistinguishably mixing statements
with external system calls” is one of them, IMO
From
http://stromberg.dnsalias.org/~dstromberg/debugging-with-syscall-tracers.html#terminology
A quick note on terminology: open() is typically a system call.
fopen is probably never a system call - instead, it is a function in
the C library that wraps open(), making open() easier to use. Then
there's the system() function - like fopen(), it isn't really a
system call, despite its name. Rather, it is a C library function
that typically will wrap the fork() and exec*() system calls.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Dreaming of new generation IDE
Vladimir Ignatov wrote: dynamic-type languages. Instead of current text-oriented IDEs, it should be a database-centric and resemble current CAD systems instead of being just "fancy text editor". Source text should be an output product of that CAD and not a "source material" itself. can you sketch an example/use case more concretely? Robert -- http://mail.python.org/mailman/listinfo/python-list
Re: Dreaming of new generation IDE
John Bokma wrote:
> my $x = ( 5, "hello", sub {}, [], {} )[ int rand 5 ];
>
> what's $x? The answer is: it depends.
That's why my blog post advocated (as usual for me) developer tests.
Then you either mock the rand, like all developers should, or you get
what you pay for, and Principle of Least Surprise still applies...
Over the past decade, teams discovered that developer tests more than
made up for the lack of rigor in dynamic languages. A dynamic language
with tests can be more productive than a static language, even with
its runtime type checks AND with its tests.
However, our editors must catch up to us. When I test, I am statically
declaring a set of types, even if the language would prefer to
dynamically fling them hither and yon. We should leverage that.
--
Phlip
--
http://mail.python.org/mailman/listinfo/python-list
Re: Logging oddity: handlers mandatory in every single logger?
On Feb 3, 11:36 am, Masklinn wrote: Well, Xavier, I would be the first to agree that the existing logging configuration API is not ideal. There are a number of reasons for the current ConfigParser schema used (e.g. an old GUI for configuring logging, which was there before the logging package was added to Python, but which was not brought across). However, there is no point in nitpicking over the particular shortcomings you've focused on, unless of course you've run out of bikesheds to paint ;-) Particularly as I've just received the good news from Guido van Rossum that PEP 391 (Dictionary-Based Configuration For Logging) has been accepted, and my aim is to get it into Python 2.7 and Python 3.2. Now, PEP 391 was announced on python-list and python-dev in October 2009, so plenty of people have had an opportunity to comment on it. Going forwards, and over time, I would hope that this configuration scheme will supplant the ConfigParser-based approach, and so I don't think there's much need to tinker with that API. Onwards, upwards, ever forwards :-) Regards, Vinay Sajip -- http://mail.python.org/mailman/listinfo/python-list
Re: exec within function
Gerald Britton wrote:
> On Wed, Feb 3, 2010 at 2:59 PM, Terry Reedy wrote:
>> On 2/3/2010 3:30 AM, Simon zack wrote:
>>>
>>> hi,
>>> I'm not sure how I can use exec within a function correctly
>>> here is the code i'm using:
>>>
>>> def a():
>>> exec('b=1')
>>> print(b)
>>>
>>> a()
>>>
>>> this will raise an error, but I would like to see it outputting 1
>>
>> Always **copy and paste** **complete error tracebacks** when asking a
>> question like this. (The only exception would be if it is v e r y long,
>> as with hitting the recursion depth limit of 1000.)
> I get no error:
>
def a():
> ... exec('b=1')
> ... print(b)
> ...
a()
> 1
My crystal ball says you're using Python 2.x. Try it again, this time in
3.x:
Python 3.1.1+ (r311:74480, Nov 2 2009, 15:45:00)
[GCC 4.4.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> def f():
... exec('a = 42')
... print(a)
...
>>> f()
Traceback (most recent call last):
File "", line 1, in
File "", line 3, in f
NameError: global name 'a' is not defined
OP: Python 2.x generates different bytecode for functions containing an exec
statement. In 3.x this statement is gone and exec() has become a normal
function. I suppose you now have to pass a namespace explicitly:
>>> def f():
... ns = {}
... exec("a=1", ns)
... print(ns["a"])
...
>>> f()
1
Peter
--
http://mail.python.org/mailman/listinfo/python-list
Re: Dreaming of new generation IDE
Phlip writes:
> John Bokma wrote:
>
>> my $x = ( 5, "hello", sub {}, [], {} )[ int rand 5 ];
>>
>> what's $x? The answer is: it depends.
>
> That's why my blog post advocated (as usual for me) developer tests.
> Then you either mock the rand, like all developers should, or you get
> what you pay for, and Principle of Least Surprise still applies...
Yup, I agree with you that (to some extent) an IDE should be able to
determine types, especially if programmers don't reuse variables, like
(again Perl):
my $result = # int
:
:
if ( ... ) {
$result = # string
}
# $result can be still an int, or either a string, depending on the
# test.
> Over the past decade, teams discovered that developer tests more than
> made up for the lack of rigor in dynamic languages. A dynamic language
> with tests can be more productive than a static language, even with
> its runtime type checks AND with its tests.
Yup, this matches up with my experience. I can't recall that I ever
bumped into an issue in Perl (the dynamic language I've been using
the most for the past years). Not saying that it hasn't happened, but I
just can't recall. Probably also the reason why a "new" language I am
learning is also dynamic: Python ;-)
> However, our editors must catch up to us. When I test, I am statically
> declaring a set of types, even if the language would prefer to
> dynamically fling them hither and yon. We should leverage that.
I am all for testing, but it should IMO not get into the way. I am quite
happy with Emacs as an editor (I "recently" switched), it satisfies most
(if not all) of the items on the check list.
--
John Bokma j3b
Hacking & Hiking in Mexico - http://johnbokma.com/
http://castleamber.com/ - Perl & Python Development
--
http://mail.python.org/mailman/listinfo/python-list
Re: How to guard against bugs like this one?
kj wrote:
I just spent about 1-1/2 hours tracking down a bug.
An innocuous little script, let's call it buggy.py, only 10 lines
long, and whose output should have been, at most two lines, was
quickly dumping tens of megabytes of non-printable characters to
my screen (aka gobbledygook), and in the process was messing up my
terminal *royally*. Here's buggy.py:
import sys
import psycopg2
connection_params = "dbname='%s' user='%s' password='%s'" % tuple(sys.argv[1:])
conn = psycopg2.connect(connection_params)
cur = conn.cursor()
cur.execute('SELECT * FROM version;')
print '\n'.join(x[-1] for x in cur.fetchall())
(Of course, buggy.py is pretty useless; I reduced the original,
more useful, script to this to help me debug it.)
Through a *lot* of trial an error I finally discovered that the
root cause of the problem was the fact that, in the same directory
as buggy.py, there is *another* innocuous little script, totally
unrelated, whose name happens to be numbers.py. (This second script
is one I wrote as part of a little Python tutorial I put together
months ago, and is not much more of a script than hello_world.py;
it's baby-steps for the absolute beginner. But apparently, it has
a killer name! I had completely forgotten about it.)
Both scripts live in a directory filled with *hundreds* little
one-off scripts like the two of them. I'll call this directory
myscripts in what follows.
It turns out that buggy.py imports psycopg2, as you can see, and
apparently psycopg2 (or something imported by psycopg2) tries to
import some standard Python module called numbers; instead it ends
up importing the innocent myscript/numbers.py, resulting in *absolute
mayhem*.
(This is no mere Python "wart"; this is a suppurating chancre, and
the fact that it remains unfixed is a neverending source of puzzlement
for me.)
How can the average Python programmer guard against this sort of
time-devouring bug in the future (while remaining a Python programmer)?
The only solution I can think of is to avoid like the plague the
basenames of all the 200 or so /usr/lib/pythonX.XX/xyz.py{,c} files,
and *pray* that whatever name one chooses for one's script does
not suddenly pop up in the appropriate /usr/lib/pythonX.XX directory
of a future release.
What else can one do? Let's see, one should put every script in its
own directory, thereby containing the damage.
Anything else?
Any suggestion would be appreciated.
TIA!
~k
Here's a pretty simple fix that should work in about any version of
python available:
Put modules in ~/lib. Put scripts in ~/bin. Your modules end with
.py. Your scripts don't. Your scripts add ~/lib to sys.path as
needed. Things that go in ~/lib are named carefully. Things in ~/bin
also need to be named carefully, but for an entirely different reason -
if you name something "ls", you may get into trouble.
Then things in ~/lib plainly could cause issues. Things in ~/bin don't.
Ending everything with .py seems to come from the perl tradition of
ending everything with .pl. This perl tradition appears to have come
from perl advocates wanting everyone to know (by looking at a URL) that
they are using a perl CGI. IMO, it's language vanity, and best
dispensed with - aside from this issue, it also keeps you from rewriting
your program in another language with an identical interface.
This does, however, appear to be a scary issue from a security
standpoint. I certainly hope that scripts running as root don't search
"." for modules.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Dreaming of new generation IDE
Robert writes: > Vladimir Ignatov wrote: >> dynamic-type languages. Instead of current text-oriented IDEs, it >> should be a database-centric and resemble current CAD systems instead >> of being just "fancy text editor". Source text should be an output >> product of that CAD and not a "source material" itself. > > can you sketch an example/use case more concretely? I guess Vladimir means what's called a structure editor. The (by me) aforementioned Synthesizer Generator is an example of such an editor (environment). http://en.wikipedia.org/wiki/Structure_editor http://portal.acm.org/citation.cfm?doid=358746.358755 -- John Bokma j3b Hacking & Hiking in Mexico - http://johnbokma.com/ http://castleamber.com/ - Perl & Python Development -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP 3147 - new .pyc format
On Wed, 03 Feb 2010 11:55:57 +0100, Daniel Fetchinson wrote: [...] >> Python does most of that for you: it automatically recompiles the >> source whenever the source code's last modified date stamp is newer >> than that of the byte code. So to a first approximation you can forget >> all about the .pyc files and just care about the source. > > True, but the .pyc file is lying around and I always have to do 'ls -al > | grep -v pyc' in my python source directory. So alias a one-word name to that :) [...] > Here is an example: shared object files. If your code needs them, you > can use them easily, you can access them easily if you want to, but they > are not in the directory where you keep your C files. They are somewhere > in /usr/lib for example, where they are conveniently collected, you can > inspect them, look at them, distribute them, do basically whatever you > want, but they are out of the way, and 99% of the time while you develop > your code, you don't need them. In the 1% of the case you can easily get > at them in the centralized location, /usr/lib in our example. > > Of course the relationship between C source files and shared objects is > not parallel to the relationship to python source files and the created > pyc files, please don't nitpick on this point. The analogy is in the > sense that your project inevitable needs for whatever reason some binary > files which are rarely needed at hand, only the > linker/compiler/interpreter/etc needs to know where they are. These > files can be stored separately, but at a location where one can inspect > them if needed (which rarely happens). I'll try not to nit-pick :) When an object file is in /usr/lib, you're dealing with it as a user. You, or likely someone else, have almost certainly compiled it in a different directory and then used make to drop it in place. It's now a library, you're a user of that library, and you don't care where the object file is so long as your app can find it (until you have a conflict, and then you do). While you are actively developing the library, on the other hand, the compiler typically puts the object file in the same directory as the source file. (There may be an option to gcc to do otherwise, but surely most people don't use it often.) While the library is still being actively developed, the last thing you want is for the object file to be placed somewhere other than in your working directory. A potentially unstable or broken library could end up in /usr/lib and stomp all over a working version. Even if it doesn't, it means you have to be flipping backwards and forwards between two locations to get anything done. Python development is much the same, the only(?) differences are that we have a lower threshold between "in production" and "in development", and that we typically install both the source and the binary instead of just the binary. When you are *using* a library/script/module, you don't care whether import uses the .py file or the .pyc, and you don't care where they are, so long as they are in your PYTHONPATH (and there are no conflicts). But I would argue that while you are *developing* the module, it would more nuisance than help to have the .pyc file anywhere other than immediately next to the .py file (either in the same directory, or in a clearly named sub-directory). -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Dreaming of new generation IDE
> can you sketch an example/use case more concretely? Sorry, I don't have anything written down. I just have some rough idea of implementation and some concrete features I would like to see in such system. For example: 1) Instant refactoring. No more needs for manual search/inspect/rename. Since system knows exactly that is going on, the refactoring will be fully automatic. 2) Show "xref table" for each function. How often this function used? Where is it used? (code snippets of calls) What functionality is supported by this function? 3) Extended statistics. How many objects this object/function interacts with? Popular functions, dead/unused functions. 4) Code smell detector - too long functions, too much interaction with other objects, global objects, etc. ... Vladimir Ignatov -- http://mail.python.org/mailman/listinfo/python-list
Re: Dreaming of new generation IDE
On 2010-02-03 14:40 PM, Robert wrote: Vladimir Ignatov wrote: dynamic-type languages. Instead of current text-oriented IDEs, it should be a database-centric and resemble current CAD systems instead of being just "fancy text editor". Source text should be an output product of that CAD and not a "source material" itself. can you sketch an example/use case more concretely? I believe that Smalltalk came pretty close to what Vladimir is asking for. You wrote the methods as linear plain text, but you used the GUI three pane class browser to define and navigate classes. You could export class definitions to a text file and read them back in, but in Vladimir's terms, the text files were not the "source material" themselves. http://www.cosc.canterbury.ac.nz/wolfgang.kreutzer/cosc205/smalltalk1.html -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Ruby
On Feb 2, 9:11 pm, John Bokma wrote: > Jonathan Gardner writes: > > I can explain, in an hour, every single feature of the Python language > > to an experienced programmer, all the way up to metaclasses, > > Either you're a hell of a talker, or I am far, far away from being an > experienced programmer. It's advocacy like this, IMO, that keeps people > away from a language, because you can't feel nothing but a failure after > a statement like this. > I can explain all of Python in an hour; I doubt anyone will understand all of Python in an hour. Coming from perl to python, the big "aha!" moment was when I realized there wasn't anything more than what I saw before me. I kept expecting something big around the corner, kind of like when I first discovered refs in perl, or when I realized how hard it truly was to write OO code in perl that actually does what you think it should do. Perl has trained me to be fearful of the language, constantly on the lookout for jabberwockies. If you fall into one of those traps in perl, it's because you weren't smart enough and aren't worthy of the language, or so they say. It's never perl's fault. I mean, doesn't everyone know what the Schwartzian Transform is? Python is the complete opposite. Go through http://docs.python.org/reference/ . Once you've familiarized yourself with all the operators, statements, and the special methods, you're done with syntax and the core language. There is no more. The next step is to learn the basic objects and functions in builtins. That's in the first seven chapters of http://docs.python.org/library/index.html. You can always fall back to the "help" function to remind yourself if you forget. I do it all the time. After that, it's merely figuring out which standard libraries do what and how. The documentation there is complete and awesome, and there are more than enough people willing to point you in the right direction here. There are no dragons in this forest. Heck, this isn't even a forest--- it's a single-room apartment with everything you need right there where you can see it. The thermostat is set to room temperature, and no matter what happens outside, you're safe and protected from it all. -- http://mail.python.org/mailman/listinfo/python-list
Re: Dreaming of new generation IDE
> I guess Vladimir means what's called a structure editor. The (by me) > aforementioned Synthesizer Generator is an example of such an editor > (environment). Maybe. Yes, it kind of "generator". It has (entered somehow) internal representation of target program. Then it generates code out of this internal data. Yes, it is imaginable system, I don't have any working prototype yet. But about to start making it. For prototype I choose python 2.x as implementation language, sqlite as internal database and Django as UI. Vladimir Ignatov -- http://mail.python.org/mailman/listinfo/python-list
Re: Dreaming of new generation IDE
On Wed, 03 Feb 2010 08:18:40 -0500, Adam Tauno Williams wrote: > On Wed, 2010-02-03 at 14:10 +0300, Vladimir Ignatov wrote: >> Hello, >> I am sitting here for quite some time, but usually keep silent ;-) I >> use Python since 2003 both "professionally" and for my hobby projects >> and love it a much. >> I notice however, that "maintaining" existing/older python code is may >> be not so enjoyable task. It may be even harder than supporting old >> code written in some type of "static" languages (like Java or C++). >> Surely "dynamic" nature of python comes with price. > > Yes, it certainly does. Not that you'll get many Pythonistas to confess > to that fact. Somehow those who brag about the readability and > expressiveness of source code just cannot admit that: > > class.method(sting name, int count) > > - is *obviously* more expressive than - > > class.method(name, count) Obviously? I don't know about that. Being told that "count" is an int doesn't really help me -- it's obvious just from the name. In a well- written API, what else could it be? And surely count should be positive or zero but not negative? Saying it's an int is misleading. Or perhaps count can be negative, in which case maybe negative counts have some special meaning that isn't obvious from the function signature. Can I pass None to get the default behaviour? Either way, I need to read the docs, so the supposed added expressiveness doesn't actually add much. And why is count limited to an actual int type, rather than anything which is integer-like? Why can't I pass 3.0 or Decimal(3)? If you have a good reason for that limitation, great, but if it's just there to satisfy the compiler, then boo hiss to you. I cheerfully admit that *sometimes* there are type restrictions which make sense, and of course we know that there are sometimes useful performance gains to be made with static typing. Any compiler which requires types to be declared is far too 1970s though -- a good modern static language should use type inference to reduce the number of declarations needed. As for Pythonistas refusing to accept this, how do you explain function annotations then? Quoting Guido: "Optional static typing has long been requested as a Python feature." http://www.artima.com/weblogs/viewpost.jsp?thread=85551 More on function annotations and type inference for Python: http://lambda-the-ultimate.org/node/1519 http://www.python.org/dev/peps/pep-3107/ http://www.python.org/workshops/2000-01/proceedings/papers/aycock/aycock.html > This is obvious even in the Python documentation itself where one > frequently asks oneself "Uhh... so what is parameter X supposed to be... > a string... a list... ?" The answer is usually "both, and anything else that obeys some subset of the sequence or iterable protocols". -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Dreaming of new generation IDE
On Wed, 03 Feb 2010 06:42:52 -0800, Paul Rubin wrote: > One nice trick with static types is if you change > what the method does (even if its type signature doesn't change), you > can rename the method: > >class.method2(string name, int count): # change 'method' to >'method2' > > and recompile your codebase. Every place in the code that called > 'method' now gets a compile time "undefined method" error that you can > examine to see if you need to update it. This is something you can't > catch with unit tests because the call sites can be in distant modules. I don't understand why that won't work with unit tests. If you change the name of a method, surely your unit tests will now start failing with AttributeError? -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Dreaming of new generation IDE
On Wed, 03 Feb 2010 18:48:12 +0300, Vladimir Ignatov wrote: > Imagine simple operation like "method renaming" in a simple "dumb" > environment like text editor + grep. Now imagine how simple it can be if > system "knows" all your identifiers and just regenerates relevant > portions of text from internal database-alike representation. Something like Bicycle Repair Man then: http://bicyclerepair.sourceforge.net/ -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Dreaming of new generation IDE
On Wed, 03 Feb 2010 10:39:53 -0500, Adam Tauno Williams wrote: > On Wed, 2010-02-03 at 16:23 +0100, Stef Mientki wrote: >> Yes, it certainly does. Not that you'll get many Pythonistas >> to confess >> to that fact. Somehow those who brag about the readability and >> expressiveness of source code just cannot admit that: >> class.method(sting name, int count) >> - is *obviously* more expressive than - class.method(name, >> count) >> Oh, well. >> This is obvious even in the Python documentation itself where >> one >> frequently asks oneself "Uhh... so what is parameter X supposed >> to be... >> a string... a list... ?" > >> But I thought that was the one of beauties of Python, you don't need to >> know if the input parameter is a list or a string. > > You don't need to know; unless of course you want the expected result. Says who? If you're free to assume the function requires a certain type, we're free to assume the function is polymorphic and doesn't. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: simple and fast platform independent IPC
Tim Golden wrote: > >> Anyway, you have in mind that respect to speed: >> >> shared memory> named pipes> Unix domain socket> TCP socket > > True, but the OP didn't mention speed; rather simplicity. Not > saying it isn't a consideration but premature optimisation and > all that... > Yes true. I'm looking for something simple, platform agnostic. Lateron I can always improve performance. Perhaps I'll stick initially with xmlrpc, as it is quite simple, though a little heavy. I just have to see how to deal with servers which are not up, no more up, being restarted. N -- http://mail.python.org/mailman/listinfo/python-list
PyChecker under python's virtualenv
Hi Everybody, I've been doing some test on pythons' virtualenv and recently I've decided to run PyChecker. But I'm having some difficulties with importing modules available only on virtualenv by pychecker. As if it was trying to use systemwide python. I've googled about it, and found nothing in this area. I installed pychecker using python setup.py install from virtualenv. I looked at pychecker script - it uses correct python. Any help appreciate, Soltys -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Ruby
On 2010-02-03 15:32 PM, Jonathan Gardner wrote: I can explain all of Python in an hour; I doubt anyone will understand all of Python in an hour. With all respect, talking about a subject without a reasonable chance of your audience understanding the subject afterwards is not explaining. It's just exposition. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco -- http://mail.python.org/mailman/listinfo/python-list
Re: Wrap a function
Dan Stromberg writes: > Ben Finney wrote: > > It's no sin to say that Python isn't a good choice for specific > > things; and “I want to write programs by indistinguishably mixing > > statements with external system calls” is one of them, IMO > > From > http://stromberg.dnsalias.org/~dstromberg/debugging-with-syscall-tracers.html#terminology > >A quick note on terminology: open() is typically a system call. […] That is a different use of “system call”. I used it in the ‘os.system’ sense: meaning “invoke an external OS command as a child of this process”. -- \ “I was in a bar the other night, hopping from barstool to | `\ barstool, trying to get lucky, but there wasn't any gum under | _o__) any of them.” —Emo Philips | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
