Re: Unicode in Python

[Rustom Mody]

On Wednesday, April 23, 2014 11:22:33 AM UTC+5:30, Steven D'Aprano wrote:

> 25 Unicode characters down, 1114000+ to go :-)

The question would arise if there was some suggestion to add
1114000(+) characters to the syntactic/lexical definition of python.

IOW while its true that unicode is a character-set, its better to think
of it as a repertory  -- here is the universal set from which a choice is 
available.

On Wednesday, April 23, 2014 11:20:35 AM UTC+5:30, Chris Angelico wrote:
> On Wed, Apr 23, 2014 at 3:31 PM, Rustom Mody wrote:
> > Chris Angelico wrote:
> >> it's impossible for most people to type (and programming with a palette
> >> of arbitrary syntactic tokens isn't my idea of fun)...
> > Where's the suggestion to use a "palette of arbitrary tokens" ?
> > I just tried a greek keyboard; ie do
> > $ setxkbmap -option "grp:switch,grp:alt_shift_toggle,grp_led:scroll" 
> > -layout "us,gr"
> > Thereafter typing
> > abcdefghijklmnopqrstuvwxyz
> > after a Shift-Alt
> > gives
> > αβψδεφγηιξκλμνοπ;ρστθωςχυζ
> > One more Shift-Alt and back to roman

> Okay. Now what about your other symbols? Your alternative assignment
> operator, for instance. How do you type that?

In case you missed it, I said:

> Of course
> - One would need to define such a keyboard (setxkb)
> - One would have to find similar technologies for other OSes

In more detail:
In our normal use of a US-104 keyboard, every letter 'costs' something.
eg 'a' costs 1 keystroke
   'A' costs 2 (Shift+a)
Most people do not count that as a significant cost.
and when kids come on this list and talk smsese -- i wanna do so-n-so

we chide them for keystrokes at the cost of readability.

In such a (default) setup typing a ∧ or ∨ is not possible at all without
something like a char-picker and at best has an ergonomic cost that is an
order of magnitude higher than the 'naturally available' characters.

