date:20130603

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\nbod...n 
position 74: surrogates not allowed\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 stdin, line 1, in module
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: Python Heisenbugs? (was: Re: PyWart: The problem with print)

2013-06-03 Thread Devin Jeanpierre

On Mon, Jun 3, 2013 at 12:34 AM, Dan Sommers d...@tombstonezero.net 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?

The garbage collector can do this, but I think in practice it's
ridiculously rare, since __del__ is almost never useful due to its
unreliability*. The problem is that the garbage collector can do
whatever it wants. For example, in CPython it is called after so many
cycles have been created. This allows code and user actions to
inadvertently affect the garbage collector, and therefore, the
invocation of __del__.

If your __del__ does anything that accesses mutable global state also
used elsewhere, it's conceivable that the order of someone else's
access and __del__'s invocation depends on the GC. One order or the
other might be the wrong one which causes a failure. As it happens,
the bt command in pdb creates a cycle and might trigger the garbage
collector, causing __del__ to run immediately, and potentially hiding
the failure.

This isn't really pure python in that Python doesn't even guarantee
__del__ is ever called at all, let alone why. It's completely
implementation-specific, and not a property of Python the language.

-- Devin

.. [*] Some people use it as an unreliable fallback; this turns
their magical autosaving code into an attractive and yet horribly
dangerous nuisance. Friends don't let friends use __del__.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PyWart: The problem with print

On Mon, Jun 3, 2013 at 3:49 PM, Michael Torrie torr...@gmail.com wrote:
 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.

Plus, writing to a file actually makes a lot of sense for development
too. It's far easier to run the program the same way in dev and
release, which often means daemonized. I like to have Upstart manage
all my services, for instance.

ChrisA
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Changing filenames from Greeklish = Greek (subprocess complain)

On Mon, Jun 3, 2013 at 4:46 PM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
 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.

Minor quibble: Surrogates are an artifact of UTF-16, so they're 16-bit
values like 0xD808 or 0xDF45. Possibly what you're talking about here
is a continuation byte, which in UTF-8 are used only after a lead
byte. For instance: 0xF0 0x92 0x8D 0x85 is valid UTF-8, but 0x41 0x92
is not.

There is one other really annoying thing to deal with, and that's the
theoretical UTF-8 encoding of a UTF-16 surrogate. (I say theoretical
because strictly, these are invalid; UTF-8 does not encode invalid
codepoints.) 0xED 0xA0 0x88 and 0xED 0xBD 0x85 encode the two I
mentioned above. Depending on what's reading the filename, you might
actually have these throw errors, or maybe not. Python's decoder is
correctly strict:

 str(b'\xed\xa0\x88','utf-8')
Traceback (most recent call last):
  File pyshell#9, line 1, in module
str(b'\xed\xa0\x88','utf-8')
UnicodeDecodeError: 'utf-8' codec can't decode bytes in position 0-2:
invalid continuation byte

Actually, I'm not sure here, but I think that error message may be
wrong, or at least unclear. It's perfectly possible to decode those
bytes using the UTF-8 algorithm; you end up with the value 0xD808,
which you then reject because it's a surrogate. But maybe the Python
UTF-8 decoder simplifies some of that.

ChrisA
-- 
http://mail.python.org/mailman/listinfo/python-list

Interactive interpreter hooks

The sys module defines two hooks that are used in the interactive 
interpreter:

* sys.displayhook(value) gets called with the result of evaluating the 
line when you press ENTER;

* sys.excepthook(type, value, traceback) gets called with the details of 
the exception when your line raises an exception.

Is there a way to hook into the interactive interpreter *before* it is 
evaluated? That is, if I type len([]) at the prompt and hit ENTER, I 
want a hook that runs before len([]) is evaluated to 0, so that I get the 
string len([]).



-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PyWart: The problem with print

2013-06-03 Thread Alister

On Mon, 03 Jun 2013 17:17:12 +1000, Chris Angelico wrote:

 On Mon, Jun 3, 2013 at 3:49 PM, Michael Torrie torr...@gmail.com
 wrote:
 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.
 
 Plus, writing to a file actually makes a lot of sense for development
 too. It's far easier to run the program the same way in dev and release,
 which often means daemonized. I like to have Upstart manage all my
 services, for instance.
 
 ChrisA

further point
the production logging code needs to be implemented and tested at 
development time anyway so why not make use of it instead of creating 
additional redundant code?



-- 
It is a lesson which all history teaches wise men, to put trust in ideas,
and not in circumstances.
-- Emerson
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PyWart: The problem with print

2013-06-03 Thread Mark Lawrence


On 03/06/2013 04:10, 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.  ;-)

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.



Strikes me it's a bit like problems when prototyping circuit boards. 
The card doesn't work, so you mount it on an extender card, problem goes 
away, remove extender card, problem reappears.  Wash, rinse, repeat :)


--
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)

2013-06-03 Thread Mark Lawrence


On 03/06/2013 07:11, Νικόλαος Κούρας wrote:

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?



import ocdecs?

Sums up perfectly the amount of effort you put in.

--
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: Interactive interpreter hooks

2013-06-03 Thread Fábio Santos

On 3 Jun 2013 09:04, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info
wrote:

 The sys module defines two hooks that are used in the interactive
 interpreter:

 * sys.displayhook(value) gets called with the result of evaluating the
 line when you press ENTER;

 * sys.excepthook(type, value, traceback) gets called with the details of
 the exception when your line raises an exception.

 Is there a way to hook into the interactive interpreter *before* it is
 evaluated? That is, if I type len([]) at the prompt and hit ENTER, I
 want a hook that runs before len([]) is evaluated to 0, so that I get the
 string len([]).


I don't know whether that is possible, but you could recreate the repl.
This page seems to have good resources for that:
http://stackoverflow.com/questions/1395913/python-drop-into-repl-read-eval-print-loop

A trace function could also work. See docs for sys.settrace. The source
code for the python GOTO module is a good example of its usage.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Changing filenames from Greeklish = Greek (subprocess complain)

On Mon, Jun 3, 2013 at 7:00 PM, Mark Lawrence breamore...@yahoo.co.uk wrote:
 On 03/06/2013 07:11, Νικόλαος Κούρας wrote:

 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?


 import ocdecs?

 Sums up perfectly the amount of effort you put in.

If he imported a little more OCD, it might help a lot.

ChrisA
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Changing filenames from Greeklish = Greek (subprocess complain)

2013-06-03 Thread Νικόλαος Κούρας

Τη Δευτέρα, 3 Ιουνίου 2013 9:46:46 π.μ. UTC+3, ο χρήστης Steven D'Aprano έγραψε:

 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?

 Fix those file names, and hopefully the problem will go away.

You are right Steven, i just renames the file 'Euxi tou Ihsou.mp3' = 'Eυχή του 
Ιησού.mp3' and here is how it appears the filename directory listing via Chrome.

http://superhost.gr/data/apps/

I doesn't display the file with proper Greek characters but with *Mojibake* 
instead.

So, as you correctly said when files.py need to actually open that file, it 
cannot decode its stored byte stream from the hdd to proper 'utf-8' charset.

So, how will files.py be able to open these files then?!?!
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Changing filenames from Greeklish = Greek (subprocess complain)

2013-06-03 Thread Νικόλαος Κούρας

Here is the whole code of files.py in case someone wants to comment on 
somethign about how to properly encode/decode the filanames, which seems to be 
the problem.

http://pastebin.com/qXasy5iU
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PyWart: The problem with print

2013-06-03 Thread Robert Kern


On 2013-06-03 05:20, Dan Sommers wrote:

On Sun, 02 Jun 2013 23:23:42 -0400, Jason Swails wrote:



