Re: TKinter Newbie question
TUA wrote: > Why does the button frame in the code below not show? > tk.Button(bf, padx = 10, relief = tk.GROOVE, text = 'Help') You forgot to layout it with .pack(). > I intend to have it displayed in between the notebook at the top and the > fake statusbar at the bottom. I think for that you need to swap the sb.pack() and bf.pack() calls, or remove side=BOTTOM from bf.pack(). -- https://mail.python.org/mailman/listinfo/python-list
Re: python package management confusion
dcs3spp via Python-list writes: > ... > How do I configure setuptools to pull my own private dependency package using > virtualenv + python setup.py develop You call "python setup.py develop" for your own package (which the "python" from the virtualenv). This makes your package (more precisely, the one whose "setup.py" you have activated) available in the virtualenv. The "making available" happens in a way, that Python is actually using your package's source tree; thus, modifications in this source tree are seen by Python (either the next "run" or via "importlib.reload"). -- https://mail.python.org/mailman/listinfo/python-list
TKinter Newbie question
Why does the button frame in the code below not show?
I intend to have it displayed in between the notebook at the top and the fake
statusbar at the bottom.
Thanks for any help!
from tkinter import ttk
import tkinter as tk
class MainForm():
def __init__(self, master):
self.master = master
self.master.title('Test')
nb = ttk.Notebook(self.master)
page_1 = ttk.Frame(nb)
nframe = ttk.LabelFrame(page_1, text='Frame', padding = 10)
tk.Label(nframe, padx = 10, pady = 5, text = 'Name').pack()
tk.Entry(nframe, width = 30).pack()
tk.Label(nframe, padx = 10, pady = 5, text = 'City').pack()
tk.Entry(nframe, width = 30).pack()
#
nframe.pack(fill="both", expand="yes", padx = 10, pady = 10) # pad
around the frame
nb.add(page_1, text = 'Tab #1')
nb.pack(expand = True, fill = "both")
#---
# button frame for Help button why does it not show?
#---
bf = ttk.Frame(self.master, relief = tk.SUNKEN)
tk.Button(bf, padx = 10, relief = tk.GROOVE, text = 'Help')
bf.pack(side = tk.BOTTOM, fill = tk.X)
#---
# fake a status bar from a label
#---
sb = tk.Label(self.master, text = ' Waiting for rain ...', bd = 1,
anchor = tk.W, relief = tk.SUNKEN)
sb.pack(side = tk.BOTTOM, fill = tk.X)
def CloseApplication(self):
self.master.destroy()
def StartApplication():
root = tk.Tk()
MainForm(root)
root.mainloop()
if __name__ == '__main__':
StartApplication()
--
https://mail.python.org/mailman/listinfo/python-list
Re: Pythonic Y2K
Back in the computer world, Y2K gave such managers some cover. There was a FIRM deadline. I wonder how many used the impending arrival of the year 2000 as an excuse to perhaps clean up other parts of their act and charge it to prevention. I mean they might suggest they rewrite some legacy COBOL or even machine language programs into something more modern or other improvements like getting a new database including new hardware. Of course we did! However, as pointed-out elsewhere, sometimes the costs of re-writing seemed less than those required to ameliorate any number of unknown issues in the legacy code. Remembering that we would also remove unneeded cruft, and (usually) add features needed for 'today's use'. What were you saying about politicians 'playing' with retirement funds and public money? The other advantage to a re-write decision was even more under-hand: once agreed, that became a dev project (with a 31Dec1999 drop-dead deadline) and was NO LONGER part of the Y2K project, ie no longer 'my problem'! I recall at least one project where the users over-egged their case (IMHO), taking the dev option even against my advice. They failed to make the deadline. Let's just say, on their part, there was a lot of fancy-footwork during the first days of 2000... I also wonder if jobs for some programmers declined sharply in the years after when not only were they not desperately needed, but perhaps not needed at all unless they developed new talents. No, quite the opposite. What happened was that many other projects were put-off pending Y2K amelioration. Once we could release staff, they were greeted with open arms, and often far, far, greater appreciation than normally meets a new dev upon arrival. Just FYI, the name Y2K always struck me as similar nonsense. They abbreviated Year and 2000 from at least 8 characters to 3 and did it wrong as 2K is 2048. As far as I know, nothing special will happen in 2048 and I also have no special vision for 2020. You don't seem to understand journalism: Never let the truth (facts) interfere with a 'good story'! I was just talking with a (tech) librarian, who had asked me about "the Unix Millennium bug" a few weeks ago, and mentioned this thread. He groaned, wondering how long it will be before some hack writes a sensationalist book with which to greet the end of the (binary) world... My play-time this afternoon will involve using Python to keep (time-code) track of when/where to superimpose components into a video stream... (I should be back before 2038) -- Regards =dn -- https://mail.python.org/mailman/listinfo/python-list
Re: oldschool texter GUI with python, char repeating is not working great !
i just uploaded everything on github https://github.com/kourpetis/python_old_school_texter -- https://mail.python.org/mailman/listinfo/python-list
Re: AssertionError without traceback?
> On Jan 14, 2019, at 10:40 PM, dieter wrote: > > Israel Brewster writes: >> I have a flask application deployed on CentOS 7 using Python 3.6.7 and uwsgi >> 2.0.17.1, proxied behind nginx. uwsgi is configured to listed on a socket in >> /tmp. The app uses gevent and the flask_uwsgi_websockets plugin as well as >> various other third-party modules, all installed via pip in a virtualenv. >> The environment was set up using pip just a couple of days ago, so >> everything should be fully up-to-date. The application *appears* to be >> running properly (it is in moderate use and there have been no reports of >> issues, nor has my testing turned up any problems), however I keep getting >> entries like the following in the error log: >> >> AssertionError >> 2019-01-14T19:16:32Z failed with >> AssertionError > > I would try to find out where the log message above has been generated > and ensure it does not only log the information above but also the > associated traceback. > > I assume that the log comes from some framework -- maybe "uwsgi" > or "gevent". It is a weakness to log exceptions without the > associated traceback. After extensive debugging, it would appear the issue arrises due to a combination of my use of gevent.spawn to run a certain function, and the portion of that function that sends web socket messages. If I remove either the gevent.spawn and just call the function directly, or keep the gevent.spawn but don't try to send any messages via web sockets, the error goes away. With the combination, I *occasionally* get the message - most of the time it works. So I guess I just run everything synchronously for now, and as log as the performance isn't hurt noticeably, call it good. I still find it strange that this never happened on CentOS 6, but whatever. The gevent.spawn calls were probably pre-mature optimization anyway. > >> There is no additional information provided, just that. I was running the >> same app (checked out from a GIT repository, so exact same code) on CentOS 6 >> for years without issue, it was only since I moved to CentOS 7 that I've >> seen the errors. I have not so far been able to correlate this error with >> any specific request. Has anyone seen anything like this before such that >> you can give me some pointers to fixing this? As the application *appears* >> to be functioning normally, it may not be a big issue, but it has locked up >> once since the move (no errors in the log, just not responding on the >> socket), so I am a bit concerned. >> --- >> Israel Brewster >> Systems Analyst II >> 5245 Airport Industrial Rd >> Fairbanks, AK 99709 >> (907) 450-7293 >> --- >> >> [cid:05a3a602-0c27-4749-91b8-096a5857d984@flyravn.com] >> >> >> >> [cid:bbc82752-6db4-44cf-b919-421ed304e1d1@flyravn.com] > > -- > https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
RE: Pythonic Y2K
Ian, You just scared me. It is 2019 which has four digits. In less than 8,000 years we will need to take the fifth to make numbers from 10,000 to 10,999. 90,000 years later we will need a sixth digit and so on. Do you know how many potential Y2K-like anomalies we may have between now and year 292,277,026,596 when it may all be over? Will people evert learn and just set aside lots of room that dates can grow into or allow varying lengths? Makes me wonder though why anyone in the distant future would want numbers that long to represent that date. I suspect that long before then, some surviving members of whatever the human race becomes will do a reset to a new calendar such as the date the first settlers arrived in the Gamma Quadrant. So whatever unit they store time in, though, may still need a way to reach back to historic times just as we do by talking about what may have happened in 2000 B.C. -Original Message- From: Python-list On Behalf Of Ian Kelly Sent: Thursday, January 17, 2019 2:14 PM To: Python Subject: Re: Pythonic Y2K On Wed, Jan 16, 2019 at 9:57 PM Avi Gross wrote: > > The forthcoming UNIX 2038 problem will, paradoxically happen on > January 19. I wonder what they will do long before then. Will they just add a byte or four or 256 and then make a date measurable in picoseconds? Or will they start using a number format that can easily deal with 1 Million B.C. and 5 Billion A.D. just in case we escape earth before it co-locates with the expanding sun. The obvious solution is to stop using 32-bit Unix timestamps and start using 64-bit Unix timestamps. This change has already been made in some OSes, and the problem will not repeat until the year 292,277,026,596, by which time it is highly unlikely that either Unix timestamps or humankind itself will still exist. Even if they will, that moment in time is so far out from the present that I can't really be bothered by the possibility. We have 19 years to take care of the problem before it happens. Hopefully this time around we won't be trying to fix it right up until the last minute. -- https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
RE: Pythonic Y2K
Well said, Joseph. Unfortunately, many companies are run these days with a view toward the IMMEDIATE bottom line. I mean numbers like revenues or expenses are seen short-term. If a project stops development on new things and spends time redoing old things, there are expenses recorded with no revenues. Another organization might go ahead and get up to date and a few years down the road their projects are sailing along while the first employer keeps running into obstacles and is not able to get new developments and so on. But often, the manager making the decision will have taken their bonus or promotion and perhaps moved on or retired. Not to be political, I note many government entities, especially including the state I live in, have gigantic pension obligations they have no easy way to meet. Over the years in negotiations with unions they have often traded rich promises for the future instead of immediate pay hikes. The costs may largely be invisible and did not impact their current budgets so they could waste money on other things such as giveaways that help them get re-elected to ever higher office. But the costs are getting very visible now, and especially when the stocks they invest in decline. Back in the computer world, Y2K gave such managers some cover. There was a FIRM deadline. I wonder how many used the impending arrival of the year 2000 as an excuse to perhaps clean up other parts of their act and charge it to prevention. I mean they might suggest they rewrite some legacy COBOL or even machine language programs into something more modern or other improvements like getting a new database including new hardware. I also wonder if jobs for some programmers declined sharply in the years after when not only were they not desperately needed, but perhaps not needed at all unless they developed new talents. Just FYI, the name Y2K always struck me as similar nonsense. They abbreviated Year and 2000 from at least 8 characters to 3 and did it wrong as 2K is 2048. As far as I know, nothing special will happen in 2048 and I also have no special vision for 2020. -Original Message- From: Python-list On Behalf Of Schachner, Joseph Sent: Thursday, January 17, 2019 1:46 PM To: Python Subject: RE: Pythonic Y2K I'd like to add one more thing to your list of what companies will have to consider: 6) The ability to hire and retain employees who will be happy to program in an obsolete version of Python. A version about which new books will probably not be written. A version which new packages will not support. A version which most other companies will no longer be using, so programming only in Python 2 will place the employee at a disadvantage compared to others who have gained experience with Python 3 if they ever have to change employers. --- Joseph S. -Original Message- From: Chris Angelico Sent: Wednesday, January 16, 2019 2:15 PM To: Python Subject: Re: Pythonic Y2K On Thu, Jan 17, 2019 at 6:04 AM Avi Gross wrote: > > I see messages like the following where someone is still asking how to > do something in some version of python 2.X. > > I recall the days before the year 2000 with the Y2K scare when people > worried that legacy software might stop working or do horrible things > once the clock turned. It may even have been scary enough for some > companies to rewrite key applications and even switch from languages like COBOL. > > What is happening in the python community, and especially in places > where broken software may be a serious problem? > > I assume versions of python 2.X will continue to be available for some > time but without any further support and without features being back-ported. Commercial support for Python 2 will probably continue for a while, in the same way that support for versions older than 2.7 is still available to Red Hat customers today (if I'm not mistaken). Otherwise, well, the software will continue without updates or security patches until it breaks. Companies will have to weigh up five costs against each other: 1) The cost of the status quo: the risk of critical failures or external attacks against unsupported and unpatched software 2) The cost of migrating to Python 3 3) The cost of migrating to a completely different language 4) The cost of maintaining their own local fork of Python 2 5) The cost of using a supported commercial platform such as RHEL. For most small to medium projects, it's probably going to come down to #1 or #2, where #1 has the laziness bonus. For many larger companies, #1 is an unpayable cost. Everyone has to make that choice, and remember that "cost" doesn't just mean money (for instance, the cost of moving to Linux might be quite considerable for a Windows shop, and even within a Linux ecosystem, switching to Red Hat may have consequences to other programs you might need). ChrisA -- https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
oldschool texter GUI with python, char repeating is not working great !
I have this tkinter GUI of an old school texter that runs on a Raspberry pi 3.
I have 16 pressure analog pressure sensors that i am readding them through a
multiplexor, and i pass there values to an ADC mcp3002. if the value pass a
thresshold i consider it as a key press, and there i need some chars to roll
while i have it pressed inside a text area, if the voltage passes the
thresshold the other way i consider the key to be released and the last char
that was inside the text area will be set at that cursor point, the cursor will
move one place next, and wait untill an other press to do the same thing again.
this is the code for the def :
def process(value):
global keypressed, keyreleased
num_press=0
#message=[] #this table gets the chars. After the roll is finished the last
char is appented to it. eventually this table is piped to minimodem.
steps=0
i=0
x=int(value)
key_pressed=x
#proceedInLoop = True
while True:
binary_x="{0:04b}".format(x) #get the binary of x and set each 0
and 1 to the appropreate GPIO
GPIO.output(26, int(binary_x[0]))
GPIO.output(13, int(binary_x[1]))
GPIO.output(12, int(binary_x[2]))
GPIO.output(5, int(binary_x[3]))
# average three readings to get a more stable one
channeldata_1 = read_mcp3002(0) # get CH0 input
sleep(0.001)
channeldata_2 = read_mcp3002(0) # get CH0 input
sleep(0.001)
channeldata_3 = read_mcp3002(0) # get CH0 input
channeldata = (channeldata_1+channeldata_2+channeldata_3)/3
#
# Voltage = (CHX data * (V-ref [= 3300 mV] * 2 [= 1:2 input divider]) /
1024 [= 10bit resolution]#
voltage = int(round(((channeldata * vref * 2) / resolution),0))+
calibration
#voltage = 6000 # temporary voltage for testing
print(voltage)
if DEBUG : print("Data (bin){0:010b}".format(channeldata))
key_pressed=x
if ( voltage < 4000) : #key is released
keypressed = False
keyreleased = True
x=x+1
if ( voltage >= 4001) : #key is pressed
keypressed = True
keyreleased = False
key_pressed=x#define which key is pressed
# print(i)
if key_pressed==0:
transmite(message)
x=x+1
sleep(0.01)
keypressed = False
keyreleased = True
if key_pressed==1:
print('read')
keypressed = False
keyreleased = True
if key_pressed==2:
sys.stdout.write('\033[2K]')
sys.stdout.write('\033[1G]')
keypressed = False
keyreleased = True
if key_pressed==3:
#print('\b\b')
print('\b ', end="", flush=True)
sys.stdout.write('\010')
sleep(1)
keypressed = False
keyreleased = True
if key_pressed > 3:
#if key == key_pressed :
while num_press <= (max_press[key_pressed]) and
keyreleased==False:
#average three readings to get a more stable one
channeldata_1 = read_mcp3002(0) # get CH0 input
sleep(0.001)
channeldata_2 = read_mcp3002(0) # get CH0 input
sleep(0.001)
channeldata_3 = read_mcp3002(0) # get CH0 input
channeldata =
(channeldata_1+channeldata_2+channeldata_3)/3
#
# Voltage = (CHX data * (V-ref [= 3300 mV] * 2 [= 1:2
input divider]) / 1024 [= 10bit resolution]
voltage =
int(round(((channeldata*vref*2)/resolution),0))+ calibration
if DEBUG : print("Data (bin)
{0:010b}".format(channeldata))
if ( voltage < 4000) : #key is released
print("voltage < 4000")
keyreleased = True
keypressed = False
sys.stdout.write('\033[1C')
char=sensor[key_pressed][num_press]
message.append(char) # here is the append.
num_press=0
#else :
#keypressed = True
#keyreleased = False
if num_press <= max_press[key_pressed] and keyreleased
== False:
top.Text1.insert("end",
sensor[key_pressed][num_press] + '\n')
print(sensor[key_pressed][num_press])
Sarah Guido
Perhaps it is not a coincidence that I plucked the mock-suggestion to name a language Guido out of thin air. A book I ordered quite a while ago arrived. "Introduction to Machine Learning with Python: A Guide for Data Scientists" by Andreas C. Müller and <<>> Note the last name is the same Guido we have been discussing for no meaningful reason whatsoever merely because naming after a (live) founder may not be a good reason. I tend to order books in bunches and I have no recollection of even noticing the first author, let alone the second. I have received and read many of the books on the subject that arrived first. Still, the way I read I tend to see everything around an area even if I am not consciously reading it so I suspect a subliminal recognition along with perhaps a subliminal amusement that Guido is now both the first and last name of someone I can associate with python. If I had been involved in the above book publication, I might have suggested using the word "Guide" instead of "Introduction" as it melds well with the name "Guido" so it is good nobody would even dream of asking me. Maybe her next book will be abut a GUI to DO or something that fits. P.S. This is not an endorsement of the book mentioned above nor of Machine Learning in general but IS an endorsement for using python for such things. Then again, I also endorse R as I have actually already done such things using it and want broader choices. Heck, I have already used both together. Their approaches can be maddeningly different and that opens up opportunities. -Original Message- From: Python-list On Behalf Of Avi Gross Sent: Wednesday, January 16, 2019 9:49 PM To: python-list@python.org Subject: Guido (Sarducci) Dennis, I wish to apologize for introducing any suggestion to name anything as Guido, let alone any language that springs from a python. Yes, it may be a stereotypic Italian name related to what you hint at. You probably recognized it as an allusion to someone who is clearly Dutch and has some finite relationship with python. The name is ultimately Germanic and used in many countries. I, in a Monty Python Spirit, insist I was thinking about the Saturday Night Live comedic character from generations ago, Father Guido Sarducci, who does indeed appear to be Italian. That is the pythonic way to choose a name although 3.X might well have been named after the Three Stooges. Again, my apologies. I will try to resume being serious and maybe talk about mission creep. Avi -Original Message- From: Python-list On Behalf Of Dennis Lee Bieber Sent: Wednesday, January 16, 2019 4:36 PM To: python-list@python.org Subject: Re: the python name On Wed, 16 Jan 2019 13:46:29 -0500, "Avi Gross" declaimed the following: >[HUMOR for the ALERT] > >But as languages develop and evolve, sometimes a name change may be a >decent idea. Perhaps version 4.0 should be renamed Guido so we can get >more silly questions. > So we can make jokes about a mafia hitman (which is where many might go with the name) > >Imagine people developing languages like X and Y and over the years >enhancing them. > >An Enhanced or Extended X, naturally, might be renamed EX. Getting too close to REXX (which was something like Restructured EXtended eXecutor). > >With further Super new features (think super-symmetry in Physics) we >would have a Super Extended X, or SEX in brief. > Computer science already has sexpr https://en.wikipedia.org/wiki/S-expression -- Wulfraed Dennis Lee Bieber AF6VN wlfr...@ix.netcom.comHTTP://wlfraed.home.netcom.com/ -- https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: [tkinter] question about correct use of validation
Il 17/01/19 14:08, Peter Otten ha scritto: Alternatives: - If you know that you'll always just call pack() you can change the make_entry() method accordingly def make_entry(...): ... entry.pack() return entry - Write a helper function def pack(widget): widget.pack() return widget and then use it self.id1_entry = pack(self.make_entry(...)) # create and layout widget it's true! they are important things that make the difference and help in understanding. Thanks a lot of support ;-) -- https://mail.python.org/mailman/listinfo/python-list
Re: Pythonic Y2K
On Fri, Jan 18, 2019 at 8:47 AM DL Neil wrote: > > On 17/01/19 6:53 PM, Chris Angelico wrote: > > On Thu, Jan 17, 2019 at 3:55 PM Avi Gross wrote: > >> The forthcoming UNIX 2038 problem will, paradoxically happen on January 19. > >> > > > > Paradoxically? What do you mean by that? > > > First we had to duck the Y2K problem. > By moving everything to 64-bits, we duck the Unix Millennium problem. > > There you go: two ducks - a pair-o-ducks! Well, I'm sorry Neil, but these things are well documented. In fact, you can find information on the web, OR you can examine the man pages in your local installation. Wait, we're right back where we started... a pair-o-docs > I assume the paradox involves noting that the end of the (32-bit) Unix > epoch, does not coincide with the end of a (Gregorian) calendar year. Ahh yes, as paradoxical as when the Mayan Y2K happened in December of 2012. Gotcha. > Actually, aren't there three date-time problems to be ducked? Wasn't > Python's move to having wider timestamps (+= fractions of seconds) in > part connected with the need to modify NTP - which hits the wall a few > years before 2038... Oh, probably. But one of the reasons I use high level languages is so I don't have to worry about the sizes of integers. In fact, some day, we won't use floats to store seconds, we'll just use bignum integers to store some number of Planck times ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Pythonic Y2K
On 17/01/19 6:53 PM, Chris Angelico wrote: On Thu, Jan 17, 2019 at 3:55 PM Avi Gross wrote: The forthcoming UNIX 2038 problem will, paradoxically happen on January 19. Paradoxically? What do you mean by that? First we had to duck the Y2K problem. By moving everything to 64-bits, we duck the Unix Millennium problem. There you go: two ducks - a pair-o-ducks! I assume the paradox involves noting that the end of the (32-bit) Unix epoch, does not coincide with the end of a (Gregorian) calendar year. Actually, aren't there three date-time problems to be ducked? Wasn't Python's move to having wider timestamps (+= fractions of seconds) in part connected with the need to modify NTP - which hits the wall a few years before 2038... -- Regards =dn -- https://mail.python.org/mailman/listinfo/python-list
Re: [tkinter] question about correct use of validation
steve wrote: > Il 17/01/19 14:08, Peter Otten ha scritto: > >> Two remarks: >> >>> self.id1_entry = self.make_entry(self.parent, maxlen=1).pack() >> >> You set all idX_entry attributes to None, as that's what pack() returns. > > you mean.. > > self.idx_entry = self.make_entry(self.parent, width=50, maxlen=30, > highlightcolor='blue', validate='key') ? > > or > > self.idx_entry.pack() ? > > I did not understand :-D Both. This > self.id1_entry = self.make_entry(self.parent, maxlen=1).pack() will assign None to self.id1_entry. You need two steps self.id1_entry = self.make_entry(...) # create widget self.id1_entry.pack() # layout widget Alternatives: - If you know that you'll always just call pack() you can change the make_entry() method accordingly def make_entry(...): ... entry.pack() return entry - Write a helper function def pack(widget): widget.pack() return widget and then use it self.id1_entry = pack(self.make_entry(...)) # create and layout widget -- https://mail.python.org/mailman/listinfo/python-list
Re: the python name
On Fri, Jan 18, 2019 at 8:33 AM DL Neil wrote: > > On 18/01/19 8:20 AM, Dennis Lee Bieber wrote: > > On Thu, 17 Jan 2019 18:12:33 +1300, Gregory Ewing > > declaimed the following: > > > >> Dennis Lee Bieber wrote: > >>> Getting too close to REXX (which was something like Restructured > >>> EXtended eXecutor). > >> > >> And if we continue the theme of dinosaur evolution, we end up > >> with Tyrannosaurus REXX. > > > > I'd propose that the Regina project be renamed to that -- one tyrant > > to > > rule all REXX > > > LotR reference aside, just how many pythonistas do you think also speak > Latin - to be able to appreciate that joke? > "Regina" is a REXX interpreter. https://regina-rexx.sourceforge.io/ You don't necessarily have to know Latin to know about "regina" and "rex"; a bit of knowledge of royal protocol can help, or you might just recognize the parallels. But honestly, knowing a bit of Latin isn't a bad thing :) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: the python name
On 18/01/19 8:20 AM, Dennis Lee Bieber wrote: On Thu, 17 Jan 2019 18:12:33 +1300, Gregory Ewing declaimed the following: Dennis Lee Bieber wrote: Getting too close to REXX (which was something like Restructured EXtended eXecutor). And if we continue the theme of dinosaur evolution, we end up with Tyrannosaurus REXX. I'd propose that the Regina project be renamed to that -- one tyrant to rule all REXX LotR reference aside, just how many pythonistas do you think also speak Latin - to be able to appreciate that joke? -- Regards =dn -- https://mail.python.org/mailman/listinfo/python-list
Re: [tkinter] question about correct use of validation
Il 17/01/19 14:08, Peter Otten ha scritto: Two remarks: self.id1_entry = self.make_entry(self.parent, maxlen=1).pack() You set all idX_entry attributes to None, as that's what pack() returns. you mean.. self.idx_entry = self.make_entry(self.parent, width=50, maxlen=30, highlightcolor='blue', validate='key') ? or self.idx_entry.pack() ? I did not understand :-D apply(Entry.__init__, (self, master), kw) You can write that in way compatible with Python 3 as Entry.__init__(self, master, **kw) Ok this i understood -- https://mail.python.org/mailman/listinfo/python-list
Re: Pythonic Y2K
On 2019-01-17, Schachner, Joseph wrote: > I'd like to add one more thing to your list of what companies will have to > consider: > > 6) The ability to hire and retain employees who will be happy to >program in an obsolete version of Python. A version about which >new books will probably not be written. A version which new >packages will not support. A version which most other companies >will no longer be using, so programming only in Python 2 will >place the employee at a disadvantage compared to others who have >gained experience with Python 3 if they ever have to change >employers. IMO, that's a non-issue. AFAICT, a pretty large percentage of SW developers are using obsolete or proprietary tools that aren't cool and fashionable, don't have outside support, about which books aren't being written, and for which third-party packages and libraries don't exist. I also don't think an experience Python2 developer would be turned down for a position on a project that's using Python3. -- Grant Edwards grant.b.edwardsYow! Do you guys know we at just passed thru a BLACK gmail.comHOLE in space? -- https://mail.python.org/mailman/listinfo/python-list
Re: Guido (Sarducci)
haha that list is the best py community par excellence 👍 Abdur-Rahmaan Janhangeer http://www.pythonmembers.club Mauritius -- https://mail.python.org/mailman/listinfo/python-list
Re: the python name
On 17/01/19 6:10 PM, Gregory Ewing wrote: Avi Gross wrote: The question that seems to come up too often about the python name is a distraction. In particular, it is answered fairly prominently in many places as just being a nonsensical name because a founder once liked a comedic entity that chose an oddball name, so they did too. There's a long tradition of naming things after animals that have some of the qualities you want people to associate with them. In the case of Python, it's not a particularly fast animal, but it is sleek and powerful, and its minimal design has a certain elegance to it. So, I think it's very appropriate. Elsewhere there is discussion about the long tail (life) of v2. So, is there also some notion of Python shedding its skin, ie making way for newer concepts and greater consistency? (not that New Zealanders need to know much about snakes!) -- Regards =dn -- https://mail.python.org/mailman/listinfo/python-list
Re: Pythonic Y2K
On Wed, Jan 16, 2019 at 9:57 PM Avi Gross wrote: > > The forthcoming UNIX 2038 problem will, paradoxically happen on January 19. I wonder what they will do long before then. Will they just add a byte or four or 256 and then make a date measurable in picoseconds? Or will they start using a number format that can easily deal with 1 Million B.C. and 5 Billion A.D. just in case we escape earth before it co-locates with the expanding sun. The obvious solution is to stop using 32-bit Unix timestamps and start using 64-bit Unix timestamps. This change has already been made in some OSes, and the problem will not repeat until the year 292,277,026,596, by which time it is highly unlikely that either Unix timestamps or humankind itself will still exist. Even if they will, that moment in time is so far out from the present that I can't really be bothered by the possibility. We have 19 years to take care of the problem before it happens. Hopefully this time around we won't be trying to fix it right up until the last minute. -- https://mail.python.org/mailman/listinfo/python-list
Re: Pythonic Y2K
On Fri, Jan 18, 2019 at 5:48 AM Schachner, Joseph wrote: > > I'd like to add one more thing to your list of what companies will have to > consider: > > 6) The ability to hire and retain employees who will be happy to program in > an obsolete version of Python. A version about which new books will probably > not be written. A version which new packages will not support. A version > which most other companies will no longer be using, so programming only in > Python 2 will place the employee at a disadvantage compared to others who > have gained experience with Python 3 if they ever have to change employers. > The costs I described were _alternatives_, so what you've really described here is one component of the costs of status quo, maintaining a local fork, or using commercial Py2 support (options 1, 4, and 5). It is definitely a cost, though, and may at some point become the impetus for a company to migrate to Py3... but frankly, I doubt it. "Legacy code" is a pretty big thing in a lot of places. Just search thedailywtf.com for "legacy" and you'll find plenty of stories of terrible codebases held together by duct tape and blue tack, run through a hodge-podge of different language interpreters, or even just one interpreter but the wrong one... https://thedailywtf.com/articles/VB_0x2b__0x2b_ By comparison to THAT, a "legacy system" that runs a clean Python 2.7 is going to be pretty tame. Until someone says, oh hey, we should use function annotations, and then starts running all their code (in production) via 2to3... naw, that'll never happen, right? Oh. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
RE: Pythonic Y2K
I'd like to add one more thing to your list of what companies will have to consider: 6) The ability to hire and retain employees who will be happy to program in an obsolete version of Python. A version about which new books will probably not be written. A version which new packages will not support. A version which most other companies will no longer be using, so programming only in Python 2 will place the employee at a disadvantage compared to others who have gained experience with Python 3 if they ever have to change employers. --- Joseph S. -Original Message- From: Chris Angelico Sent: Wednesday, January 16, 2019 2:15 PM To: Python Subject: Re: Pythonic Y2K On Thu, Jan 17, 2019 at 6:04 AM Avi Gross wrote: > > I see messages like the following where someone is still asking how to > do something in some version of python 2.X. > > I recall the days before the year 2000 with the Y2K scare when people > worried that legacy software might stop working or do horrible things > once the clock turned. It may even have been scary enough for some > companies to rewrite key applications and even switch from languages like > COBOL. > > What is happening in the python community, and especially in places > where broken software may be a serious problem? > > I assume versions of python 2.X will continue to be available for some > time but without any further support and without features being back-ported. Commercial support for Python 2 will probably continue for a while, in the same way that support for versions older than 2.7 is still available to Red Hat customers today (if I'm not mistaken). Otherwise, well, the software will continue without updates or security patches until it breaks. Companies will have to weigh up five costs against each other: 1) The cost of the status quo: the risk of critical failures or external attacks against unsupported and unpatched software 2) The cost of migrating to Python 3 3) The cost of migrating to a completely different language 4) The cost of maintaining their own local fork of Python 2 5) The cost of using a supported commercial platform such as RHEL. For most small to medium projects, it's probably going to come down to #1 or #2, where #1 has the laziness bonus. For many larger companies, #1 is an unpayable cost. Everyone has to make that choice, and remember that "cost" doesn't just mean money (for instance, the cost of moving to Linux might be quite considerable for a Windows shop, and even within a Linux ecosystem, switching to Red Hat may have consequences to other programs you might need). ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: AssertionError without traceback?
--- Israel Brewster Systems Analyst II 5245 Airport Industrial Rd Fairbanks, AK 99709 (907) 450-7293 --- [cid:bfa5c323-b100-481d-96b1-fc256ef2eb39@flyravn.com] [cid:8c891973-9e67-47b3-aa14-5f58b9b93607@flyravn.com] On Jan 14, 2019, at 10:40 PM, dieter mailto:die...@handshake.de>> wrote: Israel Brewster mailto:ibrews...@flyravn.com>> writes: I have a flask application deployed on CentOS 7 using Python 3.6.7 and uwsgi 2.0.17.1, proxied behind nginx. uwsgi is configured to listed on a socket in /tmp. The app uses gevent and the flask_uwsgi_websockets plugin as well as various other third-party modules, all installed via pip in a virtualenv. The environment was set up using pip just a couple of days ago, so everything should be fully up-to-date. The application *appears* to be running properly (it is in moderate use and there have been no reports of issues, nor has my testing turned up any problems), however I keep getting entries like the following in the error log: AssertionError 2019-01-14T19:16:32Z failed with AssertionError I would try to find out where the log message above has been generated and ensure it does not only log the information above but also the associated traceback. Any tips as to how? I tried putting in additional logging at a couple places where I called gevent.spawn() to see if that additional logging lined up with the assertions, but no luck. I guess I could just start peppering my code with logging commands, and hope something pops, but this seems quite...inelegant. I have not been able to reproduce the error, unfortunately. I assume that the log comes from some framework -- maybe "uwsgi" or "gevent". It is a weakness to log exceptions without the associated traceback. Fully agreed on both points. The reference to the callback for some reason puts me in mind of C code, but of course AssertionError is python, so maybe not. For what it's worth, the issue only seems to happen when the server is under relatively heavy load. During the night, when it is mostly idle, I don't get many (if any) errors. And this has only been happening since I upgraded to CentOS7 and the latest versions of all the frameworks. Hopefully it isn't a version incompatibility... There is no additional information provided, just that. I was running the same app (checked out from a GIT repository, so exact same code) on CentOS 6 for years without issue, it was only since I moved to CentOS 7 that I've seen the errors. I have not so far been able to correlate this error with any specific request. Has anyone seen anything like this before such that you can give me some pointers to fixing this? As the application *appears* to be functioning normally, it may not be a big issue, but it has locked up once since the move (no errors in the log, just not responding on the socket), so I am a bit concerned. --- Israel Brewster Systems Analyst II 5245 Airport Industrial Rd Fairbanks, AK 99709 (907) 450-7293 --- [cid:05a3a602-0c27-4749-91b8-096a5857d984@flyravn.com] [cid:bbc82752-6db4-44cf-b919-421ed304e1d1@flyravn.com] -- https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: python package management confusion
On Thursday, 17 January 2019 07:41:43 UTC, dieter wrote:
> dcs3spp via Python-list writes:
> > ...
> > How do I configure python setup.py develop to pull the pyramid_core
> > dependent packages using virtualenv?
>
> Your "setup.py" below should work (once, you have removed the "").
> If the "pyramid" package correctly declares its dependencies,
> then the "pyramid_core" is even likely unnecessary.
>
> Try it out.
>
> > *** setup.py **
> >
> > import os
> > import sys
> >
> > from setuptools import setup, find_packages
> >
> > here = os.path.abspath(os.path.dirname(__file__))
> > with open(os.path.join(here, 'README.md')) as f:
> > README = f.read()
> > with open(os.path.join(here, 'CHANGES.md')) as f:
> > CHANGES = f.read()
> >
> > requires = [
> > 'cryptography',
> > 'odfpy',
> > 'PyJWT',
> > 'pycrypto',
> > 'pyramid',
> > * 'pyramid_core', ***
> > requirements.txt file?
> > 'pyramid_debugtoolbar',
> > 'pyramid_tm',
> > 'requests==2.18.4',
> > 'SQLAlchemy',
> > 'transaction',
> > 'zope.sqlalchemy',
> > 'waitress',
> > 'psycopg2-binary',
> > 'python-dateutil',
> > 'uwsgi',
> > 'marshmallow-sqlalchemy',
> > ]
> >
> > setup_requires = [
> > 'pytest-runner',
> > ]
> >
> > tests_require = [
> > 'boto3',
> > 'lovely-pytest-docker',
> > 'pytest',
> > 'pytest-cov',
> > 'tuspy',
> > 'WebTest >= 1.3.1',
> > ]
> >
> > setup(name='api',
> > version='0.0',
> > description='api',
> > long_description=README + '\n\n' + CHANGES,
> > classifiers=[
> > "Programming Language :: Python",
> > "Framework :: Pyramid",
> > "Topic :: Internet :: WWW/HTTP",
> > "Topic :: Internet :: WWW/HTTP :: WSGI :: Application",
> > ],
> > author='simon pears',
> > author_email='roughlea-mu...@outlook.com',
> > url='',
> > keywords='web wsgi bfg pylons pyramid',
> > packages=find_packages('src'),
> > package_dir={'': 'src'},
> > include_package_data=True,
> > zip_safe=False,
> > extras_require={
> > 'testing': tests_require,
> > },
> > install_requires=requires,
> > setup_requires=setup_requires,
> > tests_require=tests_require,
> > test_suite='tests',
> > entry_points="""\
> > [paste.app_factory]
> > main = api:main
> > [console_scripts]
> > initialize_api_db = api.scripts.initializedb:main
> > """,
> > )
Apologies dieter, I have not explained very well. I have written the
pyramid_core package, it is not an external pypi package. I wish to use it
across my own private projects, including CI builds mentioned earlier.
How do I configure setuptools to pull my own private dependency package using
virtualenv + python setup.py develop
--
https://mail.python.org/mailman/listinfo/python-list
Re: [tkinter] question about correct use of validation
steve wrote: > Il 16/01/19 08:51, Peter Otten ha scritto: > >> def make_ui(self): >> ''' create user interface ''' >> >> def vcmd(maxlength): >> return self.parent.register( >> partial(self.maxlength_validate, maxlength=maxlength) >> ), "%P" >> > ... > > ok following your advice and that of Rick in the previous post, I > developed 2 solutions, one without classes and one with classes. I write > to you if you need someone: Two remarks: > self.id1_entry = self.make_entry(self.parent, maxlen=1).pack() You set all idX_entry attributes to None, as that's what pack() returns. > apply(Entry.__init__, (self, master), kw) You can write that in way compatible with Python 3 as Entry.__init__(self, master, **kw) > Thank you all You're welcome. -- https://mail.python.org/mailman/listinfo/python-list
Re: Guido (Sarducci)
On 1/16/19 9:48 PM, Avi Gross wrote: Dennis, I wish to apologize for introducing any suggestion to name anything as Guido, let alone any language that springs from a python. Yes, it may be a stereotypic Italian name related to what you hint at. You probably recognized it as an allusion to someone who is clearly Dutch and has some finite relationship with python. The name is ultimately Germanic and used in many countries. I, in a Monty Python Spirit, insist I was thinking about the Saturday Night Live comedic character from generations ago, Father Guido Sarducci, who does indeed appear to be Italian. That is the pythonic way to choose a name although 3.X might well have been named after the Three Stooges. Again, my apologies. I will try to resume being serious and maybe talk about mission creep. Avi -Original Message- From: Python-list On Behalf Of Dennis Lee Bieber Sent: Wednesday, January 16, 2019 4:36 PM To: python-list@python.org Subject: Re: the python name On Wed, 16 Jan 2019 13:46:29 -0500, "Avi Gross" declaimed the following: [HUMOR for the ALERT] But as languages develop and evolve, sometimes a name change may be a decent idea. Perhaps version 4.0 should be renamed Guido so we can get more silly questions. So we can make jokes about a mafia hitman (which is where many might go with the name) Imagine people developing languages like X and Y and over the years enhancing them. An Enhanced or Extended X, naturally, might be renamed EX. Getting too close to REXX (which was something like Restructured EXtended eXecutor). With further Super new features (think super-symmetry in Physics) we would have a Super Extended X, or SEX in brief. Computer science already has sexpr https://en.wikipedia.org/wiki/S-expression Finda de pope ina de pizza! A very funny skit! -- https://mail.python.org/mailman/listinfo/python-list
Re: [tkinter] question about correct use of validation
Il 16/01/19 08:51, Peter Otten ha scritto:
def make_ui(self):
''' create user interface '''
def vcmd(maxlength):
return self.parent.register(
partial(self.maxlength_validate, maxlength=maxlength)
), "%P"
...
ok following your advice and that of Rick in the previous post, I
developed 2 solutions, one without classes and one with classes. I write
to you if you need someone:
1) solution with class
(taking a cue from here:
http://effbot.org/zone/tkinter-entry-validate.htm - I wanted to reduce
the code, I'm working on it)
from Tkinter import *
class View():
''' example for set max length of char in Entry widget.
-Class implantation-
'''
def __init__(self, parent):
self.parent = parent
self.make_ui()
def make_ui(self):
''' create user interface '''
self.id1_entry = self.make_entry(self.parent, maxlen=1).pack()
self.id2_entry = self.make_entry(self.parent, maxlen=2).pack()
self.id3_entry = self.make_entry(self.parent, maxlen=3).pack()
self.id4_entry = self.make_entry(self.parent, maxlen=4).pack()
self.id5_entry = self.make_entry(self.parent, maxlen=5).pack()
def make_entry(self, parent, width=50, maxlen=30,
highlightcolor='blue',
validate='key'):
entry = MyEntry(parent, maxlen=maxlen)
entry.configure(width=width, highlightcolor=highlightcolor)
return entry
class ValidatingEntry(Entry):
# base class for validating entry widgets
def __init__(self, master, value="", **kw):
apply(Entry.__init__, (self, master), kw)
self.__value = value
self.__variable = StringVar()
self.__variable.set(value)
self.__variable.trace("w", self.__callback)
self.config(textvariable=self.__variable)
self.configure(highlightcolor='blue')
def __callback(self, *dummy):
value = self.__variable.get()
newvalue = self.validate(value)
if newvalue is None:
self.__variable.set(self.__value)
elif newvalue != value:
self.__value = newvalue
self.__variable.set(newvalue)
else:
self.__value = value
def validate(self, value):
# override: return value, new value, or None if invalid
return value
class MyEntry(ValidatingEntry):
def __init__(self, master, value="", maxlen=None, **kw):
self.maxlength = maxlen
apply(ValidatingEntry.__init__, (self, master), kw)
def validate(self, value):
return value[:self.maxlength]
def run():
root = Tk()
root.title('test')
View(root)
root.mainloop()
if __name__ == "__main__":
run()
2) classless solution (part of your code)
from Tkinter import *
from functools import partial
class View():
''' example for set max length of char in Entry widget.
-Functions implantation-
'''
def __init__(self, parent):
self.parent = parent
self.make_ui()
def make_ui(self):
''' create user interface '''
self.id1_entry = self.make_entry(self.parent, maxlen=1).pack()
self.id2_entry = self.make_entry(self.parent, maxlen=2).pack()
self.id3_entry = self.make_entry(self.parent, maxlen=3).pack()
self.id4_entry = self.make_entry(self.parent, maxlen=4).pack()
self.id5_entry = self.make_entry(self.parent, maxlen=5).pack()
def make_entry(self, parent, width=50, maxlen=30,
highlightcolor='blue',
validate='key'):
def vcmd(maxlength):
return self.parent.register(partial(self.maxlength_validate,
maxlength=maxlength)), "%P"
entry = Entry(parent)
entry.configure(width=width, highlightcolor=highlightcolor,
validate='key', validatecommand=vcmd(maxlen))
return entry
def maxlength_validate(self, value, maxlength):
return len(value) <= maxlength
def run():
root = Tk()
root.title('test')
View(root)
root.mainloop()
if __name__ == "__main__":
run()
Thank you all
--
https://mail.python.org/mailman/listinfo/python-list
Re: ImportError: cannot import name certificate_transparency
On Thursday, January 17, 2019 at 12:10:51 AM UTC-8, Stone Zhong wrote: > Hi, > > My program depend on package oci, I am using the following command to install > it: > pip install oci > > Everything works perfect in virtualenv (I am still using python 2.7.x) > > Now I am creating a zip file from the libraries: > > pip install oci -t ~/temp/oci > cd ~/temp/oci > zip -r ~/temp/oci.zip . > > Test A) PYTHONPATH=~/temp/oci myapp.py > Test B) PYTHONPATH=~/temp/oci.zip myapp.py > > Test A) works fine and Test B) failed with error "ImportError: cannot import > name certificate_transparency" > > It seems we have some so file there: > ./cryptography/hazmat/bindings/_padding.so > ./cryptography/hazmat/bindings/_openssl.so > ./cryptography/hazmat/bindings/_constant_time.so > ./_cffi_backend.so > > I also tested below: > > mytest.py: > ... > from cryptography.hazmat.bindings._constant_time import lib > > PYTHONPATH=~/temp/oci.zip mytest.py > > I end up with error "ImportError: No module named _constant_time" > > So my guess is, package with shared lib (.so files) cannot be put into zip > file, is it a bug in python zipimport? > > The reason I have to use a zip file is, I need it in a spark job, I cannot do > "virtualenv" in pyspark, have to use --py-files to pass the zip file for all > dependent packages. > > Thanks, > Stone ok, found the doc @ https://docs.python.org/3/library/zipimport.html import of dynamic modules (.pyd, .so) is disallowed. So it is not a bug. -- https://mail.python.org/mailman/listinfo/python-list
ImportError: cannot import name certificate_transparency
Hi, My program depend on package oci, I am using the following command to install it: pip install oci Everything works perfect in virtualenv (I am still using python 2.7.x) Now I am creating a zip file from the libraries: pip install oci -t ~/temp/oci cd ~/temp/oci zip -r ~/temp/oci.zip . Test A) PYTHONPATH=~/temp/oci myapp.py Test B) PYTHONPATH=~/temp/oci.zip myapp.py Test A) works fine and Test B) failed with error "ImportError: cannot import name certificate_transparency" It seems we have some so file there: ./cryptography/hazmat/bindings/_padding.so ./cryptography/hazmat/bindings/_openssl.so ./cryptography/hazmat/bindings/_constant_time.so ./_cffi_backend.so I also tested below: mytest.py: ... from cryptography.hazmat.bindings._constant_time import lib PYTHONPATH=~/temp/oci.zip mytest.py I end up with error "ImportError: No module named _constant_time" So my guess is, package with shared lib (.so files) cannot be put into zip file, is it a bug in python zipimport? The reason I have to use a zip file is, I need it in a spark job, I cannot do "virtualenv" in pyspark, have to use --py-files to pass the zip file for all dependent packages. Thanks, Stone -- https://mail.python.org/mailman/listinfo/python-list
