Re: Looking for a recent quote about dynamic typing, possibly on this list
On Sat, 07 Jul 2018 11:38:37 +1000, Ben Finney wrote: > Steven D'Aprano writes: > >> Somebody gave a quote about dynamic typing, along the lines of >> >> "Just because a language allows a lot of dynamic features, doesn't mean >> people's code uses a lot of dynamism." > > You did refer us to http://lambda-the-ultimate.org/node/1519> on > this forum. That contains a quote attributed to John Aycock with the > meaning you paraphrase above. That's it! You're my hero! I knew it wasn't *my* quote, I had forgotten that I linked to it. Thanks. -- Steven D'Aprano "Ever since I learned about confirmation bias, I've been seeing it everywhere." -- Jon Ronson -- https://mail.python.org/mailman/listinfo/python-list
Re: PEP 526 - var annotations and the spirit of python
On Fri, 06 Jul 2018 09:42:09 +0200, Antoon Pardon wrote: > On 06-07-18 08:17, Steven D'Aprano wrote: >> On Thu, 05 Jul 2018 16:09:52 +0200, Antoon Pardon wrote: >> This is not an innovation of Mypy. It's how type inference is supposed to work. If a particular type checker doesn't do that, it is doing it wrong. >>> That is how type interference works in languages that have some kind >>> of static typing like Haskell. >> No, that's how type inference works in dynamically typed languages like >> Python as well. See Mypy for an example. > > Sorry, but this kind of wording is misleading to me. IMO, it strongly > suggests that we can have type inference in python without losing any of > the dynamism. That's true in two senses, false in a third. 1. We can have the benefits of static type checking without losing any of the *available* dynamism -- the Python interpreter remains fully dynamic and we can make use of that dynamism by simply *not* type-checking a particular function or module; 2. we can get the benefits of static type checking without losing the dynamism we *actually use*, because in general we don't use much of it (you don't miss what you don't use); 3. but in the third sense, of course you do have to choose to forgo the opportunity for some dynamism in order to get the benefit of static type checking. With gradual typing you can statically check the parts of your code that benefit from it while other parts of the code remain fully dynamic. The bottom line is that every Python programmer can choose for their own projects just how much or how little dynamism is appropriate, trading off the convenience of runtime dynamic typing with the type-safety of static type checking without needing to make an All Or Nothing choice. > The impression that I got from this thread was that you could just trow > any python program through mypy and it would work. Not quite, but you might be surprised. I know I was :-) I just picked a random selection of modules out of my private toolbox, ran mypy over them, and in a few tries found some bugs: steve@orac ~ $ mypy python/utilities/enhanced_dir.py python/utilities/enhanced_dir.py:141: error: Module 'types' has no attribute 'ClassType' steve@orac ~ $ mypy python/excguard.py python/excguard.py:138: error: "str" has no attribute "uper"; maybe "upper"? That's not bad. With absolutely no type hinting, mypy found two bugs in my code from six attempts. And remember, with no type annotations, Mypy is treating all the functions as duck-typed, even if I'm not using them in a duck-typed fashion. If I were to add annotations, I'd probably find a lot more errors. (I don't fool myself into thinking my code is bug-free.) You aren't going to get the full benefit of Mypy without making a commitment to type-hinting at least *some* of your code. Running it over a random Python module with no hints is not going to do much. >> But if you opt-in to using a type-checker, the assumption is that you >> are writing in a less-dynamic, more-static style that will actually get >> some advantage from static type checking. If you're not doing so, then >> you're just annoying yourself and wasting time and you won't enjoy the >> experience one bit. > > Thank you for this clarification. It seems that we are largely agreeing > but I seem to have understood your past contributions differently than > you intended. I may have been a little unclear, if so mea culpa, sorry for any misunderstanding I caused. -- Steven D'Aprano "Ever since I learned about confirmation bias, I've been seeing it everywhere." -- Jon Ronson -- https://mail.python.org/mailman/listinfo/python-list
Re: about main()
Robin Becker wrote: The villagers will shout "hey siri I need a compiler" and one will be provided Then one day someone says "Hey, Siri, make me an artificial intelligence that can respond to voice commands", and then it's not long before the AIs are breeding by themselves and take over. Berries are no longer required after that. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: about main()
On Fri, 06 Jul 2018 18:27:16 +, Grant Edwards wrote: > On 2018-07-06, Gene Heskett wrote: > >> In that case, I hate to say it, but your education is sorely lacking in >> the fundamentals. Smelting for instance was discussed at length in the >> high school physics books I was reading by the time I was in the 3rd >> grade. Don't they teach anything in school anymore? Tanning leather for >> instance involves a long soaking in strong tea, and doesn't name the >> brand or genus of the tea, the important part was the tannic acid >> content. > > IIRC, oack leaves/chips work well also. But the *best* quality tanned leather was historically made from dog faeces, known as "pure" by the tanners of the time: Members only: https://www.vettimes.co.uk/article/a-dirty-job-but-not-to-be-sniffed-at/ But this might work for you: https://www.vettimes.co.uk/app/uploads/wp-post-to-pdf-enhanced-cache/1/a-dirty-job-but-not-to-be-sniffed-at.pdf -- Steven D'Aprano "Ever since I learned about confirmation bias, I've been seeing it everywhere." -- Jon Ronson -- https://mail.python.org/mailman/listinfo/python-list
Re: Thread-safe way to add a key to a dict only if it isn't already there?
On Sat, 07 Jul 2018 02:51:41 +0900, INADA Naoki wrote:
> D.setdefault('c', None)
Oh that's clever!
Thanks!
--
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson
--
https://mail.python.org/mailman/listinfo/python-list
Re: Looking for a recent quote about dynamic typing, possibly on this list
Steven D'Aprano writes: > Somebody gave a quote about dynamic typing, along the lines of > > "Just because a language allows a lot of dynamic features, doesn't mean > people's code uses a lot of dynamism." You did refer us to http://lambda-the-ultimate.org/node/1519> on this forum. That contains a quote attributed to John Aycock with the meaning you paraphrase above. -- \“… it's best to confuse only one issue at a time.” —Brian W. | `\Kernighan and Dennis M. Ritchie, _The C programming language_, | _o__) 1988 | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: about main()
On 07/06/18 12:57, Terry Reedy wrote:
On 7/5/2018 9:40 PM, Jim Lee wrote:
On 07/05/18 18:25, Steven D'Aprano wrote:
On Thu, 05 Jul 2018 11:27:09 -0700, Jim Lee wrote:
Take a village of people. They live mostly on wild berries.
Because of course a community of people living on one food is so
realistic. Even the Eskimos and Inuit, living in some of the harshest
environments on earth, managed to have a relatively wide variety of
foods
in their diet.
https://en.wikipedia.org/wiki/Inuit_cuisine
Pedantics again. Didn't even get the point before tearing apart the
*analogy* rather than the *point itself*.
The irony of both Steven's interruption and your reaction is that the
Inuit story somewhat supports your point:
"There has been a decline of hunting partially due to the fact that
young people lack the skills to survive off the land. "
-- because they are 'growing more accustomed to the Qallunaat ("white
people") food that they receive from the south.'
If 'white people' food stopped coming, they would starve where they are.
But change scenarios that assume that everything else remains the same
are flawed. Maintaining traditional skills comes up in every culture
that is changing, which now is most all. But the same dynamism tends
to generate new solutions where needed.
Finally, a person with sense enough to contribute a rational thought to
this thread!
>"But the same dynamism tends to generate new solutions where needed."
Yes. However, technological evolution happens at a blindingly faster
rate than cultural evolution. Because of this, there are many of us
still alive who have been here "from the beginning" of the computer era.
That gives us a unique perspective, in that we have seen first-hand many
cycles of these "solutions" being invented, re-invented, and
re-re-invented. We lament the continual re-emergence of bad ideas that
have failed in the past (and applaud the good ones).
People like that, in a cultural context, are treated as wise elders; in
the technology context, they're treated as doddering old fools.
Somehow, we've adopted the notion that old == obsolete == useless when
it comes to technological ideas. I've seen more than one person refuse
to consider some software application (even though it fit their
requirements perfectly) simply because it hadn't been updated in 9
months. That's too "old". You'd think they were shopping for a gallon
of milk.
-Jim
--
https://mail.python.org/mailman/listinfo/python-list
Re: about main()
On 2018-07-06, Jim Lee wrote: > On 07/06/18 11:25, Grant Edwards wrote: >> On 2018-07-06, Jim Lee wrote: >> >>> Pedantics again. Didn't even get the point before tearing apart the >>> *analogy* rather than the *point itself*. >> Jim Lee, this is the Internet. >> >> Intenet, this is Jim Lee. >> >> :) > > You have an inaccurate anthropomorphic reference as well as a > spelling error. > > [insert long diatribe on how Python annotations are God's gift to mankind] > > There. Do I fit in now? Yes, brilliantly! -- Grant Edwards grant.b.edwardsYow! I'm having an at emotional outburst!! gmail.com -- https://mail.python.org/mailman/listinfo/python-list
Re: about main()
On 7/5/2018 9:40 PM, Jim Lee wrote:
On 07/05/18 18:25, Steven D'Aprano wrote:
On Thu, 05 Jul 2018 11:27:09 -0700, Jim Lee wrote:
Take a village of people. They live mostly on wild berries.
Because of course a community of people living on one food is so
realistic. Even the Eskimos and Inuit, living in some of the harshest
environments on earth, managed to have a relatively wide variety of foods
in their diet.
https://en.wikipedia.org/wiki/Inuit_cuisine
Pedantics again. Didn't even get the point before tearing apart the
*analogy* rather than the *point itself*.
The irony of both Steven's interruption and your reaction is that the
Inuit story somewhat supports your point:
"There has been a decline of hunting partially due to the fact that
young people lack the skills to survive off the land. "
-- because they are 'growing more accustomed to the Qallunaat ("white
people") food that they receive from the south.'
If 'white people' food stopped coming, they would starve where they are.
But change scenarios that assume that everything else remains the same
are flawed. Maintaining traditional skills comes up in every culture
that is changing, which now is most all. But the same dynamism tends to
generate new solutions where needed.
--
Terry Jan Reedy
--
https://mail.python.org/mailman/listinfo/python-list
Re: about main()
On 07/06/18 11:25, Grant Edwards wrote: On 2018-07-06, Jim Lee wrote: Pedantics again. Didn't even get the point before tearing apart the *analogy* rather than the *point itself*. Jim Lee, this is the Internet. Intenet, this is Jim Lee. :) You have an inaccurate anthropomorphic reference as well as a spelling error. [insert long diatribe on how Python annotations are God's gift to mankind] There. Do I fit in now? :) -- https://mail.python.org/mailman/listinfo/python-list
Re: about main()
On 2018-07-06, Jim Lee wrote: > > Pedantics again. Didn't even get the point before tearing apart the > *analogy* rather than the *point itself*. Jim Lee, this is the Internet. Intenet, this is Jim Lee. :) -- Grant Edwards grant.b.edwardsYow! I'm encased in the at lining of a pure pork gmail.comsausage!! -- https://mail.python.org/mailman/listinfo/python-list
Re: about main()
On 2018-07-06, Gene Heskett wrote: > In that case, I hate to say it, but your education is sorely lacking in > the fundamentals. Smelting for instance was discussed at length in the > high school physics books I was reading by the time I was in the 3rd > grade. Don't they teach anything in school anymore? Tanning leather for > instance involves a long soaking in strong tea, and doesn't name the > brand or genus of the tea, the important part was the tannic acid > content. IIRC, oack leaves/chips work well also. -- Grant Edwards grant.b.edwardsYow! I'm shaving!! at I'M SHAVING!! gmail.com -- https://mail.python.org/mailman/listinfo/python-list
Re: about main()
On 2018-07-05, Jim Lee wrote: > Take a village of people. They live mostly on wild berries. It's completely orthogonal to your point of course, but I thought villages happened precisely because people had stopped living off wild stuff and had adopted organized agriculture... -- Grant Edwards grant.b.edwardsYow! Are you still an at ALCOHOLIC? gmail.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Thread-safe way to add a key to a dict only if it isn't already there?
D.setdefault('c', None)
On Sat, Jul 7, 2018 at 2:49 AM Steven D'Aprano
wrote:
>
> I have a dict with string keys:
>
> D = {'a': None, 'b': None}
>
> (the values don't matter for this question) and I want to add a key but
> only if it isn't already there. If I do the obvious:
>
> if not 'c' in D:
> D['c'] = None
>
> there's a Time Of Check to Time Of Use bug where some other thread could
> conceivably insert 'c' into the dict between the check and the insertion.
>
> How do I do a thread-safe insertion if, and only if, the key isn't
> already there?
>
>
>
> Thanks in advance,
>
>
>
> --
> Steven D'Aprano
> "Ever since I learned about confirmation bias, I've been seeing
> it everywhere." -- Jon Ronson
>
> --
> https://mail.python.org/mailman/listinfo/python-list
--
INADA Naoki
--
https://mail.python.org/mailman/listinfo/python-list
Thread-safe way to add a key to a dict only if it isn't already there?
I have a dict with string keys:
D = {'a': None, 'b': None}
(the values don't matter for this question) and I want to add a key but
only if it isn't already there. If I do the obvious:
if not 'c' in D:
D['c'] = None
there's a Time Of Check to Time Of Use bug where some other thread could
conceivably insert 'c' into the dict between the check and the insertion.
How do I do a thread-safe insertion if, and only if, the key isn't
already there?
Thanks in advance,
--
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson
--
https://mail.python.org/mailman/listinfo/python-list
Re: testing code
On Friday, 6 July 2018 09:22:31 UTC+5:30, Chris Angelico wrote: > On Fri, Jul 6, 2018 at 12:56 PM, Sharan Basappa > wrote: > > Please let me know if the following understanding of mine is correct. > > I need to put the program code in a separate file and organize every > > executable code in some form of function. If any code exists outside of > > function then it is not executable by importing. > > > > Kinda. It's actually the other way around: if any code exists outside > of functions, it will be executed immediately when you import. So > you're correct in that it would be hard (maybe impossible) to > unit-test that; and yes, the normal way to do it is to put all your > important code into functions. > > ChrisA thanks a lot -- https://mail.python.org/mailman/listinfo/python-list
Re: testing code
On Friday, 6 July 2018 09:32:08 UTC+5:30, Cameron Simpson wrote: > On 05Jul2018 19:56, Sharan Basappa wrote: > >I have implemented my first program in python that uses ML to do some > >classification task. The whole code is in a single file currently. > >It contains executable code as well as functions. > > I presume when you write "executable code" you mean some kind of "main > program" > that just runs when you run the .py file? > > >At the end of the program, I have series of calls that is used to test my > >code. > >Now, I would like to re-structure this to separate test code from the > >program. > >As I have not done this in Python, I am a bit lost. > > > >Please let me know if the following understanding of mine is correct. > >I need to put the program code in a separate file and organize every > >executable code in some form of function. If any code exists outside of > >function then it is not executable by importing. > > This is not quite right. Because Python is a dynamic language, importing a > file > actually runs it. That is how the functions etc get defined. > > So what you need to do is arrange that your "series of calls that is used to > test my code" live in their own function, and that that function only gets > run > if the file is directly run. > > Fortunately, this is a very common, almost universal, requirement and there > is > a standard idom for arranging it. > > Support you have your code in the file "foo.py" (because I need a concrete > filename for the example). It might look like this at present: > > def func1(...): > > def func2(...): > > x = func1(...) > y = func2(...) > print(x + y) > > i.e. some function definitions and then you testing code. > > Now, you can write another file "foo_tests.py" which starts like this: > > import foo > ... run some tests of foo.func1, foo.func2 etc ... > > The issue is that as written, foo.py will run your test calls during the > import. Restructure foo.py like this: > > def main(): > x = func1(...) > y = func2(...) > print(x + y) > > def func1(...): > > def func2(...): > > if __name__ == '__main__': > main() > > This is very standard. When you run a python file directly the built in > __name__ variable contains the string "__main__". This tells you that you're > running it as a "main program" i.e. directly. > > If you import the file instead, as from your planned testing file, the > __name__ > variable will contain the string "foo" because that is the name of the module. > > So that "main" function and the "if" at the bottom is standard Python > boilerplate code for what you're trying to do. > > >Import this in my test program (file/module) and then initiate calls > >present > >in the program. > >If there is some simple example, it would help a lot. > > Now you can do this part. > > Cheers, > Cameron Simpson Cameron. thanks. this is much more easier than I thought. -- https://mail.python.org/mailman/listinfo/python-list
Django-hotsauce 0.9.5 (Realistic Scenario) and libschevo 4.0.2 are out!
Hi everyone, I'm really happy to announce the public release of Django-hotsauce 0.9.5 (Realistic Scenario) and libschevo 4.0.2 for Python! :-) Downloads: PyPi https://pypi.org/project/Django-hotsauce/ https://pypi.org/project/libschevo/ Master site https://www.isotopesoftware.ca/pub/django-hotsauce/django-hotsauce-0.9.5.tar.gz https://www.isotopesoftware.ca/pub/libschevo/libschevo-4.0.2.tar.gz Release notes: - Maintenance bugfixes (django-hotsauce) - Fixed several critical issues with transaction management and schema migration for the ZODB backend (libschevo) Have fun!! Etienne -- Etienne Robillard tkad...@yandex.com https://www.isotopesoftware.ca/ -- https://mail.python.org/mailman/listinfo/python-list
Re: about main()
On 05/07/2018 21:43, Jim Lee wrote: ... identifying the poisonous berries. I would respect your analogy more if every compiler used today were forty years old and not being developed by anyone other than its original creator(s). ChrisA It's not about compilers - it's about skills. As programming becomes more and more specialized, it becomes harder and harder to find programmers with a skill set broad enough to be adaptable to a different task. -Jim I suspect compiler writing is a task that an AI could be taught. The villagers will shout "hey siri I need a compiler" and one will be provided, of course by that time they will all have forgotten about eating berries in favour of soma or equivalent. -- Robin Becker -- https://mail.python.org/mailman/listinfo/python-list
Re: Looking for a recent quote about dynamic typing, possibly on this list
On Fri, 06 Jul 2018 14:02:28 +0100, Bart wrote: > On 06/07/2018 13:43, Steven D'Aprano wrote: >> I think it might have been on this list, or possibly one of >> Python-Ideas or Python-Dev. >> >> Somebody gave a quote about dynamic typing, along the lines of >> >> "Just because a language allows a lot of dynamic features, doesn't mean >> people's code uses a lot of dynamism." >> >> Does anyone remember this? My google-fu is failing me. > > Wasn't that you? No -- I have frequently expressed similar sentiments, but it wasn't mine. -- Steven D'Aprano "Ever since I learned about confirmation bias, I've been seeing it everywhere." -- Jon Ronson -- https://mail.python.org/mailman/listinfo/python-list
Re: Looking for a recent quote about dynamic typing, possibly on this list
On 06/07/2018 13:43, Steven D'Aprano wrote: I think it might have been on this list, or possibly one of Python-Ideas or Python-Dev. Somebody gave a quote about dynamic typing, along the lines of "Just because a language allows a lot of dynamic features, doesn't mean people's code uses a lot of dynamism." Does anyone remember this? My google-fu is failing me. Wasn't that you? As in this quote in the PEP 526 thread, 5th July 03:01 BST: > But we know (as so many people keep reminding us) that just because > Python is extremely dynamic, that doesn't necessarily mean that we use it > in extremely dynamic ways. Most of the time, say, 95% of the time, if x > is an int *here*, it is intended to *stay* an int all the way through the > lifetime of that variable. -- bart -- https://mail.python.org/mailman/listinfo/python-list
Looking for a recent quote about dynamic typing, possibly on this list
I think it might have been on this list, or possibly one of Python-Ideas or Python-Dev. Somebody gave a quote about dynamic typing, along the lines of "Just because a language allows a lot of dynamic features, doesn't mean people's code uses a lot of dynamism." Does anyone remember this? My google-fu is failing me. -- Steven D'Aprano "Ever since I learned about confirmation bias, I've been seeing it everywhere." -- Jon Ronson -- https://mail.python.org/mailman/listinfo/python-list
Re: Is there a nice way to switch between 2 different packages providing the same APIs?
On Friday, July 6, 2018 at 1:22:46 PM UTC+1, Bev in TX wrote:
> > On Jul 6, 2018, at 3:14 AM, Mark via Python-list
> > wrote:
> >
> > In the end I changed to a completely different approach.
> >
> > I now have two parallel directories, one with PySide-based code and the
> > other with auto-generated PyQt-based code. And I created a tiny script to
> > copy the PySide code to the PyQt directory & do the necessary changes. (I
> > can post the script if anyone's interested.)
>
> I am interested.
> >
> > This means that there are no import hacks and no (manual) duplication,
> > while still being easy to test using either binding library.
> > --
> > https://mail.python.org/mailman/listinfo/python-list
>
> Bev in TX
OK, here're the details. Note that the paths are hard-coded (but could easily
be configurable using argparse).
I assume: (1) the source dir is 'app'; (2) the dest dir is 'app-pyqt'; (3)
there is a file called app/Uniform.py with this content:
#!/usr/bin/env python3
# Uniform.py
import PySide2.QtCore
from PySide2.shiboken2 import isValid as isObjectAlive
VERSION_STR = (f'PySide2 {PySide2.__version__} / '
f'Qt {PySide2.QtCore.__version__}')
I then run pyside2pyqt.py in the dir *above* app and app-pyqt:
#!/usr/bin/env python3
import contextlib
import os
import shutil
SRC = 'app'
DST = 'app-pyqt'
UNIFORM_FILE = 'Uniform.py'
def main():
with contextlib.suppress(FileNotFoundError):
shutil.rmtree(DST)
shutil.copytree(SRC, DST, ignore=shutil.ignore_patterns(
'__pycache__', UNIFORM_FILE))
for root, _, files in os.walk(DST):
for name in files:
if name.endswith(('.py', '.pyw')):
filename = os.path.join(root, name)
with open(filename, 'rt', encoding='utf-8') as file:
text = file.read().replace('PySide2', 'PyQt5')
with open(filename, 'wt', encoding='utf-8') as file:
for line in text.splitlines():
if 'pyside2pyqt: DELETE' not in line:
print(line, file=file)
with open(os.path.join(DST, UNIFORM_FILE), 'wt',
encoding='utf-8') as file:
file.write(UNIFORM)
UNIFORM = '''#!/usr/bin/env python3
import PyQt5.QtCore
import PyQt5.sip
VERSION_STR = (f'PyQt5 {PyQt5.QtCore.PYQT_VERSION_STR} / '
f'Qt {PyQt5.QtCore.QT_VERSION_STR}')
def isObjectAlive(obj):
return not PyQt5.sip.isdeleted(obj)
'''
if __name__ == '__main__':
main()
The reaons for being able to delete lines is that the APIs aren't identical.
For example, PySide2's QStyleHints has a setCursorFlashTime() method; but
PyQt5's doesn't. So for any lines you don't want copied just add the comment,
e.g.:
style_hints = self.styleHints() # pyside2pyqt: DELETE
style_hints.setCursorFlashTime(0) # pyside2pyqt: DELETE
I'm sure someone could come up with a more generalized script, but this is
sufficient for my needs.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Is there a nice way to switch between 2 different packages providing the same APIs?
> On Jul 6, 2018, at 3:14 AM, Mark via Python-list > wrote: > > In the end I changed to a completely different approach. > > I now have two parallel directories, one with PySide-based code and the other > with auto-generated PyQt-based code. And I created a tiny script to copy the > PySide code to the PyQt directory & do the necessary changes. (I can post the > script if anyone's interested.) I am interested. > > This means that there are no import hacks and no (manual) duplication, while > still being easy to test using either binding library. > -- > https://mail.python.org/mailman/listinfo/python-list Bev in TX -- https://mail.python.org/mailman/listinfo/python-list
Re: about main()
On 06/07/18 07:04, Gregory Ewing wrote: Steven D'Aprano wrote: Even the Eskimos and Inuit, living in some of the harshest environments on earth, managed to have a relatively wide variety of foods in their diet. They might be living on a very wide variety of berries. Or perhaps, in their language, "berry" simply means "food". IIRC their language didn't have a word for "toothache" owing to their diet and the use of their teeth as tools. Or was that a precursor of fake news, an urban myth? -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: about main()
On 06/07/18 02:40, Jim Lee wrote: On 07/05/18 18:25, Steven D'Aprano wrote: On Thu, 05 Jul 2018 11:27:09 -0700, Jim Lee wrote: Take a village of people. They live mostly on wild berries. Because of course a community of people living on one food is so realistic. Even the Eskimos and Inuit, living in some of the harshest environments on earth, managed to have a relatively wide variety of foods in their diet. https://en.wikipedia.org/wiki/Inuit_cuisine Pedantics again. Didn't even get the point before tearing apart the *analogy* rather than the *point itself*. Childish. The rest was TL;DR. -Jim Welcome to an exclusive club, my dream team. Congratulations :) -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
PyDev 6.4.3 Released
*PyDev 6.4.3 Release Highlights* PyDev changes: - *Debugger* - Notification of threads is done as they're created instead of synchronized afterwards. - Support for using frame evaluation disabled by default as it made the debugger much slower on some cases. - Fixed case where breakpoint was missed if an exception was raised in a given line. - Properly break on unhandled exceptions on threads. - Add missing import which affected repl with IPython. - Fix for case where breakpoints could be missed. - Fixed issue tracing lamda functions. - pydevd.settrace() could end up not stopping the debugger properly. - Fixed critical error on debugger (could deadlock when creating a new thread). - *Code Formatter* - It's now possible to use the PyDev code formatter using the command line. - Install with: *pip install pydevf* - Fixes many common formatter errors. - Tries to keep code close to the original formatting. - see: https://github.com/fabioz/PyDev.Formatter for more details. - Fixed issue where blank line was being put in the wrong place in the PyDev code formatter. - Grammar: fixed issue parsing f-strings. - Fixed issue sending current line to interactive console (F2). About PyDev PyDev is an open-source Python IDE on top of Eclipse for Python, Jython and IronPython development, now also available for Python on Visual Studio Code. It comes with goodies such as code completion, syntax highlighting, syntax analysis, code analysis, refactor, debug, interactive console, etc. It is also available as a standalone through LiClipse with goodies such as multiple cursors, theming and support for many other languages, such as Django Templates, Jinja2, Html, JavaScript, etc. Links: PyDev: http://pydev.org PyDev Blog: http://pydev.blogspot.com PyDev on VSCode: http://pydev.org/vscode LiClipse: http://www.liclipse.com PyVmMonitor - Python Profiler: http://www.pyvmmonitor.com/ Cheers, Fabio Zadrozny -- https://mail.python.org/mailman/listinfo/python-list
Re: Is there a nice way to switch between 2 different packages providing the same APIs?
In the end I changed to a completely different approach. I now have two parallel directories, one with PySide-based code and the other with auto-generated PyQt-based code. And I created a tiny script to copy the PySide code to the PyQt directory & do the necessary changes. (I can post the script if anyone's interested.) This means that there are no import hacks and no (manual) duplication, while still being easy to test using either binding library. -- https://mail.python.org/mailman/listinfo/python-list
Re: Matplotlib 3D limitations, please recommend alternative
On Wednesday, July 4, 2018 at 6:38:18 PM UTC-7, William Ray Wing wrote: > > On Jul 4, 2018, at 5:53 PM, John Ladasky wrote: [snip] > > I explored Python OpenGL bindings about three years ago, and quickly got > > bogged down. Even with Python to assist, dealing with OpenGL was like > > trying to program Java. Of course, OpenGL can do EVERYTHING. Far more > > than I need. > > > > The Python Open GL bindings have apparently changed fairly dramatically. I’m > no expert, I’m working my way through the on-line book here: > > http://www.labri.fr/perso/nrougier/python-opengl/ > > But the author DOES lay things out in a nice step by step fashion - and with > particular emphasis on scientific 3D plotting (which is what I’m after). I've started to read your link. Maybe I will attempt OpenGL a second time. I found my posts documenting my request for help the last time that I attempted OpenGL here: https://groups.google.com/forum/#!msg/comp.lang.python/Hj-UHbAFpWs/7vz-vcSHCAAJ;context-place=forum/comp.lang.python Back then I wrote: "I have concluded that Qt, PyQt, and OpenGL are all rapidly-evolving, and huge, software packages. There may be compatibility problems, and relevant examples with the right software combination may be hard to find. Two weeks of searching web pages hasn't turned up a single example which demonstrates PyQt5 doing something simple in 3D with OpenGL that I can study." It's nice to see that Nicolas Rougier confirms exactly that very near the beginning of his book (Section 2.1, "A bit of history"). -- https://mail.python.org/mailman/listinfo/python-list
Re: Matplotlib 3D limitations, please recommend alternative
On Wednesday, July 4, 2018 at 3:30:32 PM UTC-7, Rick Johnson wrote: > On Wednesday, July 4, 2018 at 4:53:19 PM UTC-5, John Ladasky wrote: > > There are many 3D graphics packages on PyPI. Some appear to be quite > > specialized. I would appreciate your recommendations. Thanks! > > If you don't want to mess with pyOpenGL, then try VPython. Thanks for the suggestion Rick, I have found some VPython examples here: http://www.glowscript.org/#/user/GlowScriptDemos/folder/Examples/ -- https://mail.python.org/mailman/listinfo/python-list
Re: Is there a nice way to switch between 2 different packages providing the same APIs?
On 05-07-18 14:57, Mark Summerfield via Python-list wrote: > For GUI programming I often use Python bindings for Qt. > > There are two competing bindings, PySide and PyQt. > > Ideally I like to have applications that can use either. This way, if I get a > problem I can try with the other bindings: if I still get the problem, then > it is probably me; but if I don't it may be an issue with the bindings. > > But working with both means that my imports are very messy. Here's a tiny > example: > > if PYSIDE: # bool True -> Use PySide; False -> Use PyQt5 > from PySide2.QtCore import Qt > from PySide2.QtGui import QIcon > from PySide2.QtWidgets import ( > QDialog, QFrame, QGridLayout, QLabel, QLineEdit, QPushButton, > QVBoxLayout) > else: > from PyQt5.QtCore import Qt > from PyQt5.QtGui import QIcon > from PyQt5.QtWidgets import ( > QDialog, QFrame, QGridLayout, QLabel, QLineEdit, QPushButton, > QVBoxLayout) > > The PYSIDE constant is imported from another module and is used for all .py > files in a given project so that just by changing PYSIDE's value I can run an > entire application with PySide2 or with PyQt5. The following is untested but what about if PYSIDE: import PySide2 as PyQt else: import PyQt5 as PyQt Qt = PyQt.QtCore.Qt QIcon = PyQt.QtGui.QIcon ... -- Antoon Pardon -- https://mail.python.org/mailman/listinfo/python-list
Re: PEP 526 - var annotations and the spirit of python
On 06-07-18 08:17, Steven D'Aprano wrote: > On Thu, 05 Jul 2018 16:09:52 +0200, Antoon Pardon wrote: > >>> This is not an innovation of Mypy. It's how type inference is supposed >>> to work. If a particular type checker doesn't do that, it is doing it >>> wrong. >> That is how type interference works in languages that have some kind of >> static typing like Haskell. > No, that's how type inference works in dynamically typed languages like > Python as well. See Mypy for an example. Sorry, but this kind of wording is misleading to me. IMO, it strongly suggests that we can have type inference in python without losing any of the dynamism. The impression that I got from this thread was that you could just trow any python program through mypy and it would work. > But if you opt-in to using a type-checker, the assumption is that you are > writing in a less-dynamic, more-static style that will actually get some > advantage from static type checking. If you're not doing so, then you're > just annoying yourself and wasting time and you won't enjoy the > experience one bit. Thank you for this clarification. It seems that we are largely agreeing but I seem to have understood your past contributions differently than you intended. -- Antoon. -- https://mail.python.org/mailman/listinfo/python-list
Re: Dealing with dicts in doctest
05.07.18 20:57, Steven D'Aprano пише:
I think that's really clever. Is it too clever? How do you deal with
dicts in doctests?
There was a proposition for adding a doctest option for
order-insensitive matching (like NORMALIZE_WHITESPACE and ELLIPSIS). But
it was rejected because there is a simple alternative:
>>> func(1) == {'a': 1, 'b': 2, 'c': 3}
True
And since 3.7 the need of this feature was reduced.
--
https://mail.python.org/mailman/listinfo/python-list
