🌐 Mailman 3 August 2016 - Python-list - python.org

Re: Why not allow empty code blocks?
by BartC Aug. 3, 2016

Aug. 3, 2016

On 03/08/2016 22:39, Chris Angelico wrote: > On Thu, Aug 4, 2016 at 6:53 AM, BartC <bc(a)freeuk.com> wrote: >> On 03/08/2016 21:12, Chris Angelico wrote: >>> >>> Fairly common approach - and it means you'll never find those .py >>> files. So it's no different from looking for sys.py and not finding >>> it, except that in the case of CPython's sys, it's not even a DLL - >>> it's part of the interpreter core. >> >> >> I don't understand. With direct access to msvcrt.dll, the interface to that >> will be inside a .py file. Not buried away somewhere else. > > Oh. CPython takes a much simpler approach: instead of forcing a Python > module to "think like C", it allows a C module to export functions to > Python. So when you "import math", you actually get something from a > .so/.dll file. But is this a generic mechanism that works for /any/ .dll file, or does there have to be dedicated support for each of the 60 built-in modules? I'm talking about the former. Then something like a file library can be written in 100% Python, built around calls to msvcrt.dll for example. Since such libraries usually come with the OS, anyone investigating how a library works will see only Python, until it gets to the foreign functions, which have their own well-documented interface. You don't just hit a brick wall and be forced to delve into the innards of CPython, which should be concerning itself with implementing the language not providing libraries too. -- Bartc

2 1

Re: Why not allow empty code blocks?
by BartC Aug. 3, 2016

Aug. 3, 2016

On 03/08/2016 21:12, Chris Angelico wrote: > On Thu, Aug 4, 2016 at 4:52 AM, BartC <bc(a)freeuk.com> wrote: >> On 03/08/2016 14:31, Chris Angelico wrote: >>> >>> On Wed, Aug 3, 2016 at 11:23 PM, BartC <bc(a)freeuk.com> wrote: >>>> >>>> On 03/08/2016 09:58, Steven D'Aprano wrote: >>>> >>>> But sometimes you try to find a .py import module and it doesn't seem to >>>> exist anywhere. (sys.py for example). >>> >>> Ultimately, you _cannot_ implement everything in Python, unless you >>> create some sort of crazy fudge like having function pointers with >>> real language support, in which case you're writing C code. Some >>> modules have to be implemented in the host language (C for CPython, >>> Java for Jython, etc), in order to provide lower-level functionality. >> >> The approach I use is to provide direct access, from the language, to >> external .dll or .so files. >> >> Then it is possible, with a suitable interface *written in the byte-code >> language*, to directly call C's fopen() for example. > > Fairly common approach - and it means you'll never find those .py > files. So it's no different from looking for sys.py and not finding > it, except that in the case of CPython's sys, it's not even a DLL - > it's part of the interpreter core. I don't understand. With direct access to msvcrt.dll, the interface to that will be inside a .py file. Not buried away somewhere else. -- Bartc

2 1

Re: Why not allow empty code blocks?
by alister Aug. 3, 2016

Aug. 3, 2016

On Wed, 03 Aug 2016 14:06:06 +0000, Grant Edwards wrote: > On 2016-08-03, Rustom Mody <rustompmody(a)gmail.com> wrote: > >> The first nokia I used never crashed but could still run out of battery >> And the round-dial landlines of 30 years ago had not even that problem > > Yes, technically, it did. Except the batteries were kept elsewhere, > and the telco went to a lot of trouble to make sure they never went > dead. but the equipment at the exchange could miss a pulse & connect you to an incorrect number - equivalent of a bug? before that, you had to ask the nice young lady at the local exchange to physically patch you in to the correct circuit (& she could make an error as well) the "original" phones had no such problem as they ware simply a direct point to point connection (Bells first call is documented "come here Watson I need you" although no-one* remembers what Elisha Grey said or to whom). *ok I suppose someone might but it is not common knowledge (& I bet we still get some pedant disputing this ;-) ) -- Imagination is more important than knowledge. -- Albert Einstein

1 0

Re: Why not allow empty code blocks?
by BartC Aug. 3, 2016

Aug. 3, 2016