... (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


No, no. It's the PSU that you have to worrNO CARRIER

--
http://mail.python.org/mailman/listinfo/python-list

Re: Too many python installations. Should i remove them all and install the latest?

2013-06-03 Thread Joshua Landau

On 3 June 2013 04:18, Chris Angelico ros...@gmail.com wrote:
 On Mon, Jun 3, 2013 at 12:30 PM, alex23 wuwe...@gmail.com wrote:
 On Jun 1, 10:24 am, Chris Angelico ros...@gmail.com 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 :)

What shell do you use? Zsh supports this (implicit cd). I don't have
it active because it's not that useful - you get better completion
with explicit cd - but it exists.
-- 
http://mail.python.org/mailman/listinfo/python-list

Extract UTFGrid from MBTiles database

2013-06-03 Thread Carmen Campos Bordons

I would appreciate any help or comment.
The idea is
to create a server in python that serves maps on the internet. The maps have to
be in MBTiles format, which is a SQLite database that store all the map tiles
in a single file. Taking this as an example 
http://a.tiles.mapbox.com/v3/mapbox.geography-class/page.html#4.00/36.74/28.30 
The tiles are images of the
map in png, like this one 
http://a.tiles.mapbox.com/v3/mapbox.geography-class/4/7/7.png and apart from 
the tiles, in the
database is stored the UTFGrid information, like this file 
http://a.tiles.mapbox.com/v3/mapbox.geography-class/4/7/7.grid.json. The 
UTFGrid (you can consult in http://www.mapbox.com/developers/utfgrid/) permits 
than when you hover in the
map, some extra information appears referring to the point where the mouse is.
As you can see in this example 
http://a.tiles.mapbox.com/v3/mapbox.geography-class/page.html#4.00/36.74/28.30 
a infobox appears with the
flag of every country(which is the information stored in the UTFGrid file).

In the
MBTiles database there are two table (also other, but not important in this 
case):
“tiles”, where are stored the tiles; and “grids”, where is stored the UTFGrid
associated to every tile.

From the
MBTiles I can extract the tiles and display a normal map, and I can also
extract the UTFGrid file individually (not all together, like the tiles that I
can see the whole map; with the UTFGrid I just get one file). When I show the
map normally, the infoboxes do not appear. But I do not get any error in
command line or in the website. It just like the UTFGrid is empty.

Attached is
the code I am using to access the MBtiles file.

I am using
this SQL to access the MBTiles file

“select
grid from grids where tile_column=? and tile_row=? and zoom_level=?, (x,
y, z)

And if I
change it for this

select
grid from grids where tile_column=? and tile_row=? and zoom_level=?, (67,
84, 7)

I am
getting always the same UTFGrid, but in this case it shows the infoboxes on the
map, that one for all the tiles.

It is like
if I have this part of the map 
http://a.tiles.mapbox.com/v3/mapbox.geography-class/page.html#4.00/10.14/17.31 
but I always get the
infoboxes of this tile 
http://a.tiles.mapbox.com/v3/mapbox.geography-class/4/7/7.png I get the 
infoboxes in all the
tiles, but all of them are showing the flag of that tile.
Thanks,Carmen 
import sqlite3
import json
import zlib

def get_tile(layer, x, y, z, ext):
	try:
		# Connect to the database and get the cursor
		db = sqlite3.connect(data/%s.mbtiles % layer)
		c = db.cursor()
		#closing(db.cursor)
	except:
		# return None
		# In case the connection can not be done
		start_response('404 Not found', [('Content-Type', 'text/plain')])
		return [Not found: %s.mbtiles % (layer,)]
	# Get the tiles from the database, using the zoom and the coordinates we got previously
	c.execute(select tile_data from tiles where tile_column=? and tile_row=? and zoom_level=?, (x, y, z))
	res = c.fetchone()
	if res:
		# In case there are tiles, print them with their necesary headers
		get_grid(layer, x, y, z)
		return bytes(res[0])
	return None


def get_grid(layer, x, y, z): #, ext):
	print accede a grid
# Connect to the database and get the cursor
	try:
		db = sqlite3.connect(data/%s.mbtiles % layer)
		c1 = db.cursor()
		c2 = db.cursor()
		#closing(db.cursor)
	except:
		# In case the connection can not be done
		start_response('404 Not found', [('Content-Type', 'text/plain')])
		return [Not found: %s.mbtiles % (layer,)]
	# Get the utfgrid info from the database, using the zoom and the coordinates we got previously
	c1.execute(select grid from grids where tile_column=? and tile_row=? and zoom_level=?, (67, 84, 7)) #(31, 39, 6)) #
	#c1.execute(select * from grids)
	row = c1.fetchone()
	if not row:
		print NO ROW
		return None
	print ROW
	bts = bytes(row[0])
	# Decompresses the data in string, returning a string containing the uncompressed data.
	files = zlib.decompress(bts)
	# Deserialize files to a Python object - http://docs.python.org/2/library/json.html#json-to-py-table
	jsonfiles = json.loads(files)
	#return jsonfiles

	# Get the data
	keys = []
	#for keyrow in c2.execute(select key_name as key, key_json as json from grid_data where zoom_level=? and tile_column=? and tile_row=?, (z, x, y)):
	for keyrow in c2.execute(SELECT keymap.key_name AS key_name, keymap.key_json AS key_json FROM map JOIN grid_utfgrid ON grid_utfgrid.grid_id = map.grid_id JOIN grid_key ON grid_key.grid_id = map.grid_id JOIN keymap ON grid_key.key_name = keymap.key_name WHERE tile_column=? and tile_row=? and zoom_level=?, (67, 84, 7)): #(31, 39, 6)): #(x, y, z)):
		keyname, keydata = keyrow  
		keys.append((keyname, eval(keydata))) 
	datadict = dict(keys)
	jsonfiles[u'data'] = datadict
	# return jsonfiles
	print okey Z: + z + x,y + x + y
	# Serialize jsonfiles to a JSON formatted string using - http://docs.python.org/2/library/json.html#py-to-json-table
	res =

Re: Changing filenames from Greeklish = Greek (subprocess complain)

2013-06-03 Thread rusi

On Jun 3, 2:12 pm, Νικόλαος Κούρας nikos.gr...@gmail.com wrote:
 You are right Steven, i just renames the file 'Euxi tou Ihsou.mp3' = 'Eõ÷Þ 
 ôïõ Éçóïý.mp3' and…

Is that how you renamed your file?
In any case thats what I see!!

[Dont whether to say: Its greek to me or its not greek to me!!]
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PyWart: The problem with print

2013-06-03 Thread Dave Angel


On 06/03/2013 04:49 AM, Mark Lawrence wrote:

On 03/06/2013 04:10, 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.  ;-)

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.



Strikes me it's a bit like problems when prototyping circuit boards. The
card doesn't work, so you mount it on an extender card, problem goes
away, remove extender card, problem reappears.  Wash, rinse, repeat :)



That's when you use a little kappy-zapper spray.

--
DaveA
--
http://mail.python.org/mailman/listinfo/python-list

Re: Interactive interpreter hooks

2013-06-03 Thread Terry Jan Reedy


On 6/3/2013 3:55 AM, Steven D'Aprano wrote:

The sys module defines two hooks that are used in the interactive
interpreter:

* sys.displayhook(value) gets called with the result of evaluating the
line when you press ENTER;

* sys.excepthook(type, value, traceback) gets called with the details of
the exception when your line raises an exception.

Is there a way to hook into the interactive interpreter *before* it is
evaluated? That is, if I type len([]) at the prompt and hit ENTER, I
want a hook that runs before len([]) is evaluated to 0, so that I get the
string len([]).


You have not said what you are actually trying to do, but you could 
definitely modify Idle to do something with user input before it sends 
it to the user process.





--
http://mail.python.org/mailman/listinfo/python-list

Re: Interactive interpreter hooks

2013-06-03 Thread Robert Kern