On the other hand when/if a keyboard mapping is defined in which
the characters that are commonly needed are available, it is
reasonable to expect the ∨,∧ to cost no more than 2 strokes each
(ie about as much as an 'A'; slightly more than an 'a'. Which means
that '∨' is expected to cost about the same as 'or' and ∧ to cost less than an 
'and'

Readability is another question altogether.
Random example from my machine
calendar.py line 99
If one finds this:

return year % 4 == 0 and (year % 100 != 0 or year % 400 == 0)

more readable than
return year%4=0 ∧ (year%100≠0  ∨  year%100 = 0)
then perhaps the following is the most preferred?

COMPUTE YEAR MODULO 4 EQUALS 0 AND YEAR MODULO 100 NOT
EQUAL TO ZERO OR YEAR MODULO 100 EQUAL to 0

IOW COBOL is desirable?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Unicode in Python

[Chris Angelico]

On Wed, Apr 23, 2014 at 4:57 PM, Rustom Mody  wrote:
> In such a (default) setup typing a ∧ or ∨ is not possible at all without
> something like a char-picker and at best has an ergonomic cost that is an
> order of magnitude higher than the 'naturally available' characters.
>
> On the other hand when/if a keyboard mapping is defined in which
> the characters that are commonly needed are available, it is
> reasonable to expect the ∨,∧ to cost no more than 2 strokes each
> (ie about as much as an 'A'; slightly more than an 'a'. Which means
> that '∨' is expected to cost about the same as 'or' and ∧ to cost less than 
> an 'and'

So how much effort are you going to go to for, effectively, the same
end result? You can type "or" with the same keystrokes, and it takes
zero setup work and zero memorization (you may forget which keystroke
you set up for ∨, but I doubt you'll forget how to spell "or", even if
you think it means gold/yellow). Where's the benefit? I'm seriously
not seeing it.

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

Re: Unicode in Python

[Steven D'Aprano]

On Tue, 22 Apr 2014 23:57:46 -0700, Rustom Mody wrote:

> perhaps the following is the most preferred?
> 
> COMPUTE YEAR MODULO 4 EQUALS 0 AND YEAR MODULO 100 NOT EQUAL TO ZERO OR
> YEAR MODULO 100 EQUAL to 0
> 
> IOW COBOL is desirable?

If the only choices are COBOL on one hand and the mutant offspring of 
Perl and APL on the other, I'd vote for COBOL.

But surely they aren't the only options, and it is possible to find a 
happy medium which is neither excessively verbose nor painfully, 
cryptically terse.

Remember that we're talking about general purpose programming here. There 
are domains which favour terseness and a vast number of symbols, e.g. 
mathematics, but most programming is not in that domain, even when it 
uses tools from that domain.


-- 
Steve
-- 
https://mail.python.org/mailman/listinfo/python-list

how to write list in a file

[Dhananjay]

Hello everyone,

I am trying hard to write a list to a file as follows:


def average_ELECT(pwd):
os.chdir(pwd)
files = filter(os.path.isfile, os.listdir('./'))
folders = filter(os.path.isdir, os.listdir('./'))
eelec = 0.0; evdw = 0.0; EELEC = []; elecutoff = [];
g = Gnuplot.Gnuplot()
for f1 in files:
#   if f1[21:23]=='12':
if f1[27:29]==sys.argv[1]: # vdw cutoff remains constant; see 2nd
column of output
fl1 = open(f1,'r').readlines()
#   print len(fl1)

for i in range(1, len(fl1)):
fl1[i]=fl1[i].split()
eelec = eelec + float(fl1[i][1])
evdw = evdw + float(fl1[i][2])
#print fl1[i][1], fl1[i][2]
avg_eelec = eelec/40
avg_evdw = evdw/40
#   print eelec, evdw
#   print f1[21:23], f1[27:29], avg_eelec, avg_evdw
print f1[21:23], f1[27:29], avg_eelec
#   EELEC.append(avg_eelec); elecutoff.append(float(f1[21:23]))
eelec=0.0; evde=0.0;
a = f1[21:23]+' '+f1[27:29]+' '+str(avg_eelec)
EELEC.append(a)
print sorted(EELEC)
with open('EElect_elec12-40_vdwxxx.dat','w') as wr:
for i in EELEC:
print i
wr.write("%s\n" % i)
wr.close()


The script is printing "print sorted(EELEC)" as well as "print f1[21:23],
f1[27:29], avg_eelec" very well.
However, for some reason, I neither see any file (expected to see
EElect_elec12-40_vdwxxx.dat as per the script) generated nor any error
message.

Could anyone suggest me correction here.

Thanking you in advance.

-- DJ
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Unicode in Python

[Steven D'Aprano]

On Tue, 22 Apr 2014 23:57:46 -0700, Rustom Mody wrote:

> On the other hand when/if a keyboard mapping is defined in which the
> characters that are commonly needed are available, it is reasonable to
> expect the ∨,∧ to cost no more than 2 strokes each (ie about as much as
> an 'A'; slightly more than an 'a'. Which means that '∨' is expected to
> cost about the same as 'or' and ∧ to cost less than an 'and'

Oh, a further thought...

Consider your example:

return year%4=0 ∧ (year%100≠0 ∨ year%100 = 0)

vs 

return year%4=0 and (year%100!=0 or year%100 = 0) 


[aside: personally I like ≠ and if there was a platform independent way 
to type it in any editor, I'd much prefer it over != or <> ]

Apart from the memorization problem, which I've already touched on, there 
is the mode problem. Keyboard layouts are modes, and you're swapping 
modes. Every time you swap modes, there is a small mental cost. Think of 
it as an interrupt which has to be caught, pausing the current thought 
and starting a new one. So rather than:

char char char char char char char ...

you have:

char char char INTERRUPT
char INTERRUPT
char char char ...


which is a heavier cost that it appears from just counting keystrokes. Of 
course, the more experienced you become, the smaller that cost will be, 
but it will never be quite as low as just a "regular" keystroke.

Normally, when people use multiple keyboards, its because that interrupt 
cost is amortized over a significant amount of typing:

INTERRUPT (English layout)
paragraph paragraph paragraph paragraph
INTERRUPT (Greek layout)
paragraph paragraph paragraph
INTERRUPT (English again)
paragraph ...

and possibly even lost in the noise of a far greater interrupt, namely 
task-switching from one application to another. So it's manageable. But 
switching layouts for a single character is likely to be far more 
painful, especially for casual users of that layout. 

Based on an extremely generous estimate that I use "lambda" four times in 
100 lines of code, I might use λ perhaps once in a thousand non-Greek 
characters. Similarly, I might use ∧ or ∨ maybe once per hundred 
characters. That means I'm unlikely to ever get familiar enough with 
those that the cost of two interrupts per use will be negligible.


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

Re: how to write list in a file

[David Palao]

2014-04-23 9:53 GMT+02:00 Dhananjay :
> Hello everyone,
>
> I am trying hard to write a list to a file as follows:
>
>
> def average_ELECT(pwd):
> os.chdir(pwd)
> files = filter(os.path.isfile, os.listdir('./'))
> folders = filter(os.path.isdir, os.listdir('./'))
> eelec = 0.0; evdw = 0.0; EELEC = []; elecutoff = [];
> g = Gnuplot.Gnuplot()
> for f1 in files:
> #   if f1[21:23]=='12':
> if f1[27:29]==sys.argv[1]: # vdw cutoff remains constant; see 2nd
> column of output
> fl1 = open(f1,'r').readlines()
> #   print len(fl1)
>
> for i in range(1, len(fl1)):
> fl1[i]=fl1[i].split()
> eelec = eelec + float(fl1[i][1])
> evdw = evdw + float(fl1[i][2])
> #print fl1[i][1], fl1[i][2]
> avg_eelec = eelec/40
> avg_evdw = evdw/40
> #   print eelec, evdw
> #   print f1[21:23], f1[27:29], avg_eelec, avg_evdw
> print f1[21:23], f1[27:29], avg_eelec
> #   EELEC.append(avg_eelec); elecutoff.append(float(f1[21:23]))
> eelec=0.0; evde=0.0;
> a = f1[21:23]+' '+f1[27:29]+' '+str(avg_eelec)
> EELEC.append(a)
> print sorted(EELEC)
> with open('EElect_elec12-40_vdwxxx.dat','w') as wr:
> for i in EELEC:
> print i
> wr.write("%s\n" % i)
> wr.close()
>
>
> The script is printing "print sorted(EELEC)" as well as "print f1[21:23],
> f1[27:29], avg_eelec" very well.
> However, for some reason, I neither see any file (expected to see
> EElect_elec12-40_vdwxxx.dat as per the script) generated nor any error
> message.
>
> Could anyone suggest me correction here.
>
> Thanking you in advance.
>
> -- DJ
>
>
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>

A couple of minor points:
* You don't need "wr.close()" after the "with open(...) as wr:" block.
* Are you sure that you are looking in the right directory?
* Why do you need the "g = Gnuplot.Gnuplot()" line? It looks to me
that you have skipped some things while doing copy and paste?

Best regards
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: object().__dict_

[Duncan Booth]

Pavel Volkov  wrote:

> There are some basics about Python objects I don't understand.
> Consider this snippet:
> 
 class X: pass
> ... 
 x = X()
 dir(x)
> ['__class__', '__delattr__', '__dict__', '__dir__', '__doc__',
> '__eq__', '__format__', '__ge__', '__getattribute__', '__gt__',
> '__hash__', '__init__', '__le__', '__lt__', '__module__', '__ne__',
> '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__',
> '__sizeof__', '__str__', '__subclasshook__', '__weakref__']
 x.foo = 11
> 
> And now I want to make a simple object in a shorter way, without
> declaring X class:
> 
 y = object()
 dir(y)
> ['__class__', '__delattr__', '__dir__', '__doc__', '__eq__',
> '__format__', '__ge__', '__getattribute__', '__gt__', '__hash__',
> '__init__', '__le__', '__lt__', '__ne__', '__new__', '__reduce__',
> '__reduce_ex__', '__repr__', '__setattr__', '__sizeof__', '__str__',
> '__subclasshook__'] 
 y.foo = 12
> Traceback (most recent call last):
>   File "", line 1, in 
> AttributeError: 'object' object has no attribute 'foo'
> 
> The attribute list is different now and there's no __dict__ and the
> object does not accept new attributes.
> Please explain what's going on.
> 
> 
Not all classes have a __dict__ attribute. Mostly builtin classes (e.g. 
tuple, list, int, ...), but also if you have an class using __slots__ 
which subclasses a class with no __dict__ it won't have a __dict__.

Subclasses don't remove attributes, they only add them (although in 
Python you can bend that rule it still applies here). Therefore for any 
classes to not have a __dict__ attribute the ultimate base class 
'object' has to not have a __dict__.

The consequence, as you found out, is that you cannot add attributes to 
an instance of 'object()', you have to create at least an empty subclass 
which doesn't include a `__slots__` attribute to get a class that can 
accept arbitrary attributes.


-- 
Duncan Booth
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: object().__dict__

[Amirouche Boubekki]

2014-04-23 8:11 GMT+02:00 Cameron Simpson :

> On 23Apr2014 09:39, Pavel Volkov  wrote:
>
>> There are some basics about Python objects I don't understand.
>> Consider this snippet:
>>
>>  class X: pass
>
 ...
>>
>>>  x = X()
> dir(x)
>
 ['__class__', '__delattr__', '__dict__', '__dir__', '__doc__',
>> '__eq__', '__format__', '__ge__', '__getattribute__', '__gt__', '__hash__',
>> '__init__', '__le__', '__lt__', '__module__', '__ne__', '__new__',
>> '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__sizeof__',
>> '__str__', '__subclasshook__', '__weakref__']
>>
>>>  x.foo = 11
>

>> And now I want to make a simple object in a shorter way, without
>> declaring X class:
>>
>
If you don't want to go through the usual syntax that defines classes you
can use the equivalent code using type to dynamically create a class:

MyClassObject = type('MyClassObject', (object,), dict())

Mind the fact that MyClassObject is a specific kind of object: a class, a
priori, not harmful in anyway


>
>>  y = object()
> dir(y)
>
 ['__class__', '__delattr__', '__dir__', '__doc__', '__eq__',
>> '__format__', '__ge__', '__getattribute__', '__gt__', '__hash__',
>> '__init__', '__le__', '__lt__', '__ne__', '__new__', '__reduce__',
>> '__reduce_ex__', '__repr__', '__setattr__', '__sizeof__', '__str__',
>> '__subclasshook__']
>>
>>>  y.foo = 12
>
 Traceback (most recent call last):
>> File "", line 1, in 
>> AttributeError: 'object' object has no attribute 'foo'
>>
>> The attribute list is different now and there's no __dict__ and the
>> object does not accept new attributes.
>> Please explain what's going on.
>>
>
> The base "object" class has a fixed set of attributes; you can't add more.
>

Just like any other builtin type: int, float etc... which also means you
can't add method to them dynamically.

Mind the fact that an instance of object is still useful to implement
efficient SENTINEL objects


>
> Almost every other class lets you add attributes, but the price for that
> is that it is slightly in memory footprint and slower to access.
>

class defined in Python except if you define a __slots__


>
> Look up the "__slots__" dunder var in the Python doco index:
>
>   https://docs.python.org/3/glossary.html#term-slots
>
> You'll see it as a (rarely used, mostly discouraged) way to force a fixed
> set of attributes onto a class. As with object, this brings a smaller
> memory footprint and faster attribute access, but the price is flexibility.
>

True, still can be the only way to save few MB or... GB without falling
back to C or PyPy.

Have a look at PyPy to how to save memory (and speed things up) without
slots:
http://morepypy.blogspot.fr/2010/11/efficiently-implementing-python-objects.html

In Python 3 there is a class that is equivalent to:

class foo(object):
pass

simple object with a __dict__, I can't find it anymore and also there is
SimpleNamespaceclass.

To sum up:

- If you want to create a sentinel value, use object()
- If you want to create an object to hold values and access them as
attributes, use something like SimpleNamespace


> Cheers,
> Cameron Simpson 
>
> Try being nothing but bored for 4 hours straight, and then tell me that
> there's no fear involved.   - d...@elxr.jpl.nasa.gov (Dave Hayes)
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: object().__dict__

[Phil Connell]

On Wed, Apr 23, 2014 at 03:48:32PM +0200, Amirouche Boubekki wrote:
> 2014-04-23 8:11 GMT+02:00 Cameron Simpson :
> > Look up the "__slots__" dunder var in the Python doco index:
> >
> >   https://docs.python.org/3/glossary.html#term-slots
> >
> > You'll see it as a (rarely used, mostly discouraged) way to force a fixed
> > set of attributes onto a class. As with object, this brings a smaller
> > memory footprint and faster attribute access, but the price is flexibility.
> >
> 
> True, still can be the only way to save few MB or... GB without falling
> back to C or PyPy.
> 
> Have a look at PyPy to how to save memory (and speed things up) without
> slots:
> http://morepypy.blogspot.fr/2010/11/efficiently-implementing-python-objects.html

Is there any analysis of how this balances increased memory usage from the JIT
vs the CPython VM (with a reasonable amount of code)?

I'd thought that one of the main disadvantages of PyPy was drastically
increased memory usage for any decent-sized program. Would be interested to
know if this was not the case :)


Cheers,
Phil

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

Re: object().__dict__

[Amirouche Boubekki]

2014-04-23 15:59 GMT+02:00 Phil Connell :

> On Wed, Apr 23, 2014 at 03:48:32PM +0200, Amirouche Boubekki wrote:
> > 2014-04-23 8:11 GMT+02:00 Cameron Simpson :
> > > Look up the "__slots__" dunder var in the Python doco index:
> > >
> > >   https://docs.python.org/3/glossary.html#term-slots
> > >
> > > You'll see it as a (rarely used, mostly discouraged) way to force a
> fixed
> > > set of attributes onto a class. As with object, this brings a smaller
> > > memory footprint and faster attribute access, but the price is
> flexibility.
> > >
> >
> > True, still can be the only way to save few MB or... GB without falling
> > back to C or PyPy.
> >
> > Have a look at PyPy to how to save memory (and speed things up) without
> > slots:
> >
> http://morepypy.blogspot.fr/2010/11/efficiently-implementing-python-objects.html
>
> Is there any analysis of how this balances increased memory usage from the
> JIT
> vs the CPython VM (with a reasonable amount of code)?
>
> I'd thought that one of the main disadvantages of PyPy was drastically
> increased memory usage for any decent-sized program. Would be interested to
> know if this was not the case :)
>

I have a similar thought, I don't how that memory consumption increase (a
constant? a factor? probably both...)

but if the program use an absurd amount of memory even in CPython then PyPy
will be able to catchup based on comment #1 of a PyPy core dev in
http://tech.oyster.com/save-ram-with-python-slots/ see also
http://pypy.readthedocs.org/en/latest/interpreter-optimizations.html#dictionary-optimizations

Still it requires more analysis. When does PyPy trigger the optimization?


>
>
> Cheers,
> Phil
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: object().__dict__

[Phil Connell]

On Wed, Apr 23, 2014 at 04:21:26PM +0200, Amirouche Boubekki wrote:
> 2014-04-23 15:59 GMT+02:00 Phil Connell :
> 
> > On Wed, Apr 23, 2014 at 03:48:32PM +0200, Amirouche Boubekki wrote:
> > > 2014-04-23 8:11 GMT+02:00 Cameron Simpson :
> > > > Look up the "__slots__" dunder var in the Python doco index:
> > > >
> > > >   https://docs.python.org/3/glossary.html#term-slots
> > > >
> > > > You'll see it as a (rarely used, mostly discouraged) way to force a
> > fixed
> > > > set of attributes onto a class. As with object, this brings a smaller
> > > > memory footprint and faster attribute access, but the price is
> > flexibility.
> > > >
> > >
> > > True, still can be the only way to save few MB or... GB without falling
> > > back to C or PyPy.
> > >
> > > Have a look at PyPy to how to save memory (and speed things up) without
> > > slots:
> > >
> > http://morepypy.blogspot.fr/2010/11/efficiently-implementing-python-objects.html
> >
> > Is there any analysis of how this balances increased memory usage from the
> > JIT
> > vs the CPython VM (with a reasonable amount of code)?
> >
> > I'd thought that one of the main disadvantages of PyPy was drastically
> > increased memory usage for any decent-sized program. Would be interested to
> > know if this was not the case :)
> >
> 
> I have a similar thought, I don't how that memory consumption increase (a
> constant? a factor? probably both...)
> 
> but if the program use an absurd amount of memory even in CPython then PyPy
> will be able to catchup based on comment #1 of a PyPy core dev in
> http://tech.oyster.com/save-ram-with-python-slots/ see also
> http://pypy.readthedocs.org/en/latest/interpreter-optimizations.html#dictionary-optimizations

