Re: scope of function parameters (take two)
On 2011-05-30, at 20:52 , Benjamin Kaplan wrote: > On Mon, May 30, 2011 at 5:28 PM, Henry Olders wrote: >> >> On 2011-05-29, at 4:30 , Henry Olders wrote: >> > > Python doesn't have true globals. When we say "global" what we mean is > "module or built-in". Also, consider this code > > from math import sin > def redundant_sin(x) : >return sin(x) > > In Python, everything is an object. That includes functions. By your > definition, that function would either have to be written as > def redundant_sin(sin, x) : > and you would have to pass the function in every time you wanted to > call it or have a "global sin" declaration in your function. And you > would need to do that for every single function that you call in your > function body. > I don't believe so. Within redundant_sin, x is local, so if I change x, it will not change any objects named x outside of the function. As far as sin is concerned, if it were passed to redundant_sin via the parameter list, then it would be local, but otherwise sin would be looked for in the function definition; if not found there, it would be looked for in the module, where it would be found. I am not suggesting any changes to how names are looked up or scoped. Henry -- http://mail.python.org/mailman/listinfo/python-list
Re: Something is rotten in Denmark...
On Mon, May 30, 2011 at 11:48 PM, harrismh777 wrote: fs=[] fs = [(lambda n: i + n) for i in range(10)] [fs[i](1) for i in range(10)] > > [10, 10, 10, 10, 10, 10, 10, 10, 10, 10] <=== not good > > ( that was a big surprise! . . . ) > lambda? closure? scope? bug? > > What is going on with the binding in the first construct... this seems > to reduce the usefulness of lambda to a considerable extent? http://stackoverflow.com/questions/233673/lexical-closures-in-python (See 1st and 2nd answers) Cheers, Chris -- http://mail.python.org/mailman/listinfo/python-list
Re: scope of function parameters (take two)
On 2011-05-31, at 24:35 , Dan Stromberg wrote: > > On Mon, May 30, 2011 at 5:28 PM, Henry Olders wrote: > > Be careful not to conflate global scoping or global lifetime, with mutability > or pure, side-effect-free functions (callables). It sounds like what you > want is immutability and/or freedom from side effects, which is found most > often in (pure) functional languages - which is not what Python is, nor does > it attempt to be so. I think you're right, I've been conflating scoping with side effects caused by passing mutable objects. > > In Python, and in many other languages, if you pass a scalar (or more > generally, an object of an immutable type) to a function, and then change the > scalar in that function, you only change the scalar within that function, not > within the caller. > > However, if you pass an aggregate type like a list (array) or dictionary > (hash table), then the formal argument itself that you've passed is still > only changeable within that function, however what it points off at _is_ > changeable via that formal argument. This is of course because otherwise > passing a 1 gigabyte dictionary to a function would either have to copy the > whole dictionary, or implement some sort of Copy-on-Write semantics, or make > it somehow readonly. > > If you need side effect-free functions in Python, you'd probably best copy > your aggregates, EG: > > import copy > > def main(): > a = ['a list','with','three elements'] > print a > print fnc1(a) > print a > > def fnc1(b): > b = copy.deepcopy(b) > return fnc2(b) > > def fnc2(c): > c = copy.deepcopy(c) > c[1] = 'having' > return c Clearly, making a copy within the function eliminates the possibility of the side effects caused by passing in mutable objects. Would having the compiler/interpreter do this automatically make python so much different? What if it were optional, like nested scopes were in python 2.1 until they became standard in 2.2? Henry -- http://mail.python.org/mailman/listinfo/python-list
Re: Something is rotten in Denmark...
On Tue, May 31, 2011 at 12:48 AM, harrismh777 wrote: > What is going on with the binding in the first construct... this seems > to reduce the usefulness of lambda to a considerable extent? I don't see why; as you've shown there are a couple of simple ways to avoid this problem. The trick is just to recognize that when you have a closure around a variable, and that variable needs to change, but the value in the closure needs to be constant, then what you really need are two separate variables -- the cell variable needs to be promoted to a local. How you accomplish that is not terribly important. One other technique that is sometimes preferable is functools.partial, e.g.: fs = [functools.partial(operator.add, i) for i in range(10)] Tangentially, I'd like to point out that this line: [fs[i](1) for i in range(10)] is more naturally written as: [f(1) for f in fs] -- http://mail.python.org/mailman/listinfo/python-list
Re: scope of function parameters (take two)
On Tue, May 31, 2011 at 6:17 PM, Henry Olders wrote:
> Clearly, making a copy within the function eliminates the possibility of the
> side effects caused by passing in mutable objects. Would having the
> compiler/interpreter do this automatically make python so much different?
As I've pointed, you can make decorator to do that. Adding @copy_args
to each function you intend to be pure is not that hard.
import decorator
import copy
@decorator.decorator
def copy_args(f, *args, **kw):
nargs = []
for arg in args:
nargs.append(copy.deepcopy(arg))
nkw = {}
for k,v in kw.iteritems():
nkw[k] = copy.deepcopy(v)
return f(*nargs, **nkw)
@copy_args
def test(a):
a.append(1)
return a
>>> l = [0]
>>> test(l)
[0, 1]
>>> l
[0]
>>> inspect.getargspec(test)
ArgSpec(args=['a'], varargs=None, keywords=None, defaults=None)
So this decorator achieves needed result and preserves function signatures.
--
With best regards,
Daniel Kluev
--
http://mail.python.org/mailman/listinfo/python-list
Re: scope of function parameters (take two)
On Tue, May 31, 2011 at 5:17 PM, Henry Olders wrote: > Clearly, making a copy within the function eliminates the possibility of the > side effects caused by passing in mutable objects. Would having the > compiler/interpreter do this automatically make python so much different? Yes, it would make Python quite different. If suddenly you couldn't pass a mutable object to a function to get it muted (that sounds wrong), then code will break. Also, there's a fairly serious performance penalty to copying everything when it's not necessary. As has been suggested, you can specifically and deliberately cause this effect for any function(s) you wish to "protect" in this way; there's no need to change the language's fundamentals to do it. Chris Angelico -- http://mail.python.org/mailman/listinfo/python-list
BadValueError: Property title is required
Hello,
I'm trying to create simple method to create category. I set the model
category:
class Category(db.Model):
title = db.StringProperty(required=True)
clashes_count = db.IntegerProperty(default=0)
And the class New Category as well :
class NewCategoryPage(webapp.RequestHandler):
def get(self):
categories = Category.all().order('-title')
template_values = { }
path = os.path.join(os.path.dirname(__file__), 'templates',
'category_new.html')
self.response.out.write(template.render(path, template_values))
def post(self):
category = Category()
category.title = self.request.get('title')
category.put()
self.redirect('/')
Here is the template:
{%extends "base.html"%}
{%block body%}
Add New Category
Title:
{%endblock%}
The problem is that I'm getting an error BadValueError: Property title
is required. Can you help me with that ? Thanks
--
http://mail.python.org/mailman/listinfo/python-list
Re: BadValueError: Property title is required
On Tue, May 31, 2011 at 1:21 AM, michal.bulla wrote: > Hello, > > I'm trying to create simple method to create category. I set the model > category: > > class Category(db.Model): > title = db.StringProperty(required=True) > clashes_count = db.IntegerProperty(default=0) > The problem is that I'm getting an error BadValueError: Property title > is required. Can you help me with that ? Thanks Try asking on the Django mailing list: http://groups.google.com/group/django-users Cheers, Chris -- http://mail.python.org/mailman/listinfo/python-list
Re: scope of function parameters (take two)
On Dienstag 31 Mai 2011, Henry Olders wrote: > You're partially right - what I want is a function that is > free of side effects back through the parameters passed in > the function call. I don't know any object oriented language where it is not possible to change objects passed in as parameters. It is up to the passed object (a list in your case) to allow or disallow manipulations no matter how they are invocated, and the object is the same in the calling code and in the called function. -- Wolfgang -- http://mail.python.org/mailman/listinfo/python-list
Re: sqlalchemy and Unicode strings: errormessage
Hi Wolfgang, On 30/05/2011 22:40, Wolfgang Meiners wrote: I am trying to build an application using sqlalchemy. You're likely to get much better help here: http://www.sqlalchemy.org/support.html#mailinglist When you post there, make sure you include: - what python version you're using - what sqlalchemy version you're using cheers, Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk -- http://mail.python.org/mailman/listinfo/python-list
Re: Something is rotten in Denmark...
harrismh777 writes: > >>> fs=[] > >>> fs = [(lambda n: i + n) for i in range(10)] > >>> [fs[i](1) for i in range(10)] > [10, 10, 10, 10, 10, 10, 10, 10, 10, 10] <=== not good > > ( that was a big surprise! . . . ) > ( let's try it another way . . . ) The ten functions share the same i. The list comprehension changes the value of that i. At the time when the functions are called, the value is 9. A different list comprehension mechanism could create a fresh i for each element instead of changing the value of one i. Then each of the functions would have a private i which would have the value it had at the time of the creation of the closure. That is not the Python mechanism. The same sharing-an-i thing happens here: >>> fs = [] >>> for i in range(4): ...fs.append(lambda n : i + n) ... >>> fs[0](0) 3 And the different private-j thing happens here: >>> gs = [] >>> for i in range(4): ...gs.append((lambda j : lambda n : j + n)(i)) ... >>> gs[0](0) 0 You used the lambda itself to introduce its private i in your other examples, in (lambda n, i=i : i + n). In its i=i, the i to the left is a different i - will be a fresh i every time the function is called, I think - while the i to the right gets resolved to the value of the i that the list comprehension is stepping at the time when the closure is created. > What is going on with the binding in the first > construct... this seems to reduce the usefulness of lambda to a > considerable extent? The lambda is doing its lambda thing exactly. The list comprehension just updates the one i in whatever you call it that each of the ten closures remember, and they all observe the updates, so to say. It's a bit subtle. Using different names might help, like I used j. -- http://mail.python.org/mailman/listinfo/python-list
Re: Something is rotten in Denmark...
Am 31.05.2011 12:08 schrieb Jussi Piitulainen: The same sharing-an-i thing happens here: fs = [] for i in range(4): ...fs.append(lambda n : i + n) ... fs[0](0) 3 And the different private-j thing happens here: gs = [] for i in range(4): ...gs.append((lambda j : lambda n : j + n)(i)) ... gs[0](0) 0 There is a simpler way: with fs = [] for i in range(4): > ...fs.append(lambda n, i=i: i + n) > ... you give each lambda a different default argument. fs[0](0) > 0 Thomas -- http://mail.python.org/mailman/listinfo/python-list
Load averages and Python threads on different Linux cloud provider setup
Hello,
Apologies if this post is off topic.
We have a Python application that polls directories using threads and
inotify watchers. We have always run this application in a cloud
server provided by Voxel (http://www.voxel.net). We are currently
testing a different cloud server provider StormOnDemand
(http://stormondemand.com) and when we ran our application, our load
averages were a lot higher then they were when they were running on
the Voxel cloud server despite the specs being about the same (Refer
below for more details on setup). We have also ensured then when
testing the server was not handling any other loads.
I have written a simple test application (test_threads.py - attached,
or refer to http://pastebin.com/xGQU7JD0) that simulates the issues we
are seeing by starting up threads that loops, sleeping for a user
defined time on each loop. It takes 2 parameters, the amount of
threads to start and the interval period.
When I run, "python test_threads.py 50 0.1" for about 10 minutes
Load average results:
StormOnDemand:
$ uptime
18:46:22 up 7:29, 6 users, load average: 4.43, 4.16, 2.93
voxel.net
$ uptime
18:48:14 up 9 days, 15:09, 9 users, load average: 0.51, 0.47, 0.43
The load average on the StormOnDemand server is a lot higher.
Python version:
StormOnDemand - 2.6.5
Voxel - 2.6.5
Server spec:
StormOnDemand - 8 x Intel(R) Xeon(R) CPU E5506 @ 2.13GHz; 16GB RAM;
230GB HDD (Storm Bare Metal servers)
Voxel - 7 x Intel(R) Xeon(R) CPU L5640 @ 2.27GHz; 14GB RAM; 200GB HDD
(VoxCloud servers)
OS:
StormOnDemand - Ubuntu 10.04 - 2.6.36-rc8101910 #1 SMP Tue Oct 19
19:18:34 UTC 2010 x86_64 GNU/Linux
Voxel - Ubuntu 10.04 - 2.6.32-31-server #61-Ubuntu SMP Fri Apr 8
19:44:42 UTC 2011 x86_64 GNU/Linux
Virtualisation method:
StormOnDemand - Not 100% sure, but I think they use Xen
Voxel - Not sure, but the image that we are using looks to us like a
stock standard Ubuntu 10.04 server
Any suggestion on why the load would be a lot higher or how I could
debug this further is greatly appreciated.
--
Mohan
#Simple script to test load when running python threads
# usage:
# python test_threads.py
# e.g. :
# python test_threads.py 50 0.1
#
import sys
from threading import Lock, Thread
import logging
import time
logging.basicConfig()
log = logging.getLogger("test")
log.setLevel(logging.DEBUG)
class MonitorDir(Thread):
def __init__(self, id, interval):
super(MonitorDir, self).__init__()
self.interval = interval
self.id = id
self._terminated = False
def finish(self):
if not self._terminated:
log.info('Terminating... %i'%self.id)
self._terminated = True
def run(self):
print 'Start threadi %i'%self.id
try:
while not self._terminated:
log.info('in id - %i \n'%self.id)
time.sleep(self.interval)
except:
log.exception('Unexpected error while monitoring')
finally:
log.info('Done monitoring')
if __name__ == '__main__':
mThreads = []
for i in range(int(sys.argv[1])):
print "create thread %i"%i
mThread = MonitorDir(i, float(sys.argv[2]))
mThreads.append(mThread)
mThread.start()
while any(x.isAlive() for x in mThreads):
try:
time.sleep(1)
except KeyboardInterrupt:
log.debug('Exiting...')
break
else:
sys.exit(1)
for mThread in mThreads:
mThread.finish()
for mThread in mThreads:
mThread.join()
sys.exit(0)
--
http://mail.python.org/mailman/listinfo/python-list
Re: sqlalchemy and Unicode strings: errormessage
On Tue, May 31, 2011 at 8:40 AM, Wolfgang Meiners
wrote:
> metadata = MetaData('sqlite://')
> a_table = Table('tf_lehrer', metadata,
> Column('id', Integer, primary_key=True),
> Column('Kuerzel', Text),
> Column('Name', Text))
Use UnicodeText instead of Text.
> A_record = A_class('BUM', 'Bäumer')
If this is python2.x, use u'Bäumer' instead.
--
With best regards,
Daniel Kluev
--
http://mail.python.org/mailman/listinfo/python-list
Re: How to catch a line with Popen
Chris Torek wrote: > Since it is a generator that only requests another line when called, > it should be fine Is it, then, that until the new itaration, the callee is on pause? -- goto /dev/null -- http://mail.python.org/mailman/listinfo/python-list
Re: Something is rotten in Denmark...
Thomas Rachel writes: > Am 31.05.2011 12:08 schrieb Jussi Piitulainen: > > > The same sharing-an-i thing happens here: > > > fs = [] > for i in range(4): > > ...fs.append(lambda n : i + n) > > ... > fs[0](0) > > 3 > > > > And the different private-j thing happens here: > > > gs = [] > for i in range(4): > > ...gs.append((lambda j : lambda n : j + n)(i)) > > ... > gs[0](0) > > 0 > > There is a simpler way: with > > fs = [] > for i in range(4): > > ...fs.append(lambda n, i=i: i + n) > > ... > > you give each lambda a different default argument. > > fs[0](0) > > 0 I know, and harrismh777 knows. I find it an unnecessary distraction when explaining why the different closures in the initial example behave identically, but I did discuss it at the end of my post. -- http://mail.python.org/mailman/listinfo/python-list
Re: Load averages and Python threads on different Linux cloud provider setup
On Tue, May 31, 2011 at 9:25 PM, Mohanaraj Gopala Krishnan wrote: > Any suggestion on why the load would be a lot higher or how I could > debug this further is greatly appreciated. > First off, an easy question: Is system load low and comparable on both systems when this script is _not_ running? Chris Angelico -- http://mail.python.org/mailman/listinfo/python-list
Re: BadValueError: Property title is required
On May 31, 10:32 am, Chris Rebert wrote: > On Tue, May 31, 2011 at 1:21 AM, michal.bulla wrote: > > Hello, > > > I'm trying to create simple method to create category. I set the model > > category: > > > class Category(db.Model): > > title = db.StringProperty(required=True) > > clashes_count = db.IntegerProperty(default=0) > > Not "obviously" Django at all. > > The problem is that I'm getting an error BadValueError: Property title > > is required. Can you help me with that ? Thanks > > Try asking on the Django mailing > list:http://groups.google.com/group/django-users Arf ! I just told the guy he was on the wrong group when he (re?)posted this on django-users. -- http://mail.python.org/mailman/listinfo/python-list
Re: The worth of comments
On 2011-05-28, Roy Smith wrote: > One reasonable definition of a bug is something the code > actually does which differs from the documented interface. > Unless you know what the code is supposed to do, how can you > possibly look at it and say whether it has a bug or not? For > example, take this function: > > def foo(): >l = [1, 2, 3] >return l[3] > > Is this code correct? I'll bet most people would look at this > and say, "I'm not sure what he had in mind, but whatever it > was, this has to be a bug because he's indexing past the end of > the list". Well, what if I showed you the interface contract: > > def foo(): >"Raise IndexError. This is useful as a testing fixture." >l = [1, 2, 3] >return l[3] > > Now it's obvious that the function does exactly what it's > supposed to do (even if it's not the best way to do it). That's an excellent illustration of bad code hid by a bad comment. Perhaps better: def foo(): raise IndexError() -- Neil Cerutti -- http://mail.python.org/mailman/listinfo/python-list
Re: sqlalchemy and Unicode strings: errormessage
Am 31.05.11 13:32, schrieb Daniel Kluev:
> On Tue, May 31, 2011 at 8:40 AM, Wolfgang Meiners
> wrote:
>> metadata = MetaData('sqlite://')
>> a_table = Table('tf_lehrer', metadata,
>>Column('id', Integer, primary_key=True),
>>Column('Kuerzel', Text),
>>Column('Name', Text))
>
> Use UnicodeText instead of Text.
>
>> A_record = A_class('BUM', 'Bäumer')
>
> If this is python2.x, use u'Bäumer' instead.
>
>
Thank you Daniel.
So i came a little bit closer to the solution. Actually i dont write the
strings in a python program but i read them from a file, which is
utf8-encoded.
So i changed the lines
for line in open(file,'r'):
line = line.strip()
first to
for line in open(file,'r'):
line = unicode(line.strip())
and finally to
for line in open(file,'r'):
line = unicode(line.strip(),'utf8')
and now i get really utf8-strings. It does work but i dont know why it
works. For me it looks like i change an utf8-string to an utf8-string.
By the way: when i run a python program from eclipse, then
print sys.getdefaultencoding()
returns utf-8
and when i run the same python program from the command line, then
print sys.getdefaultencoding()
returns ascii
but my locale is set to
$ locale
LANG="de_DE.UTF-8"
LC_COLLATE="de_DE.UTF-8"
LC_CTYPE="de_DE.UTF-8"
LC_MESSAGES="de_DE.UTF-8"
LC_MONETARY="de_DE.UTF-8"
LC_NUMERIC="de_DE.UTF-8"
LC_TIME="de_DE.UTF-8"
LC_ALL="de_DE.UTF-8"
I think, utf8 is somewhat confusing in python - at least to me.
Wolfgang
--
http://mail.python.org/mailman/listinfo/python-list
Re: scope of function parameters (take two)
On 5/31/2011 2:37 AM, Henry Olders wrote: what I want is a function that is free of side effects back through the parameters passed in the function call. You can get that by refraining from mutating parameter objects. Simple as that. Just do not expect Python to enforce that discipline on everyone else. To be really functional, and never mutate objects, do not use Python lists, which are arrays. Use linked-list trees, like Lisp languages and perhaps others do. One can easily do this with tuples, or a subclass of tuples, or a class wrapping tuples. Linked-lists and functional programming go together because prepending to a linked list creates a new object while appending to a Python list mutates an existing list. Similarly, popping from a linked list retrieves an item and an existing sublist while popping from a Python list retrieves and item and mutates the list. -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: sqlalchemy and Unicode strings: errormessage
Am 31.05.11 11:55, schrieb Chris Withers: > Hi Wolfgang, > > On 30/05/2011 22:40, Wolfgang Meiners wrote: >> I am trying to build an application using sqlalchemy. > > You're likely to get much better help here: > > http://www.sqlalchemy.org/support.html#mailinglist > > When you post there, make sure you include: > > - what python version you're using > - what sqlalchemy version you're using > > cheers, > > Chris > Thank you for pointing me to this list. I will have a look to it. At the moment i think i am really struggeling with python and uft8. Wolfgang -- http://mail.python.org/mailman/listinfo/python-list
Re: scope of function parameters (take two)
On 5/31/2011 3:17 AM, Henry Olders wrote: Clearly, making a copy within the function eliminates the possibility of the side effects caused by passing in mutable objects. Mutable objects and mutating methods and functions are a *feature* of Python. If you do not like them, do not use them. > Would having the compiler/interpreter do this automatically > make python so much different? Yes. How would you then write a function like list.sort or list.pop? It is fundamental that parameters are simply local names that must be bound as part of the calling process. After that, they are nothing special. Python is a language for adults that take responsibility for what they do. If you do not like argument-mutating functions, then do not write them and do not use them (without making a copy yourself). Python was not designed to model timeless immutable mathematics. It is an information-object manipulation language and in real life, we mutate collections and associations all the time. -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: scope of function parameters (take two)
On Tue, May 31, 2011 at 1:38 AM, Daniel Kluev wrote:
> @decorator.decorator
> def copy_args(f, *args, **kw):
> nargs = []
> for arg in args:
> nargs.append(copy.deepcopy(arg))
> nkw = {}
> for k,v in kw.iteritems():
> nkw[k] = copy.deepcopy(v)
> return f(*nargs, **nkw)
There is no "decorator" module in the standard library. This must be
some third-party module. The usual way to do this would be:
def copy_args(f):
@functools.wraps(f)
def wrapper(*args, **kw):
nargs = map(copy.deepcopy, args)
nkw = dict(zip(kw.keys(), map(copy.deepcopy, kw.values(
return f(*nargs, **nkw)
return wrapper
Note that this will always work, whereas the "decorator.decorator"
version will break if the decorated function happens to take a keyword
argument named "f".
Cheers,
Ian
--
http://mail.python.org/mailman/listinfo/python-list
Re: sqlalchemy and Unicode strings: errormessage
I just found a second method on
http://docs.python.org/howto/unicode
you can use tho module codecs and then simply write
import codecs
f = codecs.open('unicode.rst', encoding='utf-8')
for line in f:
print repr(line)
Wolfgang
--
http://mail.python.org/mailman/listinfo/python-list
Re: scope of function parameters (take two)
On Tue, May 31, 2011 at 9:16 AM, Ian Kelly wrote:
> On Tue, May 31, 2011 at 1:38 AM, Daniel Kluev wrote:
> > @decorator.decorator
> > def copy_args(f, *args, **kw):
> >nargs = []
> >for arg in args:
> >nargs.append(copy.deepcopy(arg))
> >nkw = {}
> >for k,v in kw.iteritems():
> >nkw[k] = copy.deepcopy(v)
> >return f(*nargs, **nkw)
>
> There is no "decorator" module in the standard library. This must be
> some third-party module. The usual way to do this would be:
>
> def copy_args(f):
>@functools.wraps(f)
>def wrapper(*args, **kw):
>nargs = map(copy.deepcopy, args)
>nkw = dict(zip(kw.keys(), map(copy.deepcopy, kw.values(
>return f(*nargs, **nkw)
>return wrapper
>
>
Is there any reason not to simplify this to:
def copy_args(f):
@functools.wraps(f)
def wrapper(*args, **kw):
nargs = copy.deepcopy(args)
nkw = copy.deepcopy(kw)
return f(*nargs, **nkw)
return wrapper
It means you will copy the keys as well, however they will (almost)
certainly be strings which is effectively a no-op.
> Note that this will always work, whereas the "decorator.decorator"
> version will break if the decorated function happens to take a keyword
> argument named "f".
>
> Cheers,
> Ian
> --
> http://mail.python.org/mailman/listinfo/python-list
>
--
http://mail.python.org/mailman/listinfo/python-list
Re: sqlalchemy and Unicode strings: errormessage
On Tue, May 31, 2011 at 8:45 AM, Wolfgang Meiners
wrote:
> Am 31.05.11 13:32, schrieb Daniel Kluev:
>> On Tue, May 31, 2011 at 8:40 AM, Wolfgang Meiners
>> wrote:
>>> metadata = MetaData('sqlite://')
>>> a_table = Table('tf_lehrer', metadata,
>>> Column('id', Integer, primary_key=True),
>>> Column('Kuerzel', Text),
>>> Column('Name', Text))
>>
>> Use UnicodeText instead of Text.
>>
>>> A_record = A_class('BUM', 'Bäumer')
>>
>> If this is python2.x, use u'Bäumer' instead.
>>
>>
>
> Thank you Daniel.
> So i came a little bit closer to the solution. Actually i dont write the
> strings in a python program but i read them from a file, which is
> utf8-encoded.
>
> So i changed the lines
>
> for line in open(file,'r'):
> line = line.strip()
>
> first to
>
> for line in open(file,'r'):
> line = unicode(line.strip())
>
> and finally to
>
> for line in open(file,'r'):
> line = unicode(line.strip(),'utf8')
>
> and now i get really utf8-strings. It does work but i dont know why it
> works. For me it looks like i change an utf8-string to an utf8-string.
>
There's no such thing as a UTF-8 string. You have a list of bytes
(byte string) and you have a list of characters (unicode). UTF-8 is a
function that can convert bytes into characters (and the reverse). You
may recognize that the list of bytes was encoded using UTF-8 but the
computer does not unless you explicitly tell it to. Does that help
clear it up?
--
http://mail.python.org/mailman/listinfo/python-list
Re: scope of function parameters
On May 29, 1:30 pm, Henry Olders wrote: > I just spent a considerable amount of time and effort debugging a program. > The made-up code snippet below illustrates the problem I encountered: > > def main(): > a = ['a list','with','three elements'] > print a > print fnc1(a) > print a > > def fnc1(b): > return fnc2(b) > > def fnc2(c): > c[1] = 'having' > return c > > This is the output: > ['a list', 'with', 'three elements'] > ['a list', 'having', 'three elements'] > ['a list', 'having', 'three elements'] > > I had expected the third print statement to give the same output as the > first, but variable a had been changed by changing variable c in fnc2. > > It seems that in Python, a variable inside a function is global unless it's > assigned. This rule has apparently been adopted in order to reduce clutter by > not having to have global declarations all over the place. > > I would have thought that a function parameter would automatically be > considered local to the function. It doesn't make sense to me to pass a > global to a function as a parameter. > > One workaround is to call a function with a copy of the list, eg in fnc1 I > would have the statement "return fnc2(b[:]". But this seems ugly. > > Are there others who feel as I do that a function parameter should always be > local to the function? Or am I missing something here? > > Henry You want a functional language. You can simulate that in python by using tuples in place of lists. fnc2(c): c[1] = 'having' return c will of course then give you an error that tuples are not assignable (which seems to be what you want?) So you then use (something like) fnc2(c): return c[0:1] + c[2:] -- http://mail.python.org/mailman/listinfo/python-list
Re: Load averages and Python threads on different Linux cloud provider setup
On May 31, 10:22 pm, Chris Angelico wrote: > On Tue, May 31, 2011 at 9:25 PM, Mohanaraj Gopala Krishnan > > wrote: > > Any suggestion on why the load would be a lot higher or how I could > > debug this further is greatly appreciated. > > First off, an easy question: Is system load low and comparable on both > systems when this script is _not_ running? Yes, they both are are < 0.5 (for all averages) and comparable. > > Chris Angelico -- http://mail.python.org/mailman/listinfo/python-list
RE: sqlalchemy and Unicode strings: errormessage
>line = unicode(line.strip(),'utf8')
>and now i get really utf8-strings. It does work but i dont know why it works.
>For me it looks like i change an utf8-string to an utf8-string.
I would like to point out that UTF-8 is not exactly "Unicode". From what I
understand, Unicode is a standard while UTF-8 is like an implementation of that
standard (called an encoding). Being able to convert to Unicode (the standard)
should mean you are then able to convert to any encoding that supports the
Unicode characters used.
As you can see below a string in UTF-8 is actually not Unicode. (decode
converts to Unicode, encode converts away from Unicode)
>>> type(u'test'.encode('utf8'))
>>> type('test'.decode('utf8'))
>>> type('test'.encode('utf8'))
>>> type(u'test')
Ramit
Ramit Prasad | JPMorgan Chase Investment Bank | Currencies Technology
712 Main Street | Houston, TX 77002
work phone: 713 - 216 - 5423
This communication is for informational purposes only. It is not
intended as an offer or solicitation for the purchase or sale of
any financial instrument or as an official confirmation of any
transaction. All market prices, data and other information are not
warranted as to completeness or accuracy and are subject to change
without notice. Any comments or statements made herein do not
necessarily reflect those of JPMorgan Chase & Co., its subsidiaries
and affiliates.
This transmission may contain information that is privileged,
confidential, legally privileged, and/or exempt from disclosure
under applicable law. If you are not the intended recipient, you
are hereby notified that any disclosure, copying, distribution, or
use of the information contained herein (including any reliance
thereon) is STRICTLY PROHIBITED. Although this transmission and any
attachments are believed to be free of any virus or other defect
that might affect any computer system into which it is received and
opened, it is the responsibility of the recipient to ensure that it
is virus free and no responsibility is accepted by JPMorgan Chase &
Co., its subsidiaries and affiliates, as applicable, for any loss
or damage arising in any way from its use. If you received this
transmission in error, please immediately contact the sender and
destroy the material in its entirety, whether in electronic or hard
copy format. Thank you.
Please refer to http://www.jpmorgan.com/pages/disclosures for
disclosures relating to European legal entities.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Beginner needs advice
On 31/05/2011 06:48, Ben Finney wrote: Dennis Lee Bieber writes: Well... He did say "find the bathroom", not ask for directions to whatever euphemism is in current usage (water closet, W/C, loo ?) The room which contains the bath is the bathroom. Assuming that the toilet is in the same room as the bath is parochial. If he wants the toilet, “bathroom” is a euphemism, and he should instead ask for directions to the toilet. "Toilet" is also a euphemism, as are "water closet", "WC", "loo", etc. -- http://mail.python.org/mailman/listinfo/python-list
nosend missing in suds 0.4?
Looks like the nosend attribute is not available in 0.4. Any reason for this? Any plans to add it back and what is the most recent release that does have the nosend option? -- http://mail.python.org/mailman/listinfo/python-list
Re: scope of function parameters (take two)
On Tue, May 31, 2011 at 10:34 AM, Chris Kaynor wrote: > Is there any reason not to simplify this to: > def copy_args(f): > @functools.wraps(f) > def wrapper(*args, **kw): > nargs = copy.deepcopy(args) > nkw = copy.deepcopy(kw) > return f(*nargs, **nkw) > return wrapper No reason, good call. > It means you will copy the keys as well, however they will (almost) > certainly be strings which is effectively a no-op. I think the keys will certainly be strings. Is there any scenario where they might not be? -- http://mail.python.org/mailman/listinfo/python-list
Re: Something is rotten in Denmark...
On 5/31/2011 2:48 AM, harrismh777 wrote: fs=[] Irrelevant here since you immediately rebind 'fs'. fs = [(lambda n: i + n) for i in range(10)] [fs[i](1) for i in range(10)] Same as [f(1) for f in fs] [10, 10, 10, 10, 10, 10, 10, 10, 10, 10] <=== not good ( that was a big surprise! . . . ) You have been hypnotizeed by lambda. (lambda n: i+n) is a *constant expression*, so you get 10 'equal' functions. To see this better fs = [(lambda n: i + n) for i in range(10)] from dis import dis for f in fs: dis(f) 1 0 LOAD_DEREF 0 (i) 3 LOAD_FAST0 (n) 6 BINARY_ADD 7 RETURN_VALUE 1 0 LOAD_DEREF 0 (i) 3 LOAD_FAST0 (n) 6 BINARY_ADD 7 RETURN_VALUE ... All have the same bytecode and all retrieve the same last value of i in the nonlocal listcomp scope when you call them *after* the listcomp scope has otherwise disappeared. Your code is equivalent to fs = [] for i in range(10): fs.append(lambda n: i + n) print([f(1) for f in fs]) which is equivalent (except for naming the functions) to fs = [] for i in range(10): def f(n): return i + n fs.append(f) print([f(1) for f in fs]) Does [10, 10, 10, 10, 10, 10, 10, 10, 10, 10] still surprise? Because the def is a constant expression, we can move it out of the loop, and get the equivalent (except for identity) def f(n): return i + n fs = [] for i in range(10): fs.append(f) print([f(1) for f in fs]) This in turn is equivalent to def f(n): return i + n fs = [] for _ in range(10): fs.append(f) i=9 print([f(1) for f in fs]) which in turn is equivalent in output to def f(n): return i + n i = 9 print([f(1) for _ in range(10)]) Note that: def f(n): return i+n # or f = lambda n: i+n fs = [f for i in range(10)] print([f(1) for f in fs]) works in 2.7, with the same output, but not in 3.2 because in 3.x, i is local to the list comp and the later call raises unbound global error. ( let's try it another way . . . ) All these other ways create 10 *different* (unequal) functions that are different because they have captured 10 different values of i when defined instead of deferring lookup of i to when they are called. def g(i): return (lambda n: i + n) fs = [g(i) for i in range(10)] print([f.__closure__[0].cell_contents for f in fs]) fs = [(lambda n, i=i: i + n) for i in range(10)] print([f.__defaults__[0] for f in fs]) # CPython 3.2 dependent code !!! [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: sqlalchemy and Unicode strings: errormessage
On Wed, Jun 1, 2011 at 2:31 AM, Prasad, Ramit wrote: >>line = unicode(line.strip(),'utf8') >>and now i get really utf8-strings. It does work but i dont know why it works. >>For me it looks like i change an utf8-string to an utf8-string. > > > I would like to point out that UTF-8 is not exactly "Unicode". From what I > understand, Unicode is a standard while UTF-8 is like an implementation of > that standard (called an encoding). Being able to convert to Unicode (the > standard) should mean you are then able to convert to any encoding that > supports the Unicode characters used. Unicode defines characters; UTF-8 is one way (of many) to represent those characters in bytes. UTF-16 and UTF-32 are other ways of representing those characters in bytes, and internally, Python probably uses one of them - but there is no guarantee, and you should never need to know. Unicode strings can be stored in memory and manipulated in various ways, but they're a high level construct on par with lists and dictionaries - they can't be stored on disk or transmitted to another computer without using an encoding system. UTF-8 is an efficient way to translate Unicode text consisting primarily of low codepoint characters into bytes. It's not so much an implementation of Unicode as a means of converting a mythical concept of "Unicode characters" into a concrete stream of bytes. Hope that clarifies things a little! Chris Angelico -- http://mail.python.org/mailman/listinfo/python-list
Re: scope of function parameters
On May 31, 9:46 pm, rusi wrote:
> So you then use (something like)
>
> fnc2(c): return c[0:1] + c[2:]
Er sorry -- that should have been
def fnc2(c): return c[0:1] + ('having',) + c[2:]
--
http://mail.python.org/mailman/listinfo/python-list
Re: Beginner needs advice
> If you disagree, then I invite you to list one example of two > different things that are compatible. > Men and women. MS Office and Open Office. IE6 and HTML. -- Dotan Cohen http://gibberish.co.il http://what-is-what.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Beginner needs advice
On Tue, May 31, 2011 at 11:56 AM, Dotan Cohen wrote: >> If you disagree, then I invite you to list one example of two >> different things that are compatible. >> > > Men and women. This is a slightly different sense of the word compatible than we have been discussing: able to work together to perform a function, not interchangeable. > MS Office and Open Office. Nope. Remember, the assertion by harrismh777 was that "all you have to do to prove incompatibility is to show 'one' (1) test case where compatibility fails". As one example, any Calc document that uses the EASTERSUNDAY function will fail in Excel, since Excel does not provide it. I could easily come up with other examples (let's not even get into the differences in macros), but one is all I need. > IE6 and HTML. :-) -- http://mail.python.org/mailman/listinfo/python-list
Re: Beginner needs advice
On Tue, May 31, 2011 at 21:29, Ian Kelly wrote: > On Tue, May 31, 2011 at 11:56 AM, Dotan Cohen wrote: >>> If you disagree, then I invite you to list one example of two >>> different things that are compatible. >>> >> >> Men and women. > > This is a slightly different sense of the word compatible than we have > been discussing: able to work together to perform a function, not > interchangeable. > >> MS Office and Open Office. > > Nope. Remember, the assertion by harrismh777 was that "all you have > to do to prove incompatibility is to show 'one' (1) test case where > compatibility fails". As one example, any Calc document that uses the > EASTERSUNDAY function will fail in Excel, since Excel does not provide > it. I could easily come up with other examples (let's not even get > into the differences in macros), but one is all I need. > >> IE6 and HTML. > > :-) > Ian, I'm surprised, you of all people might have noticed that my sarcasm was intended to point out exactly that no two things are compatible, least of all those things designed with compatibility as a design spec! -- Dotan Cohen http://gibberish.co.il http://what-is-what.com -- http://mail.python.org/mailman/listinfo/python-list
Re: scope of function parameters (take two)
Henry Olders wrote: [...] what I want is a function that is free of side effects [...] Shoot, that's easy! Just write your function to not have any! ~Ethan~ -- http://mail.python.org/mailman/listinfo/python-list
Re: scope of function parameters (take two)
Henry Olders wrote: Clearly, making a copy within the function eliminates the possibility of the side effects caused by passing in mutable objects. Would having the compiler/interpreter do this automatically make python so much different? It would be a different language. ~Ethan~ -- http://mail.python.org/mailman/listinfo/python-list
Thanks for all responses
I think it helped me very much to understand the problem.
So if i deal with nonascii strings, i have a 'list of bytes' and need an
encoding to interpret this list and transform it to a meaningful unicode
string. Decoding does the opposite.
Whenever i 'cross the border' of my program, i have to encode the 'list
of bytes' to an unicode string or decode the unicode string to a 'list
of bytes' which is meaningful to the world outside.
So encode early, decode lately means, to do it as near to the border as
possible and to encode/decode i need a coding system, for example 'utf8'
That means, there should be an encoding/decoding possibility to every
interface i can use: files, stdin, stdout, stderr, gui (should be the
most important ones).
While trying to understand this, i wrote the following program. Maybe
someone can give me a hint, how to print correctly:
##
#! python
# -*- coding: utf-8 -*-
class EncTest:
def __init__(self,Name=None):
self.Name=unicode(Name, encoding='utf8')
def __repr__(self):
return u'My name is %s' % self.Name
if __name__ == '__main__':
a = EncTest('Müller')
# this does work
print a.__repr__()
# throws an error if default encoding is ascii
# but works if default encoding is utf8
print a
# throws an error because a is not a string
print unicode(a, encoding='utf8')
##
Wolfgang
--
http://mail.python.org/mailman/listinfo/python-list
Re: Something is rotten in Denmark...
Terry Reedy wrote: You have been hypnotizeed by lambda. (lambda n: i+n) is a *constant expression*, so you get 10 'equal' functions. 'hypnotized' indeed! ... ok, so let me see if I get this... the lambda defers lookup|bind of its references until such time as the lambda is 'called' and not at the time (as I thought) that the anonymous function(s) are returned? If I'm understanding that correctly, then that means lambda is working as designed, and that there are very subtle nuances to be aware of. In my little case (lambda n: i + n) ... if the i goes out of scope before the anonymous function gets called then we have a problem... or if i as a reference is mutable or refers to a different object before the anonymous function is called then we have a problem? What I am discovering is that 'yes' I can use lambda syntactically where I might not be able to code a def statement; however, if I do use it (as in a list comprehension) then I may get unexpected results if any of my lambda's references go out of scope or are mutable...(?) Question: What are the ramifications of making the lookup|binding happen at the time the anonymous function is 'returned' vs 'called'? Has anyone suggested this? Is this PEP-able? Are there side-effects in the other direction? PS Thanks Chris, Ian, Jussi, Thomas, Terry... I appreciate your teaching and patience ! kind regards, m harris -- http://mail.python.org/mailman/listinfo/python-list
Re: scope of function parameters (take two)
I was thinking you could do something strange like:
kw = {object(): None}
def test(**kw):
print kw
test(**kw)
however, upon testing it (in Python 2.6), I found that it errors while
trying to unpack the kw dict stating that they must all be strings.
Perhaps making a custom class derived off basestring, str, unicode, or bytes
might allow some oddness and possibly slightly worse performance.
Chris
On Tue, May 31, 2011 at 10:10 AM, Ian Kelly wrote:
> On Tue, May 31, 2011 at 10:34 AM, Chris Kaynor
> wrote:
> > Is there any reason not to simplify this to:
> > def copy_args(f):
> >@functools.wraps(f)
> >def wrapper(*args, **kw):
> >nargs = copy.deepcopy(args)
> >nkw = copy.deepcopy(kw)
> >return f(*nargs, **nkw)
> >return wrapper
>
> No reason, good call.
>
> > It means you will copy the keys as well, however they will (almost)
> > certainly be strings which is effectively a no-op.
>
> I think the keys will certainly be strings. Is there any scenario
> where they might not be?
> --
> http://mail.python.org/mailman/listinfo/python-list
>
--
http://mail.python.org/mailman/listinfo/python-list
Re: Something is rotten in Denmark...
On Tue, 31 May 2011 01:48:05 -0500 harrismh777 wrote: > >>> fs=[] > >>> fs = [(lambda n: i + n) for i in range(10)] > >>> [fs[i](1) for i in range(10)] > [10, 10, 10, 10, 10, 10, 10, 10, 10, 10] <=== not good > > ( that was a big surprise! . . . ) > ( let's try it another way . . . ) After being confused I figured out it is a 3.x example: $ python Python 2.6.6 (r266:84292, Apr 20 2011, 11:58:30) [GCC 4.5.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> fs=[] >>> fs = [(lambda n: i + n) for i in range(10)] >>> [fs[i](1) for i in range(10)] [1, 2, 3, 4, 5, 6, 7, 8, 9, 10] $ python3.1 Python 3.1.3 (r313:86834, Nov 28 2010, 11:28:10) [GCC 4.4.5] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> fs=[] >>> fs = [(lambda n: i + n) for i in range(10)] >>> [fs[i](1) for i in range(10)] [10, 10, 10, 10, 10, 10, 10, 10, 10, 10] Is this fixed automatically by 2to3? Martin -- http://mail.python.org/mailman/listinfo/python-list
returning NotImplemented
Looking at the ABC code [1], I noticed that Mapping's __eq__ method can return NotImplemented. This got me curious as to why you would return NotImplemented and not raise a TypeError or a NotImplementedError. There was an issue regarding this last year [2] that indicated the reason for Mapping's behavior. Also, I found a thread from python-dev [3] which talks about the use of NotImplemented (the thread relates to numeric coercion). I found some older documentation on informal coercion guidelines that helped [4]. My understanding is that NotImplemented is used for binary operators: the right hand side of the operator should be tried if the left hand side returns NotImplemented. So it's more like DoNotKnowHowToHandleArgumentOfThatType. I think the name may have added to my confusion. (BTW, I learned that NotImplemented is a singleton, like None). Is binary operators the only place that NotImplemented is used under the hood? Is it all binary operators, and if not, where does it say which operators use NotImplemented? This would have bearing on when I would need to return it. In the python-dev thread [3], MRAB indicates NotImplemented is used instead of exceptions for performance reasons. Is raising NotImplementedError or TypeError that big a difference? I expect if you are using the operator on a large loop it could matter, but how much? Guido indicates earlier in the thread that NotImplemented is used so that you know that it came from the function that you directly called, and not from another call inside that function. Why does it matter if it came directly from the function or not? And couldn't the NotImplemented still have come from a call inside the operator, rather than directly? As an aside, don't we have that same situation all over the place. For instance, using __getattribute__, how do you know if an AttributeError means that the attribute was not found on the object? It could mean that __getattribute__ called something that raised the exception (and perhaps it should have handled it). Does it matter? Is there a good way to tell the difference, or would it be good practice to always handle explicitly in a function any exception type that you may be raising there? Thanks, -eric [1] http://hg.python.org/cpython/file/29e08a98281d/Lib/collections/abc.py#l398 [2] http://bugs.python.org/issue8729 [3] http://mail.python.org/pipermail/python-dev/2005-March/051835.html [4] http://docs.python.org/release/2.5.2/ref/coercion-rules.html -- http://mail.python.org/mailman/listinfo/python-list
Re: Something is rotten in Denmark...
On Tue, May 31, 2011 at 3:14 PM, Martin Manns wrote: > $ python > Python 2.6.6 (r266:84292, Apr 20 2011, 11:58:30) > [GCC 4.5.2] on linux2 > Type "help", "copyright", "credits" or "license" for more information. fs=[] fs = [(lambda n: i + n) for i in range(10)] [fs[i](1) for i in range(10)] > [1, 2, 3, 4, 5, 6, 7, 8, 9, 10] This works by accident. >>> [fs[i](1) for i in range(10)] [1, 2, 3, 4, 5, 6, 7, 8, 9, 10] >>> [fs[0](1) for i in range(10)] [1, 2, 3, 4, 5, 6, 7, 8, 9, 10] >>> [f(1) for f in fs] [10, 10, 10, 10, 10, 10, 10, 10, 10, 10] The i variable is part of the global scope, and as you iterate over range(10) again it coincidentally takes on the same values as in the original list comprehension. You don't see this in Python 3 because the scope of i is limited to the list comprehension, not global. Cheers, Ian -- http://mail.python.org/mailman/listinfo/python-list
Re: returning NotImplemented
On Tue, May 31, 2011 at 3:46 PM, Eric Snow wrote: > Looking at the ABC code [1], I noticed that Mapping's __eq__ method can > return NotImplemented. This got me curious as to why you would return > NotImplemented and not raise a TypeError or a NotImplementedError. > > There was an issue regarding this last year [2] that indicated the reason > for Mapping's behavior. Also, I found a thread from python-dev [3] which > talks about the use of NotImplemented (the thread relates to numeric > coercion). I found some older documentation on informal coercion guidelines > that helped [4]. My understanding is that NotImplemented is used for binary > operators: the right hand side of the operator should be tried if the left > hand side returns NotImplemented. So it's more like > DoNotKnowHowToHandleArgumentOfThatType. I think the name may have added to > my confusion. (BTW, I learned that NotImplemented is a singleton, like > None). > > Is binary operators the only place that NotImplemented is used under the > hood? Is it all binary operators, and if not, where does it say which > operators use NotImplemented? This would have bearing on when I would need > to return it. > > In the python-dev thread [3], MRAB indicates NotImplemented is used instead > of exceptions for performance reasons. Is raising NotImplementedError or > TypeError that big a difference? I expect if you are using the operator on > a large loop it could matter, but how much? > > Guido indicates earlier in the thread that NotImplemented is used so that > you know that it came from the function that you directly called, and not > from another call inside that function. Why does it matter if it came > directly from the function or not? And couldn't the NotImplemented still > have come from a call inside the operator, rather than directly? > > As an aside, don't we have that same situation all over the place. For > instance, using __getattribute__, how do you know if an AttributeError means > that the attribute was not found on the object? It could mean that > __getattribute__ called something that raised the exception (and perhaps it > should have handled it). Does it matter? Is there a good way to tell the > difference, or would it be good practice to always handle explicitly in a > function any exception type that you may be raising there? > > Thanks, > > -eric > > [1] > http://hg.python.org/cpython/file/29e08a98281d/Lib/collections/abc.py#l398 > [2] http://bugs.python.org/issue8729 > [3] http://mail.python.org/pipermail/python-dev/2005-March/051835.html > [4] http://docs.python.org/release/2.5.2/ref/coercion-rules.html > I'm guessing that http://docs.python.org/reference/datamodel.html is the only place in the docs that talks about the use of NotImplemented. -eric -- http://mail.python.org/mailman/listinfo/python-list
Re: Thanks for all responses
On Wed, Jun 1, 2011 at 5:52 AM, Wolfgang Meiners
wrote:
> Whenever i 'cross the border' of my program, i have to encode the 'list
> of bytes' to an unicode string or decode the unicode string to a 'list
> of bytes' which is meaningful to the world outside.
Most people use "encode" and "decode" the other way around; you encode
a string as UTF-8, and decode UTF-8 into a Unicode string. But yes,
you're correct.
> So encode early, decode lately means, to do it as near to the border as
> possible and to encode/decode i need a coding system, for example 'utf8'
Correct on both counts.
> That means, there should be an encoding/decoding possibility to every
> interface i can use: files, stdin, stdout, stderr, gui (should be the
> most important ones).
The file objects (as returned by open()) have an encoding, which
(IMHO) defaults to "utf8". GUI work depends on your GUI toolkit, and
might well accept Unicode strings directly - check the docs.
> def __repr__(self):
> return u'My name is %s' % self.Name
This means that repr() will return a Unicode string.
> # this does work
> print a.__repr__()
>
> # throws an error if default encoding is ascii
> # but works if default encoding is utf8
> print a
>
> # throws an error because a is not a string
> print unicode(a, encoding='utf8')
The __repr__ function is supposed to return a string object, in Python
2. See http://docs.python.org/reference/datamodel.html#object.__repr__
for that and other advice on writing __repr__. The problems you're
seeing are a result of the built-in repr() function calling
a.__repr__() and then treating the return value as an ASCII str, not a
Unicode string.
This would work:
def __repr__(self):
return (u'My name is %s' % self.Name).encode('utf8')
Alternatively, migrate to Python 3, where the default is Unicode
strings. I tested this in Python 3.2 on Windows, but it should work on
anything in the 3.x branch:
class NoEnc:
def __init__(self,Name=None):
self.Name=Name
def __repr__(self):
return 'My name is %s' % self.Name
if __name__ == '__main__':
a = NoEnc('Müller')
# this will still work (print is now a function, not a statement)
print(a.__repr__())
# this will work in Python 3.x
print(a)
# 'unicode' has been renamed to 'str', but it's already unicode so
this makes no sense
print(str(a, encoding='utf8'))
# to convert it to UTF-8, convert it to a string with str() or
repr() and then print:
print(str(a).encode('utf8'))
Note that the last one will probably not do what you expect. The
Python 3 'print' function (it's not a statement any more, so you need
parentheses around its argument) wants a Unicode string, so you don't
need to encode it. When you encode a Unicode string as in the last
example, it returns a bytes string (an array of bytes), which looks
like this: b'My name is M\xc3\xbcller' The print function wants
Unicode, though, so it takes this unexpected object and calls str() on
it, hence the odd display.
Hope that helps!
Chris Angelico
--
http://mail.python.org/mailman/listinfo/python-list
Re: Something is rotten in Denmark...
Martin Manns wrote: After being confused I figured out it is a 3.x example: Actually, it is a compatibility example between 2.x and 3.x, compare below for different behavior from two seemingly identical compatible constructs, one from 3.2, and the other from 2.6.4: Python 3.2 (r32:88445, Mar 29 2011, 21:33:57) [GCC 4.3.3] on linux2 fs=[] fs = [(lambda n: i + n) for i in range(10)] [fs[i](1) for i in range(10)] [10, 10, 10, 10, 10, 10, 10, 10, 10, 10] <=== compare Python 2.6.4 (r264:75706, Dec 7 2009, 18:45:15) [GCC 4.4.1] on linux2 fs=[] fs = [(lambda n: i + n) for i in range(10)] [fs[i](1) for i in range(10)] [1, 2, 3, 4, 5, 6, 7, 8, 9, 10] <=== compare Having compared the two, someone please tell me whether the two are incompatible, mostly compatible, completely incompatible, or different languages... ,.,, I realize how 3.2 is working (at the moment) but as compared with the books, and the behavior of 2.6, it sure looks 'broke' to me... ... why would we want to defer lookup of the 'i' in range(10) until the anonymous function is called, instead of the time that the function object is returned... inquiring minds want to know... PS Ian calls the second construct "working by mistake..." kind regards, m harris -- http://mail.python.org/mailman/listinfo/python-list
Re: returning NotImplemented
Eric Snow wrote: Looking at the ABC code [1], I noticed that Mapping's __eq__ method can return NotImplemented. This got me curious as to why you would return NotImplemented and not raise a TypeError or a NotImplementedError. My understanding is that if your object does not know how to perform the desired action you should return NotImplemented; Python will then give the other object a chance to perform the operation (after all, it may know how), and if the other object also returns NotImplemented then Python itself will raise a TypeError. If the first object were to raise TypeError (or any exception), the second object would not get the chance to try. ~Ethan~ -- http://mail.python.org/mailman/listinfo/python-list
Re: Something is rotten in Denmark...
harrismh777 wrote: PS Ian calls the second construct "working by mistake..." oops, actually he called it, "working by accident... " -- http://mail.python.org/mailman/listinfo/python-list
Re: returning NotImplemented
On Tue, May 31, 2011 at 4:18 PM, Ethan Furman wrote: > Eric Snow wrote: > >> Looking at the ABC code [1], I noticed that Mapping's __eq__ method can >> return NotImplemented. This got me curious as to why you would return >> NotImplemented and not raise a TypeError or a NotImplementedError. >> > > My understanding is that if your object does not know how to perform the > desired action you should return NotImplemented; Python will then give the > other object a chance to perform the operation (after all, it may know how), > and if the other object also returns NotImplemented then Python itself will > raise a TypeError. > > If the first object were to raise TypeError (or any exception), the second > object would not get the chance to try. > > RIght. But the operator code could very well handle the appropriate exception instead of handling a return value of NotImplemented. Hence my further questions regarding performance and identifiability. My guess is that it's ultimately because of speed. -eric > ~Ethan~ > -- http://mail.python.org/mailman/listinfo/python-list
Re: Something is rotten in Denmark...
On Tue, May 31, 2011 at 2:18 PM, harrismh777 wrote: > If I'm understanding that correctly, then that means lambda is working as > designed, and that there are very subtle nuances to be aware of. In my > little case > > (lambda n: i + n) > > ... if the i goes out of scope before the anonymous function gets called > then we have a problem... or if i as a reference is mutable or refers to > a different object before the anonymous function is called then we have a > problem? Actually, if i merely goes out of scope, there is no problem. It just creates a closure. It's only when the i within that scope is modified that we run into problems. In fact, in Python 3 the scope of a list comprehension variable is the list comprehension itself, so in your original post i was already out of scope by the time you started calling the lambda functions. Cheers, Ian -- http://mail.python.org/mailman/listinfo/python-list
Re: Something is rotten in Denmark...
On Wed, Jun 1, 2011 at 7:53 AM, harrismh777 wrote: > Having compared the two, someone please tell me whether the two are > incompatible, mostly compatible, completely incompatible, or different > languages... > By implication, every version of Python is incompatible with every other. The 2.7.1 revision notes include: - Issue #1713: Fix os.path.ismount(), which returned true for symbolic links across devices. Suppose some program were depending on this bug. It works under 2.7.0, fails under 2.7.1. Does that mean that 2.7.1 is incompatible with 2.7.0? Chris Angelico -- http://mail.python.org/mailman/listinfo/python-list
Re: Something is rotten in Denmark...
On Wed, Jun 1, 2011 at 8:39 AM, Chris Angelico wrote: > - Issue #1713: Fix os.path.ismount(), which returned true for symbolic links > across devices. PS. I know nothing about this particular issue, I just skimmed down the release notes and stopped when something caught my eye. Choose another example if you know of a better one. Chris Angelico -- http://mail.python.org/mailman/listinfo/python-list
hide gtk warning
I am getting gtkwarning: gdk_property_change: assertion window ! =Null failed gtk.main() it is gdk bug but not fixed yet.How could I simply "not show/hide" this error warning? so user should never see it. thank you -- http://mail.python.org/mailman/listinfo/python-list
Re: Something is rotten in Denmark...
On 5/31/2011 4:18 PM, harrismh777 wrote: Terry Reedy wrote: You have been hypnotizeed by lambda. (lambda n: i+n) is a *constant expression*, so you get 10 'equal' functions. 'hypnotized' indeed! I say 'hypnotized' ;-) because people have posted examples almost exactly like the one you did, with a list of 10 (usually) lambda-defined functions, at least yearly for over a decade. Never have I seen the same puzzlement when the functions are defined with def statements instead. What you did differently is to continue investigating and discover some of the alternatives for yourself. Hence you get more effort from others in response. I think part of the problem with lambda is this: the body of a def statement is indented and nicely set apart from surrounding code. The body of a lambda expression is prefixed by the header but there is no terminator to visually indicate the end of the nested scope. I think there should have been. I often add unneeded parens, as you did, but that is not lambda specific. Generator expressions have to be set apart with parentheses, and other comprehensions are all fenced. There also seems to be a bit of lambda (oc)cultism and mystique of the anonymous. However, if a function raises an exception, anonymity is a defect. What you did differently is to continue investigating and discover some of the alternatives for yourself. > ... ok, so let me see if I get this... the lambda defers lookup|bind of its references until such time as the lambda is 'called' and not at the time (as I thought) that the anonymous function(s) are returned? In Python, there are no lambda objects to be called. A def statement, when executed, produces an instance of the user-defined function class. Its .__name__ attribute is the one given in the header of the statement. A lambda expression, when executed, produces an instance of the user-defined function class. Its .__name__ attribute is '' (at least in CPython). See the single difference? The objects produced by equivalent def statements and lambda expressions are otherwise exactly the same. statement with lambda arg-list: expression is an abbreviation for def new-name(arg-list): return expression statement with new-name assuming that the lambda in in the same scope as the statement and not nested in another scope-creating expression If I'm understanding that correctly, then that means lambda is working as designed, and that there are very subtle nuances to be aware of. I would say that there is no subtle nuance. Except for not providing a name, a lambda expression is purely an optional syntactic abbreviation. In my little case (lambda n: i + n) ... if the i goes out of scope before the anonymous function gets called then we have a problem... There was no problem; nonlocal names and their associations with objects get saved (in 'cells', for CPython) association with the function than needs them. One of my examples showed how to retrieve them. > or if i as a reference is mutable Objects are mutable, names can be rebound. > or refers to a different object before the anonymous function > is called then we have a problem? Anonymity is completely irrelevant to all of the above. Everything is the same as for def f(n): return i + n. When a function is compiled, each name is classified as local, non-local, or global. When the function is called and a name is evaluated, the corresponding object from its scope is retrieved, if there is one, or an error is raised. What I am discovering is that 'yes' I can use lambda syntactically where I might not be able to code a def statement; If the lambda expression is nested in an abbreviated nested scope (lambda or comprehension), then you have to unabbreviate the outer nesting before you can unabbreviate the lambda. Several example of this have been shown. however, if I do use it (as in a list comprehension) then I may get > unexpected results if any of my lambda's references go out of scope or are mutable...(?) Nothing needed goes out of scope and all names are rebindable (not mutable). What are the ramifications of making the lookup|binding happen at the time the anonymous function is 'returned' vs 'called'? This is early-binding versus late-binding. Python is a late-binding language. Are you asking about changing all function compilation or only when functions are defined with lambda expressions? The latter *would* make there be a 'suble nuance' that Python now lacks and does not need. Has anyone suggested this? Of course, more than once, in multiple variations. All have so far been rejected, more than once. The most sensible ideas are for earlier binding of builtins to make Python run faster. You have already discovered and been given some of the solutions. Another is to define a class with a __call__ statement and save the desired early bindings as instance data attributes. Your g(i): return lambda ... as well as the def
Re: scope of function parameters (take two)
On Wed, Jun 1, 2011 at 3:16 AM, Ian Kelly wrote: > > There is no "decorator" module in the standard library. This must be > some third-party module. The usual way to do this would be: Yes, but its very useful for decorators and provides some not-readily-available functionality. http://pypi.python.org/pypi/decorator/3.3.1 > Note that this will always work, whereas the "decorator.decorator" > version will break if the decorated function happens to take a keyword > argument named "f". No, it will not. Its the magic of decorator library, it is signature-preserving, while your variant breaks function signature and causes problems to any code that relies on signatures (happens with Pylons, for example). >>> @copy_args ... def test(a, f=None): ... print f ... >>> test([], f=123) 123 Basically decorator.decorator uses exec to create new function, with signature of function you pass to your decorator, so it does not matter what names you used for args in decorator itself. -- With best regards, Daniel Kluev -- http://mail.python.org/mailman/listinfo/python-list
Re: Something is rotten in Denmark...
Terry Reedy wrote: This is early-binding versus late-binding. Python is a late-binding language. ok ... Are you asking about changing all function compilation or only when functions are defined with lambda expressions? At least lambda expressions, but (see below) any other built-in where 'early-binding' makes sense for intuitive results or performance--- possibly, not commenting. The latter *would* make there be a 'suble nuance' that Python now lacks and does not need. How so, and why not? Has anyone suggested this? Of course, more than once, in multiple variations. All have so far been rejected, more than once. The most sensible ideas are for earlier binding of builtins to make Python run faster. At the moment I'm only speaking about my OP and that particular list comprehension... the thing that happened (at least for me) is that the intuitive sense that each 'i' somehow becomes a part of the anonymous function (I know, not so) is built-in. There is little to nothing indicating in the docs that this is not so. Again, what we have here is the 'i' being saved in a cell and looked up at call time (an implementation detail, 'late-binding') that is critical for the user-coder to understand. This *may* be true for other built-ins also, I'm not commenting on that, but it seems to me that if lambda is going to remain in the language at all that 'early-binding' in the lambda specific case would make sense; at least make the lambda more useful generally. ... just saying, kind regards, m harris -- http://mail.python.org/mailman/listinfo/python-list
Re: returning NotImplemented
Eric Snow wrote: Guido indicates earlier in the thread that NotImplemented is used so that you know that it came from the function that you directly called, and not from another call inside that function. Why does it matter if it came directly from the function or not? And couldn't the NotImplemented still have come from a call inside the operator, rather than directly? An exception can bubble up from several levels below the original call. Returning NotImplemented (even if returned from another internal function) still has to be deliberately done by the original method. Later in the thread it is also stated that while exception handling performance is not too different in C code, it is very much more expensive in Python code. As to why it would matter if whether the return was from the directly called method vs some nested method... not sure, but I would hazard a guess that by returning NotImplented the interpreter knows everything worked as it should have (assuming no bugs, of course); whereas an exception could easily _not_ have come from the directly called method. Imagine if the methods raised exceptions to signal normal behavior, and some object was buggy -- for __eq__ we'd end up with a False result, instead of getting the exception propagated. (!) ~Ethan~ -- http://mail.python.org/mailman/listinfo/python-list
Python hoodie
Hi all! I LOVE Python, and want to spread the word by sporting this awesome sweater shown at: http://www.freewear.org/?page=show_item&id=FW0067 which I found by looking on the merchandise page of python.org. However, I live in the United States and before checking out I noticed that on top of the US$40 it was going to cost an additional US$45 for SHIPPING! I guess because of customs and such. Anyway, where can I get one of these sweatshirts sent to me for a reasonable shipping price in the U.S.? I would be happy to buy one and show my love for Python, but US$85 is a little steep for a hoodie for me. Cheers! Chris -- http://mail.python.org/mailman/listinfo/python-list
Re: Something is rotten in Denmark...
On Tue, 31 May 2011 15:47:33 -0600 Ian Kelly wrote: > The i variable is part of the global scope, and as you iterate over > range(10) again it coincidentally takes on the same values as in the > original list comprehension. You don't see this in Python 3 because > the scope of i is limited to the list comprehension, not global. I read about the scope change. However, list comprehension scope being global still feels "right" for me because I am still using Python 2. I feel that I should start worrying more about future migration issues. Cheers Martin -- http://mail.python.org/mailman/listinfo/python-list
Re: scope of function parameters (take two)
On Tue, May 31, 2011 at 6:04 PM, Daniel Kluev wrote: > On Wed, Jun 1, 2011 at 3:16 AM, Ian Kelly wrote: >> >> There is no "decorator" module in the standard library. This must be >> some third-party module. The usual way to do this would be: > > Yes, but its very useful for decorators and provides some > not-readily-available functionality. > http://pypi.python.org/pypi/decorator/3.3.1 > >> Note that this will always work, whereas the "decorator.decorator" >> version will break if the decorated function happens to take a keyword >> argument named "f". > > No, it will not. Its the magic of decorator library, it is > signature-preserving, while your variant breaks function signature and > causes problems to any code that relies on signatures (happens with > Pylons, for example). Ah, I see. I assumed it was much simpler than it is. I found a way to break it with Python 3, though: >>> @copy_args ... def test(*, f): ... return f ... >>> test(f=1) Traceback (most recent call last): File "", line 1, in File "", line 2, in test File "", line 6, in copy_args TypeError: test() needs keyword-only argument f The interesting thing here is that the decorated function has exactly the correct function signature; it just doesn't work. Cheers, Ian -- http://mail.python.org/mailman/listinfo/python-list
Re: returning NotImplemented
On Tue, May 31, 2011 at 6:30 PM, Ethan Furman wrote: > Eric Snow wrote: > >> Guido indicates earlier in the thread that NotImplemented is used so that >> you know that it came from the function that you directly called, and not >> from another call inside that function. Why does it matter if it came >> directly from the function or not? And couldn't the NotImplemented still >> have come from a call inside the operator, rather than directly? >> > > An exception can bubble up from several levels below the original call. > Returning NotImplemented (even if returned from another internal function) > still has to be deliberately done by the original method. > > Later in the thread it is also stated that while exception handling > performance is not too different in C code, it is very much more expensive > in Python code. > > As to why it would matter if whether the return was from the directly > called method vs some nested method... not sure, but I would hazard a guess > that by returning NotImplented the interpreter knows everything worked as it > should have (assuming no bugs, of course); whereas an exception could easily > _not_ have come from the directly called method. Imagine if the methods > raised exceptions to signal normal behavior, and some object was buggy -- > for __eq__ we'd end up with a False result, instead of getting the exception > propagated. (!) > > Thanks Ethan. That was insightful. I hadn't considered the case where we would want a TypeError or NotImplementedError or whatever to propagate. So simply catching any old exception doesn't cut it. The alternative is to have something like a CouldNotHandleTypeError that inherits just from BaseException, that is only used in the NotImplemented situation. Then the specificity resolves that problem. You're right that performance still suffers for python code, but the current NotImplemented handling stuff is in the C code that handles operators. I guess where it would hit is where you raise the Exception in the __eq__ method (or wherever), instead of returning NotImplemented. So, my understanding is that NotImplemented is sort of a special case of raising "exceptions" through return values for performance reasons, where normally we use exceptions. Here is an example of the equivalence that I am seeing: class X: def __eq__(self, other): return NotImplemented result = X().__eq__(1) if result is NotImplemented: raise TypeError - vs - class X: def __eq__(self, other): raise CouldNotHandleTypeError try: result = X().__eq__(1) except CouldNotHandleTypeError: raise TypeError I'm fine with this. It's probably one of those practicality beats purity things. And at the C level it's practically the same thing. As I have thought about this I've realized that it's really isolated to a specific place, namely operator handling for numeric and comparison operators, so no big deal. -eric ~Ethan~ > -- > http://mail.python.org/mailman/listinfo/python-list > -- http://mail.python.org/mailman/listinfo/python-list
Updated blog post on how to use super()
I've tightened the wording a bit, made much better use of keyword arguments instead of kwds.pop(arg), and added a section on defensive programming (protecting a subclass from inadvertently missing an MRO requirement). Also, there is an entry on how to use assertions to validate search order requirements and make them explicit. http://bit.ly/py_super or http://rhettinger.wordpress.com/2011/05/26/super-considered-super/ Any further suggestions are welcome. I'm expecting this to evolve into how-to guide to be included in the regular Python standard documentation. The goal is to serve as a reliable guide to using super and how to design cooperative classes in a way that lets subclasses compose and extent them. Raymond Hettinger follow my python tips on twitter: @raymondh -- http://mail.python.org/mailman/listinfo/python-list
Re: float("nan") in set or as key
On Sunday, May 29, 2011 8:59:49 PM UTC-7, Steven D'Aprano wrote: > On Sun, 29 May 2011 17:55:22 -0700, Carl Banks wrote: > > > Floating point arithmetic evolved more or less on languages like Fortran > > where things like exceptions were unheard of, > > I'm afraid that you are completely mistaken. > > Fortran IV had support for floating point traps, which are "things like > exceptions". That's as far back as 1966. I'd be shocked if earlier > Fortrans didn't also have support for traps. > > http://www.bitsavers.org/pdf/ibm/7040/C28-6806-1_7040ftnMathSubrs.pdf Fine, it wasn't "unheard of". I'm pretty sure the existence of a few high end compiler/hardware combinations that supported traps doesn't invalidate my basic point. NaN was needed because few systems had a separate path to deal with exceptional situations like producing or operating on something that isn't a number. When they did exist few programmers used them. If floating-point were standardized today it might not even have NaN (and definitely wouldn't support the ridiculous NaN != NaN), because all modern systems can be expected to support exceptions, and modern programmers can be expected to use them. > The IEEE standard specifies that you should be able to control whether a > calculation traps or returns a NAN. That's how Decimal does it, that's > how Apple's (sadly long abandoned) SANE did it, and floats should do the > same thing. If your aim is to support every last clause of IEEE for better or worse, then yes that's what Python should do. If your aim is to make Python the best language it can be, then Python should reject IEEE's obsolete notions, and throw exceptions when operating on NaN. Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
Sanitizing filename strings across platforms
Scenario: a file-name from potentially untrusted sources may have
odd filenames that need to be sanitized for the underlying OS.
On *nix, this generally just means "don't use '/' or \x00 in your
string", while on Win32, there are a host of verboten characters
and file-names. Then there's also checking the abspath/normpath
of the resulting name to make sure it's still in the intended folder.
I've read through [1] and have started to glom together various
bits from that thread. My current course of action is something like
SACRED_WIN32_FNAMES = set(
['CON', 'PRN', 'CLOCK$', 'AUX', 'NUL'] +
['LPT%i' % i for i in range(32)] +
['CON%i' % i for i in range(32)] +
def sanitize_filename(fname):
sane = set(string.letters + string.digits + '-_.[]{}()$')
results = ''.join(c for c in fname if c in sane)
# might have to check sans-extension
if results.upper() in SACRED_WIN32_FNAMES:
results = "_" + results
return results
but if somebody already has war-hardened code they'd be willing
to share, I'd appreciate any thoughts.
Thanks,
-tkc
[1]
http://stackoverflow.com/questions/295135/turn-a-string-into-a-valid-filename-in-python
--
http://mail.python.org/mailman/listinfo/python-list
Re: float("nan") in set or as key
On Sunday, May 29, 2011 7:53:59 PM UTC-7, Chris Angelico wrote: > Okay, here's a question. The Python 'float' value - is it meant to be > "a Python representation of an IEEE double-precision floating point > value", or "a Python representation of a real number"? The former. Unlike the case with integers, there is no way that I know of to represent an abstract real number on a digital computer. Python also includes several IEEE-defined operations in its library (math.isnan, math.frexp). Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
Re: float("nan") in set or as key
On Wed, Jun 1, 2011 at 12:59 PM, Carl Banks wrote: > On Sunday, May 29, 2011 7:53:59 PM UTC-7, Chris Angelico wrote: >> Okay, here's a question. The Python 'float' value - is it meant to be >> "a Python representation of an IEEE double-precision floating point >> value", or "a Python representation of a real number"? > > The former. Unlike the case with integers, there is no way that I know of to > represent an abstract real number on a digital computer. This seems peculiar. Normally Python seeks to define its data types in the abstract and then leave the concrete up to the various implementations - note, for instance, how Python 3 has dispensed with 'int' vs 'long' and just made a single 'int' type that can hold any integer. Does this mean that an implementation of Python on hardware that has some other type of floating point must simulate IEEE double-precision in all its nuances? I'm glad I don't often need floating point numbers. They can be so annoying! Chris Angelico -- http://mail.python.org/mailman/listinfo/python-list
Re: Sanitizing filename strings across platforms
On May 31, 10:17 pm, Tim Chase wrote:
> Scenario: a file-name from potentially untrusted sources may have
> odd filenames that need to be sanitized for the underlying OS.
> On *nix, this generally just means "don't use '/' or \x00 in your
> string", while on Win32, there are a host of verboten characters
> and file-names. Then there's also checking the abspath/normpath
> of the resulting name to make sure it's still in the intended folder.
>
> I've read through [1] and have started to glom together various
> bits from that thread. My current course of action is something like
>
> SACRED_WIN32_FNAMES = set(
> ['CON', 'PRN', 'CLOCK$', 'AUX', 'NUL'] +
> ['LPT%i' % i for i in range(32)] +
> ['CON%i' % i for i in range(32)] +
>
> def sanitize_filename(fname):
> sane = set(string.letters + string.digits + '-_.[]{}()$')
> results = ''.join(c for c in fname if c in sane)
> # might have to check sans-extension
> if results.upper() in SACRED_WIN32_FNAMES:
> results = "_" + results
> return results
>
> but if somebody already has war-hardened code they'd be willing
> to share, I'd appreciate any thoughts.
>
There's http://pypi.python.org/pypi/filepath/0.1 (taken from
twisted.python.filepath).
Jean-Paul
--
http://mail.python.org/mailman/listinfo/python-list
Re: float("nan") in set or as key
On Tuesday, May 31, 2011 8:05:43 PM UTC-7, Chris Angelico wrote: > On Wed, Jun 1, 2011 at 12:59 PM, Carl Banks > wrote: > > On Sunday, May 29, 2011 7:53:59 PM UTC-7, Chris Angelico wrote: > >> Okay, here's a question. The Python 'float' value - is it meant to be > >> "a Python representation of an IEEE double-precision floating point > >> value", or "a Python representation of a real number"? > > > > The former. Unlike the case with integers, there is no way that I know of > > to represent an abstract real number on a digital computer. > > This seems peculiar. Normally Python seeks to define its data types in > the abstract and then leave the concrete up to the various > implementations - note, for instance, how Python 3 has dispensed with > 'int' vs 'long' and just made a single 'int' type that can hold any > integer. Does this mean that an implementation of Python on hardware > that has some other type of floating point must simulate IEEE > double-precision in all its nuances? I think you misunderstood what I was saying. It's not *possible* to represent a real number abstractly in any digital computer. Python couldn't have an "abstract real number" type even it wanted to. (Math aside: Real numbers are not countable, meaning they cannot be put into one-to-one correspondence with integers. A digital computer can only represent countable things exactly, for obvious reasons; therefore, to model non-countable things like real numbers, one must use a countable approximation like floating-point.) You might be able to get away with saying float() merely represents an "abstract floating-point number with provisions for nan and inf", but pretty much everyone uses IEEE format, so what's the point? And no it doesn't mean Python has to support every nuance (and it doesn't). Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
Re: float("nan") in set or as key
On Jun 1, 7:45 am, Carl Banks wrote: > On Sunday, May 29, 2011 8:59:49 PM UTC-7, Steven D'Aprano wrote: > > On Sun, 29 May 2011 17:55:22 -0700, Carl Banks wrote: > > > > Floating point arithmetic evolved more or less on languages like Fortran > > > where things like exceptions were unheard of, > > > I'm afraid that you are completely mistaken. > > > Fortran IV had support for floating point traps, which are "things like > > exceptions". That's as far back as 1966. I'd be shocked if earlier > > Fortrans didn't also have support for traps. > > >http://www.bitsavers.org/pdf/ibm/7040/C28-6806-1_7040ftnMathSubrs.pdf > > Fine, it wasn't "unheard of". I'm pretty sure the existence of a few high > end compiler/hardware combinations that supported traps doesn't invalidate my > basic point. NaN was needed because few systems had a separate path to deal > with exceptional situations like producing or operating on something that > isn't a number. When they did exist few programmers used them. If > floating-point were standardized today it might not even have NaN (and > definitely wouldn't support the ridiculous NaN != NaN), because all modern > systems can be expected to support exceptions, and modern programmers can be > expected to use them. > > > The IEEE standard specifies that you should be able to control whether a > > calculation traps or returns a NAN. That's how Decimal does it, that's > > how Apple's (sadly long abandoned) SANE did it, and floats should do the > > same thing. > > If your aim is to support every last clause of IEEE for better or worse, then > yes that's what Python should do. If your aim is to make Python the best > language it can be, then Python should reject IEEE's obsolete notions, and > throw exceptions when operating on NaN. > > Carl Banks Why can python not have an fpu object (class?) where one can go and turn on/off the button that makes nan signalling? In short, cant we have the cake and eat it too? -- http://mail.python.org/mailman/listinfo/python-list
Re: float("nan") in set or as key
In article Carl Banks wrote: > pretty much everyone uses IEEE format Is there *any* hardware in use today which supports floating point using a format other than IEEE? -- http://mail.python.org/mailman/listinfo/python-list
Re: Alternatives to PythonPath
En Sun, 29 May 2011 18:49:28 -0300, ray escribió: I am using Win7 on a tightly locked down desktop. Is there an alternative to using PythonPath? What are the trade-offs? Usually there is no need to define the PYTHONPATH variable; I never use it. There is a per-user site-packages directory (2.6 and up), on Windows it is located at %APPDATA%\Python\PythonXX\site-packages. Every user gets its own %APPDATA% directory, with read and write permissions. -- Gabriel Genellina -- http://mail.python.org/mailman/listinfo/python-list
Re: float("nan") in set or as key
On Wed, Jun 1, 2011 at 1:30 PM, Carl Banks wrote: > I think you misunderstood what I was saying. > > It's not *possible* to represent a real number abstractly in any digital > computer. Python couldn't have an "abstract real number" type even it wanted > to. True, but why should the "non-integer number" type be floating point rather than (say) rational? Actually, IEEE floating point could mostly be implemented in a two-int rationals system (where the 'int' is arbitrary precision, so it'd be Python 2's 'long' rather than its 'int'); in a sense, the mantissa is the numerator, and the scale defines the denominator (which will always be a power of 2). Yes, there are very good reasons for going with the current system. But are those reasons part of the details of implementation, or are they part of the definition of the data type? > (Math aside: Real numbers are not countable, meaning they cannot be put into > one-to-one correspondence with integers. A digital computer can only > represent countable things exactly, for obvious reasons; therefore, to model > non-countable things like real numbers, one must use a countable > approximation like floating-point.) Right. Obviously a true 'real number' representation can't be done. But there are multiple plausible approximations thereof (the best being rationals). Not asking for Python to be changed, just wondering why it's defined by what looks like an implementation detail. It's like defining that a 'character' is an 8-bit number using the ASCII system, which then becomes problematic with Unicode. (Ohai, C, didn't notice you standing there.) Chris Angelico -- http://mail.python.org/mailman/listinfo/python-list
Re: Updated blog post on how to use super()
Raymond Hettinger writes: > Any further suggestions are welcome. I am impressed by your optimistic outlook: For reorderable method calls to work, the classes need to be designed cooperatively. This presents three easily solved practical issues[…] :-) It's a good document, and I'm very glad this effort is being made to provide guidance on this feature. -- \ “The trouble with the rat race is that even if you win, you're | `\ still a rat.” —Jane Wagner, via Lily Tomlin | _o__) | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: float("nan") in set or as key
Chris Angelico writes: > Right. Obviously a true 'real number' representation can't be done. > But there are multiple plausible approximations thereof (the best > being rationals). Sure. But most of those are not what is most commonly meant by ‘float’ type. > Not asking for Python to be changed, just wondering why it's defined > by what looks like an implementation detail. Because, in the case of the ‘float’ type, the agreed-upon meaning of that type – in Python as in just about every other language that is well-specified – is “an IEEE float as per the IEEE 754 spec”. A foolish consistency to the spec would be a hobgoblin for little minds. But, given that a ‘float’ type which deviated from that spec would just be inviting all sorts of other confusion, it's not a foolish consistency. > It's like defining that a 'character' is an 8-bit number using the > ASCII system, which then becomes problematic with Unicode. Right. That's why in Python 3 the Unicode text type is called ‘unicode’, the IEEE float type is called ‘float’, and the byte string type is called ‘bytes’. It's also why the ‘str’ type in Python 2 was painful enough to need changing: it didn't clearly stick to a specification, but tried to straddle the worlds between one specification (a text type) and an incompatible other specification (a bytes sequence type). Where there is a clearly-defined widely-agreed specification for a type, it's a good idea to stick to that specification when claiming to implement that functionality in a type. -- \ “The man who is denied the opportunity of taking decisions of | `\ importance begins to regard as important the decisions he is | _o__)allowed to take.” —C. Northcote Parkinson | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: float("nan") in set or as key
On Tuesday, May 31, 2011 8:57:57 PM UTC-7, Chris Angelico wrote: > On Wed, Jun 1, 2011 at 1:30 PM, Carl Banks > wrote: > > I think you misunderstood what I was saying. > > > > It's not *possible* to represent a real number abstractly in any digital > > computer. Python couldn't have an "abstract real number" type even it > > wanted to. > > True, but why should the "non-integer number" type be floating point > rather than (say) rational? Python has several non-integer number types in the standard library. The one we are talking about is called float. If the type we were talking about had instead been called real, then your question might make some sense. But the fact that it's called float really does imply that that underlying representation is floating point. > Actually, IEEE floating point could mostly > be implemented in a two-int rationals system (where the 'int' is > arbitrary precision, so it'd be Python 2's 'long' rather than its > 'int'); in a sense, the mantissa is the numerator, and the scale > defines the denominator (which will always be a power of 2). Yes, > there are very good reasons for going with the current system. But are > those reasons part of the details of implementation, or are they part > of the definition of the data type? Once again, Python float is an IEEE double-precision floating point number. This is part of the language; it is not an implementation detail. As I mentioned elsewhere, the Python library establishes this as part of the language because it includes several functions that operate on IEEE numbers. And, by the way, the types you're comparing it to aren't as abstract as you say they are. Python's int type is required to have a two's-compliment binary representation and support bitwise operations. > > (Math aside: Real numbers are not countable, meaning they > > cannot be put into one-to-one correspondence with integers. > > A digital computer can only represent countable things > > exactly, for obvious reasons; therefore, to model > > non-countable things like real numbers, one must use a > > countable approximation like floating-point.) > > Right. Obviously a true 'real number' representation can't be done. > But there are multiple plausible approximations thereof (the best > being rationals). That's a different question. I don't care to discuss it, except to say that your default real-number type would have to be called something other than float, if it were not a floating point. > Not asking for Python to be changed, just wondering why it's defined > by what looks like an implementation detail. It's like defining that a > 'character' is an 8-bit number using the ASCII system, which then > becomes problematic with Unicode. It really isn't. Unlike with characters (which are trivially extensible to larger character sets, just add more bytes), different real number approximations differ in details too important to be left to the implementation. For instance, say you are using an implementation that uses floating point, and you define a function that uses Newton's method to find a square root: def square_root(N,x=None): if x is None: x = N/2 for i in range(100): x = (x + N/x)/2 return x It works pretty well on your floating-point implementation. Now try running it on an implementation that uses fractions by default (Seriously, try running this function with N as a Fraction.) So I'm going to opine that the representation does not seem like an implementation detail. Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
No module name tests
Hey i have directory structure as gkwebapp/gnukhata-webapp/gnukhata/tests/functional in which we have our test files. When i run tests, get following error: Traceback (most recent call last): File "test_account.py", line 1, in from gnukhata.tests import * ImportError: No module named gnukhata.tests Why do this error come?? I have searched a lot but no use. Can you please help me to sort it out??? -- http://mail.python.org/mailman/listinfo/python-list