On 2013-06-03 08:55, Steven D'Aprano wrote:

The sys module defines two hooks that are used in the interactive
interpreter:

* sys.displayhook(value) gets called with the result of evaluating the
line when you press ENTER;

* sys.excepthook(type, value, traceback) gets called with the details of
the exception when your line raises an exception.

Is there a way to hook into the interactive interpreter *before* it is
evaluated? That is, if I type len([]) at the prompt and hit ENTER, I
want a hook that runs before len([]) is evaluated to 0, so that I get the
string len([]).


You will need to write your own REPL for this. Use the code.InteractiveConsole 
class:


  http://docs.python.org/2/library/code

I recommend source-diving to see what you need to override, but I suspect you 
can just wrap around the `runsource()` method.


--
Robert Kern

I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth.
  -- Umberto Eco

--
http://mail.python.org/mailman/listinfo/python-list

Re: Changing filenames from Greeklish = Greek (subprocess complain)

2013-06-03 Thread nagia . retsina

Τη Δευτέρα, 3 Ιουνίου 2013 3:54:30 μ.μ. UTC+3, ο χρήστης rusi έγραψε:

 Is that how you renamed your file?
 In any case thats what I see!
 [Dont whether to say: Its greek to me or its not greek to me!!]

Now! that weird again.
I rename sit using proper Greek letters but as it appears to you it also 
appears to me via Chrome.

Also this is how it looks like via linux cmd listing:

ni...@superhost.gr [~/www/cgi-bin]# ls -l ../data/apps/
total 368548
drwxr-xr-x 2 nikos nikos 4096 Jun  3 12:07 ./
drwxr-xr-x 6 nikos nikos 4096 May 26 21:13 ../
-rwxr-xr-x 1 nikos nikos 13157283 Mar 17 12:57 100\ Mythoi\ tou\ Aiswpou.pdf*
-rwxr-xr-x 1 nikos nikos 29524686 Mar 11 18:17 Anekdotologio.exe*
-rw-r--r-- 1 nikos nikos 42413964 Jun  2 20:29 Battleship.exe
-rwxr-xr-x 1 nikos nikos 66896732 Mar 17 13:13 Kosmas\ o\ Aitwlos\ -\ 
Profiteies  
  .pdf*
-rw-r--r-- 1 nikos nikos 51819750 Jun  2 20:04 Luxor\ Evolved.exe
-rw-r--r-- 1 nikos nikos 60571648 Jun  2 14:59 Monopoly.exe
-rwxr-xr-x 1 nikos nikos  1788164 Mar 14 11:31 Online\ Movie\ Player.zip*
-rw-r--r-- 1 nikos nikos  5277287 Jun  1 18:35 O\ Nomos\ tou\ Merfy\ v1-2-3.zip
-rwxr-xr-x 1 nikos nikos 16383001 Jun 22  2010 Orthodoxo\ Imerologio.exe*
-rw-r--r-- 1 nikos nikos  6084806 Jun  1 18:22 Pac-Man.exe
-rw-r--r-- 1 nikos nikos 25476584 Jun  2 19:50 Scrabble\ 2013.exe
-rw-r--r-- 1 nikos nikos   236032 Jun  2 19:31 Skepsou\ enan\ arithmo!.exe
-rwxr-xr-x 1 nikos nikos 49141166 Mar 17 12:48 To\ 1o\ mou\ vivlio\ gia\ to\ 
ska 
   ki.pdf*
-rwxr-xr-x 1 nikos nikos  3298310 Mar 17 12:45 Vivlos\ gia\ Atheofovous.pdf*
-rw-r--r-- 1 nikos nikos  1764864 May 29 21:50 V-Radio\ v2.4.msi
-rw-r--r-- 1 nikos nikos  3511233 Jun  3 12:07 ΞΟ
ΟΞ�\ Ο
  ΞΏΟ.mp3
ni...@superhost.gr [~/www/cgi-bin]# 

Why doesnt the name of the ?

file doesnt appear in proper Greek letter neither from cmd nor for Chrome too?
It's no wonder files.py cant decode it in 'utf-8'

How can i make the filanems appear properly or at least decode from byte 
strea,m to utf-8 properly so they can be opened via the python script without 
error?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How to get an integer from a sequence of bytes

2013-06-03 Thread Grant Edwards

On 2013-06-03, Dennis Lee Bieber wlfr...@ix.netcom.com wrote:
 On Sun, 02 Jun 2013 21:25:45 +0200, Mok-Kong Shen
mok-kong.s...@t-online.de declaimed the following in
 gmane.comp.python.general:


 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

   In other languages byte is an 8-bit signed/unsigned numeric.

That's a common assumption, but historically, a byte was merely the
smallest addressable unit of memory.  The size of a byte on widely
used used CPUs ranged from 4 bits to 60 bits.

Quoting from http://en.wikipedia.org/wiki/Byte

The size of the byte has historically been hardware
 dependent and no definitive standards existed that mandated the
 size.

That's why IEEE standards always use the word octet when referring a
value containing 8 bits.
 
Only recently has it become common to assume that an byte contains 8
bits.

-- 
Grant Edwards   grant.b.edwardsYow! It's a lot of fun
  at   being alive ... I wonder if
  gmail.commy bed is made?!?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Too many python installations. Should i remove them all and install the latest?

2013-06-03 Thread Walter Hurry

On Sun, 02 Jun 2013 14:41:45 +1000, Chris Angelico wrote:

 Nikos just
 needs to learn the skill of figuring out where his problems really are.
 
Between the keyboard and the chair, obv.
-- 
http://mail.python.org/mailman/listinfo/python-list

RE: [Python-Dev] New FreeBSD 10.0-CURRENT buildbot

 Date: Sun, 2 Jun 2013 13:43:24 -0700 
 Subject: Re: [Python-Dev] New FreeBSD 10.0-CURRENT buildbot 
 From: drsali...@gmail.com 
 To: carlosnepomuc...@outlook.com 
 CC: python-...@python.org 

 On Sun, Jun 2, 2013 at 12:51 PM, Carlos Nepomuceno  
 carlosnepomuc...@outlook.commailto:carlosnepomuc...@outlook.com  
 wrote: 

  Date: Sun, 2 Jun 2013 15:12:43 +1000 
  From: koobs.free...@gmail.commailto:koobs.free...@gmail.com 
  To: python-...@python.orgmailto:python-...@python.org 
  Subject: [Python-Dev] New FreeBSD 10.0-CURRENT buildbot 
 [...] 
  koobs-freebsd10-amd64 (clang is default here) 

 Does CPython code compiled with clang runs faster than gcc? 

 Why did you chose clang? Any benchmarks? Any benefits? 

 Clang is sometimes favored over gcc for its non-GPL license; I believe  
 the FreeBSD project sees this as an important issue. 

 In general, the more C compilers a piece of C code compiles on, the  
 fewer bugs are left in it, because different C compilers tend to catch  
 different problems - even with cranked up warnings. 

I've been to a Clang presentation and one of the important features they've 
shown were the improved error messages.

But I didn't try it yet.  
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Too many python installations. Should i remove them all and install the latest?

2013-06-03 Thread nagia . retsina

Τη Δευτέρα, 3 Ιουνίου 2013 5:35:46 μ.μ. UTC+3, ο χρήστης Walter Hurry έγραψε:
 On Sun, 02 Jun 2013 14:41:45 +1000, Chris Angelico wrote:
 
 
 
  Nikos just
 
  needs to learn the skill of figuring out where his problems really are.
 
  
 
 Between the keyboard and the chair, obv.

Maybe you should tell us how you find out yours.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Apache and suexec issue that wont let me run my python script

2013-06-03 Thread Anssi Saari