Absolutely. For long-running code manipulating large amounts of data I can
imagine the PyPy optimisations being a win.

On the other hand, if the code/data ratio is larger, CPython may well win in
terms of memory use.


> 
> Still it requires more analysis. When does PyPy trigger the optimization?

Indeed. Without measuring this is all idle speculation ;)


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

Re: Unicode in Python

[Rustom Mody]

On Wednesday, April 23, 2014 1:23:00 PM UTC+5:30, Steven D'Aprano wrote:
> On Tue, 22 Apr 2014 23:57:46 -0700, Rustom Mody wrote:

> > On the other hand when/if a keyboard mapping is defined in which the
> > characters that are commonly needed are available, it is reasonable to
> > expect the ∨,∧ to cost no more than 2 strokes each (ie about as much as
> > an 'A'; slightly more than an 'a'. Which means that '∨' is expected to
> > cost about the same as 'or' and ∧ to cost less than an 'and'

> Oh, a further thought...

> Consider your example:

> return year%4=0 ∧ (year%100≠0 ∨ year%100 = 0)

> vs

> return year%4=0 and (year%100!=0 or year%100 = 0)

> [aside: personally I like ≠ and if there was a platform independent way
> to type it in any editor, I'd much prefer it over != or <> ]

> Apart from the memorization problem, which I've already touched on, there
> is the mode problem. Keyboard layouts are modes, and you're swapping
> modes. Every time you swap modes, there is a small mental cost. Think of
> it as an interrupt which has to be caught, pausing the current thought
> and starting a new one. So rather than:

> char char char char char char char ...

> you have:

> char char char INTERRUPT
> char INTERRUPT
> char char char ...

> which is a heavier cost that it appears from just counting keystrokes. Of
> course, the more experienced you become, the smaller that cost will be,
> but it will never be quite as low as just a "regular" keystroke.

> Normally, when people use multiple keyboards, its because that interrupt
> cost is amortized over a significant amount of typing:

> INTERRUPT (English layout)
> paragraph paragraph paragraph paragraph
> INTERRUPT (Greek layout)
> paragraph paragraph paragraph
> INTERRUPT (English again)
> paragraph ...

> and possibly even lost in the noise of a far greater interrupt, namely
> task-switching from one application to another. So it's manageable. But
> switching layouts for a single character is likely to be far more
> painful, especially for casual users of that layout.

> Based on an extremely generous estimate that I use "lambda" four times in
> 100 lines of code, I might use λ perhaps once in a thousand non-Greek
> characters. Similarly, I might use ∧ or ∨ maybe once per hundred
> characters. That means I'm unlikely to ever get familiar enough with
> those that the cost of two interrupts per use will be negligible.

Its gratifying to see an argument whose framing is cognitive-based!

More on that later.

For now: mode/modeless

Yes most of us prefer the Shift key to the Caps Lock even for stretches of 
capitals.  So analogously here is a modeless solution

Earlier I found this mode-switching version
$ setxkbmap -option "grp:switch,grp:alt_shift_toggle,grp_led:scroll" -layout 
"us,gr"
this makes Shift-Alt the mode-switcher

This one on the other hand
$ setxkbmap -layout "us,gr" -option "grp:switch"
will make right-alt behave like 'Greek-Shift'

ie typing
abcdefghijklmnopqrstuvwxyz
with RAlt depressed throughout, produces
αβψδεφγηιξκλμνοπ;ρστθωςχυζ

This makes the a Greek letter's ergonomic cost identical to a capital English
letter's:  For Greek use RAlt the way one uses Shift for English.

Notes:
1. Tried on Debian and Ubuntu -- Recent Ubuntus are rather more ill-mannered in
the way they appropriates keys. Still it works as far as I can see.

2. ';' ?? ie semicolon is produced from 'q'? Whats that semicolon doing there?? 
But then Greek is -- well -- Greek to me! (As is xkb!)
-- 
https://mail.python.org/mailman/listinfo/python-list

App segmentation fault (CentOS 6.5)

[Reginaldo]

Hi,

I have a GUI app that is written using wx. When I run it on CentOS 6.5, the 
following error messages are displayed and the app closes:

(python:10096): Pango-WARNING **: shaping failure, expect ugly output. 
shape-engine='BasicEngineFc', font='DejaVu Sans 10.9990234375', text=''

(python:10096): Pango-CRITICAL **: pango_layout_get_line_count: assertion 
`layout != NULL' failed

(python:10096): Gdk-CRITICAL **: IA__gdk_draw_layout: assertion 
`PANGO_IS_LAYOUT (layout)' failed
Segmentation fault

I checked if this was a font issue, but the font is installed on the system.

I use an idle thread in my application.

Could some let me know what the problem may be in this case? Thank you!

Python Version used: 2.6.6
wxPython Version used: 2.8.11
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: App segmentation fault (CentOS 6.5)

[Mark H Harris]

On 4/23/14 1:08 PM, Reginaldo wrote:


I have a GUI app that is written using wx. When I run it on CentOS 6.5, the 
following error messages are displayed and the app closes:


   Only fails on CentOS ?



I use an idle thread in my application.


   Is your CentOS launching idle with -n switch ?



   What is different on this setup ?

   Have you tried more than one CentOS system?






  marcus

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

Re: object().__dict__

[CHIN Dihedral]

On Wednesday, April 23, 2014 10:21:26 PM UTC+8, Amirouche Boubekki wrote:
> 2014-04-23 15:59 GMT+02:00 Phil Connell :
> 
> 
> 
> On Wed, Apr 23, 2014 at 03:48:32PM +0200, Amirouche Boubekki wrote:
> 
> > 2014-04-23 8:11 GMT+02:00 Cameron Simpson :
> 
> 
> > > Look up the "__slots__" dunder var in the Python doco index:
> 
> > >
> 
> > >   https://docs.python.org/3/glossary.html#term-slots
> 
> > >
> 
> > > You'll see it as a (rarely used, mostly discouraged) way to force a fixed
> 
> > > set of attributes onto a class. As with object, this brings a smaller
> 
> > > memory footprint and faster attribute access, but the price is 
> > > flexibility.
> 
> > >
> 
> >
> 
> > True, still can be the only way to save few MB or... GB without falling
> 
> > back to C or PyPy.
> 
> >
> 
> > Have a look at PyPy to how to save memory (and speed things up) without
> 
> > slots:
> 
> > http://morepypy.blogspot.fr/2010/11/efficiently-implementing-python-objects.html
> 
> 
> 
> Is there any analysis of how this balances increased memory usage from the JIT
> 
> vs the CPython VM (with a reasonable amount of code)?
> 
> 
> 
> I'd thought that one of the main disadvantages of PyPy was drastically
> 
> increased memory usage for any decent-sized program. Would be interested to
> 
> know if this was not the case :)
> 
> 
> 
> I have a similar thought, I don't how that memory consumption increase (a 
> constant? a factor? probably both...)
> 
> but if the program use an absurd amount of memory even in CPython then PyPy 
> will be able to catchup based on comment #1 of a PyPy core dev in 
> http://tech.oyster.com/save-ram-with-python-slots/ see also 
> http://pypy.readthedocs.org/en/latest/interpreter-optimizations.html#dictionary-optimizations
> 
> 
> 
> 
> Still it requires more analysis. When does PyPy trigger the optimization?
> 
>  
> 
> 
> 
> 
> 
> 
> Cheers,
> 
> Phil
> 
> 
> 
> --
> 
> https://mail.python.org/mailman/listinfo/python-list

 The auto-code generation  of valid python codes in PyPy is helpful in CAD/CAM 