On 03/08/2016 14:31, Chris Angelico wrote: > On Wed, Aug 3, 2016 at 11:23 PM, BartC <bc(a)freeuk.com> wrote: >> On 03/08/2016 09:58, Steven D'Aprano wrote: >> >>> Python is sometimes described as a Lisp with more sensible syntax, so its >>> not >>> surprising that it is relatively simple to translate Python to Lisp and >>> visa >>> versa. >> >> >> Translating Python would be easier if everything was implemented as Python. >> But sometimes you try to find a .py import module and it doesn't seem to >> exist anywhere. (sys.py for example). >> >> I would like to see how such references are translated to Lisp. > > Ultimately, you _cannot_ implement everything in Python, unless you > create some sort of crazy fudge like having function pointers with > real language support, in which case you're writing C code. Some > modules have to be implemented in the host language (C for CPython, > Java for Jython, etc), in order to provide lower-level functionality. > You probably *could* implement the whole math module in pure Python, > but you don't want to; and cryptography, likewise, you theoretically > could implement in pure Python, and you'd get the same return value, > but you risk opening yourself up to timing-based attacks. > > How, from Lisp, would you call on OpenSSL or another lower-level > library? Or do you have to reimplement everything? What about simple > things like opening files, how do you do that without native code? The approach I use is to provide direct access, from the language, to external .dll or .so files. Then it is possible, with a suitable interface *written in the byte-code language*, to directly call C's fopen() for example. I believe Python also has a means of directly calling DLLs, so that in theory its file system can be build on top of the C runtime (msvcrt.dll or Linux' equivalent). There still needs to be some magic support for this mechanism, but more can be written in Python. -- Bartc

2 1

print() function with encoding= and errors= parameters?
by Malcolm Greene Aug. 3, 2016

Aug. 3, 2016

Looking for a way to use the Python 3 print() function with encoding and errors parameters. Are there any concerns with closing and re-opening sys.stdout so sys.stdout has a specific encoding and errors behavior? Would this break other standard libraries that depend on sys.stdout being configured a specific way? Thank you, Malcolm

5 8

Re: Why not allow empty code blocks?
by Gordon Levi Aug. 3, 2016

Aug. 3, 2016

"D'Arcy J.M. Cain" <darcy(a)Vex.Net> wrote: >On Mon, 01 Aug 2016 00:25:58 +1000 >Gordon Levi <gordon(a)address.invalid> wrote: >> "D'Arcy J.M. Cain" <darcy(a)Vex.Net> wrote: >> >I don't care if you are using carrier pigeon. If you send an email >> >address, make it a valid one. >> >> I admire those who use a valid email address on Usenet but it is an >> open invitation for spammers. I doubt if there is anybody who uses >> their primary email address. > >I never said that he had to use his primary address, just a valid one. > >On the other hand I have no throwaway accounts. Every address I use is >a primary one. I have all sorts of methods to block spam. None of >those methods involves moving my spam problem to someone else. How do you manage to avoid the resources wasted on multiple mail servers in order for the spam to each you just so that you can block it? > >But what do I know? I'm just some old fart who grew up being taught >that society works best when you consider the other guy and take >responsibility for your own messes. Old fashioned ideas I know. Nearly twenty years ago The Internet Engineering Task Force produced RFC2606 so that I could consider the other guy and use .invalid as a TLD. It makes a false email address instantly recognisable. If it is not recognised by a person it will be recognised and bounced by a nearby mail server using minimum computer resources.

1 0

Re: Why not allow empty code blocks?
by BartC Aug. 3, 2016

Aug. 3, 2016

On 03/08/2016 13:36, Chris Angelico wrote: > On Wed, Aug 3, 2016 at 10:16 PM, Rustom Mody <rustompmody(a)gmail.com> wrote: >> There he comes waddling in… Your cute-n-cudly strawman!! >> A more realistic analogy would be phones >> The cellphones we use today often crash >> The first nokia I used never crashed but could still run out of battery >> And the round-dial landlines of 30 years ago had not even that problem > > 1986? Yeah, we had a phone from then (granted, I don't remember much > of 1986, but we had the same handsets in the 1990s), and it could run > out of battery and lose its phone book. He said landlines. A typical handset would have no battery as it's powered from the line. And does not have need a memory to function. Nor would it suffer from lack of signal. Or credit (if you'd paid the last bill). Or get lost (as it's tethered to the socket). Very clunky technology but it was solid! It only did one thing but it did it incredibly well. -- Bartc

2 1

Re: Why not allow empty code blocks?
by Rustom Mody Aug. 3, 2016

Aug. 3, 2016

On Wednesday, August 3, 2016 at 1:57:43 PM UTC+5:30, Antoon Pardon wrote: > Op 02-08-16 om 14:29 schreef Rustom Mody: > > So I was talking of 3 very different levels: > > > > 1. print x vs print(x) > > — a difference too petty for me to waste my time with > > > > 2. Procedure vs Function as something very necessary for beginner > > thinking-ontology which Pascal gets right > > > > 3. The fact that the gap between a mainly-for-teaching language and a serious > > software-engineering-real-world language is not closable > > And that saying that the same language could be used for both purposes is > > like arguing that both these delightful ladies are pianists: > > > > > > Martha: https://www.youtube.com/watch?v=YLZLp6AcAi4 > > Rose : https://www.youtube.com/watch?v=_bjKDJD-CLc > > > > > > Scheme and Pascal happen to be two well-known well-crafted but quite different > > for-teaching languages > > But on what ground is scheme a well-crafted for-teaching language? > > It is not because it gets the Procedure vs Function ontology right. > > As far as I know scheme has about the same data structures as python, > they are just called differently and there are some limitations. Technically you are right But “technically” is not the most important facet. So yes scheme are python have similar underbellies but the culture of use is quite different. eg The very first example in the python tutorial uses a print statement/expr. Whereas in scheme you can go through much of the text(s) before you see the same Note: You CAN use python scheme-ishly but few people do that. eg here is SICP in python with the first examples pure useful powerful functions: http://www-inst.eecs.berkeley.edu/~cs61a/sp12/book/functions.html#first-exa… So people can use python functionally but somehow have the idea that imperative is easier/more natural/what-have-you Scheme and python data structures: Python has a rich COLLECTION of data structures Scheme really has just one — S-exp Software-engineering-wise this conduces to power in python and headache/nuisance in scheme But for a learner its the opposite: You do say dir([]) or dir({}) and you get a whole truckload of methods — how many to learn?? With scheme you chew up car/cdr/cons until you reach an epiphany of understanding vide Bruce Lee's quote: I am not afraid of the man who has practised ten thousand kicks. I am afraid of the man who has practised one kick ten thousand times Then there are motley little things that make python beginner-unfriendly. Noob makes a file whose name masks a builtin module and random things stop working. Umpteen such examples keep appearing out here. All point to one direction: Guido wants his language to be lightweight and for serious software engineering. Sure the ‘lightweight’ conduces to a neater language for teaching than say C++, Java etc. But the teaching/learning is not the primary goal, its software engineering. This can be seen in many sundry choices Backward compatibility: Guido is chary about introducing new keywords since code that currently uses that will break unexpectedly. And so we get new features that are seemingly clever but actually rather infelicitous; eg - conditional expression with wrong order of arguments - def overloaded for (ordinary) function and generator - yield overloaded for coroutine and generator For a beginner backward compatibility is a meaningless requirement: If python-2016 is inconsistently different from python-2015 who is affected since the bunch of learners has moved on. [Hapless teacher excepted!] Scheme — especially Dr. Scheme/racket — embraces inconsistency by offering different ‘teachpacks’ — different language syntaxes/semantics' for learners at different levels Likewise platform independence: One important goal of (core) python is that unless you go out of your way to be troublesome, a python program (script) on linux will run on windows and vice- versa (eg. universal newlines) This is of course good The flip-side is that important functionality that cant be easily supported — eg GUIs — get relegated to ‘advanced’ topics which is a euphemism for get neglected [As a thought experiment: If we started by teaching VB would GUIs look as advanced as they do in python?] Once again like backward compatibility, platform independence is meaningless to a beginner: For the one system that (s)he uses/owns it works or doesn’t work. That it may or may not work for other invisible, unimaginable systems is wildly over-the-top philosophy. OTOH racket (scheme) comes with fairly comprehensive GUI/graphics functionality [not tried myself] I expect 1. Its not really in the professional league of Qt or Wx but its enough for a beginner to have a comprehensive experience 2. An experience which is likely perceived as easier than struggling with PyQt wxPython etc

2 6

Re: usage of functools.partial in in parallelism
by Steven D'Aprano Aug. 3, 2016

Aug. 3, 2016

On Tuesday 02 August 2016 13:14, Michael Torrie wrote: > On 08/01/2016 01:13 AM, Michael Selik wrote: >> You might benefit from watching the talk "Stop Writing Classes" >> https://www.youtube.com/watch?v=o9pEzgHorH0 > > Great talk! Thanks for posting that. It is a great talk, but for a counter-view: http://lucumr.pocoo.org/2013/2/13/moar-classes/ Remember: moderation in all things, except for moderation. -- Steve

2 1

Re: Tcl/Tk for Python 3.6.0a3 on Os X 10.9.5
by Christian Gollwitzer Aug. 3, 2016

Aug. 3, 2016

Am 02.08.16 um 22:10 schrieb Ned Deily: > "For the initial alpha releases of Python 3.6, the installer is linked > with Tcl/Tk 8.5; this will change prior to the beta releases of 3.6.0." Let me also convey some insider information from the Tcl world: the upcoming 8.7 (I'll expect it next year) will have full Unicode support (>BMP). Because of compatibility issues with the C API, this will be done in the way that Tcl unicode strings are considered UTF-16 instead of UCS-2. So adapting Tkinter should be relatively easy in the end, if it passes UTF-8 strings, then there is zero change, if it passes Tcl_UniChar, then these must be convrted to UTF-16. Christian

2 1