Unconverted data remains

[Nikhil Verma]

Hi

My Problem


I have a list :-
 L = ['Sunday November 11  2012 9:00pm ', 'Thursday November 15  2012
7:00pm ',\
 'Friday November 16  2012 7:00pm ', 'Monday November 19
 2012 7:30pm ', \
 'Friday November 23  2012 7:30pm ', 'Sunday November 25
 2012 8:00pm ',\
 'Monday November 262012 7:00pm ', 'Thursday November 29
 2012 6:30pm ',\
 'Saturday December 1  20125:30pm ', 'Thursday December 6
 2012 9:00pm ',\
 'Sunday December 9  2012 7:00pm ', 'Friday November 9
 2012 6:00pm ', \
 'Friday November 9  2012 7:00pm ', 'Friday November 9
 2012 7:00pm ']


final_event_time = [datetime.strptime(iterable, '%A %B %d %Y %I:%M%p') for
iterable in L]

and having this error Unconverted data remains . I am trying to convert all
these in datetime object.

-- 
Regards
Nikhil Verma
+91-958-273-3156
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Multi-dimensional list initialization

[Andrew Robinson]

On 11/07/2012 11:09 PM, Ian Kelly wrote:

On Wed, Nov 7, 2012 at 8:13 PM, Andrew Robinson
  wrote:

OK, and is this a main use case?  (I'm not saying it isn't I'm asking.)

I have no idea what is a "main" use case.
Well, then we can't evaluate if it's worth keeping a list multiplier 
around at all.

You don't even know how it is routinely used.

FYI, the Python devs are not very fond of adding new keywords.  Any
time a new keyword is added, existing code that uses that word as a
name is broken.  'ini' is particularly bad, because 1) it's not a
word, and 2) it's the name of a common type of configuration file and
is probably frequently used as a variable name in relation to such
files.

Fine; Its a keyword TBD then; I should have said 'foo'.
in is worse than ini, ini is worse than something else -- at the end of 
the rainbow, maybe there is something

values = zip(   samples, [ lambda:times, ini xrange(num_groups) ]   )

 if len(values)<  len(times) * num_groups


How is this any better than the ordinary list comprehension I already
suggested as a replacement?  For that matter, how is this any better
than list multiplication?
You _asked it to implement_ a list multiplication of the traditional 
kind;  By doing copies by *REFERENCE*; so of course it's not better.

My intentions were for copying issues, not-non copying ones.

   Your basic complaint about list
multiplication as I understand it is that the non-copying semantics
are unintuitive.

No.
1) My basic complaint is that people (I think from watching) primarily 
use it to make initializer lists, and independent mutable place holders; 
List multiplication doesn't do that well.
2) If it is indeed very rare (as D'Aprano commented) then -- it has a 
second defect in looking to casual inspection to be the same as vector 
multiplication; which opacifies which operation is being done when 
matrix packages are potentially being used.



   Well, the above is even less intuitive.  It is
excessively complicated and almost completely opaque.  If I were to
come across it outside the context of this thread, I would have no
idea what it is meant to be doing.
Nor would I *know* what this list multiplier look alike does 
[1,2,3]*aValue without checking to see if someone imported a vector 
library and the variable aValue has a special multiplication operator.



As an aside, how would you do the lambda inside a list comprehension?

As a general rule, I wouldn't.  I would use map instead.

OK: Then copy by reference using map:

values = zip(   map( lambda:times, xrange(num_groups) )   )
if len(values) < len(times) * num_groups ...

Done.  It's clearer than a list comprehension and you still really don't 
need a list multiply.
I''m not going to bother explaining what the construction I offered 
would be really good at.

It's pointless to explain to the disinterested.


Thak constructs a list of 10 functions and never calls them.  If you
want to actually call the lambda, then:

Yep, I was very tired.
slice.indices() has nothing to do with it. Indexing a sequence and 
calling the .indices() method on a slice are entirely different 
operations. 
Yes, but you're very blind to history and code examples implementing the 
slice operation.

slice usually depends on index; index does not depend on slice.
Slice is suggested to be implemented by multiple calls to single indexes 
in traditional usage and documentation.


The xrange(,,)[:] implementation breaks the tradition, because it 
doesn't call index multiple times; nor does it return a result 
equivalent identical to doing that.


It's different. period.  You're not convincing in the slightest by 
splitting hairs.




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

Re: Read number of CSV files

[Peter Otten]

Smaran Harihar wrote:

> I am able to read through a CSV File and fetch the data inside the CSV
> file but I have a really big list of CSV files and I wish to do the same
> particular code in all the CSV files.
> 
> Is there some way that I can loops through all these files, which are in a
> single folder, and get my code to read the files?

import glob
import csv

def process(filename):
with open(filename, "rb") as f:
rows = csv.reader(f)
for row in rows:
... # whatever you want

for filename in glob.glob("/path/to/*.csv"):
process(filename)


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

Re: Unconverted data remains

[Peter Otten]

Nikhil Verma wrote:

> I have a list :-
>  L = ['Sunday November 11  2012 9:00pm ', 'Thursday November 15  2012
> 7:00pm ',\

[...]

>  2012 7:00pm ']

> final_event_time = [datetime.strptime(iterable, '%A %B %d %Y %I:%M%p') for
> iterable in L]
> 
> and having this error Unconverted data remains . I am trying to convert
> all these in datetime object.

Your date strings have trailing whitespace, try changing the format to

final_event_time = [datetime.strptime(s, '%A %B %d %Y %I:%M%p ') for s in L]

or apply strip to the date strings:

final_event_time = [datetime.strptime(s.strip(), '%A %B %d %Y %I:%M%p') for 
s in L]

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

Re: creating size-limited tar files

[andrea crotti]

2012/11/7 Oscar Benjamin :
>
> Correct. But if you read the rest of Alexander's post you'll find a
> suggestion that would work in this case and that can guarantee to give
> files of the desired size.
>
> You just need to define your own class that implements a write()
> method and then distributes any data it receives to separate files.
> You can then pass this as the fileobj argument to the tarfile.open
> function:
> http://docs.python.org/2/library/tarfile.html#tarfile.open
>
>
> Oscar



Yes yes I saw the answer, but now I was thinking that what I need is
simply this:
tar czpvf - /path/to/archive | split -d -b 100M - tardisk

since it should run only on Linux it's probably way easier, my script
will then only need to create the list of files to tar..

The only doubt is if this is more or less reliably then doing it in
Python, when can this fail with some bad broken pipe?
(the filesystem is not very good as I said and it's mounted with NFS)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: creating size-limited tar files

[andrea crotti]

2012/11/8 andrea crotti :
>
>
>
> Yes yes I saw the answer, but now I was thinking that what I need is
> simply this:
> tar czpvf - /path/to/archive | split -d -b 100M - tardisk
>
> since it should run only on Linux it's probably way easier, my script
> will then only need to create the list of files to tar..
>
> The only doubt is if this is more or less reliably then doing it in
> Python, when can this fail with some bad broken pipe?
> (the filesystem is not very good as I said and it's mounted with NFS)

In the meanwhile I tried a couple of things, and using the pipe on
Linux actually works very nicely, it's even faster than simple tar for
some reasons..

[andrea@andreacrotti isos]$ time tar czpvf - file1.avi file2.avi |
split -d -b 1000M - inchunks
file1.avi
file2.avi

real1m39.242s
user1m14.415s
sys 0m7.140s

[andrea@andreacrotti isos]$ time tar czpvf total.tar.gz file1.avi file2.avi
file1.avi
file2.avi

real1m41.190s
user1m13.849s
sys 0m5.723s

[andrea@andreacrotti isos]$ time split -d -b 1000M total.tar.gz inchunks

real0m55.282s
user0m0.020s
sys 0m3.553s
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Right solution to unicode error?

[wxjmfauth]

Le mercredi 7 novembre 2012 23:17:42 UTC+1, Anders a écrit :
> I've run into a Unicode error, and despite doing some googling, I
> 
> can't figure out the right way to fix it. I have a Python 2.6 script
> 
> that reads my Outlook 2010 task list. I'm able to read the tasks from
> 
> Outlook and store them as a list of objects without a hitch.  But when
> 
> I try to print the tasks' subjects, one of the tasks is generating an
> 
> error:
> 
> 
> 
> Traceback (most recent call last):
> 
>   File "outlook_tasks.py", line 66, in 
> 
> my_tasks.dump_today_tasks()
> 
>   File "C:\Users\Anders\code\Task List\tasks.py", line 29, in
> 
> dump_today_tasks
> 
> print task.subject
> 
> UnicodeEncodeError: 'ascii' codec can't encode character u'\u2013' in
> 
> position 42: ordinal not in range(128)
> 
> 
> 
> (where task.subject  was previously assigned the value of
> 
> task.Subject, aka the Subject property of an Outlook 2010 TaskItem)
> 
> 
> 
> From what I understand from reading online, the error is telling me
> 
> that the subject line  contains an en dash and that Python is trying
> 
> to convert to ascii and failing (as it should).
> 
> 
> 
> Here's where I'm getting stuck.  In the code above I was just printing
> 
> the subject so I can see whether the script is working properly.
> 
> Ultimately what I want to do is parse the tasks I'm interested in and
> 
> then create an HTML file containing those tasks.  Given that, what's
> 
> the best way to fix this problem?
> 
> 
> 
> BTW, if there's a clear description of the best solution for this
> 
> particular problem – i.e., where I want to ultimately display the
> 
> results as HTML – please feel free to refer me to the link. I tried
> 
> reading a number of docs on the web but still feel pretty lost.
> 
> 
> 
> Thanks,
> 
> Anders

--


The problem is not on the Python side or specific
to Python. It is on the side of the "coding of
characters".

1) Unicode is an abstract entity, it has to be encoded
for the system/device that will host it.
Using Python:
.encode(host_coding)

2) The host_coding scheme may not contain the
character (glyph/grapheme) corresponding to the
"unicode character". In that case, 2 possible
solutions, "ignore" it ou "replace" it with a
substitution character.
Using Python:
.encode(host_coding, "ignore")
.encode(host_coding, "replace")

3) Detecting the host_coding, the most difficult
task. Either you have to hard-code it or you
may expect Python find it via its sys.encoding.

4) Due to the nature of unicode, it the unique
way to do it correctly.

Expectedly failing and not failing examples.
Mainly Py3, but it doesn't matter. Note: Py3 encodes
and creates a byte string, which has to be
decoded to produce a native (unicode) string, here
with cp1252.


Py2

>>> u'éléphant\u2013abc'.encode('ascii')

Traceback (most recent call last):
  File "", line 1, in 
u'éléphant\u2013abc'.encode('ascii')
UnicodeEncodeError: 'ascii' codec can't encode character u'\xe9' in position 0: 
ordinal not in range(128)
>>> print(u'éléphant\u2013abc'.encode('cp1252'))
éléphant–abc
>>> 

Py3

>>> 'éléphant\u2013abc'.encode('ascii')
Traceback (most recent call last):
  File "", line 1, in 
UnicodeEncodeError: 'ascii' codec can't encode character '\xe9' in
position 0: ordinal not in range(128)
>>> 'éléphant\u2013abc'.encode('ascii', 'ignore')
b'lphantabc'
>>> 'éléphant\u2013abc'.encode('ascii', 'replace')
b'?l?phant?abc'
>>> 'éléphant\u2013abc'.encode('ascii', 'ignore').decode('cp1252')
'lphantabc'
>>> 'éléphant\u2013abc'.encode('ascii', 'replace').decode('cp1252')
'?l?phant?abc'
>>> 
>>> 'éléphant\u2013abc'.encode('cp1252').decode('cp1252')
'éléphant–abc'

>>> sys.stdout.encoding
'cp1252'
>>> 'éléphant\u2013abc'.encode(sys.stdout.encoding).decode('cp1252')
'éléphant–abc'

etc

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

Re: Right solution to unicode error?

[Hans Mulder]

On 8/11/12 00:53:49, Steven D'Aprano wrote:
> This error confuses me. Is that an exact copy and paste of the error, or 
> have you edited it or reconstructed it? Because it seems to me that if 
> task.subject is a unicode string, as it appears to be, calling print on 
> it should succeed:
> 
> py> s = u'ABC\u2013DEF'
> py> print s
> ABC–DEF

That would depend on whether python thinks sys.stdout can
handle UTF8.  For example, on my MacOS X box:

$ python2.6 -c 'print u"abc\u2013def"'
abc–def
$ python2.6 -c 'print u"abc\u2013def"' | cat
Traceback (most recent call last):
  File "", line 1, in 
UnicodeEncodeError: 'ascii' codec can't encode character u'\u2013' in
position 3: ordinal not in range(128)

This is because python knows that my terminal is capable
of handling UTF8, but it has no idea whether the program at
the other end of a pipe had that ability, so it'll fall
back to ASCII only if sys.stdout goes to a pipe.

Apparently the OP has a terminal that doesn't handle UTF8,
or one that Python doesn't know about.


Hope this helps,

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

isinstance(.., file) for Python 3

[Ulrich Eckhardt]

Hi!

I have two problems that are related and that I'd like to solve together.