and non-idiot robot brains.
-- 
https://mail.python.org/mailman/listinfo/python-list

Moving to an OOP model from an classically imperitive one

[tim . thelion]

Hello,

I am currently writting a program called subuser(subuser.org), which is written 
as classically imperative code.  Subuser is, essentially, a package manager.  
It installs and updates programs from repositories.

I have a set of source files 
https://github.com/subuser-security/subuser/tree/master/logic/subuserCommands/subuserlib
 which have functions in them.  Each function does something to a program, it 
identifies the program by the programs name.  For example, I have an 
installProgram function defined as such:

def installProgram(programName, useCache):

Now I've run into a flaw in this model.  There are certain situations where a 
"programName" is not a unique identifier. It is possible for two repositories 
to each have a program with the same name.  Obviously, I could go through my 
code and replace all use of the string "programName" with a tuple of 
(programName, repository).  Or I could define a new class with two attributes: 
programName and repository, and pass such a simple object arround, or pass a 
dictionary.  However, I think this would be better solved by moving fully to an 
OOP model.  That is, I would have a SubuserProgram class which had methods such 
as "install", "describe", "isInstalled"...

There is one problem though.  Currently, I have these functions logically 
organized into source files, each between 40 and 170 LOC.  I fear that if I 
were to put all of these functions into one class, than I would have a single, 
very large source file.  I don't like working with large source files for 
practicall reasons.  If I am to define the class SubuserProgram in the file 
SubuserProgram.py, I do not want all 

 of run.py to be moved into that file as well.

