Re: Python Heisenbugs? (was: Re: PyWart: The problem with "print")

[Devin Jeanpierre]

On Mon, Jun 3, 2013 at 12:34 AM, 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?

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"

[Chris Angelico]

On Mon, Jun 3, 2013 at 3:49 PM, Michael Torrie  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)

[Chris Angelico]

On Mon, Jun 3, 2013 at 4:46 PM, Steven D'Aprano
 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 "", line 1, in 
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

[Steven D'Aprano]

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"

[Alister]

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

> On Mon, Jun 3, 2013 at 3:49 PM, Michael Torrie 
> 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"

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

[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

[Fábio Santos]

On 3 Jun 2013 09:04, "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([])".
>

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)

[Chris Angelico]

On Mon, Jun 3, 2013 at 7:00 PM, Mark Lawrence  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)

[Νικόλαος Κούρας]

Τη Δευτέρα, 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)

[Νικόλαος Κούρας]

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"

[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?

[Joshua Landau]

On 3 June 2013 04:18, Chris Angelico  wrote:
> 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 :)

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

[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-js

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

[rusi]

On Jun 3, 2:12 pm, Νικόλαος Κούρας  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"

[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

[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

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

[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

[Grant Edwards]

On 2013-06-03, Dennis Lee Bieber  wrote:
> On Sun, 02 Jun 2013 21:25:45 +0200, Mok-Kong Shen
> 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?

[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

[Carlos Nepomuceno]

> 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  
> mailto:carlosnepomuc...@outlook.com>>  
> wrote: 
>  
> > Date: Sun, 2 Jun 2013 15:12:43 +1000 
> > From: koobs.free...@gmail.com 
> > To: 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?

[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

[Anssi Saari]

Νικόλαος Κούρας  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

[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

[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"

[Ian Kelly]

On Sun, Jun 2, 2013 at 6:16 PM, Jason Swails  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?

[Ian Kelly]

On May 31, 2013 6:27 PM, "Chris Angelico"  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?

[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"

[Jason Swails]

On Mon, Jun 3, 2013 at 1:12 PM, Ian Kelly  wrote:

> On Sun, Jun 2, 2013 at 6:16 PM, Jason Swails 
> 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"

[Jason Swails]

On Mon, Jun 3, 2013 at 1:12 PM, Ian Kelly  wrote:

> On Sun, Jun 2, 2013 at 6:16 PM, Jason Swails 
> 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"

[Jason Swails]

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

Re: [RELEASED] Python 2.7.5

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

[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...
EVVVOOLUTIONIST"S 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"

[Steven D'Aprano]

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"

[Chris Angelico]

On Tue, Jun 4, 2013 at 6:31 AM, Steven D'Aprano
 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

[Dave Angel]

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

On 2013-06-03, Dennis Lee Bieber  wrote:

On Sun, 02 Jun 2013 21:25:45 +0200, Mok-Kong Shen
 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.



 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

[Carlos Nepomuceno]

> 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
>
> Νικόλαος Κούρας  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

[Grant Edwards]

On 2013-06-03, Dave Angel  wrote:
> On 06/03/2013 10:31 AM, Grant Edwards wrote:
>> On 2013-06-03, Dennis Lee Bieber  wrote:
>>> On Sun, 02 Jun 2013 21:25:45 +0200, Mok-Kong Shen
>>>  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.
>>
>
> 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

[Carlos Nepomuceno]

> 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

[Dan Stromberg]

On Mon, Jun 3, 2013 at 7:31 AM, Grant Edwards wrote:

> 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

[Carlos Nepomuceno]

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

[Steven D'Aprano]

(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, Νικόλαος Κούρας  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)

[Steven D'Aprano]

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

[Chris Angelico]

On Tue, Jun 4, 2013 at 8:37 AM, 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?
>
> 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)

[Steven D'Aprano]

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

[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

[Carlos Nepomuceno]

> 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

[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

[Carlos Nepomuceno]

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

[Carlos Nepomuceno]

> 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

[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

[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"

[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,

Re: AES 128 bits

[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

[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"

[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

[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"

[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"

[Steven D'Aprano]

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)

[rusi]

On Jun 4, 3:37 am, Steven D'Aprano  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, Νικόλαος Κούρας  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


[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

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

[Steven D'Aprano]

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 "e

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

[Steven D'Aprano]

On Mon, 03 Jun 2013 21:35:13 -0700, rusi wrote:

> On Jun 4, 3:37 am, Steven D'Aprano  +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, Νικόλαος Κούρας  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
> 

You're looking at the encoding of the HTML page which displays only the 
body and a few selected headers, copied from Nikos' post. It has no 
connection to the encoding of the post itself.

If you're using Thunderbird, or some other mail/news client, there is 
usually an option to View Raw Post or View Entire Message or something 
similar. Use that on the original post, not the web archive.


> [Not claiming to understand all this unicode stuff...]

:-)


Start here:

http://www.joelonsoftware.com/articles/Unicode.html

http://nedbatchelder.com/text/unipain.html



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

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

[nagia . retsina]

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

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

I can't believe Chrome whcih by default uses utf8 chosed iso-8859-1 to presnt 
the filenames.
You were right Steven, when i explicitly told him to presnt page sin utf8 it 
then started to show tha filesname correctly.
 
> 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?

First of all thank you very much for being so cooperative, i appreciate it.

Here is some of my system insight you wanted to see.


ni...@superhost.gr [~]# uname -a
Linux nikos.superhost.gr 2.6.32-042stab075.2 #1 SMP Tue May 14 20:38:14 MSK 
2013 x86_64 x86_64 x86_64 GNU/Linux

ni...@superhost.gr [~]# locale
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=
ni...@superhost.gr [~]#

I'am using CentOS v6.4 becaue it is the only linux OS that supports cPanel 
which my clients need to administer their websites.

Hese is also how the terminal presents my filenames.

ni...@superhost.gr [~]# ls -l www/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 [~]#

Its wird, because as locale showed from above terminal is set to 'utf-8' but 
the greek filename cannot be viewed properly.
I must say though, that i have renamed it from my Windows 8 system and then 
uploaded via FileZilla to my remote webhost server. Maybe windows 8 is causing 
this?

I'll try renaming it via terminal too.
f you want to see soemhtign  else please ask me to show you Steven.

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

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

[Νικόλαος Κούρας]

Could you please install them because i need to work?

a) pip (so that i can successfully run 'pip install pymysql'
b) development tools

I wiped the while perl away (leaving intact 2.6) but i wiped out pip at the 
proces to.
-- 
http://mail.python.org/mailman/listinfo/python-list

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

[Νικόλαος Κούρας]

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

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

I think is this is the case too steven, but it suprises me that Chrome ignores 
the charset header.

Actually when i toild explicitly Chrome to display everythign as utf-8 it 
presented the filanem properly.

py> print(s.encode('ISO-8859-7').decode('latin-1')) 

Why you are encoding the 's' string to greek-iso?
Isn't it by itself in greek-iso since it uses greek letters?
-- 
http://mail.python.org/mailman/listinfo/python-list

RE: Beginner question

[Carlos Nepomuceno]

That doesn't even works because input() is the same as eval(raw_input()). So 
you'll get a NameError exception.

I think you know that. Perhaps you mean raw_input() instead of input().
In that case the answer is yes, it can be more 'efficient' because the 
if-then-else clause always breaks the while loop.
I think you are looking for is a switch statement, which Python don't have.

You can use the following structure to emulate a switch statement:

def function1():
if raw_input() in option1:
print('he tumbles over you')
else:
print('he stabs you')

def function2():
if raw_input() in option2:
print('you trip him up')
else:
print('he stabs you')

def default():
print 'DEFAULT'

switch = {
option1: function1,
option2: function2
}
switch.get(randomizer, default)()

Note that switch is a dictionary and you can use it without creating a 
variable, for example:

{   option1: function1,
option2: function2
}.get(randomizer, default)()


> Date: Mon, 3 Jun 2013 20:39:28 -0700
> Subject: Beginner question
> From: eschneide...@comcast.net
> To: python-list@python.org
> 
> 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
  -- 
http://mail.python.org/mailman/listinfo/python-list