Firstly, I have code that allows either a file or a string representing 
its content as parameter. If the parameter is a file, the content is 
read from the file. In Python 2, I used "isinstance(p, file)" to 
determine whether the parameter p is a file. In Python 3, the 
returnvalue of open() is of type _io.TextIOWrapper, while the built-in 
class file doesn't exist, so I can't use that code.


Secondly, checking for the type is kind-of ugly, because it means that I 
can't use an object that fits but that doesn't have the right type. In 
other words, it breaks duck-typing. This is already broken in the Python 
2 code, but since I have to touch the code anyway, I might as well fix 
it on the way.


If possible, I'm looking for a solution that works for Pythons 2 and 3, 
since I'm not fully through the conversion yet and have clients that 
might use the older snake for some time before shedding their skin.


Suggestions?

Uli


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

Re: isinstance(.., file) for Python 3

[MRAB]

On 2012-11-08 12:05, Ulrich Eckhardt wrote:

Hi!

I have two problems that are related and that I'd like to solve together.

Firstly, I have code that allows either a file or a string representing
its content as parameter. If the parameter is a file, the content is
read from the file. In Python 2, I used "isinstance(p, file)" to
determine whether the parameter p is a file. In Python 3, the
returnvalue of open() is of type _io.TextIOWrapper, while the built-in
class file doesn't exist, so I can't use that code.

Secondly, checking for the type is kind-of ugly, because it means that I
can't use an object that fits but that doesn't have the right type. In
other words, it breaks duck-typing. This is already broken in the Python
2 code, but since I have to touch the code anyway, I might as well fix
it on the way.

If possible, I'm looking for a solution that works for Pythons 2 and 3,
since I'm not fully through the conversion yet and have clients that
might use the older snake for some time before shedding their skin.

Suggestions?


Instead of checking whether it's a file, check whether it's a string!
--
http://mail.python.org/mailman/listinfo/python-list

Re: Unconverted data remains

[MRAB]

On 2012-11-08 08:04, Nikhil Verma wrote:

Hi

My Problem


