Re: Python Scalability TCP Server + Background Game
> Quick smoke test. How big are your requests/responses? You mention > > REST, which implies they're going to be based on HTTP. I would expect > > you would have some idea of the rough size. Multiply that by 50,000, > > and see whether your connection can handle it. For instance, if you > > have a 100Mbit/s uplink, supporting 50K requests/sec means your > > requests and responses have to fit within about 256 bytes each, > > including all overhead. You'll need a gigabit uplink to be able to > > handle a 2KB request or response, and that's assuming perfect > > throughput. And is 2KB enough for you? > > > > ChrisA My assumption is that there will be mostly reads and some writes; maybe in the order of 80-20%. There is a time element in the game, which forces player's entity to update on-demand. This is part of the reason why I wanted the server to be able to handle so many reques, so that it could handle the read part without having any caching layer. Let me explain a bit more about the architecture, and possible remedies, to give you an idea: * On top are the web servers exposing a REST api. * At the bottom is the game. * Communication betweeen these layers is handled by a simple text protocol using TCP. The game has a tick function every now and then, which forwards the game's time. If a player enters the game, a message is sent to the game server (querying for player details), and if the game's tick is greater than the cached version of the player details, then the game updates the player details (and caches it). This design obviously has its flaws. One being that both reads/writes has to pass through the game server. One way to remedy this is by using a new layer, on top of the game, which would hold the cache. But then another problem arises, that of invalidating the cache when a new tick has been made. I'm leaning towards letting the cache layer check the current tick every now and then, and if new tick is available, update a local variable in the cache (which each new connection would check against). Any thoughts regarding this? There are some periods in the game, where many people will be online during the same tick, which could potentially cause the game to become slow at times, but maybe this should be accepted for the pleasure of making the game in python... :D A follow-up question (which is more to the point really): How does other python game development frameworks solve this issue? Do they not use greenlets for the network layer, to be able to use the shared Queue from multiprocess? Do they only use one process for both network and game operations? On a side note, I'm considering using 0MQ for the message layering between services (web-server <-> cache <-> game) on the back-end. Besides being a great message protocol, it also has built in queues which might be able to remedy the situation when many clients are requesting data. Anyone with experience with regards to this? (This problem can be boggled down multiple producer, single consumer, and then back to producer again). Thanks for all the replies. /Phil -- https://mail.python.org/mailman/listinfo/python-list
Re: numpy.where() and multiple comparisons
On Friday, January 17, 2014 6:16:28 PM UTC-8, duncan smith wrote: > >>> a = np.arange(10) > >>> c = np.where((2 < a) & (a < 7)) > >>> c > (array([3, 4, 5, 6]),) Nice! Thanks! Now, why does the multiple comparison fail, if you happen to know? -- https://mail.python.org/mailman/listinfo/python-list
Re: How to write this as a list comprehension?
On Saturday, January 18, 2014 4:49:55 AM UTC+5:30, Piet van Oostrum wrote: > Hi, > I am looking for an elegant way to write the following code as a list > comprehension: > labels = [] > for then, name in mylist: > _, mn, dy, _, _, _, wd, _, _ = localtime(then) > labels.append(somefunc(mn, day, wd, name)) > So mylist is a list of tuples, the first member of the tuple is a time > (as epoch offset) and I neeed to apply a function on some fields of the > localtime of it. > I could define a auxiliary function like: > def auxfunc(then, name): > _, mn, dy, _, _, _, wd, _, _ = localtime(then) > return somefunc(mn, day, wd, name) > and then use > [auxfunc(then, name) for then, name in mylist] > or even > [auxfunc(*tup) for tup in mylist] > But defining the auxfunc takes away the elegance of a list comprehension. I > would like to integrate the unpacking of localtime() and calling somefunc > within the list comprehension, but I don't see a simple way to do that. > somefunc(mn, day, wd, name) for _, mn, dy, _, _, _, wd, _, _ in > [localtime(then)] > (i.e. using a list comprehension on a one element list to do the variable > shuffling) > works but I don't find that very elegant. > labels = [somefunc(mn, day, wd, name) > for then, name in mylist > for _, mn, dy, _, _, _, wd, _, _ in [localtime(then)]] > Python misses a 'where' or 'let'-like construction as in Haskell. +1 Yes Ive often been bitten by the lack of a 'comprehension-let' Something like this is possible?? [somefunc(mn,day,wd,name) for (_, mn,dy,_,_,_,wd,_,_), name) in [localtime(then), name for then, name in mylist]] Some debugging of the structure will be necessary (if at all possible) I dont have your functions so cant do it -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3.x adoption
In article , Grant Edwards wrote: > On 2014-01-17, Tim Chase wrote: > > On 2014-01-17 15:27, Grant Edwards wrote: > >> > What's wrong?... > >> > >> Python 2.7 still does everything 99% of us need to do, and we're too > >> lazy to switch. > > > > And in most distros, typing "python" invokes 2.x, and explicitly > > typing "python3" is almost 17% longer. We're a lazy bunch! :-) > > And my touch typing accuracy/speed drops pretty noticably when I have > to use the top row of keys... This is why shells have the ability to create aliases, and also why command-line autocomplete was invented :-) -- https://mail.python.org/mailman/listinfo/python-list
Re: numpy.where() and multiple comparisons
On 18/01/14 01:51, John Ladasky wrote: Hi folks, I am awaiting my approval to join the numpy-discussion mailing list, at scipy.org. I realize that would be the best place to ask my question. However, numpy is so widely used, I figure that someone here would be able to help. I like to use numpy.where() to select parts of arrays. I have encountered what I would consider to be a bug when you try to use where() in conjunction with the multiple comparison syntax of Python. Here's a minimal example: Python 3.3.2+ (default, Oct 9 2013, 14:50:09) [GCC 4.8.1] on linux Type "help", "copyright", "credits" or "license" for more information. import numpy as np a = np.arange(10) a array([0, 1, 2, 3, 4, 5, 6, 7, 8, 9]) b = np.where(a < 5) b (array([0, 1, 2, 3, 4]),) c = np.where(2 < a < 7) Traceback (most recent call last): File "", line 1, in ValueError: The truth value of an array with more than one element is ambiguous. Use a.any() or a.all() Defining b works as I want and expect. The array contains the indices (not the values) of a where a < 5. For my definition of c, I expect (array([3, 4, 5, 6]),). As you can see, I get a ValueError instead. I have seen the error message about "the truth value of an array with more than one element" before, and generally I understand how I (accidentally) provoke it. This time, I don't see it. In defining c, I expect to be stepping through a, one element at a time, just as I did when defining b. Does anyone understand why this happens? Is there a smart work-around? Thanks. >>> a = np.arange(10) >>> c = np.where((2 < a) & (a < 7)) >>> c (array([3, 4, 5, 6]),) >>> Duncan -- https://mail.python.org/mailman/listinfo/python-list
numpy.where() and multiple comparisons
Hi folks, I am awaiting my approval to join the numpy-discussion mailing list, at scipy.org. I realize that would be the best place to ask my question. However, numpy is so widely used, I figure that someone here would be able to help. I like to use numpy.where() to select parts of arrays. I have encountered what I would consider to be a bug when you try to use where() in conjunction with the multiple comparison syntax of Python. Here's a minimal example: Python 3.3.2+ (default, Oct 9 2013, 14:50:09) [GCC 4.8.1] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import numpy as np >>> a = np.arange(10) >>> a array([0, 1, 2, 3, 4, 5, 6, 7, 8, 9]) >>> b = np.where(a < 5) >>> b (array([0, 1, 2, 3, 4]),) >>> c = np.where(2 < a < 7) Traceback (most recent call last): File "", line 1, in ValueError: The truth value of an array with more than one element is ambiguous. Use a.any() or a.all() Defining b works as I want and expect. The array contains the indices (not the values) of a where a < 5. For my definition of c, I expect (array([3, 4, 5, 6]),). As you can see, I get a ValueError instead. I have seen the error message about "the truth value of an array with more than one element" before, and generally I understand how I (accidentally) provoke it. This time, I don't see it. In defining c, I expect to be stepping through a, one element at a time, just as I did when defining b. Does anyone understand why this happens? Is there a smart work-around? Thanks. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3.x adoption
Ben Finney writes:
> Terry Reedy writes:
>
> > Since 3.0, we have added new syntax ('yield from', u'' for instance)
> > but I do not believe we have deleted or changed any syntax (I might
> > have forgotten something minor)
>
> I'm aware of the removal of ‘`foo`’ (use ‘repr(foo)’ instead), and
> removal of ‘except ExcClass, exc_instance’ (use ‘except ExcClass as
> exc_instance’ instead).
Ah, you meant “deleted or changed any Python 3 syntax”. No, I'm not
aware of any such changes.
--
\ “I have never imputed to Nature a purpose or a goal, or |
`\anything that could be understood as anthropomorphic.” —Albert |
_o__)Einstein, unsent letter, 1955 |
Ben Finney
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python 3.x adoption
Terry Reedy writes:
> Since 3.0, we have added new syntax ('yield from', u'' for instance)
> but I do not believe we have deleted or changed any syntax (I might
> have forgotten something minor)
I'm aware of the removal of ‘`foo`’ (use ‘repr(foo)’ instead), and
removal of ‘except ExcClass, exc_instance’ (use ‘except ExcClass as
exc_instance’ instead).
--
\ “For my birthday I got a humidifier and a de-humidifier. I put |
`\ them in the same room and let them fight it out.” —Steven Wright |
_o__) |
Ben Finney
--
https://mail.python.org/mailman/listinfo/python-list
Re: setup.py issue - some files are included as intended, but one is not
On Wed, Jan 15, 2014 at 7:18 AM, Piet van Oostrum wrote: > Dan Stromberg writes: > >> On Sat, Jan 11, 2014 at 2:04 PM, Dan Stromberg wrote: >>> Hi folks. >>> >>> I have a setup.py problem that's driving me nuts. >> >> Anyone? I've received 0 responses. > > I can't even install your code because there's a bug in it. > > m4_treap.m4 contains this instruction twice: > > ifdef(/*pyx*/,cp)if current is None: > ifdef(/*pyx*/,cp)raise KeyError > > Which when generating pyx_treap.pyx (with *pyx* defined) expands to the > syntactically incorrect > > cpif current is None: > cpraise KeyError Apologies. I'd fixed that in my source tree, but not checked it in. It's checked in now. -- https://mail.python.org/mailman/listinfo/python-list
Re: How to write this as a list comprehension?
On Fri, Jan 17, 2014 at 3:19 PM, Piet van Oostrum wrote: > Hi, > > I am looking for an elegant way to write the following code as a list > comprehension: > > labels = [] > for then, name in mylist: > _, mn, dy, _, _, _, wd, _, _ = localtime(then) > labels.append(somefunc(mn, day, wd, name)) My recomendation: Don't use a list comprehension. List comprehensions and generator expressions are great for quick little things, but become less readable when you have to string them over multiple physical lines. > labels = [somefunc(mn, day, wd, name) > for then, name in mylist > for _, mn, dy, _, _, _, wd, _, _ in [localtime(then)]] -- https://mail.python.org/mailman/listinfo/python-list
How to write this as a list comprehension?
Hi, I am looking for an elegant way to write the following code as a list comprehension: labels = [] for then, name in mylist: _, mn, dy, _, _, _, wd, _, _ = localtime(then) labels.append(somefunc(mn, day, wd, name)) So mylist is a list of tuples, the first member of the tuple is a time (as epoch offset) and I neeed to apply a function on some fields of the localtime of it. I could define a auxiliary function like: def auxfunc(then, name): _, mn, dy, _, _, _, wd, _, _ = localtime(then) return somefunc(mn, day, wd, name) and then use [auxfunc(then, name) for then, name in mylist] or even [auxfunc(*tup) for tup in mylist] But defining the auxfunc takes away the elegance of a list comprehension. I would like to integrate the unpacking of localtime() and calling somefunc within the list comprehension, but I don't see a simple way to do that. somefunc(mn, day, wd, name) for _, mn, dy, _, _, _, wd, _, _ in [localtime(then)] (i.e. using a list comprehension on a one element list to do the variable shuffling) works but I don't find that very elegant. labels = [somefunc(mn, day, wd, name) for then, name in mylist for _, mn, dy, _, _, _, wd, _, _ in [localtime(then)]] Python misses a 'where' or 'let'-like construction as in Haskell. Anybody has a more elegant solution? -- Piet van Oostrum WWW: http://pietvanoostrum.com/ PGP key: [8DAE142BE17999C4] -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3.x adoption
On Sat, Jan 18, 2014 at 10:12 AM, MRAB wrote:
> On 2014-01-17 23:03, Terry Reedy wrote:
> [snip]
>
>> Since 3.0, we have added new syntax ('yield from', u'' for instance) but
>> I do not believe we have deleted or changed any syntax (I might have
>> forgotten something minor) and I do not know of any proposal to do so
>> (except to re-delete u'', which should only be used as a temporary
>> crutch for 2&3 code).
>>
> There was the removal of backticks.
Wasn't that removed _in_, not _since_, 3.0?
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python 3.x adoption
On 2014-01-17 23:03, Terry Reedy wrote:
[snip]
Since 3.0, we have added new syntax ('yield from', u'' for instance) but
I do not believe we have deleted or changed any syntax (I might have
forgotten something minor) and I do not know of any proposal to do so
(except to re-delete u'', which should only be used as a temporary
crutch for 2&3 code).
There was the removal of backticks.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python 3.x adoption
On 1/17/2014 5:16 PM, beliav...@aol.com wrote:
I don't think the Fortran analogy is valid.
The appropriate analogy for the changes between Python 2.x and 3.x,
which started about 1 and 2 decades after the original Python, are the
changes between Fortran IV/66 and Fortran 77, also about 1 and 2 decades
after the original Fortran. The latter two have a comparable number of
differences. "In this revision of the standard [F77], a number of
features were removed or altered in a manner that might invalidate
previously standard-conforming programs.
https://en.wikipedia.org/wiki/Fortran
Not mentioned in the wiki article is the change in calling convention
from call by value to call by reference (or maybe the opposite). I
remember a program crashing because of this when I tried it with F77.
Overall, there was more churn in Fortran up to F77 than there was in
Python up to 3.0.
The Fortran standards after F77 are almost complete supersets of F77, and
Fortran compiler vendors handle even the deleted parts of F77, knowing their
customer base. Therefore you do not need to rewrite old Fortran code to use it
with Fortran 95 or 2003 compilers, and you can easily mix old-style and modern
Fortran. Later Fortran standards did not invalidate basic syntax such as print
statements, as Python 3 did. Python 2 and 3 are incompatible in ways that do
not apply to Fortran standards pre- and post- F77.
Since 3.0, we have added new syntax ('yield from', u'' for instance) but
I do not believe we have deleted or changed any syntax (I might have
forgotten something minor) and I do not know of any proposal to do so
(except to re-delete u'', which should only be used as a temporary
crutch for 2&3 code).
> Python 2 and 3 are incompatible in ways that do not apply to Fortran
> standards pre- and post- F77.
As stated above, I disagree with respect to pre-F77 and F77. Did you
actually program in both, as I did?
--
Terry Jan Reedy
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python 3.x adoption
On 17/01/2014 22:16, beliav...@aol.com wrote: On Tuesday, January 14, 2014 2:38:29 PM UTC-5, Skip Montanaro wrote: What's the problem with Python 3.x? It was first released in 2008, but web hosting companies still seem to offer Python 2.x rather. For example, Google App Engine only offers Python 2.7. What's wrong?... What makes you think anything's wrong? Major changes to any established piece of software takes a fairly long while to infiltrate. Lots of COBOL and Fortran 77 still running out there. I don't think the Fortran analogy is valid. Later Fortran standards did not invalidate basic syntax such as print statements, as Python 3 did. Python 2 and 3 are incompatible in ways that do not apply to Fortran standards pre- and post- F77. A good choice to make, the capability to use "from __future__ import print_function", or whatever the actual thing is, has been available for years. 2to3 has been available for years, six was released at the end of June 2010 and there's now future, see http://python-future.org/ Admittedly there's a problem with the porting of code which mixes bytes and strings, but that's being addressed right now via PEPs 460, 461 and possibly others. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3.x adoption
On Tuesday, January 14, 2014 2:38:29 PM UTC-5, Skip Montanaro wrote: > > What's the problem with Python 3.x? It was first released in 2008, but > > > web hosting companies still seem to offer Python 2.x rather. > > > > > > For example, Google App Engine only offers Python 2.7. > > > > > > What's wrong?... > > > > What makes you think anything's wrong? Major changes to any > > established piece of software takes a fairly long while to infiltrate. > > Lots of COBOL and Fortran 77 still running out there. I don't think the Fortran analogy is valid. The Fortran standards after F77 are almost complete supersets of F77, and Fortran compiler vendors handle even the deleted parts of F77, knowing their customer base. Therefore you do not need to rewrite old Fortran code to use it with Fortran 95 or 2003 compilers, and you can easily mix old-style and modern Fortran. Later Fortran standards did not invalidate basic syntax such as print statements, as Python 3 did. Python 2 and 3 are incompatible in ways that do not apply to Fortran standards pre- and post- F77. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3.x adoption
On 1/17/2014 10:27 AM, Grant Edwards wrote: On 2014-01-14, Staszek wrote: What's the problem with Python 3.x? The problem with Python 3.x is Python 2.7. ;) Cute. What's wrong?... Python 2.7 still does everything 99% of us need to do, and we're too lazy to switch. While '99' is rhetorical, the statement is accurate for many. The core devs do not expect such people* to switch until they think they would benefit, and even then, only to the version that has enough goodies. * except for authors of widely used libraries ;-), and even then, it ends up being a matter of whether such authors think they will benefit from having 3.x users. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Is it possible to protect python source code by compiling it to .pyc or .pyo?
On 18 January 2014 08:31, Joshua Landau wrote: > On 17 January 2014 00:58, Sam wrote: > > I would like to protect my python source code. It need not be foolproof > as long as it adds inconvenience to pirates. > > > > Is it possible to protect python source code by compiling it to .pyc or > .pyo? Does .pyo offer better protection? > > If you're worried about something akin to corporate espionage or > some-such, I don't know of a better way than ShedSkin or Cython. Both > of those will be far harder to snatch the source of. Cython will be > particularly easy to use as it is largely compatible with Python > codebases. > Indeed - I've only had one time someone absolutely insisted that this be done (for trade secret reasons - there needed to be a good-faith attempt to prevent others from trivially getting the source). I pointed them at Pyrex (this was before Cython, or at least before it was dominant). They fully understood that it wouldn't stop a determined attacker - this was a place where a large number of the developers were used to working on bare metal. If you're going to do this, I strongly suggest only using Cython on code that needs to be obscured (and if applicable, performance-critical sections). I'm currently working with a system which works this way - edge scripts in uncompiled .py files, and inner code as compiled extensions. The .py files have been really useful for interoperability purposes e.g. I was able to verify yesterday that one of the scripts had a bug in its command-line parsing and I wasn't going insane after all. Also, remember that any extension can be imported and poked at (e.g. in the interactive interpreter). You'd be surprised just how much information you can get that way just using help, dir, print and some experimentation. The output I was parsing from one of the scripts was ambiguous, and it was one where most of the work was done in an extension. I was able to poke around using the interactive interpreter understand what it was doing and obtain the data in an unambiguous manner to verify against my parser. The only way to truly protect code is to not ship any version of it (compiled or otherwise), but have the important parts hosted remotely under your control (and do your best to ensure it doesn't become compromised). Tim Delaney -- https://mail.python.org/mailman/listinfo/python-list
Re: [newbie] advice and comment wanted on first tkinter program
On 1/17/2014 8:20 AM, Jean Dupont wrote:
Dear all,
I made a simple gui with tkinter. I can imagine there are things which I
did which are "not optimal". So what I ask is to comment on my code
preferable with snippets of code which show how to do improve my code.
#!/usr/bin/env python
import Tkinter
1. import Tkinter as tk
Besides saving a bit of writing and reading time later, this makes any
future conversion to 3.x easier.
import tkinter as tk
2. add a few spaces to demarcate blocks of code.
import time
import RPi.GPIO as GPIO
2. add a few spaces to demarcate blocks of code, such as here
GPIO.setmode(GPIO.BOARD)
GPIO.setup(26,GPIO.OUT)
GPIO.setup(24,GPIO.OUT)
#hardware : connect 2 leds:
#board-pin 26 on/off led; control with buttons
#board-pin 24 led with pwm dimming and frequency; control via sliders
and here
top = Tkinter.Tk()
top.geometry("600x400+310+290")
This looks strange somehow, but if it works...
label1 = Label(top,relief=RAISED,bg =
"#EFF980",font=("Helvetica",14),height = 1, width = 15)
In calls, put spaces after , but not before and after =.
For other suggestions, see
http://www.python.org/dev/peps/pep-0008/
I suspect that the above is one line in your code and the bad wrapping a
result of mis-spacing. The following is also one line, but easer to read
as spaces separate argument chunks
label1 = Label(top, relief=RAISED, bg="#EFF980", font=("Helvetica",14),
height=1, width=15)
and the wrapping, if any, does not break up an arg chunk.
Some people advocate defining an App class, but Tk and tkinter, even
though object method based, allow the straightforward imperative style
you have used.
I agree with Peter: "First and foremost a program has to do what the
author wants it to do. Everything else is secondary." But a bit of
styling will make reading and changing easier.
--
Terry Jan Reedy
--
https://mail.python.org/mailman/listinfo/python-list
Re: Is it possible to protect python source code by compiling it to .pyc or .pyo?
On 17 January 2014 00:58, Sam wrote: > I would like to protect my python source code. It need not be foolproof as > long as it adds inconvenience to pirates. > > Is it possible to protect python source code by compiling it to .pyc or .pyo? > Does .pyo offer better protection? If you're worried about something akin to corporate espionage or some-such, I don't know of a better way than ShedSkin or Cython. Both of those will be far harder to snatch the source of. Cython will be particularly easy to use as it is largely compatible with Python codebases. I offer no opinions, however, on whether this is a task worth doing. I only suggest you consider the disadvantages and how they apply to your individual case. -- https://mail.python.org/mailman/listinfo/python-list
Re: interactive help on the base object
On 1/17/2014 7:25 AM, Jean-Michel Pichavant wrote: '''The default top superclass for all Python classes. http://bugs.python.org/issue20285 The issue is tagged 2.7. Is object the superclass of all classes in 2.7 ? 2.7 should say 'all new-style classes'. Thanks for noticing and reporting. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: doctests compatibility for python 2 & python 3
On 1/17/2014 7:14 AM, Robin Becker wrote: I tried this approach with a few more complicated outcomes and they fail in python2 or 3 depending on how I try to render the result in the doctest. I never got how you are using doctests. There were certainly not meant for heavy-duty unit testing, but for testing combined with explanation. Section 26.2.3.7. (in 3.3) Warnings warns that they are fragile to even single char changes and suggests == as a workaround, as 'True' and 'False' will not change. So I would not reject that option. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Building and accessing an array of dictionaries
On 2014-01-16, Mark Lawrence wrote:
> On 16/01/2014 09:48, Chris Angelico wrote:
>> On Thu, Jan 16, 2014 at 8:41 PM, Sam wrote:
>>> I would like to build an array of dictionaries. Most of the dictionary
>>> example on the net are for single dictionary.
>>>
>>> dict = {'a':'a','b':'b','c':'c'}
>>> dict2 = {'a':'a','b':'b','c':'c'}
>>> dict3 = {'a':'a','b':'b','c':'c'}
>>>
>>> arr = (dict,dict2,dict3)
>>>
>>> What is the syntax to access the value of dict3->'a'?
>>
>> Technically, that's a tuple of dictionaries
>
> For the benefit of lurkers, newbies or whatever it's the commas that
> make the tuple, not the brackets.
In _that_ example, yes. There are other cases where it's the
brackets (sort of):
foo('a','b','c')# three separate string objects are passed
foo(('a','b','c')) # a single tuple object is passed
--
Grant Edwards grant.b.edwardsYow! Being a BALD HERO
at is almost as FESTIVE as a
gmail.comTATTOOED KNOCKWURST.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Guessing the encoding from a BOM
On 17/01/2014 18:43, Tim Chase wrote: On 2014-01-17 09:10, Mark Lawrence wrote: Slight aside, any chance of changing the subject of this thread, or even ending the thread completely? Why? Every time I see it I picture Inspector Clouseau, "A BOM!!!" :) In discussions regarding BOMs, I regularly get the "All your base" meme from a couple years ago stuck in my head: "Somebody set us up the bomb!" ITYM "Somebody set up us the bomb". -- https://mail.python.org/mailman/listinfo/python-list
Re: Compiling main script into .pyc
On 2014-01-17, Steven D'Aprano wrote:
> On Thu, 16 Jan 2014 23:43:02 -0500, Dave Angel wrote:
> [steve@ando ~]$ cat sample.py
> print("Hello!")
>
> [steve@ando ~]$ ls sample.pyc
> ls: sample.pyc: No such file or directory
> [steve@ando ~]$ python -m compileall sample.py
> Compiling sample.py ...
> [steve@ando ~]$ ls sample.p*
> sample.py sample.pyc
> [steve@ando ~]$ python sample.pyc
> Hello!
Cool! Now I can distribute my application as a pre-compiled "binary"
just like I do for .
[That was meant ironically, BTW]
--
Grant Edwards grant.b.edwardsYow! I want EARS! I want
at two ROUND BLACK EARS
gmail.comto make me feel warm
'n secure!!
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python 3.x adoption
On 2014-01-17, Tim Chase wrote: > On 2014-01-17 15:27, Grant Edwards wrote: >> > What's wrong?... >> >> Python 2.7 still does everything 99% of us need to do, and we're too >> lazy to switch. > > And in most distros, typing "python" invokes 2.x, and explicitly > typing "python3" is almost 17% longer. We're a lazy bunch! :-) And my touch typing accuracy/speed drops pretty noticably when I have to use the top row of keys... -- Grant Edwards grant.b.edwardsYow! Half a mind is a at terrible thing to waste! gmail.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Guessing the encoding from a BOM
On 2014-01-17 09:10, Mark Lawrence wrote: > Slight aside, any chance of changing the subject of this thread, or > even ending the thread completely? Why? Every time I see it I > picture Inspector Clouseau, "A BOM!!!" :) In discussions regarding BOMs, I regularly get the "All your base" meme from a couple years ago stuck in my head: "Somebody set us up the bomb!" (usually in reference to clients sending us files with the aforementioned superfluous UTF-8 BOMs in them) -tkc -- https://mail.python.org/mailman/listinfo/python-list
Re: python2.6 needed as an aptitude package as dependency
On Friday, January 17, 2014 4:24:16 PM UTC+2, Jan Hapala wrote: > Hello, > I need to install a program (MACS: http://liulab.dfci.harvard.edu/MACS/) for > which I need to have Python2.6 installed. > I do have two other Pythons installed but not this version. > I will be grateful for your suggestions, > Jan you can try install from source option explicitly specifying python version from command line. guess for altinstall it should be python2.6 python2.6 setup.py install --prefix /home/taoliu/ https://github.com/taoliu/MACS/blob/master/INSTALL.rst /Asaf -- https://mail.python.org/mailman/listinfo/python-list
Re: Guessing the encoding from a BOM
On 01/17/2014 08:46 AM, Pete Forman wrote: Chris Angelico writes: On Fri, Jan 17, 2014 at 8:10 PM, Mark Lawrence wrote: Slight aside, any chance of changing the subject of this thread, or even ending the thread completely? Why? Every time I see it I picture Inspector Clouseau, "A BOM!!!" :) Special delivery, a berm! Were you expecting one? Endian detection: Does my BOM look big in this? LOL! -- ~Ethan~ -- https://mail.python.org/mailman/listinfo/python-list
Re: Python glob and raw string
On 17/01/2014 16:45, Xaxa Urtiz wrote: [masses of double spaced lines snipped] Would you please read and action this https://wiki.python.org/moin/GoogleGroupsPython to prevent us seeing the double line spacing in your posts, thanks. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: Templating engines that work very well with Python/Django
On Fri, Jan 17, 2014 at 6:22 PM, San D wrote: > Can someone suggest a few templating engines that work really well with > Django and help in coding efficiency? > > Where can I fin comparison of tempating engines I can find to know their pros > and cons? I believe the most widely used template engine in Django is "The Django template language" itself :) https://docs.djangoproject.com/en/dev/topics/templates/ However the cool kids are always talking about switching to jinja2, a simple google search like jinja2 django could be a good starting point for finding good comparatives between both. -- Marc -- https://mail.python.org/mailman/listinfo/python-list
Re: Graph or Chart Software for Django
On Fri, Jan 17, 2014 at 6:18 PM, San D wrote: > What is the best Graph or Chart software used with Django (libraries & > products), preferably open source? > > Need something stable and robust, and used by many developers, so active on > community channels. what I use is a JS library called highcharts, the django-side are only views that dump some data in json format perhaps in django-users mailing list you'll be able to find better answers than here :) -- Marc -- https://mail.python.org/mailman/listinfo/python-list
Templating engines that work very well with Python/Django
Can someone suggest a few templating engines that work really well with Django and help in coding efficiency? Where can I fin comparison of tempating engines I can find to know their pros and cons? Thanks. -- https://mail.python.org/mailman/listinfo/python-list
Graph or Chart Software for Django
What is the best Graph or Chart software used with Django (libraries & products), preferably open source? Need something stable and robust, and used by many developers, so active on community channels. Thanks. -- https://mail.python.org/mailman/listinfo/python-list
Re: Compiling main script into .pyc
On Thu, 16 Jan 2014 17:01:51 -0800, Sam wrote: > One thing I observe about python byte-code compiling is that the main > script does not gets compiled into .pyc. Only imported modules are > compiled into .pyc. > > May I know how can I compile the main script into .pyc? It is to > inconvenience potential copy-cats. if you want to stop casual programmers reading your code to see how you have achieved something don't bother. 1) your code is not that 'Clever'(Hopefully) 2) 'Clever' code is seldom worth copying * * 'Clever' code usually makes use of obscure functions, side effects & other features that make it difficult to follow & maintain just skim through www.thedailywtf.com for examples of 'Clever' code that should never have seen the light of day. if you have found a straight forward way to achive complex goal such that it is worth copying rest assured it will be copied no mater how hard you try to protect it. -- #define SIGILL 6 /* blech */ -- Larry Wall in perl.c from the perl source code -- https://mail.python.org/mailman/listinfo/python-list
Re: Guessing the encoding from a BOM
On Sat, Jan 18, 2014 at 3:30 AM, Rustom Mody wrote: > If you or I break a standard then, well, we broke a standard. > If Microsoft breaks a standard the standard is obliged to change. > > Or as the saying goes, everyone is equal though some are more equal. https://en.wikipedia.org/wiki/800_pound_gorilla Though Microsoft has been losing weight over the past decade or so, just as IBM before them had done (there was a time when IBM was *the* 800lb gorilla, pretty much, but definitely not now). In Unix/POSIX contexts, Linux might be playing that role - I've seen code that unwittingly assumes Linux more often than, say, assuming FreeBSD - but I haven't seen a huge amount of "the standard has to change, Linux does it differently", possibly because the areas of Linux-assumption are areas that aren't standardized anyway (eg additional socket options beyond the spec). The one area where industry leaders still heavily dictate to standards is the web. Fortunately, it usually still results in usable standards documents that HTML authors can rely on. Usually. *twiddles fingers* ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Guessing the encoding from a BOM
Chris Angelico writes: > On Fri, Jan 17, 2014 at 8:10 PM, Mark Lawrence > wrote: >> Slight aside, any chance of changing the subject of this thread, or even >> ending the thread completely? Why? Every time I see it I picture Inspector >> Clouseau, "A BOM!!!" :) > > Special delivery, a berm! Were you expecting one? Endian detection: Does my BOM look big in this? -- Pete Forman -- https://mail.python.org/mailman/listinfo/python-list
Re: Python glob and raw string
Le jeudi 16 janvier 2014 19:14:30 UTC+1, Neil Cerutti a écrit :
> On 2014-01-16, Xaxa Urtiz <> wrote:
>
> > Hello everybody, i've got a little problem, i've made a script
>
> > which look after some files in some directory, typically my
>
> > folder are organized like this :
>
> >
>
> > [share]
>
> > folder1
>
> > ->20131201
>
> > -->file1.xml
>
> > -->file2.txt
>
> > ->20131202
>
> > -->file9696009.tmp
>
> > -->file421378932.xml
>
> > etc
>
> > so basically in the share i've got some folder
>
> > (=folder1,folder2.) and inside these folder i've got these
>
> > folder whose name is the date (20131201,20131202,20131203
>
> > etc...) and inside them i want to find all the xml files.
>
> > So, what i've done is to iterate over all the folder1/2/3 that
>
> > i want and look, for each one, the xml file with that:
>
> >
>
> > for f in glob.glob(dir +r"\20140115\*.xml"):
>
> > ->yield f
>
> >
>
> > dir is the folder1/2/3 everything is ok but i want to do
>
> > something like that :
>
> >
>
> > for i in range(10,16):
>
> > ->for f in glob.glob(dir +r"\201401{0}\*.xml".format(i)):
>
> > -->yield f
>
> >
>
> > but the glob does not find any file (and of course there is
>
> > some xml and the old way found them...)
>
> > Any help would be appreciate :)
>
>
>
> I've done this two different ways. The simple way is very similar
>
> to what you are now doing. It sucks because I have to manually
>
> maintain the list of subdirectories to traverse every time I
>
> create a new subdir.
>
>
>
> Here's the other way, using glob and isdir from os.path, adapted
>
> from actual production code.
>
>
>
> class Miner:
>
> def __init__(self, archive):
>
> # setup goes here; prepare to acquire the data
>
> self.descend(os.path.join(archive, '*'))
>
>
>
> def descend(self, path):
>
> for fname in glob.glob(os.path.join(path, '*')):
>
> if os.path.isdir(fname):
>
> self.descend(fname)
>
> else:
>
> self.process(fname)
>
>
>
> def process(self, path):
>
> # Do what I want done with an actual file path.
>
> # This is where I add to the data.
>
>
>
> In your case you might not want to process unless the path also
>
> looks like an xml file.
>
>
>
> mine = Miner('myxmldir')
>
>
>
> Hmmm... I might be doing too much in __init__. ;)
>
>
>
> --
>
> Neil Cerutti
i only have 1 level of subdirectory, it's just in the case when i don't want to
process all the date (otherwise i make a glob on '/*/*', no need to do any
recursion.
thanks for the answer !
--
https://mail.python.org/mailman/listinfo/python-list
Re: Guessing the encoding from a BOM
On Sat, Jan 18, 2014 at 3:26 AM, Pete Forman wrote: > It would have been nice if there was an eighth encoding scheme defined > there UTF-8NB which would be UTF-8 with BOM not allowed. Or call that one UTF-8, and the one with the marker can be UTF-8-MS-NOTEPAD. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Guessing the encoding from a BOM
On Friday, January 17, 2014 9:56:28 PM UTC+5:30, Pete Forman wrote: > Rustom Mody writes: > > On Friday, January 17, 2014 7:10:05 AM UTC+5:30, Tim Chase wrote: > >> On 2014-01-17 11:14, Chris Angelico wrote: > >> > UTF-8 specifies the byte order > >> > as part of the protocol, so you don't need to mark it. > >> You don't need to mark it when writing, but some idiots use it > >> anyway. If you're sniffing a file for purposes of reading, you need > >> to look for it and remove it from the actual data that gets returned > >> from the file--otherwise, your data can see it as corruption. I end > >> up with lots of CSV files from customers who have polluted it with > >> Notepad or had Excel insert some UTF-8 BOM when exporting. This > >> means my first column-name gets the BOM prefixed onto it when the > >> file is passed to csv.DictReader, grr. > > And its part of the standard: > > Table 2.4 here > > http://www.unicode.org/versions/Unicode5.0.0/ch02.pdf > It would have been nice if there was an eighth encoding scheme defined > there UTF-8NB which would be UTF-8 with BOM not allowed. If you or I break a standard then, well, we broke a standard. If Microsoft breaks a standard the standard is obliged to change. Or as the saying goes, everyone is equal though some are more equal. -- https://mail.python.org/mailman/listinfo/python-list
Re: Guessing the encoding from a BOM
Rustom Mody writes: > On Friday, January 17, 2014 7:10:05 AM UTC+5:30, Tim Chase wrote: >> On 2014-01-17 11:14, Chris Angelico wrote: >> > UTF-8 specifies the byte order >> > as part of the protocol, so you don't need to mark it. > >> You don't need to mark it when writing, but some idiots use it >> anyway. If you're sniffing a file for purposes of reading, you need >> to look for it and remove it from the actual data that gets returned >> from the file--otherwise, your data can see it as corruption. I end >> up with lots of CSV files from customers who have polluted it with >> Notepad or had Excel insert some UTF-8 BOM when exporting. This >> means my first column-name gets the BOM prefixed onto it when the >> file is passed to csv.DictReader, grr. > > And its part of the standard: > Table 2.4 here > http://www.unicode.org/versions/Unicode5.0.0/ch02.pdf It would have been nice if there was an eighth encoding scheme defined there UTF-8NB which would be UTF-8 with BOM not allowed. -- Pete Forman -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3.x adoption
On 17/01/2014 16:15, Tim Chase wrote: On 2014-01-17 15:27, Grant Edwards wrote: What's wrong?... Python 2.7 still does everything 99% of us need to do, and we're too lazy to switch. And in most distros, typing "python" invokes 2.x, and explicitly typing "python3" is almost 17% longer. We're a lazy bunch! :-) -tkc For the really lazy the obvious solution is to switch to Windows where it's simply "py -2" or "py -3". -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: doctests compatibility for python 2 & python 3
On 17/01/2014 15:27, Steven D'Aprano wrote: .. # -*- coding: utf-8 -*- def func(a): """ >>> print(func(u'aaa\u020b')) aaa╚ï """ return a There seems to be some mojibake in your post, which confuses issues. You refer to \u020b, which is LATIN SMALL LETTER I WITH INVERTED BREVE. At least, that's what it ought to be. But in your post, it shows up as the two character mojibake, ╚ followed by ï (BOX DRAWINGS DOUBLE UP AND RIGHT followed by LATIN SMALL LETTER I WITH DIAERESIS). It appears that your posting software somehow got confused and inserted the two characters which you would have got using cp-437 while claiming that they are UTF-8. (Your post is correctly labelled as UTF-8.) I'm confident that the problem isn't with my newsreader, Pan, because it is pretty damn good at getting encodings right, but also because your post shows the same mojibake in the email archive: https://mail.python.org/pipermail/python-list/2014-January/664771.html To clarify: you tried to show \u020B as a literal. As a literal, it ought to be the single character ȋ which is a lower case I with curved accent on top. The UTF-8 of that character is b'\xc8\x8b', which in the cp-437 code page is two characters ╚ ï. when I edit the file in vim with ut88 encoding I do see your ȋ as the literal. However, as you note I'm on windows and no amount of cajoling will get it to work reasonably so my printouts are broken. So on windows (py27) C:\code\hg-repos>python -c"print(u'aaa\u020b')" aaa╚ï on my linux $ python2 -c"print(u'aaa\u020b')" aaaȋ $ python2 tdt1.py /usr/lib/python2.7/doctest.py:1531: UnicodeWarning: Unicode equal comparison failed to convert both arguments to Unicode - interpreting them as being unequal if got == want: /usr/lib/python2.7/doctest.py:1551: UnicodeWarning: Unicode equal comparison failed to convert both arguments to Unicode - interpreting them as being unequal if got == want: ** File "tdt1.py", line 4, in __main__.func Failed example: print(func(u'aaa\u020b')) Expected: aaaȋ Got: aaaȋ ** 1 items had failures: 1 of 1 in __main__.func ***Test Failed*** 1 failures. robin@everest ~/tmp: $ cat tdt1.py # -*- coding: utf-8 -*- def func(a): """ >>> print(func(u'aaa\u020b')) aaaȋ """ return a def _doctest(): import doctest doctest.testmod() if __name__ == "__main__": _doctest() robin@everest ~/tmp: so the error persists with our without copying errors. Note that on my putty terminal I don't see the character properly (I see unknown glyph square box), but it copies OK. -- Robin Becker -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3.x adoption
On 2014-01-17 15:27, Grant Edwards wrote: > > What's wrong?... > > Python 2.7 still does everything 99% of us need to do, and we're too > lazy to switch. And in most distros, typing "python" invokes 2.x, and explicitly typing "python3" is almost 17% longer. We're a lazy bunch! :-) -tkc -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3.x adoption
On 2014-01-14, Staszek wrote: > What's the problem with Python 3.x? The problem with Python 3.x is Python 2.7. ;) > What's wrong?... Python 2.7 still does everything 99% of us need to do, and we're too lazy to switch. -- Grant Edwards grant.b.edwardsYow! We have DIFFERENT at amounts of HAIR -- gmail.com -- https://mail.python.org/mailman/listinfo/python-list
Re: doctests compatibility for python 2 & python 3
On Fri, 17 Jan 2014 12:12:35 +, Robin Becker wrote:
> On 17/01/2014 11:41, Steven D'Aprano wrote:
>> def func(a):
>> """
>> >>> print(func(u'aaa'))
>> aaa
>> """
>> return a
>
> I think this approach seems to work if I turn the docstring into unicode
>
> def func(a):
> u"""
> >>> print(func(u'aaa\u020b'))
> aaa\u020b
> """
> return a
Good catch! Without the u-prefix, the \u... is not interpreted as an
escape sequence, but as a literal backslash-u.
> If I leave the u off the docstring it goes wrong in python 2.7. I also
> tried to put an encoding onto the file and use the actual utf8
> characters ie
>
> # -*- coding: utf-8 -*-
> def func(a):
> """
> >>> print(func(u'aaa\u020b'))
> aaaȋ
> """
> return a
There seems to be some mojibake in your post, which confuses issues.
You refer to \u020b, which is LATIN SMALL LETTER I WITH INVERTED BREVE.
At least, that's what it ought to be. But in your post, it shows up as
the two character mojibake, ╚ followed by ï (BOX DRAWINGS DOUBLE UP AND
RIGHT followed by LATIN SMALL LETTER I WITH DIAERESIS). It appears that
your posting software somehow got confused and inserted the two
characters which you would have got using cp-437 while claiming that they
are UTF-8. (Your post is correctly labelled as UTF-8.)
I'm confident that the problem isn't with my newsreader, Pan, because it
is pretty damn good at getting encodings right, but also because your
post shows the same mojibake in the email archive:
https://mail.python.org/pipermail/python-list/2014-January/664771.html
To clarify: you tried to show \u020B as a literal. As a literal, it ought
to be the single character ȋ which is a lower case I with curved accent on
top. The UTF-8 of that character is b'\xc8\x8b', which in the cp-437 code
page is two characters ╚ ï.
py> '\u020b'.encode('utf8').decode('cp437')
'ȋ'
Hence, mojibake.
> def _doctest():
> import doctest
> doctest.testmod()
>
> and that works in python3, but fails in python 2 with this
>> (py27) C:\code\hg-repos>python tdt1.py C:\python\Lib\doctest.py:1531:
>> UnicodeWarning: Unicode equal comparison failed to convert both
>> arguments to Unicode - in terpreting them as being unequal
>> if got == want:
>> C:\python\Lib\doctest.py:1551: UnicodeWarning: Unicode equal comparison
>> failed to convert both arguments to Unicode - in terpreting them as
>> being unequal
I cannot replicate this specific exception. I think it may be a side-
effect of you being on Windows. (I'm on Linux, and everything is UTF-8.)
>> if got == want:
>> **
>> File "tdt1.py", line 4, in __main__.func Failed example:
>> print(func(u'aaa\u020b'))
>> Expected:
>> aaaȋ
>> Got:
>> aaaȋ
The difficulty here is that it is damn near impossible to sort out which,
if any, bits are mojibake inserted by your posting software, which by
your editor, your terminal, which by Python, and which are artifacts of
the doctest system.
The usual way to debug these sorts of errors is to stick a call to repr()
just before the print.
print(repr(func(u'aaa\u020b')))
--
Steven
--
https://mail.python.org/mailman/listinfo/python-list
Re: [newbie] advice and comment wanted on first tkinter program
Jean Dupont wrote:
> Dear all,
> I made a simple gui with tkinter. I can imagine there are things which I
> did which are "not optimal". So what I ask is to comment on my code
> preferable with snippets of code which show how to do improve my code.
> #!/usr/bin/env python
> import Tkinter
> import time
> import RPi.GPIO as GPIO
> GPIO.setmode(GPIO.BOARD)
> GPIO.setup(26,GPIO.OUT)
> GPIO.setup(24,GPIO.OUT)
> #hardware : connect 2 leds:
> #board-pin 26 on/off led; control with buttons
> #board-pin 24 led with pwm dimming and frequency; control via sliders
> top = Tkinter.Tk()
> top.geometry("600x400+310+290")
> var1 = DoubleVar()
> var2 = DoubleVar()
> i=0
> p=GPIO.PWM(24,1)
> p.start(50)
> def btn_on_cmd():
> text3.configure(bg = "#00FF00")
> text3.delete(0.1,END)
> text3.insert("0.1","ON ")
> GPIO.output(26,True)
> def btn_off_cmd():
> text3.configure(bg = "#FF4000")
> text3.delete(0.1,END)
> text3.insert("0.1","OFF")
> GPIO.output(26, False)
> def timer0():
> global i
> i=i+1
> text1.delete(0.1,END)
> text1.insert(4.2,"Timer: " + str(i))
> label1.configure(text=time.strftime("%H:%M:%S"))
> top.after(1000, timer0)
> def Set_PWM(var1):
> DC = float(var1)
> p.ChangeDutyCycle(DC)
> def Set_FREQ(var2):
> FR = float(var2)
> p.ChangeFrequency(FR)
> btn_on = Button(top, text ="On", command = btn_on_cmd)
> btn_on.place(x=10,y=100)
> btn_off = Button(top, text ="Off", command = btn_off_cmd)
> btn_off.place(x=100,y=100)
> text1 =Text(top, bg = "#009BFF", font=("Helvetica",14), height = 1, width
> = 15)
> text1.place(x=5,y=5)
> text3=Text(top, bg = "red", font=("Helvetica",12),height = 1, width = 4)
> text3.place(x=60,y=60)
> label1 = Label(top,relief=RAISED,bg =
> "#EFF980",font=("Helvetica",14),height = 1, width = 15)
> label1.place(x=5,y=350)
> label2= Label(top,relief=RAISED,bg =
> "#BFBFBF",font=("Helvetica",10),height = 1, text= "Freq (Hz)")
> label2.place(x=420,y=320)
> label3= Label(top,relief=RAISED,bg =
> "#BFBFBF",font=("Helvetica",10),height = 1, text= "DC %")
> label3.place(x=520,y=320)
> slider1 = Scale(top,variable = var1,length = 300,resolution = 1,command =
> Set_PWM)
> slider1 = Scale(top,variable = var1,length = 300,resolution = 1,command =
> Set_PWM) slider1.place(x=500,y=5)
> slider1.set(50)
> slider2 = Scale(top,variable = var2,length = 300,from_= 0.1, to =
> 50,resolution = 0.1,command = Set_FREQ) slider2.place(x=400,y=5)
> slider2.set(2)
> timer0()
> top.mainloop()
> GPIO.cleanup()
>
>
> thanks in advance
> jean
First and foremost a program has to do what the author wants it to do.
Everything else is secondary. You are likely to have such a program on your
machine, so congrats :)
However, the version you posted does not run, probably because you started
to replace
from Tkinter import *
top = Tk()
...
var1 = DoubleVar()
with the -- better --
import Tkinter
top = Tkinter.Tk()
...
but stopped too early, so that the line
var1 = DoubleVar
will raise a NameError. The fix is mechanical: run the program, go to the
line with the NameError and add the 'Tkinter.' prefix.
Once you have done that you should take the time to find good variable
names. var1? I have no idea what value that could hold until I've read the
whole program. That's feasible here, but program size may grow over time,
and can you still tell me what var1 means next week? I recommend names that
reflect the problem domain, e. g. `var_dutycycle` or just `dutycycle`.
Next you should consider grouping the code by topic -- not necessarily into
functions; having a section that does the setup for the dutycycle data and
widgets and one for the time etc., visually separated by one or two empty
lines should be sufficient.
If you're ambitious you should read up on the grid layout manager. I allows
widget size to change depending on the window size.
The Text widget can be used to write whole Editors (like IDLE) -- it does no
harm here, but seems a bit heavyweight for just an On/Off display. I would
go with a Label or Entry.
What does a red widget with no text mean, by the way? On, off, or undefined?
Personally, I like to start with a defined state. An easy way to achieve
this is to call
button_off_cmd() # or button_on_cmd()
manually before your program enters the mainloop() -- just like you did with
timer0().
PS: An easy way to get an idea of what a script does is to run it. I'd guess
that by keeping the Rasperry-Pi-specific code in you are reducing the number
of readers who can do that by a few orders of magnitude. I managed to get it
to run with the following ad-hoc changes:
$ diff -u raspberry_orig.py raspberry_mock.py
--- raspberry_orig.py 2014-01-17 16:10:20.843334832 +0100
+++ raspberry_mock.py 2014-01-17 16:10:58.970855503 +0100
@@ -1,7 +1,36 @@
#!/usr/bin/env python
import Tkinter
+from Tkinter import *
import time
-import RPi.GPIO as GPIO
+
+try:
+
Re: python2.6 needed as an aptitude package as dependency
On Sat, Jan 18, 2014 at 1:24 AM, Jan Hapala wrote: > I need to install a program (MACS: http://liulab.dfci.harvard.edu/MACS/) for > which I need to have Python2.6 installed. > > I do have two other Pythons installed but not this version. Is one of those Pythons a 2.7? If so, MACS will probably run with that. The only problem is that the dpkg installer doesn't know that you have the right dependencies. This isn't a Python question, it's a Debian packaging one, but I happen to know one of the ways to deal with this: the 'equivs' system. Since you've now installed Python 2.6 from source, you do have it, so all you need to do is make a dummy package called (or providing) python2.6. http://www.debian.org/doc/manuals/apt-howto/ch-helpers.en.html I used this system at work for several packages where I wanted to run a newer version of something than the repos provided. Saved us a lot of hassle. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python declarative
El miércoles, 15 de enero de 2014 18:02:08 UTC+1, Sergio Tortosa Benedito
escribió:
> Hi I'm developing a sort of language extension for writing GUI programs
>
> called guilang, right now it's written in Lua but I'm considreing Python
>
> instead (because it's more tailored to alone applications). My question
>
> it's if I can achieve this declarative-thing in python. Here's an
>
> example:
>
>
>
> Window "myWindow" {
>
> title="Hello world";
>
> Button "myButton" {
>
> label="I'm a button";
>
> onClick=exit
>
> }
>
> }
>
> print(myWindow.myButton.label)
>
>
>
> Of course it doesn't need to be 100% equal. Thanks in advance
>
>
>
> Sergio
Wow thank you very much, really. I wasn't expecting that much from everyone.
BTW, sorry for no answering earlier , I'm receiving no e-mails from the list
(I'll look later what happens). First, I don't like that all parenthesis, I
like to differentiate which type of delimiter is, this is not so bad if using
spaces but anyways it's a little more difficult.Second, In regard, to using
something like myWindow=Window rather than Window "myWindow", at first I didn't
liked it that much, but in the end it does tell the user that the attributes
can be accesed just like anything else. Finally , the project I'm developing
(guilang) it's toolkit-independent so I don't mind having to do some wrappers.
Sergio
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python declarative
Some time ago I played with Tkinter trying a more declarative way of coding the GUI building part and I come out with this: top = Tk( 'top' ).add ( Frame( 'frame' ).add ( Pack( side = 'top' ), Frame ( 'panel1' ).add ( Pack( side='left'), Label ( 'label', text="Entry 1 : " ), Entry ( 'entry' ) ), Frame( 'panel2' ).add ( Pack( side='left'), Label ( 'label', text="Entry 2 : " ), Entry( 'entry' ) ), Pack( side = 'bottom' ), # packing change Button( 'button', text='Click Me' )) ) top.frame.button["command"] = functools.partial(button_cb, top) top.realize().mainloop() which, without changing the underlying plumbing, may also be written this way, which avoid nesting but still looks declarative-ish : top = Tk( 'top' ) top.add( Frame( 'frame' ) ) top.frame.add ( Pack( side = 'top' ), Frame ( 'panel1' ), Frame( 'panel2' ), Pack( side = 'bottom' ), # packing change Button( 'button', text='Click Me', command = functools.partial(button_cb, top) ) ) top.frame.panel1.add( Pack( side='left'), Label ( 'label', text="Entry 1 : " ), Entry ( 'entry' ) ) top.frame.panel2.add( Pack( side='left'), Label ( 'label', text="Entry 1 : " ), Entry( 'entry' ) ) top.realize().mainloop() The underlying plumbing for those two examples is just two classes amounting to about fifty lines of code, plus one-liner wrappers for each kind of widgets/geometry This just to tell you that yes, with python you can write declarative-looking code ... if you don't mind parenthesis :-) -- https://mail.python.org/mailman/listinfo/python-list
python2.6 needed as an aptitude package as dependency
Hello, I need to install a program (MACS: http://liulab.dfci.harvard.edu/MACS/) for which I need to have Python2.6 installed. I do have two other Pythons installed but not this version. 1) So I tried apt-get install... python2.6 is not there as a package (I am running Linux Mint 15). 2) Okay, I added some repos to the /etc/apt/sources.list: deb http://packages.linuxmint.com/ debian main upstream import deb http://debian.linuxmint.com/latest testing main contrib non-free deb http://debian.linuxmint.com/latest/security testing/updates main contrib non-free deb http://debian.linuxmint.com/latest/multimedia testing main non-free I ran apt-get update... python2.6 not there 3) I downloaded python2.6 as a source tar and compiled it and installed with make altinstall... Python2.6 is installed. When I enter "python" in the command line and hit Tab, I can see there now all three versions of python. Still I get the same error: dpkg: dependency problems prevent configuration of macs: macs depends on python2.6; however: Package python2.6 is not installed. I will be grateful for your suggestions, Jan -- https://mail.python.org/mailman/listinfo/python-list
[newbie] advice and comment wanted on first tkinter program
Dear all,
I made a simple gui with tkinter. I can imagine there are things which I
did which are "not optimal". So what I ask is to comment on my code
preferable with snippets of code which show how to do improve my code.
#!/usr/bin/env python
import Tkinter
import time
import RPi.GPIO as GPIO
GPIO.setmode(GPIO.BOARD)
GPIO.setup(26,GPIO.OUT)
GPIO.setup(24,GPIO.OUT)
#hardware : connect 2 leds:
#board-pin 26 on/off led; control with buttons
#board-pin 24 led with pwm dimming and frequency; control via sliders
top = Tkinter.Tk()
top.geometry("600x400+310+290")
var1 = DoubleVar()
var2 = DoubleVar()
i=0
p=GPIO.PWM(24,1)
p.start(50)
def btn_on_cmd():
text3.configure(bg = "#00FF00")
text3.delete(0.1,END)
text3.insert("0.1","ON ")
GPIO.output(26,True)
def btn_off_cmd():
text3.configure(bg = "#FF4000")
text3.delete(0.1,END)
text3.insert("0.1","OFF")
GPIO.output(26, False)
def timer0():
global i
i=i+1
text1.delete(0.1,END)
text1.insert(4.2,"Timer: " + str(i))
label1.configure(text=time.strftime("%H:%M:%S"))
top.after(1000, timer0)
def Set_PWM(var1):
DC = float(var1)
p.ChangeDutyCycle(DC)
def Set_FREQ(var2):
FR = float(var2)
p.ChangeFrequency(FR)
btn_on = Button(top, text ="On", command = btn_on_cmd)
btn_on.place(x=10,y=100)
btn_off = Button(top, text ="Off", command = btn_off_cmd)
btn_off.place(x=100,y=100)
text1 =Text(top, bg = "#009BFF", font=("Helvetica",14), height = 1, width
= 15)
text1.place(x=5,y=5)
text3=Text(top, bg = "red", font=("Helvetica",12),height = 1, width = 4)
text3.place(x=60,y=60)
label1 = Label(top,relief=RAISED,bg =
"#EFF980",font=("Helvetica",14),height = 1, width = 15)
label1.place(x=5,y=350)
label2= Label(top,relief=RAISED,bg =
"#BFBFBF",font=("Helvetica",10),height = 1, text= "Freq (Hz)")
label2.place(x=420,y=320)
label3= Label(top,relief=RAISED,bg =
"#BFBFBF",font=("Helvetica",10),height = 1, text= "DC %")
label3.place(x=520,y=320)
slider1 = Scale(top,variable = var1,length = 300,resolution = 1,command =
Set_PWM)
slider1 = Scale(top,variable = var1,length = 300,resolution = 1,command =
Set_PWM)
slider1.place(x=500,y=5)
slider1.set(50)
slider2 = Scale(top,variable = var2,length = 300,from_= 0.1, to = 50,resolution
= 0.1,command = Set_FREQ)
slider2.place(x=400,y=5)
slider2.set(2)
timer0()
top.mainloop()
GPIO.cleanup()
thanks in advance
jean
--
https://mail.python.org/mailman/listinfo/python-list
Re: EuroPython has a new blog
Hi Marc-André, Cool for EuroPython, Good idea, I think we will use tumblr for a small blog for Python-FOSDEM. Stef On 17 Jan 2014, at 13:37, M.-A. Lemburg wrote: > The EuroPython Society has setup a new blog for EuroPython in its > efforts to provide more conference facilities for the EuroPython > organization and to enhance the EuroPython attendee experience. > > http://blog.europython.eu/ > > There’s an RSS feed in case you want to subscribe to it: > > http://blog.europython.eu/rss > > The blog itself is hosted on Tumblr, so you can also follow the blog > using your Tumblr account: log in, visit the blog and click “Follow" in > the upper right corner: > > http://www.tumblr.com/follow/europython > > If you’re looking for older blog entries, please check the > EuroPython 2013 blog, which lists the entries for 2011-2013: > > https://ep2013.europython.eu/blog/ > > Enjoy, > -- > Marc-Andre Lemburg > Director > EuroPython Society > http://www.europython-society.org/ > -- > https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
EuroPython Society website now live
The EuroPython Society has created a new website to collect information on EuroPython, the society and its workings: http://www.europython-society.org/ For those who don’t know: the society is a Swedish non-profit organization which was formed in 2004 by the EuroPython organizers to put on EuroPython conferences. A new board was voted in at the EuroPython 2012 conference: https://ep2013.europython.eu/blog/2012/07/08/change-board-europython-society Given the size of EuroPython conferences, we’re working on formalizing the EuroPython selection process, providing resources and arranging with local teams to run EuroPython conferences: http://www.europython-society.org/cfp We consider the EuroPython Society the representation of the EuroPython attendees, so if you have questions, requests for improvements or other ideas on how to improve the series, please feel free to contact us: http://www.europython-society.org/contact You can also become members of the EuroPython Society at no charge and then vote at the general assembly of the society. Please visit our members page for more information: http://www.europython-society.org/members Enjoy, -- Marc-Andre Lemburg Director EuroPython Society http://www.europython-society.org/ -- https://mail.python.org/mailman/listinfo/python-list
EuroPython has a new blog
The EuroPython Society has setup a new blog for EuroPython in its efforts to provide more conference facilities for the EuroPython organization and to enhance the EuroPython attendee experience. http://blog.europython.eu/ There’s an RSS feed in case you want to subscribe to it: http://blog.europython.eu/rss The blog itself is hosted on Tumblr, so you can also follow the blog using your Tumblr account: log in, visit the blog and click “Follow" in the upper right corner: http://www.tumblr.com/follow/europython If you’re looking for older blog entries, please check the EuroPython 2013 blog, which lists the entries for 2011-2013: https://ep2013.europython.eu/blog/ Enjoy, -- Marc-Andre Lemburg Director EuroPython Society http://www.europython-society.org/ -- https://mail.python.org/mailman/listinfo/python-list
Re: interactive help on the base object
- Original Message - > On 17/01/2014 01:00, Terry Reedy wrote: > > On 12/6/2013 8:35 PM, Terry Reedy wrote: > >> On 12/6/2013 12:03 PM, Mark Lawrence wrote: > >>> Is it just me, or is this basically useless? > >>> > >>> >>> help(object) > >>> Help on class object in module builtins: > >>> > >>> class object > >>> | The most base type > >> > >> Given that this can be interpreted as 'least desirable', it could > >> definitely be improved. > >> > >>> Surely a few more words, > >> > >> How about something like. > >> > >> '''The default top superclass for all Python classes. > >> > >> Its methods are inherited by all classes unless overriden. > >> ''' > >> > >> When you have 1 or more concrete suggestions for the docstring, > >> open a > >> tracker issue. > > > > At Mark's invitation, I have done so. > > http://bugs.python.org/issue20285 > > > > Thanks, I've altered my will accordingly :) > > > -- > My fellow Pythonistas, ask not what our language can do for you, ask > what you can do for our language. > > Mark Lawrence The issue is tagged 2.7. Is object the superclass of all classes in 2.7 ? I'm asking because in 2.5, it is not (old/new style). JM -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -- https://mail.python.org/mailman/listinfo/python-list
Re: doctests compatibility for python 2 & python 3
On 17/01/2014 11:30, Chris Angelico wrote: On Fri, Jan 17, 2014 at 10:24 PM, Chris Angelico wrote: Do your test strings contain any non-ASCII characters? If not, you might be able to do this: def func(a): """ >>> str(func(u'aaa')) 'aaa' """ return a Actually, probably better than that: def func(a): """ >>> text(func(u'aaa')) 'aaa' """ return a try: class text(unicode): # Will throw NameError in Py3 def __repr__(self): return unicode.__repr__(self)[1:] except NameError: # Python 3 doesn't need this wrapper. text = str Little helper class that does what I don't think monkey-patching will do. I've tested this and it appears to work in both 2.7.4 and 3.4.0b2, but that doesn't necessarily mean that the repr of any given Unicode string will be exactly the same on both versions. It's likely to be better than depending on the strings being ASCII, though. ChrisA I tried this approach with a few more complicated outcomes and they fail in python2 or 3 depending on how I try to render the result in the doctest. -- Robin Becker -- https://mail.python.org/mailman/listinfo/python-list
Re: doctests compatibility for python 2 & python 3
On 17/01/2014 11:41, Steven D'Aprano wrote: def func(a): """ >>> print(func(u'aaa')) aaa """ return a I think this approach seems to work if I turn the docstring into unicode def func(a): u""" >>> print(func(u'aaa\u020b')) aaa\u020b """ return a def _doctest(): import doctest doctest.testmod() if __name__ == "__main__": _doctest() If I leave the u off the docstring it goes wrong in python 2.7. I also tried to put an encoding onto the file and use the actual utf8 characters ie # -*- coding: utf-8 -*- def func(a): """ >>> print(func(u'aaa\u020b')) aaaȋ """ return a def _doctest(): import doctest doctest.testmod() and that works in python3, but fails in python 2 with this (py27) C:\code\hg-repos>python tdt1.py C:\python\Lib\doctest.py:1531: UnicodeWarning: Unicode equal comparison failed to convert both arguments to Unicode - in terpreting them as being unequal if got == want: C:\python\Lib\doctest.py:1551: UnicodeWarning: Unicode equal comparison failed to convert both arguments to Unicode - in terpreting them as being unequal if got == want: ** File "tdt1.py", line 4, in __main__.func Failed example: print(func(u'aaa\u020b')) Expected: aaaȋ Got: aaaȋ ** 1 items had failures: 1 of 1 in __main__.func ***Test Failed*** 1 failures. -- Robin Becker -- https://mail.python.org/mailman/listinfo/python-list
Re: doctests compatibility for python 2 & python 3
On Fri, 17 Jan 2014 11:16:17 +, Robin Becker wrote: > I have some problems making some doctests for python2 code compatible > with python3. The problem is that as part of our approach we are > converting the code to use unicode internally. So we allow eihter byte > strings or unicode in inputs, but we are trying to convert to unicode > outputs. Alas, I think you've run into one of the weaknesses of doctest. Don't get me wrong, I am a huge fan of doctest, but it is hard to write polyglot string tests with it, as you have discovered. However, you may be able to get 95% of the way by using print. def func(a): """ >>> print(func(u'aaa')) aaa """ return a ought to behave identically in both Python 2 and Python 3.3, provided you only print one object at a time. This ought to work with both ASCII and non-ASCII (at least in the BMP). -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: doctests compatibility for python 2 & python 3
On Fri, Jan 17, 2014 at 10:24 PM, Chris Angelico wrote: > Do your test strings contain any non-ASCII characters? If not, you > might be able to do this: > > def func(a): > """ > >>> str(func(u'aaa')) > 'aaa' > """ > return a Actually, probably better than that: def func(a): """ >>> text(func(u'aaa')) 'aaa' """ return a try: class text(unicode): # Will throw NameError in Py3 def __repr__(self): return unicode.__repr__(self)[1:] except NameError: # Python 3 doesn't need this wrapper. text = str Little helper class that does what I don't think monkey-patching will do. I've tested this and it appears to work in both 2.7.4 and 3.4.0b2, but that doesn't necessarily mean that the repr of any given Unicode string will be exactly the same on both versions. It's likely to be better than depending on the strings being ASCII, though. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: doctests compatibility for python 2 & python 3
On Fri, Jan 17, 2014 at 10:16 PM, Robin Becker wrote: > Aside from changing the tests so they look like > """ > >>> func(u'aaa')==u'aaa' > True > """ Do your test strings contain any non-ASCII characters? If not, you might be able to do this: def func(a): """ >>> str(func(u'aaa')) 'aaa' """ return a which should work in both. In Py3, the str() call will do nothing, and it'll compare correctly; in Py2, it'll convert it into a byte string, which will repr() without the 'u'. I don't think it's possible to monkey-patch unicode.__repr__ to not put the u'' prefix on, but if there is a way, that'd possibly be more convenient. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
doctests compatibility for python 2 & python 3
I have some problems making some doctests for python2 code compatible with python3. The problem is that as part of our approach we are converting the code to use unicode internally. So we allow eihter byte strings or unicode in inputs, but we are trying to convert to unicode outputs. That makes doctests quite hard as def func(a): """ >>> func(u'aaa') 'aaa' """ return a fails in python2 whilst def func(a): """ >>> func(u'aaa') u'aaa' """ return a fails in python3. Aside from changing the tests so they look like """ >>> func(u'aaa')==u'aaa' True """ which make the test utility harder. If the test fails I don't see the actual outcome and expected I see expected True got False. Is there an easy way to make these kinds of tests work in python 2 & 3? -- Robin Becker -- https://mail.python.org/mailman/listinfo/python-list
Re: Guessing the encoding from a BOM
On Fri, Jan 17, 2014 at 8:47 PM, Mark Lawrence wrote: > On 17/01/2014 09:43, Chris Angelico wrote: >> >> On Fri, Jan 17, 2014 at 8:10 PM, Mark Lawrence >> wrote: >>> >>> Slight aside, any chance of changing the subject of this thread, or even >>> ending the thread completely? Why? Every time I see it I picture >>> Inspector >>> Clouseau, "A BOM!!!" :) >> >> >> Special delivery, a berm! Were you expecting one? >> >> ChrisA >> > > By coincidence I'm just off to collect a special delievry, of what I don't > yet know. Did you write a script to buy you something for a dollar off eBay every day? Day six gets interesting, as I understand it. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Guessing the encoding from a BOM
On 17/01/2014 09:43, Chris Angelico wrote: On Fri, Jan 17, 2014 at 8:10 PM, Mark Lawrence wrote: Slight aside, any chance of changing the subject of this thread, or even ending the thread completely? Why? Every time I see it I picture Inspector Clouseau, "A BOM!!!" :) Special delivery, a berm! Were you expecting one? ChrisA By coincidence I'm just off to collect a special delievry, of what I don't yet know. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: Guessing the encoding from a BOM
On Fri, Jan 17, 2014 at 8:10 PM, Mark Lawrence wrote: > Slight aside, any chance of changing the subject of this thread, or even > ending the thread completely? Why? Every time I see it I picture Inspector > Clouseau, "A BOM!!!" :) Special delivery, a berm! Were you expecting one? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: extracting string.Template substitution placeholders
On 17/01/2014 06:07, gmflanagan wrote:
On Sunday, January 12, 2014 3:08:31 PM UTC, Eric S. Johansson wrote:
As part of speech recognition accessibility tools that I'm building, I'm
using string.Template. In order to construct on-the-fly grammar, I need
to know all of the identifiers before the template is filled in. what is
the best way to do this?
Try this:
import string
cmplxstr="""a simple $string a longer $string a $last line ${another} one"""
def finditer(s):
for match in string.Template.pattern.finditer(s):
arg = match.group('braced') or match.group('named')
if arg:
yield arg
if __name__ == '__main__':
print set(finditer(cmplxstr))
Would you please read and action this
https://wiki.python.org/moin/GoogleGroupsPython to prevent us seeing the
double line spacing above, thanks.
--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.
Mark Lawrence
--
https://mail.python.org/mailman/listinfo/python-list
Re: Process datafeed in one MySql table and output to another MySql table
On 17/01/2014 08:53, Sam wrote: On Friday, January 17, 2014 10:07:58 AM UTC+8, Denis McMahon wrote: On Thu, 16 Jan 2014 17:03:24 -0800, Sam wrote: I have a datafeed which is constantly sent to a MySql table ... Which are the python libraries which are suitable for this purpose? Are there any useful sample code or project on the web that I can use as reference? Did you search for mysql on the python docs website, or perhaps try googling "python mysql"? I did. There were documentation but I was hoping to have more sample code. Preferably a similar project which I can use as reference. -- Denis McMahon, denismfmcma...@gmail.com Would you please read and action this https://wiki.python.org/moin/GoogleGroupsPython to prevent us seeing the double line spacing above, thanks. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: interactive help on the base object
On 17/01/2014 01:00, Terry Reedy wrote: On 12/6/2013 8:35 PM, Terry Reedy wrote: On 12/6/2013 12:03 PM, Mark Lawrence wrote: Is it just me, or is this basically useless? >>> help(object) Help on class object in module builtins: class object | The most base type Given that this can be interpreted as 'least desirable', it could definitely be improved. Surely a few more words, How about something like. '''The default top superclass for all Python classes. Its methods are inherited by all classes unless overriden. ''' When you have 1 or more concrete suggestions for the docstring, open a tracker issue. At Mark's invitation, I have done so. http://bugs.python.org/issue20285 Thanks, I've altered my will accordingly :) -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: Guessing the encoding from a BOM
On 17/01/2014 01:40, Tim Chase wrote: On 2014-01-17 11:14, Chris Angelico wrote: UTF-8 specifies the byte order as part of the protocol, so you don't need to mark it. You don't need to mark it when writing, but some idiots use it anyway. If you're sniffing a file for purposes of reading, you need to look for it and remove it from the actual data that gets returned from the file--otherwise, your data can see it as corruption. I end up with lots of CSV files from customers who have polluted it with Notepad or had Excel insert some UTF-8 BOM when exporting. This means my first column-name gets the BOM prefixed onto it when the file is passed to csv.DictReader, grr. -tkc My code that used to handle CSV files from M$ Money had to allow for a single NUL byte right at the end of the file. Thankfully I've now moved on to gnucash. Slight aside, any chance of changing the subject of this thread, or even ending the thread completely? Why? Every time I see it I picture Inspector Clouseau, "A BOM!!!" :) -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: Converting folders of jpegs to single pdf per folder
On 17/01/2014 05:42, vasishtha.sp...@gmail.com wrote:
> try:
> n = 0
> for dirpath, dirnames, filenames in os.walk(root):
> PdfOutputFileName = os.path.basename(dirpath) + ".pdf"
> c = canvas.Canvas(PdfOutputFileName)
> if n > 0 :
>for filename in filenames:
> LowerCaseFileName = filename.lower()
> if LowerCaseFileName.endswith(".jpg"):
> print(filename)
> filepath= os.path.join(dirpath, filename)
> print(filepath)
> im = ImageReader(filepath)
> imagesize = im.getSize()
> c.setPageSize(imagesize)
> c.drawImage(filepath,0,0)
> c.showPage()
> c.save()
> n = n + 1
> print "PDF of Image directory created" + PdfOutputFileName
>
> except:
> print "Failed creating PDF"
> -
One thing I would point out (assuming that this is your final code):
your try-except is too broad, both in terms of the code it encloses and
in terms of the exceptions it traps.
As it stands, your code will drop straight out as soon as it hits an
error, with the message "Failed creating PDF" -- which is what it would
have done anyway, only you've removed the informative traceback which
would have told you what went wrong!
In the circumstances, you presumably want to attempt to recover from
some failure (perhaps caused by a corrupt JPEG or a permissions issue)
and continue to generate the remaning PDFs. In that case, you'd do
better a structure of this sort:
import logging
logging.basicConfig()
for d, ds, fs in os.walk("..."):
# init pdf
try:
# create PDF
except:
logging.exception("Couldn't create PDF for %s", d)
continue
else:
logging.info("Created PDF for %s", d)
# write PDF
If you could narrow down the range of exceptions you want to recover
from, that would go in the "except:" clause, but in this situation you
might not be in a position to do that.
TJG
--
https://mail.python.org/mailman/listinfo/python-list
Re: Process datafeed in one MySql table and output to another MySql table
On Friday, January 17, 2014 10:07:58 AM UTC+8, Denis McMahon wrote: > On Thu, 16 Jan 2014 17:03:24 -0800, Sam wrote: > > > > > I have a datafeed which is constantly sent to a MySql table ... > > > > > Which are the python libraries which are suitable for this purpose? Are > > > there any useful sample code or project on the web that I can use as > > > reference? > > > > Did you search for mysql on the python docs website, or perhaps try > > googling "python mysql"? > I did. There were documentation but I was hoping to have more sample code. Preferably a similar project which I can use as reference. > > > -- > > Denis McMahon, denismfmcma...@gmail.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Converting folders of jpegs to single pdf per folder
On 17/01/2014 05:42, vasishtha.sp...@gmail.com wrote: > On Thursday, January 16, 2014 12:07:59 PM UTC-8, Tim Golden wrote: >> >> Here's a quick example. This should walk down the Python directory, >> creating a text file for each directory. The textfile will contain >> the names of all the files in the directory. (NB this might create >> a lot of text files so run it inside some temp directory). [.. snip sample code ...] > > Thanks Tim. It worked like a charm and saved me weeks of work using > a drag and drop utility. About 250 pdf files created of 50 to 100 > pages each. Heres the code in case any one else can use it. [snip] Glad it was helpful. And thanks for coming back with the solution: hopefully future searchers will find it useful. (And it's a great advert for how easy it is to do useful things in just a few lines of Python). TJG -- https://mail.python.org/mailman/listinfo/python-list
Re: Compiling main script into .pyc
On Thu, 16 Jan 2014 23:43:02 -0500, Dave Angel wrote:
> MRAB Wrote in message:
>> On 2014-01-17 02:56, bob gailer wrote:
>>> On 1/16/2014 8:01 PM, Sam wrote:
One thing I observe about python byte-code compiling is that the main
script does not gets compiled into .pyc. Only imported modules are
compiled into .pyc.
May I know how can I compile the main script into .pyc?
>>> Duh? Just import it!
>>>
>> What if you want to just compile it? Importing will run it!
>>
>>
>>
> Importing will only run the portion of the code not protected by
>
> if __name__ == "__main__":
Nevertheless, there is no need to run *any* of the code just to compile
it.
[steve@ando ~]$ cat sample.py
print("Hello!")
[steve@ando ~]$ ls sample.pyc
ls: sample.pyc: No such file or directory
[steve@ando ~]$ python -m compileall sample.py
Compiling sample.py ...
[steve@ando ~]$ ls sample.p*
sample.py sample.pyc
[steve@ando ~]$ python sample.pyc
Hello!
--
Steven
--
https://mail.python.org/mailman/listinfo/python-list