I thought about keeping each method in a separate file, much as I do now, 
something like:

###
#FileA.py
###
def a(self):
  blah

###
#FileB.py
###
def b(self):
  blah

###
#Class.py
###
import FileA, FileB
class C:
  a=FileA.a
  b=FileB.b

This works, but I find that it is hard to read.  When I come across FileA, and 
I see "self" it just seems very confusing.  I suffer a bout of "who-am-i"ism.

I asked on IRC and it was sugested that I use multiple classes, however I see 
no logical way to separate a SubuserProgram object into multiple classes.

So I thought I would seek your advice.

Tim
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Moving to an OOP model from an classically imperitive one

[Mark Lawrence]

On 23/04/2014 21:57, tim.thel...@gmail.com wrote:

Hello,

I am currently writting a program called subuser(subuser.org), which is written 
as classically imperative code.  Subuser is, essentially, a package manager.  
It installs and updates programs from repositories.

I have a set of source files 
https://github.com/subuser-security/subuser/tree/master/logic/subuserCommands/subuserlib
 which have functions in them.  Each function does something to a program, it 
identifies the program by the programs name.  For example, I have an 
installProgram function defined as such:

def installProgram(programName, useCache):

Now I've run into a flaw in this model.  There are certain situations where a "programName" is not a unique identifier. 
It is possible for two repositories to each have a program with the same name.  Obviously, I could go through my code and replace 
all use of the string "programName" with a tuple of (programName, repository).  Or I could define a new class with two 
attributes: programName and repository, and pass such a simple object arround, or pass a dictionary.  However, I think this would 
be better solved by moving fully to an OOP model.  That is, I would have a SubuserProgram class which had methods such as 
"install", "describe", "isInstalled"...