I have a list :-
  L = ['Sunday November 11  2012 9:00pm ', 'Thursday November 15  2012
7:00pm ',\
  'Friday November 16  2012 7:00pm ', 'Monday November
19  2012 7:30pm ', \
  'Friday November 23  2012 7:30pm ', 'Sunday November
25  2012 8:00pm ',\
  'Monday November 262012 7:00pm ', 'Thursday November
29  2012 6:30pm ',\
  'Saturday December 1  20125:30pm ', 'Thursday December
6  2012 9:00pm ',\
  'Sunday December 9  2012 7:00pm ', 'Friday November 9
  2012 6:00pm ', \
  'Friday November 9  2012 7:00pm ', 'Friday November 9
  2012 7:00pm ']

final_event_time = [datetime.strptime(iterable, '%A %B %d %Y %I:%M%p')
for iterable in L]

and having this error Unconverted data remains . I am trying to convert
all these in datetime object.


It's complaining about the trailing space in the strings. Try removing
it.
--
http://mail.python.org/mailman/listinfo/python-list

Re: isinstance(.., file) for Python 3

[Chris Angelico]

On Thu, Nov 8, 2012 at 11:05 PM, Ulrich Eckhardt
 wrote:
> Firstly, I have code that allows either a file or a string representing its
> content as parameter. If the parameter is a file, the content is read from
> the file. In Python 2, I used "isinstance(p, file)" to determine whether the
> parameter p is a file...

Can you use the inverted check "isinstance(p, str)"? It's more likely
that you'll want to pass a file-like object than a string-like object.
This would work on Python 2 as well, though it's semantically
different; to safely check for both Unicode and bytes strings on both
Py2 and Py3, this may work:

# Once-off:
try:
basestring
except NameError:
basestring = (str, bytes)

# Is p a string?
if isinstance(p, basestring):
pass

It abuses the fact that isinstance will happily accept the
'basestring' common supertype of both strings in Python 2, but will
equally happily accept a tuple of types.

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

Re: isinstance(.., file) for Python 3

[Peter Otten]

Ulrich Eckhardt wrote:

> Hi!
> 
> I have two problems that are related and that I'd like to solve together.
> 
> Firstly, I have code that allows either a file or a string representing
> its content as parameter. If the parameter is a file, the content is
> read from the file. In Python 2, I used "isinstance(p, file)" to
> determine whether the parameter p is a file. In Python 3, the
> returnvalue of open() is of type _io.TextIOWrapper, while the built-in
> class file doesn't exist, so I can't use that code.
> 
> Secondly, checking for the type is kind-of ugly, because it means that I
> can't use an object that fits but that doesn't have the right type. In
> other words, it breaks duck-typing. This is already broken in the Python
> 2 code, but since I have to touch the code anyway, I might as well fix
> it on the way.
> 
> If possible, I'm looking for a solution that works for Pythons 2 and 3,
> since I'm not fully through the conversion yet and have clients that
> might use the older snake for some time before shedding their skin.
> 
> Suggestions?

In order of obviousness:
hasattr(p, "read")
not isinstance(p, str)
iter(p) is p

Or you change the interface

def f(*, contents=None, file=None):
if contents is None:
with open(file) as f:
contents = f.read()
... # work with contents



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

Re: isinstance(.., file) for Python 3

[Steven D'Aprano]

On Thu, 08 Nov 2012 13:05:22 +0100, Ulrich Eckhardt wrote:

> Firstly, I have code that allows either a file or a string representing
> its content as parameter. If the parameter is a file, the content is
> read from the file. In Python 2, I used "isinstance(p, file)" to
> determine whether the parameter p is a file. In Python 3, the
> returnvalue of open() is of type _io.TextIOWrapper, 

Incorrect.

py> type(open('x', 'wb'))


The type returned by open will depend on what you open and how you open 
it.

> while the built-in
> class file doesn't exist, so I can't use that code.

import io
file = io._IOBase

will probably work. But consider it a little smelly, since you're relying 
on an implementation detail.


> Secondly, checking for the type is kind-of ugly, because it means that I
> can't use an object that fits but that doesn't have the right type. In
> other words, it breaks duck-typing. This is already broken in the Python
> 2 code, but since I have to touch the code anyway, I might as well fix
> it on the way.

if hasattr(obj, 'read'):
# object is file-like enough to treat as a file
pass

That means that you can also use io.StringIO objects as pseudo-files too.



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

Re: Numpy module

[Anssi Saari]

farrellpolym...@gmail.com writes:

> Hello to the group!
>
> I've learned a lot about Ubuntu just trying to install numpy for Python 
> 3.2.3. I've finally managed to put it in the Python3.2 directory but when I 
> try to import it, I still get there's "no module named numpy." There are 
> other modules in the same directory, like 'email' and it imports fine.
>
> Does Numpy 1.6.2 not run with Python 3.2.3?
>
> Can anybody help? Thank you in advance.

What's the goal of this exercise? Ubuntu packages Python 3 and Numpy so
all you need to do is install packages python3 and python3-numpy. 
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: error

[inshu chauhan]

Actually data is neither a zanzibar nor a class nor a list.. its a yml
image. with pixels
I am trying to access pixels of a 3D image through this programme..





On Tue, Nov 6, 2012 at 8:59 PM, woooee  wrote:

> From this line, "data" appears to be a class
> if 0 < ix < data.width and 0 < iy < data.height:
> From this line, "data" appears to be a list, although a two
> dimensional list would be accessed as data[ix][iy]
> point = data[ix, iy]
>
> Also, returning a list from a function is a matter of preference.
> Some people argue that it should be returned to make it obvious.  If
> you do not know the difference between what is mutable and what is not
> mutable, then return everything until you do.
> --
> http://mail.python.org/mailman/listinfo/python-list
>
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: isinstance(.., file) for Python 3

[Duncan Booth]

Ulrich Eckhardt  wrote:

> If possible, I'm looking for a solution that works for Pythons 2 and 3, 
> since I'm not fully through the conversion yet and have clients that 
> might use the older snake for some time before shedding their skin.
> 
> Suggestions?

Why bother checking types at all?

def foo(file_or_string):
try:
data = file_or_string.read()
except AttributeError:
data = file_or_string
... use data ...

-- 
Duncan Booth http://kupuguy.blogspot.com
-- 
http://mail.python.org/mailman/listinfo/python-list

RE: Right solution to unicode error?

[Anders Schneiderman]

Thanks, Oscar and Ramit! This is exactly what I was looking for.

Anders 


> -Original Message-
> From: Oscar Benjamin [mailto:oscar.j.benja...@gmail.com]
> Sent: Wednesday, November 07, 2012 6:27 PM
> To: Anders Schneiderman
> Cc: python-list@python.org
> Subject: Re: Right solution to unicode error?
> 
> On 7 November 2012 22:17, Anders  wrote:
> >
> > Traceback (most recent call last):
> >   File "outlook_tasks.py", line 66, in 
> > my_tasks.dump_today_tasks()
> >   File "C:\Users\Anders\code\Task List\tasks.py", line 29, in
> > dump_today_tasks
> > print task.subject
> > UnicodeEncodeError: 'ascii' codec can't encode character u'\u2013' in
> > position 42: ordinal not in range(128)
> >
> > Here's where I'm getting stuck.  In the code above I was just printing
> > the subject so I can see whether the script is working properly.
> > Ultimately what I want to do is parse the tasks I'm interested in and
> > then create an HTML file containing those tasks.  Given that, what's
> > the best way to fix this problem?
> 
> Are you using cmd.exe (standard Windows terminal)? If so, it does not
> support unicode and Python is telling you that it cannot encode the string in 
> a
> way that can be understood by your terminal. You can try using chcp to set
> the code page to something that works with your script.
> 
> If you are only printing it for debugging purposes you can just print the 
> repr()
> of the string which will be ascii and will come out fine in your terminal. If 
> you
> want to write it to a html file you should encode the string with whatever
> encoding (probably utf-8) you use in the html file. If you really just want 
> your
> script to be able to print unicode characters then you need to use something
> other than cmd.exe (such as IDLE).
> 
> 
> Oscar

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

Re: Right solution to unicode error?

[Oscar Benjamin]

On 8 November 2012 00:44, Oscar Benjamin  wrote:
> On 7 November 2012 23:51, Andrew Berg  wrote:
>> On 2012.11.07 17:27, Oscar Benjamin wrote:
>>> Are you using cmd.exe (standard Windows terminal)? If so, it does not
>>> support unicode
>> Actually, it does. Code page 65001 is UTF-8. I know that doesn't help
>> the OP since Python versions below 3.3 don't support cp65001, but I
>> think it's important to point out that the Windows command line system
>> (it is not unique to cmd) does in fact support Unicode.
>
> I have tried to use code page 65001 and it didn't work for me even if
> I did use a version of Python (possibly 3.3 alpha) that claimed to
> support it.

I stand corrected. I've just checked and codepage 65001 does work in
cmd.exe (on this machine):

O:\>Q:\tools\Python33\python -c print('abc\u2013def')
Traceback (most recent call last):
  File "", line 1, in 
  File "Q:\tools\Python33\lib\encodings\cp850.py", line 19, in encode
return codecs.charmap_encode(input,self.errors,encoding_map)[0]
UnicodeEncodeError: 'charmap' codec can't encode character '\u2013' in
position 3: character maps to
 

O:\>chcp 65001
Active code page: 65001

O:\>Q:\tools\Python33\python -c print('abc\u2013def')
abc-def


O:\>Q:\tools\Python33\python -c print('\u03b1')
α

It would be a lot better though if it just worked straight away
without me needing to set the code page (like the terminal in every
other OS I use).


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

Re: Numpy module

[Colin J. Williams]

On 08/11/2012 8:09 AM, Anssi Saari wrote:

farrellpolym...@gmail.com writes:


[snip]

Does Numpy 1.6.2 not run with Python 3.2.3?


It does on the Raspberry Pi, which uses a variant of Debian.

Colin W.

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

Executing .exe on a remote Windows machine

[Kevin Holleran]

Good morning,

I wrote a python script to connect out to a bunch of my remote machines
that are running some software.  It modifies a bunch of the config files
for me.  After making the changes, I need to restart the software.  The way
to do this is to call an .exe passing in a argument 'restart'  Simply
restarting services is NOT acceptable & rebooting the machine isn't either.

I was trying to find a way to simply call the .exe on the remote machine
with subprocess but how can I get it to execute on the remote machine?
 These machines do not have SSH.

Is there a way to do this or am I stuck coordinating a time when the
machines can be rebooted? (because this would be faster than asking anyone
on site to execute the command)

Thanks for your help.

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

Re: Multi-dimensional list initialization

[wrw]

On Nov 7, 2012, at 11:51 PM, Andrew Robinson  wrote:

> On 11/07/2012 04:00 PM, Steven D'Aprano wrote:
>> Andrew, it appears that your posts are being eaten or rejected by my
>> ISP's news server, because they aren't showing up for me. Possibly a side-
>> effect of your dates being in the distant past?
> Date has been corrected since two days ago.  It will remain until a reboot
> Ignorance, though, might be bliss...
> 
>> Every now and again I come across somebody who tries to distinguish between 
>> "call by foo" and "pass by foo", but nobody has been able to explain the 
>> difference (if any) to me.
> I think the "Call by foo" came into vogue around the time of C++; Eg: It's in 
> books like C++ for C programmers;  I never saw it used before then so I 
> *really* don't know for sure…
> 

Just as an aside - there is a famous quote from Niklaus Wirt, who, when asked 
how he pronounced his name, is said to have replied:  "Well you can call me by 
name, Veert, or you can call me by value, Worth."

That would have been sometime in the early 60s, when he was at Stanford.

-Bill


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

Re: Executing .exe on a remote Windows machine

[Tim Golden]

On 08/11/2012 14:25, Kevin Holleran wrote:
> Good morning,
> 
> I wrote a python script to connect out to a bunch of my remote machines
> that are running some software.  It modifies a bunch of the config files
> for me.  After making the changes, I need to restart the software.  The
> way to do this is to call an .exe passing in a argument 'restart'
>  Simply restarting services is NOT acceptable & rebooting the machine
> isn't either.
> 
> I was trying to find a way to simply call the .exe on the remote machine
> with subprocess but how can I get it to execute on the remote machine?
>  These machines do not have SSH.  

WMI can usually help with this (although there are limitations on what
you can execute via WMI). Also people recommend sysinternals' psexec.
(I've never tried it myself).

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

Re: Executing .exe on a remote Windows machine

[Kevin Holleran]

My goodness psexec.

thanks can't believe that didn't come to me...



--
Kevin Holleran
Master of Science, Computer Information Systems
Grand Valley State University
Master of Business Administration
Western Michigan University
SANS GCFE, CCNA, ISA, MCSA, MCDST, MCP

My Paleo & Fitness Blog 

"Do today what others won't, do tomorrow what others can't" - SEALFit

"We are what we repeatedly do. Excellence, then, is not an act, but a
habit." - Aristotle



On Thu, Nov 8, 2012 at 9:31 AM, Tim Golden  wrote:

> On 08/11/2012 14:25, Kevin Holleran wrote:
> > Good morning,
> >
> > I wrote a python script to connect out to a bunch of my remote machines
> > that are running some software.  It modifies a bunch of the config files
> > for me.  After making the changes, I need to restart the software.  The
> > way to do this is to call an .exe passing in a argument 'restart'
> >  Simply restarting services is NOT acceptable & rebooting the machine
> > isn't either.
> >
> > I was trying to find a way to simply call the .exe on the remote machine
> > with subprocess but how can I get it to execute on the remote machine?
> >  These machines do not have SSH.
>
> WMI can usually help with this (although there are limitations on what
> you can execute via WMI). Also people recommend sysinternals' psexec.
> (I've never tried it myself).
>
> TJG
> --
> http://mail.python.org/mailman/listinfo/python-list
>
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Right solution to unicode error?

[wxjmfauth]

Le jeudi 8 novembre 2012 15:07:23 UTC+1, Oscar Benjamin a écrit :
> On 8 November 2012 00:44, Oscar Benjamin  wrote:
> 
> > On 7 November 2012 23:51, Andrew Berg  wrote:
> 
> >> On 2012.11.07 17:27, Oscar Benjamin wrote:
> 
> >>> Are you using cmd.exe (standard Windows terminal)? If so, it does not
> 
> >>> support unicode
> 
> >> Actually, it does. Code page 65001 is UTF-8. I know that doesn't help
> 
> >> the OP since Python versions below 3.3 don't support cp65001, but I
> 
> >> think it's important to point out that the Windows command line system
> 
> >> (it is not unique to cmd) does in fact support Unicode.
> 
> >
> 
> > I have tried to use code page 65001 and it didn't work for me even if
> 
> > I did use a version of Python (possibly 3.3 alpha) that claimed to
> 
> > support it.
> 
> 
> 
> I stand corrected. I've just checked and codepage 65001 does work in
> 
> cmd.exe (on this machine):
> 
> 
> 
> O:\>Q:\tools\Python33\python -c print('abc\u2013def')
> 
> Traceback (most recent call last):
> 
>   File "", line 1, in 
> 
>   File "Q:\tools\Python33\lib\encodings\cp850.py", line 19, in encode
> 
> return codecs.charmap_encode(input,self.errors,encoding_map)[0]
> 
> UnicodeEncodeError: 'charmap' codec can't encode character '\u2013' in
> 
> position 3: character maps to
> 
>  
> 
> 
> 
> O:\>chcp 65001
> 
> Active code page: 65001
> 
> 
> 
> O:\>Q:\tools\Python33\python -c print('abc\u2013def')
> 
> abc-def
> 
> 
> 
> 
> 
> O:\>Q:\tools\Python33\python -c print('\u03b1')
> 
> α
> 
> 
> 
> It would be a lot better though if it just worked straight away
> 
> without me needing to set the code page (like the terminal in every
> 
> other OS I use).
> 
> 
> 
> 
> 
> Oscar

--

It *WORKS* straight away. The problem is that
people do not wish to use unicode correctly
(eg. Mulder's example).
Read the point 1) and 4) in my previous post.

Unicode and in general the coding of the characters
have nothing to do with the os's or programming languages.

jmf

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

Re: isinstance(.., file) for Python 3

[Stefan Behnel]

Duncan Booth, 08.11.2012 14:58:
> Ulrich Eckhardt wrote:
>> If possible, I'm looking for a solution that works for Pythons 2 and 3, 
>> since I'm not fully through the conversion yet and have clients that 
>> might use the older snake for some time before shedding their skin.
>>
>> Suggestions?
> 
> Why bother checking types at all?
> 
> def foo(file_or_string):
> try:
> data = file_or_string.read()
> except AttributeError:
> data = file_or_string
> ... use data ...

Or, a tiny bit more safely:

try:
read = file_or_string.read
except AttributeError:
data = file_or_string
else:
data = read()

I'd rather go with one of the previous solutions, though.

Stefan


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

Re: Executing .exe on a remote Windows machine

[Kevin Holleran]

On Thu, Nov 8, 2012 at 9:43 AM, Kevin Holleran  wrote:

> My goodness psexec.
>
> thanks can't believe that didn't come to me...
>
>
>
>
> On Thu, Nov 8, 2012 at 9:31 AM, Tim Golden  wrote:
>
>> On 08/11/2012 14:25, Kevin Holleran wrote:
>> > Good morning,
>> >
>> > I wrote a python script to connect out to a bunch of my remote machines
>> > that are running some software.  It modifies a bunch of the config files
>> > for me.  After making the changes, I need to restart the software.  The
>> > way to do this is to call an .exe passing in a argument 'restart'
>> >  Simply restarting services is NOT acceptable & rebooting the machine
>> > isn't either.
>> >
>> > I was trying to find a way to simply call the .exe on the remote machine
>> > with subprocess but how can I get it to execute on the remote machine?
>> >  These machines do not have SSH.
>>
>> WMI can usually help with this (although there are limitations on what
>> you can execute via WMI). Also people recommend sysinternals' psexec.
>> (I've never tried it myself).
>>
>> TJG
>> --
>> http://mail.python.org/mailman/listinfo/python-list
>>
>
>

OK, not quite resolved yet

My code

[code]
try:
print("Attempting to restart Splunk...")
subprocess.call(["psexec", "" + host, "'c:\\Program
Files\\Splunk\\bin\\splunk.exe'", "restart"])
[/code]

& am getting:

[output]
Attempting to restart Splunk...

PsExec v1.98 - Execute processes remotely
Copyright (C) 2001-2010 Mark Russinovich
Sysinternals - www.sysinternals.com


PsExec could not start 'c:\Program Files\Splunk\bin\splunk.exe' restart on
[IP_ADDRESS]:
The filename, directory name, or volume label syntax is incorrect.
[/output]

I am simply trying to restart the splunk forwarder instance

Any thoughts??

Thanks.

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

Re: Multi-dimensional list initialization

[Ian Kelly]

On Thu, Nov 8, 2012 at 1:26 AM, Andrew Robinson
 wrote:
> OK: Then copy by reference using map:
>
> values = zip(   map( lambda:times, xrange(num_groups) )   )
> if len(values) < len(times) * num_groups ...
>
> Done.  It's clearer than a list comprehension and you still really don't
> need a list multiply.

That is not equivalent to the original.  Even had you not omitted some parts:

values = zip(samples, map(lambda i: times, range(num_groups)))

This still has the problem that map returns a list of num_groups
elements, each of which is times.  The desired value to be passed into
zip is a *single* sequence containing len(times) * num_groups
elements.  This is easily handled by list multiplication, but not so
easily by map or by a single list comprehension.  Looking back at the
'ini' solution you proposed before, I see that this also would be a
problem there.  Fixing the above, it would have to be something like:

values = zip(samples, reduce(operator.add, map(lambda i: times,
range(num_groups)), []))

Or from how I understand the 'ini' syntax to work:

values = zip(samples, reduce(operator.add, [lambda: times, ini
xrange(num_groups)], []))

Which brings to mind another point that I want to get to in a moment.
But when I said that I would use map instead, I meant that *if* the
body of the list comprehension is just a function application, then I
would prefer to use map over the list comprehension.  But in the above
I see no benefit in using a lambda in the first place.

Getting back to that other point, notice what we ended up doing in
both of those constructions above: repeated list concatenation as a
substitute for multiplication.  In fact, when we multiply (aList * 5),
this should be the equivalent of (aList + aList + aList + aList
+aList), should it not?  Clearly, however, there should be no implicit
copying involved in mere list concatenation.  For one thing, if the
user wants to concatenate copies, that is quite easily done
explicitly: (aList[:] + aList[:]) instead of (aList + aList).  For
another, list concatenation is less likely to be used for an
initialization process.  If list multiplication were to copy nested
lists, then, this would break the intuitive notion that list
multiplication is equivalent to repeated list concatenation.

> Yes, but you're very blind to history and code examples implementing the
> slice operation.
> slice usually depends on index; index does not depend on slice.
> Slice is suggested to be implemented by multiple calls to single indexes in
> traditional usage and documentation.

...and then by composing the elements located at those indexes into a
subsequence.

> The xrange(,,)[:] implementation breaks the tradition, because it doesn't
> call index multiple times; nor does it return a result equivalent identical
> to doing that.

Whether any given __getitem__ slicing implementation recursively calls
__getitem__ with a series of indexes or not is an implementation
detail.  If it were possible to index a range object multiple times
and then stuff the results into another range object, then the slicing
result would be equivalent.  The only reason it is not is that you
cannot construct a range object in that fashion.

I think that what you're expecting is that range(5)[:] should return a
list in Python 3 because it returns a list in Python 2.  This does not
represent a change in slicing behavior -- in fact, all you got by
slicing an xrange object in Python 2 was a TypeError.  This represents
an intentional break in backward compatibility between Python 2 and
Python 3, which was the purpose of Python 3 -- to fix a lot of
existing warts in Python by breaking them all at once, rather than
progressively over a long string of versions.  Users porting their
scripts from Python 2 to Python 3 are advised to replace "range(...)"
with "list(range(...))" if what they actually want is a list, and I
believe the 2to3 tool does this automatically.  Once the range object
is converted to a list, there is no further break with Python 2 --
slicing a list gives you a list, just as it always has.

In a nutshell, yes: range(...)[:] produces a different result in
Python 3 than in Python 2, just as it does without the slicing
operation tacked on.  It was never intended that scripts written for
Python 2 should be able to run in Python 3 unchanged without careful
attention to detail.
-- 
http://mail.python.org/mailman/listinfo/python-list

int.__init__ incompatible in Python 3.3

[Ulrich Eckhardt]

Hi!

Preparing for an upgrade from 2.7 to 3, I stumbled across an 
incompatibility between 2.7 and 3.2 on one hand and 3.3 on the other:


class X(int):
def __init__(self, value):
super(X, self).__init__(value)
X(42)

On 2.7 and 3.2, the above code works. On 3.3, it gives me a "TypeError: 
object.__init__() takes no parameters". To some extent, this makes sense 
to me, because the int subobject is not initialized in __init__ but in 
__new__. As a workaround, I can simple drop the parameter from the call. 
However, breaking backward compatibility is another issue, so I wonder 
if that should be considered as a bug.


Bug? Feature? Other suggestions?


Uli


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

Re: Executing .exe on a remote Windows machine

[Tim Golden]

On 08/11/2012 15:37, Kevin Holleran wrote:
> [code]
> try:
> print("Attempting to restart Splunk...")
> subprocess.call(["psexec", "" + host, "'c:\\Program
> Files\\Splunk\\bin\\splunk.exe'", "restart"])
> [/code]
> 
> & am getting:
> 
> [output]
> Attempting to restart Splunk...
> 
> PsExec v1.98 - Execute processes remotely
> Copyright (C) 2001-2010 Mark Russinovich
> Sysinternals - www.sysinternals.com 
> 
> 
> PsExec could not start 'c:\Program Files\Splunk\bin\splunk.exe' restart
> on [IP_ADDRESS]:
> The filename, directory name, or volume label syntax is incorrect.
> [/output]
> 
> I am simply trying to restart the splunk forwarder instance
> 
> Any thoughts??

Lose the nested quotes in the .exe path; subprocess will take care of that:

subprocess.call(["psexec", "" + host, "c:\\Program
Files\\Splunk\\bin\\splunk.exe", "restart"])


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

Re: Executing .exe on a remote Windows machine

[Chris Rebert]

On Thursday, November 8, 2012, Kevin Holleran wrote:

> On Thu, Nov 8, 2012 at 9:43 AM, Kevin Holleran 
> 
> > wrote:
>
>> My goodness psexec.
>>
>> thanks can't believe that didn't come to me...
>>
>>
>>
>>
>> On Thu, Nov 8, 2012 at 9:31 AM, Tim Golden 
>> 
>> > wrote:
>>
>>> On 08/11/2012 14:25, Kevin Holleran wrote:
>>> > Good morning,
>>> >
>>> > I wrote a python script to connect out to a bunch of my remote machines
>>> > that are running some software.  It modifies a bunch of the config
>>> files
>>> > for me.  After making the changes, I need to restart the software.  The
>>> > way to do this is to call an .exe passing in a argument 'restart'
>>> >  Simply restarting services is NOT acceptable & rebooting the machine
>>> > isn't either.
>>> >
>>> > I was trying to find a way to simply call the .exe on the remote
>>> machine
>>> > with subprocess but how can I get it to execute on the remote machine?
>>> >  These machines do not have SSH.
>>>
>>> WMI can usually help with this (although there are limitations on what
>>> you can execute via WMI). Also people recommend sysinternals' psexec.
>>> (I've never tried it myself).
>>>
>>> TJG
>>> --
>>> http://mail.python.org/mailman/listinfo/python-list
>>>
>>
>>
>
> OK, not quite resolved yet
>
> My code
>
> [code]
> try:
> print("Attempting to restart Splunk...")
> subprocess.call(["psexec", "" + host, "'c:\\Program
> Files\\Splunk\\bin\\splunk.exe'", "restart"])
> [/code]
>
> & am getting:
>
> [output]
> Attempting to restart Splunk...
>
> PsExec v1.98 - Execute processes remotely
> Copyright (C) 2001-2010 Mark Russinovich
> Sysinternals - www.sysinternals.com
>
>
> PsExec could not start 'c:\Program Files\Splunk\bin\splunk.exe' restart on
> [IP_ADDRESS]:
> The filename, directory name, or volume label syntax is incorrect.
> [/output]
>
> I am simply trying to restart the splunk forwarder instance
>
> Any thoughts??
>

Remove the apostrophes surrounding the path to Splunk's executable. The
subprocess module already takes care of the quoting for you, so the
apostrophes are unnecessary and are being interpreted literally.


-- 
Cheers,
Chris
--
http://rebertia.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: error

[Dave Angel]

On 11/08/2012 08:47 AM, inshu chauhan wrote:
> Actually data is neither a zanzibar nor a class nor a list.. its a yml
> image. with pixels
> I am trying to access pixels of a 3D image through this programme..
> 


You want us to keep guessing?  And without supplying any new
information?  There's no such thing as a yml image in Python, though
there might be some library that supports such a thing with some class
structure.  And you just might have downloaded it from the
http://www.ymlgroup.com/obscurehiddenlocation/downloads site, and
imported  it using  from notzanzibar import DataType.

Then you'd have instantiated it in some code like
  data = DataType(filename)

and then the type of data would be notzanzibar.DataType  and the docs
would be probably available somewhere on www.invalid.com/docs

The only new guess:

A 3D image would presumably have 3 subscripts, and you're only supplying
two.



If you want help, be explicit:

1) what version of CPython are you using, and on what OS?
2) what web site did you download some extra library from ?
3) what import statement did you use ?
4) How are all those global variables initialized ?
5) What command did you use to start the script ?  Did you run it from
command.com, or from some IDE ?
5) Exactly what error message did you get, including the traceback ?
6) What have you done to try to figure out your own error?




-- 

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

Re: Executing .exe on a remote Windows machine

[Kevin Holleran]

On Thu, Nov 8, 2012 at 11:32 AM, Chris Rebert  wrote:

> On Thursday, November 8, 2012, Kevin Holleran wrote:
>
>> On Thu, Nov 8, 2012 at 9:43 AM, Kevin Holleran  wrote:
>>
>>> My goodness psexec.
>>>
>>> thanks can't believe that didn't come to me...
>>>
>>>
>>>
>>>
>>> On Thu, Nov 8, 2012 at 9:31 AM, Tim Golden  wrote:
>>>
 On 08/11/2012 14:25, Kevin Holleran wrote:
 > Good morning,
 >
 > I wrote a python script to connect out to a bunch of my remote
 machines
 > that are running some software.  It modifies a bunch of the config
 files
 > for me.  After making the changes, I need to restart the software.
  The
 > way to do this is to call an .exe passing in a argument 'restart'
 >  Simply restarting services is NOT acceptable & rebooting the machine
 > isn't either.
 >
 > I was trying to find a way to simply call the .exe on the remote
 machine
 > with subprocess but how can I get it to execute on the remote machine?
 >  These machines do not have SSH.

 WMI can usually help with this (although there are limitations on what
 you can execute via WMI). Also people recommend sysinternals' psexec.
 (I've never tried it myself).

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

>>>
>>>
>>
>> OK, not quite resolved yet
>>
>> My code
>>
>> [code]
>> try:
>> print("Attempting to restart Splunk...")
>> subprocess.call(["psexec", "" + host, "'c:\\Program
>> Files\\Splunk\\bin\\splunk.exe'", "restart"])
>> [/code]
>>
>> & am getting:
>>
>> [output]
>> Attempting to restart Splunk...
>>
>> PsExec v1.98 - Execute processes remotely
>> Copyright (C) 2001-2010 Mark Russinovich
>> Sysinternals - www.sysinternals.com
>>
>>
>> PsExec could not start 'c:\Program Files\Splunk\bin\splunk.exe' restart
>> on [IP_ADDRESS]:
>> The filename, directory name, or volume label syntax is incorrect.
>>  [/output]
>>
>> I am simply trying to restart the splunk forwarder instance
>>
>> Any thoughts??
>>
>
> Remove the apostrophes surrounding the path to Splunk's executable. The
> subprocess module already takes care of the quoting for you, so the
> apostrophes are unnecessary and are being interpreted literally.
>
>
> --
> Cheers,
> Chris
> --
> http://rebertia.com
>

Thanks Tim & Chris... you guys are my heroes for today :)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: accuracy problem in calculation

[Chris Angelico]

On Fri, Nov 9, 2012 at 4:05 AM, Debashish Saha  wrote:
> (15+1.00067968)-(15+1.00067961)
> Out[102]: 2.384185791015625e-07
>
> 1.00067968-(1.00067961)
> Out[103]: 7.1866624e-08
>
> above i am showing the two different results,though the two outputs
> should be same if we do it in copy(the lass one is acceptable value).
> so my question is how to increase the accuracy(windows7(32bit)
> ,python2.7.2)

Welcome to floating point. You're working with very large and very
small numbers, and you _will_ lose accuracy.

There are a few options. It's possible that a 64-bit build of Python
will give you more accuracy, but better would be to separate your huge
numbers from your tiny ones and work with them separately.
Alternatively, switch to the Decimal or Fraction types, but be aware
that your script will probably run a lot slower.

>>> from decimal import Decimal
>>> (Decimal("15")+Decimal("1.00067968"))-(Decimal("15")+Decimal("1.00067961"))
Decimal('7E-8')
>>> Decimal("1.00067968")-Decimal("1.00067961")
Decimal('7E-8')

Unless something's tying you to Python 2, consider moving to Python 3.
You may find that, on Python 3.3, you can switch to Decimal without
losing too much performance.

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

Re: int.__init__ incompatible in Python 3.3

[Ian Kelly]

On Thu, Nov 8, 2012 at 8:55 AM, Ulrich Eckhardt
 wrote:
> Hi!
>
> Preparing for an upgrade from 2.7 to 3, I stumbled across an incompatibility
> between 2.7 and 3.2 on one hand and 3.3 on the other:
>
> class X(int):
> def __init__(self, value):
> super(X, self).__init__(value)
> X(42)
>
> On 2.7 and 3.2, the above code works. On 3.3, it gives me a "TypeError:
> object.__init__() takes no parameters". To some extent, this makes sense to
> me, because the int subobject is not initialized in __init__ but in __new__.
> As a workaround, I can simple drop the parameter from the call. However,
> breaking backward compatibility is another issue, so I wonder if that should
> be considered as a bug.
>
> Bug? Feature? Other suggestions?

A similar change was made to object.__init__ in 2.6, so this could
just be bringing the behavior of int into line with object.  There's
nothing about it in the whatsnew document, though.  I say open a bug
report and let the devs sort it out.
-- 
http://mail.python.org/mailman/listinfo/python-list

duck typing assert

[Andriy Kornatskyy]

People who come from strongly typed languages that offer interfaces often are 
confused by lack of one in Python. Python, being dynamic typing programming 
language, follows duck typing principal. It can as simple as this:

assert looks(Foo).like(IFoo)

The post below shows how programmer can assert duck typing between two Python 
classes:

mindref.blogspot.com/2012/11/python-duck-typing-assert.html

Comments or suggestions are welcome.

Thanks.

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

duck typing assert‏

[Andriy Kornatskyy]

People who come from strongly typed languages that offer interfaces often are 
confused by lack of one in Python. Python, being dynamic typing programming 
language, follows duck typing principal. It can as simple as this:
 
assert looks(Foo).like(IFoo)
 
The post below shows how programmer can assert duck typing between two Python 
classes:
 
http://mindref.blogspot.com/2012/11/python-duck-typing-assert.html
 
Comments or suggestions are welcome.
 
Thanks.
 
Andriy Kornatskyy 
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: accuracy problem in calculation

[Dave Angel]

On 11/08/2012 12:05 PM, Debashish Saha wrote:
> (15+1.00067968)-(15+1.00067961)
> Out[102]: 2.384185791015625e-07
>
> 1.00067968-(1.00067961)
> Out[103]: 7.1866624e-08
>
> above i am showing the two different results,though the two outputs
> should be same if we do it in copy(the lass one is acceptable value).
> so my question is how to increase the accuracy(windows7(32bit)
> ,python2.7.2)

To improve accuracy, do some algebra before coding brute force.  If you
know you'll be subtracting two values that are nearly equal, see if you
can factor out the large part, and only subtract the small parts.

If you have a processor with 16 digits of float accuracy, and you
calculate an 18 digit sum, you're going to lose 3 digts at a minimum. 
Each sum has the same problem.  So now you have lopped off all the
digits that are different.  So subtracting them is meaningless.

Picture needing to know how thick a leaf is.  So measure the distance
from one side of it to the sun.  Then measure the distance from the
other side to the sun.  Now just subtract the answers.  Silly, isn't it?

You have  (a+b) - (a+c), where a is much larger than either b or c.  So
simplify it to b-c before programming it.  Oh, yeah, that's your second
approach.

More generally, if you have a sum of 3 or more values (which you can get
by just stating the problem as a + b + -a + -c), you can usually
minimize error by reordering the arithmetic, based on the sizes of the
items.  Fortunately Python has a library function that knows how to do that:

http://docs.python.org/2/library/math.html#math.fsum

If you want to postpone the problem so instead of hitting at 15 digits
or so, it hits at a few hundred digits, you could use decimal.Decimal,
which is a standard library in Python.  It permits you to specify your
own precision, instead of being what Intel (professor Kahn) decided on
in about 1985.  They constrained themselves to what could be encoded in
8 bytes.  Naturally, if you ask for much higher precision with Decimal,
you'll pay for it with space and/or time.  But apparently in 3.3, they
did a very good job minimizing the time it takes, for reasonable precision.

Interestingly, I got a similar question in about 1977, concerning a trig
package I had microcoded.  A man was measuring the flatness of a
hypothetical level table (which must be curved, of course).  And he did
it with trig, and effectively by subtracting two measurements to the
center of the earth.  I was able to simplify his problem using some
geometry (similar triangles) to get all the accuracy he needed.  And
strangely enough, the trig canceled out and was unnecessary.


-- 

DaveA

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

how to simulate tar filename substitution across piped subprocess.Popen() calls?

[jkn]

Hi All
i am trying to build up a set of subprocess.Ponen calls to
replicate the effect of a horribly long shell command. I'm not clear
how I can do one part of this and wonder if anyone can advise. I'm on
Linux, fairly obviously.

I have a command which (simplified) is a tar -c command piped through
to xargs:

tar  -czvf myfile.tgz -c $MYDIR mysubdir/ | xargs -I '{}' sh -c "test -
f $MYDIR/'{}'"

(The full command is more complicated than this; I got it from a shell
guru).

IIUC, when called like this, the two occurences of '{}' in the xargs
command will get replaced with the file being added to the tarfile.

Also IIUC, I will need two calls to subprocess.Popen() and use
subprocess.stdin on the second to receive the output from the first.
But how can I achive the substitution of the '{}' construction across
these two calls?

Apologies if I've made any howlers in this description - it's very
likely...

Cheers
J^n






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

Re: accuracy problem in calculation

[Grant Edwards]

On 2012-11-08, Chris Angelico  wrote:
> On Fri, Nov 9, 2012 at 4:05 AM, Debashish Saha  wrote:

>> (15+1.00067968)-(15+1.00067961)
>> Out[102]: 2.384185791015625e-07
>>
>> 1.00067968-(1.00067961)
>> Out[103]: 7.1866624e-08
>>
>> above i am showing the two different results,though the two outputs
>> should be same if we do it in copy (the lass one is acceptable value).

Then do it the way you did the last one.

Seriously, that's the answer they teach you in numerical analysis
classes.

>> so my question is how to increase the accuracy(windows7(32bit)
>> ,python2.7.2)
>
> Welcome to floating point. You're working with very large and very
> small numbers, and you _will_ lose accuracy.
>
> There are a few options. It's possible that a 64-bit build of Python
> will give you more accuracy,

Pretty doubtful.  64-bit and 32-bit builds on all common OSes and
hardware are both going to use 64-bit IEEE floating point.

> but better would be to separate your huge numbers from your tiny ones
> and work with them separately.

> Alternatively, switch to the Decimal or Fraction types, but be aware
> that your script will probably run a lot slower.

Or admit to yourself that the measurements that produce your input
data just aren't that accurate anyway and forget about it.  :)

-- 
Grant Edwards   grant.b.edwardsYow! Bo Derek ruined
  at   my life!
  gmail.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Right solution to unicode error?

[Oscar Benjamin]

On 8 November 2012 15:05,   wrote:
> Le jeudi 8 novembre 2012 15:07:23 UTC+1, Oscar Benjamin a écrit :
>> On 8 November 2012 00:44, Oscar Benjamin  wrote:
>> > On 7 November 2012 23:51, Andrew Berg  wrote:
>> >> On 2012.11.07 17:27, Oscar Benjamin wrote:
>>
>> >>> Are you using cmd.exe (standard Windows terminal)? If so, it does not
>> >>> support unicode
>>
>> >> Actually, it does. Code page 65001 is UTF-8. I know that doesn't help
>> >> the OP since Python versions below 3.3 don't support cp65001, but I
>> >> think it's important to point out that the Windows command line system
>> >> (it is not unique to cmd) does in fact support Unicode.
>>
>> > I have tried to use code page 65001 and it didn't work for me even if
>> > I did use a version of Python (possibly 3.3 alpha) that claimed to
>> > support it.
>>
>> I stand corrected. I've just checked and codepage 65001 does work in
>> cmd.exe (on this machine):
>>
>> O:\>chcp 65001
>> Active code page: 65001
>>
>> O:\>Q:\tools\Python33\python -c print('abc\u2013def')
>> abc-def
>>
>> O:\>Q:\tools\Python33\python -c print('\u03b1')
>> α
>>
>> It would be a lot better though if it just worked straight away
>> without me needing to set the code page (like the terminal in every
>> other OS I use).
>
> It *WORKS* straight away. The problem is that
> people do not wish to use unicode correctly
> (eg. Mulder's example).
> Read the point 1) and 4) in my previous post.
>
> Unicode and in general the coding of the characters
> have nothing to do with the os's or programming languages.

I don't know what you mean that it works "straight away".

The default code page on my machine is cp850.

O:\>chcp
Active code page: 850

cp850 doesn't understand utf-8. It just prints garbage:

O:\>Q:\tools\Python33\python -c "import sys;
sys.stdout.buffer.write('\u03b1\n'.encode('utf-8'))"
╬▒

Using the correct encoding doesn't help:

O:\>Q:\tools\Python33\python -c "import sys;
sys.stdout.buffer.write('\u03b1\n'.encode('cp850'))"
Traceback (most recent call last):
  File "", line 1, in 
  File "Q:\tools\Python33\lib\encodings\cp850.py", line 12, in encode
return codecs.charmap_encode(input,errors,encoding_map)
UnicodeEncodeError: 'charmap' codec can't encode character '\u03b1' in
position 0: character maps to
 

O:\>Q:\tools\Python33\python -c "import sys;
sys.stdout.buffer.write('\u03b1\n'.encode(sys.stdout.en
coding))"
Traceback (most recent call last):
  File "", line 1, in 
  File "Q:\tools\Python33\lib\encodings\cp850.py", line 12, in encode
return codecs.charmap_encode(input,errors,encoding_map)
UnicodeEncodeError: 'charmap' codec can't encode character '\u03b1' in
position 0: character maps to
 

If I want the other characters to work I need to change the code page:

O:\>chcp 65001
Active code page: 65001

O:\>Q:\tools\Python33\python -c "import sys;
sys.stdout.buffer.write('\u03b1\n'.encode('utf-8'))"
α

O:\>Q:\tools\Python33\python -c "import sys;
sys.stdout.buffer.write('\u03b1\n'.encode(sys.stdout.en
coding))"
α


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

Re: duck typing assert

[Ian Kelly]

On Thu, Nov 8, 2012 at 10:30 AM, Andriy Kornatskyy
 wrote:
>
> People who come from strongly typed languages that offer interfaces often are 
> confused by lack of one in Python. Python, being dynamic typing programming 
> language, follows duck typing principal. It can as simple as this:
>
> assert looks(Foo).like(IFoo)
>
> The post below shows how programmer can assert duck typing between two Python 
> classes:
>
> mindref.blogspot.com/2012/11/python-duck-typing-assert.html
>
> Comments or suggestions are welcome.

Overall, it looks potentially useful to me.  Looking over the
wheezy.core.introspection source, it appears to ignore special method
names.  For example, if you do:

class IFoo(object):
def __len__(self):
pass

class Foo(object):
pass

assert looks(Foo).like(IFoo)

I would expect this to fail, but judging from the code it would not,
as it ignores all names starting with '_'.  That makes some sense for
private names (but on the other hand, why would you declare private
names in an interface unless you want to enforce their presence?), but
names like __len__ should not be considered private.

Another comment I have is on properties, and descriptors in general.
Does this allow something declared as a property to be implemented as
a simple class attribute, and vice versa?  Or can something declared
as a property be implemented with some custom descriptor class?  I
think the answer is "no" to both, as the check it performs is
"t2.__class__ is not t.__class__".  I assert though that in general
the type of a descriptor (that is not a simple class attribute) is not
as important in duck testing as its API -- and all descriptors have
basically the same API of __get__, __set__, and __delete__.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Right solution to unicode error?

[Ian Kelly]

On Thu, Nov 8, 2012 at 11:32 AM, Oscar Benjamin
 wrote:
> If I want the other characters to work I need to change the code page:
>
> O:\>chcp 65001
> Active code page: 65001
>
> O:\>Q:\tools\Python33\python -c "import sys;
> sys.stdout.buffer.write('\u03b1\n'.encode('utf-8'))"
> α
>
> O:\>Q:\tools\Python33\python -c "import sys;
> sys.stdout.buffer.write('\u03b1\n'.encode(sys.stdout.en
> coding))"
> α

I find that I also need to change the font.  With the default font,
printing '\u2013' gives me:

–

The only alternative font option I have in Windows XP is Lucida
Console, which at least works correctly, although it seems to be
lacking a lot of glyphs.
-- 
http://mail.python.org/mailman/listinfo/python-list

RE: duck typing assert

[Andriy Kornatskyy]

Ian,

Thank you for the comments.

There is definitely a room for improvement, however there are limits. One of 
them is related to decorator that replaces decorated method arguments with 
something like *args, **kwargs. Here is an example.

def x():
    def decorate(m):
    def x(*args, **kwargs):
    pass
    return x
    return decorate

class Foo(object):

    @x
    def bar(self, a):
    pass

Another one challenge is related to inheritance, or even more complex case: 
multiple inheritance. I do not believe there is a need to scan whole hierarchy, 
better apply checks separately, the assert will be more readable.

class IFoo(object):
    def foo(self):
    pass

class IBar(IFoo):
    def bar(self):
    pass

class Bar(IBar):
    def foo(self):
    pass

    def bar(self):
    pass

assert looks(Bar).like(IBar)
assert looks(Bar).like(IFoo)


I agree, special methods __?__ should not be considered private... but what is 
right: know which one are special (how about some custom? e.g. __ctx__) or 
enforce check for it by explicitly asking for such check?

# 1
assert looks(Foo).like(IFoo, notice=['__len__'])
# 2
assert looks(Foo, notice=['__len__']).like(IFoo)

I believe if IFoo.foo is decorated as property, it must remain property, 
otherwise you need exclude it from checks, thus this way you pay code reviewer 
attention to that.

Thanks.

Andriy Kornatskyy



> From: ian.g.ke...@gmail.com
> Date: Thu, 8 Nov 2012 11:34:45 -0700
> Subject: Re: duck typing assert
> To: python-list@python.org
>
> On Thu, Nov 8, 2012 at 10:30 AM, Andriy Kornatskyy
>  wrote:
> >
> > People who come from strongly typed languages that offer interfaces often 
> > are confused by lack of one in Python. Python, being dynamic typing 
> > programming language, follows duck typing principal. It can as simple as 
> > this:
> >
> > assert looks(Foo).like(IFoo)
> >
> > The post below shows how programmer can assert duck typing between two 
> > Python classes:
> >
> > mindref.blogspot.com/2012/11/python-duck-typing-assert.html
> >
> > Comments or suggestions are welcome.
>
> Overall, it looks potentially useful to me. Looking over the
> wheezy.core.introspection source, it appears to ignore special method
> names. For example, if you do:
>
> class IFoo(object):
> def __len__(self):
> pass
>
> class Foo(object):
> pass
>
> assert looks(Foo).like(IFoo)
>
> I would expect this to fail, but judging from the code it would not,
> as it ignores all names starting with '_'. That makes some sense for
> private names (but on the other hand, why would you declare private
> names in an interface unless you want to enforce their presence?), but
> names like __len__ should not be considered private.
>
> Another comment I have is on properties, and descriptors in general.
> Does this allow something declared as a property to be implemented as
> a simple class attribute, and vice versa? Or can something declared
> as a property be implemented with some custom descriptor class? I
> think the answer is "no" to both, as the check it performs is
> "t2.__class__ is not t.__class__". I assert though that in general
> the type of a descriptor (that is not a simple class attribute) is not
> as important in duck testing as its API -- and all descriptors have
> basically the same API of __get__, __set__, and __delete__.
> --
> http://mail.python.org/mailman/listinfo/python-list
  
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Right solution to unicode error?

[wxjmfauth]

Le jeudi 8 novembre 2012 19:32:14 UTC+1, Oscar Benjamin a écrit :
> On 8 November 2012 15:05,   wrote:
> 
> > Le jeudi 8 novembre 2012 15:07:23 UTC+1, Oscar Benjamin a écrit :
> 
> >> On 8 November 2012 00:44, Oscar Benjamin  
> >> wrote:
> 
> >> > On 7 November 2012 23:51, Andrew Berg  wrote:
> 
> >> >> On 2012.11.07 17:27, Oscar Benjamin wrote:
> 
> >>
> 
> >> >>> Are you using cmd.exe (standard Windows terminal)? If so, it does not
> 
> >> >>> support unicode
> 
> >>
> 
> >> >> Actually, it does. Code page 65001 is UTF-8. I know that doesn't help
> 
> >> >> the OP since Python versions below 3.3 don't support cp65001, but I
> 
> >> >> think it's important to point out that the Windows command line system
> 
> >> >> (it is not unique to cmd) does in fact support Unicode.
> 
> >>
> 
> >> > I have tried to use code page 65001 and it didn't work for me even if
> 
> >> > I did use a version of Python (possibly 3.3 alpha) that claimed to
> 
> >> > support it.
> 
> >>
> 
> >> I stand corrected. I've just checked and codepage 65001 does work in
> 
> >> cmd.exe (on this machine):
> 
> >>
> 
> >> O:\>chcp 65001
> 
> >> Active code page: 65001
> 
> >>
> 
> >> O:\>Q:\tools\Python33\python -c print('abc\u2013def')
> 
> >> abc-def
> 
> >>
> 
> >> O:\>Q:\tools\Python33\python -c print('\u03b1')
> 
> >> α
> 
> >>
> 
> >> It would be a lot better though if it just worked straight away
> 
> >> without me needing to set the code page (like the terminal in every
> 
> >> other OS I use).
> 
> >
> 
> > It *WORKS* straight away. The problem is that
> 
> > people do not wish to use unicode correctly
> 
> > (eg. Mulder's example).
> 
> > Read the point 1) and 4) in my previous post.
> 
> >
> 
> > Unicode and in general the coding of the characters
> 
> > have nothing to do with the os's or programming languages.
> 
> 
> 
> I don't know what you mean that it works "straight away".
> 
> 
> 
> The default code page on my machine is cp850.
> 
> 
> 
> O:\>chcp
> 
> Active code page: 850
> 
> 
> 
> cp850 doesn't understand utf-8. It just prints garbage:
> 
> 
> 
> O:\>Q:\tools\Python33\python -c "import sys;
> 
> sys.stdout.buffer.write('\u03b1\n'.encode('utf-8'))"
> 
> ╬▒
> 
> 
> 
> Using the correct encoding doesn't help:
> 
> 
> 
> O:\>Q:\tools\Python33\python -c "import sys;
> 
> sys.stdout.buffer.write('\u03b1\n'.encode('cp850'))"
> 
> Traceback (most recent call last):
> 
>   File "", line 1, in 
> 
>   File "Q:\tools\Python33\lib\encodings\cp850.py", line 12, in encode
> 
> return codecs.charmap_encode(input,errors,encoding_map)
> 
> UnicodeEncodeError: 'charmap' codec can't encode character '\u03b1' in
> 
> position 0: character maps to
> 
>  
> 
> 
> 
> O:\>Q:\tools\Python33\python -c "import sys;
> 
> sys.stdout.buffer.write('\u03b1\n'.encode(sys.stdout.en
> 
> coding))"
> 
> Traceback (most recent call last):
> 
>   File "", line 1, in 
> 
>   File "Q:\tools\Python33\lib\encodings\cp850.py", line 12, in encode
> 
> return codecs.charmap_encode(input,errors,encoding_map)
> 
> UnicodeEncodeError: 'charmap' codec can't encode character '\u03b1' in
> 
> position 0: character maps to
> 
>  
> 
> 
> 
> If I want the other characters to work I need to change the code page:
> 
> 
> 
> O:\>chcp 65001
> 
> Active code page: 65001
> 
> 
> 
> O:\>Q:\tools\Python33\python -c "import sys;
> 
> sys.stdout.buffer.write('\u03b1\n'.encode('utf-8'))"
> 
> α
> 
> 
> 
> O:\>Q:\tools\Python33\python -c "import sys;
> 
> sys.stdout.buffer.write('\u03b1\n'.encode(sys.stdout.en
> 
> coding))"
> 
> α
> 
> 
> 
> 
> 
> Oscar

You are confusing two things. The coding of the
characters and the set of the characters (glyphes/graphemes)
of a coding scheme.

It is always possible to encode safely an unicode, but
the target coding may not contain the character.

Take a look at the output of this "special" interactive
interpreter" where the host coding (sys.stdout.encoding)
can be change on the fly.


>>> s = 'éléphant\u2013abc需'
>>> sys.stdout.encoding
''
>>> s
'éléphant–abc需'
>>> 
>>> sys.stdout.encoding = 'cp1252'
>>> s.encode('cp1252')
'éléphant–abc需'
>>> sys.stdout.encoding = 'cp850'
>>> s.encode('cp850')
Traceback (most recent call last):
  File "", line 1, in 
  File "C:\Python32\lib\encodings\cp850.py", line 12, in encode
return codecs.charmap_encode(input,errors,encoding_map)
UnicodeEncodeError: 'charmap' codec can't encode character '\u2013'
in position 8: character maps to 
>>> # but
>>> s.encode('cp850', 'replace')
'éléphant?abcé??'
>>> 
>>> sys.stdout.encoding = 'utf-8'
>>> s
'éléphant–abc需'
>>> s.encode('utf-8')
'éléphant–abc需'
>>> 
>>> sys.stdout.encoding = 'utf-16-le'  <
>>> s
' é l é p h a n t  a b c é S ¬ '
>>> s.encode('utf-16-le')
'éléphant–abc需'

<<< some cheating here do to the mail system, it really looks like this.

jmf


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

Re: Right solution to unicode error?

[wxjmfauth]

Le jeudi 8 novembre 2012 19:49:24 UTC+1, Ian a écrit :
> On Thu, Nov 8, 2012 at 11:32 AM, Oscar Benjamin
> 
>  wrote:
> 
> > If I want the other characters to work I need to change the code page:
> 
> >
> 
> > O:\>chcp 65001
> 
> > Active code page: 65001
> 
> >
> 
> > O:\>Q:\tools\Python33\python -c "import sys;
> 
> > sys.stdout.buffer.write('\u03b1\n'.encode('utf-8'))"
> 
> > α
> 
> >
> 
> > O:\>Q:\tools\Python33\python -c "import sys;
> 
> > sys.stdout.buffer.write('\u03b1\n'.encode(sys.stdout.en
> 
> > coding))"
> 
> > α
> 
> 
> 
> I find that I also need to change the font.  With the default font,
> 
> printing '\u2013' gives me:
> 
> 
> 
> –
> 
> 
> 
> The only alternative font option I have in Windows XP is Lucida
> 
> Console, which at least works correctly, although it seems to be
> 
> lacking a lot of glyphs.



Font has nothing to do here.
You are "simply" wrongly encoding your "unicode".

>>> '\u2013'
'–'
>>> '\u2013'.encode('utf-8')
b'\xe2\x80\x93'
>>> '\u2013'.encode('utf-8').decode('cp1252')
'–'

jmf

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

Re: int.__init__ incompatible in Python 3.3

[Terry Reedy]

On 11/8/2012 12:13 PM, Ian Kelly wrote:

On Thu, Nov 8, 2012 at 8:55 AM, Ulrich Eckhardt
 wrote:



Preparing for an upgrade from 2.7 to 3, I stumbled across an incompatibility
between 2.7 and 3.2 on one hand and 3.3 on the other:

class X(int):
 def __init__(self, value):
 super(X, self).__init__(value)


This is a bug. Subclasses of immutables should not define __init__.
>>> int.__init__ is object.__init__
True

object.__init__(self) is a dummy placeholder function that takes no args 
and does nothing.



X(42)

On 2.7 and 3.2, the above code works.


That is a bug. It is documented that calling with the wrong number of 
args is an error.



On 3.3, it gives me a "TypeError: object.__init__() takes no parameters".

>> To some extent, this makes sense to

me, because the int subobject is not initialized in __init__ but in __new__.
As a workaround, I can simple drop the parameter from the call.


Just drop the do-nothing call.


breaking backward compatibility is another issue, so I wonder if that should
be considered as a bug.


Every bug fix breaks backward compatibility with code that depends on 
the bug. Such breakage is not a bug, but, as in this case, some fixes 
are not put in bugfix releases because of such breakage.



Bug? Feature? Other suggestions?


Intentional bugfix.
http://bugs.python.org/issue1683368
There was additional discussion on pydev or python-ideas lists before 
the final commit. This fix was not back-ported to 2.7 or 3.2.



A similar change was made to object.__init__ in 2.6, so this could
just be bringing the behavior of int into line with object.  There's
nothing about it in the whatsnew document, though.


What's New is a summary of *new* features. It does not list bug fixes. 
At the top it says " For full details, see the Misc/NEWS file." The last 
patch on the issue added this entry.

'''
Core and Builtins
-

- Issue #1683368: object.__new__ and object.__init__ raise a TypeError
if they are passed arguments and their complementary method is not 
overridden.

'''


I say open a bug report and let the devs sort it out.


Please do not. The current situation is the result of 'sorting it out' 
over several years.



--
Terry Jan Reedy

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

Re: duck typing assert‏

[Terry Reedy]

On 11/8/2012 12:34 PM, Andriy Kornatskyy wrote:


People who come from strongly typed languages that offer interfaces
often are confused by lack of one in Python. Python, being dynamic
typing programming language, follows duck typing principal. It can as
simple as this:

assert looks(Foo).like(IFoo)

The post below shows how programmer can assert duck typing between
two Python classes:

http://mindref.blogspot.com/2012/11/python-duck-typing-assert.html

Comments or suggestions are welcome.


From the post:
'''
So far so good. Let fix it and take a look at properties:

from wheezy.core.introspection import looks

class IFoo(object):

def foo(self, a, b=None):
pass

@property
def bar(self):
pass


class Foo(object):

def foo(self, a, b=None):
pass

def bar(self):
pass

assert looks(Foo).like(IFoo)

Here is output:

test.py:21: UserWarning: 'bar': is not property.
  assert looks(Foo).like(IFoo)
Traceback (most recent call last):
  File "test.py", line 21, in
assert looks(Foo).like(IFoo)
AssertionError
'''

I view this check as an error. Properties are intended to be transparent 
to the user. One use of properties is to make something that is not a 
Mallard act like a Mallard. So this check breaks duck typing.


--
Terry Jan Reedy

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

Re: Right solution to unicode error?

[Ian Kelly]

On Thu, Nov 8, 2012 at 12:54 PM,   wrote:
> Font has nothing to do here.
> You are "simply" wrongly encoding your "unicode".
>
 '\u2013'
> '–'
 '\u2013'.encode('utf-8')
> b'\xe2\x80\x93'
 '\u2013'.encode('utf-8').decode('cp1252')
> '–'

No, it seriously is the font.  This is what I get using the default
("Raster") font:

C:\>chcp 65001
Active code page: 65001

C:\>c:\python33\python
Python 3.3.0 (v3.3.0:bd8afb90ebf2, Sep 29 2012, 10:55:48) [MSC v.1600
32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> '\u2013'
'–'
>>> import sys
>>> sys.stdout.buffer.write('\u2013\n'.encode('utf-8'))
–
4

I should note here that the characters copied and pasted do not
correspond to the glyphs actually displayed in my terminal window.  In
the terminal window I actually see:

ΓÇô

If I change the font to Lucida Console and run the *exact same code*,
I get this:

C:\>chcp 65001
Active code page: 65001

C:\>c:\python33\python
Python 3.3.0 (v3.3.0:bd8afb90ebf2, Sep 29 2012, 10:55:48) [MSC v.1600
32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> '\u2013'
'–'

>>> import sys
>>> sys.stdout.buffer.write('\u2013\n'.encode('utf-8'))
–
4

Why is the font important?  I have no idea.  Blame Microsoft.
-- 
http://mail.python.org/mailman/listinfo/python-list

RE: Right solution to unicode error?

[Prasad, Ramit]

wxjmfa...@gmail.com wrote:
> 
> Le jeudi 8 novembre 2012 19:49:24 UTC+1, Ian a écrit :
> > On Thu, Nov 8, 2012 at 11:32 AM, Oscar Benjamin
> >
> >  wrote:
> >
> > > If I want the other characters to work I need to change the code page:
> > >
> > > O:\>chcp 65001
> > > Active code page: 65001
> > >
> > > O:\>Q:\tools\Python33\python -c "import sys;
> > > sys.stdout.buffer.write('\u03b1\n'.encode('utf-8'))"
> > > α
> > >
> > > O:\>Q:\tools\Python33\python -c "import sys;
> > > sys.stdout.buffer.write('\u03b1\n'.encode(sys.stdout.en
> > > coding))"
> > > α
> >
> > I find that I also need to change the font.  With the default font,
> >
> > printing '\u2013' gives me:
> > –
> >
> > The only alternative font option I have in Windows XP is Lucida
> > Console, which at least works correctly, although it seems to be
> > lacking a lot of glyphs.
> 
> 
> 
> Font has nothing to do here.
> You are "simply" wrongly encoding your "unicode".
> 


Why would font not matter? Unicode is the abstract definition 
of all characters right? From that we map the abstract 
character to a code page/set, which gives real values for an
abstract character. From that code page we then visually display 
the "real value" based on the font. If that font does
not have a glyph for a specific character page (or a different
glyph) then that is a problem and not related encoding. 

Unicode->code page->font


> >>> '\u2013'
> '–'
> >>> '\u2013'.encode('utf-8')
> b'\xe2\x80\x93'
> >>> '\u2013'.encode('utf-8').decode('cp1252')
> '–'
> 

This is a mismatched translation between code pages; not
font related but is instead one abstraction "level" up. 


This email is confidential and subject to important disclaimers and
conditions including on offers for the purchase or sale of
securities, accuracy and completeness of information, viruses,
confidentiality, legal privilege, and legal entity disclaimers,
available at http://www.jpmorgan.com/pages/disclosures/email.  
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Right solution to unicode error?

[Ian Kelly]

On Thu, Nov 8, 2012 at 1:54 PM, Prasad, Ramit  wrote:
> Why would font not matter? Unicode is the abstract definition
> of all characters right? From that we map the abstract
> character to a code page/set, which gives real values for an
> abstract character. From that code page we then visually display
> the "real value" based on the font. If that font does
> not have a glyph for a specific character page (or a different
> glyph) then that is a problem and not related encoding.

Usually though when the font is missing a glyph for a Unicode
character, you just get a missing glyph symbol, such as an empty
rectangle.  For some reason when using the default font, cmd seemingly
ignores the active code page, skips decoding the characters, and tries
to print the individual bytes as if using code page 437.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Right solution to unicode error?

[Oscar Benjamin]

On 8 November 2012 19:54,   wrote:
> Le jeudi 8 novembre 2012 19:49:24 UTC+1, Ian a écrit :
>> On Thu, Nov 8, 2012 at 11:32 AM, Oscar Benjamin
>>
>>  wrote:
>>
>> > If I want the other characters to work I need to change the code page:
>>
>> >
>>
>> > O:\>chcp 65001
>>
>> > Active code page: 65001
>>
>> >
>>
>> > O:\>Q:\tools\Python33\python -c "import sys;
>>
>> I find that I also need to change the font.  With the default font,
>>
>> printing '\u2013' gives me:
>>
>> –
>>
>>
>>
>> The only alternative font option I have in Windows XP is Lucida
>>
>> Console, which at least works correctly, although it seems to be
>>
>> lacking a lot of glyphs.
>
> Font has nothing to do here.
> You are "simply" wrongly encoding your "unicode".
>
 '\u2013'
> '–'
 '\u2013'.encode('utf-8')
> b'\xe2\x80\x93'
 '\u2013'.encode('utf-8').decode('cp1252')
> '–'

You have correctly identified that the displayed characters are the
result of accidentally interpreting utf-8 bytes as if they were cp1252
or similar. However, it is not Ian or Python that is confusing the
encoding. It is cmd.exe that is confusing the encoding in a
font-dependent way. I also had to change the font as Ian describes
though I did it some time ago and forgot to mention it here.

jmf, can you please trim the text you quote removing the parts you are
not responding to and then any remaining blank lines that were
inserted by your reader/editor?


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

How to print python commands automatically?

[Peng Yu]

Hi,

In bash, set -v will print the command executed. For example, the
following screen output shows that the "echo" command is printed
automatically. Is there a similar thing in python?

~/linux/test/bash/man/builtin/set/-v$ cat main.sh
#!/usr/bin/env bash

set -v
echo "Hello World!"
~/linux/test/bash/man/builtin/set/-v$ ./main.sh
echo "Hello World!"
Hello World!



Regards,
Peng
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Multi-dimensional list initialization

[88888 Dihedral]

On Monday, November 5, 2012 3:07:12 PM UTC+8, Chris Rebert wrote:
> On Sun, Nov 4, 2012 at 10:27 PM, Demian Brecht  wrote:
> 
> > So, here I was thinking "oh, this is a nice, easy way to initialize a 4D 
> > matrix" (running 2.7.3, non-core libs not allowed):
> 
> >
> 
> > m = [[None] * 4] * 4
This is not clear in a name binding objective 
programming language.

b=[1,2,3,4]*4
mb=[ b]*4 

# check the behaviors  and usages of reference copies 
# and shadow value copies and deep-value copies





> 
> >
> 
> > The way to get what I was after was:
> 
> >
> 
> > m = [[None] * 4, [None] * 4, [None] * 4, [None * 4]]
> 
> >
> 
> > (Obviously, I could have just hardcoded the initialization, but I'm too 
> > lazy to type all that out ;))
> 
> >
> 
> > The behaviour I encountered seems a little contradictory to me.
> 
> > [None] * 4 creates four distinct elements in a single array
> 
> > while [[None] * 4] * 4 creates one distinct array of four distinct 
> > elements, with three references to it:
> 
> 
> 
> Incorrect. In /both/ cases, the result is a list of length 4, whose
> 
> elements are 4 (references to) the exact same object as the original
> 
> list's element.
> 
> Put simply, the list multiplication operator never copies objects; it
> 
> just makes additional references to them.
> 
> 
> 
> However, unlike a list object (as in your latter example), the object
> 
> `None` is completely immutable (and what's more, a singleton value),
> 
> so you just-so-happen *not to be able to* run into the same problem of
> 
> mutating an object (assignment to an index of a list constitutes
> 
> mutation of that list) that is referenced in multiple places, for you
> 
> cannot mutate None in the first place!:
> 
> >>> x = None
> 
> >>> x.a = 42
> 
> Traceback (most recent call last):
> 
>   File "", line 1, in 
> 
> AttributeError: 'NoneType' object has no attribute 'a'
> 
> >>> # it doesn't overload any mutating operators:
> 
> >>> type(None).__dict__.keys()
> 
> ['__hash__', '__repr__', '__doc__']
> 
> >>> # and it obviously has no instance variables,
> 
> >>> # so, we can't modify it in any way whatsoever!
> 
> (Lists, on the other hand, define item assignment, .pop(), .remove(),
> 
> and a few other mutator methods.)
> 
> 
> 
>  a = [None] * 4
> 
>  a[0] = 'a'
> 
>  a
> 
> > ['a', None, None, None]
> 
> >
> 
>  m = [[None] * 4] * 4
> 
>  m[0][0] = 'm'
> 
>  m
> 
> > [['m', None, None, None], ['m', None, None, None], ['m', None, None, None], 
> > ['m', None, None, None]]
> 
> >
> 
> > Is this expected behavior
> 
> 
> 
> Yes. It's also a FAQ:
> 
> http://docs.python.org/2/faq/programming.html#how-do-i-create-a-multidimensional-list
> 
> 
> 
> > and if so, why?
> 
> 
> 
> It's a general (albeit AFAIK unstated) principle that Python never
> 
> copies objects unless you explicitly ask it to. You have encountered
> 
> one example of this rule in action.
> 
> 
> 
> > In my mind either result makes sense, but the inconsistency is what throws 
> > me off.
> 
> 
> 
> It is perfectly consistent, once you understand what list
> 
> multiplication actually does.
> 
> 
> 
> Cheers,
> 
> Chris
> 
> --
> 
> http://rebertia.com

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

Re: duck typing assert‏

[Steven D'Aprano]

On Thu, 08 Nov 2012 20:34:58 +0300, Andriy Kornatskyy wrote:

> People who come from strongly typed languages that offer interfaces
> often are confused by lack of one in Python. Python, being dynamic
> typing programming language, follows duck typing principal. It can as
> simple as this:
>  
> assert looks(Foo).like(IFoo)

How very cute. And I don't mean that in a good way.

Why is this a class with a method, instead of a function that takes two 
class arguments (plus any optional arguments needed)?

looks_like(Foo, IFoo)

is less "cute", reads better to English speakers, and much more Pythonic. 
This isn't Java, not everything needs to be a class.


> The post below shows how programmer can assert duck typing between two
> Python classes:
>  
> http://mindref.blogspot.com/2012/11/python-duck-typing-assert.html

I don't understand the emphasis on assert for this code. It is enough 
that looks() return a flag. The caller can then use that as an assertion:

assert looks(Spam).like(Ham)

or as a conditional:

if looks(food).like(Meat):
...
else:
...


Assertions are only one use for this check, and in my opinion, the least 
useful one.

And why the warnings? In my opinion, using the warning mechanism as a way 
to communicate the differences between the classes is an abuse of 
warnings: they're not *warnings*, they are *diagnostic information*.

It is also fragile: the caller may have filtered warnings, and will not 
see the messages you generate.

Lastly, I do not understand the purpose of this "wheezy.core" package. 
Does it have something to do with Ubuntu Wheezy? The documentation is 
unclear -- it refers to it as a "Python package" that "provides core 
features", but doesn't say what the purpose of the package is: core 
features of *what*? And the examples.rst file doesn't show any examples.

https://bitbucket.org/akorn/wheezy.core/src/ca5b902e9605/doc/examples.rst


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

Re: duck typing assert‏

[Steven D'Aprano]

On Thu, 08 Nov 2012 15:39:24 -0500, Terry Reedy wrote:

[...]
> test.py:21: UserWarning: 'bar': is not property.
>assert looks(Foo).like(IFoo)
> Traceback (most recent call last):
>File "test.py", line 21, in
>  assert looks(Foo).like(IFoo)
> AssertionError
> '''
> 
> I view this check as an error. Properties are intended to be transparent
> to the user. One use of properties is to make something that is not a
> Mallard act like a Mallard. So this check breaks duck typing.

Properties and methods do not have the same interface:

IFoo.bar  # returns a computed property
Foo.bar()  # calls a method

Since the interfaces are different, duck-typing will fail. It will 
actually fail in a potentially nasty way:

x = Foo.bar  # doesn't raise an exception, gives the method object
# ... much later
do_something_with(x)  # blows up potentially far, far away




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

Re: duck typing assert

[Ian Kelly]

On Thu, Nov 8, 2012 at 4:33 PM, Steven D'Aprano
 wrote:
> On Thu, 08 Nov 2012 20:34:58 +0300, Andriy Kornatskyy wrote:
>
>> People who come from strongly typed languages that offer interfaces
>> often are confused by lack of one in Python. Python, being dynamic
>> typing programming language, follows duck typing principal. It can as
>> simple as this:
>>
>> assert looks(Foo).like(IFoo)
>
> How very cute. And I don't mean that in a good way.
>
> Why is this a class with a method, instead of a function that takes two
> class arguments (plus any optional arguments needed)?
>
> looks_like(Foo, IFoo)
>
> is less "cute", reads better to English speakers, and much more Pythonic.
> This isn't Java, not everything needs to be a class.

I disagree.  Does that test whether Foo looks like IFoo, or IFoo looks
like Foo?  Of course, given the naming convention and the example,
it's easy to work out, but when you're trying to *write* that from
memory, it could be a nuisance to remember the proper order.  This is
already a wart of isinstance and issubclass.

looks(Foo).like(IFoo), on the other hand, is crystal clear about which
argument is which.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: how to simulate tar filename substitution across piped subprocess.Popen() calls?

[Hans Mulder]

On 8/11/12 19:05:11, jkn wrote:
> Hi All
> i am trying to build up a set of subprocess.Ponen calls to
> replicate the effect of a horribly long shell command. I'm not clear
> how I can do one part of this and wonder if anyone can advise. I'm on
> Linux, fairly obviously.
> 
> I have a command which (simplified) is a tar -c command piped through
> to xargs:
> 
> tar  -czvf myfile.tgz -c $MYDIR mysubdir/ | xargs -I '{}' sh -c "test -
> f $MYDIR/'{}'"
> 
> (The full command is more complicated than this; I got it from a shell
> guru).
> 
> IIUC, when called like this, the two occurences of '{}' in the xargs
> command will get replaced with the file being added to the tarfile.
> 
> Also IIUC, I will need two calls to subprocess.Popen() and use
> subprocess.stdin on the second to receive the output from the first.
> But how can I achive the substitution of the '{}' construction across
> these two calls?

That's what 'xargs' will do for you.  All you need to do, is invoke
xargs with arguments containing '{}'.  I.e., something like:

cmd1 = ['tar', '-czvf', 'myfile.tgz', '-c', mydir, 'mysubdir']
first_process = subprocess.Popen(cmd1, stdout=subprocess.PIPE)

cmd2 = ['xargs', '-I', '{}', 'sh', '-c', "test -f %s/'{}'" % mydir]
second_process = subprocess.Popen(cmd2, stdin=first_process.stdout)

> Apologies if I've made any howlers in this description - it's very
> likely...

I think the second '-c' argument to tar should have been a '-C'.

I'm not sure I understand what the second command is trying to
achieve.  On my system, nothing happens, because tar writes the
names of the files it is adding to stderr, so xargs receives no
input at all.  If I send the stderr from tar to the stdin of
xargs, then it still doesn't seem to do anything sensible.

Perhaps your real xargs command is more complicated and more
sensible.



Hope this helps,

-- HansM

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

Re: Multi-dimensional list initialization

[Mark Lawrence]

On 07/11/2012 01:55, Steven D'Aprano wrote:


Who knows? Who cares? Nobody does:

n -= n



But I've seen this scattered through code:

x := x - x - x

--
Cheers.

Mark Lawrence.

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

Re: How to print python commands automatically?

[rusi]

On Nov 9, 4:12 am, Peng Yu  wrote:
> Hi,
>
> In bash, set -v will print the command executed. For example, the
> following screen output shows that the "echo" command is printed
> automatically. Is there a similar thing in python?
>
> ~/linux/test/bash/man/builtin/set/-v$ cat main.sh
> #!/usr/bin/env bash
>
> set -v
> echo "Hello World!"
> ~/linux/test/bash/man/builtin/set/-v$ ./main.sh
> echo "Hello World!"
> Hello World!
>
> Regards,
> Peng

Is this what you want?
http://docs.python.org/2/library/trace.html
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Right solution to unicode error?

[Andrew Berg]

On 2012.11.08 08:06, Oscar Benjamin wrote:
> It would be a lot better though if it just worked straight away
> without me needing to set the code page (like the terminal in every
> other OS I use).
The crude equivalent of .bashrc/.zshrc/whatever shell startup script for
cmd is setting a string value (REG_SZ) in
HKCU\Software\Microsoft\Command Processor named autorun and setting that
with whatever command(s) you want to run whenever the shell starts. Mine
has a value of '@chcp 65001>nul'. I actually run zsh when practical
(gotta love Cygwin) and I have an equivalent command in my .zshrc.
Getting unicode to work in a Windows is a hassle, but it /can/ work.
CPython does have a bug that makes it annoying at times, though -
http://bugs.python.org/issue1602
-- 
CPython 3.3.0 | Windows NT 6.1.7601.17835
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: duck typing assert‏

[Terry Reedy]

On 11/8/2012 6:40 PM, Steven D'Aprano wrote:

On Thu, 08 Nov 2012 15:39:24 -0500, Terry Reedy wrote:

[...]

test.py:21: UserWarning: 'bar': is not property.
assert looks(Foo).like(IFoo)
Traceback (most recent call last):
File "test.py", line 21, in
  assert looks(Foo).like(IFoo)
AssertionError
'''

I view this check as an error. Properties are intended to be transparent
to the user. One use of properties is to make something that is not a
Mallard act like a Mallard. So this check breaks duck typing.


Properties and methods do not have the same interface:


Of course not, properties mimic instance attributes, accessed via the 
instance, not calls of methods. I believe the attributes are most often 
used to micic data attributes. The classical example is giving x,y 
properties to points with r,theta attributes so that they look like and 
can be substituted for points with actual x,y attributes. This is the 
kind of duck typing I was referring to, and it would be broken by the 
property check.


But if an instance method is being mimicked, so that inst.meth is a 
bound instance method when meth is an instance method attribute of the 
class of inst, then meth.get(inst) of a meth property must also return a 
bound instance method. (I am not exactly sure when one would want to do 
this, but since you brought up methods in relation to properties ...)


from types import MethodType as bm

class C:
def __init__(self, x = 0):
self.x = x
def double(self):
return 2 * self.x

class Cp:
def __init__(self, x = 0):
self.x = x
@property
def double(self):
return bm(lambda self: 2 * self.x, self)

c, cp = C(3), Cp(3)

print(c.double, cp.double, c.double(), cp.double(), sep = '\n')
#
>
 of <__main__.Cp object at 0x03455A58>>
6
6


IFoo.bar  # returns a computed property


Assuming IFoo is a class and bar is a property attribute of the class, 
IFoo.bar is the property object itself, not the computed property of an 
instance.



Foo.bar()  # calls a method


Assuming Foo is a class, this only works if bar is a class method, 
static method, or pre-bound instance method (as returned by 
types.MethodType).


If bar is a function intended to be a regular instance method, it has to 
be called on the instance or given an instance as an arguement.


> Since the interfaces are different, duck-typing will fail. It will
> actually fail in a potentially nasty way:

I don't understand what you mean, assuming that the property is used as 
intended.


> x = Foo.bar  # doesn't raise an exception,

why should it?

> gives the method object

if bar is a method (function), of course, just as IFoo.bar gives the 
property object.


> # ... much later
> do_something_with(x)  # blows up potentially far, far away

Transparency applies to immediate access via an instance. If you extract 
different machinery from behind two class curtains and save them for 
later use, then they are different. So what? This is not an issue for 
instance data attributes. Instance methods of classes are intended to be 
accessed via an instance, at which point the result is a bound method 
that can be called either immediately or later (possible many times).

--
Terry Jan Reedy

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

Re: Multi-dimensional list initialization

[Chris Angelico]

On Fri, Nov 9, 2012 at 12:39 PM, Mark Lawrence  wrote:
> On 07/11/2012 01:55, Steven D'Aprano wrote:
>>
>>
>> Who knows? Who cares? Nobody does:
>>
>> n -= n
>>
>
> But I've seen this scattered through code:
>
> x := x - x - x

Can you enlighten us as to how this is better than either:
 x := -x
or
 x := 0 - x
? I'm not seeing it. And I'm not seeing any nonnumeric that would
benefit from being subtracted from itself twice (strings, arrays,
sets, you can subtract them from one another but not usefully more
than once).

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

Re: duck typing assert

[Chris Angelico]

On Fri, Nov 9, 2012 at 12:00 PM, Ian Kelly  wrote:
> looks(Foo).like(IFoo), on the other hand, is crystal clear about which
> argument is which.

I'm not so sure that it is, tbh. If you read it like an English
sentence, it's clearly testing whether Foo matches the template in
IFoo, but which are you more likely to do: test one class to see if it
satisfies lots of templates, or test one template against every class
you meet? I think probably the latter is, if not more likely than the
former, at least sufficiently plausible as to create confusion. It
makes very good sense to say:

duckmatch(IFoo).compare(Foo)

ie with the arguments the other way.

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

Re: duck typing assert‏

[Steven D'Aprano]

On Thu, 08 Nov 2012 23:44:54 -0500, Terry Reedy wrote:

> On 11/8/2012 6:40 PM, Steven D'Aprano wrote:
[...]
>> IFoo.bar  # returns a computed property
> 
> Assuming IFoo is a class and bar is a property attribute of the class,
> IFoo.bar is the property object itself, not the computed property of an
> instance.

Given the context we were discussing, namely duck-typing, the examples I 
gave should have been understood as indications, not literal code 
snippets. Yes, it is true that "IFoo.bar" returns a property object, and 
"Foo.bar" returns an unbound method (a function in Python 3). But they 
are meant as illustrations, not working code samples. Much the same way 
that we will often talk about "list.append" when what we actually mean is 
the bound append method on some specific, context-dependent list instance.

I am sorry that I did not make that clear and that my terminology was 
sloppy.

But in context, duck-typing classes normally is intended to substitute an 
instance of one class for an instance of another class. In that case, if 
IFoo.bar is a property, and Foo.bar is a method, then you cannot 
substitute an IFoo instance for a Foo instance, or vice versa:

ifoo = IFoo()
ifoo.bar  # returns a computed attribute

foo = Foo()
foo.bar()  # calls the method

In the general case, you cannot use ifoo.bar() where foo.bar() is 
expected, nor can you use foo.bar where ifoo.bar is expected. Just in 
case it isn't clear what I mean:

Suppose the expected interface is that instance.bar is a method that 
takes no arguments. foo.bar() matches that interface, because bar is a 
method. But ifoo.bar is a property. Suppose it computes an int result. 
Then ifoo.bar() will try to call an int, and raise TypeError. So ifoo 
cannot be used in place of foo, and types IFoo and Foo are not duck-type 
compatible. Likewise if the expected interface is for a property or 
attribute, such as ifoo.bar would give. Then foo.bar returns an unbound 
method. Instead of getting an error there and then, you might not get an 
error until much later, say:

integers = [1, 3, ifoo.bar, foo.bar, 42]
# much later
y = sum(integers)  # raises TypeError because foo.bar is a method


So, duck-typing classes IFoo (with bar a property) and Foo (with bar a 
method) will not in general work, and looks(IFoo).like(Foo) should return 
False.



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

Re: Multi-dimensional list initialization

[Steven D'Aprano]

On Fri, 09 Nov 2012 17:07:09 +1100, Chris Angelico wrote:

> On Fri, Nov 9, 2012 at 12:39 PM, Mark Lawrence 
> wrote:
>> On 07/11/2012 01:55, Steven D'Aprano wrote:
>>>
>>>
>>> Who knows? Who cares? Nobody does:
>>>
>>> n -= n
>>>
>>>
>> But I've seen this scattered through code:
>>
>> x := x - x - x
> 
> Can you enlighten us as to how this is better than either:
>  x := -x
> or
>  x := 0 - x
> ? I'm not seeing it. 

I'm hoping that Mark intended it as an example of crappy code he has 
spotted in some other language rather than a counter-example of something 
you would do.

To be pedantic... there may very well be some (rare) cases where you 
actually do want x -= x rather than just x = 0. Consider the case where x 
could be an INF or NAN. Then x -= x should give x = NAN rather than zero. 
That may be desirable in some cases.

At the very least, the compiler should NOT optimize away x = x - x to 
x = 0 if x could be a float, complex or Decimal.


> And I'm not seeing any nonnumeric that would
> benefit from being subtracted from itself twice (strings, arrays, sets,
> you can subtract them from one another but not usefully more than once).

How do you subtract strings?



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

Re: Multi-dimensional list initialization

[Chris Angelico]

On Fri, Nov 9, 2012 at 5:37 PM, Steven D'Aprano
 wrote:
> On Fri, 09 Nov 2012 17:07:09 +1100, Chris Angelico wrote:
>> Can you enlighten us as to how this is better than either:
>>  x := -x
>> or
>>  x := 0 - x
>> ? I'm not seeing it.
>
> I'm hoping that Mark intended it as an example of crappy code he has
> spotted in some other language rather than a counter-example of something
> you would do.

Ohh. Yeah, that figures. Huh.

> To be pedantic... there may very well be some (rare) cases where you
> actually do want x -= x rather than just x = 0. Consider the case where x
> could be an INF or NAN. Then x -= x should give x = NAN rather than zero.
> That may be desirable in some cases.
>
> At the very least, the compiler should NOT optimize away x = x - x to
> x = 0 if x could be a float, complex or Decimal.

Yep. In the specific case of integers, though, and in the specific
instance of CPU registers in assembly language, it's reasonable to
optimize it the *other* way - MOV reg,0 is a one-byte opcode and 1, 2,
or 4 bytes of immediate data, while SUB reg,reg (or XOR reg,reg) is a
two-byte operation regardless of data size. But that's
microoptimization that makes, uhh, itself-subtracted-from-itself sense
in Python.

>> And I'm not seeing any nonnumeric that would
>> benefit from being subtracted from itself twice (strings, arrays, sets,
>> you can subtract them from one another but not usefully more than once).
>
> How do you subtract strings?

The same way you subtract sets. Same with arrays. Python doesn't do
either, but Python also doesn't do the ":=" operator that the example
code demonstrated, so I didn't assume Python.

Pike v7.8 release 700 running Hilfe v3.5 (Incremental Pike Frontend)
> "Hello, world!"-"l";
(1) Result: "Heo, word!"
> ({1,2,3,3,2,3,1,2,1})-({2});
(2) Result: ({ /* 6 elements */
1,
3,
3,
3,
1,
1
})

Python spells it differently:
>>> "Hello, world!".replace("l","")
'Heo, word!'

Not sure how to do array subtraction other than with filter:
>>> list(filter(lambda x: x!=2,[1,2,3,3,2,3,1,2,1]))
[1, 3, 3, 3, 1, 1]
But there's probably a way (list.remove only takes out the first
occurrence, so it's not equivalent).

In any case, subtracting something from _itself_ is only going to give
you an empty string, array, set, or whatever, and doing so a second
time is going to achieve nothing. Hence my comment.

But poor code we will always have with us, to paraphrase the Gospel of Matthew.

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

Writing game-state data...

[Graham Fielding]

Hey, folks, me again! I've been puzzling over this for a while now: I'm trying 
to write data to a file to save the state of my game using the following 
function: def save_game():
#open a new empty shelve (possibly overwriting an old one) to write the 
game data
file_object = open('savegame.sav', 'wb')
file['map'] = map
file['objects'] = objects
file['player_index'] = objects.index(player)  #index of player in objects 
list
file['inventory'] = inventory
file['game_msgs'] = game_msgs
file['game_state'] = game_state
file['stairs_index'] = objects.index(stairs)
file['dungeon_level'] = dungeon_level
file.close() However, while 'savegame.sav' is created in the directory I 
specify, the function dies on file['map'] = map.  This is the end of the stack 
trace: 
  File "C:\Python Project\Roguelike.py", line 966, in save_game
file['map'] = map
TypeError: 'type' object does not support item assignment Now, the map is 
randomly generated -- could that be an issue? Should I just scrap the current 
system and use pickle?-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Multi-dimensional list initialization

[Mark Lawrence]

On 09/11/2012 06:37, Steven D'Aprano wrote:

On Fri, 09 Nov 2012 17:07:09 +1100, Chris Angelico wrote:


On Fri, Nov 9, 2012 at 12:39 PM, Mark Lawrence 
wrote:

On 07/11/2012 01:55, Steven D'Aprano wrote:



Who knows? Who cares? Nobody does:

n -= n



But I've seen this scattered through code:

x := x - x - x


Can you enlighten us as to how this is better than either:
  x := -x
or
  x := 0 - x
? I'm not seeing it.


I'm hoping that Mark intended it as an example of crappy code he has
spotted in some other language rather than a counter-example of something
you would do.


Correct, CORAL 66 and pointed out to me by a colleague when another team 
member had resigned.




To be pedantic... there may very well be some (rare) cases where you
actually do want x -= x rather than just x = 0. Consider the case where x
could be an INF or NAN. Then x -= x should give x = NAN rather than zero.
That may be desirable in some cases.


Interesting what comes up when we get chatting here.  I hope we don't 
get punished for going off topic :)




At the very least, the compiler should NOT optimize away x = x - x to
x = 0 if x could be a float, complex or Decimal.



X was an int so almost certainly optimised away by the SDL compiler on 
VMS of 1986 or 1987.


--
Cheers.

Mark Lawrence.

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

Re: Writing game-state data...

[Mark Lawrence]

On 09/11/2012 07:20, Graham Fielding wrote:


Hey, folks, me again! I've been puzzling over this for a while now: I'm trying 
to write data to a file to save the state of my game using the following 
function: def save_game():
 #open a new empty shelve (possibly overwriting an old one) to write the 
game data
 file_object = open('savegame.sav', 'wb')
 file['map'] = map
 file['objects'] = objects
 file['player_index'] = objects.index(player)  #index of player in objects 
list
 file['inventory'] = inventory
 file['game_msgs'] = game_msgs
 file['game_state'] = game_state
 file['stairs_index'] = objects.index(stairs)
 file['dungeon_level'] = dungeon_level
 file.close() However, while 'savegame.sav' is created in the directory I 
specify, the function dies on file['map'] = map.  This is the end of the stack 
trace:
   File "C:\Python Project\Roguelike.py", line 966, in save_game
 file['map'] = map
TypeError: 'type' object does not support item assignment Now, the map is 
randomly generated -- could that be an issue? Should I just scrap the current 
system and use pickle?  



Please always give the complete stack trace, it's provided for a 
purpose.  Here I'll grope around in the dark and guess that you need 
file_object = shelve.open(...


--
Cheers.

Mark Lawrence.

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