Νικόλαος Κούρας nikos.gr...@gmail.com writes:

 [code]
 root@nikos [/home/nikos/www/cgi-bin]# chmod g+w /var/log/httpd/suexec.log
 root@nikos [/home/nikos/www/cgi-bin]# ls -l /var/log/httpd/suexec.log
 -rw-rw-r-- 1 root root 0 Jun 1 02:52 /var/log/httpd/suexec.log
 [/code]


 and still iam receiving the same error.

What did you hope to accomplish with this second chmod? Nobody is in the
root group except root. I hope. My guess based on very minimal Googling
on the topic is you should change the group of /var/log/httpd/suexec.log
to apache. 

Then again, I have no idea why you have both
/usr/local/apache/logs/suexec_log and /var/log/httpd/suexec.log, but the
former apparently has some data in it and the latter does not so
changing permissions on /var/log/httpd/suexec.log may not help...

Oh, apparently suexec prints its config if you run suexec -V, so include
that output if you still have problems.
-- 
http://mail.python.org/mailman/listinfo/python-list

Pillow lib for x86_64 GNU/Linux

2013-06-03 Thread consultski

It is great that Pillow wants to be setuptools compatible but without a 
suitable compiled library for x86_64 GNU/Linux, I am stuck between a rock and a 
hard place.

Any suggestions?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Pillow lib for x86_64 GNU/Linux

2013-06-03 Thread Irmen de Jong

On 3-6-2013 18:23, consult...@gmail.com wrote:
 It is great that Pillow wants to be setuptools compatible but without a 
 suitable compiled library for x86_64 GNU/Linux, I am stuck between a rock and 
 a hard place.
 
 Any suggestions?
 

Try your distribution's package repository.

$ sudo apt-get install python-pillow

Or failing that,

$ sudo apt-get install python-imaging


Worked fine for me (Ubuntu 64-bit)

Irmen



-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PyWart: The problem with print

2013-06-03 Thread Ian Kelly

On Sun, Jun 2, 2013 at 6:16 PM, Jason Swails jason.swa...@gmail.com wrote:
 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).

It seems to me that your problem here wasn't that the time needed for
the deactivated debugprint was too great. Your problem was that a
debugprint that executes 243K times in 0.73 seconds is going to
generate far too much output to be useful, and it had no business
being there in the first place.  *Reasonably* placed debugprints are
generally not going to be a significant time-sink for the application
when disabled.

 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.

Indeed, the print function is for general output, not specifically for
debugging.  If you have the global print deactivation that RR is
suggesting, then what you have is no longer a print function, but a
misnamed debug function.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Too many python installations. Should i remove them all and install the latest?

2013-06-03 Thread Ian Kelly

On May 31, 2013 6:27 PM, Chris Angelico ros...@gmail.com wrote:
 Yeah. I know that particular one because I have l aliased to ls -CF
 (aka --columns --classify), mainly because it came that way as a
 commented-out entry in my first Debian. Have since become quite
 accustomed to it; to me, 'l' means 'look' (I do love my MUDs), so I'm
 considering aliasing 'gl' to 'pwd' so that I can 'glance' too :)

 Hmm. What other MUD commands have obvious Unix equivalents?

 say -- echo
 emote -- python -c
 attack -- sudo rm -f

Have you ever tried Adventure Shell?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Too many python installations. Should i remove them all and install the latest?

2013-06-03 Thread Michael Torrie

On 06/03/2013 09:01 AM, nagia.rets...@gmail.com wrote:
 Maybe you should tell us how you find out yours.

Chris and others have told you how they go about solving their problems.
 Quite a few times.  In fact repeating themselves even.  I think we've
run out of different ways to saying it now.

It's a process of research, tracing execution, understanding code flow,
beta-testing code on a local machine (not on a production server!).  Why
do you expect it to be any different?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PyWart: The problem with print

2013-06-03 Thread Jason Swails

On Mon, Jun 3, 2013 at 1:12 PM, Ian Kelly ian.g.ke...@gmail.com wrote:

 On Sun, Jun 2, 2013 at 6:16 PM, Jason Swails jason.swa...@gmail.com
 wrote:
  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).

 It seems to me that your problem here wasn't that the time needed for
 the deactivated debugprint was too great. Your problem was that a
 debugprint that executes 243K times in 0.73 seconds is going to
 generate far too much output to be useful, and it had no business
 being there in the first place.  *Reasonably* placed debugprints are
 generally not going to be a significant time-sink for the application
 when disabled.


Well in 'debug' mode I wouldn't use an example that executed the loop 200K
times -- I'd find one that executed a manageable couple dozen, maybe.
 When 'disabled,' the print statement won't do anything except consume
clock cycles and potentially displace useful cache (the latter being the
more harmful, since most applications are bound by the memory bus).  It's
better to eliminate this dead call when you're not in 'debugging' mode.
 (When active, it certainly would've taken more than 0.73
seconds) Admittedly such loops should be tight enough that debugging
statements inside the inner loop are generally unnecessary, but perhaps not
always.

But unlike RR, who suggests some elaborate interpreter-wide, ambiguous
ignore-rule to squash out all of these functions, I'm simply suggesting
that sometimes it's worth commenting-out debug print calls instead of 'just
leaving them there because you won't notice the cost' :).

 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.

 Indeed, the print function is for general output, not specifically for
 debugging.  If you have the global print deactivation that RR is
 suggesting, then what you have is no longer a print function, but a
 misnamed debug function.


Exactly.  I was just trying to make the point that it is -occasionally-
worth spending the time to comment-out certain debug calls rather than
leaving 'dead' function calls in certain places.

All the best,
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: PyWart: The problem with print

2013-06-03 Thread Jason Swails

On Mon, Jun 3, 2013 at 1:12 PM, Ian Kelly ian.g.ke...@gmail.com wrote:

 On Sun, Jun 2, 2013 at 6:16 PM, Jason Swails jason.swa...@gmail.com
 wrote:
  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).

 It seems to me that your problem here wasn't that the time needed for
 the deactivated debugprint was too great. Your problem was that a
 debugprint that executes 243K times in 0.73 seconds is going to
 generate far too much output to be useful, and it had no business
 being there in the first place.  *Reasonably* placed debugprints are
 generally not going to be a significant time-sink for the application
 when disabled.


Well in 'debug' mode I wouldn't use an example that executed the loop 200K
times -- I'd find one that executed a manageable couple dozen, maybe.
 When 'disabled,' the print statement won't do anything except consume
clock cycles and potentially displace useful cache (the latter being the
more harmful, since most applications are bound by the memory bus).  It's
better to eliminate this dead call when you're not in 'debugging' mode.
 Admittedly such loops should be tight enough that debugging statements
inside the inner loop are generally unnecessary, but perhaps not always.

But unlike RR, who suggests some elaborate interpreter-wide, ambiguous
ignore-rule to squash out all of these functions, I'm simply suggesting
that sometimes it's worth commenting-out debug print calls instead of 'just
leaving them there because you won't notice the cost' :).

 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.

 Indeed, the print function is for general output, not specifically for
 debugging.  If you have the global print deactivation that RR is
 suggesting, then what you have is no longer a print function, but a
 misnamed debug function.


Exactly.  I was just trying to make the point that it is -occasionally-
worth spending the time to comment-out certain debug calls rather than
leaving 'dead' function calls in certain places.

All the best,
Jason
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PyWart: The problem with print

2013-06-03 Thread Jason Swails

ack, sorry for the double-post.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: [RELEASED] Python 2.7.5

2013-06-03 Thread John Nagle

On 5/15/2013 9:19 PM, Benjamin Peterson wrote:
 It is my greatest pleasure to announce the release of Python 2.7.5.
 
 2.7.5 is the latest maintenance release in the Python 2.7 series.

Thanks very much.  It's important that Python 2.x be maintained.