There is one problem though.  Currently, I have these functions logically organized 
into source files, each between 40 and 170 LOC.  I fear that if I were to put all of 
these functions into one class, than I would have a single, very large source file.  
I don't like working with large source files for practicall reasons.  If I am to 
define the class SubuserProgram in the file SubuserProgram.py, I do not want all 

 of run.py to be moved into that file as well.

I thought about keeping each method in a separate file, much as I do now, 
something like:

###
#FileA.py
###
def a(self):
   blah

###
#FileB.py
###
def b(self):
   blah

###
#Class.py
###
import FileA, FileB
class C:
   a=FileA.a
   b=FileB.b

This works, but I find that it is hard to read.  When I come across FileA, and I see 
"self" it just seems very confusing.  I suffer a bout of "who-am-i"ism.

I asked on IRC and it was sugested that I use multiple classes, however I see 
no logical way to separate a SubuserProgram object into multiple classes.

So I thought I would seek your advice.

Tim



You're writing Python, not Java, so put your code into one file and stop 
messing about.


--
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.


Mark Lawrence

---
This email is free from viruses and malware because avast! Antivirus protection 
is active.
http://www.avast.com


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

Re: Moving to an OOP model from an classically imperitive one

[Ian Kelly]

On Apr 23, 2014 5:01 PM,  wrote:
> I asked on IRC and it was sugested that I use multiple classes, however I
see no logical way to separate a SubuserProgram object into multiple
classes.

You say you already have the methods logically separated into files. How
about adding one abstract class per file, and then letting SubuserProgram
inherit from each of those individual classes?

As another alternative that you haven't mentioned yet, you could create a
decorator to be applied to each method, which will inject it into the class
at the time it is defined. The explicitness of the decorator solves your
confusion problem of "why does this function use self". It creates a couple
of new problems though: 1) reading the class won't tell you what methods it
contains; and 2) making sure the class is fully constructed before it is
used becomes tricky.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Moving to an OOP model from an classically imperitive one

[Ethan Furman]

On 04/23/2014 01:57 PM, tim.thel...@gmail.com wrote:


There is one problem though.  Currently, I have these functions logically
 organized into source files, each between 40 and 170 LOC.  I fear that if
I were to put all of these functions into one class, than I would have a
 single, very large source file.  I don't like working with large source
 files for practicall reasons.


I'm curious what these practical reasons are.  One my smallest source files has 
870 lines in it, my largest nearly 9000.

If the problem is your editor, you should seriously consider switching.

--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list

Re: Moving to an OOP model from an classically imperitive one

[MRAB]

On 2014-04-23 21:57, tim.thel...@gmail.com wrote:

Hello,

I am currently writting a program called subuser(subuser.org), which
is written as classically imperative code.  Subuser is, essentially,
a package manager.  It installs and updates programs from
repositories.

I have a set of source files
https://github.com/subuser-security/subuser/tree/master/logic/subuserCommands/subuserlib
which have functions in them.  Each function does something to a
program, it identifies the program by the programs name.  For
example, I have an installProgram function defined as such:

def installProgram(programName, useCache):

Now I've run into a flaw in this model.  There are certain situations
where a "programName" is not a unique identifier. It is possible for
two repositories to each have a program with the same name.
Obviously, I could go through my code and replace all use of the
string "programName" with a tuple of (programName, repository).  Or I
could define a new class with two attributes: programName and
repository, and pass such a simple object arround, or pass a
dictionary.  However, I think this would be better solved by moving
fully to an OOP model.  That is, I would have a SubuserProgram class
which had methods such as "install", "describe", "isInstalled"...


[snip]
Could you make the program name unique just by combining it with the
repository name in a single string?
--
https://mail.python.org/mailman/listinfo/python-list

Re: Moving to an OOP model from an classically imperitive one

[Chris Angelico]

On Thu, Apr 24, 2014 at 7:42 AM, Ethan Furman  wrote:
> On 04/23/2014 01:57 PM, tim.thel...@gmail.com wrote:
>>
>>
>> There is one problem though.  Currently, I have these functions logically
>>  organized into source files, each between 40 and 170 LOC.  I fear that if
>> I were to put all of these functions into one class, than I would have a
>>  single, very large source file.  I don't like working with large source
>>  files for practicall reasons.
>
>
> I'm curious what these practical reasons are.  One my smallest source files
> has 870 lines in it, my largest nearly 9000.
>
> If the problem is your editor, you should seriously consider switching.

