Re: Future standard GUI library
On Wed, May 29, 2013 at 3:26 AM, Wolfgang Keller wrote: > I won't give you an example, but just some very basic criteria: > > - It must be very efficient for very small "datagrams" > - It must provide connections > - For asynchronous programming it must provide for callbacks In other words, a TELNET connection. I absolutely concur. I've made extensive use of that family of protocols; between MUDs (three active connections right at this moment), mail (SMTP and POP both), actual command execution (though that's usually encrypted via SSH), and *seven* separate protocols that I devised for work, I pretty much *always* am working with a system that parses text into lines and (usually) lines into commands with arguments. It's a broad concept that can be applied to *everything*. I'm firmly of the opinion that Magic: The Gathering could be played over a MUD connection. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: String object has no attribute "append"
On Wed, May 29, 2013 at 4:25 AM, Matt Graves wrote:
> I receive this error while toying around with Functions...
>
> def pulldata(speclist,speccolumn):
> (speclist).append(column[('speccolumn')])
>
> pulldata(speclist = 'numbers', speccolumn = "0")
>
> I'm getting the error because it should say "numbers.append", but it is
> reading it as "(speclist).append".
Others have answered the immediate problem, but you may find this a
worthwhile read:
http://mail.python.org/pipermail/tutor/2010-December/080505.html
It's an excellent explanation of the way Python passes arguments to functions.
ChrisA
--
http://mail.python.org/mailman/listinfo/python-list
Re: IndentationError: expected an indented block but it's there
On Wed, May 29, 2013 at 2:53 AM, Peter Otten <__pete...@web.de> wrote: > Chris Angelico wrote: > >> On Wed, May 29, 2013 at 2:19 AM, Peter Otten <__pete...@web.de> wrote: >>> Solution: configure your editor to use four spaces for indentation. >> >> ITYM eight spaces. > > I meant: one hit of the Tab key should add spaces up to the next multiple of > four. Which implies > >> But the real solution is to not mix tabs and >> spaces. Stick to one or the other and you're safe. Sure. If you configure your tab *key* to not insert a tab *character*, then you're fine. Or alternatively, if you always use \t for indentation, you can tweak the displayed width of it. (Or, as I do, just let it be eight wide. On today's screens that's not much of a problem.) ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Python for IPSA (Power flow analysis)
On Tuesday, May 28, 2013 11:00:42 AM UTC+1, Debbie wrote:
> Hi there,
>
> I am new to Python, and wondering if you could help me with python based
> coding for the IPSA (Power system analysis software). I have a electrical
> distribution network with generators, buses and loads, on which I am
> performing the load flow analysis every 1 hour for a period of 1 year.
>
>
>
> The code to perform instantaneous load/power flow analysis is given below. I
> need to modify it such that I can perform this load flow analysis every 1
> hour for a period of 1 year. Please help.
>
>
>
> from ipsa import *
>
>
>
> ipsasys = IscInterface()
>
> net = ipsasys.ReadFile("refinery.iif")
>
> bok = net.DoLoadFlow();
>
> if bok:
>
> busbars = net.GetBusbars()
>
> print "Load Flow results:"
>
> print ""
>
> print "BusName Vmag(kV)"
>
> print ""
>
> for bus in busbars.itervalues():
>
> name = bus.GetName()
>
> vm = bus.GetVoltageMagnitudekV()
>
> res = "%-8s %10.5f" % (name, vm)
>
> print res
>
> else:
>
> print "Load Flow failed!"
>
>
>
> Regards,
>
> Debbie
Hi Debbie,
Just found your question. I work for Ipsa and, among other things, provide
support for the scripting side.
The quickest way to achieve what you want is to adjust the loads on the network
and perform a load flow. The sequence would be roughly as follows;
for hours in year():
# set load values
loads = net.GetLoads()
for load in loads().itervalues:
# set new value for each load to represent the next hour of data
load.SetDValue(IscLoad.ReactiveMVAr, next_MVAr_value)
load.SetDValue(IscLoad.RealMW, next_MW_value)
net.DoLoadFlow()
# do something with these results
The above code obviously won't work and will need tweaking, but should give you
the idea. The next version of Ipsa (2.3.2) will have load profiles in so will
give a different way of achieving the same results, as well as speed
improvements.
As Robert mentioned, the best place for Ipsa support is to go onto the website
(www.ipsa-power.com) and check the Support of Education pages or check the
LinkedIn group Ipsa Power Software Group at
http://www.linkedin.com/groups/IPSA-Power-Software-4860907
Hope this helps,
Steve
--
http://mail.python.org/mailman/listinfo/python-list
MySQL dymanic query in Python
Can anyone tell me the proper way in which I can execute dynamic MySQL queries in Python? I want to do dynamic queries for both CREATE and INSERT statement. Here is my attempted code: sql="create table %s (%%s, %%s, %%s ... )" % (tablename,''.join(fields)+' '.join(types)) cur.execute(sql) where 'field' is the fieldnames stored in a list and 'types' are the fieldtypes stored in a list. -- http://mail.python.org/mailman/listinfo/python-list
Re: MySQL dymanic query in Python
On 29 May 2013 10:13, "RAHUL RAJ" wrote: > > Can anyone tell me the proper way in which I can execute dynamic MySQL queries in Python? > > I want to do dynamic queries for both CREATE and INSERT statement. > > Here is my attempted code: > > > sql="create table %s (%%s, %%s, %%s ... )" % (tablename,''.join(fields)+' '.join(types)) > cur.execute(sql) > > > where 'field' is the fieldnames stored in a list and 'types' are the fieldtypes stored in a list. You need to join the fields and the field types. Use zip(). Then join with commas. fields_and_types = ['%s %s' % (field, type) for field, type in zip(fields, types)] what_goes_between_the_parens = ', '.join(fields_and_types) sql = 'create table %s (%s)' % (tablename, what_goes_between_the_parens) See where that gets you. -- http://mail.python.org/mailman/listinfo/python-list
Re: Text-to-Sound or Vice Versa (Method NOT the source code)
On May 29, 4:30 am, Dennis Lee Bieber wrote: > On Tue, 28 May 2013 15:10:03 + (UTC), Grant Edwards > declaimed the following in > gmane.comp.python.general: > > > On 2013-05-25, Rakshith Nayak wrote: > > > > Always wondered how sound is generated from text. Googling couldn't > > > help. Devs having knowledge about this could provide, the > > > information, Links, URLs or anything that could help. > > > > > > >http://www.cstr.ed.ac.uk/projects/festival/ > >http://code.google.com/p/pyfestival/ > >http://machakux.appspot.com/blog/44003/making_speech_with_python > > I suppose one could go for archaic and complex... > > Obtain a working Amiga computer, install whatever the last Python > version was available pre-built. Then write a server application which > would take text over the net, and feed it to the appropriate Amiga > libraries -- translator and narrator as I recall (one converted plain > text to phoneme codings, the other then converted phonemes to sound, and > could return values for "mouth shape" to sync animation) [history: the > Amiga had text to speech in the late 80s -- it even allowed for > adjusting some formant parameters so one could create pseudo accents]. If venerable history is wanted, there is (always?!) emacs: http://emacspeak.sourceforge.net/ This seems to go back to version 19 of emacs which is (c) mid- nineties -- http://mail.python.org/mailman/listinfo/python-list
Re: Encodign issue in Python 3.3.1 (once again)
What makes us o sure it is a pymysql issue and not python's encoding issue? -- http://mail.python.org/mailman/listinfo/python-list
Re: usage of os.posix_fadvise
Hi,
Wolfgang Maier biologie.uni-freiburg.de> writes:
>
> Dear all,
> I was just experimenting for the first time with os.posix_fadvise(), which
> is new in Python3.3 . I'm reading from a really huge file (several GB) and I
> want to use the data only once, so I don't want OS-level page caching. I
> tried os.posix_fadvise with the os.POSIX_FADV_NOREUSE and with the
> os.POSIX_FADV_DONTNEED flags, but neither seemed to have any effect on the
> caching behaviour of Ubuntu (still uses all available memory to page cache
> my I/O).
> Specifically, I was trying this:
>
> import os
> fd = os.open('myfile', os.O_RDONLY)
> # wasn't sure about the len parameter in fadvise,
> # so thought I just use it on the first 4GB
> os.posix_fadvise(fd, 0, 40, os.POSIX_FADV_NOREUSE) # or DONTNEED
The Linux version of "man posix_fadvise" probably holds the answer:
"In kernels before 2.6.18, POSIX_FADV_NOREUSE had the same semantics
as POSIX_FADV_WILLNEED. This was probably a bug; since kernel
2.6.18, this flag is a no-op."
"POSIX_FADV_DONTNEED attempts to free cached pages associated with the
specified region. This is useful, for example, while streaming large
files. A program may periodically request the kernel to free cached
data that has already been used, so that more useful cached pages are
not discarded instead."
So, in summary:
- POSIX_FADV_NOREUSE doesn't do anything on (modern) Linux kernels
- POSIX_FADV_DONTNEED must be called *after* you are done with a range of
data, not before you read it (note that I haven't tested to confirm it :-))
Regards
Antoine.
--
http://mail.python.org/mailman/listinfo/python-list
detect key conflict in a JSON file
Hi,
How can you detect if a key is duplicated in a JSON file? Example:
{
"something": [...],
...
"something": [...]
}
I have a growing JSON file that I edit manually and it might happen
that I repeat a key. If this happens, I would like to get notified.
Currently the value of the second key silently overwrites the value of
the first.
Do you know about a command line JSON validator?
Thanks,
Laszlo
--
http://mail.python.org/mailman/listinfo/python-list
Output is not coming with defined color
hi,
I am trying to display my output with different colour on terminal, but it's
coming with that colour code.
Please help me how is it possible?
my code is -
from fabric.colors import green, red, blue
def colorr():
a = red('This is red')
b = green('This is green')
c = blue('This is blue')
d = {a, b, c}
print d
colorr()
output -
set(['\x1b[32mThis is green\x1b[0m', '\x1b[34mThis is blue\x1b[0m',
'\x1b[31mThis is red\x1b[0m'])
Thanks
--
http://mail.python.org/mailman/listinfo/python-list
Fatal Python error
Hello all, again. Instead of revising like I'm meant to be, I've been delving into a bit of Python and I've come up with this code: class ClassWithProperty: @property def property(self): pass thingwithproperty = ClassWithProperty() def loop(): try: thingwithproperty.property except: pass loop() try: loop() except RuntimeError: pass As you will expect, this does nothing... on Python2.7 and PyPy. Python3.3 prefers to spit out a "Fatal Python error: Cannot recover from stack overflow.", which seems a bit unexpected. Wuzzup with that? -- http://mail.python.org/mailman/listinfo/python-list
Re: Output is not coming with defined color
On 29 May 2013 12:25, "Avnesh Shakya" wrote:
>
> hi,
>I am trying to display my output with different colour on terminal,
but it's
> coming with that colour code.
> Please help me how is it possible?
>
> my code is -
> from fabric.colors import green, red, blue
> def colorr():
> a = red('This is red')
> b = green('This is green')
> c = blue('This is blue')
> d = {a, b, c}
> print d
> colorr()
>
> output -
> set(['\x1b[32mThis is green\x1b[0m', '\x1b[34mThis is blue\x1b[0m',
'\x1b[31mThis is red\x1b[0m'])
>
> Thanks
You are printing the {a, b, c} set. That ends up printing the repr of all
of its contents. The repr breaks the desired output. Try to just
print a, b, c
--
http://mail.python.org/mailman/listinfo/python-list
Re: Fatal Python error
On 05/29/2013 07:48 AM, Joshua Landau wrote: Hello all, again. Instead of revising like I'm meant to be, I've been delving into a bit of Python and I've come up with this code: To start with, please post in text mode. By using html, you've completely messed up any indentation you presumably had. class ClassWithProperty: @property def property(self): pass Did you really mean to hide the built-in property? I don't know if this does that, but it's certainly confusing. And perhaps that's a difference between 2.x and 3.x thingwithproperty = ClassWithProperty() def loop(): try: thingwithproperty.property except: pass loop() try: loop() except RuntimeError: pass As you will expect, this does nothing... on Python2.7 and PyPy. Python3.3 prefers to spit out a "Fatal Python error: Cannot recover from stack overflow.", which seems a bit unexpected. A stack overflow means you have infinite recursion. Try fixing the property name above, and see if that makes a difference. -- DaveA -- http://mail.python.org/mailman/listinfo/python-list
Re: Fatal Python error
I just tried your code with similar results: it does nothing on PyPy 2.0.0-beta2 and Python 2.7.4. But on Python 3.3.1 it caused core dump. It's a little weird but so is the code. You have defined a function that calls itself unconditionally. This will cause a stack overflow, which is a RuntimeError. Since you are handling this very exception with a pass statement, we would expect that no error occurs. But the fatal error message seems pretty informative at this point: "Cannot recover from stack overflow.". One thing to note is that while it's reasonable to handle exceptions that happens at the level of your Python code, like a ValueError, it's not so reasonable to try to handle something that may disturb the interpreter itself in a lower level, like a stack overflow (I think that the stack used by your code is the same stack used by the interpreter code, but I'm not sure). 2013/5/29 Joshua Landau > Hello all, again. Instead of revising like I'm meant to be, I've been > delving into a bit of Python and I've come up with this code: > > class ClassWithProperty: > @property > def property(self): > pass > > thingwithproperty = ClassWithProperty() > > def loop(): > try: > thingwithproperty.property > except: > pass > > loop() > > try: > loop() > except RuntimeError: > pass > > As you will expect, this does nothing... on Python2.7 and PyPy. Python3.3 > prefers to spit out a "Fatal Python error: Cannot recover from stack > overflow.", which seems a bit unexpected. > > Wuzzup with that? > > -- > http://mail.python.org/mailman/listinfo/python-list > > -- http://mail.python.org/mailman/listinfo/python-list
Re: Fatal Python error
On 29 May 2013 13:25, Dave Angel wrote: > On 05/29/2013 07:48 AM, Joshua Landau wrote: > >> Hello all, again. Instead of revising like I'm meant to be, I've been >> delving into a bit of Python and I've come up with this code: >> >> > To start with, please post in text mode. By using html, you've completely > messed up any indentation you presumably had. Appologies, I use GMail and I don't know how to force text-only > class ClassWithProperty: >> @property >> def property(self): >> pass >> > > Did you really mean to hide the built-in property? I don't know if this > does that, but it's certainly confusing. And perhaps that's a difference > between 2.x and 3.x I'm not. That goes to self.property, whilst the normal function isn't. I guess it does locally hide it, but who really cares? :P You can rename it if you want. Anything will do. Obviously this is a minimal example code, and not the real thing. As you will expect, this does nothing... on Python2.7 and PyPy. Python3.3 >> prefers to spit out a "Fatal Python error: Cannot recover from stack >> overflow.", which seems a bit unexpected. >> >> > A stack overflow means you have infinite recursion. I realise, but I was hoping to catch that with the "except RuntimeError". > Try fixing the property name above, and see if that makes a difference. It does not make a difference. -- http://mail.python.org/mailman/listinfo/python-list
Re: Fatal Python error
On 29 May 2013 12:48, Joshua Landau wrote: > Hello all, again. Instead of revising like I'm meant to be, I've been > delving into a bit of Python and I've come up with this code: Here's a simpler example that gives similar results: $ py -3.3 Python 3.3.2 (v3.3.2:d047928ae3f6, May 16 2013, 00:03:43) [MSC v.1600 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> def broken(): ... try: ... broken() ... except RuntimeError: ... broken() ... >>> broken() Fatal Python error: Cannot recover from stack overflow. Current thread 0x058c: File "", line 3 in broken File "", line 3 in broken ... Under Python 2.7.5 it just goes into an infinite loop. Under Python 3.2.5 and 3.3.2 it crashes the interpreter as shown above. What the broken() function is doing is totally stupid: responding to a recursion error with more recursion. However this may indicate or be considered a bug in the 3.x interpreter. Oscar -- http://mail.python.org/mailman/listinfo/python-list
Re: Fatal Python error
On 05/29/2013 08:45 AM, Oscar Benjamin wrote: On 29 May 2013 12:48, Joshua Landau wrote: Hello all, again. Instead of revising like I'm meant to be, I've been delving into a bit of Python and I've come up with this code: Here's a simpler example that gives similar results: $ py -3.3 Python 3.3.2 (v3.3.2:d047928ae3f6, May 16 2013, 00:03:43) [MSC v.1600 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. def broken(): ... try: ... broken() ... except RuntimeError: ... broken() ... broken() Fatal Python error: Cannot recover from stack overflow. Current thread 0x058c: File "", line 3 in broken File "", line 3 in broken ... Under Python 2.7.5 it just goes into an infinite loop. Under Python 3.2.5 and 3.3.2 it crashes the interpreter as shown above. What the broken() function is doing is totally stupid: responding to a recursion error with more recursion. However this may indicate or be considered a bug in the 3.x interpreter. Oscar More likely a bug in the 2.x interpreter. Once inside an exception handler, that frame must be held somehow. If not on the stack, then in some separate list. So the logic will presumably fill memory, it just may take longer on 2.x . Joshua: Avoid doing anything complex inside an exception handler. If nothing else, the exception frame is huge. I probably would have spotted it except for the indentation problem triggered by html. The top level code following your function didn't have any loops, so it wasn't a problem. Can anyone help Joshua put his gmail into text mode? -- DaveA -- http://mail.python.org/mailman/listinfo/python-list
Re: Fatal Python error
On 29 May 2013 13:30, Marcel Rodrigues wrote: > > I just tried your code with similar results: it does nothing on PyPy 2.0.0-beta2 and Python 2.7.4. But on Python 3.3.1 it caused core dump. > It's a little weird but so is the code. You have defined a function that calls itself unconditionally. This will cause a stack overflow, which is a RuntimeError. The weirdness of the code is simply as I've taken all the logic and conditionality away, since it was irrelevant. Why, though, does removing any one element make it fail properly? That's what's confusing, largely. > > Since you are handling this very exception with a pass statement, we would expect that no error occurs. But the fatal error message seems pretty informative at this point: "Cannot recover from stack overflow.". > > One thing to note is that while it's reasonable to handle exceptions that happens at the level of your Python code, like a ValueError, it's not so reasonable to try to handle something that may disturb the interpreter itself in a lower level, like a stack overflow (I think that the stack used by your code is the same stack used by the interpreter code, but I'm not sure). What is the expected response here then? Should I ever feel justified in catching a Stack Overflow error? This code was extracted from a file manager after much difficulty, but it should have been "caught" by a global try...except and not crashed the whole program immediately. I'd imagine that's a good enough reason to bring this up. Also; This works for the code: def loop(): thingwithproperty.prop loop() This does not: def loop(): try: thingwithproperty.prop except: pass loop() thingwithproperty.prop NEVER creates an error. (.prop is the new .property) -- http://mail.python.org/mailman/listinfo/python-list
Re: Fatal Python error
I think the issue here has little to do with classes/objects/properties. See, for example, the code posted by Oscar Benjamin. What that code is trying to do is similar to responding to an "Out Of Memory" error with something that might require more memory allocation. Even if we consider the Py3 behavior here a bug, that code is unreliable by design. It's an infinite loop at the best. 2013/5/29 Joshua Landau > On 29 May 2013 13:30, Marcel Rodrigues wrote: > > > > I just tried your code with similar results: it does nothing on PyPy > 2.0.0-beta2 and Python 2.7.4. But on Python 3.3.1 it caused core dump. > > It's a little weird but so is the code. You have defined a function that > calls itself unconditionally. This will cause a stack overflow, which is a > RuntimeError. > > > The weirdness of the code is simply as I've taken all the logic and > conditionality away, since it was irrelevant. Why, though, does removing > any one element make it fail properly? That's what's confusing, largely. > > > > > > Since you are handling this very exception with a pass statement, we > would expect that no error occurs. But the fatal error message seems pretty > informative at this point: "Cannot recover from stack overflow.". > > > > One thing to note is that while it's reasonable to handle exceptions > that happens at the level of your Python code, like a ValueError, it's not > so reasonable to try to handle something that may disturb the interpreter > itself in a lower level, like a stack overflow (I think that the stack used > by your code is the same stack used by the interpreter code, but I'm not > sure). > > > What is the expected response here then? Should I ever feel justified in > catching a Stack Overflow error? This code was extracted from a file > manager after much difficulty, but it should have been "caught" by a global > try...except and not crashed the whole program immediately. I'd imagine > that's a good enough reason to bring this up. > > > > Also; > This works for the code: > > def loop(): > thingwithproperty.prop > loop() > > This does not: > > def loop(): > try: > thingwithproperty.prop > except: > pass > loop() > > thingwithproperty.prop NEVER creates an error. > (.prop is the new .property) > -- http://mail.python.org/mailman/listinfo/python-list
Re: detect key conflict in a JSON file
In article , Jabba Laci wrote: > I have a growing JSON file that I edit manually and it might happen > that I repeat a key. If this happens, I would like to get notified. The real answer here is that JSON is probably not the best choice for large files that get hand-edited. For data that you intend to hand-edit a lot, YAML might be a better choice. > Currently the value of the second key silently overwrites the value of > the first. Yeah, that's what I would expect. http://www.json.org/ is mute on the question of what to do with duplicate keys, but I would be quite surprised to discover any implementation which behaved differently. > Do you know about a command line JSON validator? All JSON implementations validate their input. You are assuming that having duplicate keys is "invalid". I would think it falls more into the category of "undefined behavior". -- http://mail.python.org/mailman/listinfo/python-list
Re: detect key conflict in a JSON file
> The real answer here is that JSON is probably not the best choice for > large files that get hand-edited. For data that you intend to hand-edit > a lot, YAML might be a better choice. > >> Currently the value of the second key silently overwrites the value of >> the first. Thanks but how would it be different with YAML? Can YAML check duplicate keys? How to process (read) YAML files in Python? Can you give me some hints how to get started? All I need is read it in and create a dictionary of it. Thanks, Laszlo -- http://mail.python.org/mailman/listinfo/python-list
Re: Fatal Python error
On 29 May 2013 14:02, Dave Angel wrote: > On 05/29/2013 08:45 AM, Oscar Benjamin wrote: > Joshua: Avoid doing anything complex inside an exception handler. Unfortunately, Ranger (the file manager in question) wraps a lot of stuff in one big exception handler. Hence there isn't much choice. The original wasn't actually in an infinite recursion, too, but just a recursion over a large directory. Is there a reason that Python 3 can't be made to work like Python 2 and PyPy, and -if not- should it? The catchable fail would be much nicer than just bombing the program. In the meantime the algorithm should just be reworked, but it seems like a larger step than should be needed. If nothing else, the exception frame is huge. I probably would have > spotted it except for the indentation problem triggered by html. The top > level code following your function didn't have any loops, so it wasn't a > problem. > > Can anyone help Joshua put his gmail into text mode? I've found a new option. As a test, here's a simplified version without the property: def loop(): try: (lambda: None)() except: pass loop() try: loop() except RuntimeError: pass which is pretty much Oscar Benjamin's, but less stupid. -- http://mail.python.org/mailman/listinfo/python-list
Re: Output is not coming with defined color
On May 29, 5:11 pm, Fábio Santos wrote:
> On 29 May 2013 12:25, "Avnesh Shakya" wrote:
>
>
>
>
>
>
>
>
>
> > hi,
> > I am trying to display my output with different colour on terminal,
> but it's
> > coming with that colour code.
> > Please help me how is it possible?
>
> > my code is -
> > from fabric.colors import green, red, blue
> > def colorr():
> > a = red('This is red')
> > b = green('This is green')
> > c = blue('This is blue')
> > d = {a, b, c}
> > print d
> > colorr()
>
> > output -
> > set(['\x1b[32mThis is green\x1b[0m', '\x1b[34mThis is blue\x1b[0m',
>
> '\x1b[31mThis is red\x1b[0m'])
>
>
>
> > Thanks
>
> You are printing the {a, b, c} set. That ends up printing the repr of all
> of its contents. The repr breaks the desired output. Try to just
>
> print a, b, c
Or
for x in d: print x
should work
--
http://mail.python.org/mailman/listinfo/python-list
Re: detect key conflict in a JSON file
Hello,
On Wed, May 29, 2013 at 03:41:50PM +0200, Jabba Laci wrote:
> > The real answer here is that JSON is probably not the best choice for
> > large files that get hand-edited. For data that you intend to hand-edit
> > a lot, YAML might be a better choice.
> >
> >> Currently the value of the second key silently overwrites the value of
> >> the first.
>
> Thanks but how would it be different with YAML? Can YAML check duplicate keys?
no, I think it can't,
I'm using yaml a few months ago, as I noticed, the last key
prevail.
> How to process (read) YAML files in Python? Can you give me some hints
> how to get started? All I need is read it in and create a dictionary
> of it.
import yaml
struct = yaml.load(file("yamlfile.yml" 'r'))
and struct will be a Python dictionary,
As I know, yaml modul is not part of standard Python library, but
most Linux systems has package, eg. Debian/Ubuntu has a
"python-yaml".
Cheers:
a.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Short-circuit Logic
On Tuesday, May 28, 2013 3:48:17 PM UTC+2, Steven D'Aprano wrote: > On Mon, 27 May 2013 13:11:28 -0700, Ahmed Abdulshafy wrote: > > > > > That may be true for integers, but for floats, testing for equality is > > > not always precise > > > > Incorrect. Testing for equality is always precise, and exact. The problem > > is not the *equality test*, but that you don't always have the number > > that you think you have. The problem lies elsewhere, not equality! > > > Steven Well, this is taken from my python shell> >>> 0.33455857352426283 == 0.33455857352426282 True Anyway, man, those were not my words anyway, most programming books I've read state so. Here's an excerpt from the Python book, I'm currently reading> ">>> 0.0, 5.4, -2.5, 8.9e-4 (0.0, 5.4004, -2.5, 0.00088995) The inexactness is not a problem specific to Python—all programming languages have this problem with floating-point numbers." -- http://mail.python.org/mailman/listinfo/python-list
Re: Short-circuit Logic
On Thu, May 30, 2013 at 12:27 AM, Ahmed Abdulshafy wrote: > Well, this is taken from my python shell> > 0.33455857352426283 == 0.33455857352426282 > True >>> 0.33455857352426283,0.33455857352426282 (0.3345585735242628, 0.3345585735242628) They're not representably different. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Short-circuit Logic
On May 29, 7:27 pm, Ahmed Abdulshafy wrote: > On Tuesday, May 28, 2013 3:48:17 PM UTC+2, Steven D'Aprano wrote: > > On Mon, 27 May 2013 13:11:28 -0700, Ahmed Abdulshafy wrote: > > > > That may be true for integers, but for floats, testing for equality is > > > > not always precise > > > Incorrect. Testing for equality is always precise, and exact. The problem > > > is not the *equality test*, but that you don't always have the number > > > that you think you have. The problem lies elsewhere, not equality! > > > Steven > > Well, this is taken from my python shell> > > >>> 0.33455857352426283 == 0.33455857352426282 > > True > > Anyway, man, those were not my words anyway, most programming books I've read > state so. Here's an excerpt from the Python book, I'm currently reading> > > ">>> 0.0, 5.4, -2.5, 8.9e-4 > (0.0, 5.4004, -2.5, 0.00088995) > > The inexactness is not a problem specific to Python—all programming languages > have this problem with floating-point numbers." 0.0 == 0.0 implies 5.4 == 5.4 is not a true statement is what (I think) Steven is saying. 0 (or if you prefer 0.0) is special and is treated specially. Naturally if you reach (nearabout) 0.0 by some numerical process thats another matter... -- http://mail.python.org/mailman/listinfo/python-list
Re: detect key conflict in a JSON file
On May 29, 6:41 pm, Jabba Laci wrote: > > The real answer here is that JSON is probably not the best choice for > > large files that get hand-edited. For data that you intend to hand-edit > > a lot, YAML might be a better choice. > > >> Currently the value of the second key silently overwrites the value of > >> the first. > > Thanks but how would it be different with YAML? Can YAML check duplicate keys? > > How to process (read) YAML files in Python? Can you give me some hints > how to get started? All I need is read it in and create a dictionary > of it. > > Thanks, > > Laszlo There seems to be a suggested patch for duplicate-detection here http://pyyaml.org/ticket/128 -- http://mail.python.org/mailman/listinfo/python-list
Re: Python #ifdef
On 2013-05-28, Carlos Nepomuceno wrote: > How do you have "invalid@invalid.invalid" instead of your email address? I have this in my .slrnrc: set hostname "invalid.invalid" set username "grant" set realname "Grant Edwards" I'm not sure why it doesn't show up as grant@invalid.invalid -- I think it used to. Since I'm this as a Usenet news group using the slrn newsreader program, there's no need to make my email address visible in the message headers in a usable form. I originally did this long ago (probably 20 years) to avoid spam. I'm pretty sure that it's all in vain these days, and the spam filters at Google are what's keeping me from drowning. -- Grant Edwards grant.b.edwardsYow! Gee, I feel kind of at LIGHT in the head now, gmail.comknowing I can't make my satellite dish PAYMENTS! -- http://mail.python.org/mailman/listinfo/python-list
Re: Fatal Python error
On May 29, 5:43 pm, Joshua Landau wrote: > On 29 May 2013 13:25, Dave Angel wrote: > > > On 05/29/2013 07:48 AM, Joshua Landau wrote: > > >> Hello all, again. Instead of revising like I'm meant to be, I've been > >> delving into a bit of Python and I've come up with this code: > > > To start with, please post in text mode. By using html, you've completely > > messed up any indentation you presumably had. > > Appologies, I use GMail and I don't know how to force text-only In gmail New interface: There should be a down arrow next to the trash-can right bottom of posting-screen Click the down-arrow. YOu should see a 'choose text-only' option Old interface: When posting a new message, right at the top next to all the formatting icons is a text-only link -- http://mail.python.org/mailman/listinfo/python-list
Re: Python #ifdef
On 2013-05-29, Dan Stromberg wrote: > And in case you still want a preprocessor for Python (you likely don't need > one this time), here's an example of doing this using the venerable m4: > https://pypi.python.org/pypi/red-black-tree-mod . Note the many comments > added to keep line numbers consistent. I was wondering whether or not to mention m4. Since m4 is (in my mind) inextricably linked to RATFOR and sendmail config files I try to avoid thinking about it lest the flashbacks start again... -- Grant Edwards grant.b.edwardsYow! Hmmm ... a CRIPPLED at ACCOUNTANT with a FALAFEL gmail.comsandwich is HIT by a TROLLEY-CAR ... -- http://mail.python.org/mailman/listinfo/python-list
Re: Python #ifdef
On Thu, May 30, 2013 at 12:55 AM, Grant Edwards wrote: > On 2013-05-29, Dan Stromberg wrote: > >> And in case you still want a preprocessor for Python (you likely don't need >> one this time), here's an example of doing this using the venerable m4: >> https://pypi.python.org/pypi/red-black-tree-mod . Note the many comments >> added to keep line numbers consistent. > > I was wondering whether or not to mention m4. Since m4 is (in my > mind) inextricably linked to RATFOR and sendmail config files I try > to avoid thinking about it lest the flashbacks start again... It's not a bad tool. I used it as a sort of PHP preprocessor, because requirements at work had me wanting to have a source file defining a PHP class and having an autogenerated section in the middle of that class. PHP's 'include' directive doesn't work for that. Of course, had we been using a better language, that wouldn't have been an issue (and it stopped being an issue when we improved the design and stopped using that class system, too, though I retained the makefile directives about building .php.m4 -> .php files). But still, GNU M4 is a decent piece of technology. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Fatal Python error
On 29 May 2013 14:02, Dave Angel wrote: > On 05/29/2013 08:45 AM, Oscar Benjamin wrote: > > More likely a bug in the 2.x interpreter. Once inside an exception handler, > that frame must be held somehow. If not on the stack, then in some separate > list. So the logic will presumably fill memory, it just may take longer on > 2.x . I'm not so sure. The following gives the same behaviour in 2.7, 3.2 and 3.3: $ cat tmp.py def loop(): loop() loop() $ py -3.2 tmp.py Traceback (most recent call last): File "tmp.py", line 4, in loop() File "tmp.py", line 2, in loop loop() File "tmp.py", line 2, in loop loop() File "tmp.py", line 2, in loop loop() File "tmp.py", line 2, in loop ... However the following leads to a RuntimeError in 2.7 but different stack overflow errors in 3.2 and 3.3: $ cat tmp.py def loop(): try: (lambda: None)() except RuntimeError: pass loop() loop() $ py -2.7 tmp.py Traceback (most recent call last): File "tmp.py", line 8, in loop() File "tmp.py", line 6, in loop loop() File "tmp.py", line 6, in loop loop() File "tmp.py", line 6, in loop loop() File "tmp.py", line 6, in loop ... RuntimeError: maximum recursion depth exceeded $ py -3.2 tmp.py Fatal Python error: Cannot recover from stack overflow. This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. $ py -3.3 tmp.py Fatal Python error: Cannot recover from stack overflow. Current thread 0x05c4: File "tmp.py", line 3 in loop File "tmp.py", line 6 in loop File "tmp.py", line 6 in loop File "tmp.py", line 6 in loop File "tmp.py", line 6 in loop File "tmp.py", line 6 in loop File "tmp.py", line 6 in loop ... I would expect this to give "RuntimeError: maximum recursion depth exceeded" in all three cases. Oscar -- http://mail.python.org/mailman/listinfo/python-list
Re: detect key conflict in a JSON file
On May 29, 2013, at 9:41 AM, Jabba Laci wrote: >> The real answer here is that JSON is probably not the best choice for >> large files that get hand-edited. For data that you intend to hand-edit >> a lot, YAML might be a better choice. >> >>> Currently the value of the second key silently overwrites the value of >>> the first. > > Thanks but how would it be different with YAML? Can YAML check duplicate keys? Oh, I didn't mean to imply that. I was just pointing out that in general, YAML is more friendly for hand-editing than JSON. They both have the same GIGO issue. > How to process (read) YAML files in Python? Take a look at http://pyyaml.org/ --- Roy Smith r...@panix.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Python #ifdef
On 2013-05-29, Chris Angelico wrote: > On Thu, May 30, 2013 at 12:55 AM, Grant Edwards > wrote: >> On 2013-05-29, Dan Stromberg wrote: >> >>> And in case you still want a preprocessor for Python (you likely don't need >>> one this time), here's an example of doing this using the venerable m4: >>> https://pypi.python.org/pypi/red-black-tree-mod . Note the many comments >>> added to keep line numbers consistent. >> >> I was wondering whether or not to mention m4. Since m4 is (in my >> mind) inextricably linked to RATFOR and sendmail config files I try >> to avoid thinking about it lest the flashbacks start again... > > It's not a bad tool. I used it as a sort of PHP preprocessor, > [...] > But still, GNU M4 is a decent piece of technology. I didn't mean to disparage m4 -- it always seemed well thought out and useful. It just happens to be associated with unpleasant things for me. [And it didn't really seem like a good option for the OP's problem.] Still, if one really did want a preprocessor for Python programs, m4 would be the first thing I'd look at. -- Grant Edwards grant.b.edwardsYow! I wonder if I ought at to tell them about my gmail.comPREVIOUS LIFE as a COMPLETE STRANGER? -- http://mail.python.org/mailman/listinfo/python-list
Re: detect key conflict in a JSON file
On Wed, May 29, 2013 at 4:16 AM, Jabba Laci wrote:
> Hi,
>
> How can you detect if a key is duplicated in a JSON file? Example:
>
> {
> "something": [...],
> ...
> "something": [...]
> }
>
> I have a growing JSON file that I edit manually and it might happen
> that I repeat a key. If this happens, I would like to get notified.
> Currently the value of the second key silently overwrites the value of
> the first.
You can pass an appropriate object_pairs_hook function to json.load():
http://docs.python.org/2/library/json.html#repeated-names-within-an-object
http://docs.python.org/2/library/json.html#json.load
Cheers,
Chris
--
http://mail.python.org/mailman/listinfo/python-list
Re: Short-circuit Logic
On Wed, May 29, 2013 at 8:33 AM, rusi wrote: > 0.0 == 0.0 implies 5.4 == 5.4 > is not a true statement is what (I think) Steven is saying. > 0 (or if you prefer 0.0) is special and is treated specially. It has nothing to do with 0 being special. A floating point number will always equal itself (except for nan, which is even more special), and in particular 5.4 == 5.4. But if you have two different calculations that produce 0, or two different calculations that produce 5.4, you might actually get two different numbers that approximate 0 or 5.4 thanks to rounding error. If you then compare those two ever-so-slightly different numbers, you will find them unequal. -- http://mail.python.org/mailman/listinfo/python-list
Re: Piping processes works with 'shell = True' but not otherwise.
On Sun, May 26, 2013 at 4:58 PM, Luca Cerone wrote: > Hi Chris, first of all thanks for the help. Unfortunately I can't provide the > actual commands because are tools that are not publicly available. > I think I get the tokenization right, though.. the problem is not that the > programs don't run.. it is just that sometimes I get that error.. > > Just to be clear I run the process like: > > p = subprocess.Popen(['program1','--opt1','val1',...'--optn','valn'], ... the > rest) > > which I think is the right way to pass arguments (it works fine for other > commands).. >> You may also want to provide /dev/null as p1's stdin, out of an abundance of >> caution. > > I tried to redirect the output to /dev/null using the Popen argument: > 'stdin = os.path.devnull' (having imported os of course).. > But this seemed to cause even more troubles... That's because stdin/stdout/stderr take file descriptors or file objects, not path strings. Cheers, Chris -- http://mail.python.org/mailman/listinfo/python-list
Re: Piping processes works with 'shell = True' but not otherwise.
Am 27.05.2013 02:14 schrieb Carlos Nepomuceno: pipes usually consumes disk storage at '/tmp'. Good that my pipes don't know about that. Why should that happen? Thomas -- http://mail.python.org/mailman/listinfo/python-list
Getting a callable for any value?
Is there anything like this in the standard library? class AnyFactory(object): def __init__(self, anything): self.product = anything def __call__(self): return self.product def __repr__(self): return "%s.%s(%r)" % (self.__class__.__module__, self.__class__.__name__, self.product) my use case is: collections.defaultdict(AnyFactory(collections.defaultdict(AnyFactory(None And I think lambda expressions are not preferable... I found itertools.repeat(anything).next and functools.partial(copy.copy, anything) but both of those don't repr well... and are confusing... I think AnyFactory is the most readable, but is confusing if the reader doesn't know what it is, am I missing a standard implementation of this? -- http://mail.python.org/mailman/listinfo/python-list
Re: Getting a callable for any value?
On 05/29/2013 06:46 PM, Croepha wrote: Is there anything like this in the standard library? class AnyFactory(object): def __init__(self, anything): self.product = anything def __call__(self): return self.product def __repr__(self): return "%s.%s(%r)" % (self.__class__.__module__, self.__class__.__name__, self.product) my use case is: collections.defaultdict(AnyFactory(collections.defaultdict(AnyFactory(None I think I would scratch my head for a good half an hour if I see a string like this, so I hope there isn't anything in the standard library to do that :D -- http://mail.python.org/mailman/listinfo/python-list
Re: Getting a callable for any value?
On 5/29/2013 1:46 PM, Croepha wrote:
Is there anything like this in the standard library?
class AnyFactory(object):
def __init__(self, anything):
self.product = anything
def __call__(self):
return self.product
def __repr__(self):
return "%s.%s(%r)" % (self.__class__.__module__,
self.__class__.__name__, self.product)
my use case is:
collections.defaultdict(AnyFactory(collections.defaultdict(AnyFactory(None
And I think lambda expressions are not preferable...
It's not clear to me that this does what you want. Won't your
defaultdict use the same defaultdict for all of its default values? This
is hard to describe in English but:
d =
collections.defaultdict(AnyFactory(collections.defaultdict(AnyFactory(None
d[1][1] = 1
d[2][2] = 2
print d[1]
#-> defaultdict(__main__.AnyFactory(None), {1: 1, 2: 2})
print d[1] is d[2]
#-> True
It might not be possible to get this right without lambdas:
d = collections.defaultdict(lambda: collections.defaultdict(lambda: None))
d[1][1] = 1
d[2][2] = 2
print d[1]
#-> defaultdict( at 0x02091D70>, {1: 1})
print d[1] is d[2]
#-> False
--Ned.
I found itertools.repeat(anything).next and
functools.partial(copy.copy, anything)
but both of those don't repr well... and are confusing...
I think AnyFactory is the most readable, but is confusing if the
reader doesn't know what it is, am I missing a standard implementation
of this?
--
http://mail.python.org/mailman/listinfo/python-list
Re: Getting a callable for any value?
On 29 May 2013 18:51, "Croepha" wrote: > > Is there anything like this in the standard library? > > class AnyFactory(object): > def __init__(self, anything): > self.product = anything > def __call__(self): > return self.product > def __repr__(self): > return "%s.%s(%r)" % (self.__class__.__module__, self.__class__.__name__, self.product) > > my use case is: collections.defaultdict(AnyFactory(collections.defaultdict(AnyFactory(None > > And I think lambda expressions are not preferable... > > I found itertools.repeat(anything).next and functools.partial(copy.copy, anything) > > but both of those don't repr well... and are confusing... > > I think AnyFactory is the most readable, but is confusing if the reader doesn't know what it is, am I missing a standard implementation of this? > > Are you sure you don't want to use a lambda expression? They are pretty pythonic. none_factory = lambda: None defaultdict_none_factory = lambda: defaultdict(none_factory) collections.defaultdict(defaultdict_none_factory) Just what are you trying to do? -- http://mail.python.org/mailman/listinfo/python-list
Re: Getting a callable for any value?
On Wed, May 29, 2013 at 11:46 AM, Croepha wrote: > Is there anything like this in the standard library? > > class AnyFactory(object): > def __init__(self, anything): > self.product = anything > def __call__(self): > return self.product > def __repr__(self): > return "%s.%s(%r)" % (self.__class__.__module__, self.__class__.__name__, > self.product) In other words, the function (lambda: x) with a repr that tells you what x is? Not that I'm aware of, but you could just do something like: def return_x(): return x And then the repr will include the name "return_x", which will give you a hint as to what it does. Also, "AnyFactory" is a misleading name because the class above is not a factory. > my use case is: > collections.defaultdict(AnyFactory(collections.defaultdict(AnyFactory(None > > And I think lambda expressions are not preferable... What you have above is actually buggy. Your "AnyFactory" will always return the *same instance* of the passed in defaultdict, which means that no matter what key you give to the outer defaultdict, you always get the same inner defaultdict. Anyway, I think it's clearer with lambdas: defaultdict(lambda: defaultdict(lambda: None)) But I can see your point about the repr. You could do something like this: class NoneDefaultDict(dict): def __missing__(self, key): return None def __repr__(self): return "NoneDefaultDict(%s)" % super(NoneDefaultDict, self).__repr__() some_dict = defaultdict(NoneDefaultDict) -- http://mail.python.org/mailman/listinfo/python-list
The state of pySerial
Hi, all. pySerial is probably "the solution" for serial port programming. Physical serial port is dead on PC but USB-to-Serial give it a second life. Serial port stuff won't interest end users at all. But it is still used in the EE world and so on. Arduino uses it to upload programs. Sensors may use serial port to communicate with PC. GSM Modem also uses serial port to communicate with PC. Unforunately, pySerial project doesn't seem to have a good state. I find pySerial + Python 3.3 broken on my machine (Python 2.7 is OK) . There are unanswered outstanding bugs, PyPI page has 2.6 while SF homepage still gives 2.5. Any idea? -- http://mail.python.org/mailman/listinfo/python-list
Re: Getting a callable for any value?
On Wed, May 29, 2013 at 12:19 PM, Fábio Santos wrote: > Are you sure you don't want to use a lambda expression? They are pretty > pythonic. > > none_factory = lambda: None > defaultdict_none_factory = lambda: defaultdict(none_factory) > > collections.defaultdict(defaultdict_none_factory) Gah. If you're going to go to the trouble of assigning a name to the lambda, then just use a def statement: def none_factory: return None def defaultdict_none_factory: return defaultdict(none_factory) collections.defaultdict(defaultdict_none_factory) -- http://mail.python.org/mailman/listinfo/python-list
python b'...' notation
This notation displays hex values except when they are 'printable', in which case it displays that printable character. How do I get it to force hex for all bytes? Thanks, Steve -- http://mail.python.org/mailman/listinfo/python-list
Re: How clean/elegant is Python's syntax?
A bit more context. If visiting z.cn (Amazon China), one can see that there are plenty of new (published in 2010 or later) books on QBASIC, Visual Basic, Visual Foxpro. This is weird, if one want to do development legally these tools won't be a option for new programmers. However, I also like to know whether there are any technical arguments that Python is superior in the context of education. For pure procedural paradigm, I haven't seen much advantages of Python. Yes, Python has true OOP but I don't like this argument since I don't like Java-ism true OOP. Yes, Python has much more libraries. But it seems that Python is more useful and suitable in CLI and Web applications. People are still discussing whether to replace tkinter with wxPython or not. VB and VFP people are never bothered with such issue. -- http://mail.python.org/mailman/listinfo/python-list
How clean/elegant is Python's syntax?
Hi, list. I hope this is not a duplicate of older question. If so, drop me a link is enough. I've used Python here and there, just for the sweet libraries though. For the core language, I have mixed feeling. On one hand, I find that Python has some sweet feature that is quite useful. On the other hand, I often find Pyhton snippets around hard to understand. I admit that I never learned Python very formally; I've programmed in many other languages already. Code snippets in BASIC or Pascal seems quite obvious to understand (Unless I don't understand the algorithm) . Can someone inspire me? -- http://mail.python.org/mailman/listinfo/python-list
Re: How clean/elegant is Python's syntax?
On Thu, May 30, 2013 at 4:37 AM, Ma Xiaojun wrote: > Yes, Python has much more libraries. But it seems that Python is more > useful and suitable in CLI and Web applications. People are still > discussing whether to replace tkinter with wxPython or not. VB and VFP > people are never bothered with such issue. Let me put this debate in context by giving an analogous example. A while back, it was loudly proclaimed that it was far easier to write iPhone apps than Android ones, because Android apps had to worry about a variety of different screen resolutions/sizes, while iPhone ones could be certain of what they were going to get. But what this really meant was that writing for iPhone was equivalent to writing for "Android on phone model XYZ", and that you could, by targeting Android, also then make your app available on a bunch of other phone models by simply dealing with the differences. Python gives you a lot more choice than VB does. With Visual BASIC, if you don't like the windowing toolkit, tough. You don't have any alternative. With Python, you can pretend it's like VB by simply picking one toolkit and ignoring all the others; it'll be exactly the same. But the benefit is that, if you decide you want one of the others, it's relatively cheap to switch. That said, though, GUIs and databasing are two of the areas where I think Python's standard library could stand to be improved a bit. There are definitely some rough edges there. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: python b'...' notation
On Wed, May 29, 2013 at 12:33 PM, alcyon wrote:
> This notation displays hex values except when they are 'printable', in which
> case it displays that printable character. How do I get it to force hex for
> all bytes? Thanks, Steve
Is this what you want?
>>> ''.join('%02x' % x for x in b'hello world')
'68656c6c6f20776f726c64'
--
http://mail.python.org/mailman/listinfo/python-list
RE: Piping processes works with 'shell = True' but not otherwise.
> From: nutznetz-0c1b6768-bfa9-48d5-a470-7603bd3aa...@spamschutz.glglgl.de > Subject: Re: Piping processes works with 'shell = True' but not otherwise. > Date: Wed, 29 May 2013 19:39:40 +0200 > To: python-list@python.org > > Am 27.05.2013 02:14 schrieb Carlos Nepomuceno: >> pipes usually consumes disk storage at '/tmp'. > > Good that my pipes don't know about that. > > Why should that happen? > > > Thomas > -- > http://mail.python.org/mailman/listinfo/python-list Ooops! My mistake! We've been using 'tee' when in debugging mode and I though that would apply to this case. Nevermind! -- http://mail.python.org/mailman/listinfo/python-list
Re: The state of pySerial
On 2013-05-29, Ma Xiaojun wrote: > pySerial is probably "the solution" for serial port programming. > Physical serial port is dead on PC but USB-to-Serial give it a second > life. Serial port stuff won't interest end users at all. But it is > still used in the EE world and so on. Arduino uses it to upload > programs. Sensors may use serial port to communicate with PC. GSM > Modem also uses serial port to communicate with PC. > > Unforunately, pySerial project doesn't seem to have a good state. I > find pySerial + Python 3.3 broken on my machine (Python 2.7 is OK) . > There are unanswered outstanding bugs, PyPI page has 2.6 while SF > homepage still gives 2.5. > > Any idea? Volunteer as a maintainer and start fixing bugs? I use pyserial regularly, and the current version works fine for me, but I'm using Python 2.7. There are still too many libraries that don't support 3.x for me to consider using 3.x for real work. -- Grant Edwards grant.b.edwardsYow! They collapsed at ... like nuns in the gmail.comstreet ... they had no teen appeal! -- http://mail.python.org/mailman/listinfo/python-list
Re: The state of pySerial
On May 29, 2013, at 2:23 PM, Ma Xiaojun wrote: > Hi, all. > > pySerial is probably "the solution" for serial port programming. > Physical serial port is dead on PC but USB-to-Serial give it a second > life. Serial port stuff won't interest end users at all. But it is > still used in the EE world and so on. Arduino uses it to upload > programs. Sensors may use serial port to communicate with PC. GSM > Modem also uses serial port to communicate with PC. > > Unforunately, pySerial project doesn't seem to have a good state. I > find pySerial + Python 3.3 broken on my machine (Python 2.7 is OK) . > There are unanswered outstanding bugs, PyPI page has 2.6 while SF > homepage still gives 2.5. > > Any idea? > -- > http://mail.python.org/mailman/listinfo/python-list Let me add another vote/request for pySerial support. I've been using it with python 2.7 on OS-X, unaware that there wasn't a path forward to python 3.x. If an external sensor absolutely positively has to be readable, then RS-232 is the only way to go. USB interfaces can and do lock up if recovery from a power failure puts power on the external side before the computer has finished initializing the CPU side. RS-232, bless its primitive heart, could care less. Thanks, Bill -- http://mail.python.org/mailman/listinfo/python-list
Re: How clean/elegant is Python's syntax?
On Thu, 30 May 2013 04:54:44 +1000, Chris Angelico wrote: > GUIs and databasing are two of the areas where I > think Python's standard library could stand to be improved a bit. > There are definitely some rough edges there. Dunno what you mean about "standard library", but I'm very happy with wxPython and psycopg2 for GUIs and databasing respectively. -- http://mail.python.org/mailman/listinfo/python-list
Re: How clean/elegant is Python's syntax?
You might try http://wiki.python.org/moin/BeginnersGuide -- MarkJ Tacoma, Washington -- http://mail.python.org/mailman/listinfo/python-list
Re: The state of pySerial
On 5/29/2013 4:00 PM, William Ray Wing wrote: On May 29, 2013, at 2:23 PM, Ma Xiaojun wrote: Hi, all. pySerial is probably "the solution" for serial port programming. Physical serial port is dead on PC but USB-to-Serial give it a second life. Serial port stuff won't interest end users at all. But it is still used in the EE world and so on. Arduino uses it to upload programs. Sensors may use serial port to communicate with PC. GSM Modem also uses serial port to communicate with PC. Unforunately, pySerial project doesn't seem to have a good state. I find pySerial + Python 3.3 broken on my machine (Python 2.7 is OK) . There are unanswered outstanding bugs, PyPI page has 2.6 while SF homepage still gives 2.5. Any idea? -- http://mail.python.org/mailman/listinfo/python-list Let me add another vote/request for pySerial support. I've been using it with python 2.7 on OS-X, unaware that there wasn't a path forward to python 3.x. If an external sensor absolutely positively has to be readable, then RS-232 is the only way to go. USB interfaces can and do lock up if recovery from a power failure puts power on the external side before the computer has finished initializing the CPU side. RS-232, bless its primitive heart, could care less. Then 'someone' should ask the author his intentions and offer to help or take over. I did some RS-232 interfacing in the 1980s, and once past the fiddly start/stop/parity bit, baud rate, and wiring issues, I had a program run connected to multiple machines for years with no more interface problems. Terry -- http://mail.python.org/mailman/listinfo/python-list
Re: The state of pySerial
On 5/29/2013 3:47 PM, Grant Edwards wrote: On 2013-05-29, Ma Xiaojun wrote: pySerial is probably "the solution" for serial port programming. Physical serial port is dead on PC but USB-to-Serial give it a second life. Serial port stuff won't interest end users at all. But it is still used in the EE world and so on. Arduino uses it to upload programs. Sensors may use serial port to communicate with PC. GSM Modem also uses serial port to communicate with PC. Unforunately, pySerial project doesn't seem to have a good state. I find pySerial + Python 3.3 broken on my machine (Python 2.7 is OK) . There are unanswered outstanding bugs, PyPI page has 2.6 while SF homepage still gives 2.5. Any idea? Volunteer as a maintainer and start fixing bugs? It seems to be getting around 200 downloands a day. Quite worth someone supporting it. I use pyserial regularly, and the current version works fine for me, but I'm using Python 2.7. There are still too many libraries that don't support 3.x for me to consider using 3.x for real work. The only download is a .exe. It it just the executable binary or is that a zip unpacker with source? -- http://mail.python.org/mailman/listinfo/python-list
Re: How clean/elegant is Python's syntax?
On 30May2013 02:13, Ma Xiaojun wrote: | For the core language, I have mixed feeling. On one hand, I find that | Python has some sweet feature that is quite useful. On the other hand, | I often find Pyhton snippets around hard to understand. I think you will find that is lack of practice. I find Python far far easier to read, even in snippet form. BUT, for years I found it obtuse because I hadn't learnt it. Now that I have, I rarely want to use other things (if Python is apt; often but not always). | I admit that I | never learned Python very formally; I've programmed in many other | languages already. Me too. Use it some more. | Code snippets in BASIC or Pascal seems quite obvious to understand | (Unless I don't understand the algorithm) . Code in BASIC is generally lower level than python; it is less expressive. Because of this, it will be more obvious in terms of being more direct. But it will be less expressive because you will often need more BASIC to do something than you would with Python. So python is usually more succinct, and therefore more more expressive: a shorter but very readable way to do the same thing. Comparison: your English is excellent. Presuming from context that you're in China, many of your compatriots do not speak fluent English (and why should they?) For those speaking English as a second language there are difficulties; English grammar I gather is very different, and it has a fine suite of irregular forms. (Let me say up front that I do not speak Chinese at all.) Anyway, would you rather converse with someone fluent, or not? I would expect you would far rather deal with a fluent English speaker or a fluent Chinese speaker than a speaker using English badly. Python code is a lot like written English. BASIC is like badly written English. Cheers, -- Cameron Simpson Helicopters are considerably more expensive [than fixed wing aircraft], which is only right because they don't actually fly, but just beat the air into submission.- Paul Tomblin -- http://mail.python.org/mailman/listinfo/python-list
Re: python b'...' notation
On 29May2013 13:14, Ian Kelly wrote:
| On Wed, May 29, 2013 at 12:33 PM, alcyon wrote:
| > This notation displays hex values except when they are 'printable', in
which case it displays that printable character. How do I get it to force hex
for all bytes? Thanks, Steve
|
| Is this what you want?
|
| >>> ''.join('%02x' % x for x in b'hello world')
| '68656c6c6f20776f726c64'
Not to forget binascii.hexlify.
--
Cameron Simpson
Every particle continues in its state of rest or uniform motion in a straight
line except insofar as it doesn't. - Sir Arther Eddington
--
http://mail.python.org/mailman/listinfo/python-list
Re: The state of pySerial
On 29/05/2013 22:38, Terry Jan Reedy wrote: On 5/29/2013 4:00 PM, William Ray Wing wrote: On May 29, 2013, at 2:23 PM, Ma Xiaojun wrote: Hi, all. pySerial is probably "the solution" for serial port programming. Physical serial port is dead on PC but USB-to-Serial give it a second life. Serial port stuff won't interest end users at all. But it is still used in the EE world and so on. Arduino uses it to upload programs. Sensors may use serial port to communicate with PC. GSM Modem also uses serial port to communicate with PC. Unforunately, pySerial project doesn't seem to have a good state. I find pySerial + Python 3.3 broken on my machine (Python 2.7 is OK) . There are unanswered outstanding bugs, PyPI page has 2.6 while SF homepage still gives 2.5. Any idea? -- http://mail.python.org/mailman/listinfo/python-list Let me add another vote/request for pySerial support. I've been using it with python 2.7 on OS-X, unaware that there wasn't a path forward to python 3.x. If an external sensor absolutely positively has to be readable, then RS-232 is the only way to go. USB interfaces can and do lock up if recovery from a power failure puts power on the external side before the computer has finished initializing the CPU side. RS-232, bless its primitive heart, could care less. Then 'someone' should ask the author his intentions and offer to help or take over. This page: http://pyserial.sourceforge.net/pyserial.html#requirements says: "Python 2.3 or newer, including Python 3.x" I did some RS-232 interfacing in the 1980s, and once past the fiddly start/stop/parity bit, baud rate, and wiring issues, I had a program run connected to multiple machines for years with no more interface problems. -- http://mail.python.org/mailman/listinfo/python-list
Re: Piping processes works with 'shell = True' but not otherwise.
On 29May2013 19:39, Thomas Rachel wrote: | Am 27.05.2013 02:14 schrieb Carlos Nepomuceno: | >pipes usually consumes disk storage at '/tmp'. | | Good that my pipes don't know about that. | Why should that happen? It probably doesn't on anything modern. On V7 UNIX at least there was a kernel notion of the "pipe fs", where pipe storage existed; usually /tmp; using small real (but unnamed) files is an easy way to implement them, especially on systems where RAM is very small and without a paging VM - for example, V7 UNIX ran on PDP-11s amongst other things. And files need a filesystem. But even then pipes are still small fixed length buffers; they don't grow without bound as you might have inferred from the quoted statement. Cheers, -- Cameron Simpson ERROR 155 - You can't do that. - Data General S200 Fortran error code list -- http://mail.python.org/mailman/listinfo/python-list
Re: Short-circuit Logic
On 05/29/2013 12:50 PM, Ian Kelly wrote: On Wed, May 29, 2013 at 8:33 AM, rusi wrote: 0.0 == 0.0 implies 5.4 == 5.4 is not a true statement is what (I think) Steven is saying. 0 (or if you prefer 0.0) is special and is treated specially. It has nothing to do with 0 being special. A floating point number will always equal itself (except for nan, which is even more special), and in particular 5.4 == 5.4. But if you have two different calculations that produce 0, or two different calculations that produce 5.4, you might actually get two different numbers that approximate 0 or 5.4 thanks to rounding error. If you then compare those two ever-so-slightly different numbers, you will find them unequal. Rounding error is just one of the problems. Usually less obvious is quantization error. If you represent a floating number in decimal, but you're using a binary floating point representation, it just might change. Another error is roundoff error. Even in a pure decimal system of (say) 40 digits, I could type in a 42 digit number and it would get quantized. So just because two 42 digit numbers are different doesn't imply that the 40 digit internal format would be. -- DaveA -- http://mail.python.org/mailman/listinfo/python-list
Re: How clean/elegant is Python's syntax?
On Wed, May 29, 2013 at 11:13 AM, Ma Xiaojun wrote: > Hi, list. > > For the core language, I have mixed feeling. On one hand, I find that > Python has some sweet feature that is quite useful. On the other hand, > I often find Pyhton snippets around hard to understand. I admit that I > never learned Python very formally; I've programmed in many other > languages already. > > Code snippets in BASIC or Pascal seems quite obvious to understand > (Unless I don't understand the algorithm) . > I'm finding it kind of hard to imagine not finding Python's syntax and semantics pretty graceful. About the only thing I don't like is: var = 1, That binds var to a tuple (singleton) value, instead of 1. Oh, and method decorators seem much more complex than they should've been. But on the whole, python is a pretty beautiful language. It's not just another rehash of Pascal though; if that's what you want you might be better off looking elsewhere. -- http://mail.python.org/mailman/listinfo/python-list
Re: How clean/elegant is Python's syntax?
On Thu, May 30, 2013 at 8:24 AM, Dan Stromberg wrote: > I'm finding it kind of hard to imagine not finding Python's syntax and > semantics pretty graceful. > > About the only thing I don't like is: > >var = 1, > > That binds var to a tuple (singleton) value, instead of 1. > > Oh, and method decorators seem much more complex than they should've been. Yes, you touched something. IMHO, Python has far more built-in features so it looks at least complicated from time to time. For example, some people use "generating 9x9 multiplication table" as an programming exercise. What interest me is a one liner: print '\n'.join(['\t'.join(['%d*%d=%d' % (j,i,i*j) for i in range(1,10)]) for j in range(1,10)]) I don't like code like this. But Python at least allow such practise. > But on the whole, python is a pretty beautiful language. It's not just > another rehash of Pascal though; if that's what you want you might be better > off looking elsewhere. That's a fair point. -- http://mail.python.org/mailman/listinfo/python-list
Re: The state of pySerial
I've already mailed the author, waiting for reply. For Windows people, downloading a exe get you pySerial 2.5, which list_ports and miniterm feature seems not included. To use 2.6, download the tar.gz and use standard "setup.py install" to install it (assume you have .py associated) . There is no C compiling involved in the installation process. For whether Python 3.3 is supported or not. I observed something like: http://paste.ubuntu.com/5715275/ . miniterm works for Python 3.3 at this time. -- http://mail.python.org/mailman/listinfo/python-list
Re: Short-circuit Logic
On Wed, 29 May 2013 10:50:47 -0600, Ian Kelly wrote: > On Wed, May 29, 2013 at 8:33 AM, rusi wrote: >> 0.0 == 0.0 implies 5.4 == 5.4 >> is not a true statement is what (I think) Steven is saying. 0 (or if >> you prefer 0.0) is special and is treated specially. > > It has nothing to do with 0 being special. A floating point number will > always equal itself (except for nan, which is even more special), and in > particular 5.4 == 5.4. But if you have two different calculations that > produce 0, or two different calculations that produce 5.4, you might > actually get two different numbers that approximate 0 or 5.4 thanks to > rounding error. If you then compare those two ever-so-slightly > different numbers, you will find them unequal. EXACTLY! The problem does not lie with the *equality operator*, it lies with the calculations. And that is an intractable problem -- in general, floating point is *hard*. So the problem occurs when we start with a perfectly good statement of the facts: "If you naively test the results of a calculation for equality without understanding what you are doing, you will often get surprising results" which then turns into a general heuristic that is often, but not always, reasonable: "In general, you should test for floating point *approximate* equality, in some appropriate sense, rather than exact equality" which then gets mangled to: "Never test floating point numbers for equality" and then implemented badly by people who have no clue what they are doing and have misunderstood the nature of the problem, leading to either: * de facto exact equality testing, only slower and with the *illusion* of avoiding equality, e.g. "abs(x-y) < sys.float_info.epsilon" is just a long and slow way of saying "x == y" when both numbers are sufficiently large; * incorrectly accepting non-equal numbers as "equal" just because they happen to be "close". The problem is that there is *no one right answer*, except "have everyone become an expert in floating point, then judge every case on its merits", which will never happen. But if nothing else, I wish that we can get past the rank superstition that you should "never" test floats for equality. That would be a step forward. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: How clean/elegant is Python's syntax?
On May 30, 6:14 am, Ma Xiaojun wrote: > What interest me is a one liner: > print '\n'.join(['\t'.join(['%d*%d=%d' % (j,i,i*j) for i in > range(1,10)]) for j in range(1,10)]) Ha,Ha! The join method is one of the (for me) ugly features of python. You can sweep it under the carpet with a one-line join function and then write clean and pretty code: #joinwith def joinw(l,sep): return sep.join(l) def mktable(m,n): return [[(j,i,i*j) for i in range(1,m+1)] for j in range(1,n+1)] def prettyrow(r): return joinw(['%d*%d=%d' % ele for ele in r],'\t') def prettytable(t): return joinw([prettyrow(r) for r in t],'\n') > I don't like code like this. But Python at least allow such practise. Are you saying VB etc disallow dirty code?? Dirty code is always possible in all languages. Of course the shape and size and smell of the dirt will differ -- http://mail.python.org/mailman/listinfo/python-list
Re: detect key conflict in a JSON file
On Wed, 29 May 2013 11:20:59 -0400, Roy Smith wrote: >> How to process (read) YAML files in Python? > > Take a look at http://pyyaml.org/ Beware that pyaml suffers from the same issue as pickle, namely that it can execute arbitrary code when reading untrusted data. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: detect key conflict in a JSON file
On Wed, May 29, 2013 at 1:10 PM, Chris Rebert wrote:
> On Wed, May 29, 2013 at 4:16 AM, Jabba Laci wrote:
> > I have a growing JSON file that I edit manually and it might happen
> > that I repeat a key. If this happens, I would like to get notified.
> > Currently the value of the second key silently overwrites the value of
> > the first.
>
> You can pass an appropriate object_pairs_hook function to json.load():
> http://docs.python.org/2/library/json.html#repeated-names-within-an-object
> http://docs.python.org/2/library/json.html#json.load
>
That makes it pretty easy to provide any validation you might like to your
JSON data. Here's a quick example that raises ValueError on duplicate keys,
since the docs didn't have any examples.
Python 3.2.2 (default, Sep 4 2011, 09:51:08) [MSC v.1500 32 bit (Intel)]
on win32
>>> s = '{"x": 1, "x": 2, "x": 3}'
>>> def json_checker(seq):
d = {}
for key, value in seq:
if key in d:
raise ValueError("Duplicate key %r in json document" % key)
else:
d[key]=value
return d
>>> json.loads(s, object_pairs_hook=json_checker)
Traceback (most recent call last):
File "", line 1, in
json.loads(s, object_pairs_hook=checker)
File "C:\Python32\lib\json\__init__.py", line 320, in loads
return cls(**kw).decode(s)
File "C:\Python32\lib\json\decoder.py", line 351, in decode
obj, end = self.raw_decode(s, idx=_w(s, 0).end())
File "C:\Python32\lib\json\decoder.py", line 367, in raw_decode
obj, end = self.scan_once(s, idx)
File "", line 5, in json_checker
raise ValueError("Duplicate key %r in json document" % key)
ValueError: Duplicate key 'x' in json document
--
Jerry
--
http://mail.python.org/mailman/listinfo/python-list
Re: Short-circuit Logic
On Thu, May 30, 2013 at 12:28 PM, Steven D'Aprano wrote: > * de facto exact equality testing, only slower and with the *illusion* of > avoiding equality, e.g. "abs(x-y) < sys.float_info.epsilon" is just a > long and slow way of saying "x == y" when both numbers are sufficiently > large; > The problem here, I think, is that "epsilon" has two meanings: * sys.float_info.epsilon, which is an extremely specific value (the smallest x such that 1.0+x != x) * the mathematical concept, which is where the other got its name from. Let's suppose someone is told to compare floating point numbers by seeing if the absolute value of the difference is less than some epsilon. They look up "absolute value" and find abs(); they look up "epsilon" and think they've found it. Trouble is, they've found the wrong epsilon... and really, there's an engineering issue here too. Here's one of my favourite examples of equality comparisons: http://xkcd.com/1047/ # Let's say we measured this accurately to one part in 40 x = one_light_year_in_meters y = pow(99,8) x == y # False abs(x-y) < x/40 # True Measurement accuracy is usually far FAR worse than floating-point accuracy. It's pretty pointless to compare for some kind of "equality" that ignores this. Say you measure the diameter and circumference of a circle, accurate to one meter, and got values of 79 and 248; does this mean that pi is less than 3.14? No - in fact: pi = 248/79 # math.pi = 3.141592653589793 abs(pi-math.pi) < pi/79 # True Worst error is 1 in 79, so all comparisons are done with epsilon derived from that. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: How clean/elegant is Python's syntax?
On Thu, May 30, 2013 at 7:01 AM, Walter Hurry wrote: > On Thu, 30 May 2013 04:54:44 +1000, Chris Angelico wrote: > > >> GUIs and databasing are two of the areas where I >> think Python's standard library could stand to be improved a bit. >> There are definitely some rough edges there. > > Dunno what you mean about "standard library", but I'm very happy with > wxPython and psycopg2 for GUIs and databasing respectively. They are not part of the standard library. Yes, Python is strongly enhanced by additional packages off PyPI, but that's not the same thing; if I publish a program that requires psycopg2, I can't simply say "go get Python from your OS's repository or python.org", I have to also instruct people to install another package. On Debian, I can simply apt-get python-psycopg2, which I would trust to be (a) a stable build, (b) compatible with the apt-gettable python (which is 2.7.3; ditto python3-psycopg2 and python3, for 3.2.3), and (c) from an authoritative source. There's probably a way to do this for other Linuxes too, but I don't know the exact package names everywhere. And on Windows, I have no idea what the best way would be. These days, networking is considered essential. Python's standard library includes basic sockets, HTTP (client and server), etc. AFAIK Python doesn't have obscurities like DNS (obviously you can connect a socket by hostname, but you can't look up an SPF record, nor can you write a DNS server), but networking generally is considered important enough to be inbuilt. Why is databasing second-class? ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: How clean/elegant is Python's syntax?
On Thu, May 30, 2013 at 10:24 AM, Dan Stromberg wrote: > I'm finding it kind of hard to imagine not finding Python's syntax and > semantics pretty graceful. > > About the only thing I don't like is: > >var = 1, > > That binds var to a tuple (singleton) value, instead of 1. I agree, and would write it as: var = (1,) for clarity. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: The state of pySerial
On 2013-05-29, Terry Jan Reedy wrote: > On 5/29/2013 3:47 PM, Grant Edwards wrote: >> On 2013-05-29, Ma Xiaojun wrote: [...] >>> Unforunately, pySerial project doesn't seem to have a good state. I >>> find pySerial + Python 3.3 broken on my machine (Python 2.7 is OK) . >>> There are unanswered outstanding bugs, PyPI page has 2.6 while SF >>> homepage still gives 2.5. >>> >>> Any idea? >> >> Volunteer as a maintainer and start fixing bugs? > > It seems to be getting around 200 downloands a day. Quite worth > someone supporting it. Chris has a day job, just like the rest of us. He might even have a family and hobbies other than supporting pyserial. ;) Everybody should feel free to submit patches for open bugs and to test any patches waiting to be accepted. >> I use pyserial regularly, and the current version works fine for me, >> but I'm using Python 2.7. There are still too many libraries that >> don't support 3.x for me to consider using 3.x for real work. > > The only download is a .exe. It it just the executable binary or is that > a zip unpacker with source? http://pyserial.sourceforge.net/pyserial.html#from-source-tar-gz-or-checkout https://pypi.python.org/packages/source/p/pyserial/pyserial-2.6.tar.gz#md5=cde799970b7c1ce1f7d6e9ceebe64c98 -- Grant -- http://mail.python.org/mailman/listinfo/python-list
Building a HPC data assimilation system using Python?
I have a prototype data assimilation code ( an ionospheric nowcast/forecast model driven by GPS data ) that is written in IDL (interactive data language) which is a horrible language choice for scaling the application up to large datasets as IDL is serial and slow (interpreted). I am embarking on a project to convert this prototype into an operational parallel HPC code. In the past I've used C++ for this kind of project and am comfortable using MPI. On the other hand, I've recently started using python and appreciate the flexibility and speed of development using python compared with C++. I have read that there is a trend to use python as the high level 'glue' for these kind of large number crunching projects, so it would seem appropriate to go down that path. There are a number of C++ and FORTRAN(!) libraries I'd need to incorporate that handle things such as the processing of raw GPS data and computing ionospheric models, so I'd need to be able to make the appropriate interface for these into python. If anyone uses python is this way, I'd appreciate any tips, hints, things to be careful about and in general any war stories you can relate that you wish you'd heard before making some mistake. Here are the things I have investigated that it looks like I'd probably need to use: * scipy/numpy/matplotlib * Cython (or pyrex?) for speeding up any bottlenecks that occur in python code (as opposed to C++/FORTRAN libraries) * MPI for Python (mpi4py). Does this play nice with Cython? * Something to interface python with other language libraries. ctypes, swig, boost? Which would be best for this application? * Profiling. profile/cprofile are straightforward to use, but how do they cope with a parallel (mpi4py) code? * If a C++ library call has its own MPI calls, does that work smoothly with mpi4py operating in the python part of the code? Sorry if some of this is a little basic, I'm trying to get up to speed on this a quick as I can. Thanks in advance! -- http://mail.python.org/mailman/listinfo/python-list
Re: Short-circuit Logic
On Wed, 29 May 2013 07:27:40 -0700, Ahmed Abdulshafy wrote: > On Tuesday, May 28, 2013 3:48:17 PM UTC+2, Steven D'Aprano wrote: >> On Mon, 27 May 2013 13:11:28 -0700, Ahmed Abdulshafy wrote: >> >> >> >> > That may be true for integers, but for floats, testing for equality >> > is >> >> > not always precise >> >> >> >> Incorrect. Testing for equality is always precise, and exact. The >> problem >> >> is not the *equality test*, but that you don't always have the number >> >> that you think you have. The problem lies elsewhere, not equality! >> >> >> Steven > > Well, this is taken from my python shell> > 0.33455857352426283 == 0.33455857352426282 > True This is an excellent example of misunderstanding what you are seeing. Both 0.33455857352426283 and 0.33455857352426282 represent the same float, so it is hardly a surprise that they compare equal -- they compare equal because they are equal. py> a, b = 0.33455857352426283, 0.33455857352426282 py> a.as_integer_ratio() (6026871468229899, 18014398509481984) py> b.as_integer_ratio() (6026871468229899, 18014398509481984) You've made a common error: neglecting to take into account the finite precision of floats. Floats are not mathematical "real numbers", with infinite precision. The error is more obvious if we exaggerate it: py> 0.3 == 0.31 True Most people who have seen an ordinary four-function calculator will realise that the issue here is *not* that the equality operator == is wrongly stating that two unequal numbers are equal, but that just because you enter 0.300...1 doesn't mean that all those decimal places are actually used. > Anyway, man, those were not my words anyway, most programming books I've > read state so. Here's an excerpt from the Python book, I'm currently > reading> > > ">>> 0.0, 5.4, -2.5, 8.9e-4 > (0.0, 5.4004, -2.5, 0.00088995) > > > The inexactness is not a problem specific to Python—all programming > languages have this problem with floating-point numbers." I'm not denying that floats are tricky to use correctly, or that testing for exact equality is *sometimes* the wrong thing to do: # Wrong, don't do this! x = 0.1 while x != 17.3: print(x) x += 0.1 I'm just saying that a simple minded comparison with sys.float_info.epsilon is *also* often wrong. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Short-circuit Logic
On Thu, May 30, 2013 at 3:10 PM, Steven D'Aprano wrote: > # Wrong, don't do this! > x = 0.1 > while x != 17.3: > print(x) > x += 0.1 > Actually, I wouldn't do that with integers either. There are too many ways that a subsequent edit could get it wrong and go infinite, so I'd *always* use an inequality for that: x = 1 while x < 173: print(x) x += 1 Well, in Python I'd use for/range, but the equivalent still applies. A range() is still based on an inequality: >>> list(range(1,6)) [1, 2, 3, 4, 5] >>> list(range(1,6,3)) [1, 4] Stops once it's no longer less than the end. That's safe, since Python can't do integer wraparound. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Short-circuit Logic
On Wed, 29 May 2013 20:23:00 -0400, Dave Angel wrote:
> Even in a pure decimal system of (say)
> 40 digits, I could type in a 42 digit number and it would get quantized.
> So just because two 42 digit numbers are different doesn't imply that
> the 40 digit internal format would be.
Correct, and we can demonstrate it using Python:
py> from decimal import *
py> getcontext().prec = 3
py> a = +Decimal('1.')
py> b = +Decimal('1.0009')
py> a == b
True
(By default, the Decimal constructor does not honour the current
precision. To force it to do so, use the unary + operator.)
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
Re: Short-circuit Logic
On Thu, 30 May 2013 13:45:13 +1000, Chris Angelico wrote: > Let's suppose someone is told to compare floating point numbers by > seeing if the absolute value of the difference is less than some > epsilon. Which is usually the wrong way to do it! Normally one would prefer *relative* error, not absolute: # absolute error: abs(a - b) < epsilon # relative error: abs(a - b)/a < epsilon One problem with absolute error is that it can give an entirely spurious image of "fuzziness", when in reality it is actually performing the same exact equality as == only slower and more verbosely. If a and b are sufficiently large, the smallest possible difference between a and b may be greater than epsilon (for whichever epsilon you pick). When that happens, you might as well just use == and be done with it. But using relative error also raises questions: - what if a is negative? - why relative to a instead of relative to b? - what if a is zero? The first, at least, is easy to solve: take the absolute value of a. But strangely, you rarely see programming books mention that, so I expect that there is a lot of code in the real world that assumes a is positive and does the wrong thing when it isn't. Here's another way, mathematically equivalent (although not necessarily equivalent using floating point computations!) which avoids the divide-by- zero problem: abs(a - b) < epsilon*a Whichever method you choose, there are gotchas to watch out for. > http://xkcd.com/1047/ Nice! -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: How clean/elegant is Python's syntax?
On Thu, 30 May 2013 02:37:35 +0800, Ma Xiaojun wrote: > For pure procedural paradigm, I haven't seen much advantages of Python. Nice syntax with a minimum of boiler plate -- "executable pseudo-code", as they say. Extensive library support -- "batteries included". These are both good advantages. > Yes, Python has true OOP but I don't like this argument since I don't > like Java-ism true OOP. Java is not the best example of OOP. In some ways, it is a terrible example of OOP: some values are not objects, classes are not first-class values, and the language is horribly verbose. There are good reasons for some of these things, but good reasons or bad, Java is *not* the exemplar of OOP that some Java coders believe. In some ways, Python is a more pure OOP language than Java: everything in Python is an object, including classes themselves. In other ways, Python is a less pure and more practical language. You don't have to wrap every piece of functionality in a class. Python encourages you to write mixed procedural, functional and object oriented code, whatever is best for the problem you are trying to solve, which is very much in contrast to Java: http://steve-yegge.blogspot.com.au/2006/03/execution-in-kingdom-of- nouns.html > Yes, Python has much more libraries. But it seems that Python is more > useful and suitable in CLI and Web applications. That is fair. All languages have their strengths and weaknesses. I wouldn't use Python to program low-level device driver code, and I wouldn't write a web-app in C. > People are still > discussing whether to replace tkinter with wxPython or not. VB and VFP > people are never bothered with such issue. Which people? "People" can discuss any rubbish they like. For many reasons, tkinter will not be replaced. For the standard library, it is a good, stable, powerful but not cutting-edge GUI library. If you don't like it, you can install a third-party framework like wxPython. Using tkinter is not compulsory. In the case of VB and VFP, they aren't bothered by such issues because they're used to closed-source, proprietary programming where you use what you are given and like it. In the open-source world, if you don't like what you are given, you find something else, and if you can't find it, you make it yourself. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Getting a callable for any value?
On Wed, 29 May 2013 12:46:19 -0500, Croepha wrote: > Is there anything like this in the standard library? > > class AnyFactory(object): > def __init__(self, anything): > self.product = anything > def __call__(self): > return self.product > def __repr__(self): > return "%s.%s(%r)" % (self.__class__.__module__, > self.__class__.__name__, self.product) > > my use case is: > collections.defaultdict(AnyFactory(collections.defaultdict( > AnyFactory(None That's not a use-case. That's a code snippet. What does it mean? Why would you write such an ugly thing? What does it do? I get a headache just looking at it. I *think* it's a defaultdict that returns a defaultdict on KeyError, where the *second* defaultdict returns None. from collections import defaultdict defaultdict(lambda: defaultdict(lambda: None)) looks more reasonable to me. I don't know why you need to wrap such a simple pair of functions in a class. This is not Java. http://steve-yegge.blogspot.com.au/2006/03/execution-in-kingdom-of-nouns.html (Twice in one day I have linked to this.) I'm not sure why you care about the repr of the "AnythingFactory" object. You stuff it directly into the defaultdict, where you are very unlikely to need to inspect it. You only ever see the defaultdicts they return, and they already have a nice repr. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