3.x is a different language, with different libraries, and lots of
things that still don't work.  Many old applications will never
be converted.

John Nagle
-- 
http://mail.python.org/mailman/listinfo/python-list

THRINAXODON MURDERS THE ATHEISTS OF REDVILLE.

2013-06-03 Thread Thrinaxodon

THRINAXODON SECRETLY STALKS THE ATHEISTS OF REDVILLE. NOW, THRINAXODON
PUNCHES RABBIT HOLE IN HIS FACE. HE SLAUGHTERED DAVID IAIN GREIG, WITH
A ROUNDHOUSE KICK. HE BEAT HARRIS TO DEATH, AND SENT FIRE TO DR.
NYIKOS. NOW, RICHARD DAWKINS SETS OUT WITH FIRE, TO HUNT THRINAXODON.
THRINAOXDON USES WATER TO SHED OFF THE WATER, AND SHITS ON DAWKINS'
HEAD, AND DAWKINS DIES!!! THRINAXODON WINS.

===

HERE'S THRINAXODON SCARING SOMEONE TO DEATH.
http://www.youtube.com/watch?v=9Zlzin6PIo8

==
Thrinaxodon, in the form of prion, infecting this person's temporal
lobe, and causing DEATH SLOWLY
http://upload.wikimedia.org/wikipedia/commons/thumb/2/2e/CJD_spongios...
___
___
YE EVILUTIONISTS, THEY INFECT THE SOUL AND GIVE YOU NIGHTMARES. THEY
GIVE YOU...
EVVVOOLUTIONISTS DESEASE!
___
_
PROOF OF GHOSTS!!!
http://media.tumblr.com/tumblr_lxlws5u4tE1qjlz5q.jpg
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PyWart: The problem with print

On Mon, 03 Jun 2013 15:09:48 -0400, Jason Swails wrote:

 But unlike RR, who suggests some elaborate interpreter-wide, ambiguous
 ignore-rule to squash out all of these functions, I'm simply suggesting
 that sometimes it's worth commenting-out debug print calls instead of
 'just leaving them there because you won't notice the cost' :).

+1

Further to this idea, many command line apps have a verbose mode, where 
they print status messages as the app runs. Some of these include 
multiple levels, so you can tune just how many messages you get, commonly:

- critical messages only
- important or critical messages
- warnings, important or critical messages
- status, warnings, important or critical messages
- all of the above, plus debugging messages
- all of the above, plus even more debugging messages

Since this verbosity level is selectable at runtime, the code itself must 
include many, many calls to some equivalent to print, enough calls to 
print to cover the most verbose case, even though most of the time most 
such calls just return without printing.

This is a feature. And like all features, it has a cost. If (generic) 
your application does not benefit from verbose print statements scattered 
all throughout it, *don't put them in*. But if it will, then there is a 
certain amount of overhead to this feature. Deal with it, either by 
accepting the cost, or by writing more code that trades off complexity 
for efficiency. It's 2013, not 1975, and computers have more than 32K of 
RAM and the slowest CPU on the market is a million times faster than the 
ones that took us to the moon, and quite frankly I have no sympathy for 
the view that CPU cycles are so precious that we mustn't waste them. If 
that were the case, Python is the wrong language.



-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PyWart: The problem with print

On Tue, Jun 4, 2013 at 6:31 AM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
 ... quite frankly I have no sympathy for
 the view that CPU cycles are so precious that we mustn't waste them. If
 that were the case, Python is the wrong language.

CPU cycles *are* valuable still, though. The efficiency of your code
determines how well it scales - but we have to be talking 100tps vs
1000tps here. There needs to be a huge difference for it to be at all
significant.

ChrisA
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How to get an integer from a sequence of bytes

2013-06-03 Thread Dave Angel


On 06/03/2013 10:31 AM, Grant Edwards wrote:

On 2013-06-03, Dennis Lee Bieber wlfr...@ix.netcom.com wrote:

On Sun, 02 Jun 2013 21:25:45 +0200, Mok-Kong Shen
mok-kong.s...@t-online.de declaimed the following in
gmane.comp.python.general:



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


In other languages byte is an 8-bit signed/unsigned numeric.


That's a common assumption, but historically, a byte was merely the
smallest addressable unit of memory.  The size of a byte on widely
used used CPUs ranged from 4 bits to 60 bits.



Hehe I recall rewriting the unpacking algorithm to get the 10 
characters from each byte, on such a machine.



--
DaveA
--
http://mail.python.org/mailman/listinfo/python-list

RE: Apache and suexec issue that wont let me run my python script

 From: a...@sci.fi
 Subject: Re: Apache and suexec issue that wont let me run my python script
 Date: Mon, 3 Jun 2013 18:20:00 +0300
 To: python-list@python.org

 Νικόλαος Κούρας nikos.gr...@gmail.com writes:

 [code]
 root@nikos [/home/nikos/www/cgi-bin]# chmod g+w /var/log/httpd/suexec.log
 root@nikos [/home/nikos/www/cgi-bin]# ls -l /var/log/httpd/suexec.log
 -rw-rw-r-- 1 root root 0 Jun 1 02:52 /var/log/httpd/suexec.log
 [/code]

 and still iam receiving the same error.

 What did you hope to accomplish with this second chmod? Nobody is in the
 root group except root. I hope. My guess based on very minimal Googling
 on the topic is you should change the group of /var/log/httpd/suexec.log
 to apache.

 Then again, I have no idea why you have both
 /usr/local/apache/logs/suexec_log and /var/log/httpd/suexec.log, but the
 former apparently has some data in it and the latter does not so
 changing permissions on /var/log/httpd/suexec.log may not help...

'/var/log/httpd' is the default place for the Red Hat and CentOS installation 
of httpd.

'/usr/local/apache/logs' is the default directory of the Apache httpd 
installation.

httpd has probably been upgraded by 'make install'.

 Oh, apparently suexec prints its config if you run suexec -V, so include
 that output if you still have problems.
 --
 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

2013-06-03 Thread Grant Edwards

On 2013-06-03, Dave Angel d...@davea.name wrote:
 On 06/03/2013 10:31 AM, Grant Edwards wrote:
 On 2013-06-03, Dennis Lee Bieber wlfr...@ix.netcom.com wrote:
 On Sun, 02 Jun 2013 21:25:45 +0200, Mok-Kong Shen
 mok-kong.s...@t-online.de declaimed the following in
 gmane.comp.python.general:


 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

 In other languages byte is an 8-bit signed/unsigned numeric.

 That's a common assumption, but historically, a byte was merely the
 smallest addressable unit of memory.  The size of a byte on widely
 used used CPUs ranged from 4 bits to 60 bits.


Hehe I recall rewriting the unpacking algorithm to get the 10 
 characters from each byte, on such a machine.

Yep.  IIRC there were CDC machines (Cyber 6600?) with a 60-bit wide
byte and a 6-bit wide upper-case-only character set.  ISTM that the
Pascal compiler limited you to 6 significant characters in variable
names so that it could use a simple single register compare while
doing symbol lookups...

I think some IBM machines had 60-bit bytes as well.

-- 
Grant Edwards   grant.b.edwardsYow! DIDI ... is that a
  at   MARTIAN name, or, are we
  gmail.comin ISRAEL?
-- 
http://mail.python.org/mailman/listinfo/python-list

RE: Source code as text/plain


 Date: Mon, 3 Jun 2013 09:06:46 +1000
 From: c...@zip.com.au
 To: c...@rebertia.com
[...]
 http://hg.python.org/cpython/raw-file/tip/Lib/string.py

What's the 'tip' tag? 
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How to get an integer from a sequence of bytes

2013-06-03 Thread Dan Stromberg

