Re: are int, float, long, double, side-effects of computer engineering?
On Mar 5, 9:26 pm, Tim Roberts wrote: > Xah Lee wrote: > > >some additional info i thought is relevant. > > >are int, float, long, double, side-effects of computer engineering? > > Of course they are. Such concepts violate the purity of a computer > language's abstraction of the underlying hardware. We accept that > violation because of performance reasons. There are, as you point out, > languages that do maintain the purity of the abstraction, but that purity > is ALWAYS at the expense of performance. > > I would also point out pre-emptively that there is nothing inherently wrong > with asking us to accept an impure abstraction in exchange for performance. > It is a performance choice that we choose to make. while what you said is true, but the problem is that 99.99% of programers do NOT know this. They do not know Mathematica. They've never seen a language with such feature. The concept is alien. This is what i'd like to point out and spread awareness. also, argument about raw speed and fine control vs automatic management, rots with time. Happened with auto memory management, managed code, compilers, auto type conversion, auto extension of array, auto type system, dynamic/scripting languages, etc. i'd share this these talks: 〈Programing Language: Steve Yegge on Dynamic Languages〉 http://xahlee.org/comp/Steve_Yegge_on_dynamic_languages.html 〈Guy Steele on Parallel Programing: Get rid of cons!〉 http://xahlee.org/comp/Guy_Steele_parallel_computing.html 〈Ocaml Use in Industry (Janestreet Talk by Yaron Minsky)〉 http://xahlee.org/comp/Yaron_Minsky_Janestreet_talk.html 〈Stephen Wolfram: The Background and Vision of Mathematica 〉 http://xahlee.blogspot.com/2011/10/stephen-wolfram-background-and-vision.html Xah -- http://mail.python.org/mailman/listinfo/python-list
Re: are int, float, long, double, side-effects of computer engineering?
Xah Lee wrote: > >some additional info i thought is relevant. > >are int, float, long, double, side-effects of computer engineering? Of course they are. Such concepts violate the purity of a computer language's abstraction of the underlying hardware. We accept that violation because of performance reasons. There are, as you point out, languages that do maintain the purity of the abstraction, but that purity is ALWAYS at the expense of performance. I would also point out pre-emptively that there is nothing inherently wrong with asking us to accept an impure abstraction in exchange for performance. It is a performance choice that we choose to make. -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc. -- http://mail.python.org/mailman/listinfo/python-list
Re: are int, float, long, double, side-effects of computer engineering?
On Mon, Mar 05, 2012 at 05:11:09PM -0800, Xah Lee wrote: > some additional info i thought is relevant. > > are int, float, long, double, side-effects of computer engineering? > > Xah Lee wrote: > «… One easy way to measure it is whether a programer can read and > understand a program without having to delve into its idiosyncrasies. > …» > > Chris Angelico wrote: > «Neither the behavior of ints nor the behavior of IEEE floating point > is a "quirk" or an "idiosyncracy". …» > > they are computer engineering by-products. Are quirks and > idiosyncracies. Check out a advanced lang such as Mathematica. There, > one can learn how the mathematical concept of integer or real number > are implemented in a computer language, without lots by-products of > comp engineering as in vast majority of langs (all those that chalks > up to some IEEE. (which, sadly, includes C, C++, perl, python, > lisp, and almost all. (Common/Scheme lisp idiots speak of the jargon > “number tower” instead I.) (part of the reason almost all langs > stick to some I stuff is because it's kinda standard, and > everyone understand it, in the sense that unix RFC (aka really fucking > common) is wide-spread because its free yet technically worst. (in a > sense, when everybody's stupid, there arise a cost to not be > stupid.. > > > A friend asked: «Can you enlighten us as to Mathematica's way of > handling numbers, either by a post or a link to suitable > documentation? …» > > what i meant to point out is that Mathematica deals with numbers at a > high-level human way. That is, one doesn't think in terms of float, > long, int, double. These words are never mentioned. Instead, you have > concepts of machine precision, accuracy. The lang automatically handle > the translation to hardware, and invoking exact value or infinite > precision as required or requested. > > in most lang's doc, words like int, long, double, float are part of > the lang, and it's quick to mention IEEE. Then you have the wide- > spread overflow issue in your lang. In M, the programer only need to > think in terms of math, i.e. Real number, Integer, complex number, > precision, accuracy, etc. > > this is what i meat that most lang deals with computer engineering by- > products, and i wished them to be higher level like M. > > http://reference.wolfram.com/mathematica/guide/PrecisionAndAccuracyControl.html Try Fortran. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: Why aren't my widgets expanding when I resize the window?
On 06/03/2012 02:56, Rick Johnson wrote: On Mar 5, 8:33 pm, Mark Lawrence wrote: please stick with the Light rather than the Dark Side. You're correct. I need to ignore these negative distractions. Thanks for re-focusing the conversation. No problem, but as I've often stated in the past my normal professional fee applies which is two (2) pints of Ringwood Old Thumper or equivalent should you ever be in my neck of the woods. :) http://www.ringwoodbrewery.co.uk/beers/beer.aspx?bid=3 -- Cheers. Mark Lawrence. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: Why aren't my widgets expanding when I resize the window?
On Mar 5, 8:33 pm, Mark Lawrence wrote: > please stick with the > Light rather than the Dark Side. You're correct. I need to ignore these negative distractions. Thanks for re-focusing the conversation. -- http://mail.python.org/mailman/listinfo/python-list
Re: Error with co_filename when loading modules from zip file
On Mon, Mar 05, 2012 at 02:22:55PM -0800, Vinay Sajip wrote: > On Mar 5, 8:36 pm, Bob wrote: > > > The logging package gets the filename and line number > > of the calling function by looking at two variables, the filename > > of the frame in the stack trace and the variable logging._srcfile. > > The comparison is done in logging/__init__.py:findCaller. > > > > The _srcfile is computed in logging/__init__.py - can you see which of > the paths it takes when computing _srcfile? > > > I've tried putting only the pyc files, only the py files > > and both in the zip file. > > I think the filename info might be stored in the .pyc from when you > ran it outside the .zip. If you delete all .pyc files and only > have .py in the .zip, what happens? Darn it, this was reported in 2007 http://bugs.python.org/issue1180193 and it was mentioned the logging package was effected. Yikes. Any resolutions? Bob -- http://mail.python.org/mailman/listinfo/python-list
Re: RotatingFileHandler Fails
On Mar 5, 4:27 am, Jean-Michel Pichavant
wrote:
> nac wrote:
> > The RotatingFileHandler running on win 7 64-bit; py 2.7 is failing
> > when the script launches a process using subprocess.Popen. Works fine
> > if the subprocess is not launched
>
> > The exception thrown
> > Traceback (most recent call last):
> > File "C:\Python27\lib\logging\handlers.py", line 78, in emit
> > self.doRollover()
> > File "C:\Python27\lib\logging\handlers.py", line 141, in doRollover
> > os.rename(self.baseFilename, dfn)
> > WindowsError: [Error 32] The process cannot access the file because it
> > is being used by another process
>
> > Anyone have an idea how to fix this?
>
> > import os, sys
> > import logging
> > import logging.handlers
> > import subprocess
>
> > def chomp(s):
> > "remove trailing carriage return"
> > if s[-1:]=='\n': return s[:-1]
> > else: return s
>
> > logging.basicConfig(level=logging.DEBUG, format='%(asctime)s %
> > (name)-2s %(levelname)-8s %(threadName)-12s %(message)s')
> > q5Logger = logging.getLogger('Q5')
> > logFileHandler = logging.handlers.RotatingFileHandler(filename='c:\
> > \logger\\q5.log', mode= 'a', maxBytes=100, backupCount=5)
> > logFileHandler.setFormatter(logging.Formatter('%(asctime)s %(name)-2s %
> > (levelname)-8s %(threadName)-12s %(message)s'))
> > logFileHandler.setLevel(logging.DEBUG)
> > q5Logger.addHandler(logFileHandler)
>
> > progOutput = subprocess.Popen(r'dir *.*', shell=True, bufsize=1000,
> > stdout=subprocess.PIPE).stdout
> > line = progOutput.readline()
> > while (line) != "":
> > q5Logger.info( chomp(line))
> > line = progOutput.readline()
> > rc = progOutput.close()
>
> I don't think you can open a file from 2 different processes, hence the
> error message. The only exception would be that one of them opens it in
> read only mode which won't happen for log file.
>
> You cannot fix it, it is the operand system that blocks the operation.
> Using thread may allow you to log into the same file, but could bring a
> bunch of other problems.
>
> I know some ppl use a log server, your processes using a socket (client)
> logger. You could do that on your local machine. There's a tutorial on
> that in the logging documentation.
>
> JM
Thanks for taking the time to look at the problem. In case you are
interested I was able to get this to work with the code at URL below.
Seemed to work because the subprocess I am running is not actually
using the log file but the OS make it inherit a handle to the log
file. The code below disables that inheritance. Do you see any
problems with the approach?
http://bugs.python.org/file14420/NTSafeLogging.py
--
http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: Why aren't my widgets expanding when I resize the window?
On 06/03/2012 02:20, Rick Johnson wrote: On Mar 5, 7:10 pm, Steven D'Aprano wrote: John, it is polite to leave attributions in place when you quote somebody. I don't know who you are quoting above, [...] Which is a pity, because I gather that Rick actually does know Tkinter well. My, my. Between your ad hominem attacks, FUD, wild assumptions, and veiled insults you did manage to get ONE small sentence of truthful content to propagate up; congratulations! Excuse me whist i toss my cookies! But dealing with him is like wrestling with a pig: And there it is again. We can't admit Rick is correct without insulting him. But Steven, when have you EVER dealt with me on a professional level? When have you EVER offered a helping hand to one of my issues? For example: I can remember asking you to explain the new .format method of Py3000 and you said: "Sorry, too busy!". But you where not too busy to troll-up the list! WHEN have you ever admitted (without insulting me first) that i am in fact an asset to this community? Do you think this community will ever be a homogeneous block? And if so, would that be a good thing? I have an idea: How about YOU stop clinging to some archaic ideal of what YOU *think* this community *should* be, and instead, start opening up your mind to diverse personalities and diverse ideas. Heck, maybe you'll learn something new, "old dog". Remember how much you ranted about diversity in evolution? And now you have the AUDACITY to preach the opposite just to suit your own selfish argument. You are as hollow as a politician Steven. Nothing that you say can be taken seriously because it is just more propaganda and lies. And one more thing, If ANYONE on this list deserves "thespian of the year" award, it is you my friend! Between your comeo appearances as "Devils Advocate", "Sammy the Strawman Stuffer", "Snarky Detractor", and the ever-present "Troll Slayer" (saving damsels in distress from the trolls of c.l.p) -- i'd say you have the nomination won by a landslide! There is no need for this. You (as I've stated in another reply) seem to know what you're talking about WRT tkinter so please stick with the Light rather than the Dark Side. -- Cheers. Mark Lawrence. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: Why aren't my widgets expanding when I resize the window?
On Mar 5, 7:10 pm, Steven D'Aprano wrote: > John, it is polite to leave attributions in place when you quote > somebody. I don't know who you are quoting above, > [...] > Which is a pity, because I gather that Rick actually does know Tkinter > well. My, my. Between your ad hominem attacks, FUD, wild assumptions, and veiled insults you did manage to get ONE small sentence of truthful content to propagate up; congratulations! Excuse me whist i toss my cookies! > But dealing with him is like wrestling with a pig: And there it is again. We can't admit Rick is correct without insulting him. But Steven, when have you EVER dealt with me on a professional level? When have you EVER offered a helping hand to one of my issues? For example: I can remember asking you to explain the new .format method of Py3000 and you said: "Sorry, too busy!". But you where not too busy to troll-up the list! WHEN have you ever admitted (without insulting me first) that i am in fact an asset to this community? Do you think this community will ever be a homogeneous block? And if so, would that be a good thing? I have an idea: How about YOU stop clinging to some archaic ideal of what YOU *think* this community *should* be, and instead, start opening up your mind to diverse personalities and diverse ideas. Heck, maybe you'll learn something new, "old dog". Remember how much you ranted about diversity in evolution? And now you have the AUDACITY to preach the opposite just to suit your own selfish argument. You are as hollow as a politician Steven. Nothing that you say can be taken seriously because it is just more propaganda and lies. And one more thing, If ANYONE on this list deserves "thespian of the year" award, it is you my friend! Between your comeo appearances as "Devils Advocate", "Sammy the Strawman Stuffer", "Snarky Detractor", and the ever-present "Troll Slayer" (saving damsels in distress from the trolls of c.l.p) -- i'd say you have the nomination won by a landslide! -- http://mail.python.org/mailman/listinfo/python-list
Re: Error with co_filename when loading modules from zip file
On Mon, Mar 05, 2012 at 02:22:55PM -0800, Vinay Sajip wrote: > On Mar 5, 8:36 pm, Bob wrote: > > > The logging package gets the filename and line number > > of the calling function by looking at two variables, the filename > > of the frame in the stack trace and the variable logging._srcfile. > > The comparison is done in logging/__init__.py:findCaller. > > > > The _srcfile is computed in logging/__init__.py - can you see which of > the paths it takes when computing _srcfile? Yes, it's this one, elif __file__[-4:].lower() in ['.pyc', '.pyo']: _srcfile = __file__[:-4] + '.py' _srcfile I beleive is correct. It's filename that isn't IMHO. > > I've tried putting only the pyc files, only the py files > > and both in the zip file. > > I think the filename info might be stored in the .pyc from when you > ran it outside the .zip. If you delete all .pyc files and only > have .py in the .zip, what happens? Nice one. I tried putting only pyc file, only py files and both in the zip. But I never tried putting the py files in the zip and deleting the pyc files. That makes it work as I'm guessing it has to recompile the python bytecode, making the filename and _srcfile match. The problem with this approach, is that it's less efficient to store the pyc files, since I've got to recompile them on startup, right? I found this issue, http://bugs.python.org/issue6811 and this related patch, http://hg.python.org/cpython/rev/5deb2094f033 that I think might address this issue. Although that's using 3.3 which isn't released yet. This is probably an issue that could be addressed in the logging library. Comparing the compiled in filename (which is determined at compile time) and the source file name (which is determined at module load time) doesn't seem to play well when you are moving the interpreter around in a zip file. I don't think one would expect it to. One solution would be to look to see if the filename ends in pythonNM[.zip]/logging/__init__.py Any suggestions? Thanks, Bob -- http://mail.python.org/mailman/listinfo/python-list
Re: are int, float, long, double, side-effects of computer engineering?
On 06/03/2012 01:11, Xah Lee wrote: some additional info i thought is relevant. are int, float, long, double, side-effects of computer engineering? Whatever you're taking please can I have some? Is it available via an NHS prescription or do I have to go private, or do I go down the pub and get it illegally? -- Cheers. Mark Lawrence. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: Why aren't my widgets expanding when I resize the window?
On 06/03/2012 01:10, Steven D'Aprano wrote: Which is a pity, because I gather that Rick actually does know Tkinter well. +1. Please Rick less of the Dark Side. :) -- Cheers. Mark Lawrence. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: Why aren't my widgets expanding when I resize the window?
On Monday, March 5, 2012 7:10:50 PM UTC-6, Steven D'Aprano wrote: > On Mon, 05 Mar 2012 14:07:05 -0800, John Salerno quoted: > > >> Wah! > >> > >> Stop whining and act like a professional! You complain about qualifying > >> constants but you happily type "self" until your fingers bleed without > >> even a whimper??? > > John, it is polite to leave attributions in place when you quote > somebody. I don't know who you are quoting above, but given the obnoxious > tone and the fact that this is about Tkinter, I'm guessing it is > RantingRick, a.k.a. Rick Johnson. > > Rick is a notorious troll, and you'll probably save yourself a lot of > grief if you pay no attention to him. It's not so much that his advice is > *always* bad, but that you'll spend so many hours sifting through the > piles of bad advice, unprofessional language, and annoying self- > aggrandisement for the occasional nugget of gold that it just isn't worth > it. > > Which is a pity, because I gather that Rick actually does know Tkinter > well. But dealing with him is like wrestling with a pig: > > "I learned long ago, never to wrestle with a pig. You get dirty, and > besides, the pig likes it." -- George Bernard Shaw > > > -- > Steven Thank you. Sorry about the attribution. That was my fault because I was trying to cite just the relevant bits, and I cut off the header too. -- http://mail.python.org/mailman/listinfo/python-list
are int, float, long, double, side-effects of computer engineering?
some additional info i thought is relevant. are int, float, long, double, side-effects of computer engineering? Xah Lee wrote: «… One easy way to measure it is whether a programer can read and understand a program without having to delve into its idiosyncrasies. …» Chris Angelico wrote: «Neither the behavior of ints nor the behavior of IEEE floating point is a "quirk" or an "idiosyncracy". …» they are computer engineering by-products. Are quirks and idiosyncracies. Check out a advanced lang such as Mathematica. There, one can learn how the mathematical concept of integer or real number are implemented in a computer language, without lots by-products of comp engineering as in vast majority of langs (all those that chalks up to some IEEE. (which, sadly, includes C, C++, perl, python, lisp, and almost all. (Common/Scheme lisp idiots speak of the jargon “number tower” instead I.) (part of the reason almost all langs stick to some I stuff is because it's kinda standard, and everyone understand it, in the sense that unix RFC (aka really fucking common) is wide-spread because its free yet technically worst. (in a sense, when everybody's stupid, there arise a cost to not be stupid.. A friend asked: «Can you enlighten us as to Mathematica's way of handling numbers, either by a post or a link to suitable documentation? …» what i meant to point out is that Mathematica deals with numbers at a high-level human way. That is, one doesn't think in terms of float, long, int, double. These words are never mentioned. Instead, you have concepts of machine precision, accuracy. The lang automatically handle the translation to hardware, and invoking exact value or infinite precision as required or requested. in most lang's doc, words like int, long, double, float are part of the lang, and it's quick to mention IEEE. Then you have the wide- spread overflow issue in your lang. In M, the programer only need to think in terms of math, i.e. Real number, Integer, complex number, precision, accuracy, etc. this is what i meat that most lang deals with computer engineering by- products, and i wished them to be higher level like M. http://reference.wolfram.com/mathematica/guide/PrecisionAndAccuracyControl.html Xah -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: Why aren't my widgets expanding when I resize the window?
On Mon, 05 Mar 2012 14:07:05 -0800, John Salerno quoted: >> Wah! >> >> Stop whining and act like a professional! You complain about qualifying >> constants but you happily type "self" until your fingers bleed without >> even a whimper??? John, it is polite to leave attributions in place when you quote somebody. I don't know who you are quoting above, but given the obnoxious tone and the fact that this is about Tkinter, I'm guessing it is RantingRick, a.k.a. Rick Johnson. Rick is a notorious troll, and you'll probably save yourself a lot of grief if you pay no attention to him. It's not so much that his advice is *always* bad, but that you'll spend so many hours sifting through the piles of bad advice, unprofessional language, and annoying self- aggrandisement for the occasional nugget of gold that it just isn't worth it. Which is a pity, because I gather that Rick actually does know Tkinter well. But dealing with him is like wrestling with a pig: "I learned long ago, never to wrestle with a pig. You get dirty, and besides, the pig likes it." -- George Bernard Shaw -- Steven -- http://mail.python.org/mailman/listinfo/python-list
State of Python+OpenAL?
Hunting around to see if there's any existing work to get 3d audio in Python, I encountered two packages (pyopenal[1] & alpy[2]), but both seem sparsely documented if at all and somewhat abandoned. Has anybody used either, or have any pointers on getting up to speed on either? Thanks, -tkc [1] http://home.gna.org/oomadness/en/pyopenal/ https://github.com/forrestv/pyopenal [2] http://www.stolk.org/alpy/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Error with co_filename when loading modules from zip file
On Mar 5, 8:36 pm, Bob wrote: > The logging package gets the filename and line number > of the calling function by looking at two variables, the filename > of the frame in the stack trace and the variable logging._srcfile. > The comparison is done in logging/__init__.py:findCaller. > The _srcfile is computed in logging/__init__.py - can you see which of the paths it takes when computing _srcfile? > I've tried putting only the pyc files, only the py files > and both in the zip file. I think the filename info might be stored in the .pyc from when you ran it outside the .zip. If you delete all .pyc files and only have .py in the .zip, what happens? Regards, Vinay Sajip -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: Why aren't my widgets expanding when I resize the window?
> > I don't like importing things piecemeal. I suppose I could do: > > So you prefer to pollute? How bout we just auto import the whole > Python stdlib so you can save a few keystrokes? > > so that's four more constants I'd have to explicitly import. And > > (tk.N, tk.S, tk.E, tk.W) is just horrible to look at. > > Wah! > > Stop whining and act like a professional! You complain about > qualifying constants but you happily type "self" until your fingers > bleed without even a whimper??? > > Look, either import ONLY the constants you need, or qualify each > constant with a module name/variable; that is the choices available to > a professional. Or, just be lazy and pollute your namespace. > > FYI: Lazy coders get what they deserve in the end. How exactly am I being lazy and polluting the namespace? I never said I wanted to use the "*" import method, if that's what you are (wrongly) assuming. I said it seems cleaner and, to me, LESS lazy to import the whole module as "import tkinter.constants as tkc" and qualify everything. It's certainly more explicit than importing constants on an as-needed basis, having an ever-increasing list of constants, and referring to them unqualified in the code. Yes, I complain that tk.N, tk.S, etc. is ugly to look at, but I'm saying it seems like a better way than using them unqualified, unless maybe there is yet another, better way. As far as using "self" all the time, how do you know I never "whimpered" about it? The first time I learned about it I DIDN'T like it, because it seemed like a lot of unnecessary typing, but eventually I came to accept it because 1) you HAVE to do it, unlike the various options for referring to these constants, and 2) I began to like the explicitness of qualifying everything with "self." You are very helpful, but you sure like to throw around the term "lazy" a little too unabashedly. I never said I wanted to import with "*", which you seem to think I want to do. I LIKE qualifying things, which is the reason I didn't care so much for your method of importing the constants by name. -- http://mail.python.org/mailman/listinfo/python-list
xlutils 1.5.1 released!
Hi All, xlutils 1.5.1 is out, fixing the usual embarrassing mistake I make when I move projects from Subversion to Git that results in some required non-.py files being omitted. All the details of where to find mailing lists, issue trackers, and the like for xlutils can be found here: http://www.simplistix.co.uk/software/python/xlutils cheers, Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk -- http://mail.python.org/mailman/listinfo/python-list
Error with co_filename when loading modules from zip file
Hi,
I'm using a program that distributes python in a zip
file and ran into an issue with the logging package.
It seems to return the wrong filename/line number when
loading python from a zip file. Please help!
I'm using python31, and have copied the lib directory to
/home/user/python3.1
and have created a zip of that directory and placed it in
/home/user/python3.1/python31.zip
The logging package gets the filename and line number
of the calling function by looking at two variables, the filename
of the frame in the stack trace and the variable logging._srcfile.
The comparison is done in logging/__init__.py:findCaller.
In the situation above, when I run,
PYTHONPATH=/home/user/python3.1 ./myexe run.py
I see
filename=/home/user/python3.1/logging/__init__.py
_srcfile=/home/user/python3.1/logging/__init__.py
Here, filename and _srcfile are the same, so the logger correctly
outputs the filename of run.py.
When I run,
PYTHONPATH=/home/user/python3.1/python31.zip ./myexe run.py
I see
filename=/home/user/python3.1/logging/__init__.py
_srcfile=/home/user/python3.1/python31.zip/logging/__init__.py
Here, filename and _srcfile are different, so the logger incorrectly
outputs the filename of /home/user/python3.1/logging/__init__.py
I've noticed this:
- the filename seems to be set when you compile the module
- it seems to be set when you load the module (even after moving it)
- it does not seem to get set when you load the module from
the pyc in the zip file!
I've tried putting only the pyc files, only the py files
and both in the zip file.
Any help?
Thanks,
Bob
run.py:
import logging
class Handler(logging.Handler):
def __init__(self):
logging.Handler.__init__(self)
def emit(self, record):
print('message: ' + record.msg)
print('filename: ' + record.pathname)
print('line: ' + str(record.lineno))
logging.getLogger().addHandler(Handler())
logging.error('hi')
--
http://mail.python.org/mailman/listinfo/python-list
Re: Is it necessary to call Tk() when writing a GUI app with Tkinter?
In article <3d0bf288-fa5d-48e5-9529-db92d420a...@1g2000yqv.googlegroups.com>, Rick Johnson wrote: > On Feb 29, 11:24 pm, Terry Reedy wrote: > > On 2/29/2012 10:22 PM, Rick Johnson wrote: > > > > PS: I would highly suggest against using the "from Tkinter import *". > > > Instead, use "import Tkinter as tk" and prefix all module contents > > > with "tk.". > > > > I have changed the example to do that. I also showed the alternate to > > initialize a widget. Here is the current version, tested on Windows 3.2.2. > > > > import tkinter as tk > > > > class Application(tk.Frame): > > def __init__(self, master=None): > > tk.Frame.__init__(self, master) > > self.pack() > > With all due respect, I would also recommend against "self packing" a > widget. And i can speak from experience on this issue. There was a > time when i was self-packing lots of custom compund widgets; then i > realized later the shortcomings of such action; what if you need to > use the grid or place geometry mangers instead? So remove the > self.pack line and add a line to the bottom: > > > root = tk.Tk() > > app = Application(master=root) > > app.pack() # <-- added this line > > app.mainloop() I agree. Application is simply another widget, like Entry or Canvas. its contents should be packed or gridded (as appropriate) into itself, but the user should then pack or grid the Application widget as appropriate. That makes the code much more reusable. -- Russell -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: Why aren't my widgets expanding when I resize the window?
On Mar 5, 11:31 am, John Salerno wrote:
> Ok, so use pack when putting the frame into the root, since that's
> all that goes into the root directly. But just out of curiosity,
> what did I do wrong with using grid? How would it work with grid?
If you read my post carefully, i said: "You need to use
columnconfigure and rowconfigure on ROOT!". Here is the solution;
although, not the correct code you should use because pack is perfect
for this:
## START CODE ##
import tkinter as tk
import tkinter.ttk as ttk
class AppFrame(ttk.Frame):
def __init__(self, parent, **kwargs):
super().__init__(parent, **kwargs)
self.create_widgets()
def create_widgets(self):
entry = ttk.Entry(self)
entry.grid(row=0, column=1, sticky='nsew')
label = ttk.Label(self, text='Name:')
label.grid(row=0, column=0, sticky='nsew')
root = tk.Tk()
root.title('Test Application')
root.columnconfigure(0, weight=1)
root.rowconfigure(0, weight=1)
frame = AppFrame(root, borderwidth=15, relief='sunken')
frame.grid(row=0, column=0, sticky='nsew')
root.mainloop()
## END CODE ##
> I don't like importing things piecemeal. I suppose I could do:
So you prefer to pollute? How bout we just auto import the whole
Python stdlib so you can save a few keystrokes?
> import tkinter.constants as tkc (or something like that)
>
> and qualify each constant. Seems like more work, but it just seems
> better than having to manage each constant that I need in the import
> list.
Then do "from tkinter.constants import *". I have no complaints
against import all the constants during testing/building, however, you
should be a professional and import only the constants you are going
to use.
> Also, N+S+E+W and (N, S, E, W) don't seem to work unless qualified,
Of course not, you never imported them! How could that code possibly
work?
> so that's four more constants I'd have to explicitly import. And
> (tk.N, tk.S, tk.E, tk.W) is just horrible to look at.
Wah!
Stop whining and act like a professional! You complain about
qualifying constants but you happily type "self" until your fingers
bleed without even a whimper???
Look, either import ONLY the constants you need, or qualify each
constant with a module name/variable; that is the choices available to
a professional. Or, just be lazy and pollute your namespace.
FYI: Lazy coders get what they deserve in the end.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: Why aren't my widgets expanding when I resize the window?
> You will need to configure the root columns and rows also because the > configurations DO NOT propagate up the widget hierarchy! Actually, for > this example, I would recommend using the "pack" geometry manager on > the frame. Only use grid when you need to use grid. Never use any > functionality superfluously! Also, you should explicitly pack the > frame from OUTSIDE frame.__init__()! Ok, so use pack when putting the frame into the root, since that's all that goes into the root directly. But just out of curiosity, what did I do wrong with using grid? How would it work with grid? > from tkinter.constants import BOTH, YES > I always use either: > > sticky='nswe' > sticky=N+S+W+E This is something I'm not too thrilled with. I don't like importing things piecemeal. I suppose I could do: import tkinter.constants as tkc (or something like that) and qualify each constant. Seems like more work, but it just seems better than having to manage each constant that I need in the import list. Also, N+S+E+W and (N, S, E, W) don't seem to work unless qualified, so that's four more constants I'd have to explicitly import. And (tk.N, tk.S, tk.E, tk.W) is just horrible to look at. -- http://mail.python.org/mailman/listinfo/python-list
Re: A Crypto Juniper $9$ secrets library
Hello! On Sun, Mar 04, 2012 at 10:16:05PM +0100, Julio G?mez wrote: > I have developed a Python library which encrypt/decrypt Juniper $9$ secrets. Thank you and welcome to the community! > I would like it is part of the common Python libraries and be able to > install it through APT, YUM, RPM... depending on the system. [skip] > Could you tell me the process I have to follow to publish the library? Let me give you some advice. First, there is Python Package Index - http://pypi.python.org/pypi - a central repository of python software. On the first page you can find all necessary information - how to register a user, how to register a package, how to register a release. The site also provides file hosting service so you can upload you releases. But you can host anywhere and only publish links to your preferred hosting. Some people just publish links to their mercurial or git repositories. Documentation uploaded to the site will be published at http://packages.python.org/ . It is also very important to send good release announcements. Please read the following introductory articles: http://en.wikipedia.org/wiki/Announcement_%28computing%29 http://perlbuzz.com/2009/03/how-to-write-an-announcement.html Read the archives of the python announcements mailing list: http://mail.python.org/pipermail/python-announce-list/ or http://groups.google.com/group/comp.lang.python.announce/topics Oleg. -- Oleg Broytmanhttp://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. -- http://mail.python.org/mailman/listinfo/python-list
Re: [RELEASED] Python 3.3.0 alpha 1
Georg Brandl wrote: > For a more extensive list of changes in 3.3.0, see > > http://docs.python.org/3.3/whatsnew/3.3.html > So far as I can see the what's new don't mention that hash randomisation is enabled by default in Python 3.3. I think it would be worth adding something about that. Also the what's new doesn't mention PEP 414 although the release page does. -- Duncan Booth http://kupuguy.blogspot.com -- http://mail.python.org/mailman/listinfo/python-list
Re: How to convert simple B/W graphic to the dot matrix for the LED display/sign
> >>> import Image
> >>> im=Image.new('L', (100,100))
> >>> im=im.convert('1')
> >>> px=im.load()
> >>> px[0,0]
Thanks, load() method works great.
One more question.
Finally, I would like to store array in the database.
What is the best way to store arrays?
Petr
--
http://mail.python.org/mailman/listinfo/python-list
Re: [Python-Dev] [RELEASED] Python 3.3.0 alpha 1
On 3/5/2012 2:54 AM, Georg Brandl wrote:
On behalf of the Python development team, I'm happy to announce the
first alpha release of Python 3.3.0.
This is a preview release, and its use is not recommended in
production settings.
Python 3.3 includes a range of improvements of the 3.x series, as well
as easier
porting between 2.x and 3.x. Major new features in the 3.3 release
series are:
* PEP 380, Syntax for Delegating to a Subgenerator ("yield from")
* PEP 393, Flexible String Representation (doing away with the
distinction between "wide" and "narrow" Unicode builds)
* PEP 409, Suppressing Exception Context
* PEP 3151, Reworking the OS and IO exception hierarchy
* The new "packaging" module, building upon the "distribute" and
"distutils2" projects and deprecating "distutils"
* The new "lzma" module with LZMA/XZ support
* PEP 3155, Qualified name for classes and functions
* PEP 414, explicit Unicode literals to help with porting
* The new "faulthandler" module that helps diagnosing crashes
* Wrappers for many more POSIX functions in the "os" and "signal"
modules, as well as other useful functions such as "sendfile()"
For a more extensive list of changes in 3.3.0, see
http://docs.python.org/3.3/whatsnew/3.3.html
The 3.3 whatsnews page doesn't seem to mention PEP 414 or Unicode
literals at all.
--Ned.
To download Python 3.3.0 visit:
http://www.python.org/download/releases/3.3.0/
Please consider trying Python 3.3.0a1 with your code and reporting any
bugs you may notice to:
http://bugs.python.org/
Enjoy!
--
Georg Brandl, Release Manager
georg at python.org
(on behalf of the entire python-dev team and 3.3's contributors)
___
Python-Dev mailing list
python-...@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/ned%40nedbatchelder.com
--
http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: Why aren't my widgets expanding when I resize the window?
On Mar 5, 1:12 am, John Salerno wrote:
> I can't seem to wrap my head around all the necessary arguments
> for making a widget expand when a window is resized.
You will need to configure the root columns and rows also because the
configurations DO NOT propagate up the widget hierarchy! Actually, for
this example, I would recommend using the "pack" geometry manager on
the frame. Only use grid when you need to use grid. Never use any
functionality superfluously! Also, you should explicitly pack the
frame from OUTSIDE frame.__init__()!
## START CODE ##
import tkinter as tk
import tkinter.ttk as ttk
from tkinter.constants import BOTH, YES
class AppFrame(ttk.Frame):
def __init__(self, parent, **kwargs):
super().__init__(parent, **kwargs)
self._create_widgets()
def _create_widgets(self):
entry = ttk.Entry(self)
entry.grid(row=0, column=1, sticky='nsew')
label = ttk.Label(self, text='Name:')
label.grid(row=0, column=0, sticky='nsew')
root = tk.Tk()
root.title('Test Application')
frame = AppFrame(root, borderwidth=15, relief='sunken')
frame.pack(fill=BOTH, expand=YES)
root.mainloop()
## END CODE ##
> Is there something wrong with the sticky argument, maybe? The
> tutorial I'm reading says they can be strings, but it also uses what
> appears to be a tuple of constants like this: sticky=(N, S, E, W) --
> but that didn't work either.
I always use either:
sticky='nswe'
sticky=N+S+W+E
--
http://mail.python.org/mailman/listinfo/python-list
Re: AttributeError: 'module' object has no attribute 'logger'
youssef.mah...@hotmail.com wrote: hi all, when installing sage, there is a problem with emacs.py so, this screen appeared after rynning ./sage -- | Sage Version 4.4.2, Release Date: 2010-05-19 | | Type notebook() for the GUI, and license() for information.| -- Traceback (most recent call last): File "/home/zid/sage/local/bin/sage-ipython", line 18, in import IPython File "/usr/lib/python2.7/dist-packages/IPython/__init__.py", line 58, in __import__(name,glob,loc,[]) File "/usr/lib/python2.7/dist-packages/IPython/ipstruct.py", line 17, in from IPython.genutils import list2dict2 File "/usr/lib/python2.7/dist-packages/IPython/genutils.py", line 114, in import IPython.rlineimpl as readline File "/usr/lib/python2.7/dist-packages/IPython/rlineimpl.py", line 18, in from pyreadline import * File "/usr/local/lib/python2.7/dist-packages/pyreadline-2.0_dev1- py2.7.egg/pyreadline/__init__.py", line 11, in from . import unicode_helper, logger, clipboard, lineeditor, modes, console File "/usr/local/lib/python2.7/dist-packages/pyreadline-2.0_dev1- py2.7.egg/pyreadline/modes/__init__.py", line 3, in from . import emacs, notemacs, vi File "/usr/local/lib/python2.7/dist-packages/pyreadline-2.0_dev1- py2.7.egg/pyreadline/modes/emacs.py", line 11, in import pyreadline.logger as logger AttributeError: 'module' object has no attribute 'logger' any one can help me pleas regards Zid You probably have the wrong version of pyreadline. Try to install the last stable 1.7.1 or look for emacs.py requirement for the pyreadline version. Non constructive solution : use vim :o) JM -- http://mail.python.org/mailman/listinfo/python-list
Re: Trying to understand 'import' a bit better
Frank Millman wrote: Hi all I have been using 'import' for ages without particularly thinking about it - it just works. Now I am having to think about it a bit harder, and I realise it is a bit more complicated than I had realised - not *that* complicated, but there are some subtleties. I don't know the correct terminology, but I want to distinguish between the following two scenarios - 1. A python 'program', that is self contained, has some kind of startup, invokes certain functionality, and then closes. 2. A python 'library', that exposes functionality to other python programs, but relies on the other program to invoke its functionality. The first scenario has the following characteristics - - it can consist of a single script or a number of modules - if the latter, the modules can all be in the same directory, or in one or more sub-directories - if they are in sub-directories, the sub-directory must contain __init__.py, and is referred to as a sub-package - the startup script will normally be in the top directory, and will be executed directly by the user When python executes a script, it automatically places the directory containing the script into 'sys.path'. Therefore the script can import a top-level module using 'import ', and a sub-package module using 'import .'. The second scenario has similar characteristics, except it will not have a startup script. In order for a python program to make use of the library, it has to import it. In order for python to find it, the directory containing it has to be in sys.path. In order for python to recognise the directory as a valid container, it has to contain __init__.py, and is referred to as a package. To access a module of the package, the python program must use 'import .' (or 'from import '), and to access a sub-package module it must use 'import ... So far so uncontroversial (I hope). The subtlety arises when the package wants to access its own modules. Instead of using 'import ' it must use 'import .'. This is because the directory containing the package is in sys.path, but the package itself is not. It is possible to insert the package directory name into sys.path as well, but as was pointed out recently, this is dangerous, because you can end up with the same module imported twice under different names, with potentially disastrous consequences. Therefore, as I see it, if you are developing a project using scenario 1 above, and then want to change it to scenario 2, you have to go through the entire project and change all import references by prepending the package name. Have I got this right? Frank Millman I think you got it right. It happened to me as well, I guess it's a classic for program being promoted into a library. JM -- http://mail.python.org/mailman/listinfo/python-list
Re: RotatingFileHandler Fails
nac wrote:
The RotatingFileHandler running on win 7 64-bit; py 2.7 is failing
when the script launches a process using subprocess.Popen. Works fine
if the subprocess is not launched
The exception thrown
Traceback (most recent call last):
File "C:\Python27\lib\logging\handlers.py", line 78, in emit
self.doRollover()
File "C:\Python27\lib\logging\handlers.py", line 141, in doRollover
os.rename(self.baseFilename, dfn)
WindowsError: [Error 32] The process cannot access the file because it
is being used by another process
Anyone have an idea how to fix this?
import os, sys
import logging
import logging.handlers
import subprocess
def chomp(s):
"remove trailing carriage return"
if s[-1:]=='\n': return s[:-1]
else: return s
logging.basicConfig(level=logging.DEBUG, format='%(asctime)s %
(name)-2s %(levelname)-8s %(threadName)-12s %(message)s')
q5Logger = logging.getLogger('Q5')
logFileHandler = logging.handlers.RotatingFileHandler(filename='c:\
\logger\\q5.log', mode= 'a', maxBytes=100, backupCount=5)
logFileHandler.setFormatter(logging.Formatter('%(asctime)s %(name)-2s %
(levelname)-8s %(threadName)-12s %(message)s'))
logFileHandler.setLevel(logging.DEBUG)
q5Logger.addHandler(logFileHandler)
progOutput = subprocess.Popen(r'dir *.*', shell=True, bufsize=1000,
stdout=subprocess.PIPE).stdout
line = progOutput.readline()
while (line) != "":
q5Logger.info( chomp(line))
line = progOutput.readline()
rc = progOutput.close()
I don't think you can open a file from 2 different processes, hence the
error message. The only exception would be that one of them opens it in
read only mode which won't happen for log file.
You cannot fix it, it is the operand system that blocks the operation.
Using thread may allow you to log into the same file, but could bring a
bunch of other problems.
I know some ppl use a log server, your processes using a socket (client)
logger. You could do that on your local machine. There's a tutorial on
that in the logging documentation.
JM
--
http://mail.python.org/mailman/listinfo/python-list
xlutils 1.5.0 released!
Hi All, I'm pleased to announce the release of xlutils 1.5.0, featuring the following changes: - Now takes advantage of "ragged rows" optimisation in xlrd 0.7.3 - Add support for PANE records to xlutils.copy, which means that zoom factors are now copied. The full change log is here: http://www.simplistix.co.uk/software/python/xlutils/changes Now, the other big change for this release is that development has moved to GitHub: https://github.com/cjw296/xlutils All the details of where to find mailing lists, issue trackers, and the like for xlutils can be found here: http://www.simplistix.co.uk/software/python/xlutils cheers, Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk -- http://mail.python.org/mailman/listinfo/python-list