It's probably not the case here, but one good reason for splitting a
file into pieces is to allow separate people or systems to update
different parts. Lots of Linux programs support either
/etc/foobar.conf or /etc/foobar.conf.d/ where the former is one file
and the latter is a directory of separate files, generally deemed to
be concatenated to the main config file. (Example:
/etc/apt/sources.list and /etc/apt/sources.list.d/ - the main config
for your Debian repositories, the directory for additional ones for
VirtualBox or PostgreSQL.) It's easier to allow someone to completely
overwrite a file than to try to merge changes.

But that's not often the case with source code.

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

Re: how to write list in a file

[Terry Reedy]

On 4/23/2014 3:53 AM, Dhananjay wrote:

Hello everyone,

I am trying hard to write a list to a file as follows:


def average_ELECT(pwd):
 os.chdir(pwd)


I would 'print pwd' to make sure where files are being opened.


 files = filter(os.path.isfile, os.listdir('./'))
 folders = filter(os.path.isdir, os.listdir('./'))
 eelec = 0.0; evdw = 0.0; EELEC = []; elecutoff = [];
 g = Gnuplot.Gnuplot()
 for f1 in files:
#   if f1[21:23]=='12':
 if f1[27:29]==sys.argv[1]: # vdw cutoff remains constant; see
2nd column of output
 fl1 = open(f1,'r').readlines()
 #   print len(fl1)

 for i in range(1, len(fl1)):
 fl1[i]=fl1[i].split()
 eelec = eelec + float(fl1[i][1])
 evdw = evdw + float(fl1[i][2])
 #print fl1[i][1], fl1[i][2]
 avg_eelec = eelec/40
 avg_evdw = evdw/40
 #   print eelec, evdw
 #   print f1[21:23], f1[27:29], avg_eelec, avg_evdw
 print f1[21:23], f1[27:29], avg_eelec
 #   EELEC.append(avg_eelec); elecutoff.append(float(f1[21:23]))
 eelec=0.0; evde=0.0;
 a = f1[21:23]+' '+f1[27:29]+' '+str(avg_eelec)
 EELEC.append(a)
 print sorted(EELEC)
 with open('EElect_elec12-40_vdwxxx.dat','w') as wr:
 for i in EELEC:
 print i
 wr.write("%s\n" % i)
 wr.close()


The script is printing "print sorted(EELEC)" as well as "print
f1[21:23], f1[27:29], avg_eelec" very well.
However, for some reason, I neither see any file (expected to see
EElect_elec12-40_vdwxxx.dat as per the script) generated nor any error
message.

Could anyone suggest me correction here.

Thanking you in advance.

-- DJ







--
Terry Jan Reedy

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

Re: why my cur.executescript can not run?

[Terry Reedy]

On 4/23/2014 7:23 AM, length power wrote:

please download the attachment


Cinfo.zip. Please do not post with attachments. This is a text list, and 
binary attachments can be a vehicle for malware. Instead, reduce your 
code to the minimum necessary to exhibit the problem and include it in 
the post, or if still too large, include a link to a storage location on 
the web where it can be viewed in a browser before downloading.


--
Terry Jan Reedy

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

Re: App segmentation fault (CentOS 6.5)

[Terry Reedy]

On 4/23/2014 3:46 PM, Mark H Harris wrote:

On 4/23/14 1:08 PM, Reginaldo wrote:


I have a GUI app that is written using wx. When I run it on CentOS
6.5, the following error messages are displayed and the app closes:


Only fails on CentOS ?



I use an idle thread in my application.


Is your CentOS launching idle with -n switch ?


I am quite sure that his 'idle thread' had nothing to do with Idle. 
Rather, it should be a thread that runs when the app is otherwise idle. 
However, if he were trying to run wx and Idle/tk in the same process, I 
would expect problems.


--
Terry Jan Reedy

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

Re: Moving to an OOP model from an classically imperitive one

[Gregory Ewing]

tim.thel...@gmail.com wrote:

I think this would be better solved
by moving fully to an OOP model.  That is, I would have a SubuserProgram
class which had methods such as "install", "describe", "isInstalled"...


This wouldn't necessarily be better. Don't be taken in by the
"everything is better as a class" kind of dogma that seems to
prevail in some circles.

If all you do is take a bunch of module-level functions and
put them into a single class, you haven't really changed anything.
It's still the same design, you've just arranged the source
differently.

There are a couple of good reasons for turning a function into
a method. One is if it embodies implementation details that you
want to keep separated from the rest of the program. But if
*all* of your code is inside the class, there isn't any "rest
of the program" to keep it separate from.

Another is if you want to be able to override it in subclasses.
If there were different kinds of SubuserProgram that needed to
be installed in different ways, for example, it would make
sense to structure this as a collection of classes with an
install() method. But even then, you don't have to put all
the installation code in the classes -- the methods could just
be stubs that call out to different module-level functions if
you wanted.

A reasonable compromise might be to keep the *data* assocated
with a SubuserProgram in a class, maybe together with a few
methods that are tightly coupled to it, but have the major
pieces of functionality such as install() implemented by
separate functions that operate *on* the class, rather than
being inside it.


Currently, I have these functions logically
organized into source files, each between 40 and 170 LOC.


That's quite small as these things typically go. You can afford
to make them somewhat larger; I tend to find that files start to
get unwieldy around 1000 lines or so.

--
Greg
--
https://mail.python.org/mailman/listinfo/python-list

Re: Moving to an OOP model from an classically imperitive one

[Gregory Ewing]

Ian Kelly wrote:

How 
about adding one abstract class per file, and then letting 
SubuserProgram inherit from each of those individual classes?


I'd recommend against that kind of thing, because it makes
the code hard to follow. With module-level functions, you can
tell where any given function is coming from by looking at the
imports (as long as you haven't used 'import *', which is a
bad idea for this very reason).