On Mon, Jun 3, 2013 at 7:31 AM, Grant Edwards invalid@invalid.invalidwrote:

 That's a common assumption, but historically, a byte was merely the
 smallest addressable unit of memory.  The size of a byte on widely
 used used CPUs ranged from 4 bits to 60 bits.

 Quoting from http://en.wikipedia.org/wiki/Byte

 The size of the byte has historically been hardware
  dependent and no definitive standards existed that mandated the
  size.

 That's why IEEE standards always use the word octet when referring a
 value containing 8 bits.


When I was a Freshman in college, I used a CDC Cyber a lot; it had 6 bit
bytes and 60 bit words.  This was in 1985.

Today though, it would be difficult to sell a conventional (Von Neumann)
computer that didn't have 8 bit bytes.  Quantum computers would still sell
if they were odd this way - they're going to be really different anyway.
-- 
http://mail.python.org/mailman/listinfo/python-list

RE: [RELEASED] Python 2.7.5

 From: na...@animats.com
 Subject: Re: [RELEASED] Python 2.7.5
 Date: Mon, 3 Jun 2013 12:20:43 -0700
[...]
 3.x is a different language, with different libraries, and lots of
 things that still don't work. Many old applications will never
 be converted.

 John Nagle

What still doesn't work in Python 3?

Is Python 2.7.5 last (final, never to be updated) revision or will it still be 
supported? 
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Changing filenames from Greeklish = Greek (subprocess complain)

(Note: this post is sent using UTF-8. If anyone reading this sees 
mojibake, please make sure your email or news client is set to use UTF-8.)



On Mon, 03 Jun 2013 05:54:30 -0700, rusi wrote:

 On Jun 3, 2:12 pm, Νικόλαος Κούρας nikos.gr...@gmail.com wrote:
 You are right Steven, i just renames the file 'Euxi tou Ihsou.mp3' =
 'Eõ÷Þ ôïõ Éçóïý.mp3' and…
 
 Is that how you renamed your file?
 In any case thats what I see!!

rusi, whatever program you are using to read these posts is buggy.

Nicholas (please excuse me ASCII-fying his name, but given that we are 
discussing encoding problems, it is probably for the best) sent his post 
with a header line:

charset=ISO-8859-7

If your client honoured that charset line, you would see:

Eυχή του Ιησού.mp3

It looks like your client is ignoring the charset header, and 
interpreting the bytes as Latin-1 when they are actually ISO-8859-7.

py s = 'Eυχή του Ιησού.mp3'
py print(s.encode('ISO-8859-7').decode('latin-1'))
Eõ÷Þ ôïõ Éçóïý.mp3

which matches what you see. If you can manually tell your client to use 
ISO-8859-7, you should see it correctly.



-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Changing filenames from Greeklish = Greek (subprocess complain)

On Mon, 03 Jun 2013 02:12:31 -0700, Νικόλαος Κούρας wrote:

Τη Δευτέρα, 3 Ιουνίου 2013 9:46:46 π.μ. UTC+3, ο χρήστης Steven D'Aprano
έγραψε:

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?

Fix those file names, and hopefully the problem will go away.

You are right Steven, i just renames the file 'Euxi tou Ihsou.mp3' =
'Eυχή του Ιησού.mp3' and here is how it appears the filename directory
listing via Chrome.

http://superhost.gr/data/apps/

I doesn't display the file with proper Greek characters but with
*Mojibake* instead.

Not so -- it actually shows correctly, provided you use the right
encoding. Tell your browser to view the page as UTF-8, and the file name
is displayed correctly.

By default, my browser Iceweasel views the page as Latin-1, which
displays like this:

Î•Ï…Ï‡Î® Ï„Î¿Ï… Î™Î·ÏƒÎ¿Ï.mp3

so the first thing you need to fix is to find some way to tell Apache to
include a UTF-8 encoding line in its automatically generated pages. Then
at least it will display correctly for visitors.

I now tentatively believe that the file names are correct, using the UTF-8
encoding. But you can help confirm this:

* What operating system are you using? If Linux, what distro and version?

* What is the output of the locale command?

--
Steven
--
http://mail.python.org/mailman/listinfo/python-list

Re: [RELEASED] Python 2.7.5

On Tue, Jun 4, 2013 at 8:37 AM, Carlos Nepomuceno
carlosnepomuc...@outlook.com wrote:

 From: na...@animats.com
 Subject: Re: [RELEASED] Python 2.7.5
 Date: Mon, 3 Jun 2013 12:20:43 -0700
 [...]
 3.x is a different language, with different libraries, and lots of
 things that still don't work. Many old applications will never
 be converted.

 John Nagle

 What still doesn't work in Python 3?

 Is Python 2.7.5 last (final, never to be updated) revision or will it still 
 be supported?

There won't be a Python 2.8 (at least, not from python.org), so there
won't be any feature additions to the Python 2 line. It'll be
supported in terms of bugfixes for a good while though, see PEP 373
[1], and of course distributions can do their own backporting of
patches for as long as they like (Red Hat will quite possibly want to
support old Pythons for a long time).

[1] http://www.python.org/dev/peps/pep-0373/

ChrisA
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Changing filenames from Greeklish = Greek (subprocess complain)

On Mon, 03 Jun 2013 02:32:42 -0700, Νικόλαος Κούρας wrote:

 Here is the whole code of files.py in case someone wants to comment on
 somethign about how to properly encode/decode the filanames, which seems
 to be the problem.
 
 http://pastebin.com/qXasy5iU


Second line in the file says:

import cgi, re, os, sys, socket, datetime, pymysql, locale


but there is no pymysql module available. Fix that problem, and then we 
can look at the next problem.


-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: [RELEASED] Python 2.7.5

2013-06-03 Thread Mark Lawrence

On 03/06/2013 23:37, Carlos Nepomuceno wrote:

From: na...@animats.com
Subject: Re: [RELEASED] Python 2.7.5
Date: Mon, 3 Jun 2013 12:20:43 -0700

[...]

3.x is a different language, with different libraries, and lots of
things that still don't work. Many old applications will never
be converted.

John Nagle

What still doesn't work in Python 3?

http://python3wos.appspot.com/

Is Python 2.7.5 last (final, never to be updated) revision or will it still be 
supported?   

http://www.python.org/dev/peps/pep-0373/

--
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: How to get an integer from a sequence of bytes

 Date: Mon, 3 Jun 2013 15:41:41 -0700 
 Subject: Re: How to get an integer from a sequence of bytes 
 From: drsali...@gmail.com 
 To: python-list@python.org 
[...]
 Today though, it would be difficult to sell a conventional (Von  
 Neumann) computer that didn't have 8 bit bytes.  Quantum computers  
 would still sell if they were odd this way - they're going to be really  
 different anyway. 

Nowadays it would be a hard task to find a Von Neumann architecture machine.

Most of current CPUs are variants of the Harvard architecture: they separate 
instructions from data at the cache level.  

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Apache and suexec issue that wont let me run my python script

2013-06-03 Thread Michael Torrie

On 06/03/2013 04:13 PM, Carlos Nepomuceno wrote:
 '/var/log/httpd' is the default place for the Red Hat and CentOS installation 
 of httpd.
 
 '/usr/local/apache/logs' is the default directory of the Apache httpd 
 installation.
 
 httpd has probably been upgraded by 'make install'.

Oh wow.  What a mess.  I think Nick needs to read a good book on Red Hat
EL system administration.  Think he needs to start over with a fresh
install of CentOS and only install software that comes from a repo using
yum until he learns what he's doing.
-- 
http://mail.python.org/mailman/listinfo/python-list

RE: [RELEASED] Python 2.7.5

Thank you! :)

 To: python-list@python.org
 From: breamore...@yahoo.co.uk
