Re: [tkinter] question about correct use of validation
steve wrote:
> for determine the maximum number of characters in an entry
>
> I have read several interpretations for the solution of the problem, but
> I wanted to find an alternative way (for convenience of the code)
>
> I kindly ask for an opinion on the use of validation in this way.
>
> -
>
> problem: limit number of characters in different entries of a form.
>
> code:
>
> #!/usr/bin/python
> # -*- coding: utf-8 -*
>
> from Tkinter import *
>
>
> class View():
>
> def __init__(self, parent):
> self.parent = parent
> self.make_ui()
>
> def make_ui(self):
> ''' create user interface '''
> self.id_entry = Entry(self.parent, width=6)
> # take out the properties for understanding
>
> vcmd = (self.parent.register(self.maxlength_validate), '%P', 4)
> # 4 is my question
>
> self.id_entry.configure(validate="key", validatecommand=vcmd)
> self.id_entry.pack()
>
> self.name_entry = Entry(self.parent, width=30)
> # take out the properties for understanding
>
> vcmd = (self.parent.register(self.maxlength_validate), '%P', 20)
> # 20 is my question
>
> self.name_entry.configure(validate="key", validatecommand=vcmd)
> self.name_entry.pack()
>
> def maxlength_validate(self, value, maxlength):
> ''' function validated for maximum number of characters '''
> maxlength = int(maxlength)
> if len(value) > maxlength:
> value = value[:maxlength]
> return (value == ' ')
> return True
>
>
> def run():
> root = Tk()
> root.title('test')
> View(root)
> root.mainloop()
>
> if __name__ == "__main__":
> run()
>
> The code works well :-) but...
>
> in vcmd i use this:
>
> vcmd = (self.parent.register(self.maxlength_validate), '%P', 20)
> # '20' argument is my question, is not default value (is max length of
> char, different for each entry... very comfortable for me)
>
> is it all right, according to you, to pass a non-default argument? (no
> error from the interpreter)
>
> Without this way I would not know how to pass the maximum number of
> characters to the validation function, I can not use one variable
> self.--- for each entry ... it would become aesthetically unattractive.
>
> I would not even like to add a textvariable variable because anyway then
>
> I should always pass the comparison value.
>
> thank you in advance
A viable alternative may be to use functools.partial() to pass the
maxlength:
from Tkinter import *
from functools import partial
class View():
def __init__(self, parent):
self.parent = parent
self.make_ui()
def make_ui(self):
''' create user interface '''
def vcmd(maxlength):
return self.parent.register(
partial(self.maxlength_validate, maxlength=maxlength)
), "%P"
self.id_entry = Entry(self.parent, width=6)
# take out the properties for understanding
self.id_entry.configure(validate="key", validatecommand=vcmd(4))
self.id_entry.pack()
self.name_entry = Entry(self.parent, width=30)
# take out the properties for understanding
self.name_entry.configure(validate="key", validatecommand=vcmd(20))
self.name_entry.pack()
def maxlength_validate(self, value, maxlength):
return len(value) <= maxlength
--
https://mail.python.org/mailman/listinfo/python-list
Re: Email blast management?
unless there's a solid python solution out there ready to plug in Abdur-Rahmaan Janhangeer http://www.pythonmembers.club Mauritius -- https://mail.python.org/mailman/listinfo/python-list
Re: python package management confusion
On Wednesday, 16 January 2019 07:07:29 UTC, dieter wrote:
> dcs3spp via Python-list writes:
> > ...
> > So to manage the development of private packages, e.g. wheels, I would have
> > to use my own private repository (something like devpi or a an alternative
> > cloud pypi subscription service) to store each private dependency that I
> > have written.
>
> No, you do not need something like "devpi" (or similar).
> Instead, you can set up a "virtualenv" (there is a Python package
> which can build "virtualenv"s), and use "setuptool"'s "develop"
> "setup" command to "install" links to the package sources you
> currently have under development. "develop" will automatically
> install external requirements via "pypi".
>
> > ...
> > However, if I wanted to take a step further and run a CI build using cloud
> > services(e.g. in a private gitlab.com repository) for a package that uses
> > the private packages, then presumably there is no access to the devpi
> > repository on my local system? So, alternatively when developing private
> > Python packages I either use requirements.txt or pay subscription for a
> > private pypi cloud repository and configure pip, setup.cfg on gitlab.com CI
> > to reference it in config files. When the CI build completes it pushes the
> > package to the private pypi repository.
>
> I assume that you will be able to build an appropriate "virtualenv"
> in a CI build setup.
Thankyou for responding and thanks for your patience with this newbie dieter
A, so it is possible to use a virtualenv to pull in dependencies from
setup.py
I have the setup.py below and the pyramid_core package surrounded by * in the
requires list has own setup.py and virtual environment. I currently have
pip.conf and setup.cfg etc. setup to pull this dependency from devpi repository.
How do I configure python setup.py develop to pull the pyramid_core dependent
packages using virtualenv?
*** 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
""",
)
--
https://mail.python.org/mailman/listinfo/python-list
Re: get the terminal's size
On 2019-01-16, Karen Shaeffer wrote: [fixed quoting and formatting] >> That will tell you the terminal size at the time Python was started. >> >> If the terminal size has changed while Python was running, those >> environment variables will be wrong. You need to use the TIOCGWINSZ >> ioctl call: >> >> http://www.delorie.com/djgpp/doc/libc/libc_495.html >> >> And to detect the size changes (so you know _when_ you need to do the >> above), you need to attach a signal handler for the WINCH signal. > > I'm running a python 3 interpreter on linux. I'm actually ssh'd into > the terminal on a headless server. [...] > [...] > With the python interpreter running on the remote terminal, I have > resized the terminal window on my local laptop several times. And > each time, the remote python interpreter knows about the change, > correctly printing the new size. I have done nothing with > environment variables. I have not used a signal handler for the > WINCH signal. It just works. Yes, we know that works on Python3. The discussion was about what to do on Python2. $ python2 Python 2.7.15 (default, Sep 12 2018, 15:19:18) [GCC 7.3.0] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import shutil >>> shutil.get_terminal_size() Traceback (most recent call last): File "", line 1, in AttributeError: 'module' object has no attribute 'get_terminal_size' >>> -- Grant Edwards grant.b.edwardsYow! I'm having a BIG BANG at THEORY!! gmail.com -- https://mail.python.org/mailman/listinfo/python-list
ANN: libchirp (Message-passing for everyone)
Announcing libchirp Message-passing for everyone. I proudly announce libchirp [0]. I believe queues, message-routers and patterns like pub-sub are the way message-passing should be done. However, I also believe they should be optional and tweak-able. libchirp does only one thing: message-passing with encryption. All other building-blocks should be implemented in upper-layer modules or daemons. libchirp is the basis for modular message-passing and actor-based programming. I want to thank Adfinis-SyGroup [1] who have supported me and allowed me to develop libchirp. [0] https://github.com/concretecloud/python-chirp [1] https://adfinis-sygroup.ch/ Here the mandatory echo-server example: import asyncio from libchirp.asyncio import Chirp, Config, Loop class EchoChirp(Chirp): async def handler(self, msg): await self.send(msg) loop = Loop(); config = Config() config.DISABLE_ENCRYPTION = True # Workers are usually asynchronous config.SYNCHRONOUS = False aio_loop = asyncio.get_event_loop() try: chirp = EchoChirp(loop, config, aio_loop) try: aio_loop.run_forever() finally: chirp.stop() finally: loop.stop() There is also a ThreadPoolExecutor- [2] and a Queue-based [3] interface. By the way libchirp for python are bindings to my C99-implementation [4]. My secondary goal is to build a polyglot message-passing toolkit. Please be welcome to contribute bindings for your favorite language. [2] https://docs.adfinis-sygroup.ch/public/python-chirp/pool.html [3] https://docs.adfinis-sygroup.ch/public/python-chirp/queue.html [4] https://github.com/concretecloud/chirp Project links * python-chirp: https://github.com/concretecloud/python-chirp * C99-chirp: https://github.com/concretecloud/chirp * Other chirp related software: https://github.com/concretecloud Best, Jean-Louis Fuchs -- https://mail.python.org/mailman/listinfo/python-list
RE: the python name
[HUMOR for the ALERT] 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. 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. There once was a trend to name languages after alphabetic symbols like C and R. I shudder to think of the possibilities opened up as python embraced Unicode and we now can select from many thousands of such singletons, most of which nobody knows how to pronounce. Imagine people developing languages like X and Y and over the years enhancing them. An Enhanced or Extended X, naturally, might be renamed EX. With further Super new features (think super-symmetry in Physics) we would have a Super Extended X, or SEX in brief. Naturally, there may be a tendency to suggest that Y has some really neat features and perhaps you should extend X in the direction of Y in a sort of merger you might call SEXY. OK, enough kidding around. But realistically, as I study the history of Python including not just new features but deprecating and even removing old features, and sometimes doing major rewrites of internal implementations and adding brand new methods and ideas and endless modules and so on, I wonder if my analogy is stretchable. Python may have begun as a snake of sorts able to do a simple form of locomotion but over the years, it seems to have re-grown 4 legs to be more like other reptiles and perhaps become like some ancient dinosaurs and then kept changing as it started to walk on hind legs and then the front legs morphed into wings so that modern python is not limited to low-lying ground movement but can run and swim and even fly and is now more of a bird. Given my current name, dare I say it seems sort of AVIan? Nah! -- https://mail.python.org/mailman/listinfo/python-list
Pythonic Y2K
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. Conversion of some features seems simple enough but as I have been studying, I keep running into many areas where the pythons differ and often in subtle ways that many may not know to change. I won't go into detail, but fixing the print statement to become the print function is far from enough. Some things can be made to work in the last versions of 2.7 where the back-porting allows a smoother transition. So, is there info out there on what may be problem areas? Are there modules, for example, that have not been ported and are not available for 3.X and don't have some similar enough other module that might be used? This is not just a python problem, of course. PERL is an example where there seem to be a new and incompatible old version running around. As a note, I am not complaining that python has evolved in incompatible ways. Not easy to avoid unless you like stasis. But if enough people keep avoiding the hints and outright warnings to get more up-to-date, this Y2-->3K event may be a problem. -Original Message- From: Python-list On Behalf Of Grant Edwards Sent: Wednesday, January 16, 2019 10:46 AM To: python-list@python.org Subject: Re: get the terminal's size On 2019-01-16, Karen Shaeffer wrote: [fixed quoting and formatting] >> That will tell you the terminal size at the time Python was started. >> >> If the terminal size has changed while Python was running, those >> environment variables will be wrong. You need to use the TIOCGWINSZ >> ioctl call: >> >> http://www.delorie.com/djgpp/doc/libc/libc_495.html >> >> And to detect the size changes (so you know _when_ you need to do the >> above), you need to attach a signal handler for the WINCH signal. > > I'm running a python 3 interpreter on linux. I'm actually ssh'd into > the terminal on a headless server. [...] [...] With the python > interpreter running on the remote terminal, I have resized the > terminal window on my local laptop several times. And each time, the > remote python interpreter knows about the change, correctly printing > the new size. I have done nothing with environment variables. I have > not used a signal handler for the WINCH signal. It just works. Yes, we know that works on Python3. The discussion was about what to do on Python2. $ python2 Python 2.7.15 (default, Sep 12 2018, 15:19:18) [GCC 7.3.0] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import shutil >>> shutil.get_terminal_size() Traceback (most recent call last): File "", line 1, in AttributeError: 'module' object has no attribute 'get_terminal_size' >>> -- Grant Edwards grant.b.edwardsYow! I'm having a BIG BANG at THEORY!! gmail.com -- https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
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: the python name
On Thu, Jan 17, 2019 at 8:37 AM Dennis Lee Bieber wrote: > > On Wed, 16 Jan 2019 13:46:29 -0500, "Avi Gross" > declaimed the following: > > >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). > I assumed that that's what Avi was referencing. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: get the terminal's size
On Mon, 14 Jan 2019 11:57:33 +, Alex Ternaute wrote:
> Hi there,
>
> I want to know the number of columns of the terminal where python2 writes
> it's outputs.
>
> In a terminal, I type
> $ echo $COLUMNS
> 100
>
> But in Python, os.getenv("COLUMNS") gets nothing.
> It gets nothing as well if I try to read the output of "echo $COLUMNS"
> from a subprocess.
>
> I feel that I'm missing something but what ?
>
> Looking on the internet for a hint, I see that python3 has an
> os.get_terminal_size().
> Please, is there something similar for python2 ?
>
> Cheers
I have used this Python2 code with success in Linux...
#!/usr/bin/env python
import fcntl
import os
import struct
import termios
tty = os.open(os.ctermid(), os.O_RDONLY)
ts = struct.unpack("hh", fcntl.ioctl(tty, termios.TIOCGWINSZ, "1234"))
os.close(tty)
print str(ts[1]) + "x" + str(ts[0])
--
GNU/Linux user #557453
"There are only 10 types of people in the world...
those who understand Binary and those who don't."
-Spike
--
https://mail.python.org/mailman/listinfo/python-list
Re: get the terminal's size
> On Mon, 14 Jan 2019 11:57:33 +, Alex Ternaute wrote: > > > Hi there, > > > > I want to know the number of columns of the terminal where python2 writes > > it's outputs. A couple days late to the party, a discussion of several ways I tried: http://shallowsky.com/blog/hardware/serial-24-line-terminals.html and the script I ended up with: https://github.com/akkana/scripts/blob/master/termsize (I've only tested these on Linux). ...Akkana -- https://mail.python.org/mailman/listinfo/python-list
RE: Pythonic Y2K
Chris, The comparison to Y2K was not a great one. I am not sure what people did in advance, but all it took was to set the clock forward on a test system and look for anomalies. Not everything would be found but it gave some hints. Similarly, it is trivial today to take a machine and install only the new python version and try it, albeit many programs may have effects far away across the internet in some apps and harder to isolate. But Y2K was going to happen guaranteed. The split between 2.X has been fairly slow in some ways and with crutches designed to make a transition smoother. As long as there are people willing to remain behind in what they consider safe territory, there will be those happy to sell them some things and probably raise their prices. I recall what happened with TELEX some years ago. It was awfully slow compared to other methods such as email or FAX but it had legal standing and clients who had to be reached in places that had less access and so on. I recall how despite huge drops in message volume year after year, it remained a very profitable item for my AT&T unit and continued to be supported as we just kept raising the price for those still wanting to use it. I was working on newer stuff and just watched several such parts in amazement including others using what I considered obsolete protocols. Not obsolete to those customers though. I empathize with people using software that already works. You know, if it isn't broken, But to continue making it work may require supplying complete solutions as customers cannot be expected to have older python interpreters sitting around on their machine. If your application resides within your servers and only communicates with others of the same ilk, you probably can continue using it indefinitely. There may be someone still using an ancient PC from the 80's running Windows 1.0 with a similarly old copy of WordPerfect and a serial printer attached. But if they want to load a recent version of Microsoft Office, forget it. Heck, it would not fit on their 20MEG hard disk. I assume there must be tools out there that can look over your code and point out places where it may not be compatible. But the more I learn, the more I realize how subtle a problem may be. Some of the back-ported features for example are not exactly identical in effect. Close, maybe. Things like changes in Unicode functionality often are papered over and then a valid statement in one may print a character while in the other it may print a short int. If you ran such a program and it showed minimal issues like just needing to change print statements into print functions, it might be easier to convince your boss to upgrade. If the effort looks massive, they may even opt for a complete rewrite or move to another language that is less likely to keep changing, or maybe just buy a solution that is not quite tailored to their needs. I did have an experience along these lines years ago when a new variation of C came across. Years ago I worked on a project at Bell Labs that was mostly in C. As C++ was coming out, I volunteered to do my part using it as I could show why my application would be object-oriented. I was shocked when they approved and I set up make files that recognized what code was in C or C++ and compiled and linked them properly and so on. It worked beautifully and guess what? We tossed the entire project! This was back in the days when AT&T cared less about wasting money. Our project had been canceled at higher levels and the management spent half a year deciding what our next project would be but felt no need to tell us! So when I offered to do something experimental, they figured why not! And, yes, eventually we did our new development in C++. But had they considered it, it would have made more sense to stop developing something and take the time to retrain the staff with courses that were available and have us use up some vacation days and be ready for a new project. Bottom line here is I should not be surprised if some people want an answer on how to keep projects in 2.X going. But, unless there is a reason, I see little reason in going along or teaching new programmers on what is in a sense the less useful version going forward. The main reason to study 2.X, FOR ME, is to be able to understand it if I encounter it and perhaps be able to rewrite it. -Original Message- From: Python-list On Behalf Of 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 langua
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
Re: Pythonic Y2K
On Wed, Jan 16, 2019 at 9:35 PM Avi Gross wrote: > > Chris, > > The comparison to Y2K was not a great one. I am not sure what people did in > advance, but all it took was to set the clock forward on a test system and > look for anomalies. Not everything would be found but it gave some hints. Clearly you did not live through that. I did and I got over 2 years of real work from it. Companies hired me to check their code and find their Y2K exposures. Things like a hard coded '19' being added to a 2 digit year. Or code that only allocated 2 bytes for the year. I could go on and on. At one client I had I found over 4,000 places in their code that needed to be modified. And there was no widespread use of VMs that you could easily and quickly spin up for testing. It was a real problem but because of many people like me, it was dealt with. Now the next thing to deal with is the Jan. 19, 2038 problem. I'll be 80 then, but probably still writing code. Call me if you need me. -- https://mail.python.org/mailman/listinfo/python-list
Re: Pythonic Y2K
On 17/01/19 4:45 PM, Larry Martell wrote: On Wed, Jan 16, 2019 at 9:35 PM Avi Gross wrote: Chris, The comparison to Y2K was not a great one. I am not sure what people did in advance, but all it took was to set the clock forward on a test system and look for anomalies. Not everything would be found but it gave some hints. Clearly you did not live through that. I did and I got over 2 years of real work from it. Companies hired me to check their code and find their Y2K exposures. Things like a hard coded '19' being added to a 2 digit year. Or code that only allocated 2 bytes for the year. I could go on and on. At one client I had I found over 4,000 places in their code that needed to be modified. And there was no widespread use of VMs that you could easily and quickly spin up for testing. It was a real problem but because of many people like me, it was dealt with. Now the next thing to deal with is the Jan. 19, 2038 problem. I'll be 80 then, but probably still writing code. Call me if you need me. Same. The easy part was finding the hardware, configuring identical systems, and changing the date-era. Remember that we pre-dated TDD, so we pretty much re-designed entire testing suites! The most difficult work was with the oldest systems - for which there was no/little/worthless documentation, and usually no dev staff with 'memory'. Then there were the faults in OpSys and systems programs on which we could supposedly rely - I still have a couple of certificates somewhere, for diagnosing faults which MSFT had not found... The difficulty of multi-layer fault-finding is an order of magnitude more difficult than Python debugging alone! I'm told there are fewer and fewer COBOL programmers around, and those that survive can command higher rates as a consequence. Would going 'back' to that be regarded as "up" skilling? Does this imply that there might one day be a premium chargeable by Py2.n coders? -- Regards =dn -- https://mail.python.org/mailman/listinfo/python-list
RE: Pythonic Y2K
Larry, I was not belittling the effort it took to make sure Y2K was not a disaster. I was making the comparison of how you could start to emulate the problem in advance just as you can easily test older python code with newer ones. My work those days was in places where we did not do much of what you point out such as a hardcoded 19 or using a condensed date format. I had a cousin die recently at 105 and his brother is now 103 and clearly they would not fit well in a 2-digit date field as they might be placed in kindergarten. Weird assumptions were often made because saving space in memory or on tape was considered essential. 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. This may be a place where the unlimited integer in python may be useful but with some hidden gotchas as I can think of places where longer ints are not trivially supported. You actually are sort of making my point clearer. The Y2K problem was "partially" due to the fact that code people wrote was not expected to be around very long and yet some sort of inertia kept plenty around and even when new code came along, it tried to emulate the old. I can well understand people holding on to what they know, especially when the new stuff is likely to keep changing. Some of that legacy code probably is very un-pythonic and a relatively minimal translation from how it was done in C, when that is possible. Arguably such code might be easier to port as it may use just 2% of what python makes available. No functional programming, no classes/objects, just ASCII text and while loops. 😊 Remember when file names were very limited? DOS was 8 by 3. UNIX was once 14 with the optional period anywhere including at the beginning. People often made somewhat compressed names and a two-character year was all you had room for. I have data I sometimes work with containing hundreds of variables with 8-character names that drive me nuts as they are not meaningful to me. I often read them in and rename them. How would you encode say a test score taken on December 22, 2013? "1013" would use up the entire allotment. Back to python, I see lots of mission creep mixed in with nice features to the point where it stopped being a particularly simple language many releases ago. Some of that may be part of what makes upgrading some code harder. Many additions include seemingly endless dunder variables that enable some protocols. I mean __ADD_ may seem a reasonable way to define what happens when a binary "+" operation is defined, but then you have left/right versions of it as well as autoincrement as well as symbols with similar and sometimes confusing meanings and many that do not correspond to symbols in the language such as __ITER__ and __NEXT__ whose presence drives an added iteration protocol. The zoo can be confusing and new stuff keeps being added including in modules outside the formal language. It is great and can separate the women from the girls, so to speak. Lots of nice, convenient and powerful functionality can be added by placing such methods or variables in objects directly or in associated objects. But I see it as a tad clearer in a language like R where you can name an operator in some form of quotes. I do not recommend redefining the plus operator as I am about to do but note base R does not add using "+" and you generally use the paste() function. (Ignore the prompt of "> " in the example below.) > "hello" + "world" Error in "hello" + "world" : non-numeric argument to binary operator > '+' <- function(x, y) paste(x, y, sep="+++") > "hello" + "world" [1] "hello+++world" > "one" + "two" + "three" [1] "one+++two+++three" The point is you know what is being changed rather than having to identify what a "word" like __iadd__ means or that when it is absent, the regular __add__ is used. And you can extend the language this way quite a bit like by making operators between percent signs like "%*%" or "%matrixmult%" or whatever. Heck, there are many versions of pipes made using "%>%" or other such invented symbols that make writing some code easier and clearer. Not saying the language is overall better or that some features would be a good idea to graft on now. Just that some things may be more intuitive and as python keeps adding to a namespace, the meaning of a class keeps getting more amorphous and sometimes has so much loaded into it that it fills multiple pages. I would not show most beginners too much of python at first, or just ask them to take some things on faith for a while. A language that initially claimed to be designed to do things pretty much ONE wa
Re: the python name
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. That may be how it started, but I don't think Python is a silly name for a programming language at all. 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. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: the python name
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. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
RE: Pythonic Y2K
Dave,
You have me worried now. Yes, years from now you may need experts who can
handle not just 2.X but specific versions like 2.4. Assuming python keeps
making incompatible changes and is up to version 9.02, you may also have 3.X
experts and 4.X experts and so on.
Of course, by then, some of the experts may be an AI specializing ...
All kidding aside, I have to wonder if future developments may result in new
categories of computer languages that are designed anew in radically
different ways to the point where it may get more people to switch and more
languages to halt further development.
I see Unicode as a potential driver. The number of symbols in languages like
python is fixed by what can be seen on a normal keyboard. That keyboard
needs to change a bit, or some virtual version, to support lots more. When
that happens, we won't be forced to do as much sharing and overloading as we
do now. How many ways is "%" used including within one line of code?
>>> print("%d %s " % (9 % 5, "ways to use %"))
4 ways to use %
Similarly, {} can be used for dictionaries or sets but an empty set
initializes a dictionary only. [] can be used to index lists by number or
dictionaries by key. There are not as many such sets of characters available
and <> is reserved for other uses and parentheses also has an odd role with
tuples as well as keeping things in some order of operations. Imagine adding
a few more matched symbols including some you can define for your own newly
created kinds of data like matrices. Similarly, you could have an
abbreviated way of defining additional operations if you could just use come
common mathematical symbols that are not in ASCII, not to mention some
dingbats.
If a programming language leaped across the ASCII divide (and I am sure some
have, including the languages that used backspace to make overwritten
multi-character operators) I can see ways to make more compact but less
confusing languages. I admit that might confuse some people, especially some
that only really know one language. I am used to multiple languages
including some with rather unique character sets and perhaps may be the only
one willing to use such a language. OK, sort of kidding.
I have seen many forums like this one (and not just about computer
languages) where I encounter true believers that do not welcome any
suggestion that there may be other things out there with some merit or that
their own may change. I welcome change and am interested in different ways
of thinking. This makes it harder for me to quite see the viewpoint that I
associate with stasis. But, to each their own. Perhaps literally.
-Original Message-
From: Python-list On
Behalf Of DL Neil
Sent: Wednesday, January 16, 2019 11:04 PM
To: Python
Subject: Re: Pythonic Y2K
On 17/01/19 4:45 PM, Larry Martell wrote:
> On Wed, Jan 16, 2019 at 9:35 PM Avi Gross wrote:
>>
>> Chris,
>>
>> The comparison to Y2K was not a great one. I am not sure what people
>> did in advance, but all it took was to set the clock forward on a
>> test system and look for anomalies. Not everything would be found but it
gave some hints.
>
> Clearly you did not live through that. I did and I got over 2 years of
> real work from it. Companies hired me to check their code and find
> their Y2K exposures. Things like a hard coded '19' being added to a 2
> digit year. Or code that only allocated 2 bytes for the year. I could
> go on and on. At one client I had I found over 4,000 places in their
> code that needed to be modified. And there was no widespread use of
> VMs that you could easily and quickly spin up for testing. It was a
> real problem but because of many people like me, it was dealt with.
> Now the next thing to deal with is the Jan. 19, 2038 problem. I'll be
> 80 then, but probably still writing code. Call me if you need me.
Same.
The easy part was finding the hardware, configuring identical systems, and
changing the date-era. Remember that we pre-dated TDD, so we pretty much
re-designed entire testing suites! The most difficult work was with the
oldest systems - for which there was no/little/worthless documentation, and
usually no dev staff with 'memory'.
Then there were the faults in OpSys and systems programs on which we could
supposedly rely - I still have a couple of certificates somewhere, for
diagnosing faults which MSFT had not found... The difficulty of multi-layer
fault-finding is an order of magnitude more difficult than Python debugging
alone!
I'm told there are fewer and fewer COBOL programmers around, and those that
survive can command higher rates as a consequence. Would going 'back' to
that be regarded as "up" skilling?
Does this imply that there might one day be a premium chargeable by Py2.n
coders?
--
Regards =dn
--
https://mail.python.org/mailman/listinfo/python-list
--
https://mail.python.org/mailman/listinfo/python-list
Re: Pythonic Y2K
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? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
RE: the python name
Greg, Boy am I getting sorry I brought this topic up again. Getting hard to take seriously. I am not making fun of the python name. I am making fun of the people that want a GOOD REASON for choosing a name. People generally don't care what silly name you choose for a dog and certainly tolerate weird names for a racehorse. But they might question naming a child Thingamajig Mistake Jones or Moon Unit, whatever that means. Is python an elegant animal name for the language python once was? Sure. Many animals are admired and on the cover of computer books. My PERSONAL opinion is that it has become quite a complex language and might as well be named "The Bronx Zoo" as it houses lots of different animating aspects. I like it when a commonly used name is easy to remember and pronounce unlike, say, 3CPO and R2D2. I am now truly sorry I said anything since no matter what I say, someone will find it wanting. When python grows enough, maybe we can rename it "the Full Monty" and people will still ask why. The name is among the least important things about python. So is the animal it also represents. But if it pleases some people, good for them. -Original Message- From: Python-list On Behalf Of Gregory Ewing Sent: Thursday, January 17, 2019 12:10 AM To: python-list@python.org Subject: Re: the python name 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. That may be how it started, but I don't think Python is a silly name for a programming language at all. 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. -- Greg -- https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: python package management confusion
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
> """,
> )
--
https://mail.python.org/mailman/listinfo/python-list
