Re: Shoulid constants be introduced to Python?
On Thu, Nov 16, 2017 at 05:35:59PM -0500, ROGER GRAYDON CHRISTMAN wrote: > Well, pi already does have a value: > import math math.pi > > 3.141592653589793 > > but it's not a constant in the sense you are looking for: And, it's not really a constant at all, it's only got a constant definition :-) > The only PEP I saw that makes any mention of constants is the PEP 8 Style > Guide, > which recommends all constants be named with all caps, such as "math.PI". > (Why the math module doesn't do that beats me, unless it is there for > hyster^H^H^H^H^Historical reasons.) So, import math math.PI = math.pi seems helpful :) Karsten -- -- https://mail.python.org/mailman/listinfo/python-list
Re: Should constants be introduced to Python?
On 16/11/2017 06:16, Saeed Baig wrote: Hey guys I am thinking of perhaps writing a PEP to introduce constants to Python. Something along the lines of Swift’s “let” syntax (e.g. “let pi = 3.14”). Since I’m sort of new to this, I just wanted to ask: - Has a PEP for this already been written? If so, where can I find the link/info to it? - Do you guys think it would be a good idea? Why or why not? Do you think there’s a better way to do it? I’d like to know what others think about this idea before making any formal submission. I've taken part in a few discussions here on the subject. However, if you're going to write a PEP, does that require that you have some idea of how it would be implemented? For example, you write this: let A = 10 let B = 20 x = A + B On CPython, would the byte-code compiler reduce the A+B to 30, or would it still do the calculation? Suppose those lets were in an imported module M: import M x = M.A + M.B Would it reduce the expression here or not? (And if so, how? Remember that M itself is not constant, so M could have been reassigned as another module, or a class, so that another M.A is not a constant.) What would happen here: let A = 10 A = 12 Would the assignment be allowed or not? Because the way Python works now, is that EVERY (top-level) identifier created by the user is a variable, and can be assigned something else. To prohibit A=12 would mean creating a new category of identifier that is fixed. And the error would be hard to pick up at compile-time here: M.A = 12 As the category of M.A is not known to the byte-code compiler (also that M is not constant as I said). Note that names are created also with 'import', 'def' and 'class', and it might be desirable to have these constant too, for example: let def F(): -- bartc -- https://mail.python.org/mailman/listinfo/python-list
Re: "help( pi )"
On 17 November 2017 at 12:36, Stefan Ram wrote: > A web page says: > > “The argument to pydoc can be the name of a function, > module, or package, or a dotted reference to a class, > method, or function within a module or module in a package.” [...] > , but not for »pi«: > > from math import pi > help( pi ) math.pi is not "a class method, or function within a module or module in a package". It's a number. I can see why you would want to be able to do this, but technically the help function shows the object's docstring, and numbers don't have docstrings. Paul -- https://mail.python.org/mailman/listinfo/python-list
Re: Should constants be introduced to Python?
I'm against this because Python's strength is its simplicity. This doesn't actually simplify anything, but it does add a new language feature to understand. All the benefits of this can be achieved with linting. On Thu, Nov 16, 2017 at 1:16 AM, Saeed Baig wrote: > Hey guys I am thinking of perhaps writing a PEP to introduce constants to > Python. Something along the lines of Swift’s “let” syntax (e.g. “let pi = > 3.14”). > > Since I’m sort of new to this, I just wanted to ask: > - Has a PEP for this already been written? If so, where can I find the > link/info to it? > - Do you guys think it would be a good idea? Why or why not? Do you think > there’s a better way to do it? I’d like to know what others think about > this idea before making any formal submission. > -- > https://mail.python.org/mailman/listinfo/python-list > -- Marcin Tustin Tel: +1 917 553 3974 -- https://mail.python.org/mailman/listinfo/python-list
Re: "help( pi )"
Paul Moore : > numbers don't have docstrings. There's no reason they couldn't: >>> help(2) Help on built-in number 2 in module builtins: 2 2 -> int The natural number immediately succeeding 1 (qv). The number of hemispheres in a healthy mammal's brain. It might also be useful to define a __docstr__() method for cases where a static __doc__ string is unwieldy. Then, the class could construct the doc string for its objects. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Should constants be introduced to Python?
Marcin Tustin : > I'm against this because Python's strength is its simplicity. This > doesn't actually simplify anything, but it does add a new language > feature to understand. And there will be eternal debates on the correct use of the feature. One of the ugliest features of C is the "const" modifier. There's no way to use it correctly. Even the POSIX libraries and C standards abuse it. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Artificial creating of [Lists], is it possible? the best way...
On Fri, 17 Nov 2017 00:04:16 + in comp.lang.python, MRAB said: > On 2017-11-16 18:47, jakub.raj...@gmail.com wrote: > > Hello, im working on school project, its deck game Sorry! > > I need to create specific lists: > > My idea is about to using for > > For i in range (n): > > i=[] > > I know, that there is no possibility to make it from number, but > > i havent idea, how to reach my wants Li/L"i"/L(i), how to make > > possible for lists? > > > > > If you want multiple lists, make a list of lists: > > my_lists = [] > > for i in range(n): > my_lists.append([]) > > Then you can say my_lists[0], my_lists[1], etc. It'd be even shorter using a list comprehension: my_lists = [[] for i in range(n)] And _even shorter still_ just using the multiply operator: my_lists = [[]] * n -- https://mail.python.org/mailman/listinfo/python-list
Re: Artificial creating of [Lists], is it possible? the best way...
On Sat, Nov 18, 2017 at 2:29 AM, eth0 wrote: > On Fri, 17 Nov 2017 00:04:16 + in comp.lang.python, MRAB said: >> On 2017-11-16 18:47, jakub.raj...@gmail.com wrote: >> > Hello, im working on school project, its deck game Sorry! >> > I need to create specific lists: >> > My idea is about to using for >> > For i in range (n): >> > i=[] >> > I know, that there is no possibility to make it from number, but >> > i havent idea, how to reach my wants Li/L"i"/L(i), how to make >> > possible for lists? >> > >> > >> If you want multiple lists, make a list of lists: >> >> my_lists = [] >> >> for i in range(n): >> my_lists.append([]) >> >> Then you can say my_lists[0], my_lists[1], etc. > > It'd be even shorter using a list comprehension: > > my_lists = [[] for i in range(n)] > > And _even shorter still_ just using the multiply operator: > > my_lists = [[]] * n Those are semantically different though. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: "help( pi )"
On 17 November 2017 at 15:52, Marko Rauhamaa wrote: > Paul Moore : >> numbers don't have docstrings. > > There's no reason they couldn't: In the sense that the Python object model could be amended to attach docstrings to instances of classes like "int", and syntax could be added to the language to write those docstrings in your code, then yes, of course there's no reason they couldn't. I'd say "patches gratefully accepted" but actually I suspect "justifications for why the extra complexity is worth it, followed up with a patch, might just be accepted if the justification were *extremely* strong" is more accurate ;-) Paul -- https://mail.python.org/mailman/listinfo/python-list
Re: Artificial creating of [Lists], is it possible? the best way...
On 2017-11-17, eth0 wrote: > On Fri, 17 Nov 2017 00:04:16 + in comp.lang.python, MRAB said: >> On 2017-11-16 18:47, jakub.raj...@gmail.com wrote: >> > Hello, im working on school project, its deck game Sorry! >> > I need to create specific lists: >> > My idea is about to using for >> > For i in range (n): >> > i=[] >> > I know, that there is no possibility to make it from number, but >> > i havent idea, how to reach my wants Li/L"i"/L(i), how to make >> > possible for lists? >> > >> > >> If you want multiple lists, make a list of lists: >> >> my_lists = [] >> >> for i in range(n): >> my_lists.append([]) >> >> Then you can say my_lists[0], my_lists[1], etc. > > It'd be even shorter using a list comprehension: > > my_lists = [[] for i in range(n)] > > And _even shorter still_ just using the multiply operator: > > my_lists = [[]] * n $ python Python 2.7.14 (default, Nov 2 2017, 11:45:51) [GCC 5.4.0] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> x = [[] for i in 1,2,3,4] >>> x [[], [], [], []] >>> y = [[]] * 4 >>> y [[], [], [], []] >>> x[0].append(1) >>> y[0].append(1) >>> x [[1], [], [], []] >>> y [[1], [1], [1], [1]] -- Grant Edwards grant.b.edwardsYow! Do I have a lifestyle at yet? gmail.com -- https://mail.python.org/mailman/listinfo/python-list
Re: from xx import yy
On Thu, Nov 16, 2017 at 2:46 PM, Cameron Simpson wrote: > On 16Nov2017 09:42, bvdp wrote: > >> In my original case, I think (!!!), the problem was that I had a variable >> in mod1.py and when I did the "from mod1 import myvarible" all was fine. >> Python create a new local-to-the-module variable and initialized it to the >> value it was set to in mod1. And at this point all is well. But, when mod1 >> changed the value of myvariable the change didn't get passed to the other >> modules. Of course, the reason for my confusion is that I'm thinking that >> python is using pointers :) Opps. >> >> Maybe we need pointers in python . >> > > Thinking about this as pointers works pretty well. We call them references > in Python because they are not (or need not be) memory addresses and C > pointers are memory addresses. However the model is the same: an arrow from > a variable name pointing at the place a value (the object) is stored. > > Look: > > mod1.py: x = 1 > > making: > > mod1.x --> 1 > > Now consider: > > mod2.py: from mod1 import x > > Making: > > mod1.x --> 1 > ^ > mod2.x + > > both referring to the "1" object. > > Now: > mod2.py: x = 2 > > Making: > > mod1.x --> 1 > mod2.x --> 2 > > You see that mod1 is not adjusted. Versus: > > mod2.py: import mod1 > > Making: > > mod2.mod1 --> mod1, mod1.x --> 1 > > Then: > > mod2.py: mod1.x = 2 > > Making: > > mod2.mod1 --> mod1, mod1.x --> 2 > > Because you're adjusting the reference "mod1.x", _not_ the distinct > reference "mod2.x". > > Cheers, > Cameron Simpson (formerly c...@zip.com.au) > > Draw little boxes with arrows. It helps. - Michael J. Eager > Yes, your examples work perfectly. It's when one does an "from mod1 import var" that it doesn't. In mod1 set var to a value. Lets use 5. Now, in mod2 we do: from mod1 import var And, yes, var is equal to 5. But, to the folks like me who are not complete pythonistas, we'd think it worked and was wonderful. But, if we change the variable in mod1 whit a function in mod1, the value doesn't change in mod2. The problem is that from/import does not create var as a pointer, but as a new variable. -- Listen to my FREE CD at http://www.mellowood.ca/music/cedars Bob van der Poel ** Wynndel, British Columbia, CANADA ** EMAIL: b...@mellowood.ca WWW: http://www.mellowood.ca -- https://mail.python.org/mailman/listinfo/python-list
Re: Should constants be introduced to Python?
On 17/11/2017 15:14, Marcin Tustin wrote: I'm against this because Python's strength is its simplicity. If it was simple once, then it isn't any more. Perhaps you mean consistency, in having only one class of identifier which can always be assigned to. All the benefits of this can be achieved with linting. The significance of true constants can go beyond that, assuming the proposal is not merely for some 'write-protect' flag on an ordinary variable. Proper constants allow reduction of expressions using them at compile-time. They allow lightweight enums that do the same. They allow the possibility of an efficient 'switch' statement. And that's just for numeric constants. If applied also to constant defs, classes and imports, they introduce extra scope for compile-time optimising. -- bartc -- https://mail.python.org/mailman/listinfo/python-list
Re: Artificial creating of [Lists], is it possible? the best way...
On Thursday, November 16, 2017 at 12:48:05 PM UTC-6, Jakub Raj ok wrote: > Artificial creating of [Lists], is it possible? the best way... There is nothing "artificial" about creating any object. Much less python lists. And i believe the usage of such word in the title of this thread was unfortunate, as it injects superfluous distraction into our comprehension of your true _intentions_. So, if the suggestions offered so far are _truely_ what you wanted to do -- and i have not reason to believe they are _not_ -- then the process here can more accurately be described, in English, as "creating a list containing N number of empty sublists". Words matter! Anecdotal speaking... an oft-stated observation of politics is that "Elections have consequences". And in the same spirit we should also understand that "words _themselves_ have consequences". Or rather: "your _word_choice_ is highly essential to our correct and efficient comprehension of your _intent_". So, in conclusion... If you cannot describe the result you want to achieve in _words_, then show us the result in actual _code_. For instance, the following question would have been self- explanatory: "How do i create a list that looks like this -> [[],[],[]] It is always better to restrict your use of natural language words to only those you _fully_ understand, than to attempt to stretch the definition of those words until they wrap around a concept, for which the "conceptual relationship" may only be obvious to _you_. PS: If you think about it, everything we _do_ in the "programming realm" is artificial. AKA: "Abstract". And while the end result of our incessant "juggling of abstractions" (which are _themselves_ built upon multiple layers of other abstractions) will inevitably be the concrete action of elections moving through a conductor, we, as programmers, are unconcerned with such "mechanical minutiae", and are only interested in the _results_ these worker-bee elections can bring to us. We are the shrewd military strategists and unapologetic mercenaries who fight endless, abstract battles against a manevolent, three- headed monster which plauges all of mankind -- namely: "needs", "wants", and "desires --, and who manevolently unleashes its legions of incoragble gremlins and hordes of mindless creepy crawlies to seek-out, and utlimately infest, every system that man -- in his boneheaded hubris -- has ever struggled to dominate. -- https://mail.python.org/mailman/listinfo/python-list
Re: "help( pi )"
It *could* be made to work: import math class PI(float): __doc__ = "The circle constant (Note: tau is better :-)" math.pi = PI(math.pi) print(math.pi) help(math.pi) -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: "help( pi )"
On Sat, Nov 18, 2017 at 8:27 AM, Gregory Ewing wrote: > It *could* be made to work: > > import math > > class PI(float): > > __doc__ = "The circle constant (Note: tau is better :-)" > > math.pi = PI(math.pi) > > print(math.pi) > help(math.pi) How is THAT an improvement? Docstrings aren't supposed to give false information! *diving for cover* ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Should constants be introduced to Python?
Yes the same consideration applies to any new feature. I think that Python's reticence to add new features has been a strength. And I do think the benefit here is absolutely negligible. It's not that I don't like constants - but there's a bunch of things that go great together, like constants, functional programming, and static type analysis, and none of those are in python. There are plenty of languages that have that; and nothing that prevents you from creating a desugaring compiler for an extended version of python. Indeed, I think that a lot of features like annotations would be better in an extension project. Constants (from a code quality perspective) really manifest their benefits in statically preventing errors. A linter can warn about assignment to ALL_CAPS, ClassNames, and built-in names. If you're following appropriate conventions (and your linter isn't a pure peephole linter) you can identify those errors. On Fri, Nov 17, 2017 at 4:47 PM, Saeed Baig wrote: > Well I think that depends on how one defines simplicity. Which seems > simpler, this: > > # Treat as constants > c = 299792458 # Speed of light > e = 2.71828 # Euler’s constant > > or this: > let c = 299792458 # Speed of light > let e = 2.71828 # Euler’s constant > > The latter involves less typing, and is hardly more difficult to > understand. > > I can see where you’re coming from; it does arguably add complexity. But > one could argue that ANY new feature to the language (list comprehension, > lambdas, type hints, etc) will add complexity to the language just by > virtue of being an extra thing to learn. One has to consider the benefit VS > cost of a new feature by comparing “How useful is it” to “How complex is > it”. > > And forgive me for my ignorance on this topic, but how can linting give > the benefits of constants? > > On 18 Nov 2017, at 02:14, Marcin Tustin wrote: > > I'm against this because Python's strength is its simplicity. This doesn't > actually simplify anything, but it does add a new language feature to > understand. > > All the benefits of this can be achieved with linting. > > On Thu, Nov 16, 2017 at 1:16 AM, Saeed Baig > wrote: > >> Hey guys I am thinking of perhaps writing a PEP to introduce constants to >> Python. Something along the lines of Swift’s “let” syntax (e.g. “let pi = >> 3.14”). >> >> Since I’m sort of new to this, I just wanted to ask: >> - Has a PEP for this already been written? If so, where can I find the >> link/info to it? >> - Do you guys think it would be a good idea? Why or why not? Do you think >> there’s a better way to do it? I’d like to know what others think about >> this idea before making any formal submission. >> -- >> https://mail.python.org/mailman/listinfo/python-list >> > > > > -- > Marcin Tustin > Tel: +1 917 553 3974 <(917)%20553-3974> > > > -- Marcin Tustin Tel: +1 917 553 3974 -- https://mail.python.org/mailman/listinfo/python-list
Re: "help( pi )"
On 17Nov2017 11:09, Dennis Lee Bieber wrote: On 17 Nov 2017 12:36:37 GMT, r...@zedat.fu-berlin.de (Stefan Ram) declaimed “The argument to pydoc can be the name of a function, module, or package, or a dotted reference to a class, method, or function within a module or module in a package.” , but not for »pi«: math.pi is NOT a "function, module, or package..." Would you expect help(1) to produce something like "Multiplicative identity"? (or "Boolean truth" especially for older Python code before True/False became standard). Why should help(3.1415926536) #or whatever precision is used in module math produce anything? That IS what is seen by the help() operation, not the name "pi", just a number. And if help() somehow recognizes 3.1415926536 as pi, what does it do if provided with just 3.141592654 instead? This is not a consistent argument. mymath.py: def square(x): ''' Return the square of a value: its value muliplied by itself. ''' return x*x my code: from mymath import square def sq2(x): return x*x I expect help(square) to have doco and don't expect help(sq2) to have doco. Stefan's argument points to the deficiency that one cannot attach a docstring to things like numbers. I've certainly wanted to. I don't think he's arguing that help magicly recognises 3.1415926536 as "pi" and produces a docstring for it and all "sufficiently close" values. I'm not. But the math module has bound "pi" to a specific float. Why _can't_ we annotate that float with a docstring? math.py: pi = 3.1415926536 pi.__doc__ = 'The ratio of round things to straight things. Roughly 3.' Now, I accept that the "CPython coaleases some values to shared singletons" thing is an issue, but the language doesn't require it, and one could change implementations such that applying a docstring to an object _removed_ it from the magic-shared-singleton pool, avoiding conflicts with other uses of the same value by coincidence. Cheers, Cameron Simpson (formerly c...@zip.com.au) -- https://mail.python.org/mailman/listinfo/python-list
Re: "help( pi )"
On Sat, Nov 18, 2017 at 9:38 AM, Cameron Simpson wrote:
> I don't think he's arguing that help magicly recognises 3.1415926536 as "pi"
> and produces a docstring for it and all "sufficiently close" values. I'm
> not. But the math module has bound "pi" to a specific float. Why _can't_ we
> annotate that float with a docstring?
>
> math.py:
>pi = 3.1415926536
>pi.__doc__ = 'The ratio of round things to straight things. Roughly 3.'
>
> Now, I accept that the "CPython coaleases some values to shared singletons"
> thing is an issue, but the language doesn't require it, and one could change
> implementations such that applying a docstring to an object _removed_ it
> from the magic-shared-singleton pool, avoiding conflicts with other uses of
> the same value by coincidence.
>
Perhaps what we want is not so much "attach docstrings to floats" but
"get documentation for a module attribute, not for the object referred
to".
pi = 3.1415926536 # A yet-to-be-released version of TeX
help("math.pi")
==>
"""
math.pi [3.1415926536]
A yet-to-be-released version of TeX
"""
To make this work, the help() function would have to be given a
string, or else be some sort of magic UI feature rather than a plain
function. It'd then also need to get hold of either the source code or
the compiled math.pyc (but not the importable module) and somehow
locate the module attribute assignment operation. It wouldn't be
efficient, but it would be something that's only done when a human
specifically asks for it, so taking 50ms isn't going to mean much.
Possible? Yes. Practical? Not so sure.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: "help( pi )"
On Sat, Nov 18, 2017 at 09:50:29AM +1100, Chris Angelico wrote: > Perhaps what we want is not so much "attach docstrings to floats" but > "get documentation for a module attribute, not for the object referred > to". The reason this can't really work is that members are just variables with arbitrary values. It does not make sense for them to have doc strings. You *can* (and probably should!) document the members in the class' (or module's) doc string. That's really the only sensible place to do it. But remember that Python's idea of objects is more fluid than in other languages... You don't have constants, so you can arbitrarily change any object's member values to anything, even to the point of adding new ones at your whim. This probably would make more sense for constants, if Python had them. But you don't really need them, and there's no reason documenting the purpose of the members of a class or module in the parent object's doc string shouldn't be sufficient. -- https://mail.python.org/mailman/listinfo/python-list
ctypes help
Hello Pythonistas,
I'm starting to play with ctypes, as I'd like to provide Python
interfaces to a C/C++ library I have. For now I'm just messing with a
very simple piece of code to get things sorted out. I'm working with
this example C++ library, which just wraps a call to stat():
-=-=-=-=-=-=-
$ cat stat.cc
#include
#include
#include
extern "C" int my_stat(const char *path, struct stat *st)
{
return stat(path, st);
}
-=-=-=-=-=-=-
Then I compile this to a shared object with g++ -shared -fPIC in /tmp. My
attempt to wrap that looks as follows:
-=-=-=-=-=-=-
#!/usr/bin/python
import ctypes
libc = ctypes.CDLL("/tmp/my_stat.so")
stat = libc.my_stat
class Timespec(ctypes.Structure):
_fields_ = [("tv_sec", ctypes.c_longlong),
("tv_usec", ctypes.c_longlong)]
class Stat(ctypes.Structure):
_fields_ = [("st_dev", ctypes.c_ulong),
("st_ino", ctypes.c_ulong),
("st_mode", ctypes.c_ulong),
("st_nlink", ctypes.c_ulong),
("st_uid", ctypes.c_ulong),
("st_gid", ctypes.c_ulong),
("st_rdev", ctypes.c_ulong),
("st_size", ctypes.c_ulonglong),
("st_blksize", ctypes.c_ulonglong),
("st_blocks", ctypes.c_ulonglong),
("st_atim", Timespec),
("st_mtim", Timespec),
("st_ctim", Timespec)]
Stat_p = ctypes.POINTER(Stat)
stat.argtypes = [ctypes.c_char_p, Stat_p]
path = "/tmp"
c_path = ctypes.c_char_p(path)
st = Stat()
rc = stat(c_path, ctypes.byref(st))
print rc
print st.st_dev
print st.st_ino
print st.st_mode
print st.st_nlink
print st.st_uid
print st.st_gid
print st.st_size
print st.st_atim
print st.st_mtim
-=-=-=-=-=-=-
This crashes immediately on one system, actually does work as expected
on another, but crashes before exiting. Clearly I must be doing
something wrong, but what?
On the system I have handy at the moment, it does not print any output, and
backtrace looks like this:
$ ./my_ctypes.py
*** Error in `/usr/bin/python': corrupted size vs. prev_size:
0x027b8320 ***
=== Backtrace: =
/lib/x86_64-linux-gnu/libc.so.6(+0x777e5)[0x7f6444a907e5]
/lib/x86_64-linux-gnu/libc.so.6(+0x7e9dc)[0x7f6444a979dc]
/lib/x86_64-linux-gnu/libc.so.6(+0x81cde)[0x7f6444a9acde]
/lib/x86_64-linux-gnu/libc.so.6(__libc_malloc+0x54)[0x7f6444a9d184]
/lib/x86_64-linux-gnu/libc.so.6(_IO_file_doallocate+0x55)[0x7f6444a861d5]
/lib/x86_64-linux-gnu/libc.so.6(_IO_doallocbuf+0x34)[0x7f6444a94594]
/lib/x86_64-linux-gnu/libc.so.6(_IO_file_overflow+0x1c8)[0x7f6444a938f8]
/lib/x86_64-linux-gnu/libc.so.6(_IO_file_xsputn+0xad)[0x7f6444a9228d]
/lib/x86_64-linux-gnu/libc.so.6(_IO_vfprintf+0xc90)[0x7f6444a66e00]
/lib/x86_64-linux-gnu/libc.so.6(__fprintf_chk+0xf9)[0x7f6444b2fb89]
/usr/bin/python[0x53290c]
/usr/bin/python[0x511c1f]
/usr/bin/python(PyFile_WriteObject+0x533)[0x5116d3]
/usr/bin/python(PyEval_EvalFrameEx+0x3a8f)[0x4c7a8f]
/usr/bin/python(PyEval_EvalCodeEx+0x255)[0x4c2765]
/usr/bin/python(PyEval_EvalCode+0x19)[0x4c2509]
/usr/bin/python[0x4f1def]
/usr/bin/python(PyRun_FileExFlags+0x82)[0x4ec652]
/usr/bin/python(PyRun_SimpleFileExFlags+0x191)[0x4eae31]
/usr/bin/python(Py_Main+0x68a)[0x49e14a]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0)[0x7f6444a39830]
/usr/bin/python(_start+0x29)[0x49d9d9]
--
https://mail.python.org/mailman/listinfo/python-list
Re: "help( pi )"
On Sat, Nov 18, 2017 at 10:34 AM, Python wrote: > On Sat, Nov 18, 2017 at 09:50:29AM +1100, Chris Angelico wrote: >> Perhaps what we want is not so much "attach docstrings to floats" but >> "get documentation for a module attribute, not for the object referred >> to". > > The reason this can't really work is that members are just variables > with arbitrary values. It does not make sense for them to have doc > strings. Did you read my post? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: ctypes help
On Sat, Nov 18, 2017 at 9:11 AM, Python wrote: > Hello Pythonistas, > > I'm starting to play with ctypes, as I'd like to provide Python > interfaces to a C/C++ library I have. For now I'm just messing with a > very simple piece of code to get things sorted out. I'm working with > this example C++ library, which just wraps a call to stat(): I would recommend you look into Cython, which can help you write C code that links to Python without all the hassle of manually tracking refcounts etc. (I also recommend using Python 3 instead of Python 2, but that's a separate point.) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: "help( pi )"
On Sat, Nov 18, 2017 at 10:35 AM, Stefan Ram wrote:
> Dennis Lee Bieber writes:
>>should
>> help(3.1415926536) #or whatever precision is used in
>> module math
>>produce anything?
>
> That question made me try something else whose output
> surprises me:
>
> |Python 3.7.0 ...
> |>>> help( 'math.pi' )
> |Help on float in math object:
> |
> |math.pi = class float(object)
> | | math.pi(x=0, /)
> | |
> | | Convert a string or number to a floating point number, if possible.
> | |...
Yes, that's correct; it's critical for anything that's a keyword (eg
help("if")), but legal for others. And it can have the side-effect of
importing and caching a module.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: "help( pi )"
On Sat, Nov 18, 2017 at 10:47:55AM +1100, Chris Angelico wrote: > On Sat, Nov 18, 2017 at 10:34 AM, Python wrote: > > On Sat, Nov 18, 2017 at 09:50:29AM +1100, Chris Angelico wrote: > >> Perhaps what we want is not so much "attach docstrings to floats" but > >> "get documentation for a module attribute, not for the object referred > >> to". > > > > The reason this can't really work is that members are just variables > > with arbitrary values. It does not make sense for them to have doc > > strings. > > Did you read my post? Yes! Did you read mine? I tried to explain to you that what you're suggesting doesn't really fit Python's paradigm: Doc strings describe their owner class, not individual instances--the class' doc string is where the description of your class (or module--same thing) attributes should go. Of course, in most cases you can set the doc strings to whatever you want, but in doing so you wipe out the owner class' documentation. If others are using your code, they may not expect or want this, so that's mostly a bad idea. You need a new attribute to set the instance description, and you can in fact just add that yourself if you want to. Monkeypatch to your heart's content! In this paradigm, the class for pi in your example is float, i.e. a floating point number, where the doc string for that class would logically be "A floating point number"--but since this is obvious, there is no compelling reason to even have it. In fact, it DOES have it: >>> x = 1.3 >>> x.__doc__ 'float(x) -> floating point number\n\nConvert a string or number to a floating point number, if possible.' Fundamental types have read-only doc strings, because it's the only thing that makes sense. But know what? In fact, if you really want to, you *can* get your attrs to have descriptive doc strings... by defining your own class that inherits from float (or whatever): -=-=-=-=-=-=- $ cat pi.py #!/usr/bin/python class Pi(float): def __init__(self): self.__doc__ = "the constant pi" def __new__(cls, value = 3.1415927): return float.__new__(cls, 3.1415927) x = Pi() print x print x + 2 print x.__doc__ $ ./pi.py 3.1415927 5.1415927 the constant pi -=-=-=-=-=-=- But asking the standard modules to do this is mostly silly, because it doesn't fit the paradigm... It changes the purpose of the doc string, and obliterates the information it is INTENDED to convey. But since this is Python, you can still do it if you want to. -- https://mail.python.org/mailman/listinfo/python-list
Re: "help( pi )"
On Sat, Nov 18, 2017 at 2:12 PM, Python wrote: > On Sat, Nov 18, 2017 at 10:47:55AM +1100, Chris Angelico wrote: >> On Sat, Nov 18, 2017 at 10:34 AM, Python wrote: >> > On Sat, Nov 18, 2017 at 09:50:29AM +1100, Chris Angelico wrote: >> >> Perhaps what we want is not so much "attach docstrings to floats" but >> >> "get documentation for a module attribute, not for the object referred >> >> to". >> > >> > The reason this can't really work is that members are just variables >> > with arbitrary values. It does not make sense for them to have doc >> > strings. >> >> Did you read my post? > > Yes! Did you read mine? I tried to explain to you that what you're > suggesting doesn't really fit Python's paradigm: Doc strings describe > their owner class, not individual instances--the class' doc string is > where the description of your class (or module--same thing) attributes > should go. I gave a detailed example of something that was NOT a docstring. That was, in fact, the whole point of my post. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: ctypes help
On Sat, Nov 18, 2017 at 10:49:40AM +1100, Chris Angelico wrote: > On Sat, Nov 18, 2017 at 9:11 AM, Python wrote: > > Hello Pythonistas, > > > > I'm starting to play with ctypes, as I'd like to provide Python > > interfaces to a C/C++ library I have. For now I'm just messing with a > > very simple piece of code to get things sorted out. I'm working with > > this example C++ library, which just wraps a call to stat(): > > I would recommend you look into Cython, which can help you write C > code that links to Python without all the hassle of manually tracking > refcounts etc. (I also recommend using Python 3 instead of Python 2, > but that's a separate point.) Cython looks interesting, but none of your suggestions are options in my situation. -- https://mail.python.org/mailman/listinfo/python-list
Re: "help( pi )"
On Sat, Nov 18, 2017 at 02:19:25PM +1100, Chris Angelico wrote: > On Sat, Nov 18, 2017 at 2:12 PM, Python wrote: > > On Sat, Nov 18, 2017 at 10:47:55AM +1100, Chris Angelico wrote: > >> On Sat, Nov 18, 2017 at 10:34 AM, Python wrote: > >> > On Sat, Nov 18, 2017 at 09:50:29AM +1100, Chris Angelico wrote: > >> >> Perhaps what we want is not so much "attach docstrings to floats" but > >> >> "get documentation for a module attribute, not for the object referred > >> >> to". > >> > > >> > The reason this can't really work is that members are just variables > >> > with arbitrary values. It does not make sense for them to have doc > >> > strings. > >> > >> Did you read my post? > > > > Yes! Did you read mine? I tried to explain to you that what you're > > suggesting doesn't really fit Python's paradigm: Doc strings describe > > their owner class, not individual instances--the class' doc string is > > where the description of your class (or module--same thing) attributes > > should go. > > I gave a detailed example of something that was NOT a docstring. That > was, in fact, the whole point of my post. Ah... Sorry, I didn't find that to be clear from your post, even after rereading it... I took it to mean that *conceptually* it was different from a doc string, but still actually using the doc string via some magic, the description of which I honestly found kind of vague and hand-wavey, not so much detailed. And TBH I still do, even now that I have a better idea what you're talking about. ¯\_(ツ)_/¯ Apologies for my confusion. -- https://mail.python.org/mailman/listinfo/python-list
Re: "help( pi )"
On Sat, Nov 18, 2017 at 2:38 PM, Python wrote: > On Sat, Nov 18, 2017 at 02:19:25PM +1100, Chris Angelico wrote: >> On Sat, Nov 18, 2017 at 2:12 PM, Python wrote: >> > On Sat, Nov 18, 2017 at 10:47:55AM +1100, Chris Angelico wrote: >> >> On Sat, Nov 18, 2017 at 10:34 AM, Python wrote: >> >> > On Sat, Nov 18, 2017 at 09:50:29AM +1100, Chris Angelico wrote: >> >> >> Perhaps what we want is not so much "attach docstrings to floats" but >> >> >> "get documentation for a module attribute, not for the object referred >> >> >> to". >> >> > >> >> > The reason this can't really work is that members are just variables >> >> > with arbitrary values. It does not make sense for them to have doc >> >> > strings. >> >> >> >> Did you read my post? >> > >> > Yes! Did you read mine? I tried to explain to you that what you're >> > suggesting doesn't really fit Python's paradigm: Doc strings describe >> > their owner class, not individual instances--the class' doc string is >> > where the description of your class (or module--same thing) attributes >> > should go. >> >> I gave a detailed example of something that was NOT a docstring. That >> was, in fact, the whole point of my post. > > Ah... Sorry, I didn't find that to be clear from your post, even after > rereading it... I took it to mean that *conceptually* it was different > from a doc string, but still actually using the doc string via some > magic, the description of which I honestly found kind of vague and > hand-wavey, not so much detailed. And TBH I still do, even now that I > have a better idea what you're talking about. ¯\_(ツ)_/¯ Apologies > for my confusion. Ah. Yeah, the point was that the comment *was actually* the documentation. That's why that idea is unlikely to be practical - it involves reading the source. But it IS possible, without any compiler help. Apology accepted :) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