But if you're looking at a method call on a class that
inherits from half a dozen base classes, it's hard to tell
which class it's implemented in.

In other words, massively multiple inheritance is the OO
equivalent of 'import *'.

The same goes for any scheme for injecting methods into a
class after defining it, only more so, because the reader
won't be expecting weird things like that.

--
Greg
--
https://mail.python.org/mailman/listinfo/python-list

retrieve source code from code object as returned by compile()

[Justin Ezequiel]

Is there a way to get the original source?
I am trying to retrieve the main script from a py2exe'd old program.
The programmer neglected to commit to SVN before leaving.

Using "Easy Python Decompiler" I am able to get the source for the imported 
modules.
Using "Resources Viewer" from PlexData and some code I am able to retrieve the 
code object. I am however stumped as to how to retrieve the source from this 
code object. 

PythonWin 2.5.4 (r254:67916, Dec 23 2008, 15:10:54) [MSC v.1310 32 bit (Intel)] 
on win32.
Portions Copyright 1994-2008 Mark Hammond - see 'Help/About PythonWin' for 
further copyright information.
>>> s = 'import time\nprint time.time()\n'
>>> c = compile(s, 'foo.py', 'exec')
>>> exec(c)
1398299623.77
>>> c
 at 01E5C5C0, file "foo.py", line 1>
>>> for n in dir(c):
... if n.startswith('_'): continue
... print n
... a = getattr(c, n)
... print type(a)
... print `a`
... print
... 
co_argcount

0

co_cellvars

()

co_code

'd\x00\x00d\x01\x00k\x00\x00Z\x00\x00e\x00\x00i\x00\x00\x83\x00\x00GHd\x01\x00S'

co_consts

(-1, None)

co_filename

'foo.py'

co_firstlineno

1

co_flags

64

co_freevars

()

co_lnotab

'\x0c\x01'

co_name

''

co_names

('time',)

co_nlocals

0

co_stacksize

2

co_varnames

()
>>> len(s)
30
>>> len(c.co_code)
27
>>> 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: App segmentation fault (CentOS 6.5)

[Wesley]

在 2014年4月24日星期四UTC+8上午2时08分29秒，Reginaldo写道：
> Hi,
> 
> 
> 
> I have a GUI app that is written using wx. When I run it on CentOS 6.5, the 
> following error messages are displayed and the app closes:
> 
> 
> 
> (python:10096): Pango-WARNING **: shaping failure, expect ugly output. 
> shape-engine='BasicEngineFc', font='DejaVu Sans 10.9990234375', text=''
> 
> 
> 
> (python:10096): Pango-CRITICAL **: pango_layout_get_line_count: assertion 
> `layout != NULL' failed
> 
> 
> 
> (python:10096): Gdk-CRITICAL **: IA__gdk_draw_layout: assertion 
> `PANGO_IS_LAYOUT (layout)' failed
> 
> Segmentation fault
> 
> 
> 
> I checked if this was a font issue, but the font is installed on the system.
> 
> 
> 
> I use an idle thread in my application.
> 
> 
> 
> Could some let me know what the problem may be in this case? Thank you!
> 
> 
> 
> Python Version used: 2.6.6
> 
> wxPython Version used: 2.8.11

Maybe you can gdb python attach the running pid and check the backtrace.
Severay days ago, I use this guy to address thread hang and memory leak issues.
Just say here if that helps.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: how to write list in a file

[Dave Angel]

Terry Reedy  Wrote in message:
> On 4/23/2014 3:53 AM, Dhananjay wrote:
>> Hello everyone,
>>
>> I am trying hard to write a list to a file as follows:
>>
>>
>> def average_ELECT(pwd):
>>  os.chdir(pwd)
> 
> I would 'print pwd' to make sure where files are being opened.
> 
>>  files = filter(os.path.isfile, os.listdir('./'))
>>  

I wouldn't.  I've seen too many flaky problems to trust os.chdir
 in real code.  I think the op should build each filename with
 os.path.append or similar. All paths used for actual file
 operations should either be absolute,  or strictly relative to
 the user's cwd when the script started.  And even the latter is
 suspect when you're anywhere near Windows. 

-- 
DaveA

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

Re:Moving to an OOP model from an classically imperitive one

[Dave Angel]

tim.thel...@gmail.com Wrote in message:
>

I don't really understand your problem or your examples,  but
 others apparently do. So I'll just make a few comments.
 


> 
> There is one problem though.  Currently, I have these functions logically 
> organized into source files, each between 40 and 170 LOC.  I fear that if I 
> were to put all of these functions into one class, than I would have a 
> single, very large source file.  I don't like working with large source files 
> for practicall reasons.

Definitely limit your source file size. 10k lines is probably a
 good limit.

>  If I am to define the class SubuserProgram in the file SubuserProgram.py, 

That's a big mistake right there.  Never let the module name match
 the class name.  If you really only happen to have a single class
 in the file, then just use lower case for the filename.
 


-- 
DaveA

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

Re: retrieve source code from code object as returned by compile()

[Gregory Ewing]

Justin Ezequiel wrote:

Using "Easy Python Decompiler" I am able to get the source for the imported
modules. Using "Resources Viewer" from PlexData and some code I am able to
retrieve the code object. I am however stumped as to how to retrieve the
source from this code object.


Easy Python Decompiler should be able to do that, but you
may need to delve into its innards a bit to find an entry
point where you can feed in a code object.

Alternatively you could create a .pyc file out of the code
object and then use Easy Python Decompiler on that. The
following snippet of code should do that:

import marshal
import py_compile
import time

with open('output.pyc', 'wb') as fc:
fc.write('\0\0\0\0')
py_compile.wr_long(fc, long(time.time()))
marshal.dump(codeobject, fc)
fc.flush()
fc.seek(0, 0)
fc.write(py_compile.MAGIC)

(Taken from: 
http://stackoverflow.com/questions/8627835/generate-pyc-from-python-ast)


--
Greg
--
https://mail.python.org/mailman/listinfo/python-list