Re: holding if/else condition in live bitcoin trading Python
On Tuesday, August 2, 2016 at 9:42:03 PM UTC+5:30, Steven D'Aprano wrote: > On Tue, 2 Aug 2016 07:14 pm, Arshpreet Singh wrote: > > > is there any approach I can go with so auto_order_buy() auto_order_sell() > > function only executed once? > > Take them out of the while loop. yes but Bitfinex is hacked, so no use now. -- https://mail.python.org/mailman/listinfo/python-list
Re: make an object read only
Robin Becker writes: > A reportlab user found he was doing the wrong thing by calling canvas.save > repeatedly, our documentation says you should not use Canvas objects after > the > save method has been used. The user had mixed results :( > > It would be better to make the canvas object completely immutable all the way > down when save has been called, but I think that's quite hard as these > objects > have quite a large and varied set of attributes, lists other objects > dictionaries etc etc. If changing things happen at an elementary level (by assigning to the object's instance attributes), then you could implement your on "__setattr__/__delattr__" methods. There, you could check whether you are ready to allow the change or reject it. -- https://mail.python.org/mailman/listinfo/python-list
Re: Why not allow empty code blocks?
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. So when putting scheme and python next to each other we should choose scheme for teaching and python for production. -- Antoon Pardon -- https://mail.python.org/mailman/listinfo/python-list
Re: gmane sending
On 03/08/2016 01:24, Ben Finney wrote: Terry Reedy writes: I am reading and sending via gmane right now. ... I also hope not. Hope doesn't fund important infrastructure like Gmane, though; and Lars clearly needs help if Gmane is to thrive https://lwn.net/Articles/695695/>. The signs are troubling: http://gmane.org/donate.php> has been timing out since that news :-( Frome various blogs etc etc I seem to hear he might keep the smtp nntp bridge going. FWIW my issue was python-list@python.org SMTP error from remote mail server after RCPT TO:: host mail.python.org [188.166.95.178]: 504-5.5.2 : Helo command rejected: need fully-qualified hostname this being sent by gmane -- Robin Becker -- https://mail.python.org/mailman/listinfo/python-list
Re: Tcl/Tk for Python 3.6.0a3 on Os X 10.9.5
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 -- https://mail.python.org/mailman/listinfo/python-list
Re: Tcl/Tk for Python 3.6.0a3 on Os X 10.9.5
On Wed, Aug 3, 2016 at 6:30 PM, Christian Gollwitzer wrote: > 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). Yay!! > 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. Ehh. Well, it's no worse than ECMAScript uses. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Why not allow empty code blocks?
On Wednesday, August 3, 2016 at 12:53:02 AM UTC+5:30, Paul Rubin wrote: > Steven D'Aprano writes: > > where power is defined (rather fuzzily) as the expressiveness > > of the language, how easy it is for the programmer to read, write and > > maintain code, how efficient/fast you can implement it, etc. > > Scheme guru Matthias Felleisen takes a stab at a precise definition here > (though it's pointy-headed theory that I don't understand that well): > > http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.51.4656 Lovely! Thanks for that! [Been preparing some notes/thoughts for a Theory of CS course — v drafty : https://bitbucket.org/rustom/toc/wiki/themes — and had listed this (topic) as one of the big open problems] > > > The Halting Problem is easily solved for Bloop languages: they always > > halt. > > If Bloop is powerful enough to "solve the halting problem" as you > describe, that gives it capabilities that Turing-complete languages > lack. (Of course it also loses some capabilities). Some of the > advantages of Turing-incomplete languages (plus why they are less > constraining than it might sound) are discussed here: > >http://www.jucs.org/doi?doi=10.3217/jucs-010-07-0751 And thanks for that as well I had seen that decades ago but forgot waht to look for -- https://mail.python.org/mailman/listinfo/python-list
Re: Debugging (was Re: Why not allow empty code blocks?)
On 03/08/2016 06:43, Steven D'Aprano wrote: Not everything that is done is worth the cognitive burden of memorising a special case. In some ways, Python is a more minimalist language than you like. That's okay, you're allowed to disagree with some design decisions. Well it's minimalist in some ways, and completely the opposite in others! It uses minimal basic syntax (missing a couple of loop forms, loop controls, switch/case, select-expressions... it's just a handful of features). But then you get to the standard library, and the plethora of different data types, methods and options. It's never-ending! So the idea that remembering 'repeat N' is a cognitive burden, and the myriad string operations for example are not, is ridiculous. (Especially when 'repeat N' will have an obvious counterpart in some other languages, but 'str.encode(...)' for example will not.) -- Bartc -- https://mail.python.org/mailman/listinfo/python-list
Re: usage of functools.partial in in parallelism
So yeah I wanted to remark that I actually identified more with the two questions raised after the 'stop the classes' talk, and I felt much like the two questions that raised after as per documenting design via use of classes in code (However I make sure to keep it all flattened as opposed to the lecturer first examples). I also think it's a matter of style and personal preference. The nodejs like-minded people would prolly lean more to the function based coupling using 'partial', while people like me would prefer classes as they'd think tasks in logical domain grouping, as I really love encapsulation. I am not left to wonder about difference in performance of functional vs. objectional python. -Sivan On Tue, Aug 2, 2016 at 7:14 AM, Steven D'Aprano < steve+comp.lang.pyt...@pearwood.info> wrote: > 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 > > -- > https://mail.python.org/mailman/listinfo/python-list > -- Sivan Greenberg Co founder & CTO Vitakka Consulting -- https://mail.python.org/mailman/listinfo/python-list
Re: Why not allow empty code blocks?
On Wednesday 03 August 2016 05:22, Paul Rubin wrote: >> The Halting Problem is easily solved for Bloop languages: they always >> halt. > > If Bloop is powerful enough to "solve the halting problem" as you > describe, that gives it capabilities that Turing-complete languages > lack. (Of course it also loses some capabilities). It only solves it in the sense that it isn't capable of looping forever, so there's never a question of whether or not a Bloop program will halt: they all do. It doesn't have any capabilities that Floop lacks: Floop can solve any problem that Bloop can solve, plus problems that Bloop cannot. In a sense, it's a less extreme version of this: Me: "I have here a computer which is immune to all computer viruses, malware and hostile code, now and in the future!" You: "That's great! Turn it on so we can see how it works." Me: "Oh, it doesn't turn on. There's no power supply. That was the only way I could guarantee it wouldn't execute malware: by making sure it couldn't execute *anything*." While I suppose it is true that a computer that doesn't run is still a computer, its an abuse of language to say that it has capabilities that running computers lack: - unhackable - immune to all viruses - unaffected by power surges - data storage is 100% reliable, never lose data again - instantaneous log-off and shutdown :-) Floop can certainly give a *partial* solution to the Halting Problem: - if the code is runnable using Bloop, then it definitely halts; - if the code is runnable using Floop, then ... maybe it halts? A sufficiently clever Floop program might be able to analyse Floop code and recognise many common cases of non-terminating loops. For example, the Floop equivalent of: while True: pass is clearly non-terminating. There's no mystery about being able to detect that. But not all code is that straight-forward. > Some of the > advantages of Turing-incomplete languages (plus why they are less > constraining than it might sound) are discussed here: > >http://www.jucs.org/doi?doi=10.3217/jucs-010-07-0751 > >> But as we've seen, syntax can make a HUGE difference to power in the >> sense of expressiveness, maintainability of code, readability, >> efficiency of the programmer, and even efficiency of the >> interpreter. Conway's Game of Life is Turing Complete. Would you >> rather use Python, or Game of Life? BrainF*ck or Javascript? > > That's completely different than Python vs Scheme, where you can > basically transliterate Python to Scheme by converting indentation > structure into parentheses and a few other things like that. I wouldn't say "completely different". Since GoL, Python, BrainF*uck and Javascript are all Turing Complete, there must be a way to convert a program in any one to any of the others. One obvious way to do this is to (for example) write a Javascript interpreter in BrainF*ck. That demonstrates that anything Javascript can do, BrainF*ck can do too. Of course, going the other way (BrainF*ck interpreter written in Javascript) is considerably easier :-) 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. It would be harder to translate (say) COBOL code to (say) Smalltalk. But it is always the case that any program for a Turing Complete language can be translated into a program for any other Turing Complete language. It might be *really really really difficult*, inefficient and slow, but its always possible. What's *not* possible is to take any Floop program and translate it into Bloop. There are things Floop can do that Bloop cannot -- Bloop is not Turing Complete, but Floop is. -- Steve -- https://mail.python.org/mailman/listinfo/python-list
Re: Why not allow empty code blocks?
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-example
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
--
https://mail.python.org/mailman/listinfo/python-list
Issue with ctypes and callback functions
Hi All, Is this a good place to ask questions about the above? Regards Bill. -- https://mail.python.org/mailman/listinfo/python-list
Re: Why not allow empty code blocks?
Rustom Mody : > So yes scheme are python have similar underbellies but the culture of > use is quite different. I don't know if there's enough Scheme activity out there to call it a culture. As far as underbellies go, Scheme macros and operators are not first-class. The Kernel programming language (http://klisp.org/>) addresses this flaw. > Note: You CAN use python scheme-ishly but few people do that. I don't know who or what you are referring to. About the only Schemey things not available to Python are tail recursion elimination and macros. From the little I have seen, Scheme programmers use tail recursion too little and macros too much. > So people can use python functionally but somehow have the idea that > imperative is easier/more natural/what-have-you In that regard, I don't see much difference in Scheme and Python practices. > Python has a rich COLLECTION of data structures > Scheme really has just one — S-exp Scheme has all kinds of data structures. > Then there are motley little things that make python > beginner-unfriendly. I can hardly imagine a programming language that would be better-suited for complete beginners. Scheme for beginning programmers could be like abstract algebra for kindergartners. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Issue with ctypes and callback functions
On Wed, Aug 3, 2016 at 9:38 AM, Bill Somerville wrote: > > Is this a good place to ask questions about the above? Discussing ctypes is fine here. There's also a ctypes-users list. -- https://mail.python.org/mailman/listinfo/python-list
Re: Why not allow empty code blocks?
On Wednesday, August 3, 2016 at 5:11:23 PM UTC+5:30, Steven D'Aprano wrote: > On Wednesday 03 August 2016 05:22, Paul Rubin wrote: > > >> The Halting Problem is easily solved for Bloop languages: they always > >> halt. > > > > If Bloop is powerful enough to "solve the halting problem" as you > > describe, that gives it capabilities that Turing-complete languages > > lack. (Of course it also loses some capabilities). > > It only solves it in the sense that it isn't capable of looping forever, so > there's never a question of whether or not a Bloop program will halt: they > all > do. It doesn't have any capabilities that Floop lacks: Floop can solve any > problem that Bloop can solve, plus problems that Bloop cannot. > > In a sense, it's a less extreme version of this: > > Me: "I have here a computer which is immune to all computer viruses, malware > and hostile code, now and in the future!" > > You: "That's great! Turn it on so we can see how it works." > > Me: "Oh, it doesn't turn on. There's no power supply. That was the only way I > could guarantee it wouldn't execute malware: by making sure it couldn't > execute > *anything*." > > While I suppose it is true that a computer that doesn't run is still a > computer, its an abuse of language to say that it has capabilities that > running > computers lack: > > - unhackable > - immune to all viruses > - unaffected by power surges > - data storage is 100% reliable, never lose data again > - instantaneous log-off and shutdown > > :-) 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 But correspondingly the functionality: The early landlines could just dial a NUMBER (which you looked up from a dead-tree book) The first cell phones had some rudimentary phone book Nowadays phones do everything a computer can… Including crash! -- https://mail.python.org/mailman/listinfo/python-list
Re: Why not allow empty code blocks?
On Wednesday, August 3, 2016 at 5:39:25 PM UTC+5:30, Marko Rauhamaa wrote: > Rustom Mody : > > So yes scheme are python have similar underbellies but the culture of > > use is quite different. > > I don't know if there's enough Scheme activity out there to call it a > culture. > > As far as underbellies go, Scheme macros and operators are not > first-class. The Kernel programming language (http://klisp.org/>) > addresses this flaw. > > > Note: You CAN use python scheme-ishly but few people do that. > > I don't know who or what you are referring to. I put it in the next line! > Scheme for beginning programmers could be like abstract algebra for > kindergartners. Maybe you are right — Anyhow MIT switching from scheme to python seems to think so. As I said earlier what they (the MIT profs) seem to be saying is that the topical relevance of python — a library for making robots — trumps scheme’s abstract beauty -- https://mail.python.org/mailman/listinfo/python-list
print() function with encoding= and errors= parameters?
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 -- https://mail.python.org/mailman/listinfo/python-list
Re: Why not allow empty code blocks?
On Wednesday, August 3, 2016 at 5:53:44 PM UTC+5:30, Rustom Mody wrote: > On Wednesday, August 3, 2016 at 5:39:25 PM UTC+5:30, Marko Rauhamaa wrote: > > Rustom Mody : > > I don't know who or what you are referring to. > > I put it in the next line! > > > Scheme for beginning programmers could be like abstract algebra for > > kindergartners. Funny keeps disappearing! One more try! 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-example -- https://mail.python.org/mailman/listinfo/python-list
Re: Why not allow empty code blocks?
Rustom Mody : > As I said earlier what they (the MIT profs) seem to be saying is that > the topical relevance of python — a library for making robots — trumps > scheme’s abstract beauty Python is an excellent choice. As far as abstract beauty is concerned, I'm wondering why Python abolished braces from statement syntax but not from expression syntax. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Why not allow empty code blocks?
On Wed, Aug 3, 2016 at 10:16 PM, Rustom Mody 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. Sorry matey, you just lost the strawman game. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Why not allow empty code blocks?
Rustom Mody : > 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-example I see nothing there that is not ordinary Python. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Why not allow empty code blocks?
On Wednesday, August 3, 2016 at 6:08:08 PM UTC+5:30, Marko Rauhamaa wrote: > Rustom Mody : > > > 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-example > > I see nothing there that is not ordinary Python. Its an example of python used functionally — normal python (3 I think) ie No loops, no prints (at least in early chapters Ive obviously not scoured the whole book) No assignment is harder, but you will see the assignment is more like a lisp-let; ie its a single assignment -- https://mail.python.org/mailman/listinfo/python-list
Re: Why not allow empty code blocks?
On 03/08/2016 13:36, Chris Angelico wrote: On Wed, Aug 3, 2016 at 10:16 PM, Rustom Mody 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 -- https://mail.python.org/mailman/listinfo/python-list
Re: Debugging (was Re: Why not allow empty code blocks?)
On Wed, Aug 3, 2016 at 8:16 PM, BartC wrote:
> On 03/08/2016 06:43, Steven D'Aprano wrote:
>
>> Not everything that is done is worth the cognitive burden of memorising a
>> special case.
>
>
>
>> In some ways, Python is a more minimalist language than you like. That's
>> okay,
>> you're allowed to disagree with some design decisions.
>
>
> Well it's minimalist in some ways, and completely the opposite in others!
>
> It uses minimal basic syntax (missing a couple of loop forms, loop controls,
> switch/case, select-expressions... it's just a handful of features).
>
> But then you get to the standard library, and the plethora of different data
> types, methods and options. It's never-ending!
The standard library doesn't have the cognitive burden that the core
language has. For starters, it's all namespaced; for seconds, once
you've mastered language syntax, you can introspect for documentation
(simplest form: help(obj) at the interactive prompt).
> So the idea that remembering 'repeat N' is a cognitive burden, and the
> myriad string operations for example are not, is ridiculous.
>
> (Especially when 'repeat N' will have an obvious counterpart in some other
> languages, but 'str.encode(...)' for example will not.)
Myriad string operations? Let's see.
>>> dir("")
['__add__', '__class__', '__contains__', '__delattr__', '__dir__',
'__doc__', '__eq__', '__format__', '__ge__', '__getattribute__',
'__getitem__', '__getnewargs__', '__gt__', '__hash__', '__init__',
'__init_subclass__', '__iter__', '__le__', '__len__', '__lt__',
'__mod__', '__mul__', '__ne__', '__new__', '__reduce__',
'__reduce_ex__', '__repr__', '__rmod__', '__rmul__', '__setattr__',
'__sizeof__', '__str__', '__subclasshook__', 'capitalize', 'casefold',
'center', 'count', 'encode', 'endswith', 'expandtabs', 'find',
'format', 'format_map', 'index', 'isalnum', 'isalpha', 'isdecimal',
'isdigit', 'isidentifier', 'islower', 'isnumeric', 'isprintable',
'isspace', 'istitle', 'isupper', 'join', 'ljust', 'lower', 'lstrip',
'maketrans', 'partition', 'replace', 'rfind', 'rindex', 'rjust',
'rpartition', 'rsplit', 'rstrip', 'split', 'splitlines', 'startswith',
'strip', 'swapcase', 'title', 'translate', 'upper', 'zfill']
We have:
* Dunder methods and attributes, used for implementing other features.
You ignore them in regular code.
* Methods that do what other languages do with stand-alone functions.
It's not much different to do "spam".capitalize() than
capitalize("spam") or "spam".replace("sp","h") than
replace("spam","sp","h"). Likewise the "is*" functions,
startswith/endswith, and other querying functions.
* String formatting (both format and format_map). That probably
belongs in the previous category, but since Python's .format() method
differs from every other string formatting out there, you could say it
takes extra cognitive load. But honestly, what modern language doesn't
have some sort of formatted-string system, at least in its standard
library?
* join(), which most languages have as an array method that takes a
string, but Python has as a string method that takes any iterable.
Yes, that's a bit weird, I know. We can give you that one.
* And, uhh... you specifically mentioned encoding strings to bytes.
Well, Pike doesn't have that as a method. Instead, you have
string_to_utf8() for the most common case (and, naturally,
utf8_to_string() to convert bytes to text), and then has a Charset
module for all other conversions. Cognitive burden? Pretty much
equivalent.
I would say str.encode() has barely more cognitive burden than repeat
N would have. To get your head around "repeat N", you have to
understand that a computer can do things more than once. To get your
head around "spam".encode("utf-8"), you have to understand that bytes
are a means of representing text, and that they're not the same thing.
Yes, that's a bit harder (if you teach algorithms using a pen and
paper, you'll probably conflate data with its representation, since
there's no representation of the representation), but not hugely.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: Why not allow empty code blocks?
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. -- Bartc -- https://mail.python.org/mailman/listinfo/python-list
Re: Why not allow empty code blocks?
On Wed, Aug 3, 2016 at 11:04 PM, BartC wrote: > On 03/08/2016 13:36, Chris Angelico wrote: >> >> On Wed, Aug 3, 2016 at 10:16 PM, Rustom Mody >> 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. Yes, I was talking about landlines. It did have a battery, and it did have a phone book. (And it did get lost, too, but that's because we had a lot of papers and stuff in that corner of the kitchen. We knew it was SOMEWHERE in the pile, but can you find it before the caller gives up?) And it actually suffered from lack of signal more often than you might think. We called them "outages", and they were the phone system's equivalent to power blackouts. Usually from the same cause, too - a car crashed into a pole somewhere and snapped the wires. The only issue I might have about this is whether it dated back to 1986. I asked my mother, and she couldn't remember quite when they came out. Certainly they were around in the early 1990s, and they weren't new then, so they can't be more than a couple years off the 30-years-ago estimate. Can you blame me if I take "30 years ago" and answer it from 28? :) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Why not allow empty code blocks?
On Wed, Aug 3, 2016 at 11:23 PM, BartC 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? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
RE: Issue with ctypes and callback functions
-Original Message-
From: eryk sun [mailto:eryk...@gmail.com]
Sent: 03 August 2016 13:16
To: python-list@python.org
Cc: Bill Somerville
Subject: Re: Issue with ctypes and callback functions
On Wed, Aug 3, 2016 at 9:38 AM, Bill Somerville
wrote:
>
> Is this a good place to ask questions about the above?
Discussing ctypes is fine here. There's also a ctypes-users list.
Thanks Eryk,
I am trying to handle Python callback functions in a SWIG interface, SWIG does
not support callbacks where the target is a Python callable but I can do this
with ctypes. My problem is that I need to have the callback receive a SWIG
wrapped type as an argument by reference. I see that if I use a
ctypes.Structure type then it works nicely but I have a huge and changing API
to wrap and do not want to manually describe every C struct with
ctypes.Structure when SWIG has already automatically created its own shadow
classes. The SWIG struct wrapper is just a class wrapping a pointer so can be
easily be passed just like ctypes.Structure can be. How do I tell ctypes that
it needs to reconstitute the type from an address in the callback thunk it
generates?
I have tried defining from_param() and self._as_parameter_ for the types which
works for passing to a function but I don't need that as SWIG does that
already. With callback arguments I get various errors depending on what
methods/attributes I supply like:
Parsing argument 0
TypeError: cannot build parameter
At the point where the callback is being called.
To summarize:
C API like:
typedef struct {
int member;
/* ... */
} my_type;
typedef int (*pfn) (my_type const *);
int fn (pfn);
Implementation could be:
#include "api.h"
int fn (pfn cb) {
my_type t = {42, /* ... */};
return cb (&t);
}
I want Python code like:
from ctypes import *
import api # SWIG extension module
def my_cb (t):
print ('in callback with:', t.member)
return 0
proto = CFUNCTYPE (c_int, my_type)
cb = proto (my_cb)
res = api.fn (cast (cb, c_void_p).value)
print ('fn returned:', res)
I can extend the SWIG shadow class to do the creation of the prototype and
thunk, the required cast above and any extra attributes or methods like
_as_parameter_ and from_param() but I can't see any way of having the Python
callback (my_cb) magically receive the SWIG wrapped 'my_type' struct.
TIA
Bill.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Why not allow empty code blocks?
"D'Arcy J.M. Cain" wrote: >On Mon, 01 Aug 2016 00:25:58 +1000 >Gordon Levi wrote: >> "D'Arcy J.M. Cain" 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. -- https://mail.python.org/mailman/listinfo/python-list
Re: Why not allow empty code blocks?
On 2016-08-03, Rustom Mody 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. -- Grant Edwards grant.b.edwardsYow! If I pull this SWITCH at I'll be RITA HAYWORTH!! gmail.comOr a SCIENTOLOGIST! -- https://mail.python.org/mailman/listinfo/python-list
Re: print() function with encoding= and errors= parameters?
On Wed, Aug 3, 2016, at 08:29, Malcolm Greene wrote: > 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? You could duplicate stdout [open(os.dup(sys.stdout.fileno()), ...)] You could make an IO class which sends bytes output to sys.stdout.buffer but won't close it when closed (you know, it'd be nice to be able to have "not owned underlying stream" as an option of the standard IO classes) If your output isn't going to be long, you could print everything to a StringIO and then write to sys.stdout.buffer at the end. -- https://mail.python.org/mailman/listinfo/python-list
Re: print() function with encoding= and errors= parameters?
Random832 wrote:
> On Wed, Aug 3, 2016, at 08:29, Malcolm Greene wrote:
>> 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?
Can you give an example of what you have in mind? One that would not be
considered a bug in said library?
> You could duplicate stdout [open(os.dup(sys.stdout.fileno()), ...)]
>
> You could make an IO class which sends bytes output to sys.stdout.buffer
> but won't close it when closed (you know, it'd be nice to be able to
> have "not owned underlying stream" as an option of the standard IO
> classes)
>
> If your output isn't going to be long, you could print everything to a
> StringIO and then write to sys.stdout.buffer at the end.
I'm unsure about this myself -- wouldn't it be better to detach the
underlying raw stream? Like
>>> import sys, io
>>> print("ähnlich üblich möglich")
ähnlich üblich möglich
>>> sys.stdout = io.TextIOWrapper(sys.stdout.detach(), encoding="ascii",
errors="xmlcharrefreplace")
>>> print("ähnlich üblich möglich")
ähnlich üblich möglich
The ValueError raised if you try to write to the original stdout
>>> print("ähnlich üblich möglich", file=sys.__stdout__)
Traceback (most recent call last):
File "", line 1, in
ValueError: underlying buffer has been detached
looks like a feature to me.
PS: An alternative would be to set the environment variable:
$ PYTHONIOENCODING=ascii:backslashreplace python3 -c 'print("Smørrebrød")'
Sm\xf8rrebr\xf8d
--
https://mail.python.org/mailman/listinfo/python-list
Re: print() function with encoding= and errors= parameters?
On Wed, Aug 3, 2016, at 11:09, Peter Otten wrote: > I'm unsure about this myself -- wouldn't it be better to detach the > underlying raw stream? Like Well, "better" depends on your point of view. > The ValueError raised if you try to write to the original stdout > looks like a feature to me. Maybe. But if the goal is to not cause problems for other code that consumes the original stdio, this is very much not a feature. Of course, it's hard to imagine in what kind of program design it is reasonable for there not to be a single guiding principle controlling all of the code that sends output to stdout, but I'm not the one asking the question here. -- https://mail.python.org/mailman/listinfo/python-list
Re: print() function with encoding= and errors= parameters?
Thank you Random832 and Peter - excellent ideas. My use case was diagnostic output being (temporarily) output to stdout via debug related print statements. The output is for debugging only and not meant for production. I was looking for a solution that would allow me to output to the console with as few changes to the original scripts as possible, eg. non-invasive except for the print statements themselves. When debugging under Linux/OSX, standard print statements work fine because their stdouts' encoding is UTF-8. But under Windows, the stdout is workstation specific and *never* UTF-8. So the occasional non-ASCII string trips up our diagnostic output when tested under Windows. Peter's suggestion to set the PYTHONIOENCODING [1] environment variable is the non-invasive, diagnostic only, non-production solution I was looking for ... for the use case at hand. Again, thank you both. Malcolm [1] PYTHONIOENCODING=ascii:backslashreplace -- https://mail.python.org/mailman/listinfo/python-list
Re: print() function with encoding= and errors= parameters?
On Thu, Aug 4, 2016 at 1:35 AM, Malcolm Greene wrote:
> My use case was diagnostic output being (temporarily) output to stdout
> via debug related print statements. The output is for debugging only and
> not meant for production. I was looking for a solution that would allow
> me to output to the console with as few changes to the original scripts
> as possible, eg. non-invasive except for the print statements
> themselves.
Don't forget that the print function can simply be shadowed. If you
have a lot of code that uses print(...) to output text, and you want
to quickly transform it so it uses ASCII + backslash-replace, you
could simply:
def print(msg):
sys.stdout.write(msg.encode("ASCII",
errors="backslashreplace").decode("ASCII") + "\n")
or whatever other transformation you want. Your current situation may
be solved, but this is a great tool in your toolbox, and worth bearing
in mind.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: print() function with encoding= and errors= parameters?
Chris, > Don't forget that the print function can simply be shadowed. I did forget! Another excellent option. Thank you! Malcolm -- https://mail.python.org/mailman/listinfo/python-list
Re: Why not allow empty code blocks?
On 03/08/2016 14:31, Chris Angelico wrote: On Wed, Aug 3, 2016 at 11:23 PM, BartC 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 -- https://mail.python.org/mailman/listinfo/python-list
Re: print() function with encoding= and errors= parameters?
On Wed, Aug 3, 2016 at 3:35 PM, Malcolm Greene wrote: > But under Windows, the stdout is workstation specific and *never* UTF-8. So > the > occasional non-ASCII string trips up our diagnostic output when tested under > Windows. You could use win_unicode_console enabled in sitecustomize or usercustomize. https://pypi.python.org/pypi/win_unicode_console -- https://mail.python.org/mailman/listinfo/python-list
Re: print() function with encoding= and errors= parameters?
> You could use win_unicode_console enabled in sitecustomize or usercustomize. > https://pypi.python.org/pypi/win_unicode_console The pypi link you shared has an excellent summary of the issues associated when working Unicode from the Windows terminal. Thank you Eryk. Malcolm -- https://mail.python.org/mailman/listinfo/python-list
Re: Why not allow empty code blocks?
On Thu, Aug 4, 2016 at 4:52 AM, BartC wrote: > On 03/08/2016 14:31, Chris Angelico wrote: >> >> On Wed, Aug 3, 2016 at 11:23 PM, BartC 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. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Why not allow empty code blocks?
On Wed, 03 Aug 2016 14:06:06 +, Grant Edwards wrote: > On 2016-08-03, Rustom Mody 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 -- https://mail.python.org/mailman/listinfo/python-list
Re: Why not allow empty code blocks?
On 03/08/2016 21:12, Chris Angelico wrote: On Thu, Aug 4, 2016 at 4:52 AM, BartC wrote: On 03/08/2016 14:31, Chris Angelico wrote: On Wed, Aug 3, 2016 at 11:23 PM, BartC 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 -- https://mail.python.org/mailman/listinfo/python-list
Re: Why not allow empty code blocks?
On Thu, Aug 4, 2016 at 6:53 AM, BartC 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. I've no idea how Jython does this; it appears that math.__file__ is AttributeError. Ditto PyPy. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Issue with ctypes and callback functions
On Wed, Aug 3, 2016 at 1:21 PM, Bill Somerville
wrote:
> I can extend the SWIG shadow class to do the creation of the prototype and
> thunk, the
> required cast above and any extra attributes or methods like _as_parameter_
> and
> from_param() but I can't see any way of having the Python callback (my_cb)
> magically
> receive the SWIG wrapped 'my_type' struct.
from_param is a hook method for a type that's set in a function
pointer's argtypes. It gets called to convert an argument when the
function pointer is called from Python. The return value can be a
ctypes instance, an object with a hard-coded conversion (e.g. a string
or integer), or an object that defines an _as_parameter_ attribute.
Only ctypes types are supported in callbacks, which unfortunately
isn't documented clearly. Specifically, the class dict needs to be an
extended C storage dict (i.e. StgDictObject), either to look up the
getfunc of a simple type or to ensure that instantiating a non-simple
type returns a ctypes instance (i.e. CDataObject) with a known size.
The relevant code in _CallPythonObject is as follows (when stripped of
declarations and error handling):
cnv = PySequence_GetItem(converters, i);
dict = PyType_stgdict(cnv);
if (dict && dict->getfunc && !_ctypes_simple_instance(cnv)) {
v = dict->getfunc(*pArgs, dict->size);
PyTuple_SET_ITEM(arglist, i, v);
} else if (dict) {
obj = (CDataObject *)PyObject_CallFunctionObjArgs(cnv, NULL);
memcpy(obj->b_ptr, *pArgs, dict->size);
PyTuple_SET_ITEM(arglist, i, (PyObject *)obj);
} else {
PyErr_SetString(PyExc_TypeError,
"cannot build parameter");
I don't have much experience with SWIG. Does it provide some means to
instantiate a wrapped type from an address? If it does, then you can
use a void pointer as the callback parameter.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Why not allow empty code blocks?
On 03/08/2016 22:39, Chris Angelico wrote: On Thu, Aug 4, 2016 at 6:53 AM, BartC 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 -- https://mail.python.org/mailman/listinfo/python-list
Re: Why not allow empty code blocks?
On Thu, Aug 4, 2016 at 8:21 AM, BartC wrote: > 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. Frankly, I don't want that. Most C APIs are horrendously unPythonic, so you'd need a wrapper anyway; plus, you shouldn't have to use C-like idioms except VERY rarely (eg pointers and stuff). You *can* use ctypes in CPython, but that's the failure mode for when you don't have any better option. The best option, for a DLL that doesn't already have any Python interface, is to write something in Cython. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Why not allow empty code blocks?
BartC writes: > 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. (require 'sys) -- https://mail.python.org/mailman/listinfo/python-list
Re: Why not allow empty code blocks?
On 04/08/2016 00:25, Paul Rubin wrote: BartC writes: 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. (require 'sys) What does that do? Don't tell me that every Lisp contains a full implementation of everything defined in Python's sys module! -- Bartc -- https://mail.python.org/mailman/listinfo/python-list
Re: Why not allow empty code blocks?
On 03/08/2016 23:31, Chris Angelico wrote: On Thu, Aug 4, 2016 at 8:21 AM, BartC wrote: 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. Frankly, I don't want that. Most C APIs are horrendously unPythonic, so you'd need a wrapper anyway; plus, you shouldn't have to use C-like idioms except VERY rarely (eg pointers and stuff). Yes, you'd need an ugly wrapper. But at least it would be in Python. As it is, you still need a wrapper, it's still ugly, and it's probably written in C and buried in CPython somewhere. -- Bartc -- https://mail.python.org/mailman/listinfo/python-list
Getting started with type-checking
Is there a good guide to getting started with type-checking Python code? Specifically as an aid to porting from Python 2 to 3. There are the PEPs, of course. Anything else? Apart from mypy, what type checkers are available? -- Steve “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
Re: ctypes Usage Note
On Tuesday, August 2, 2016 at 6:46:45 PM UTC+12, I wrote: > On Tuesday, August 2, 2016 at 5:18:14 PM UTC+12, eryk sun wrote: > >> I recommend using ctypes.CDLL instead. ctypes.cdll is pretty much >> pointless on Unix systems (and a potential problem on Windows due to >> cached function pointers). It also doesn't allow passing the mode, >> handle, and use_errno parameters. > > None of which I currently care about. Actually, thinking about it, there might be a point to specifying RTLD_GLOBAL. Which makes me wonder: why isn’t it the default? As for errno, that’s an egregious piece of POSIX brain damage. You’ll notice that just about nothing else uses it, apart from (the various implementations of) libc, which have to. -- https://mail.python.org/mailman/listinfo/python-list
Re: can't add variables to instances of built-in classes
On Thursday, July 21, 2016 at 2:29:53 PM UTC+12, Chris Angelico wrote: > Using __slots__ basically takes your object down to the level of a > Java one. Is Java like a bogeyman you use to scare people with if they don’t write Python code the way you like it? -- https://mail.python.org/mailman/listinfo/python-list
Re: can't add variables to instances of built-in classes
On Thu, Aug 4, 2016 at 12:34 PM, Lawrence D’Oliveiro wrote: > On Thursday, July 21, 2016 at 2:29:53 PM UTC+12, Chris Angelico wrote: > >> Using __slots__ basically takes your object down to the level of a >> Java one. > > Is Java like a bogeyman you use to scare people with if they don’t write > Python code the way you like it? LOL! Not really; it's just that Java's objects are way less featured than Python's. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Debugging (was Re: Why not allow empty code blocks?)
On Wed, 3 Aug 2016 08:16 pm, BartC wrote: > On 03/08/2016 06:43, Steven D'Aprano wrote: > >> Not everything that is done is worth the cognitive burden of memorising a >> special case. > > >> In some ways, Python is a more minimalist language than you like. That's >> okay, you're allowed to disagree with some design decisions. > > Well it's minimalist in some ways, and completely the opposite in others! > > It uses minimal basic syntax (missing a couple of loop forms, loop > controls, switch/case, select-expressions... it's just a handful of > features). > > But then you get to the standard library, and the plethora of different > data types, methods and options. It's never-ending! "Never-ending" is a bit of an exaggeration. You should check out the Java libraries, and how many different kinds of key:value mapping they provide. They make Python's collection of types look positively anaemic :-) In general, most types and operations in Python earned their place by proving their usefulness. They proved that they are useful, hard to program correctly, easy to get wrong, or some combination of all three. Many of them have gone through a gruelling process of discussion via a Python Enhancement Proposal (PEP) before being accepted. Having written two PEPs, I can tell you that in general the Python core developers attitude to adding new features, types or operations is to be very conservative and say No. Most suggestions get rejected even before that point. For instance, Guido used to reject the idea of having a ternary if operator for years. Python didn't need it, you can use an if...else statement, or when you need an if expression, use shortcut bool operators: result = condition and x or y gives x if condition is true and y if condition is false. At least, that's what Guido used to say... until he personally got bitten by a flaw in the argument. If x is a falsey argument, y is always returned. It took something in excess of 15 years before anyone publicly noticed this flaw, and when Guido did, Python pretty quickly got a ternary if operator. > So the idea that remembering 'repeat N' is a cognitive burden, and the > myriad string operations for example are not, is ridiculous. Who says it isn't a cognitive burden? Of course it is. The difference is that most of the string methods carry their own weight in usefulness versus burden, and "repeat N" doesn't (according to the core developers). You have weighed "repeat N" high on the usefulness side and low on the burden side, and Guido has done the opposite. This is, of course, a subjective argument. I'm not trying to convince you that you're wrong and Python is right. I completely accept that different people have different opinions on the usefulness versus burden of adding a specific feature. (That's why we have different languages, and some people like Perl where there are a million ways to do everything and some people don't.) I'm just trying to get you to understand where Python is coming from, not necessary to agree with every one of its design decisions, but to understand why they are the way they are. Its trivial to perform "repeat N" using the standard "for x in ..." syntax and built-in range() function, so including a dedicated "repeat N" syntax doesn't add much to the language. It's a trivial operation easily performed using a for loop. So the benefit is small. The cost is also small, but greater than the benefit: there's a new keyword, which means any code using "repeat" as a variable, function or method will break. Its more code in the compiler (even if it's only an extra ten bytes, that's still more). It's another feature that needs to be documented and tested. It's another decision for users to make, "should I use repeat N, or a for loop?", and another feature beginners to learn. Individually these costs are small, but they aren't *zero*. Collectively, according to the judgement of the people making the decision, they add up to more cost than the minimal benefit that "repeat N" would bring. But to take your example of str.encode... if Python didn't provide it, it would be a dozen kinds of a pain in the arse to provide it yourself. Especially with any sort of efficiency. Not to mention actually coming up with the encodings themselves. There are *dozens* of them. Adding one more string method "encode" to the dozens already there is not much of an additional burden. It doesn't stop people from using "encode" as a function name or variable, since the encode method is isolated to the str namespace. It provides a very important function, one which is critical in the post-ASCII world, and it is too difficult to expect users to implement their own. So the benefit is much greater than the cost. On the other hand, there's also str.swapcase(), which only remains due to a combination of nostalgia and backwards compatibility. Occasionally people, including Guido, suggest removing it: its pretty much useless, and hardly anyone uses it. It