[...]
 What still doesn't work in Python 3?

 http://python3wos.appspot.com/

 Is Python 2.7.5 last (final, never to be updated) revision or will it still 
 be supported?

 http://www.python.org/dev/peps/pep-0373/

 --
 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: Apache and suexec issue that wont let me run my python script

 Date: Mon, 3 Jun 2013 17:23:16 -0600
 From: torr...@gmail.com
 To: python-list@python.org
 Subject: Re: Apache and suexec issue that wont let me run my python script

 On 06/03/2013 04:13 PM, Carlos Nepomuceno wrote:
 '/var/log/httpd' is the default place for the Red Hat and CentOS 
 installation of httpd.

 '/usr/local/apache/logs' is the default directory of the Apache httpd 
 installation.

 httpd has probably been upgraded by 'make install'.

 Oh wow. What a mess. I think Nick needs to read a good book on Red Hat
 EL system administration. Think he needs to start over with a fresh
 install of CentOS and only install software that comes from a repo using
 yum until he learns what he's doing.
 --
 http://mail.python.org/mailman/listinfo/python-list

I did a httpd 'make install' on CentOS 6 and it worked fine. Needed a few 
tweaks that I don't remember though.

If you don't have any previous experience with Apache httpd settings I wouldn't 
try that on a production server.  
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How to get an integer from a sequence of bytes

2013-06-03 Thread Dan Stromberg

On Mon, Jun 3, 2013 at 4:18 PM, Carlos Nepomuceno 
carlosnepomuc...@outlook.com wrote:

  Date: Mon, 3 Jun 2013 15:41:41 -0700
  Subject: Re: How to get an integer from a sequence of bytes
  From: drsali...@gmail.com
  To: python-list@python.org
 [...]
  Today though, it would be difficult to sell a conventional (Von
  Neumann) computer that didn't have 8 bit bytes.  Quantum computers
  would still sell if they were odd this way - they're going to be really
  different anyway.

 Nowadays it would be a hard task to find a Von Neumann architecture
 machine.

 Most of current CPUs are variants of the Harvard architecture: they
 separate instructions from data at the cache level.

I stand corrected.  Thank you.
-- 
http://mail.python.org/mailman/listinfo/python-list

AES 128 bits

2013-06-03 Thread usman mjoda

  Good day everyone, I need assistance for python codes of aes 128 bits key
that can be run on SAGE Application. Thanks

Sent from my Windows Phone
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PyWart: The problem with print

2013-06-03 Thread Rick Johnson

On Sunday, June 2, 2013 1:58:30 PM UTC-5, Steven D'Aprano wrote:
 On Sun, 02 Jun 2013 10:04:00 -0700, Rick Johnson wrote:

Oh Steven, you've really outdone yourself this time with the
theatrics. I hope you scored some cool points with your
minions. Heck, you almost had me convinced until i slapped
myself and realized your whole argument is just pure BS. For
the sake of the lemmings, i must dissect your BS and expose
it's methane emitting innards for all to smell.

  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.
 [...]

And perhaps you should read a dictionary and obtain (at
minimum) a primary school level education in English before
making such foolish statements, because, OBVIOUSLY you don't
know the definition of syntactical sugar... shall i
educate you?



#   Wikipedia: syntactic sugar   #

# In computer science, syntactic sugar is syntax within a  #
# programming language that is designed to make things #
# easier to read or to express. It makes the language  #
# sweeter for human use: things can be expressed more#
# clearly, more concisely, or in an alternative style that #
# some may prefer[...] #


The print function is the very definition of a syntactic sugar.

For example:
print(some sting)

is much more readable than:

sys.stdout.write(some string+\n)

or:

sys.stderr.write(some string+\n)

or:

streamFoo.write(blah)

But wait, there's more!


# Wikipedia: syntactic sugar (continued) #

# [...]Specifically, a construct in a language is called   #
# syntactic sugar if it can be removed from the language   #
# without any effect on what the language can do:  #
# functionality and expressive power will remain the same. #


Again, the removal of a print function (or print statement)
will not prevent users from calling the write method on
sys.stdout or sys.stderr (or ANY stream object for that matter!)

The only mistake i made was to specify stdout.write
specifically instead of generally referring to the print
function as a sugar for stream.write().

  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!!!
 Only if you're a lousy programmer who doesn't understand Python's truth
 model.

I understand the Python truth model quite well, i just don't
happen to like it. Implicit conversion to Boolean breaks the
law of least astonishment.

Many times you'll get a result (or an input) that you expect
to be a Boolean, but instead is a string. A good example of
poor coding is dialog box return values. Take your
standard yes/no/cancel dialog, i would expect it to return
True|False|None respectively, HOWEVER, some *idiot* decided
to return the strings 'yes'|'no'|'cancel'.

If you tried to bool test a string (In a properly designed
language that does NOT support implicit Boolean conversion)
you would get an error if you tried this:

  py string =  
  py if string:
  ... do_something()
  ERROR: Cannot convert string to Boolean!

However, with Python's implicit conversion to Boolean, the
same conditional will ALWAYS be True: because any string
that is not the null string is True (as far as Python is
concerned). This is an example of Python devs breaking TWO
Zens at once:

 explicit is better than implicit
 errors should NEVER pass silently

And even though Python does not raise an error, it should!

  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

Re: AES 128 bits

2013-06-03 Thread Denis McMahon

On Tue, 04 Jun 2013 07:52:17 +0800, usman mjoda wrote:

 Good day everyone, I need assistance for python codes of aes 128 bits
 key that can be run on SAGE Application. Thanks

google pycrypto

-- 
Denis McMahon, denismfmcma...@gmail.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Pillow lib for x86_64 GNU/Linux

2013-06-03 Thread Jeff SKI Kinsey

Sorry. Should have been more clear. 

This is a hosting account server. I am not in the sudoers file.

Was able to get PIL v1.1.7 to create a tiff file. Problem solved.

Thanks.

On Monday, June 3, 2013 12:41:17 PM UTC-4, Irmen de Jong wrote:
 On 3-6-2013 18:23, consult...@gmail.com wrote:
 
  It is great that Pillow wants to be setuptools compatible but without a 
  suitable compiled library for x86_64 GNU/Linux, I am stuck between a rock 
  and a hard place.
 
  
 
  Any suggestions?
 
  
 
 
 
 Try your distribution's package repository.
 
 
 
 $ sudo apt-get install python-pillow
 
 
 
 Or failing that,
 
 
 
 $ sudo apt-get install python-imaging
 
 
 
 
 
 Worked fine for me (Ubuntu 64-bit)
 
 
 
 Irmen
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PyWart: The problem with print

2013-06-03 Thread Vito De Tullio

Rick Johnson wrote:

 Take your
 standard yes/no/cancel dialog, i would expect it to return
 True|False|None respectively,

you clearly mean True / False / FileNotFound.

( http://thedailywtf.com/Articles/What_Is_Truth_0x3f_.aspx )

-- 
ZeD

-- 
http://mail.python.org/mailman/listinfo/python-list

Beginner question

2013-06-03 Thread eschneider92

Is there a more efficient way of doing this? Any help is gratly appreciated.


import random
def partdeux():
print('''A man lunges at you with a knife!
Do you DUCK or PARRY?''')
option1=('duck')
option2=('parry')
optionsindex=[option1, option2]
randomizer=random.choice(optionsindex)
while randomizer==option1:
if input() in option1:
print('he tumbles over you')
break
else:
print('he stabs you')
break
while randomizer==option2:
if input() in option2:
print('you trip him up')
break
else:
print('he stabs you')
break
partdeux()
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PyWart: The problem with print

2013-06-03 Thread Rick Johnson

On Monday, June 3, 2013 10:16:13 PM UTC-5, Vito De Tullio wrote:
 Rick Johnson wrote:
  Take your
  standard yes/no/cancel dialog, i would expect it to return
  True|False|None respectively,
 you clearly mean True / False / FileNotFound.

No, i clearly meant what i said :-). FileDialogs only return
one of two values; either a valid path or a value
representing failure. I suppose FileNotFound is a custom
exception? That will work however i wonder if exception
handling is overkill for this?

  try:
  path = filedialog.open(path)
  except FileNotFound:
  return
  do_something(path)

