Re: Changing filenames from Greeklish => Greek (subprocess complain)
On Sun, 02 Jun 2013 22:05:28 -0700, Νικόλαος Κούρας wrote:
> Why subprocess fails when it has to deal with a greek flename? and that
> an indirect call too
It doesn't. The command you are calling fails, not subprocess.
The code you show is this:
/home/nikos/public_html/cgi-bin/metrites.py in ()
217 template = htmldata + counter
218 elif page.endswith('.py'):
=> 219 htmldata = subprocess.check_output( '/home/nikos/
public_html/cgi-bin/' + page )
220 template = htmldata.decode('utf-8').replace
( 'Content-type: text/html; charset=utf-8', '' ) + counter
The first step is to inspect the value of the file name. Normally I would
just call print, but since this is live code, and a web server, you
probably don't want to use print directly. But you can print to a file,
and then inspect the file. Using logging is probably better, but here's a
real quick and dirty way to get the same result:
elif page.endswith('.py'):
name = '/home/nikos/public_html/cgi-bin/' + page
print(name, file=open('/home/nikos/out.txt', 'w'))
htmldata = subprocess.check_output(name)
Now inspect /tmp/out.txt using the text editor of your choice. What does
it contain? Is the file name of the executable what you expect? Does it
exist, and is it executable?
The next step, after checking that, is to check the executable .py file.
It may contain a bug which is causing this problem. However, I think I
can guess what the nature of the problem is.
The output you show includes:
cmd = '/home/nikos/public_html/cgi-bin/files.py'
output = b'Content-type: text/html; charset=utf-8\n\n\n\n'
My *guess* of your problem is this: your file names have invalid bytes in
them, when interpreted as UTF-8.
Remember, on a Linux system, file names are stored as bytes. So the file-
name-as-a-string need to be *encoded* into bytes. My *guess* is that
somehow, when renaming your files, you gave them a name which may be
correctly encoded in some other encoding, but not in UTF-8. Then, when
you try to read the file names in UTF-8, you hit an illegal byte, half of
a surrogate pair perhaps, and everything blows up.
Something like this:
py> s = "Νικόλαος Κούρας"
py> b = s.encode('ISO-8859-7') # Oh oh, wrong encoding!
py> print(b)
b'\xcd\xe9\xea\xfc\xeb\xe1\xef\xf2 \xca\xef\xfd\xf1\xe1\xf2'
py> b.decode('UTF-8')
Traceback (most recent call last):
File "", line 1, in
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xcd in position 0:
invalid continuation byte
Obviously the error is a little different, because the original string is
different.
If I am right, the solution is to fix the file names to ensure that they
are all valid UTF-8 names. If you view the directory containing these
files in a file browser that supports UTF-8, do you see any file names
containing Mojibake?
http://en.wikipedia.org/wiki/Mojibake
Fix those file names, and hopefully the problem will go away.
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
Re: Changing filenames from Greeklish => Greek (subprocess complain)
Thankls Michael,
are these two behave the same in your opinion?
sys.stdout = os.fdopen(1, 'w', encoding='utf-8')
which is what i have now
opposed to this one
import ocdecs
sys.stdout = codecs.getwriter("utf-8")(sys.stdout.detach())
Which one should i keep and why?
--
http://mail.python.org/mailman/listinfo/python-list
Re: PyWart: The problem with "print"
On 06/02/2013 12:18 PM, Rick Johnson wrote: > On Sunday, June 2, 2013 12:49:02 PM UTC-5, Dan Sommers wrote: >> On Mon, 03 Jun 2013 03:20:52 +1000, Chris Angelico wrote: >>> On Mon, Jun 3, 2013 at 3:04 AM, Rick Johnson >> [...] Or use the logging module. It's easy to get going quickly >> (just call logging.basicConfig at startup time), and with a little >> care and feeding, you can control the output in more ways than can >> fit into the margin. Oh, yeah, I'm sure it introduces some >> overhead. So does everything else. > > I hate log files, at least during development or testing. I prefer to > debug on the command line or using my IDE. Log files are for release > time, not development. Except that it's not. Have you even looked at what the logging module is? It most certainly can log to stderr if you provide no logging handler to write to a file. -- http://mail.python.org/mailman/listinfo/python-list
Re: Changing filenames from Greeklish => Greek (subprocess complain)
On 06/02/2013 11:22 PM, Νικόλαος Κούρας wrote: > Ok, this email is something of a recital of how I approached this. Excellent. You're making progress. Keep doing research, and learn how to debug your python programs. One thing I've done as a last resort when I just can't get good error reporting because of subprocess or something else, is to have my script open a file in /tmp and write messages to it as the program executes. Sometimes I write out what the standard input was so I know for doing a standalone run. There's your free hint for the day. -- http://mail.python.org/mailman/listinfo/python-list
Re: Changing filenames from Greeklish => Greek (subprocess complain)
On 06/02/2013 12:34 PM, Νικόλαος Κούρας wrote: > The whole subprocess fails when it has to deal with a greek lettered > filename. No it doesn't. subprocess is working correctly. It's the program subprocess is running that is erring out. subprocess is merely reporting to you that it erred out, just as it should. > I just dont get it... I didn't ask for metrites.py to open via > subprocess the greek filename, i just told metrites.py to call > files.py which in turn tries to open that greek filename. Seems to me, then it's clear how you should go about debugging this. Have to run each layer separately, and see where the error occurs. Start with files.py. that's what any of us would do if the code were ours. But we can't do the debugging for you. It's not possible! We don't have access to your code nor to your server environment. Nor is it appropriate for any of us who have no contractual relationship with you to have such access to your server. Good luck. -- http://mail.python.org/mailman/listinfo/python-list
Re: Changing filenames from Greeklish => Greek (subprocess complain)
But still when it comes to subprocess trying to call files.py which in turn tries to call a greek filename i get the same response i posted at my initial post. -- http://mail.python.org/mailman/listinfo/python-list
Re: Changing filenames from Greeklish => Greek (subprocess complain)
Ok, this email is something of a recital of how I approached this.
The apache error log:
I restarted the apache:
/etc/init.d/httpd restart
Then a:
ps axf
gave me the PID of a running httpd. Examining its open files:
lsof -p 9287
shows me:
httpd 9287 nobody2w REG0,192 12719609 56510510
/usr/local/apache/logs/error_log
httpd 9287 nobody7w REG0,192 7702310 56510512
/usr/local/apache/logs/access_log
among many others.
So, to monitor these logs:
tail -F /usr/local/apache/logs/error_log /usr/local/apache/logs/access_log &
placing the tail in the background so I can still use that shell.
Watching the log while fetching the page:
http://superhost.gr/
says:
==> /usr/local/apache/logs/error_log <==
[Tue Apr 23 12:11:40 2013] [error] [client 54.252.27.86] suexec policy
violation: see suexec log for more details
[Tue Apr 23 12:11:40 2013] [error] [client 54.252.27.86] Premature end of
script headers: metrites.py
[Tue Apr 23 12:11:40 2013] [error] [client 54.252.27.86] File does not exist:
/home/nikos/public_html/500.shtml
[Tue Apr 23 12:11:43 2013] [error] [client 107.22.40.41] suexec policy
violation: see suexec log for more details
[Tue Apr 23 12:11:43 2013] [error] [client 107.22.40.41] Premature end of
script headers: metrites.py
[Tue Apr 23 12:11:43 2013] [error] [client 107.22.40.41] File does not exist:
/home/nikos/public_html/500.shtml
[Tue Apr 23 12:11:45 2013] [error] [client 79.125.63.121] suexec policy
violation: see suexec log for more details
[Tue Apr 23 12:11:45 2013] [error] [client 79.125.63.121] Premature end of
script headers: metrites.py
[Tue Apr 23 12:11:45 2013] [error] [client 79.125.63.121] File does not
exist: /home/nikos/public_html/500.shtml
So:
You're using suexec in your Apache. This greatly complicates your debugging.
Suexec seems to be a facility for arranging that CGI script run as the user
who owns them. Because that has a lot of potential for ghastly
security holes, suexec performs a large number of strict checks on
CGI script locations, permissions and locations before running a
CGI script. At a guess the first hurdle would be that metrites.py
is owned by root. Suexec is very picky about what users it is
prepared to become. "root" is not one of them, as you might imagine.
I've chowned metrites.py to nikos:nikos. Suexec not lets it run, producing this:
Traceback (most recent call last):
File "metrites.py", line 9, in
sys.stderr = open('/home/nikos/public_html/cgi.err.out', 'a')
PermissionError: [Errno 13] Permission denied:
'/home/nikos/public_html/cgi.err.out'
That file is owned by root. metrites.py is being run as nikos.
So:
chown nikos:nikos /home/nikos/public_html/cgi.err.out
A page reload now shows this:
Error in sys.excepthook:
UnicodeEncodeError: 'ascii' codec can't encode characters in position
2334-2342: ordinal not in range(128)
Original exception was:
Traceback (most recent call last):
File "metrites.py", line 226, in
print( template )
UnicodeEncodeError: 'ascii' codec can't encode characters in position 30-38:
ordinal not in range(128)
This shows you writing the string in template to stdout. The default
encoding for stdout is 'ascii', accepting only characters of values
0..127. I expect template contains more than this, since the ASCII
range is very US Anglocentric; Greek characters for example won't
encode into ascii.
As mentioned in the thread on python-list, python will adopt your
terminal's encoding it used interactively but will be pretty
conservation if the output is not a terminal; ascii as you see
above.
What you want is probably UTF-8 in the output byte stream. But
let's check what the HTTP headers are saying, because _they_ tell
the browser the byte stream encoding. The headers and your program's
encoding must match. So:
% wget -S -O - http://superhost.gr/
--2013-04-23 19:34:38-- http://superhost.gr/
Resolving superhost.gr (superhost.gr)... 82.211.30.133
Connecting to superhost.gr (superhost.gr)|82.211.30.133|:80... connected.
HTTP request sent, awaiting response...
HTTP/1.1 200 OK
Date: Tue, 23 Apr 2013 09:34:46 GMT
Server: Apache/2.2.24 (Unix) mod_ssl/2.2.24 OpenSSL/1.0.0-fips
mod_auth_passthrough/2.1 mod_bwlimited/1.4 FrontPage/5.0.2.2635
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html; charset=utf-8
Length: unspecified [text/html]
Saving to: ‘STDOUT’
--> -->
So, the Content-Type: header says: "text/html; charset=utf-8". So that's good.
So I've imported codecs and added this line:
sys.stdout = os.fdopen(1, 'w', encoding='utf-8')
under the setting of sys.stderr. If the cgi libraries run under
python 3 there is probably a cleaner way to do this but i don't know how.
This just opens UNIX file descriptor 1 (standard output) from scratch
for write ('w') using the 'utf-8' encoding.
And now your CGI script runs, ac
Re: Changing filenames from Greeklish => Greek (subprocess complain)
Chris can you please help me solve this problem? Why subprocess fails when it has to deal with a greek flename? and that an indirect call too -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Heisenbugs? (was: Re: PyWart: The problem with "print")
On Mon, Jun 3, 2013 at 2:34 PM, Dan Sommers wrote: > On Mon, 03 Jun 2013 13:37:27 +1000, Tim Delaney wrote: > >> With the increase in use of higher-level languages, these days >> Heisenbugs most often appear with multithreaded code that doesn't >> properly protect critical sections, but as you say, with lower-level >> languages uninitialised memory is a common source of them. > > Aside from an I/O caching bug directly affected by calling print or > somefile.write (where somefile is stdout), how else could I create a > Heisenbug in pure Python? If you have a @property, merely retrieving it could affect things. It shouldn't happen, but bugs can be anywhere. Basically, ANY Python code can trigger ANY Python code. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Changing filenames from Greeklish => Greek (subprocess complain)
On Mon, Jun 3, 2013 at 9:10 AM, Tim Delaney wrote: >> A programmer chooses his own clients, and you are the Atherton Wing to >> my Inara Serra. > > > I've just been watching this train wreck (so glad I didn't get involved at > the start) but I have to say - that's brilliant Chris. Thank you for > starting my week off so well. That went well. *sighs happily* ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Changing filenames from Greeklish => Greek (subprocess complain)
I did all the google searh i could, but iwht no luxk, this is no suexec issue. Why you say it is one? The other problem i had was 'suexec' related, not this one, this is a subprocess issue. -- http://mail.python.org/mailman/listinfo/python-list
Python Heisenbugs? (was: Re: PyWart: The problem with "print")
On Mon, 03 Jun 2013 13:37:27 +1000, Tim Delaney wrote: > With the increase in use of higher-level languages, these days > Heisenbugs most often appear with multithreaded code that doesn't > properly protect critical sections, but as you say, with lower-level > languages uninitialised memory is a common source of them. Aside from an I/O caching bug directly affected by calling print or somefile.write (where somefile is stdout), how else could I create a Heisenbug in pure Python? To bring this thread back around full circle: I suppose that if I had a local function called print, and decided that I needed some debugging output, I could be in for a surprise; or a local module called logging, and decided to use the logging module instead of calling print directly. -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWart: The problem with "print"
On Sun, 02 Jun 2013 23:23:42 -0400, Jason Swails wrote: > On Sun, Jun 2, 2013 at 11:10 PM, Dan Sommers > wrote: >> Ah, yes. The Heisenbug. ;-) > > Indeed. Being in the field of computational chemistry/physics, I was > almost happy to have found one just to say I was hunting a Heisenbug. > It seems to be a term geared more toward the physics-oriented > programming crowd. I'd been using the word Heisenbug for years with only a pop-culture clue as to what it meant. Many years later, I went to college, studied physics (and math), and had one self-study semester of computational physics on my way to my undergraduate degree. After a career in software development, including a few years in the financial industry, with lots of floating point economic models, I must say that it was very enlightening. >> They're much harder to see in the wild with Python. > > Yea, I've only run into Heisenbugs with Fortran or C/C++. Every time > I've seen one it's been due to an uninitialized variable somewhere -- > something valgrind is quite good at pinpointing ... Uninitialized variables and off-by-one pointer operations. Little can screw up a calculation like mistaking a stack frame link for a floating point number. :-) > ... (And yes, a good portion of our code is -still- in Fortran -- but > at least it's F90+ :). I am a huge proponent of using the right tool for the job. There is nothing wrong with some well-placed FORTRAN, as long as the PSF -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWart: The problem with "print"
On 3 June 2013 13:23, Jason Swails wrote: > Yea, I've only run into Heisenbugs with Fortran or C/C++. Every time I've > seen one it's been due to an uninitialized variable somewhere -- something > valgrind is quite good at pinpointing. (And yes, a good portion of our > code is -still- in Fortran -- but at least it's F90+ :). > With the increase in use of higher-level languages, these days Heisenbugs most often appear with multithreaded code that doesn't properly protect critical sections, but as you say, with lower-level languages uninitialised memory is a common source of them. I had a fun one once (in C++, but could have happened in any language) where a semaphore was being acquired twice on the one thread. There were 10 semaphore slots available, and very occasionally the timings would result in one of the threads deadlocking. Fortunately, by reducing to a single thread + single semaphore slot I was able to turn it from a Heisenbug to a 100% replicable bug. Tim Delaney -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWart: The problem with "print"
On Sun, Jun 2, 2013 at 11:10 PM, Dan Sommers wrote: > On Sun, 02 Jun 2013 20:16:21 -0400, Jason Swails wrote: > > > ... If you don't believe me, you've never hit a bug that 'magically' > > disappears when you add a debugging print statement ;-). > > Ah, yes. The Heisenbug. ;-) > Indeed. Being in the field of computational chemistry/physics, I was almost happy to have found one just to say I was hunting a Heisenbug. It seems to be a term geared more toward the physics-oriented programming crowd. > We used to run into those back in the days of C and assembly langua > > ge. > > They're much harder to see in the wild with Python. > > Yea, I've only run into Heisenbugs with Fortran or C/C++. Every time I've seen one it's been due to an uninitialized variable somewhere -- something valgrind is quite good at pinpointing. (And yes, a good portion of our code is -still- in Fortran -- but at least it's F90+ :). -- http://mail.python.org/mailman/listinfo/python-list
Re: Too many python installations. Should i remove them all and install the latest?
On Mon, Jun 3, 2013 at 12:30 PM, alex23 wrote: > On Jun 1, 10:24 am, Chris Angelico wrote: >> Hmm. What other MUD commands have obvious Unix equivalents? >> >> say --> echo >> emote --> python -c >> attack --> sudo rm -f > > who --> who > tell --> write > alias --> ln > look --> cat > go --> cd > teleport --> pushd/popd ? I don't use an explicit 'go' though, I usually just type 'n' to go north, or 'booth1' to go booth1. Unfortunately that doesn't translate well into a simple alias :) Hey, if you like MUDs, why not come play D&D with us? minstrelhall.com port 221 - always looking for new players! ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWart: The problem with "print"
On Sun, 02 Jun 2013 20:16:21 -0400, Jason Swails wrote: > ... If you don't believe me, you've never hit a bug that 'magically' > disappears when you add a debugging print statement ;-). Ah, yes. The Heisenbug. ;-) We used to run into those back in the days of C and assembly language. They're much harder to see in the wild with Python. -- http://mail.python.org/mailman/listinfo/python-list
Re: How to Begin Web Development with Python ?
On Jun 1, 11:23 pm, Giorgos Tzampanakis wrote: > Modulok suggested using ORM software. ORM should not really be needed if > you are aiming at scientific content for your application, you should > be fine with straight SQL (many consider ORM a hindrance rather than > help for any project [1], [2]). But if you do find the need for ORM > then SQLAlchemy is very good and is considered pretty much a de facto > standard in the Python world. SQLAlchemy isn't just an ORM, though. Even more compelling, to me, is its SQL Expression Language, which allows you to programmatically write SQL expressions in a cross-database compatible way. It makes it a lot easier to port your application to another database backend should it require it. I tend to start projects with a local instance of sqlite, for example, before migrating to PostGres/Oracle for production. -- http://mail.python.org/mailman/listinfo/python-list
Re: xsd:anyType parameter in suds!
On Jun 2, 12:56 pm, Tamer Higazi wrote: > The original sample is an application, where a "PHP Array" is being > passed for the remoted method. What is the same type in python to > accomplish the task?! In this case, you probably want to use a dict(). -- http://mail.python.org/mailman/listinfo/python-list
Re: Too many python installations. Should i remove them all and install the latest?
On Jun 1, 1:20 am, Νικόλαος Κούρας wrote: > Why so many pythons in my system. Because _you_ installed them. And we _know_ this because you've posted multiple threads relating to your problems with _your_ installations of Python 3. Even more entertainingly: > root@nikos [~]# which python3 > /root/.local/lib/python2.7/bin/python3 You seem to have installed python3 inside of a local copy of python2.7. Awesomely professional webhosting service you're providing here. > root@nikos [~]# python3 > Python 3.3.0 (default, Apr 6 2013, 01:53:31) > [GCC 4.4.7 20120313 (Red Hat 4.4.7-3)] on linux > Type "help", "copyright", "credits" or "license" for more information. > >>> exit() > > root@nikos [~]# python3.3 > Python 3.3.0 (default, Apr 6 2013, 01:53:31) > [GCC 4.4.7 20120313 (Red Hat 4.4.7-3)] on linux > Type "help", "copyright", "credits" or "license" for more information. > >>> exit() Did you _really_ need to post this? Was it to have us confirm they _are_ the same versions? > did i screwed up my remote VPS which i host 10 peoples webpages? STOP EXPERIMENTING ON YOUR PRODUCTION SERVER. You should have a test server that is a mirror of your production on which you can _safely_ flail around ignorantly without _costing your customers_ in lost time or data. They're sure as hell should _not_ be paying you to learn Python badly. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python #ifdef
On Mon, Jun 3, 2013 at 9:57 AM, Erik Max Francis wrote: > On 05/29/2013 08:05 AM, Chris Angelico wrote: >> >> It's not a bad tool. I used it as a sort of PHP preprocessor, because >> requirements at work had me wanting to have a source file defining a >> PHP class and having an autogenerated section in the middle of that >> class. PHP's 'include' directive doesn't work for that. Of course, had >> we been using a better language, that wouldn't have been an issue (and >> it stopped being an issue when we improved the design and stopped >> using that class system, too, though I retained the makefile >> directives about building .php.m4 -> .php files). But still, GNU M4 is >> >> a decent piece of technology. > > > Agreed. The terror that most people feel when hearing "m4" is because m4 > was associated with sendmail, not because m4 was inherently awful. It has > problems, but you'd only encounter them when doing something _very_ > abstract. Ah. I actually wasn't aware of m4's use with sendmail. I first met it as the aforementioned PHP preprocessor, simply by Googling for something along the lines of "generic preprocessor". First hit solved my problems. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Issue converting to string to integer.
On Mon, Jun 3, 2013 at 11:52 AM, Dan Sommers wrote:
> On Sun, 02 Jun 2013 18:12:33 -0700, Fdama wrote:
>
>> I combined the int conversion and the input on the same line, rather
>> than to have two different statements. But got an error message:
>
>> Traceback (most recent call last):
>> File "C:\Users\Faisal\Documents\python\pizza_slicer.py", line 23, in
>>
>> start=int(input("\nStart: "))
>> ValueError: invalid literal for int() with base 10: ''
>>
>> Could someone tell me why I got this error message?
>
> The difference is what used to happen in between the input and the
> conversion. In the first version, the "if" statement prevents the
> conversion from happening when there is no input. In the second
> version, though, python tries to do the conversion with no input, and
> fails.
You could combine them in, as long as you're okay with blank input and
input of '0' being folded to the same:
start = int(input("\nStart: ") or 0)
ChrisA
--
http://mail.python.org/mailman/listinfo/python-list
Re: Issue converting to string to integer.
On Jun 3, 11:12 am, Fdama wrote:
> I combined the int conversion and the input on the same line, rather than to
> have two different statements. But got an error message:
>
> Traceback (most recent call last):
> File "C:\Users\Faisal\Documents\python\pizza_slicer.py", line 23, in
>
> start=int(input("\nStart: "))
> ValueError: invalid literal for int() with base 10: ''
>
> Could someone tell me why I got this error message?
When you were presented the 'Start' prompt, you hit Enter, which
causes `input` to return an empty string. As it's passed directly
into `int`, which requires a valid string-representing-a-number, you
get the ValueError traceback, which shows you the failing input it
received: '' This doesn't happen in your original code, because your
condition `if start:` will fail on an empty string, and not try to
turn it into an int.
You don't want to wrap your `input` with an `int`. You want to test
the return result from `input` to ensure it can be coerced:
start = input("\nStart: "))
if start and start.isdigit():
start=int(start)
...
else:
start='' # set start to empty string so the while loop repeats
Here we check that all of the characters in the string `start` are
actually numbers before coercing. This is known as the "Look Before
You Leap" (LBYL) approach. Another approach is to catch the ValueError
exception:
start = input("\nStart: "))
try:
start = int(start)
except ValueError:
start = ''
if start:
This is known as "Easier to for Ask Forgiveness than
Permission" (EAFP). They both have their advantages. try/excepts tends
to be quicker if few exceptions are called, while an if/else will test
every time, although at this point it's not something you need to
overly concern yourself with. Go with whichever is easiest for you to
understand & extend.
--
http://mail.python.org/mailman/listinfo/python-list
Re: PyWart: The problem with "print"
On Mon, Jun 3, 2013 at 10:16 AM, Jason Swails wrote:
> Copy-and-pasting your timeit experiment on my machine yields different
> timings (Python 2.7):
>
import sys
timeit.timeit('debugprint("asdf")','def debugprint(*args):\n\tif not
DEBUG: return\n\tsys.stdout.write(*args)\nDEBUG=False',number=100)
> 0.15644001960754395
>
> which is ~150 ns/function call, versus ~1300 ns/function call. And there
> may be even more extreme examples, this is just one I was able to cook up
> quickly.
The exact time will of course vary enormously. My point still would
stand at 1300ns; it's still extremely low compared to many other
overheads.
> This is, I'm sad to say, where my alignment with RR ends. While I use
> prints in debugging all the time, it can also become a 'crutch', just like
> reliance on valgrind or gdb. If you don't believe me, you've never hit a
> bug that 'magically' disappears when you add a debugging print statement
> ;-).
Yes, I've had situations like that. They are, however, EXTREMELY rare
compared to the times when a bug magically becomes shallow when you
add a debugging print!
> The easiest way to eliminate these 'dead' calls is to simply comment-out the
> print call, but I would be quite upset if the interpreter tried to outsmart
> me and do it automagically as RR seems to be suggesting. And if you're
> actually debugging, then you typically only add a few targeted print
> statements -- not too hard to comment-out. If it is, and you're really that
> lazy, then by all means add a new, greppable function call and use a sed
> command to comment those lines out for you.
Yes. I also have high hopes for some of the cool AST manipulation
that's being developed at the moment; it should be relatively easy to
have a simple flag that controls whether debugprint (btw, I'd shorten
the name) represents code or no-code.
But consider all the other things that you probably do in your Python
programs. Every time you reference something as "module.name", you
require a lookup into the current module's namespace to find the
module name, then into that module's namespace to find the object you
want. Snagging names as locals is a common optimization, but is far
from universally applied. Why? Because the readability cost just isn't
worth it. We use Python because it is "fast enough", not because it
lets us squeeze every CPU cycle out of the code.
That said, I can often smoke Python with Pike, thanks to a few rather
cool optimizations (including looking up module names at compile time,
which reduces what I just said above). Maybe in the future some of
these optimizations will be done, I don't know. But for 99.9% of
Python scripts, you will *never* see the performance difference.
ChrisA
--
http://mail.python.org/mailman/listinfo/python-list
Re: Issue converting to string to integer.
On Sun, 02 Jun 2013 18:12:33 -0700, Fdama wrote:
> I combined the int conversion and the input on the same line, rather
> than to have two different statements. But got an error message:
> Traceback (most recent call last):
> File "C:\Users\Faisal\Documents\python\pizza_slicer.py", line 23, in
>
> start=int(input("\nStart: "))
> ValueError: invalid literal for int() with base 10: ''
>
> Could someone tell me why I got this error message?
The difference is what used to happen in between the input and the
conversion. In the first version, the "if" statement prevents the
conversion from happening when there is no input. In the second
version, though, python tries to do the conversion with no input, and
fails.
Dan
--
http://mail.python.org/mailman/listinfo/python-list
Re: Please help with Threading
On Saturday, 18 May 2013 10:58:13 UTC+2, Jurgens de Bruin wrote:
> This is my first script where I want to use the python threading module. I
> have a large dataset which is a list of dict this can be as much as 200
> dictionaries in the list. The final goal is a histogram for each dict 16
> histograms on a page ( 4x4 ) - this already works.
>
> What I currently do is a create a nested list [ [ {} ], [ {} ] ] each inner
> list contains 16 dictionaries, thus each inner list is a single page of 16
> histograms. Iterating over the outer-list and creating the graphs takes to
> long. So I would like multiple inner-list to be processes simultaneously and
> creating the graphs in "parallel".
>
> I am trying to use the python threading for this. I create 4 threads loop
> over the outer-list and send a inner-list to the thread. This seems to work
> if my nested lists only contains 2 elements - thus less elements than
> threads. Currently the scripts runs and then seems to get hung up. I monitor
> the resource on my mac and python starts off good using 80% and when the
> 4-thread is created the CPU usages drops to 0%.
>
>
>
> My thread creating is based on the following :
> http://www.tutorialspoint.com/python/python_multithreading.htm
>
>
>
> Any help would be create!!!
Thanks to all for the discussion/comments on threading, although I have not
been commenting I have been following. I have learnt a lot and I am still
reading up on everything mentioned. Thanks again
Will see how I am going to solve my senario.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Issue converting to string to integer.
On Sun, Jun 2, 2013 at 6:12 PM, Fdama wrote:
> Hi,
>
> I was following an exercise in a book when I edited the code and came
> across something I did not get. Here is the relevant part of the code that
> works:
>
> start=None #initialise
> while start !="":
> start=input("\nStart: ")
>
> if start:
> start=int(start)
> finish=int(input("Finish: "))
>
> print("word[",start,":",finish,"] is", word[start:finish])
>
> I then changed the code to this:
>
> start=None #initialise
> while start !="":
> start=int(input("\nStart: "))
>
> if start:
>
> finish=int(input("Finish: "))
>
> print("word[",start,":",finish,"] is", word[start:finish])
>
> I combined the int conversion and the input on the same line, rather than
> to have two different statements. But got an error message:
>
> Traceback (most recent call last):
> File "C:\Users\Faisal\Documents\python\pizza_slicer.py", line 23, in
>
> start=int(input("\nStart: "))
> ValueError: invalid literal for int() with base 10: ''
>
Converting an empty string to base 10 doesn't fly, so if you hit a blank
line on the input(), you get a bad conversion. In the first version,
you're only converting to base 10 if the string is non-empty. In the
second, you're attempting to convert irrespective.
BTW, I'm partial to:
if not start:
continue
...but that's a stylistic thing.
--
http://mail.python.org/mailman/listinfo/python-list
Issue converting to string to integer.
Hi,
I was following an exercise in a book when I edited the code and came across
something I did not get. Here is the relevant part of the code that works:
start=None #initialise
while start !="":
start=input("\nStart: ")
if start:
start=int(start)
finish=int(input("Finish: "))
print("word[",start,":",finish,"] is", word[start:finish])
I then changed the code to this:
start=None #initialise
while start !="":
start=int(input("\nStart: "))
if start:
finish=int(input("Finish: "))
print("word[",start,":",finish,"] is", word[start:finish])
I combined the int conversion and the input on the same line, rather than to
have two different statements. But got an error message:
Traceback (most recent call last):
File "C:\Users\Faisal\Documents\python\pizza_slicer.py", line 23, in
start=int(input("\nStart: "))
ValueError: invalid literal for int() with base 10: ''
Could someone tell me why I got this error message?
Thanks
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python #ifdef
> The terror that most people feel when hearing "m4" is because m4 was associated with sendmail, not because m4 was inherently awful. In fact, m4 made sendmail configs easier to maintain. Skip -- http://mail.python.org/mailman/listinfo/python-list
Re: Python #ifdef
In article , Erik Max Francis wrote: > On 05/29/2013 08:05 AM, Chris Angelico wrote: > > It's not a bad tool. I used it as a sort of PHP preprocessor, because > > requirements at work had me wanting to have a source file defining a > > PHP class and having an autogenerated section in the middle of that > > class. PHP's 'include' directive doesn't work for that. Of course, had > > we been using a better language, that wouldn't have been an issue (and > > it stopped being an issue when we improved the design and stopped > > using that class system, too, though I retained the makefile > > directives about building .php.m4 -> .php files). But still, GNU M4 is > > a decent piece of technology. > > Agreed. The terror that most people feel when hearing "m4" is because > m4 was associated with sendmail Aggghhh. You had to go and dredge up those bad memories? I hadn't thought about sendmail config files in years. I'll probably never be able to get to sleep tonight. -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWart: The problem with "print"
On Sun, Jun 2, 2013 at 1:20 PM, Chris Angelico wrote:
>
> Hmm. Could be costly. Hey, you know, Python has something for testing that.
>
> >>> timeit.timeit('debugprint("asdf")','def debugprint(*args):\n\tif not
> DEBUG: return\n\tprint(*args)\nDEBUG=False',number=100)
> 0.5838018519113444
>
> That's roughly half a second for a million calls to debugprint().
> That's a 580ns cost per call. Rather than fiddle with the language,
> I'd rather just take this cost. Oh, and there's another way, too: If
> you make the DEBUG flag have effect only on startup, you could write
> your module thus:
>
This is a slightly contrived demonstration... The time lost in a function
call is not just the time it takes to execute that function. If it
consistently increases the frequency of cache misses then the cost is much
greater -- possibly by orders of magnitude if the application is truly
bound by the bandwidth of the memory bus and the CPU pipeline is almost
always saturated.
I'm actually with RR in terms of eliminating the overhead involved with
'dead' function calls, since there are instances when optimizing in Python
is desirable. I actually recently adjusted one of my own scripts to
eliminate branching and improve data layout to achieve a 1000-fold
improvement in efficiency (~45 minutes to 0.42 s. for one example) --- all
in pure Python. The first approach was unacceptable, the second is fine.
For comparison, if I add a 'deactivated' debugprint call into the inner
loop (executed 243K times in this particular test), then the time of the
double-loop step that I optimized takes 0.73 seconds (nearly doubling the
duration of the whole step). The whole program is too large to post here,
but the relevant code portion is shown below:
i = 0
begin = time.time()
for mol in owner:
for atm in mol:
blankfunc("Print i %d" % i)
new_atoms[i] = self.atom_list[atm]
i += 1
self.atom_list = new_atoms
print "Done in %f seconds." % (time.time() - begin)
from another module:
DEBUG = False
[snip]
def blankfunc(instring):
if DEBUG:
print instring
Also, you're often not passing a constant literal to the debug print --
you're doing some type of string formatting or substitution if you're
really inspecting the value of a particular variable, and this also takes
time. In the test I gave the timings for above, I passed a string the
counter substituted to the 'dead' debug function. Copy-and-pasting your
timeit experiment on my machine yields different timings (Python 2.7):
>>> import sys
>>> timeit.timeit('debugprint("asdf")','def debugprint(*args):\n\tif not
DEBUG: return\n\tsys.stdout.write(*args)\nDEBUG=False',number=100)
0.15644001960754395
which is ~150 ns/function call, versus ~1300 ns/function call. And there
may be even more extreme examples, this is just one I was able to cook up
quickly.
This is, I'm sad to say, where my alignment with RR ends. While I use
prints in debugging all the time, it can also become a 'crutch', just like
reliance on valgrind or gdb. If you don't believe me, you've never hit a
bug that 'magically' disappears when you add a debugging print statement
;-).
The easiest way to eliminate these 'dead' calls is to simply comment-out
the print call, but I would be quite upset if the interpreter tried to
outsmart me and do it automagically as RR seems to be suggesting. And if
you're actually debugging, then you typically only add a few targeted print
statements -- not too hard to comment-out. If it is, and you're really
that lazy, then by all means add a new, greppable function call and use a
sed command to comment those lines out for you.
BTW: *you* in the above message refers to a generic person -- none of my
comments were aimed at anybody in particular
All the best,
Jason
P.S. All that said, I would agree with ChrisA's suggestion that the
overhead is negligible is most cases...
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python #ifdef
On 05/29/2013 08:05 AM, Chris Angelico wrote: It's not a bad tool. I used it as a sort of PHP preprocessor, because requirements at work had me wanting to have a source file defining a PHP class and having an autogenerated section in the middle of that class. PHP's 'include' directive doesn't work for that. Of course, had we been using a better language, that wouldn't have been an issue (and it stopped being an issue when we improved the design and stopped using that class system, too, though I retained the makefile directives about building .php.m4 -> .php files). But still, GNU M4 is a decent piece of technology. Agreed. The terror that most people feel when hearing "m4" is because m4 was associated with sendmail, not because m4 was inherently awful. It has problems, but you'd only encounter them when doing something _very_ abstract. -- Erik Max Francis && m...@alcyone.com && http://www.alcyone.com/max/ San Jose, CA, USA && 37 18 N 121 57 W && AIM/Y!M/Jabber erikmaxfrancis Substance is one of the greatest of our illusions. -- Sir Arthur Eddington -- http://mail.python.org/mailman/listinfo/python-list
Re: Changing filenames from Greeklish => Greek (subprocess complain)
On 3 June 2013 09:10, Tim Delaney wrote: > A programmer chooses his own clients, and you are the Atherton Wing to >> my Inara Serra. >> > > I've just been watching this train wreck (so glad I didn't get involved at > the start) but I have to say - that's brilliant Chris. Thank you for > starting my week off so well. > And I just realised I missed a shiny opportunity to wrangle "train job" in there ... Tim Delaney -- http://mail.python.org/mailman/listinfo/python-list
Re: Changing filenames from Greeklish => Greek (subprocess complain)
> > A programmer chooses his own clients, and you are the Atherton Wing to > my Inara Serra. > I've just been watching this train wreck (so glad I didn't get involved at the start) but I have to say - that's brilliant Chris. Thank you for starting my week off so well. Tim Delaney -- http://mail.python.org/mailman/listinfo/python-list
Re: Output from to_bytes
On 6/2/2013 3:09 PM, Mok-Kong Shen wrote: Am 28.05.2013 17:35, schrieb Grant Edwards: On 2013-05-26, Mok-Kong Shen wrote: I don't understand why with the code: for k in range(8,12,1): print(k.to_bytes(2,byteorder='big')) one gets the following output: b'\x00\x08' b'\x00\t' b'\x00\n' b'\x00\x0b' I mean the 2nd and 3rd should be b'\x00\x09' and b'x00\x0a'. Anyway, how could I get the output in the forms I want? Well, it would help if you told us what output form you want. As I stated, I like the 2nd and 3rd be b'\x00\x09' and b'\x00\x0a' respectively. This is what would expeacted to be in a hexadecimal notation IMHO in other PLs. When you print bytes, Python doesn't use "hexadecimal notation." It prints a Python bytes literal. That literal will use printable characters like 'Q', or hex escapes like '\x00', or other escapes like '\n', depending on the character. If you want hex output, you have to create it yourself, for example with the binascii module. --Ned. M. K. Shen -- http://mail.python.org/mailman/listinfo/python-list
Re: Arp cache poisoning using scapy
On Sunday, June 2, 2013 11:19:46 AM UTC-7, bakbak...@gmail.com wrote:
> I am trying to get the arp cache poisoning working with scapy and python but
> having problems
>
>
>
> The python script itself is very simple:
>
> root@ubuntu:/home/joker/Downloads/scapy-2.2.0/scripts# cat arp_poison.py
>
> #!/usr/bin/env python
>
>
>
> import sys
>
>
>
> from scapy.all import *
>
>
>
> arpcachepoison("00:22:fa:98:5e:04", "192.168.1.131")
>
>
>
> The error I am getting is illegal IP address. How do I fix it?
>
>
>
>
>
>
>
> root@ubuntu:/home/joker/Downloads/scapy-2.2.0/scripts# python arp_poison.py
>
> WARNING: No route found for IPv6 destination :: (no default route?)
>
> Traceback (most recent call last):
>
> File "arp_poison.py", line 7, in
>
> arpcachepoison("00:22:fa:98:5e:04", "192.168.1.131")
>
> File "/usr/lib/python2.7/dist-packages/scapy/layers/l2.py", line 440, in
> arpcachepoison
>
> tmac = getmacbyip(target)
>
> File "/usr/lib/python2.7/dist-packages/scapy/layers/l2.py", line 53, in
> getmacbyip
>
> tmp = map(ord, inet_aton(ip))
>
> socket.error: illegal IP address string passed to inet_aton
>
> root@ubuntu:/home/joker/Downloads/scapy-2.2.0/scripts#
>
> root@ubuntu:/home/joker/Downloads/scapy-2.2.0/scripts#
--
http://mail.python.org/mailman/listinfo/python-list
Re: Arp cache poisoning using scapy
On Sunday, June 2, 2013 11:19:46 AM UTC-7, bakbak...@gmail.com wrote:
> I am trying to get the arp cache poisoning working with scapy and python but
> having problems
>
>
>
> The python script itself is very simple:
>
> root@ubuntu:/home/joker/Downloads/scapy-2.2.0/scripts# cat arp_poison.py
>
> #!/usr/bin/env python
>
>
>
> import sys
>
>
>
> from scapy.all import *
>
>
>
> arpcachepoison("00:22:fa:98:5e:04", "192.168.1.131")
>
>
>
> The error I am getting is illegal IP address. How do I fix it?
>
>
>
>
>
>
>
> root@ubuntu:/home/joker/Downloads/scapy-2.2.0/scripts# python arp_poison.py
>
> WARNING: No route found for IPv6 destination :: (no default route?)
>
> Traceback (most recent call last):
>
> File "arp_poison.py", line 7, in
>
> arpcachepoison("00:22:fa:98:5e:04", "192.168.1.131")
>
> File "/usr/lib/python2.7/dist-packages/scapy/layers/l2.py", line 440, in
> arpcachepoison
>
> tmac = getmacbyip(target)
>
> File "/usr/lib/python2.7/dist-packages/scapy/layers/l2.py", line 53, in
> getmacbyip
>
> tmp = map(ord, inet_aton(ip))
>
> socket.error: illegal IP address string passed to inet_aton
>
> root@ubuntu:/home/joker/Downloads/scapy-2.2.0/scripts#
>
> root@ubuntu:/home/joker/Downloads/scapy-2.2.0/scripts#
This works. Although it shouldn't.
The documentation should be changed to reflect this. As per document:
arpcachepoison
arpcachepoison(target,victim,interval=60)
Poison target’s cache with (your MAC,victim’s IP)
It makes more sense to assign a MAC to the vitim ip to falsly claim and poison
the network so ideally the documentation is correct the the command does not
work as such. However the command with 2 IPs does the thing correctly. So
change documentation? How do one go about it?
Also all the items in () need to have "" or it gives syntax error. Is that how
it should work?
--
http://mail.python.org/mailman/listinfo/python-list
Re: Changing filenames from Greeklish => Greek (subprocess complain)
On Mon, Jun 3, 2013 at 5:51 AM, wrote: > Now, is anyone willing to help me on this please? > I also accept hints on how to solve this! Hints I can do. Here, I've set up a scavenger hunt for you. You'll go to a number of web sites that I nominate, type in keywords, and hit enter. The first web site is Google: www.google.com Type in: suexec The second web site is DuckDuckGo: www.duckduckgo.com Type in: paid apache technical support The third web site is ESR Question (not its official name): http://www.catb.org/esr/faqs/smart-questions.html Unlike the other two, this one is so smart (it says it right in the URL!) that it doesn't need you to type anything in! Read through these pages. You will find clues scattered throughout; some of them will be solved by typing them into one of the first two web sites. When you complete the scavenger hunt, you will find your prize. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWart: The problem with "print"
On 6/2/2013 2:18 PM, Rick Johnson wrote: On Sunday, June 2, 2013 12:49:02 PM UTC-5, Dan Sommers wrote: On Mon, 03 Jun 2013 03:20:52 +1000, Chris Angelico wrote: On Mon, Jun 3, 2013 at 3:04 AM, Rick Johnson [...] Or use the logging module. It's easy to get going quickly (just call logging.basicConfig at startup time), and with a little care and feeding, you can control the output in more ways than can fit into the margin. Oh, yeah, I'm sure it introduces some overhead. So does everything else. I hate log files, at least during development or testing. I prefer to debug on the command line or using my IDE. Log files are for release time, not development. Rick, you should give the logging module a try. The default configuration from basicConfig is that the messages all go to stderr, so no log files to deal with. And it's configurable in the ways you want, plus a lot more. --Ned. -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWart: The problem with "print"
On Mon, Jun 3, 2013 at 4:58 AM, Steven D'Aprano
wrote:
>> I've found that many subtle bugs are caused by not limiting the inputs
>> to sane values (or types). And with Python's duct typing
>
> Nothing worse than having pythons roaming through your ducts, eating your
> ducks.
Steven, you misunderstand. It's more about using your ducts to type
code. Have you seen the Mythbusters episode where they're trying to
enter a building surreptitiously? ("Crimes and Mythdemeanors 1", I
think, if you want to look it up.) At one point, we can CLEARLY hear
one of the hosts, moving along a duct, *typing*. We can hear the
click-click-click of giant keys.
Hah. Knew I could trust Youtube. http://www.youtube.com/watch?v=5LovGVrrIuk
ChrisA
--
http://mail.python.org/mailman/listinfo/python-list
Re: PyWart: The problem with "print"
On Mon, Jun 3, 2013 at 4:09 AM, Rick Johnson
wrote:
> On Jun 2, 12:20 pm, Chris Angelico wrote:
>> On Mon, Jun 3, 2013 at 3:04 AM, Rick Johnson
>> > * Woefully inadequate because: Switching on or off the debug
>> >messages is only valid in the current module that the
>> >function was imported. What if you want to kill all
>> >debugprint messages EVERYWHERE? Do you really want to edit
>> >"debug = BOOLEAN" in every source file OR do something
>> >stupid like import debugprint and edit the DEBUG constant
>> >OR even dumber, edit the debugprint source code? GAWD NO!
>> Easy fix to this one. Instead of copying and pasting debugprint into
>> everything, have it in a module and import it everywhere. Then the
>> debug flag will be common to them all.
>
> Ignoring the fact that you have "import everywhere", what if you want
> to stop ALL debug messages? If you "import everywhere" to get them,
> you then have to "edit everywhere" to stop them.
Example:
## debugprint.py
DEBUG = True
def debugprint(*a,**kw):
if DEBUG:
return print(*a,**kw)
## every other module
from debugprint import debugprint
debugprint("I got imported!")
def foo():
debugprint("I got foo'd!")
See how many places you need to edit to change the DEBUG flag? You can
even do it at run time with this version of the code:
## toggle debugging
import debugprint
debugprint.DEBUG = not debugprint.DEBUG
And, as several others have pointed out, this is kinda sorta what the
logging module does, only it does it better. Same method; you import
the same module everywhere. It is THE SAME module.
>> That's roughly half a second for a million calls to debugprint().
>> That's a 580ns cost per call. Rather than fiddle with the language,
>> I'd rather just take this cost.
>
> I never purposely inject ANY superfluous cycles in my code except in
> the case of testing or development. To me it's about professionalism.
Why do you use Python? Clearly the only professional option is to use
raw assembler. Or possibly you could justify C on the grounds of
portability.
> Let's consider a thought exercise shall we?
>
> Imagine your an auto mechanic. You customer brings in his
> car and asks you to make some repairs. You make the
> repairs but you also adjust the air/fuel ratio to run
> "rich" (meaning the vehicle will get less MPG). Do you
> still pat yourself on the back and consider you've done a
> professional job?
>
> I would not! However, you're doing the same thing as the mechanic when
> your code executes superflouos calls and burns cycles for no other
> reason than pure laziness. CPU's are not immortal you know, they have
> a lifetime. Maybe you don't care about destroying someone's CPU,
> however, i do!
Better analogy: When you build a car, you incorporate a whole bunch of
gauges and indicators. They clutter things up, and they're extra
weight to carry; wouldn't the car get more MPG (side point: can I have
my car get more OGG instead? I like open formats) if you omit them?
> I just wonder how many of your "creations" (aka: monstrosities!) are
> burning cycles this very minute!
Every one that's written in a high level language. So that's Yosemite,
Minstrel Hall, Tisroc, KokoD, RapidSend/RapidRecv, and Vizier. And
that's just the ones that I've personally created and that I *know*
are currently running (and that I can think of off-hand). They're
wasting CPU cycles dealing with stuff that I, the programmer, now
don't have to. Now let's see. According to my server, right now, load
average is 0.21 - of a single-core Intel processor that was mid-range
back in 2009. And that's somewhat higher-than-normal load, caused by
some sort of usage spike a few minutes ago (and is dropping);
normally, load average is below 0.10.
At what point would it be worth my effort to rewrite all that code to
eliminate waste? Considering that I could build a new server for a few
hundred (let's say $1000 to be generous, though the exact price will
depend on where you are), or rent one in a top-quality data center for
$40-$55/month and not have to pay for electricity or internet, any
rewrite would need to take less than two days of my time to be
worthwhile. Let 'em burn cycles; we can always get more.
>> So you can eliminate part of the cost there, if it matters to you. If
>> a half-microsecond cost is going to be significant to you, you
>> probably should be looking at improving other areas, maybe using
>> ctypes/cython, or possibly playing with the new preprocessor tricks
>> that have been being discussed recently. There's really no need to
>> change the language to solve one specific instance of this "problem".
>
> That's like suggesting to the poor fella who's MPG is suffering
> (because of your incompetent adjustments!) to buy fuel additives to
> compensate for the loss of MPG. Why should he incur costs because you
> are incompetent?
He's welcome to push a wheelbarrow if he doesn't want the overhead of
a car. The car offers convenience, b
Re: How to get an integer from a sequence of bytes
On Mon, Jun 3, 2013 at 5:25 AM, Mok-Kong Shen wrote: > b'7' is the byte with the character 7 in a certain code, so that's > ok. In other PLs one assigns an int to a byte, with that int in either > decimal notation or hexadecimal notation, or else one assigns a > character to it, in which case it gets the value of the character > in a certain code. What I don't yet understand is why Python is > apprently different from other PLs in that point in not allowing direct > coersion of a byte to an int. It does. Just subscript it: >>> b'7'[0] 55 ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Changing filenames from Greeklish => Greek (subprocess complain)
Τη Κυριακή, 2 Ιουνίου 2013 10:44:05 μ.μ. UTC+3, ο χρήστης Carlos Nepomuceno έγραψε: > Hey guys! Come on!!! > Repeat with me: "Googsfraba!" You are not and Jack Nicholson and this is not an Anger Management lesson (which was a great movie btw). I'am the one that i should chant that mantra because instead of receiving helpfull replies i get that kind of responses. Now, is anyone willing to help me on this please? I also accept hints on how to solve this! -- http://mail.python.org/mailman/listinfo/python-list
RE: Changing filenames from Greeklish => Greek (subprocess complain)
Hey guys! Come on!!! Repeat with me: "Googsfraba!" http://www.youtube.com/watch?v=Fscuv4PIjws lol > To: python-list@python.org > From: breamore...@yahoo.co.uk > Subject: Re: Changing filenames from Greeklish => Greek (subprocess complain) > Date: Sun, 2 Jun 2013 16:24:10 +0100 > > On 02/06/2013 16:04, Νικόλαος Κούρας wrote: >> Τη Κυριακή, 2 Ιουνίου 2013 5:51:31 μ.μ. UTC+3, ο χρήστης Mark Lawrence >> έγραψε: >> >>> You've obviously arrived very late at the party. >> >> Apart from the "funny" commenting, can you for once contribute towards to an >> actual solution or this is the best you can do to prove yourself smart in >> here by talking down on me? >> > > The only thing I'll contribute is that if you're looking to run a > commercial venture, you wouldn't be the last on my list for services, > you'd never get on it. > > Further I'll point out that you never give any indication at all of ever > doing any research before you ask a question. You simply fire off email > after email in the hope that you'll get a response. Luckily for you a > substantial number of people have come to your rescue. Unfortunately > for you, you've exhausted the patience of a number who might well have > been extremely helpful *IF* you'd put in a little effort. That is just > too much to ask of course. > > -- > "Steve is going for the pink ball - and for those of you who are > watching in black and white, the pink is next to the green." Snooker > commentator 'Whispering' Ted Lowe. > > Mark Lawrence > > -- > http://mail.python.org/mailman/listinfo/python-list > -- http://mail.python.org/mailman/listinfo/python-list
Re: How to get an integer from a sequence of bytes
Am 30.05.2013 21:22, schrieb Ned Batchelder: On 5/30/2013 2:26 PM, Mok-Kong Shen wrote: Am 27.05.2013 17:30, schrieb Ned Batchelder: On 5/27/2013 10:45 AM, Mok-Kong Shen wrote: From an int one can use to_bytes to get its individual bytes, but how can one reconstruct the int from the sequence of bytes? The next thing in the docs after int.to_bytes is int.from_bytes: http://docs.python.org/3.3/library/stdtypes.html#int.from_bytes I am sorry to have overlooked that. But one thing I yet wonder is why there is no direct possibilty of converting a byte to an int in [0,255], i.e. with a constrct int(b), where b is a byte. Presumably you want this to work: >>> int(b'\x03') 3 But you also want this to work: >>> int(b'7') 7 These two interpretations are incompatible. If b'\x03' becomes 3, then shouldn't b'\x37' become 55? But b'\x37' is b'7', and you want that to be 7. b'7' is the byte with the character 7 in a certain code, so that's ok. In other PLs one assigns an int to a byte, with that int in either decimal notation or hexadecimal notation, or else one assigns a character to it, in which case it gets the value of the character in a certain code. What I don't yet understand is why Python is apprently different from other PLs in that point in not allowing direct coersion of a byte to an int. M. K. Shen -- http://mail.python.org/mailman/listinfo/python-list
Re: Arp cache poisoning using scapy
On Sun, Jun 2, 2013 at 11:19 AM, wrote:
>
> I am trying to get the arp cache poisoning working with scapy and python
> but having problems
>
> The python script itself is very simple:
> root@ubuntu:/home/joker/Downloads/scapy-2.2.0/scripts# cat arp_poison.py
> #!/usr/bin/env python
>
> import sys
>
> from scapy.all import *
>
> arpcachepoison("00:22:fa:98:5e:04", "192.168.1.131")
>
> The error I am getting is illegal IP address. How do I fix it?
>
It looks to me like arpcachepoison wants two IP's, not a MAC and an IP.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Output from to_bytes
Am 28.05.2013 17:35, schrieb Grant Edwards: On 2013-05-26, Mok-Kong Shen wrote: I don't understand why with the code: for k in range(8,12,1): print(k.to_bytes(2,byteorder='big')) one gets the following output: b'\x00\x08' b'\x00\t' b'\x00\n' b'\x00\x0b' I mean the 2nd and 3rd should be b'\x00\x09' and b'x00\x0a'. Anyway, how could I get the output in the forms I want? Well, it would help if you told us what output form you want. As I stated, I like the 2nd and 3rd be b'\x00\x09' and b'\x00\x0a' respectively. This is what would expeacted to be in a hexadecimal notation IMHO in other PLs. M. K. Shen -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWart: The problem with "print"
On Sun, 02 Jun 2013 11:09:12 -0700, Rick Johnson wrote: > Maybe you don't care about destroying someone's CPU, however, i do! And yet here you are, destroying millions of people's CPUs by sending them email or usenet messages filled with garbage. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWart: The problem with "print"
On Sun, 02 Jun 2013 10:04:00 -0700, Rick Johnson wrote:
> Many
> languages provide a function, method, or statement by which users can
> write easily to stdout, and Python is no exception with it's own "print"
> function. However, whilst writing to stdout via "print" is slightly less
> verbose than calling the "write" method of "sys.stdout", we don't really
> gain much from this function except a few keystrokes... is this ALL
> print should be? A mere syntactical sugar?
Perhaps you should read the docs before asking rhetorical questions,
because the actual answer is, No, print is not mere syntactical sugar
saving a few keystrokes.
Help on built-in function print in module builtins:
print(...)
print(value, ..., sep=' ', end='\n', file=sys.stdout, flush=False)
Prints the values to a stream, or to sys.stdout by default.
Optional keyword arguments:
file: a file-like object (stream); defaults to the current
sys.stdout.
sep: string inserted between values, default a space.
end: string appended after the last value, default a newline.
flush: whether to forcibly flush the stream.
Still not powerful enough for you? Easily fixed:
import builtins
# The higher the verbosity, the more messages are printed.
verbosity = 2
def print(*args, level=1, **kwargs):
if level >= verbosity:
builtins.print(*args, **kwargs)
print("debug message", level=4) # Only prints if verbosity >= 4
print("info message", level=3)
print("warning message", level=2)
print("critical message", level=1) # Only prints if verbosity >= 1
Trivial enough to embed in each module that needs it, in which case each
module can have its own verbosity global variable. Or you can put it in a
helper module, with a single, application-wide global variable, and use
it like this:
import verbose_print
print = verbose_print.print
verbose_print.verbosity = 3
print("some message", level=4)
Of course, in practice you would set the verbosity according to a command
line switch, or an environment variable, or a config file, and not hard
code it in your source code.
> I've found that many subtle bugs are caused by not limiting the inputs
> to sane values (or types). And with Python's duct typing
Nothing worse than having pythons roaming through your ducts, eating your
ducks.
> and implicit
> casting to Boolean, you end up with all sorts of misleading things
> happening! Maybe you're testing for truth values and get a string
> instead; which screws everything up!!!
Only if you're a lousy programmer who doesn't understand Python's truth
model.
> A "wise programmer" may think he's solved the problem by writing a
> function called "debugprint" that looks like this:
>
> def debugprint(*args):
> if DEBUG == True:
> print(*args)
No no no, that's not how you do it. It should be:
if DEBUG == True == True:
Wait, no, I got that wrong. It should be:
if DEBUG == True == True == True:
Hang on, I've nearly got it!
if DEBUG == True == True == True == True:
Or, you could program like a professional, and say:
if DEBUG:
By the way, why is DEBUG a constant? Doesn't that defeat the purpose?
> However that solution is at best woefully inadequate and at worse a
> cycle burner!
Certainly you don't want to be burning cycles. Imagine the pollution from
the burning rubber tyres!
> * Woefully inadequate because: Switching on or off the debug
>messages is only valid in the current module that the function was
>imported. What if you want to kill all debugprint messages
>EVERYWHERE?
You start by learning how Python works, and not making woefully incorrect
assumptions.
>Do you really want to edit "debug = BOOLEAN" in every
>source file
Python does not work that way.
>OR do something stupid like import debugprint and edit
>the DEBUG constant
Heaven forbid that people do something that actually works the way Python
is designed to work.
>OR even dumber, edit the debugprint source code?
>GAWD NO!
>
> * But even if you are willing to cope with all the "switch-
>on-and-off" nonsense, are you willing to have you code slowed by
>numerous calls to a dead function containing a comparison that will
>always be false?
And of course you have profiled your application, and determined that the
bottleneck in performance is the calls to debugprint, because otherwise
you are wasting your time and ours with premature optimization.
Life is hard. Sometimes you have to choose between performance and
debugging.
> This
> realization has brought me to the conclusion that Python (and other
> languages) need a "scoped print function". What is a "scoped print
> function" anyway? Well what i am proposing is that Python include the
> following "debug switches" in the language:
>
> --
>Switch: "__GLOBALDEBUG__"
> --
> Global switching allows a programmer to
Re: Changing filenames from Greeklish => Greek (subprocess complain)
Τη Κυριακή, 2 Ιουνίου 2013 8:21:46 μ.μ. UTC+3, ο χρήστης Chris Angelico έγραψε: > Or you could do a quick web search, like we keep telling you to do for > other things. I'm pretty sure Google is familiar with both those > names, and will point you to a mighty fine shindig. I see, nice one! :) I though ti was somehtign you invented yourself :) Now, as yo my initial question, can you suggest anything please? I dont know what else to try. The whole subprocess fails when it has to deal with a greek lettered filename. I just dont get it... I didn't ask for metrites.py to open via subprocess the greek filename, i just told metrites.py to call files.py which in turn tries to open that greek filename. Thats indirectly call... -- http://mail.python.org/mailman/listinfo/python-list
Arp cache poisoning using scapy
I am trying to get the arp cache poisoning working with scapy and python but
having problems
The python script itself is very simple:
root@ubuntu:/home/joker/Downloads/scapy-2.2.0/scripts# cat arp_poison.py
#!/usr/bin/env python
import sys
from scapy.all import *
arpcachepoison("00:22:fa:98:5e:04", "192.168.1.131")
The error I am getting is illegal IP address. How do I fix it?
root@ubuntu:/home/joker/Downloads/scapy-2.2.0/scripts# python arp_poison.py
WARNING: No route found for IPv6 destination :: (no default route?)
Traceback (most recent call last):
File "arp_poison.py", line 7, in
arpcachepoison("00:22:fa:98:5e:04", "192.168.1.131")
File "/usr/lib/python2.7/dist-packages/scapy/layers/l2.py", line 440, in
arpcachepoison
tmac = getmacbyip(target)
File "/usr/lib/python2.7/dist-packages/scapy/layers/l2.py", line 53, in
getmacbyip
tmp = map(ord, inet_aton(ip))
socket.error: illegal IP address string passed to inet_aton
root@ubuntu:/home/joker/Downloads/scapy-2.2.0/scripts#
root@ubuntu:/home/joker/Downloads/scapy-2.2.0/scripts#
--
http://mail.python.org/mailman/listinfo/python-list
Re: PyWart: The problem with "print"
On Sunday, June 2, 2013 12:49:02 PM UTC-5, Dan Sommers wrote: > On Mon, 03 Jun 2013 03:20:52 +1000, Chris Angelico wrote: > > On Mon, Jun 3, 2013 at 3:04 AM, Rick Johnson > [...] > Or use the logging module. It's easy to get going quickly > (just call logging.basicConfig at startup time), and with > a little care and feeding, you can control the output in > more ways than can fit into the margin. Oh, yeah, I'm sure > it introduces some overhead. So does everything else. I hate log files, at least during development or testing. I prefer to debug on the command line or using my IDE. Log files are for release time, not development. -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWart: The problem with "print"
On Jun 2, 12:20 pm, Chris Angelico wrote:
> On Mon, Jun 3, 2013 at 3:04 AM, Rick Johnson
> > * Woefully inadequate because: Switching on or off the debug
> >messages is only valid in the current module that the
> >function was imported. What if you want to kill all
> >debugprint messages EVERYWHERE? Do you really want to edit
> >"debug = BOOLEAN" in every source file OR do something
> >stupid like import debugprint and edit the DEBUG constant
> >OR even dumber, edit the debugprint source code? GAWD NO!
> Easy fix to this one. Instead of copying and pasting debugprint into
> everything, have it in a module and import it everywhere. Then the
> debug flag will be common to them all.
Ignoring the fact that you have "import everywhere", what if you want
to stop ALL debug messages? If you "import everywhere" to get them,
you then have to "edit everywhere" to stop them.
> Oh, and you probably want to add **kwargs to debugprint, because the
> print function does a lot more than sys.stdout.write does:
The kwargs to print are not germane to the issue, however noobs may be
watching so glad you pointed that one out.
> [...]
> py> timeit.timeit('debugprint("asdf") [...]
> 0.5838018519113444
>
> That's roughly half a second for a million calls to debugprint().
> That's a 580ns cost per call. Rather than fiddle with the language,
> I'd rather just take this cost.
I never purposely inject ANY superfluous cycles in my code except in
the case of testing or development. To me it's about professionalism.
Let's consider a thought exercise shall we?
Imagine your an auto mechanic. You customer brings in his
car and asks you to make some repairs. You make the
repairs but you also adjust the air/fuel ratio to run
"rich" (meaning the vehicle will get less MPG). Do you
still pat yourself on the back and consider you've done a
professional job?
I would not! However, you're doing the same thing as the mechanic when
your code executes superflouos calls and burns cycles for no other
reason than pure laziness. CPU's are not immortal you know, they have
a lifetime. Maybe you don't care about destroying someone's CPU,
however, i do!
I just wonder how many of your "creations" (aka: monstrosities!) are
burning cycles this very minute!
> [...]
> So you can eliminate part of the cost there, if it matters to you. If
> a half-microsecond cost is going to be significant to you, you
> probably should be looking at improving other areas, maybe using
> ctypes/cython, or possibly playing with the new preprocessor tricks
> that have been being discussed recently. There's really no need to
> change the language to solve one specific instance of this "problem".
That's like suggesting to the poor fella who's MPG is suffering
(because of your incompetent adjustments!) to buy fuel additives to
compensate for the loss of MPG. Why should he incur costs because you
are incompetent?
--
http://mail.python.org/mailman/listinfo/python-list
Re: PyWart: The problem with "print"
On Mon, 03 Jun 2013 03:20:52 +1000, Chris Angelico wrote: > On Mon, Jun 3, 2013 at 3:04 AM, Rick Johnson > wrote: >> * Woefully inadequate because: Switching on or off the debug >>messages is only valid in the current module that the function was >>imported. What if you want to kill all debugprint messages >>EVERYWHERE? Do you really want to edit "debug = BOOLEAN" in every >>source file OR do something stupid like import debugprint and edit >>the DEBUG constant OR even dumber, edit the debugprint source >>code? GAWD NO! > > Easy fix to this one. Instead of copying and pasting debugprint into > everything, have it in a module and import it everywhere. Then the > debug flag will be common to them all. Or use the logging module. It's easy to get going quickly (just call logging.basicConfig at startup time), and with a little care and feeding, you can control the output in more ways than can fit into the margin. Oh, yeah, I'm sure it introduces some overhead. So does everything else. >> * But even if you are willing to cope with all the "switch- >>on-and-off" nonsense, are you willing to have you code slowed by >>numerous calls to a dead function containing a comparison that >>will always be false? > > Hmm. Could be costly ... Yeah, all that time that I have left over and have to find something else to do instead of debugging my program. What a waste! ;-) Dan -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWart: The problem with "print"
On Mon, Jun 3, 2013 at 3:30 AM, Andrew Berg wrote: > I don't think you go far enough. Obviously we need way more flexibility. A > simple on/off is okay for some things, but a finer granularity > would be really helpful because some things are more important than others. > And why stop at stdout/stderr? We need to add a consistent way > to output these messages to files too in case we need to reference them > again. The messages should have a consistent format as well. Why add > the same information to each message when it would be much simpler to simply > define a default format and insert the real meat of the message > into it? It really seems like we should already have something like this. > Hmm. You have a really good point there. I'm sure I could think of a really good way to do all this, but I'm stuck... it's like there's a log jam in my head... (Okay, maybe I should go to bed now, my puns are getting worse. Considering how late it is, I'll probably sleep like a log.) ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Too many python installations. Should i remove them all and install the latest?
On 06/01/2013 01:51 AM, Νικόλαος Κούρας wrote: > Τη Σάββατο, 1 Ιουνίου 2013 9:18:26 π.μ. UTC+3, ο χρήστης Chris > Angelico έγραψε: > >> That would require that the repo have a 3.3.2 build in it. I don't >> know the Red Hat / CentOS policies there, but I know Debian stable >> wouldn't have anything so new - it takes time to test things. > > Is there a way to change to some repo that contain the latest python > 3.3.2 to yo yum it? Let me brutally blunt here, nick: have you googled for the answer or are you just expecting us to do all your research for you? I googled for this out of curiousity and found at least one third-party repo that did have Python 3.3.x in it for CentOS/RHEL 6.4. I'll give you a free hint about finding it: sometimes you have to add RHEL to the search term as well as CentOS, since CentOS is a free clone of RHEL. From now on, Νικόλαος, before asking a question like this on this list, please state what google search terms you used, what you found, and why the google searches did not turn up the information you seek. -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWart: The problem with "print"
I don't think you go far enough. Obviously we need way more flexibility. A simple on/off is okay for some things, but a finer granularity would be really helpful because some things are more important than others. And why stop at stdout/stderr? We need to add a consistent way to output these messages to files too in case we need to reference them again. The messages should have a consistent format as well. Why add the same information to each message when it would be much simpler to simply define a default format and insert the real meat of the message into it? It really seems like we should already have something like this. Hmm. -- CPython 3.3.2 | Windows NT 6.2.9200 / FreeBSD 9.1 -- http://mail.python.org/mailman/listinfo/python-list
Re: Changing filenames from Greeklish => Greek (subprocess complain)
On Mon, Jun 3, 2013 at 3:12 AM, Νικόλαος Κούρας wrote: > Τη Κυριακή, 2 Ιουνίου 2013 8:05:32 μ.μ. UTC+3, ο χρήστης Chris Angelico > έγραψε: > >> A programmer chooses his own clients, and you are the Atherton Wing to >> my Inara Serra. > > You might want to explain this mystique call-name you inprovised for me. Or you could do a quick web search, like we keep telling you to do for other things. I'm pretty sure Google is familiar with both those names, and will point you to a mighty fine shindig. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Changing filenames from Greeklish => Greek (subprocess complain)
On 06/02/2013 11:12 AM, Νικόλαος Κούρας wrote: > Τη Κυριακή, 2 Ιουνίου 2013 8:05:32 μ.μ. UTC+3, ο χρήστης Chris Angelico > έγραψε: > >> A programmer chooses his own clients, and you are the Atherton Wing to >> my Inara Serra. > > You might want to explain this mystique call-name you inprovised for me? Maybe you could research it a bit. -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWart: The problem with "print"
On Mon, Jun 3, 2013 at 3:04 AM, Rick Johnson
wrote:
> * Woefully inadequate because: Switching on or off the debug
>messages is only valid in the current module that the
>function was imported. What if you want to kill all
>debugprint messages EVERYWHERE? Do you really want to edit
>"debug = BOOLEAN" in every source file OR do something
>stupid like import debugprint and edit the DEBUG constant
>OR even dumber, edit the debugprint source code? GAWD NO!
Easy fix to this one. Instead of copying and pasting debugprint into
everything, have it in a module and import it everywhere. Then the
debug flag will be common to them all.
Oh, and you probably want to add **kwargs to debugprint, because the
print function does a lot more than sys.stdout.write does:
>>> print(1,2,3,4,sep='#')
1#2#3#4
> * But even if you are willing to cope with all the "switch-
>on-and-off" nonsense, are you willing to have you code
>slowed by numerous calls to a dead function containing a
>comparison that will always be false?
Hmm. Could be costly. Hey, you know, Python has something for testing that.
>>> timeit.timeit('debugprint("asdf")','def debugprint(*args):\n\tif not DEBUG:
>>> return\n\tprint(*args)\nDEBUG=False',number=100)
0.5838018519113444
That's roughly half a second for a million calls to debugprint().
That's a 580ns cost per call. Rather than fiddle with the language,
I'd rather just take this cost. Oh, and there's another way, too: If
you make the DEBUG flag have effect only on startup, you could write
your module thus:
if DEBUG:
debugprint=print
else:
def debugprint(*args,**kwargs):
pass
So you can eliminate part of the cost there, if it matters to you. If
a half-microsecond cost is going to be significant to you, you
probably should be looking at improving other areas, maybe using
ctypes/cython, or possibly playing with the new preprocessor tricks
that have been being discussed recently. There's really no need to
change the language to solve one specific instance of this "problem".
ChrisA
--
http://mail.python.org/mailman/listinfo/python-list
Re: Changing filenames from Greeklish => Greek (subprocess complain)
Τη Κυριακή, 2 Ιουνίου 2013 8:05:32 μ.μ. UTC+3, ο χρήστης Chris Angelico έγραψε: > A programmer chooses his own clients, and you are the Atherton Wing to > my Inara Serra. You might want to explain this mystique call-name you inprovised for me. -- http://mail.python.org/mailman/listinfo/python-list
Re: Changing filenames from Greeklish => Greek (subprocess complain)
On Mon, Jun 3, 2013 at 2:44 AM, Νικόλαος Κούρας wrote: > Τη Κυριακή, 2 Ιουνίου 2013 7:31:25 μ.μ. UTC+3, ο χρήστης Chris Angelico > έγραψε: >> On Mon, Jun 3, 2013 at 2:21 AM, Νικόλαος Κούρας >> wrote: >> >> > Paying for someone to just remove a dash to get the script working is too >> > much to ask for > >> One dash: 1c >> Knowing where to remove it: $99.99 >> Total bill: $100.00 > >> Knowing that it ought really to be "utf8mb4" and giving hints that th >> docs should be read rather than just taking this simple example and >> plugging it in: Priceless. > > I agree. > So how much to solve this issue too Chris? > And would you spare me the charge for the dash(-) problem which you pointed > out and solved? :-) A programmer chooses his own clients, and you are the Atherton Wing to my Inara Serra. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
PyWart: The problem with "print"
Note to those of you who may be new to Python: I will refer to "print" as a
function -- just be aware that "print" was a statement before Python3000 was
introduced.
Introduction:
Many languages provide a function, method, or statement by which users can
write easily to stdout, and Python is no exception with it's own "print"
function. However, whilst writing to stdout via "print" is slightly less
verbose than calling the "write" method of "sys.stdout", we don't really gain
much from this function except a few keystrokes... is this ALL print should be?
A mere syntactical sugar? For me, i think the "print" function CAN and SHOULD
be so much more!
Print's Role in Debugging:
A print function can be helpful in many ways, and one very important role print
plays is to inform the programmer of internal states of objects via debug
messages written to stdout.
Sure, there are fancy debuggers by which internal state and object identity can
be inspected on the fly, however, "print" is always going to be there no matter
what libraries or add-on you have available. And let's face it folks, print is
the most simplistic and intuitive interface you'll ever find for debugging
purposes. Sure, "print" may not be the most productive for large scale
debugging, but for the majority of debugging tasks, it's a good fit.
I know some of you will cringe at the idea of using print for debugging,
however, i will argue that using a debugger can weaken your detective skills.
If an exception message and trackback are not giving you enough information to
find the bug, well then, the language OR the code you've written is not worth a
monkey's toss!
I've found that many subtle bugs are caused by not limiting the inputs to sane
values (or types). And with Python's duct typing and implicit casting to
Boolean, you end up with all sorts of misleading things happening! Maybe you're
testing for truth values and get a string instead; which screws everything
up!!!
Anyhoo, i digress...
Inadequacies of "print" Debugging.
In it's current implementation, print is helpful, but in many ways, print is
lacking it's true potential. Many of the problems that propagate up when using
print as a debugger focus on the fact that you cannot easily switch the debug
messages "on" or "off".
Sure, you can comment-out all calls to print, but if you need to see the
messages again you will be forced to uncomment all the lines again... hey
that's no fun!
A "wise programmer" may think he's solved the problem by writing a function
called "debugprint" that looks like this:
def debugprint(*args):
if DEBUG == True:
print(*args)
However that solution is at best woefully inadequate and at worse a cycle
burner!
* Woefully inadequate because: Switching on or off the debug
messages is only valid in the current module that the
function was imported. What if you want to kill all
debugprint messages EVERYWHERE? Do you really want to edit
"debug = BOOLEAN" in every source file OR do something
stupid like import debugprint and edit the DEBUG constant
OR even dumber, edit the debugprint source code? GAWD NO!
* But even if you are willing to cope with all the "switch-
on-and-off" nonsense, are you willing to have you code
slowed by numerous calls to a dead function containing a
comparison that will always be false?
## START INTERACTIVE SESSION ##
py> from __future__ import print_function
py> DEBUG = True
py> def debugprint(*args):
... if not DEBUG:
... return
... print(*args)
py> debugprint("foo", "bar")
foo bar
py> DEBUG = False
py> code = compile('debugprint("foo", "bar")', '', 'exec')
py> import dis
py> dis.disassemble(code)
1 0 LOAD_NAME0 (debugprint)
3 LOAD_CONST 0 ('foo')
6 LOAD_CONST 1 ('bar')
9 CALL_FUNCTION2
12 POP_TOP
13 LOAD_CONST 2 (None)
16 RETURN_VALUE
## END INTERACTIVE SESSION ##
After a few million executions of this superfluous
comparison your cpu is losing faith in your ability to
write logical code!
py> function.call() + false_comparison() == 'cycle burner'
"YOU BET YOU A$$ IT DOES!!"
Solution.
This realization has brought me to the conclusion that Python (and other
languages) need a "scoped print function". What i
Re: Getting Error can't find '__main__' module in 'X'
I think I am the dumbest guy.I got it.I was running it in a wrong way. I was running it like python X hello.py and the problem was in C:\Users\John I should have first gone in C:\Users\John\X then I should run it like python hello.py Dave Angel,Steven D'Aprano-Thank you for the help. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 2-3 compatibility
On 6/2/2013 10:13 AM, Jason Swails wrote: Because Python 2.4 and 2.5 don't support the except Exception as err: syntax, I've used except Exception, err: Is there any way of getting this effect in a way compatible with Py2.4 and 3.x? Don't do either. Just catch the exception with 'except Exception:' and access the details in the body. I googled 'python 2 to 3 exceptions' and the second hit is http://python3porting.com/noconv.html which covers what you are doing ;-). From that page "If you need to support Python versions lower than Python 2.6 and you need access to the exception that was raised, you can get that in all versions through the exc_info() function: >>> import sys >>> try: ... a = 1/'0' ... except (ZeroDivisionError, TypeError): ... e = sys.exc_info()[1] ... print(e.args[0]) unsupported operand type(s) for /: 'int' and 'str' " There are more tips on that page, a reference to the six module, and more hits on the search page. Good luck. You are not the first to support the same range of versions (and for the same reasons). -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: Changing filenames from Greeklish => Greek (subprocess complain)
Τη Κυριακή, 2 Ιουνίου 2013 7:31:25 μ.μ. UTC+3, ο χρήστης Chris Angelico έγραψε: > On Mon, Jun 3, 2013 at 2:21 AM, Νικόλαος Κούρας wrote: > > > Paying for someone to just remove a dash to get the script working is too > > much to ask for > One dash: 1c > Knowing where to remove it: $99.99 > Total bill: $100.00 > Knowing that it ought really to be "utf8mb4" and giving hints that th > docs should be read rather than just taking this simple example and > plugging it in: Priceless. I agree. So how much to solve this issue too Chris? And would you spare me the charge for the dash(-) problem which you pointed out and solved? :-) -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 2-3 compatibility
From
http://stromberg.dnsalias.org/~dstromberg/Intro-to-Python/Python%202%20and%203.pdf:
Try/Except: both 2.x and 3.x
try:
print(1/0)
except ZeroDivisionError:
extra = sys.exc_info()[1]
print('oops')
HTH
On Sun, Jun 2, 2013 at 7:13 AM, Jason Swails wrote:
> Hello Everyone,
>
> I have a Python script that I wrote to support a project that I work on
> (that runs primarily on Unix OSes). Given its support role in this
> package, this script should not introduce any other dependencies. As a
> result, I wrote the script in Python 2, since every Linux currently ships
> with 2.4--2.7 as its system Python (RHEL 5, still popular in my field,
> ships with 2.4).
>
> However, I've heard news that Ubuntu is migrating to Python 3 soon (next
> release??), and that's a platform we actively try to support due to its
> popularity. I've tried writing the code to support both 2 and 3 as much as
> possible, but with priority put on supporting 2.4 over 3.
>
> Now that Python 3-compatibility is about to become more important, I'm
> looking for a way to catch and store exceptions in a compatible way.
>
> Because Python 2.4 and 2.5 don't support the
>
> except Exception as err:
>
> syntax, I've used
>
> except Exception, err:
>
> Is there any way of getting this effect in a way compatible with Py2.4 and
> 3.x? Of course I could duplicate every module with 2to3 and do
> sys.version_info-conditional imports, but I'd rather avoid duplicating all
> of the code if possible.
>
> Any suggestions are appreciated.
>
> Thanks!
> Jason
>
> --
> Jason M. Swails
> Quantum Theory Project,
> University of Florida
> Ph.D. Candidate
> 352-392-4032
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>
>
--
http://mail.python.org/mailman/listinfo/python-list
Re: Changing filenames from Greeklish => Greek (subprocess complain)
On Mon, Jun 3, 2013 at 2:21 AM, Νικόλαος Κούρας wrote: > Paying for someone to just remove a dash to get the script working is too > much to ask for One dash: 1c Knowing where to remove it: $99.99 Total bill: $100.00 Knowing that it ought really to be "utf8mb4" and giving hints that the docs should be read rather than just taking this simple example and plugging it in: Priceless. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Changing filenames from Greeklish => Greek (subprocess complain)
Τη Κυριακή, 2 Ιουνίου 2013 6:55:31 μ.μ. UTC+3, ο χρήστης Mark Lawrence έγραψε:
> I don't think, I know. How can you be putting in any effort when you
> give yourself no thinking time? When you ask for a response maybe two
> hours after you've first posted? Basically you're using this group as a
> *FREE* technical support service. If you want something done to suit
> you, either put the effort in first, show some patience, or *PAY* for
> support.
Certainly *not you*, since you not proven yourself knowlengeable to me or in
the case you are, certainly not helpfull but ironic instead.
This is a a *free* python list.
Everybody receiving help in here does nto have to pay. this might be a simple
trick like the other issues i had with the pymysql connector where it needed
'charser='utf8'' instead of 'charser='utf-8'' which is what i was trying.
Couldn't think of the dash because in any other case i happened to make use of
'utf-8' in my scripts, it was mentioned with a dash inside the statements like:
print( '''Content-type: text/html; charset=utf-8\n'''
open('/home/nikos/public_html/' + page, encoding='utf-8') as f:
So i assumed, 'charset=utf-8' too, didn't occured to me an other symbolism.
Paying for someone to just remove a dash to get the script working is too much
to ask for, but paying for someone from this list to convert my scripts to
Django, and i will at some point because this site advertises webhosting is
logically. I want the scripts to user latest versions of python and the best
code it can be done so, to be quick and functional.
I cannot of course expect someone to do the conversion for me for free.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Changing filenames from Greeklish => Greek (subprocess complain)
On 02/06/2013 16:36, Νικόλαος Κούρας wrote *IF* ? So, you think i'm not putting any effort? Almost always i post out snippets of what i have tried in my numerous attempts to solve some issue i've encountered. Putting forward effort and being able to actually solve a problem is two difeerent things. Where is your attemps to provide an actual help to me for once It is not obligatory of course but a matter of good will, but instead of doing that, you choose not only to not help or at least ignore, but consistently making fun at my expense. I don't think, I know. How can you be putting in any effort when you give yourself no thinking time? When you ask for a response maybe two hours after you've first posted? Basically you're using this group as a *FREE* technical support service. If you want something done to suit you, either put the effort in first, show some patience, or *PAY* for support. -- "Steve is going for the pink ball - and for those of you who are watching in black and white, the pink is next to the green." Snooker commentator 'Whispering' Ted Lowe. Mark Lawrence -- http://mail.python.org/mailman/listinfo/python-list
Re: Changing filenames from Greeklish => Greek (subprocess complain)
Τη Κυριακή, 2 Ιουνίου 2013 6:24:10 μ.μ. UTC+3, ο χρήστης Mark Lawrence έγραψε: Nikos wrote: > > Apart from the "funny" commenting, can you for once contribute towards to > > an actual solution or this is the best you can do to prove yourself smart > > in here by talking down on me? > The only thing I'll contribute is that if you're looking to run a > commercial venture, you wouldn't be the last on my list for services, > you'd never get on it. I wouldn't want you as i client either. > Further I'll point out that you never give any indication at all of ever > doing any research before you ask a question. You simply fire off email > after email in the hope that you'll get a response. Luckily for you a > substantial number of people have come to your rescue. Unfortunately > for you, you've exhausted the patience of a number who might well have > been extremely helpful *IF* you'd put in a little effort. That is just > too much to ask of course. *IF* ? So, you think i'm not putting any effort? Almost always i post out snippets of what i have tried in my numerous attempts to solve some issue i've encountered. Putting forward effort and being able to actually solve a problem is two difeerent things. Where is your attemps to provide an actual help to me for once It is not obligatory of course but a matter of good will, but instead of doing that, you choose not only to not help or at least ignore, but consistently making fun at my expense. -- http://mail.python.org/mailman/listinfo/python-list
Re: Changing filenames from Greeklish => Greek (subprocess complain)
On 02/06/2013 16:04, Νικόλαος Κούρας wrote: Τη Κυριακή, 2 Ιουνίου 2013 5:51:31 μ.μ. UTC+3, ο χρήστης Mark Lawrence έγραψε: You've obviously arrived very late at the party. Apart from the "funny" commenting, can you for once contribute towards to an actual solution or this is the best you can do to prove yourself smart in here by talking down on me? The only thing I'll contribute is that if you're looking to run a commercial venture, you wouldn't be the last on my list for services, you'd never get on it. Further I'll point out that you never give any indication at all of ever doing any research before you ask a question. You simply fire off email after email in the hope that you'll get a response. Luckily for you a substantial number of people have come to your rescue. Unfortunately for you, you've exhausted the patience of a number who might well have been extremely helpful *IF* you'd put in a little effort. That is just too much to ask of course. -- "Steve is going for the pink ball - and for those of you who are watching in black and white, the pink is next to the green." Snooker commentator 'Whispering' Ted Lowe. Mark Lawrence -- http://mail.python.org/mailman/listinfo/python-list
Re: Changing filenames from Greeklish => Greek (subprocess complain)
Τη Κυριακή, 2 Ιουνίου 2013 6:15:16 μ.μ. UTC+3, ο χρήστης Chris Angelico έγραψε: >> Apart from the "funny" commenting, can you for once contribute towards to an >> >> actual solution or this is the best you can do to prove yourself smart in >> here >> by talking down on me? > What makes you think you can demand that we contribute to your problems? I'am an OP like everybody else in here and i don't demand anything. But ome people instead of being helpfull or even ignore, think its better to belittle me. You are a special case, because you do both(you ahve actually provided me hits manh times), but that is not the case of some other regulars. > I'm serious. Why do you feel entitled to assistance, when you won't > even put some effort into your posts? You loudly proclaim that you've > "spent days looking for a solution" to some problem, yet you can't > spend thirty seconds polishing your post before you hit Send? I'm clipping my posts from googles '/n' addition and i'am quoating too. > I call bogus (others may use some other b-word) on the whole "spent > days" bit. If you had, you'd have found something. Yes i have and i wasn't able to find something other that this maybe be a bug. If i had i wouldn't be asking here. -- http://mail.python.org/mailman/listinfo/python-list
Re: Changing filenames from Greeklish => Greek (subprocess complain)
On Mon, Jun 3, 2013 at 1:04 AM, Νικόλαος Κούρας wrote: > Τη Κυριακή, 2 Ιουνίου 2013 5:51:31 μ.μ. UTC+3, ο χρήστης Mark Lawrence έγραψε: > >> You've obviously arrived very late at the party. > > Apart from the "funny" commenting, can you for once contribute towards to an > actual solution or this is the best you can do to prove yourself smart in > here by talking down on me? What makes you think you can demand that we contribute to your problems? I'm serious. Why do you feel entitled to assistance, when you won't even put some effort into your posts? You loudly proclaim that you've "spent days looking for a solution" to some problem, yet you can't spend thirty seconds polishing your post before you hit Send? I call bogus (others may use some other b-word) on the whole "spent days" bit. If you had, you'd have found something. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Changing filenames from Greeklish => Greek (subprocess complain)
Τη Κυριακή, 2 Ιουνίου 2013 5:51:31 μ.μ. UTC+3, ο χρήστης Mark Lawrence έγραψε: > You've obviously arrived very late at the party. Apart from the "funny" commenting, can you for once contribute towards to an actual solution or this is the best you can do to prove yourself smart in here by talking down on me? -- http://mail.python.org/mailman/listinfo/python-list
Re: Changing filenames from Greeklish => Greek (subprocess complain)
Τη Κυριακή, 2 Ιουνίου 2013 5:36:57 μ.μ. UTC+3, ο χρήστης Giorgos Tzampanakis έγραψε: > On 2013-06-02, Νικόλαος Κούρας wrote: > > > > [snip unreadable code] > > > > Okay, this sounds like a homework exercise. Also, it doesn't appear like > you've spent any amount of time researching a solution yourself. I have spent days looking for a solution to this. Why you say it is unreadable? What is it that you do not understand? What would you want to be shown? -- http://mail.python.org/mailman/listinfo/python-list
Re: Changing filenames from Greeklish => Greek (subprocess complain)
On 02/06/2013 15:36, Giorgos Tzampanakis wrote: On 2013-06-02, Νικόλαος Κούρας wrote: [snip unreadable code] Okay, this sounds like a homework exercise. Also, it doesn't appear like you've spent any amount of time researching a solution yourself. You've obviously arrived very late at the party. -- "Steve is going for the pink ball - and for those of you who are watching in black and white, the pink is next to the green." Snooker commentator 'Whispering' Ted Lowe. Mark Lawrence -- http://mail.python.org/mailman/listinfo/python-list
Re: Changing filenames from Greeklish => Greek (subprocess complain)
On 2013-06-02, Νικόλαος Κούρας wrote: [snip unreadable code] Okay, this sounds like a homework exercise. Also, it doesn't appear like you've spent any amount of time researching a solution yourself. -- Real (i.e. statistical) tennis and snooker player rankings and ratings: http://www.statsfair.com/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Changing filenames from Greeklish => Greek (subprocess complain)
Τη Κυριακή, 2 Ιουνίου 2013 10:01:50 π.μ. UTC+3, ο χρήστης Giorgos Tzampanakis
έγραψε:
OK George, nd the rest fo the guys here it is the snippet of files.py
responsible to print the greek filenames:
for row in data:
(url, hits, host, lastvisit) = row
shorturl = url.replace( '/home/nikos/www/data/apps/', '' )
lastvisit = lastvisit.strftime('%A %e %b, %H:%M')
print('''
%s
%s
%s
''' % (shorturl, hits, host, lastvisit) )
and here is the the metrites.py snipper that calls files.py via subproccess to
run:
if page.endswith('.html'):
with open('/home/nikos/public_html/' + page, encoding='utf-8')
as f:
htmldata = f.read()
htmldata = htmldata % (quote, music)
template = htmldata + counter
elif page.endswith('.py'):
htmldata = subprocess.check_output(
'/home/nikos/public_html/cgi-bin/' + page )
template = htmldata.decode('utf-8') + counter
print( template )
--
http://mail.python.org/mailman/listinfo/python-list
Python 2-3 compatibility
Hello Everyone, I have a Python script that I wrote to support a project that I work on (that runs primarily on Unix OSes). Given its support role in this package, this script should not introduce any other dependencies. As a result, I wrote the script in Python 2, since every Linux currently ships with 2.4--2.7 as its system Python (RHEL 5, still popular in my field, ships with 2.4). However, I've heard news that Ubuntu is migrating to Python 3 soon (next release??), and that's a platform we actively try to support due to its popularity. I've tried writing the code to support both 2 and 3 as much as possible, but with priority put on supporting 2.4 over 3. Now that Python 3-compatibility is about to become more important, I'm looking for a way to catch and store exceptions in a compatible way. Because Python 2.4 and 2.5 don't support the except Exception as err: syntax, I've used except Exception, err: Is there any way of getting this effect in a way compatible with Py2.4 and 3.x? Of course I could duplicate every module with 2to3 and do sys.version_info-conditional imports, but I'd rather avoid duplicating all of the code if possible. Any suggestions are appreciated. Thanks! Jason -- Jason M. Swails Quantum Theory Project, University of Florida Ph.D. Candidate 352-392-4032 -- http://mail.python.org/mailman/listinfo/python-list
Re: Apache and suexec issue that wont let me run my python script
Am 01.06.2013 07:30, schrieb Νικόλαος Κούρας: [snipp] [Thu May 30 15:29:33 2013] [error] [client 46.12.46.11] suexec failure: could not open log file [Thu May 30 15:29:33 2013] [error] [client 46.12.46.11] fopen: Permission denied [Thu May 30 15:29:33 2013] [error] [client 46.12.46.11] Premature end of script headers: koukos.py [Thu May 30 15:29:33 2013] [error] [client 46.12.46.11] File does not exist: /home/nikos/public_html/500.shtml when i tail -F /usr/local/apache/logs/error_log & What this error means? It appears that the effective user of the script does not have permission to open the log file that the suexec call requires. Yes, so which logfile and what user is suexec using to run your script? You should be able to answer all this from your apache configuration. cheers Paul -- http://mail.python.org/mailman/listinfo/python-list
Re: Getting Error can't find '__main__' module in 'X'
On Sun, 02 Jun 2013 04:04:50 -0700, meakaakka wrote: > Hey I am newbie in python.I have installed python 2.7.5 correctly.It is > working fine but I am having some issues.I have set windows Enviroment > variables. Any particular environment variables? Shall we guess which ones? > The problem is when I try to save my program in a > folder(C:\Users\John\X)it shows that module error Are you saying that you cannot save in that folder? Sounds like a permission error, or maybe the folder doesn't exist. Have you tried saving in that folder with another program? Can you see the folder in Windows Explorer? Or do you mean you CAN save in that folder, but... something else happens? What? We could play guessing games all week, but it would be better if you actually tell us exactly what is happening. You can see exactly what happens, we can only see what you tell us. Tell us: * Where is the file saved? * What file name does it have? * EXACTLY how you are trying to run the file. * If you are trying to launch it from the command line, COPY AND PASTE the EXACT command you are using. * If you get an error, and it is in the console, COPY AND PASTE the EXACT error message you get. ALL of it. Don't summarise, don't leave out bits you think aren't important, don't retype it from memory, and especially don't assume that because you know what the error is, we will magically know too. The error message will probably start with: Traceback (most recent call last): and then end with an exception type and error message, like: NameError: name 'foo' is not defined IndexError: list index out of range SyntaxError: invalid syntax or similar. Copy and paste the entire error message. Once you have shown us these details, we might be able to help you, or at least come back to you with more questions. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Getting Error can't find '__main__' module in 'X'
On 06/02/2013 07:04 AM, meakaakka wrote: Hey I am newbie in python.I have installed python 2.7.5 correctly.It is working fine but I am having some issues.I have set windows Enviroment variables. Please be a lot more specific. Do you have any particular environment variables you suspect, and if so, what have you set them to? The problem is when I try to save my program in a folder(C:\Users\John\X)it shows that module error Then you'd better tell us what program you were using to save it with. I've never seen that error from emacs or Notepad++, but perhaps you're doing something else. but when I save it outside this X folder ( C:\Users\John ) It runs successfully.How to fix it? Perhaps you'd better start at the beginning. Thanks for telling us you're using python Version 2.7.5, Now perhaps you mean not that this error occurs during the save, but instead during running of the program. So let's try again. Don't try to answer just certain parts of the below, but instead make your own problem description that's at least as thorough. By the time you're done, you just might solve the problem yourself, or you'll have learned something new about the problem. But at least you'll help us help you. You have saved some program (what is its name?) (why not include it here, since it probably only needs about 3 lines, including an import of some form?) in the directory C:\Users\John\X. You then run it, from a cmd prompt, as follows: C:\Users\John\X > python myprog.py and you get the following error. (You fill this in. It's a group of lines called a traceback, and the whole thing can be useful. Don't summarize or retype it, use copy/paste). You then move the file to directory C:\Users\John\betterplace, do a cd there, and run it again from that directory. Now it works, no import errors, and runs to completion. So what else is in that first directory? Are you referencing X somewhere in your code? Are you referencing __name__ (which is a reserved term with very specific meaning)? Have you tried keeping the program in C:\Users\John\X but running with a different current directory? C:\Users\John\testdir > python ..\X\myprog.py If I had to mount my crystal ball, I'd say you've got some form of recursive import going on (thus __main__), and that some module or package has the name X. You might also have more than one copy of some python source file, or a sys.path that's messed up. Some general advice for the future: Avoid using any uppercase in file and directory names for source code. Avoid any single-letter names. Avoid doing recursive imports, and NEVER import the script itself from some other file. One more thing. Before replying, please read this since you're using googlegroups: http://wiki.python.org/moin/GoogleGroupsPython. -- DaveA -- http://mail.python.org/mailman/listinfo/python-list
Getting Error can't find '__main__' module in 'X'
Hey I am newbie in python.I have installed python 2.7.5 correctly.It is working fine but I am having some issues.I have set windows Enviroment variables. The problem is when I try to save my program in a folder(C:\Users\John\X)it shows that module error but when I save it outside this X folder ( C:\Users\John ) It runs successfully.How to fix it? -- http://mail.python.org/mailman/listinfo/python-list
Re: Changing filenames from Greeklish => Greek (subprocess complain)
On Sat, 01 Jun 2013 08:44:36 -0700, Νικόλαος Κούρας wrote: > CalledProcessError: Command '/home/nikos/public_html/cgi-bin/files.py' > returned non-zero exit status 1 > args = (1, '/home/nikos/public_html/cgi-bin/files.py') > cmd = '/home/nikos/public_html/cgi-bin/files.py' > output = b'Content-type: text/html; charset=utf-8\n\n 74: surrogates not allowed\n\n-->\n\n' > returncode = 1 > with_traceback = object> The traceback indicates that files.py terminated with a non-zero exit code, indicating an error. And that's *all* that can be determined from the information which you have posted. If you want to solve the problem, you'll need to make files.py generate useful error messages, then capture them. -- http://mail.python.org/mailman/listinfo/python-list
Free Money
Get Free Money here: http://horrorhorrorhorror.webs.com/free-money -- http://mail.python.org/mailman/listinfo/python-list
Re: Changing filenames from Greeklish => Greek (subprocess complain)
On 02/06/2013, Mark Lawrence wrote: > On 02/06/2013 08:01, Giorgos Tzampanakis wrote: >> >> You are not offering enough information, because you have not posted the >> contents of your files.py script. Thus it's difficult to help you. Please >> post your code to pastebin or somewhere similar because posting long >> lines >> on usenet is considered bad etiquette. >> > > I would much prefer to have a code snippet that shows the problem > inline. Plus, what happens in six months time if someone finds this > thread but can't find the code online as it's expired? I agree, and this is also the policy enforced in freenode #bash. Please do not encourage people to pastebin entire scripts, because very few people will bother to read them. The ideal approach is to post a minimal code snippet that allows us to comprehend or reproduce the problem. This encourages the question to be well-framed. Otherwise idiots will dump their entire scripts into a pastebin and write to us "why it not work?". -- http://mail.python.org/mailman/listinfo/python-list
Re: Changing filenames from Greeklish => Greek (subprocess complain)
On 02/06/2013 08:01, Giorgos Tzampanakis wrote: You are not offering enough information, because you have not posted the contents of your files.py script. Thus it's difficult to help you. Please post your code to pastebin or somewhere similar because posting long lines on usenet is considered bad etiquette. I would much prefer to have a code snippet that shows the problem inline. Plus, what happens in six months time if someone finds this thread but can't find the code online as it's expired? -- "Steve is going for the pink ball - and for those of you who are watching in black and white, the pink is next to the green." Snooker commentator 'Whispering' Ted Lowe. Mark Lawrence -- http://mail.python.org/mailman/listinfo/python-list
Re: Changing filenames from Greeklish => Greek (subprocess complain)
> The above error message happened when i tried to reanme one of my > filenames from > > its greeklish name to greek charcters. > > files.py is a script that allows users to downlaod fiels form my server. > But i wish to presnt filename sin Greek and not in Greeklish > > http://superhost.gr/?page=files.py > as it is now. > > What can i do to make pth script accept greek filenames too? > Why does subprocess is complaining? You are not offering enough information, because you have not posted the contents of your files.py script. Thus it's difficult to help you. Please post your code to pastebin or somewhere similar because posting long lines on usenet is considered bad etiquette. Also, few here know what "greeklish" means, and most of us who know would like to forget. -- Real (i.e. statistical) tennis and snooker player rankings and ratings: http://www.statsfair.com/ -- http://mail.python.org/mailman/listinfo/python-list
