Re: html 2 plain text
robin wrote: > i remember seeing this simple python function which would take raw html > and output the content (body?) of the page as plain text (no <..> tags > etc) > i have been looking at htmllib and htmlparser but this all seems to > complicated for what i'm looking for. i just need the main text in the > body of some arbitrary webbpage to then do some natural-language > processing with it... > thanks for pointing me to some helpful resources! Have a look at the Beautiful Soup library: http://www.crummy.com/software/BeautifulSoup/ Regards -- Faber http://faberbox.com/ http://smarking.com/ A teacher must always teach to doubt his teaching. -- José Ortega y Gasset -- http://mail.python.org/mailman/listinfo/python-list
Re: Threading problem
Aleksandar Cikota wrote:
> How to integrate the Code-part in the main programm, so that the
> mainprogramm works?
>
> Code:
>
> import win32com.client
> import time
> import os
> import threading
>
> Document = win32com.client.Dispatch('MaxIm.Document')
> Application = win32com.client.Dispatch('MaxIm.Application')
> p = win32com.client.dynamic.Dispatch('PinPoint.Plate')
>
> class TestThread ( threading.Thread ):
> path_to_watch = "F:/Images/VRT/"
def run(self):
# Put the following code in the run method
> before = dict ([(f, None) for f in os.listdir (path_to_watch)])
> while 1:
[cut]
> TestThread().start()
This should work
--
Faber
http://faberbox.com/
http://smarking.com/
The man who trades freedom for security does not deserve nor will he ever
receive either. -- Benjamin Franklin
--
http://mail.python.org/mailman/listinfo/python-list
Re: time conversions [hh:mm:ss.ms <-> sec(.ms)
kpp9c wrote: > I was looking at python & datetime and hoping that it would already > have a method/func to translate time formats. I need to translate seconds > to hh:mm:ss.ms and vice versa and would like the ability to do some basic > arithmetic in these formats. Have a look at datetime.timedelta: from datetime import timedelta seconds_value = 4237.63 td = timedelta(seconds=seconds_value) print td# Shows 1:10:37.63 print td.seconds# Shows 4237 other_td = td + timedelta(seconds=13) print other_td# Shows 1:10:50.63 print other_td.seconds# Shows 4250 > I think that there just has to be a package or module out there that > already does this with reasonable speed and accuracy. The accuracy seems perfect, don't know about speed - take some test :) Regards -- Faber http://faberbox.com/ http://smarking.com/ We live in a society exquisitely dependent on science and technology, in which hardly anyone knows anything about science and technology. -- Carl Sagan -- http://mail.python.org/mailman/listinfo/python-list
Re: time conversions [hh:mm:ss.ms <-> sec(.ms)
kpp9c wrote: > timedelta looks to be just the ticket! bravo, thank you... i guess this > must be pretty new to Python. Well, since Python 2.3 (July 2003): http://www.python.org/doc/2.3.5/whatsnew/node18.html#SECTION000181 :-) -- Faber http://faberbox.com/ http://smarking.com/ Only wimps use tape backup: _real_ men just upload their important stuff on ftp and let the rest of the world mirror it -- Linus Torvalds -- http://mail.python.org/mailman/listinfo/python-list
dict: keys() and values() order guaranteed to be same?
Hi group,
I have a question of which I'm unsure if the specification guarantees
it. With an arbitrary dictionaty d, are d.keys() and d.values()
guaraneed to be in the same order? I.e. what I mean is:
# For all dictionaries d:
assert({ list(d.keys())[i]: list(d.values())[i] for i in range(len(d)) }
== d)
I'm curious if it's allowed because in a special case it would make for
a nice shortcut and clean code. I think however that the implementation
may chose not to have them in the same order necessarily -- then I'd
obviously avoid relying on it.
Best regards,
Joe
--
http://mail.python.org/mailman/listinfo/python-list
Re: dict: keys() and values() order guaranteed to be same?
On 23.07.2012 13:40, Philipp Hagemeister wrote: > On 07/23/2012 01:23 PM, Henrik Faber wrote: >> With an arbitrary dictionaty d, are d.keys() and d.values() >> guaraneed to be in the same order? > > Yes. From the documentation[1]: > > If items(), keys(), values(), iteritems(), iterkeys(), and itervalues() > are called with no intervening modifications to the dictionary, the > lists will directly correspond. Ah, nice! > In most cases, you should simply use items() though. Can you elaborate > on the use case for needing both keys() and values(), where items() is > not applicable? I need to parse and modify the keys of the dict and pass the keys as a compound object to a function, which expects the values to be passed as an argument list (weird, but can't change that). The order of arguments is arbitrary (as the iteration over a dict is), but there has to be a 1-to-1 relation bewtween the compound object's key order and the argument list's value order. Best regards, Henrik -- http://mail.python.org/mailman/listinfo/python-list
Re: the meaning of rï¾â¢.......ï¾
On 23.07.2012 14:55, Roy Smith wrote: > In article <500d0632$0$1504$c3e8da3$76491...@news.astraweb.com>, > Steven D'Aprano wrote: > >> Technically, no, it's a SyntaxError, because the Original Poster has used >> some sort of "Smart Quotes" characters rââ¬â¢Ã¢â¬Ë instead of good old fashioned >> typewriter-style quotes r'' or r"". >> >> If you're going to ask programming questions using an email client that >> changes what you type, including smart quotes, special hyphens or other >> characters, you're going to have a bad time. > > Some day, we're going to have programming languages that take advantage > of the full unicode character set. Right now, we're working in ASCII > and creating silly digrams/trigrams like r'' for raw strings (and > triple-quotes for multi-line > strings). Not to mention <=, >=, ==, !=. And in languages other than > python, things like ->, => (arrows for structure membership), and so on. I disagree. Firstly, Python could already support the different types of strings even with the ASCII character set. For example, the choice could have made to treat the apostophe string 'foo' differently from the double quote string "foo". Then, the backtick could have been used `foo`. Bash for example uses all three and all three have very different meanings. Python is different: explicit is better than implicit, and I'd rather have the "r" the signifies what weird magic is going on instead of having some weird language rules. It would not be different with some UTF-8 "rawstring" magic backticks. Secondly, there's a reason that >=, <= and friends are in use. Every keyboard has a > key and every keyboard has a = key. I don't know any that would have >=, <= or != as UTF-8. It is useful to use only a limited set of characters. And if I think of PHP's latest fiasco that happened with unicode characters, it makes me shudder to think you'd want that stuff in Python. If I remember correctly, it was the Turkish locale that they stuggled with: Turkey apparently does not have a capital "I", so some weird PHP magic code broke with the Turkish locale in effect. Having to keep crap like that in mind is just plain horrible. I'm very happy with the way Python does it. Best regards, Henrik -- http://mail.python.org/mailman/listinfo/python-list
Re: the meaning of rï¾â¢.......ï¾
On 23.07.2012 14:55, Roy Smith wrote: > Some day, we're going to have programming languages that take advantage > of the full unicode character set. Plus, if I may add this: It's *your* newsreader that broke the correctly declared ISO-8859-7 encoded subject of the OP. What a bitter irony that demonstrates nicely that even in the 2010s complete and ultimate Unicode support is far from here. Best regards, Henrik -- http://mail.python.org/mailman/listinfo/python-list
Re: the meaning of rï¾â¢.......ï¾
On 23.07.2012 15:35, Chris Angelico wrote: > That said, though, there's good argument in allowing full Unicode in > *identifiers*. If I'm allowed to name something "foo", then a German > should be allowed to name something "foö". And since identifiers are > case sensitive (at least, they are in all good languages...), there > should be no issues with not having particular letters. To you have a "ö" key on your keyboard? I have one. It wouldn't be a problem for me. Most English layouts probably don't. It would be annoying. If you allow for UTF-8 identifiers you'll have to be horribly careful what to include and what to exclude. Is the non-breaking space a valid character for a identifier? Technically it's a different character than the normal space, so why shouldn't it be? What an awesome idea! What about à vs x? Or à vs à vs à vs à vs Ĩ vs Ī vs Ä« vs Ĭ vs Ä vs Ä® vs į vs I vs Ä°? Do you think if you need to maintain such code you'll immediately know the difference between the 13 (!) different "I"s I just happened to pull out randomly you need to chose and how to get it? What about È vs È? Or È¢ vs È£? Or ȸ vs ȹ? Or d vs Ô vs Ô vs Ô vs Ô? Or Ö vs g? Or Õ½ vs u? I've not even mentioned the different punctuation marks and already it's hell of a mess, although I just happened to look into a few pages. Having UTF-8 in identifiers is a horrible idea. It makes perfect sense to support it within strings (as Python3 does), but I would hate for Python to include them into identifiers. Then again, I'm pretty sure this is not planned anytime soon. Best regards, Henrik -- http://mail.python.org/mailman/listinfo/python-list
Re: the meaning of rï¾â¢.......ï¾
On 23.07.2012 15:52, Henrik Faber wrote: > but I would hate for > Python to include them into identifiers. Then again, I'm pretty sure > this is not planned anytime soon. Dear Lord. Python 3.2 (r32:88445, Dec 8 2011, 15:26:58) [GCC 4.5.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> fööbär = 3 >>> fööbär 3 I didn't know this. How awful. Regards, Johannes -- http://mail.python.org/mailman/listinfo/python-list
Re: the meaning of rï¾â¢.......ï¾
On 23.07.2012 15:55, Henrik Faber wrote: > Dear Lord. > > Python 3.2 (r32:88445, Dec 8 2011, 15:26:58) > [GCC 4.5.2] on linux2 > Type "help", "copyright", "credits" or "license" for more information. >>>> fööbär = 3 >>>> fööbär > 3 > > I didn't know this. How awful. Apparently, not all characters are fine with Python. Why can I not have domino tiles are identifier characters? >>> ð» = 9 File "", line 1 ð» = 9 ^ SyntaxError: invalid character in identifier I think there needs to be a PEP for that. Regads, Henrik -- http://mail.python.org/mailman/listinfo/python-list
Re: the meaning of rﾕ.......ï¾
On 23.07.2012 16:19, Chris Angelico wrote: > On Mon, Jul 23, 2012 at 11:52 PM, Henrik Faber wrote: >> What about × vs x? Or Ì vs Í vs Î vs Ï vs Ĩ vs Ī vs ī vs Ĭ vs ĭ vs Į vs >> į vs I vs İ? Do you think if you need to maintain such code you'll >> immediately know the difference between the 13 (!) different "I"s I just >> happened to pull out randomly you need to chose and how to get it? What >> about Ȝ vs ȝ? Or Ȣ vs ȣ? Or ȸ vs ȹ? Or d vs Ԁ vs ԁ vs ԃ vs Ԃ? Or ց vs g? >> Or ս vs u? > > If they're different characters, they're different. It's not unlike > the confusion you can already get between uppercase I and lowercase l, > or between uppercase and lowercase of the same letter, or between rn > and m, or between any other of myriad confusingly-similar pairs that > can be found just in ASCII. But your reasoning is flawed: bascially you're saying some things are already confusing, so it's just fine to add more confusion. It is not in my opinion. And that the computer can differentiate different characters is also perfectly clear to me. The interpreter can also tell the difference between a non-breaking space and a regular space. Yet the non breaking space is not valid for a identifying character. This is because readability counts. People write and maintain code, not machines. Confusion should be kept to the miminum if possible. > Of course, SOMEBODY is going to make use of those to improve upon this > sort of code: > > http://thedailywtf.com/Articles/Uppity.aspx If that was written by my coworkers, I'd strangle them. Regards, Henrik -- http://mail.python.org/mailman/listinfo/python-list
Re: the meaning of rﾕ.......ï¾
On 23.07.2012 16:10, Devin Jeanpierre wrote: > On Mon, Jul 23, 2012 at 9:52 AM, Henrik Faber wrote: >> If you allow for UTF-8 identifiers you'll have to be horribly careful >> what to include and what to exclude. Is the non-breaking space a valid >> character for a identifier? Technically it's a different character than >> the normal space, so why shouldn't it be? What an awesome idea! >> >> What about × vs x? Or Ì vs Í vs Î vs Ï vs Ĩ vs Ī vs ī vs Ĭ vs ĭ vs Į vs >> į vs I vs İ? Do you think if you need to maintain such code you'll >> immediately know the difference between the 13 (!) different "I"s I just >> happened to pull out randomly you need to chose and how to get it? What >> about Ȝ vs ȝ? Or Ȣ vs ȣ? Or ȸ vs ȹ? Or d vs Ԁ vs ԁ vs ԃ vs Ԃ? Or ց vs g? >> Or ս vs u? > > Yes, as soon as we add unicode to anything everyone will go insane and > write gibberish. No, you misunderstood me. I didn't say people are going to write gibberish. What I'm saying is that as a foreigner (who doesn't know most of these characters), it can be hard to accurately choose which one is the correct one. This is especially true if the appropriate keys are not available on your keyboard. So it makes maintenance of other people's code much more difficult if they didn't on their own chose to limit themselves to ASCII. Regards, Henrik -- http://mail.python.org/mailman/listinfo/python-list
Re: the meaning of rï¾â¢.......ï¾
On 23.07.2012 16:43, Mark Lawrence wrote: >> Apparently, not all characters are fine with Python. Why can I not have >> domino tiles are identifier characters? >> > ð» = 9 >>File "", line 1 >> ð» = 9 >> ^ >> SyntaxError: invalid character in identifier >> >> I think there needs to be a PEP for that. > > well get writing then as there's nothing to stop you. I might wait until April 1st next year with that ;-) Best regards, Henrik -- http://mail.python.org/mailman/listinfo/python-list
Re: Python vs. C++11
On 15.02.2012 08:18, Tim Roberts wrote: > sturlamolden wrote: >> >> There are bigsimilarities between Python and the new C++ standard. Now >> we can actually use our experience as Python programmers to write >> fantastic C++ :-) > > This is more true than you might think. For quite a few years now, I've > been able to do an almost line-for-line translation of my Python programs > to C++ programs. (Microsoft has had a "for each" extension for a while > that made this easier.) I disagree. Unicode support comes for free with Python3+ while C++ it still is a piece of crap (or something that you'll have to pass to external libraries). The C++ standard library is nowhere nearly as densely packed with features than Python's. For every little thing you need some external dependencies. Language semantics aren't enough to translate one language into another. Best regards, Henrik -- http://mail.python.org/mailman/listinfo/python-list
Operator commutativity
Hi there, when I have a python class X which overloads an operator, I can use that operator to do any operation for example with an integer y = X() + 123 however, say I want the "+" operator to be commutative. Then y = 123 + X() should have the same result. However, since it does not call __add__ on an instance of X, but on the int 123, this fails: TypeError: unsupported operand type(s) for +: 'int' and 'X' How can I make this commutative? Best regards, Henrik -- http://mail.python.org/mailman/listinfo/python-list
Re: Operator commutativity
On 19.09.2011 13:23, Paul Rudin wrote: > Henrik Faber writes: > >> How can I make this commutative? > > Incidentally - this isn't really about commutativity at all - the > question is how can you define both left and right versions of add, > irrespective of whether they yield the same result. Right. The operator+ in my case just happens to be commutative and I wanted a language way to express this. > I think __radd__ is what you're after. It is, thank you very much - I knew there was some way to get this done nicely. Perfect! :-) Best regards, Henrik -- http://mail.python.org/mailman/listinfo/python-list
Re: all() is slow?
On 07.11.2011 23:06, Chris Angelico wrote: > On Tue, Nov 8, 2011 at 8:46 AM, david vierra wrote: >> But, you didn't write an all() function. You wrote a more specialized >> allBoolean() function. I think this comparison is more fair to the >> builtin all(): > > So really, it's not "all() is slow" but "function calls are slow". > Maybe it'd be worthwhile making an all-factory: PLEASE say you're joking. If I saw code like that on any of our project, this would definitely qualify for a DailyWTF. Regards, Henrik -- http://mail.python.org/mailman/listinfo/python-list
Re: Multiple threads
On 16.11.2011 14:48, Eduardo Oliva wrote:
> I need my script to run 2 separated threads, and then when the first has
> finished, starts the next onebut no more than 2 threads.
> I know that Semaphores would help with that.
> But the problem here is to know when the thread has finished its job, to
> release the semaphore and start another thread.
Absolute standard request, has nothing to do with Python. The way to go
(in Cish pseudocode) is:
thread() {
/* do work */
[...]
/* finished! */
semaphore++;
}
semaphore = 2
while (jobs) {
semaphore--;// will block if pool exhausted
thread();
}
// in the end, collect remaining two workers
semaphore -= 2 // will block until all are finished
Best regards,
Henrik
--
http://mail.python.org/mailman/listinfo/python-list
Confusion about decorators
Hi group,
I'm a bit confused regarding decorators. Recently started playing with
them with Python3 and wanted (as an excercise) to implement a simple
type checker first: I know there are lots of them out there, this is
actually one of the reasons I chose that particular function (to compare
my solution against other, proven solutions).
Starting with a blank slate, I did something along the lines of:
class _TypeCheckedFunction():
def __init__(self, decoratedfunction):
self._decoratedfunction = decoratedfunction
def __call__(self, *args, **kwargs):
[...] Actual checking
def typecheck(wrappedfunction):
checkfunction = _TypeCheckedFunction(wrappedfunction)
functools.update_wrapper(checkfunction, wrappedfunction)
return checkfunction
And decorate my methods like
@typecheck
def setbar(self, bar: str):
This works somewhat. The problem is, however, when the method is
actually called. This is what happens:
1. The decorator is called upon import of the decorated class. It
creates a _TypeCheckedFunction(setbar) object.
2. When setbar is actually called (blubb.setbar("fooobar")), the
__call__ method of the previously created _TypeCheckedFunction is invoked.
3. When trying to call self._decoratedfunction from within that object,
this fails: "self" is missing! self._decoratedfunction is only the
*function*, not the bound function of the object that contains setbar().
Therefore I cannot proceed here.
Solutions that I have seen working usually consist of two functions
wrapped in each other, but I do not know why the additional introduction
of a class makes everything fail.
Can someone please enlighten me?
Best regards,
Henrik
--
http://mail.python.org/mailman/listinfo/python-list
Re: Confusion about decorators
On 12.12.2011 14:37, Andrea Crotti wrote: > On 12/12/2011 01:27 PM, Henrik Faber wrote: >> Hi group, >> >> I'm a bit confused regarding decorators. Recently started playing with >> them with Python3 and wanted (as an excercise) to implement a simple >> type checker first: I know there are lots of them out there, this is >> actually one of the reasons I chose that particular function (to compare >> my solution against other, proven solutions). > > Not sure how that could work in general, what does "bar: str" should do? > Is that a dictionary? No. It's PEP 3107 function annotations. > Anyway there is already an implementation if you're interested for type > checking: > http://oakwinter.com/code/typecheck/ *sigh* no, not really -- this is exactly why I wrote "I know there are lots of them out there". I've actually seen and run http://code.activestate.com/recipes/577299-method-signature-type-checking-decorator-for-pytho/ However, this doesn't do it for me -- I want to know why my solution fails, not just use some other solution without really understanding it. I really would like to understand what's going on. I'm especially puzzled about the fact that in my solution, __call__ is called with only the method's arguments (i.e. "fooobar") in my example instead of two arguments (self, "fooobar"). Best regards, Henrik -- http://mail.python.org/mailman/listinfo/python-list
Re: Confusion about decorators
On 12.12.2011 14:45, Arnaud Delobelle wrote:
>> Can someone please enlighten me?
>
> You can (need to?) use the descriptor protocol to deal with methods.
>
> from functools import partial
[...]
>def __get__(self, obj, objtype):
>return partial(self, obj)
Whoa. This is absolutely fantastic, it now works as expected (I get a
reference to "self").
I am very amazed -- I've been programming Python for about 5 years now
and have never even come close to something as a "descriptor protocol".
Python never ceases to amaze me. Do you have any beginners guide how
this works? The Pydoc ("Data Model") is comprehensive, but I really
don't know where to start to look.
Still amazed!
Best regards,
Henrik
--
http://mail.python.org/mailman/listinfo/python-list
Re: Confusion about decorators
On 12.12.2011 15:01, Arnaud Delobelle wrote:
>> I am very amazed -- I've been programming Python for about 5 years now
>> and have never even come close to something as a "descriptor protocol".
>> Python never ceases to amaze me. Do you have any beginners guide how
>> this works? The Pydoc ("Data Model") is comprehensive, but I really
>> don't know where to start to look.
>
> Well, I've been using Python for 10 years :) The best reference I know is:
>
> http://users.rcn.com/python/download/Descriptor.htm
Everyone starts out as a Padawan and I am no exception :-)
Maybe five years from now I'll also have made my way to be a Python Jedi
and also shake the ins and outs of descriptors out of my sleeve :-)
But I can only repeat myself: Python is such an exceptional language,
the more and more I know about it, the more I fall in love! Fantastic. I
wish we had these types of language when I was a kid!
Best regards and thanks again,
Henrik
--
http://mail.python.org/mailman/listinfo/python-list
Signature-preserving decorators
Hi group, when decorating a method in Python3, by use of the functools.update_wrapper function, it can be achieved that the docstring and name of the original function is preseverved. However, the prototype is lost: When looking into the Python help, I have lots of entries that look like: getfoo(*args, **kwargs) -> int setbar(*args, **kwargs) As you can imagine, this is really not very self-explanatory. I've seen a solution which constructs a wrapper's wrapper function using inspection and eval -- this looks really dirty to me, however. Then there's the "decorator" external module -- but I'd like to do it with on-board tools. Is this possible in Python3 with too much of a hassle? Best regards, Joe -- http://mail.python.org/mailman/listinfo/python-list
Newbie Q: modifying SQL statements
Hi all,
I'm in the process of learning Python by writing a job queue program.
Nothing fancy, mind you, just read from a table, shell out to a program,
write back to the table.
I'm working off of the tutorial listed here (amongst many places):
http://www.devx.com/dbzone/Article/22093
In my Jobs class I have:
def __iter__(self):
"creates a data set, and returns an iterator (self)"
q = "select * from %s" % (self.name)
self._query(q)
return self # an Iterator is an object
# with a next() method
def next(self):
"returns the next item in the data set,
or tells Python to stop"
r = self.dbc.fetchone()
if not r:
raise StopIteration
return r
which works well, but what if I want to modify the __iter__ query? I
want to be able to do something like this (and I know this is not the
right syntax but you'll get my drift):
for job in jobs: print job # which the above code does
for job in jobs("status = running"): print job
for job in jobs("jobid = 4"): print job
What's the pythonic way of doing this?
--
Regards,
Faber
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Newbie Q: modifying SQL statements
On 10/01/08 22:53 -0500, Mike Meyer wrote:
> Personally, I think it would be more pythonic to not try and use two
> different APIs to walk the list of jobs (... One Way To Do it):
>
> def __call__(self, where=None):
> q = "select * from %s" % (self.name,) + ("" if not where else (" where
> %s" % where))
Does this '("" if not where...' syntax actually work? I couldn't get it to
compile and I couldn't find any examples of such syntax (but you can't
expect googling for 'if not' to be too successful). I ended up
changing that line to:
q = "select * from %s" % (self.name,)
if where: q += "where %s" %where
> for r in self.dbc.iterresults() # I assume it has something like this
I don't think it does, if I read
http://dustman.net/andy/python/MySQLdb_obsolete/doc/MySQLdb-3.html
correctly.
--
Regards,
Faber Fedor
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Newbie Q: modifying SQL statements
On 11/01/08 18:29 -0500, Mike Meyer wrote: > It is a 2.5 feature, though. I was beginning to wonder of that was the case. > I converted all my clients to 2.5.1, > shortly after it was available, and haven't used anything older > since. Sorry 'bout that. No prob. -- Regards, Faber Fedor -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- http://mail.python.org/mailman/listinfo/python-list
Re: Newbie Q: modifying SQL statements
On 12/01/08 00:23 +0100, Hrvoje Niksic wrote:
> "Faber J. Fedor" <[EMAIL PROTECTED]> writes:
> > Does this '("" if not where...' syntax actually work?
>
> http://docs.python.org/whatsnew/pep-308.html
C'mon! I'm in Day Two of learning Python. You can't expect me to be
reading "What's New" docs already! :-)
I did find it interesting that the page mentioned said "Guido van Rossum
eventually chose a surprising syntax:". When I first saw the construct
I thought "Oh, they borrowed that from Perl". :-) (Although you can't do the
else part in Perl, it is a natural extension, IMO.)
--
Regards,
Faber Fedor
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
--
http://mail.python.org/mailman/listinfo/python-list
Re: where do my python files go in linux?
On 12/01/08 12:02 +0100, Jorgen Bodde wrote:
> Hi All,
>
> I am trying to make a debian package. I am following the tutorial by
> Horst Jens
> (http://showmedo.com/videos/video?name=linuxJensMakingDeb&fromSeriesID=37)
> and it is very informative. However one thing my app has and his
> doesn't, is multiple python files which need to be executed. For
> example
>
> {dir}/app
> app.py
>
> app.py calls a lot of modules in {dir}/app. Horst says the python file
> goes in /usr/bin/app.py which is ok with me, but I have multiple
> python files, and I decided to use an app.sh script to call my python
> files. In the /usr/bin I do not see subdirs so I assume that is not
> really desirable.
>
> Question 1. Where do I put the bulk of python scripts in a normal
> linux environment?
I would think you'd create a directory /usr/bin/app and then symlink
/usr/bin/app.py to /usr/bin/app/app.py.
> Question 2. Should I use *.pyc rather then *.py files to speed up
> executing as the user cannot write to /usr/bin or any other dir in the
> system and everytime my app runs it will recompile it
That would make sense.
> Thanks for any advice or maybe a good tutorial how to set up files in
> a linux environment
http://www.pathname.com/fhs/ (couldn't find a more
recent version, sorry.)
--
Regards,
Faber Fedor
President
Linux New Jersey, Inc.
908-320-0357
800-706-0701
http://www.linuxnj.com
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
--
http://mail.python.org/mailman/listinfo/python-list