As opposed to:

  path = filedialog.open(path)
  if path:
  do_something(path)

Or, if Python was really cool!

  if filedialog.open(path) as path:
  do_something(path)

However, i think True|False|None is the best return values
for a yes|no|cancel choice. Consider:

  result = yesnocancel(save changes?)
  if result:
  # Try to save changes and close.
  if self.fileSave():
  app.close()
  else:
  show_error()
  elif result is False:
  # Close without saving changes.
  app.close()
  else:
  # Canceled: Do nothing.
  return
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PyWart: The problem with print

On Tue, 04 Jun 2013 05:16:13 +0200, Vito De Tullio wrote:

 Rick Johnson wrote:
 
 Take your
 standard yes/no/cancel dialog, i would expect it to return
 True|False|None respectively,
 
 you clearly mean True / False / FileNotFound.
 
 ( http://thedailywtf.com/Articles/What_Is_Truth_0x3f_.aspx )


No no, he actually means 

return True
return False
raise an exception


Or perhaps 

0
1
2

Or perhaps:

'yes'
'no'
'cancel'

like all right-thinking people expect *wink*

Of course the one thing that a programmer should never, ever do, under 
pain of maybe having to learn something, is actually check the 
documentation of an unfamiliar library or function before making 
assumptions of what it will return. If you follow this advice, you too 
can enjoy the benefits of writing buggy code.



-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Changing filenames from Greeklish = Greek (subprocess complain)

2013-06-03 Thread rusi

On Jun 4, 3:37 am, Steven D'Aprano steve
+comp.lang.pyt...@pearwood.info wrote:
 (Note: this post is sent using UTF-8. If anyone reading this sees
 mojibake, please make sure your email or news client is set to use UTF-8.)

 On Mon, 03 Jun 2013 05:54:30 -0700, rusi wrote:
  On Jun 3, 2:12 pm, Νικόλαος Κούρας nikos.gr...@gmail.com wrote:
  You are right Steven, i just renames the file 'Euxi tou Ihsou.mp3' =
  'Eõ÷Þ ôïõ Éçóïý.mp3' and…

  Is that how you renamed your file?
  In any case thats what I see!!

 rusi, whatever program you are using to read these posts is buggy.

When you go to the python mailing list archive and look at Nikos mail
http://mail.python.org/pipermail/python-list/2013-June/648301.html
I see
META http-equiv=Content-Type content=text/html; charset=us-ascii

[Not claiming to understand all this unicode stuff...]
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Apache and suexec issue that wont let me run my python script

2013-06-03 Thread Michael Torrie

On 06/03/2013 05:33 PM, Carlos Nepomuceno wrote:
 I did a httpd 'make install' on CentOS 6 and it worked fine. Needed a
 few tweaks that I don't remember though.
 
 If you don't have any previous experience with Apache httpd settings
 I wouldn't try that on a production server.

Precisely.  Given his experience levels, installing httpd from source is
recipe for disaster.  He's now going to have to track security flaw
reports manually, try to figure out which ones apply to him, and keep
his apache up to date.  I can't think of anything he'd need in Apache
that's not in the CentOS packages.  I've sys-admined for years and I've
never ever needed an Apache outside out of the repos.  Sometimes I
needed other things I had to build from source, but never apache.
-- 
http://mail.python.org/mailman/listinfo/python-list

Bools and explicitness [was Re: PyWart: The problem with print]

On Mon, 03 Jun 2013 18:37:24 -0700, Rick Johnson wrote:
 On Sunday, June 2, 2013 1:58:30 PM UTC-5, Steven D'Aprano wrote:
 On Sun, 02 Jun 2013 10:04:00 -0700, Rick Johnson wrote:

  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:
 
 Obviously you don't appreciate the value of explicit enough.
 
   if VALUE:
 
 is not explicit enough, however

Consider a simple thought experiment. Suppose we start with a sequence of 
if statements that begin simple and get more complicated:

if a == 1: ...

if a == 1 and b  2*c: ...

if a == 1 and b  2*c or d%4 == 1: ...

if a == 1 and b  2*c or d%4 == 1 and not (d**3//7)%3 == 0: ...


I don't believe that any of these tests are improved by adding an 
extraneous == True at the end:

if (a == 1) == True: ...

if (a == 1 and b  2*c) == True: ...

if (a == 1 and b  2*c or d%4 == 1) == True: ...

if (a == 1 and b  2*c or d%4 == 1 and not (d**3//7)%3 == 0) == True: ...

At some point your condition becomes so complicated that you may wish to 
save it as a separate variable, or perhaps you need to check the flag in 
a couple of places and so calculate it only once. Moving the flag out 
into a separate variable doesn't make == True any more useful or 
helpful.

flag = a == 1
if flag == True: ...


But even if it did, well, you've just entered the Twilight Zone, because 
of course flag == True is just a flag, so it too needs to be tested 
with == True:

flag = (a == 1) == True
if flag == True: ...

but that too is just a flag so it needs more explicitness... and so on 
forever. This conclusion is of course nonsense. Adding == True to your 
boolean tests isn't helpful, so there's no need for even one, let alone 
an infinite series of == True.

if flag is as explicit as it needs to be. There's no need to 
artificially inflate the explicitness as if being explicit was good in 
and of itself. We don't normally write code like this:

n += int(1)

just to be explicit about 1 being an int. That would be redundant and 
silly. In Python, 1 *is* an int.


[...]
   if lst:
 
 I don't like that because it's too implict. What exactly about the list
 are we wanting to test?

If you are unfamiliar with Python, then you have to learn what the 
semantics of if lst means. Just as you would have to learn what 
if len(lst)  0 means.


 I prefer to be explicit at the cost of a few keystrokes:
 
   if len(lst)  0:

This line of code is problematic, for various reasons:

- you're making assumptions about the object which are unnecessary;

- which breaks duck-typing;

- and risks doing too much work, or failing altogether.

You're looking up the length of the lst object, but you don't really care 
about the length. You only care about whether there is something there or 
not, whether lst is empty or not. It makes no difference whether lst 
contains one item or one hundred million items, and yet you're asking to 
count them all. Only to throw that count away immediately!

Looking at the length of a built-in list is cheap, but why assume it is a 
built-in list? Perhaps it is a linked list where counting the items 
requires a slow O(N) traversal of the entire list. Or some kind of lazy 
sequence that has no way of counting the items remaining, but knows 
whether it is exhausted or not.

The Python way is to duck-type, and to let the lst object decide for 
itself whether it's empty or not:

if lst: ...


not to make assumptions about the specific type and performance of the 
object.


 Consider the following:
 
  What if the symbol `value` is expected to be a list, however, somehow
  it accidentally got reassigned to another type. If i choose to be
  implicit and use: if value, the code could silently work for a type i
  did not intend, therefore the program could go on for quite some time
  before failing suddenly on attribute error, or whatever.

`if len(lst)  0` also works for types you don't intend. Any type that 
defines a __len__ method which returns an integer will do it.

Tuples, sets and dicts are just the most obvious examples of things that 
support len() but do not necessarily support all the things you might 
wish to do to a list.



 However, if i choose to be explicit and use:
 
   if len(VALUE)  0:
 
 then the code will fail when it should: at the comparison line.

Except of course when it doesn't.


 Because
 any object that does not provide a __len__ method would cause Python to
 raise NameError.

TypeError.



 By being explicit enough i will inject readability and safety into my
 code base. 

Unnecessary verbosity and redundancy,

Re: Changing filenames from Greeklish = Greek (subprocess complain)