IDE of the all python version installed cant uploaded
I have from time ago installed Python 2.6, 2.7, 3.2 and the last 3.3 beta but now I can upload the window version not the prompt command some advice is needed i desintalled and reinstall and nothing!! thanks in advance Mario -- http://mail.python.org/mailman/listinfo/python-list
Re: Flexible string representation, unicode, typography, ...
On Tue, 28 Aug 2012 22:15:31 -0600, Ian Kelly wrote: > On Tue, Aug 28, 2012 at 8:42 PM, rusi wrote: >> How difficult would it be to giving the choice of string engine as a >> command-line flag? >> This would avoid the nuisance of having two binaries -- narrow and >> wide. > > Quite difficult. Even if we avoid having two or three separate > binaries, we would still have separate binary representations of the > string structs. It makes the maintainability of the software go down > instead of up. In fairness, there are already multiple binary representations of strings in Python 3.3: - ASCII-only strings use a 1-byte format (PyASCIIObject); - Compact Unicode objects (PyCompactObject), which if I'm reading correctly, appears to use a non-fixed width UTF-8 format, but are only used when the string length and maximum character are known ahead of time; - Legacy string objects (PyUnicodeObject), which are not compact, and which may use as their internal format: * 1-byte characters for Latin1-compatible strings; * 2-byte UCS-2 characters for strings in the Basic Multilingual Plane; * 4-byte UCS-4 characters for strings with at least one non-BMP character. http://www.python.org/dev/peps/pep-0393/#specification By my calculations, that makes *five* different internal formats for strings, at least two of which are capable of representing all Unicode characters. I don't think it would add that much additional complexity to have a runtime option --always-wide-strings to always use the UCS-4 format. For, you know, crazy people with more memory than sense. But I don't think there's any point in exposing further runtime options to choose the string representation: - neither the ASCII nor Latin1 representations can store arbitrary Unicode chars, so they're out; - the UTF-8 format is only used under restrictive circumstances, and so is (probably?) unsuitable for all strings. - the UCS-2 format can, by using surrogate pairs, but that's troublesome to get right, some might even say buggy. >> And it would give the python programmer a choice of efficiency >> profiles. > > So instead of having just one test for my Unicode-handling code, I'll > now have to run that same test *three times* -- once for each possible > string engine option. Choice isn't always a good thing. There is that too. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Can I get logging.FileHandler to close the file on each emit?
I use logging.FileHandler (on windows) and I would like to be able to delete the file while the process is running and have it create the file again on next log event. On windows (not tried linux) this is not possible because the file is locked by the process, can I get it to close the file after each log event? If not, would the correct thing to do be to write my own LogHandler with this behavior? / Rikard -- http://mail.python.org/mailman/listinfo/python-list
Issue installing pyopencv in mac
I tried installing pyopencv in mac but i gives me an error I have installed all the dependent softwares like opencv,boost, etcstill unable to fix it. also i have updated xcode and using python 2.7 I also tried using mac port but still no use can anybody help meThanks in advance. -- http://mail.python.org/mailman/listinfo/python-list
Re: What do I do to read html files on my pc?
Il giorno lunedì 27 agosto 2012 12:59:02 UTC+2, mikcec82 ha scritto:
> Hallo,
>
>
>
> I have an html file on my pc and I want to read it to extract some text.
>
> Can you help on which libs I have to use and how can I do it?
>
>
>
> thank you so much.
>
>
>
> Michele
Hi Peter and thanks for your precious help.
Fortunately, there aren't runs of "X" with repeats other than 2 or 4.
Starting from your code, I wrote this code (I post it, so it could be helpful
for other people):
f = open(fileorig, 'r')
nomefile = f.read()
start = nomefile.find("XX")
start2 = nomefile.find("NOT PASSED")
c0 = 0
c1 = 0
c2 = 0
while (start != -1) | (start2 != -1):
if nomefile[start:start+4] == "":
print " found at location", start
start += 4
c0 +=1
elif nomefile[start:start+2] == "XX":
print "XX found at location", start
start += 2
c1 +=1
if nomefile[start2:start2+10] == "NOT PASSED":
print "NOT PASSED found at location", start2
start2 += 10
c2 +=1
start = nomefile.find("XX", start)
start2 = nomefile.find("NOT PASSED", start2)
print " %s founded" % c0, "\nXX %s founded" % c1, "\nNOT
PASSED %s founded" % c2
Now, I'm able to find all occurences of strings: "", "XX" and "NOT PASSED"
Thank you so much.
--
http://mail.python.org/mailman/listinfo/python-list
Are the property Function really useful?
Are the property Function really useful? Where can i use the property function? -- http://mail.python.org/mailman/listinfo/python-list
Re: Flexible string representation, unicode, typography, ...
Le lundi 27 août 2012 22:37:03 UTC+2, (inconnu) a écrit : > Le lundi 27 août 2012 22:14:07 UTC+2, Ian a écrit : > > > On Mon, Aug 27, 2012 at 1:16 PM, wrote: > > > > > > > - Why int32 and not uint32? No idea, I tried to find an > > > > > > > answer without asking. > > > > > > > > > > > > UCS-4 is technically only a 31-bit encoding. The sign bit is not used, > > > > > > so the choice of int32 vs. uint32 is inconsequential. > > > > > > > > > > > > (In fact, since they made the decision to limit Unicode to the range 0 > > > > > > - 0x0010, one might even point out that the *entire high-order > > > > > > byte* as well as 3 bits of the next byte are irrelevant. Truly, > > > > > > UTF-32 is not designed for memory efficiency.) > > > > I know all this. The question is more, why not a uint32 knowing > > there are only positive code points. It seems to me more "natural". Answer found. In short: using negative ints simplifies internal tasks. -- http://mail.python.org/mailman/listinfo/python-list
Re: Flexible string representation, unicode, typography, ...
Le mercredi 29 août 2012 06:16:05 UTC+2, Ian a écrit :
> On Tue, Aug 28, 2012 at 8:42 PM, rusi wrote:
>
> > In summary:
>
> > 1. The problem is not on jmf's computer
>
> > 2. It is not windows-only
>
> > 3. It is not directly related to latin-1 encodable or not
>
> >
>
> > The only question which is not yet clear is this:
>
> > Given a typical string operation that is complexity O(n), in more
>
> > detail it is going to be O(a + bn)
>
> > If only a is worse going 3.2 to 3.3, it may be a small issue.
>
> > If b is worse by even a tiny amount, it is likely to be a significant
>
> > regression for some use-cases.
>
>
>
> As has been pointed out repeatedly already, this is a microbenchmark.
>
> jmf is focusing in one one particular area (string construction) where
>
> Python 3.3 happens to be slower than Python 3.2, ignoring the fact
>
> that real code usually does lots of things other than building
>
> strings, many of which are slower to begin with. In the real-world
>
> benchmarks that I've seen, 3.3 is as fast as or faster than 3.2.
>
> Here's a much more realistic benchmark that nonetheless still focuses
>
> on strings: word counting.
>
>
>
> Source: http://pastebin.com/RDeDsgPd
>
>
>
>
>
> C:\Users\Ian\Desktop>c:\python32\python -m timeit -s "import wc"
>
> "wc.wc('unilang8.htm')"
>
> 1000 loops, best of 3: 310 usec per loop
>
>
>
> C:\Users\Ian\Desktop>c:\python33\python -m timeit -s "import wc"
>
> "wc.wc('unilang8.htm')"
>
> 1000 loops, best of 3: 302 usec per loop
>
>
>
> "unilang8.htm" is an arbitrary UTF-8 document containing a broad swath
>
> of Unicode characters that I pulled off the web. Even though this
>
> program is still mostly string processing, Python 3.3 wins. Of
>
> course, that's not really a very good test -- since it reads the file
>
> on every pass, it probably spends more time in I/O than it does in
>
> actual processing. Let's try it again with prepared string data:
>
>
>
>
>
> C:\Users\Ian\Desktop>c:\python32\python -m timeit -s "import wc; t =
>
> open('unilang8.htm', 'r', encoding
>
> ='utf-8').read()" "wc.wc_str(t)"
>
> 1 loops, best of 3: 87.3 usec per loop
>
>
>
> C:\Users\Ian\Desktop>c:\python33\python -m timeit -s "import wc; t =
>
> open('unilang8.htm', 'r', encoding
>
> ='utf-8').read()" "wc.wc_str(t)"
>
> 1 loops, best of 3: 84.6 usec per loop
>
>
>
> Nope, 3.3 still wins. And just for the sake of my own curiosity, I
>
> decided to try it again using str.split() instead of a StringIO.
>
> Since str.split() creates more strings, I expect Python 3.2 might
>
> actually win this time.
>
>
>
>
>
> C:\Users\Ian\Desktop>c:\python32\python -m timeit -s "import wc; t =
>
> open('unilang8.htm', 'r', encoding
>
> ='utf-8').read()" "wc.wc_split(t)"
>
> 1 loops, best of 3: 88 usec per loop
>
>
>
> C:\Users\Ian\Desktop>c:\python33\python -m timeit -s "import wc; t =
>
> open('unilang8.htm', 'r', encoding
>
> ='utf-8').read()" "wc.wc_split(t)"
>
> 1 loops, best of 3: 76.5 usec per loop
>
>
>
> Interestingly, although Python 3.2 performs the splits in about the
>
> same time as the StringIO operation, Python 3.3 is significantly
>
> *faster* using str.split(), at least on this data set.
>
>
>
>
>
> > So doing some arm-chair thinking (I dont know the code and difficulty
>
> > involved):
>
> >
>
> > Clearly there are 3 string-engines in the python 3 world:
>
> > - 3.2 narrow
>
> > - 3.2 wide
>
> > - 3.3 (flexible)
>
> >
>
> > How difficult would it be to giving the choice of string engine as a
>
> > command-line flag?
>
> > This would avoid the nuisance of having two binaries -- narrow and
>
> > wide.
>
>
>
> Quite difficult. Even if we avoid having two or three separate
>
> binaries, we would still have separate binary representations of the
>
> string structs. It makes the maintainability of the software go down
>
> instead of up.
>
>
>
> > And it would give the python programmer a choice of efficiency
>
> > profiles.
>
>
>
> So instead of having just one test for my Unicode-handling code, I'll
>
> now have to run that same test *three times* -- once for each possible
>
> string engine option. Choice isn't always a good thing.
>
>
Forget Python and all these benchmarks. The problem
is on an other level. Coding schemes, typography,
usage of characters, ...
For a given coding scheme, all code points/characters are
equivalent. Expecting to handle a sub-range in a coding
scheme without shaking that coding scheme is impossible.
If a coding scheme does not give satisfaction, the only
valid solution is to create a new coding scheme, cp1252,
mac-roman, EBCDIC, ... or the interesting "TeX" case, where
the "internal" coding depends on the fonts!
Unicode (utf***), as just one another coding scheme, does
not escape to this rule.
This "Flexible String Representation" fails. Not only
it is unable to stick with a coding scheme, it is
a mixing of coding sche
Re: Are the property Function really useful? yes.
On 08/29/2012 06:32 AM, [email protected] wrote: -- DaveA -- http://mail.python.org/mailman/listinfo/python-list
Re: Flexible string representation, unicode, typography, ...
On 08/29/2012 07:40 AM, [email protected] wrote: > > Forget Python and all these benchmarks. The problem is on an other > level. Coding schemes, typography, usage of characters, ... For a > given coding scheme, all code points/characters are equivalent. > Expecting to handle a sub-range in a coding scheme without shaking > that coding scheme is impossible. If a coding scheme does not give > satisfaction, the only valid solution is to create a new coding > scheme, cp1252, mac-roman, EBCDIC, ... or the interesting "TeX" case, > where the "internal" coding depends on the fonts! Unicode (utf***), as > just one another coding scheme, does not escape to this rule. This > "Flexible String Representation" fails. Not only it is unable to stick > with a coding scheme, it is a mixing of coding schemes, the worst of > all possible implementations. jmf Nonsense. The discussion was not about an encoding scheme, but an internal representation. That representation does not change the programmer's interface in any way other than performance (cpu and memory usage). Most of the rest of your babble is unsupported opinion. Plonk. -- DaveA -- http://mail.python.org/mailman/listinfo/python-list
Re: What do I do to read html files on my pc?
You can use httplib library to download the html and then for extracting the text from it either you can use any library (google for it) or you can use regular expression for it . -- http://mail.python.org/mailman/listinfo/python-list
Re: Flexible string representation, unicode, typography, ...
On Wed, Aug 29, 2012 at 9:40 PM, wrote: > For a given coding scheme, all code points/characters are > equivalent. Expecting to handle a sub-range in a coding > scheme without shaking that coding scheme is impossible. Not all codepoints are equally likely. That's the whole point behind variable-length encodings like Huffman compression (eg deflation as used in zip/gzip), UTF-8, quoted-printable, and Morse code. They handle a sub-range efficiently and the rest of the range less efficiently. > If a coding scheme does not give satisfaction, the only > valid solution is to create a new coding scheme, cp1252, > mac-roman, EBCDIC, ... or the interesting "TeX" case, where > the "internal" coding depends on the fonts! http://xkcd.com/927/ > This "Flexible String Representation" fails. Not only > it is unable to stick with a coding scheme, it is > a mixing of coding schemes, the worst of all possible > implementations. I propose, then, that we abolish files. Who *knows* how many different things might be represented in a file! We need a single coding scheme that can handle everything, without changing representation. This ridiculous state of affairs must not go on; the same representation can be used for bitmapped images or raw audio data! ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Can I get logging.FileHandler to close the file on each emit?
On 29/08/2012 11:18, [email protected] wrote: I use logging.FileHandler (on windows) and I would like to be able to delete the file while the process is running and have it create the file again on next log event. On windows (not tried linux) this is not possible because the file is locked by the process, can I get it to close the file after each log event? If not, would the correct thing to do be to write my own LogHandler with this behavior? / Rikard I know little about the logging module but given that the FileHandler[1] has a close method, can you simply call that, delete the file and reopen where needed? Failing that I'd look at subclassing existing code and not writing your own (Your wording implies to me that you're thinking of writing something from scratch, my apologies should I be wrong on that). [1] http://docs.python.org/dev/library/logging.handlers.html -- Cheers. Mark Lawrence. -- http://mail.python.org/mailman/listinfo/python-list
Re: Sending USB commands with Python
On Wednesday, August 29, 2012 2:45:17 AM UTC-4, Tim Roberts wrote:
> Which operating system are you using? If you are on Windows, then the
>
> operating system has already loaded a printer driver for this device.
>
>
> The libusb or libusbx libraries can be used to talk to USB devices. There
>
> is a Python binding. On Windows, you still need to have a driver, but the
>
> libusbx instructions can help you find an install one.
>
I am on Windows and have installed a driver using libusb-win32. Using
http://pyusb.sourceforge.net/docs/1.0/tutorial.html as a template, this is my
code so far:
import usb.core
import usb.util
dev = usb.core.find(idVendor=0x0922, idProduct=0x0021)
# set the active configuration. With no arguments, the first
# configuration will be the active one
dev.set_configuration()
# get an endpoint instance
cfg = dev.get_active_configuration()
interface_number = cfg[(0,0)].bInterfaceNumber
alternate_settting = usb.control.get_interface(dev,interface_number)
intf = usb.util.find_descriptor(
cfg, bInterfaceNumber = interface_number,
bAlternateSetting = 0
)
ep = usb.util.find_descriptor(
intf,
# match the first OUT endpoint
custom_match = \
lambda e: \
usb.util.endpoint_direction(e.bEndpointAddress) == \
usb.util.ENDPOINT_OUT
)
assert ep is not None
I had to manually set bAlternateSetting to 0 for it to run and add dev to
usb.control.get_interface(dev,interface_number).
Trying to do the status thing mentioned before, in the interpreter I did:
>>> ep.write('A')
2
And the manual says 2 is not a valid option... So something isn't adding up.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Issue installing pyopencv in mac
On 29/08/2012 11:21, Rakesh Rocker RuLZzz wrote: I tried installing pyopencv in mac but i gives me an error I have installed all the dependent softwares like opencv,boost, etcstill unable to fix it. also i have updated xcode and using python 2.7 I also tried using mac port but still no use can anybody help meThanks in advance. The short answer is no :) Unless you tell us exactly what you've tried and the precise error details nobody can help you. -- Cheers. Mark Lawrence. -- http://mail.python.org/mailman/listinfo/python-list
Re: Can I get logging.FileHandler to close the file on each emit?
On Wednesday, August 29, 2012 2:48:57 PM UTC+2, Mark Lawrence wrote: > On 29/08/2012 11:18, wrote: > > > I use logging.FileHandler (on windows) and I would like to be able to > > delete the file while the process is running and have it create the file > > again on next log event. > > > > > > On windows (not tried linux) this is not possible because the file is > > locked by the process, can I get it to close the file after each log event? > > > > > > If not, would the correct thing to do be to write my own LogHandler with > > this behavior? > > > > > > / Rikard > > > > > > > I know little about the logging module but given that the FileHandler[1] > > has a close method, can you simply call that, delete the file and reopen > > where needed? Failing that I'd look at subclassing existing code and > > not writing your own (Your wording implies to me that you're thinking of > > writing something from scratch, my apologies should I be wrong on that). > > > > [1] http://docs.python.org/dev/library/logging.handlers.html > > > > -- > > Cheers. > > > > Mark Lawrence. I want to delete the file from outside the process while it is running, so in the code I have no idea when that is... I meant subclassing logging.Handler, which I went ahead and tried and it seems to work as I like. Basically in emit I do 1. open log file 2. write msg to it 3. close file / Rikard -- http://mail.python.org/mailman/listinfo/python-list
Re: Are the property Function really useful?
On 29/08/2012 11:32, [email protected] wrote: Rather more useful than your question :) -- Cheers. Mark Lawrence. -- http://mail.python.org/mailman/listinfo/python-list
Re: [pyxl] xlrd-0.8.0 .xlsx formatting_info=True not imlemented
> is there any other way to tell how many digits excel would round to > when displaying a floating point number? that's my only reason for > needing formatting_info=True. I have not personally used it, but OpenPyXL is another option for working with .xlsx files, and it might provide the formatting info you need: http://packages.python.org/openpyxl/index.html http://pypi.python.org/pypi/openpyxl/1.5.8 John Y. -- http://mail.python.org/mailman/listinfo/python-list
How to program test(expr) ?
Hi !
I use Python 3.2.3 + Idle.
Is it possible to program test(e) which takes
an expression e and whose execution produces
at the toplevel an echo of e and the effects
and result of its evaluation ?
# file foo.py
def foo(x) :
print('x =',x)
return x+1
test(foo(5))
# RUN !
# produces at the toplevel :
? foo(5)
x = 5
--> 6
I know I could put the expression e within a string, but
is it possible to avoid the string, like a Lisp macro ?
Thanks.
franck
--
http://mail.python.org/mailman/listinfo/python-list
Re: Flexible string representation, unicode, typography, ...
Le mercredi 29 août 2012 14:01:57 UTC+2, Dave Angel a écrit : > On 08/29/2012 07:40 AM, [email protected] wrote: > > > > > > > > Forget Python and all these benchmarks. The problem is on an other > > > level. Coding schemes, typography, usage of characters, ... For a > > > given coding scheme, all code points/characters are equivalent. > > > Expecting to handle a sub-range in a coding scheme without shaking > > > that coding scheme is impossible. If a coding scheme does not give > > > satisfaction, the only valid solution is to create a new coding > > > scheme, cp1252, mac-roman, EBCDIC, ... or the interesting "TeX" case, > > > where the "internal" coding depends on the fonts! Unicode (utf***), as > > > just one another coding scheme, does not escape to this rule. This > > > "Flexible String Representation" fails. Not only it is unable to stick > > > with a coding scheme, it is a mixing of coding schemes, the worst of > > > all possible implementations. jmf > > > > Nonsense. The discussion was not about an encoding scheme, but an > > internal representation. That representation does not change the > > programmer's interface in any way other than performance (cpu and memory > > usage). Most of the rest of your babble is unsupported opinion. > I can hit the nail a little more. I have even a better idea and I'm serious. If "Python" has found a new way to cover the set of the Unicode characters, why not proposing it to the Unicode consortium? Unicode has already three schemes covering practically all cases: memory consumption, maximum flexibility and an intermediate solution. It would be to bad, to not share it. What do you think? ;-) jmf -- http://mail.python.org/mailman/listinfo/python-list
Re: Flexible string representation, unicode, typography, ...
On Thu, Aug 30, 2012 at 1:43 AM, wrote: > If "Python" has found a new way to cover the set > of the Unicode characters, why not proposing it > to the Unicode consortium? Python's open source. If some other language wants to borrow the idea, they can look at the code, or alternatively, just read PEP 393 and implement something similar. It's a free world. By the way, can you please trim the quoted text in your replies? It's rather lengthy. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Cut out XML subtree
Hello, I have a (rather small, memory consumption is not an issue) XML document. The application is still at the planning stage, so none of the XML parsers from the stdlib is choosen yet. I want to cut out an XML subtree like that: Now I want to get the subB note including parent node, but none of sibliblings: Is there a way I can do that using etree or DOM? The first is prefered... Thanks, Florian -- http://mail.python.org/mailman/listinfo/python-list
Re: Cut out XML subtree
On Wed, 29 Aug 2012 18:17:18 +0200
Florian Lindner wrote:
> I want to cut out an XML subtree like that:
[snip]
> Is there a way I can do that using etree or DOM? The first is
> prefered...
Python 3.2.2 (default, Sep 5 2011, 22:09:30)
[GCC 4.6.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import xml.etree.ElementTree as etree
>>> test = """
...
...
... Element A.1
... Element A.2
...
...
... Element B.1
... Element B.2
...
... """
>>> tree = etree.fromstring(test)
>>> subA = tree.find("subA")
>>> tree.remove(subA)
>>> new = etree.tostring(tree, encoding="unicode")
>>> print(new)
Element B.1
Element B.2
Bye, Andreas
--
http://mail.python.org/mailman/listinfo/python-list
Re: Sending USB commands with Python
On Wednesday, August 29, 2012 4:09:49 PM UTC-4, Dennis Lee Bieber wrote:
>
> Don't the commands require an character? "\x1BA" (or
>"\x1B\x41")
>
> OTOH, if the is issued behind the scenes,
I'm not sure which esc char it is asking for, I don't think libusb is providing
its own, and it seems like the one you suggested isn't what it wants either..
> ... and you do not need to issue some sort of read()
> the "2" you are seeing is the "number of bytes written";
>
> you need to issue a read request to retrieve the returned printer
>
> status.
>
You are correct about the 2 being the number of bytes written. However when I
issue a read command I get:
>>> ep.write('\x1BA')
4
>>> ep.read(1)
Traceback (most recent call last):
File "", line 1, in
ep.read(1)
File "C:\Python32\lib\site-packages\usb\core.py", line 301, in read
return self.device.read(self.bEndpointAddress, size, self.interface,
timeout)
File "C:\Python32\lib\site-packages\usb\core.py", line 654, in read
self.__get_timeout(timeout)
File "C:\Python32\lib\site-packages\usb\backend\libusb01.py", line 483, in
bulk_read
timeout)
File "C:\Python32\lib\site-packages\usb\backend\libusb01.py", line 568, in
__read
timeout
File "C:\Python32\lib\site-packages\usb\backend\libusb01.py", line 384, in
_check
raise USBError(errmsg, ret)
usb.core.USBError: [Errno None] b'libusb0-dll:err [_usb_setup_async] invalid
endpoint 0x02\n'
Avoiding the read command all together I should be able to write " E" and
have it feed some paper, which it is not doing, so obviously there is more to
uncover. That said I feel this endeavor has evolved and is no longer pertinent
to the Python group so I will let you guys off the hook on this (although
responses/suggestions are still welcome).
Thanks for all your help!
--
http://mail.python.org/mailman/listinfo/python-list
Re: ctypes - python2.7.3 vs python3.2.3
On 8/28/12 23:51 , John Gordon wrote: In <[email protected]> Rolf writes: uint32_t myfunction (char ** _mydata) { char mydata[16]; strcpy(mydata, "Hello Dude!"); *_mydata = mydata; return 0; } mydata is an auto variable, which goes out of scope when myfunction() exits. *_mydata ends up pointing to garbage. I'm not completely sure, but i think this can be solved by using: static char mydata[16]; (Btw.: I don't know why you use char ** _mydata, i would use char * _mydata, but then again, i'm not very familiar with ctypes) Jan Kuiken -- http://mail.python.org/mailman/listinfo/python-list
Re: How to program test(expr) ?
On 8/29/2012 11:04 AM, Franck Ditter wrote:
I use Python 3.2.3 + Idle.
Is it possible to program test(e) which takes
an expression e and whose execution produces
at the toplevel an echo of e and the effects
and result of its evaluation ?
No, not as Python is delivered.
# file foo.py
def foo(x) :
print('x =',x)
return x+1
test(foo(5))
# RUN !
# produces at the toplevel :
? foo(5)
x = 5
--> 6
I know I could put the expression e within a string, but
is it possible to avoid the string, like a Lisp macro ?
It might be possible to write an IDLE extension that would 'process'
interactive input looking for (untested) re pattern something like
'test\((.*)\)'. Given a match, it prints the captured .* part and passes
it on to the Python interpreter, and prefixes output with '-->'.
(I have not yet looked at how to write extensions.)
--
Terry Jan Reedy
--
http://mail.python.org/mailman/listinfo/python-list
Re: Sending USB commands with Python
On 29Aug2012 17:57, Dennis Lee Bieber wrote:
| On Wed, 29 Aug 2012 14:21:30 -0700 (PDT), "Adam W."
| declaimed the following in
| gmane.comp.python.general:
| > You are correct about the 2 being the number of bytes written. However
when I issue a read command I get:
| >
| > >>> ep.write('\x1BA')
| > 4
|
| That's interesting -- as if each byte you send is expanding into a
| pair of bytes.
UTF-16? ISTR that Windows often uses big endian UTF-16 for filenames and
text data; could there be some default encoding in ep.write getting in
your way?
Disclaimer: I'm really not a Windows guy.
--
Cameron Simpson
There are too many people now for everyone to be entitled to his own opinion.
- Dr. Handelman
--
http://mail.python.org/mailman/listinfo/python-list
Re: Sending USB commands with Python
On 30Aug2012 08:29, I wrote: | UTF-16? ISTR that Windows often uses big endian UTF-16 [...] Sorry, little-endian. Anyway... -- Cameron Simpson Ed Campbell's pointers for long trips: 3. Stop and take a break before you really need it. -- http://mail.python.org/mailman/listinfo/python-list
Re: "convert" string to bytes without changing data (encoding)
Ross Ridge writes: > > But it is in fact only stored in one particular way, as a series of bytes. > No, it can be stored in different ways. Certainly in Python 3.3 and beyond. And in 3.2 also, depending on wide/narrow build. -- Piet van Oostrum WWW: http://pietvanoostrum.com/ PGP key: [8DAE142BE17999C4] -- http://mail.python.org/mailman/listinfo/python-list
Re: "convert" string to bytes without changing data (encoding)
Heiko Wundram writes: > Reading from stdin/a file gets you bytes, and > not a string, because Python cannot automagically guess what format the > input is in. > Huh? Python 3.3.0rc1 (v3.3.0rc1:8bb5c7bc46ba, Aug 25 2012, 10:09:29) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> x = input() abcd123 >>> x 'abcd123' >>> type(x) >>> y = sys.stdin.readline() abcd123 >>> y 'abcd123\n' >>> type(y) -- Piet van Oostrum WWW: http://pietvanoostrum.com/ PGP key: [8DAE142BE17999C4] -- http://mail.python.org/mailman/listinfo/python-list
Re: Sending USB commands with Python
On Wednesday, August 29, 2012 6:56:16 PM UTC-4, Dennis Lee Bieber wrote:
>
> BUT you do give a possible clue. Is the OP using a 3.x Python where
>
> strings are Unicode -- in which case the above may need to be explicitly
>
> declared as a "byte string" rather than text (unicode) string.
>
Huzzah! I am indeed using 3.x, and slapping on an .encode('utf-8') made my
printer try to spit paper at me! Progress.
Also, astute observation about the endpoint needing to be an input, with the
following modification I get:
>>> ep.write('\x1BA'.encode('utf-8'))
2
>>> ep = usb.util.find_descriptor(
intf,
custom_match = \
lambda e: \
usb.util.endpoint_direction(e.bEndpointAddress) == \
usb.util.ENDPOINT_IN
)
>>> ep.read(1)
array('B', [163])
>>>
Anyone want to venture a guess on how I should interpret that? It seems the
[163] is the byte data the manual is talking about, but why is there a 'B'
there? If I put paper in it and try again I get: array('B', [3])
Thanks for all your help guys, just about ready to stared coding the fun part!
--
http://mail.python.org/mailman/listinfo/python-list
Is socket.recvfrom broken in ActiveState Python 3.2?
Obviously, this my issue, but I cannot figure out what I am doing wrong.
I have the Python echo server example implemented with the server on a Windows
7 computer and the client on a Linux Redhat server.
The line 'data = sock.recv(1024)' works as expected on the Linux client.
However, the line 'data, senderAddr = sock.recvfrom(1024)' does not set the
'senderAddr' to anything.
In the code is this line:
print('RECEIVED:', data, "SENDER:", str(senderAddr))
and this is the output.
RECEIVED: Hello, world SENDER: None
On the Windows 7 server side the line 'data = conn.recv(1024)' works fine.
However, the line 'data, remoteAddr = conn.recvfrom(1024)' gives this output;
DATA: Hello, world FROM: (0,
b'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00')
While I expect this to be my issue, I cannot find an example via Google as to
what I am doing wrong. All examples are pretty much as above.
Any ideas. Is this a bug in 'recvfrom'?
--
http://mail.python.org/mailman/listinfo/python-list
Re: Sending USB commands with Python
On 30/08/2012 00:45, Adam W. wrote:
On Wednesday, August 29, 2012 6:56:16 PM UTC-4, Dennis Lee Bieber wrote:
BUT you do give a possible clue. Is the OP using a 3.x Python where
strings are Unicode -- in which case the above may need to be explicitly
declared as a "byte string" rather than text (unicode) string.
Huzzah! I am indeed using 3.x, and slapping on an .encode('utf-8') made my
printer try to spit paper at me! Progress.
Also, astute observation about the endpoint needing to be an input, with the
following modification I get:
ep.write('\x1BA'.encode('utf-8'))
2
ep = usb.util.find_descriptor(
intf,
custom_match = \
lambda e: \
usb.util.endpoint_direction(e.bEndpointAddress) == \
usb.util.ENDPOINT_IN
)
ep.read(1)
array('B', [163])
Anyone want to venture a guess on how I should interpret that? It seems the
[163] is the byte data the manual is talking about, but why is there a 'B'
there? If I put paper in it and try again I get: array('B', [3])
Thanks for all your help guys, just about ready to stared coding the fun part!
The result is an array of bytes ('B'). I think the value means:
0b10100011
^Ready
^Top of form
^No paper
^Printer error
The error is that it's out of paper.
--
http://mail.python.org/mailman/listinfo/python-list
A sad day for the scientific Python community. John Hunter, creator of matplotlib: 1968-2012.
Dear friends and colleagues, I am terribly saddened to report that yesterday, August 28 2012 at 10am, John D. Hunter died from complications arising from cancer treatment at the University of Chicago hospital, after a brief but intense battle with this terrible illness. John is survived by his wife Miriam, his three daughters Rahel, Ava and Clara, his sisters Layne and Mary, and his mother Sarah. Note: If you decide not to read any further (I know this is a long message), please go to this page for some important information about how you can thank John for everything he gave in a decade of generous contributions to the Python and scientific communities: http://numfocus.org/johnhunter. Just a few weeks ago, John delivered his keynote address at the SciPy 2012 conference in Austin centered around the evolution of matplotlib: http://www.youtube.com/watch?v=e3lTby5RI54 but tragically, shortly after his return home he was diagnosed with advanced colon cancer. This diagnosis was a terrible discovery to us all, but John took it with his usual combination of calm and resolve, and initiated treatment procedures. Unfortunately, the first round of chemotherapy treatments led to severe complications that sent him to the intensive care unit, and despite the best efforts of the University of Chicago medical center staff, he never fully recovered from these. Yesterday morning, he died peacefully at the hospital with his loved ones at his bedside. John fought with grace and courage, enduring every necessary procedure with a smile on his face and a kind word for all of his caretakers and becoming a loved patient of the many teams that ended up involved with his case. This was no surprise for those of us who knew him, but he clearly left a deep and lasting mark even amongst staff hardened by the rigors of oncology floors and intensive care units. I don't need to explain to this community the impact of John's work, but allow me to briefly recap, in case this is read by some who don't know the whole story. In 2002, John was a postdoc at the University of Chicago hospital working on the analysis of epilepsy seizure data in children. Frustrated with the state of the existing proprietary solutions for this class of problems, he started using Python for his work, back when the scientific Python ecosystem was much, much smaller than it is today and this could have been seen as a crazy risk. Furthermore, he found that there were many half-baked solutions for data visualization in Python at the time, but none that truly met his needs. Undeterred, he went on to create matplotlib (http://matplotlib.org) and thus overcome one of the key obstacles for Python to become the best solution for open source scientific and technical computing. Matplotlib is both an amazing technical achievement and a shining example of open source community building, as John not only created its backbone but also fostered the development of a very strong development team, ensuring that the talent of many others could also contribute to this project. The value and importance of this are now painfully clear: despite having lost John, matplotlib continues to thrive thanks to the leadership of Michael Droetboom, the support of Perry Greenfield at the Hubble Telescope Science Institute, and the daily work of the rest of the team. I want to thank Perry and Michael for putting their resources and talent once more behind matplotlib, securing the future of the project. It is difficult to overstate the value and importance of matplotlib, and therefore of John's contributions (which do not end in matplotlib, by the way; but a biography will have to wait for another day...). Python has become a major force in the technical and scientific computing world, leading the open source offers and challenging expensive proprietary platforms with large teams and millions of dollars of resources behind them. But this would be impossible without a solid data visualization tool that would allow both ad-hoc data exploration and the production of complex, fine-tuned figures for papers, reports or websites. John had the vision to make matplotlib easy to use, but powerful and flexible enough to work in graphical user interfaces and as a server-side library, enabling a myriad use cases beyond his personal needs. This means that now, matplotlib powers everything from plots in dissertations and journal articles to custom data analysis projects and websites. And despite having left his academic career a few years ago for a job in industry, he remained engaged enough that as of today, he is still the top committer to matplotlib; this is the git shortlog of those with more than 1000 commits to the project: 2145 John Hunter 2130 Michael Droettboom 1060 Eric Firing All of this was done by a man who had three children to raise and who still always found the time to help those on the mailing lists, solve difficult technical problems in matplotlib, teach courses
Re: [pyxl] xlrd-0.8.0 .xlsx formatting_info=True not implemented
John Yeung wrote: > > is there any other way to tell how many digits excel would round to > > when displaying a floating point number? that's my only reason for > > needing formatting_info=True. > > I have not personally used it, but OpenPyXL is another option for > working with .xlsx files, and it might provide the formatting info you > need: > > http://packages.python.org/openpyxl/index.html > http://pypi.python.org/pypi/openpyxl/1.5.8 > > John Y. thanks but openpyxl doesn't work well enough. most of the spreadsheets i need to read contain dropdown lists with data validation using a named formula like: OFFSET(Data!$K$2,0,0,COUNTA(Data!$K:$K),1) which causes openpyxl to throw a NamedRangeException. i don't even care about the named objects. i just want to know what's in the cell, not what other possible values the cell might have had. :-) apart from that, it does give access to number formats so your suggestion would work for simpler spreadsheets. hopefully the intention that xlrd not support formats in xlsx files will change one day into an intention to support them. :-) until then my users can keep manually saving xlsx files they receive as xls before importing them. :-( maybe i need to investigate some perl modules or pyuno instead. perl's Spreadsheet::XSLX module handles formats. it gets the date formats a bit wrong but it's workaroundable. cheers, raf -- http://mail.python.org/mailman/listinfo/python-list
Re: Sending USB commands with Python
On Wednesday, August 29, 2012 10:07:54 PM UTC-4, Dennis Lee Bieber wrote:
> On Wed, 29 Aug 2012 16:45:10 -0700 (PDT), "Adam W."
>
> I'm a tad curious if using the notation
>
>
>
> b'\x1bA'
>
>
>
> without the .encode() would work.
>
>
>
> My concern is that you may encounter some "string" of data for
>
> printing which the .encode() ends up /changing/ (don't UTF-8 strings use
>
> a high-bit to signal a multi-byte encoding of what had been a single
>
> character?). A pure byte string shouldn't have that problem.
>
Your notation does work, and I was just coming around to reevaluating the use
of the encode because I am getting really odd results when trying to print
lines.
For example I set the byte length to 10 and sent this 500 times or so expecting
to get a solid black bar:
ep.write('\x16FF'.encode('utf-8'))
But what I got was a weird stripped pattern... I feel like a lot of my
commands are working by chance, I can't explain to myself why the A in \x1bA
isn't being treated as part of the hex. This stuff always confuses me.
>
> > >>> ep = usb.util.find_descriptor(
>
> > intf,
>
> > custom_match = \
>
> > lambda e: \
>
> > usb.util.endpoint_direction(e.bEndpointAddress) == \
>
> > usb.util.ENDPOINT_IN
>
> > )
>
>
>
> Seems tedious to keep swapping -- does USB support bidirectional
>
> connections?
>
I assigned the input to ep2 to resolve the switching issue.
--
http://mail.python.org/mailman/listinfo/python-list
Re: A sad day for the scientific Python community. John Hunter, creator of matplotlib: 1968-2012.
May he rest in peace. On Wed, Aug 29, 2012 at 11:41 PM, Fernando Perez wrote: > Dear friends and colleagues, > > I am terribly saddened to report that yesterday, August 28 2012 at > 10am, John D. Hunter died from complications arising from cancer > treatment at the University of Chicago hospital, after a brief but > intense battle with this terrible illness. John is survived by his > wife Miriam, his three daughters Rahel, Ava and Clara, his sisters > Layne and Mary, and his mother Sarah. > > Note: If you decide not to read any further (I know this is a long > message), please go to this page for some important information about > how you can thank John for everything he gave in a decade of generous > contributions to the Python and scientific communities: > http://numfocus.org/johnhunter. > > Just a few weeks ago, John delivered his keynote address at the SciPy > 2012 conference in Austin centered around the evolution of matplotlib: > > http://www.youtube.com/watch?v=e3lTby5RI54 > > but tragically, shortly after his return home he was diagnosed with > advanced colon cancer. This diagnosis was a terrible discovery to us > all, but John took it with his usual combination of calm and resolve, > and initiated treatment procedures. Unfortunately, the first round of > chemotherapy treatments led to severe complications that sent him to > the intensive care unit, and despite the best efforts of the > University of Chicago medical center staff, he never fully recovered > from these. Yesterday morning, he died peacefully at the hospital > with his loved ones at his bedside. John fought with grace and > courage, enduring every necessary procedure with a smile on his face > and a kind word for all of his caretakers and becoming a loved patient > of the many teams that ended up involved with his case. This was no > surprise for those of us who knew him, but he clearly left a deep and > lasting mark even amongst staff hardened by the rigors of oncology > floors and intensive care units. > > I don't need to explain to this community the impact of John's work, > but allow me to briefly recap, in case this is read by some who don't > know the whole story. In 2002, John was a postdoc at the University > of Chicago hospital working on the analysis of epilepsy seizure data > in children. Frustrated with the state of the existing proprietary > solutions for this class of problems, he started using Python for his > work, back when the scientific Python ecosystem was much, much smaller > than it is today and this could have been seen as a crazy risk. > Furthermore, he found that there were many half-baked solutions for > data visualization in Python at the time, but none that truly met his > needs. Undeterred, he went on to create matplotlib > (http://matplotlib.org) and thus overcome one of the key obstacles for > Python to become the best solution for open source scientific and > technical computing. Matplotlib is both an amazing technical > achievement and a shining example of open source community building, > as John not only created its backbone but also fostered the > development of a very strong development team, ensuring that the > talent of many others could also contribute to this project. The > value and importance of this are now painfully clear: despite having > lost John, matplotlib continues to thrive thanks to the leadership of > Michael Droetboom, the support of Perry Greenfield at the Hubble > Telescope Science Institute, and the daily work of the rest of the > team. I want to thank Perry and Michael for putting their resources > and talent once more behind matplotlib, securing the future of the > project. > > It is difficult to overstate the value and importance of matplotlib, > and therefore of John's contributions (which do not end in matplotlib, > by the way; but a biography will have to wait for another day...). > Python has become a major force in the technical and scientific > computing world, leading the open source offers and challenging > expensive proprietary platforms with large teams and millions of > dollars of resources behind them. But this would be impossible without > a solid data visualization tool that would allow both ad-hoc data > exploration and the production of complex, fine-tuned figures for > papers, reports or websites. John had the vision to make matplotlib > easy to use, but powerful and flexible enough to work in graphical > user interfaces and as a server-side library, enabling a myriad use > cases beyond his personal needs. This means that now, matplotlib > powers everything from plots in dissertations and journal articles to > custom data analysis projects and websites. And despite having left > his academic career a few years ago for a job in industry, he remained > engaged enough that as of today, he is still the top committer to > matplotlib; this is the git shortlog of those with more than 1000 > commits to the project: > > 2145 John Hunter > 2130
Re: catch UnicodeDecodeError
On 7/26/2012 5:51 AM, Jaroslav Dobrek wrote:
And the cool thing is: you can! :)
In Python 2.6 and later, the new Py3 open() function is a bit more hidden,
but it's still available:
from io import open
filename = "somefile.txt"
try:
with open(filename, encoding="utf-8") as f:
for line in f:
process_line(line) # actually, I'd use "process_file(f)"
except IOError, e:
print("Reading file %s failed: %s" % (filename, e))
except UnicodeDecodeError, e:
print("Some error occurred decoding file %s: %s" % (filename, e))
Thanks. I might use this in the future.
try:
for line in f: # here text is decoded implicitly
do_something()
except UnicodeDecodeError():
do_something_different()
This isn't possible for syntactic reasons.
Well, you'd normally want to leave out the parentheses after the exception
type, but otherwise, that's perfectly valid Python code. That's how these
things work.
You are right. Of course this is syntactically possible. I was too
rash, sorry. In confused
it with some other construction I once tried. I can't remember it
right now.
But the code above (without the brackets) is semantically bad: The
exception is not caught.
The problem is that vast majority of the thousands of files that I
process are correctly encoded. But then, suddenly, there is a bad
character in a new file. (This is so because most files today are
generated by people who don't know that there is such a thing as
encodings.) And then I need to rewrite my very complex program just
because of one single character in one single file.
Why would that be the case? The places to change should be very local in
your code.
This is the case in a program that has many different functions which
open and parse different
types of files. When I read and parse a directory with such different
types of files, a program that
uses
for line in f:
will not exit with any hint as to where the error occurred. I just
exits with a UnicodeDecodeError. That
means I have to look at all functions that have some variant of
for line in f:
in them. And it is not sufficient to replace the "for line in f" part.
I would have to transform many functions that
work in terms of lines into functions that work in terms of decoded
bytes.
That is why I usually solve the problem by moving fles around until I
find the bad file. Then I recode or repair
the bad file manually.
Would it be reasonable to use pieces of the old program to write a
new program that prints the name for an input file, then searches
that input file for bad characters? If it doesn't find any, it can
then go on to the next input file, or show a message saying that no
bad characters were found.
--
http://mail.python.org/mailman/listinfo/python-list
Re: "convert" string to bytes without changing data (encoding)
On Wed, 29 Aug 2012 19:39:15 -0400, Piet van Oostrum wrote: >> Reading from stdin/a file gets you bytes, and not a string, because >> Python cannot automagically guess what format the input is in. >> > Huh? Oh, it can certainly guess (in the absence of any other information, it uses the current locale). Whether or not that guess is correct is a different matter. Realistically, if you want sensible behaviour from Python 3.x, you need to use an ISO-8859-1 locale. That ensures that conversion between str and bytes will never fail, and an str-bytes-str or bytes-str-bytes round-trip will pass data through unmangled. -- http://mail.python.org/mailman/listinfo/python-list
Re: Dumping all the sql statements as backup
On 7/25/2012 8:56 AM, andrea crotti wrote:
I have some long running processes that do very long simulations which
at the end need to write things on a database.
At the moment sometimes there are network problems and we end up with
half the data on the database.
The half-data problem is probably solved easily with sessions and
sqlalchemy (a db-transaction), but still we would like to be able to
keep a backup SQL file in case something goes badly wrong and we want to
re-run it manually..
This might also be useful if we have to rollback the db for some reasons
to a previous day and we don't want to re-run the simulations..
Anyone did something similar?
It would be nice to do something like:
with CachedDatabase('backup.sql'):
# do all your things
I'm now starting to do something similar, but in C, not Python.
Apparently not using SQL.
The simulations this is for often last a month or more.
--
http://mail.python.org/mailman/listinfo/python-list
