[Python-Dev] Heap allocate type structs in native extension modules?
I have a Python program which generates the boilerplate code for native extension modules from a Python source definition. (http://bitbucket.org/hugh_fisher/fullofeels if interested.) The examples in the Python doco and the "Python Essential Reference" book all use a statically declared PyTypeObject struct and PyType_Ready in the module init func, so I'm doing the same. Then Python 3.5 added a check for statically allocated types inheriting from heap types, which broke a couple of my classes. And now I'm trying to add a __dict__ to native classes so end users can add their own attributes, and this is turning out to be painful with static PyTypeObject structs Would it be better to use dynamically allocated type structs in native modules? -- cheers, Hugh Fisher ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Heap allocate type structs in native extension modules?
> Date: Fri, 29 Dec 2017 11:25:14 +0200 > From: Serhiy Storchaka > To: python-dev@python.org > Subject: Re: [Python-Dev] Heap allocate type structs in native > extension modules? [ munch ] > Yes, you can create heap types by using PyType_FromSpecWithBases(). > > But be aware of caveats (https://bugs.python.org/issue26979). Thanks! I'll give it a go. I've already run into and solved the tp_new issue, so that won't be a problem. -- cheers, Hugh Fisher ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] fullOfEels, assistant program for writing Python extension modules in C
I've written a Python program named fullOfEels to speed up the first stages of writing Python extension modules in C. It is not a replacement for SWIG, SIP, or ctypes. It's for the case where you want to work in the opposite direction, specifying a Python API and then writing an implementation in C. (A small niche maybe, but I hope it isn't just me who sometimes works this way.) The input is a Python module specifying what it should do but not how, with all the functions, classes, and methods being just pass. The output is a pair of .h and .c files with all the boilerplate C code required: module initialization, class type structs, C method functions and method tables. Downloadable from https://bitbucket.org/hugh_fisher/fullofeels All feedback and suggestions welcome. -- cheers, Hugh Fisher ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] fullOfEels, assistant program for writing Python extension modules in C
On Fri, Feb 12, 2016 at 3:30 AM, Nathaniel Smith wrote: > You're almost certainly aware of this, but just to double check since you > don't mention it in the email: cython is also a great tool for handling > similar situations. Not quite the same since in addition to generating all > the boilerplate for you it then lets you use almost-python to actually write > the C implementations as well, and I understand that with your tool you > write the actual implementations in C. But probably also worth considering > in cases where you'd consider this tool, so wanted to make sure it was on > your radar. Yes, cython is a fine tool and I wouldn't try to dissuade anyone from using it if it works for them. FullOfEels is for when the implementation should be hidden altogether. Most often this is because of cross-platform differences or coding horrors, but could also be handy for teaching when it's easier to just give students plain Python modules to look at. Thanks for replying. -- cheers, Hugh Fisher ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Need discussion for a PR about memory and > objects
> Date: Sun, 18 Nov 2018 22:32:35 +1000 > From: Nick Coghlan > To: "Steven D'Aprano" > Cc: python-dev > Subject: Re: [Python-Dev] Need discussion for a PR about memory and > objects [ munch background ] > > Chris's initial suggestion was to use "license number" or "social > security number" (i.e. numbers governments assign to people), but I'm > thinking a better comparison might be to vehicle registration numbers, > since that analogy can be extended to the type and value > characteristics in a fairly straightforward way: > > - the object identity is like the registration number or license plate > (unique within the particular system of registering vehicles, but not > unique across systems, and may sometimes be transferred to a new > vehicle after the old one is destroyed) > - the object type is like the make and model (e.g. a 2007 Toyota > Corolla Ascent Sedan) > - the object value is a specific car (e.g. "that white Corolla over > there with 89000 km on the odometer") > > On the other hand, we're talking about the language reference here, > not the tutorial, and understanding memory addressing seems like a > reasonable assumed pre-requisite in that context. "Handle" has been used since the 1980s among Macintosh and Win32 programmers as "unique identifier of some object but isn't the memory address". The usage within those APIs seems to match what's being proposed for the new Python C API, in that programmers used functions to ask "what type are you?" "what value do you have?" but couldn't, or at least shouldn't, rely on actual memory layout. I suggest that for the language reference, use the license plate or registration analogy to introduce "handle" and after that use handle throughout. It's short, distinctive, and either will match up with what the programmer already knows or won't clash if or when they encounter handles elsewhere. -- cheers, Hugh Fisher ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Re: Typing syntax and ecosystem
> Message: 1 > Date: Sun, 11 Apr 2021 13:31:12 -0700 > From: Barry Warsaw > Subject: [Python-Dev] Re: PEP 647 Accepted > > This is something the SC has been musing about, but as it’s not a fully > formed idea, I’m a little hesitant to bring it up. That said, it’s somewhat > relevant: We wonder if it may be time to in a sense separate the typing > syntax from Python’s regular syntax. TypeGuards are a case where if typing > had more flexibility to adopt syntax that wasn’t strictly legal “normal” > Python, maybe something more intuitive could have been proposed. I wonder if > the typing-sig has discussed this possibility (in the future, of course)? [ munch ] > > Agreed. It’s interesting that PEP 593 proposes a different approach to > enriching the typing system. Typing itself is becoming a little ecosystem of > its own, and given that many Python users are still not fully embracing > typing, maybe continuing to tie the typing syntax to Python syntax is > starting to strain. I would really like to see either "Typed Python" become a different programming language, or progress to building type checking into the CPython implementation itself. (Python 4 seems to me the obvious release.) The current halfway approach is confusing and slightly ridiculous. The first, a separate programming language, would be like RATFOR and CFront in the past and TypeScript today. Typed Python can have whatever syntax the designers want because it doesn't have to be compatible with Python, just as TypeScript is not constrained by JavaScript. A type checker translates the original Typed Python source into "dynamic" or "classic" Python for execution. (Maybe into .pyc instead of .py?) This would mean no overhead for type checking in CPython itself. No need to contort the parser into ignoring bits of code that are, in effect, syntax checked comments. And for the typing in Python enthusiasts, you won't have to listen to people like me complaining. The second approach is to assume that type checking in Python is useful and popular. Not with me, but I'm willing to accept that I'm in the minority and can be ignored - after all, I can still write my Python code without type annotations. If so running a type checker as a separate step, as we do at the moment, is like asking C programmers to run the preprocessor by hand. In today's world of continuous build and integration, it seems silly to me to have a type checker read the source, scan into lexical tokens, build an abstract syntax tree, perform semantic analysis with type checking, and then throw it away before running an interpreter which reads the same source, scans into lexical tokens, builds an abstract syntax tree, and executes. On the purely pragmatic level there is an extra chance for mismatches and things to go wrong; and from an environmental viewpoint it isn't a great use of resources. -- cheers, Hugh Fisher ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/2DMJPVE4T6SMXIPQJVWOOSYWJX6DA22H/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Typing syntax and ecosystem
> Message: 4 > Date: Mon, 12 Apr 2021 13:59:50 -0700 > From: Brett Cannon > > Please don't denigrate the hard work people have put in to even bring > forward the idea of typing in Python by saying it's "slightly ridiculous". In the interest of moving the discussion forward about separate syntax or type checking integration, I apologize to anyone who feels personally insulted by my response. That was not my intention. -- cheers, Hugh Fisher ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/HL2HHS4VFQYLCSQQB5Z22M3P5IE4PM36/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Typing syntax and ecosystem, take 2
In any Python 3.6 or later, type >>> x : float = 1 >>> isinstance(x, float) or replace the second line with >>> type(x) As someone who has programmed in FORTRAN, Pascal, C/C++, Java, and Go this is not at all what I consider reasonable. I do not believe other programmers with experience in typed languages would expect this behaviour either. Having a type checker run before the Python interpreter in our current day continuous build/integration environment adds a second step and therefore the chance for it to be forgotten, for version mismatches, for warning/error reports to be misdirected. >From an environmental point of view we're also doing the read source, lexical scan, syntax parse twice rather than once. If typing is the future of Python, and the number of PEPs being worked on suggests that it is, then type checking should be integrated into CPython itself. An alternative is the TypeScript/JavaScript model, where typed Python becomes a distinct programming language that cannot be executed directly by the Python interpreter. -- cheers, Hugh Fisher ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/273J3AZ7VY7HRPDMGDHDCDELE3JV7WPT/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Typing syntax and ecosystem, take 2
On Tue, 13 Apr 2021 at 12:09, Filipe Laíns wrote: > [ munch ] > > Python is not a typed language, it is a language with optional typing. Well, it's a dynamically typed language. And yes I agree, I want typing to remain optional. I am happy that I can write x = 1 x = [ "hello", "world" ] x = ExtremelyComplicatedObject() without even having to qualify it as x : object > > Having a type checker run before the Python interpreter in our > > current day continuous build/integration environment adds a > > second step and therefore the chance for it to be forgotten, for > > version mismatches, for warning/error reports to be misdirected. > > From an environmental point of view we're also doing the read > > source, lexical scan, syntax parse twice rather than once. > > This is simply not a good point in itself, and on top of that it seems to > completely ignore that Python could be untyped, which is something I am almost > certain won't likely change ever. At the very least you would have to pass a > flag to the interpreter to run the type checker, which completely invalidates > your "people will forget it if they have to explicitly run it" point. This is my second (and somewhat preferred) proposal where type hints are recognised by the CPython interpreter, but they would remain optional. So no flag needed. If there aren't any type hints, that's fine. If there are type hints, assume they are there on purpose and parse and check. > All I can think of are reasons *not to* include it with the interpreter, > mainly > that it would be bound to the same super slow release cycle. > Please also consider that a type checker is something that no user will have > to > run, only developers. Getting slightly off topic, I have always thought that one of the strengths of Python is that every use is a potential developer. If you have a Python program and a text editor, you can change it. No special tools required. > Why?? This reads like "let's break stuff that is absolutely working" for no > real > discerning reason. Why would you do this? -- Why would we break workflows that > work? Why would we add a code generating step to typed Python code? > I am really struggling here to understand what would be the benefit here, it > seems you want to make it slightly harder for people to forget to run it, by > either making it always run or forcing a new code generation step. This is the model used by TypeScript (and various other dialects of JavaScript) and it works for them. The big advantage is that the Python interpreter does not need to know about typing, so no PEP 543 and no PEP 649, which is currently generating a lot of esoteric (to me) discussion on python-dev. > Please do not take these comments personally, in a verbal setting I would try > to > use social cues to try to pass the feedback more lightly. No complain from me Filipe, you're doing better at this than I am. -- cheers, Hugh Fisher ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/76EQHZLNMVWVSBIM5XBHHTKPXP7EJLLJ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Typing syntax and ecosystem, take 2
On Tue, 13 Apr 2021 at 18:43, Stéfane Fermigier wrote: > [ munch ] > > Python is, historically, a dynamically typed language, and gradual typing > (see https://en.wikipedia.org/wiki/Gradual_typing) has been progressively > added to it in the last decade or so. This is a legitimate approach, both > from an academic and industrial point of view, and similar (with some > variants) to what has been done also for JavaScript, Ruby, PHP, Lua, Perl, > Scheme, etc. over the same period. I'm aware of the difference between untyped and dynamic typing, and want to emphasise that I *like* the dynamic typing in Python. My complaint is not with gradual typing, but the current way it is done. [ munch ] > No need to integrate in CPython, one can already provide runtime type > checking using the current language, see e.g. > https://pypi.org/project/typeguard/ The current runtime type checking approach is causing significant performance problems, hence PEP 563, PEP 649, and the current discussion on python-dev about how to reduce them. In the TypeScript approach, "typed Python" is a distinct programming language that is translated into dynamic Python, those problems go away because the type notation would not be valid Python code. In the integrated approach, type checking built in, there would still be overhead but it would be *useful* overhead doing the actual type checking. -- cheers, Hugh Fisher ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/FSOSTLSCKCUQQUJQBWGDZMUASROAMYGR/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Typing syntax and ecosystem, take 2
On Tue, 13 Apr 2021 at 20:30, Stephen J. Turnbull wrote: [ munch ] > > As someone who has programmed in FORTRAN, Pascal, C/C++, > > Java, and Go this is not at all what I consider reasonable. > > From the point of view of typing, you've programmed in one other > language. ;-) (Maybe Go makes two, I haven't used it.) They all > demand that variables be declared with types, and then proceed to fill > them with bit patterns that can't be introspected (unless you build it > in to class definitions yourself). There are a lot of programmers like me. Those languages I listed are widely used, and therefore we assume that if a Python language construct looks like something we've used before, it will work in the same way. > Python's different approach is a compromise. And as usual Guido's > time machine (or somebody borrowed it) is in evidence: if that example > bothers you, request that people around you who type things like that > use stub files instead so you don't have to deal with it. And that would be the TypeScript style approach, "typed Python" is a language that gets translated into non-type hinted dynamic Python. No-one who works in JavaScript needs to deal with TypeScript language features unless they want to. This is not true of the current typing in Python. [ munch ] > This is a good point, but having an explicitly typed language would > mean I can't really use Python at work (that is, I can't recommend it > to my business and economics students, who don't program, really, they > record scripts). I don't want Python to be explicitly typed either. I'm happy with dynamic typing, and do not want to have to write even x : object > > From an environmental point of view we're also doing the read > > source, lexical scan, syntax parse twice rather than once. > > This is not true. Most programs, *especially* programs that are > complex enough to want type-checking, are run far more often than they > are type-checked. Among the software devs I work with, testing and checking is something you do *every* time you make a change. If I'm adding type checks to my program, that's because I want them to be checked. Historical example would be lint for C programs. Running lint wasn't required before compiling your C code, but it was so useful that a number of projects made it compulsory, and the functionality of lint was eventually incorporated into the C compiler itself. [ munch ] > I like to think of it as "Python typing has some warts, but that's > because it will turn out to be a prince(ss) when you kiss it." Yes, perfect is the enemy of good enough. I'm reading (OK, skimming) the emails about implementing PEP 649 on this list and I'm seeing significant problems in the current tools, not just cosmetic. -- cheers, Hugh Fisher ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/ANIPH3CFWDWIP2SRN2YQVPWR5I3KNIPD/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Typing syntax and ecosystem, take 2
> From: Ned Batchelder [ munch ] > This is very similar to statically typed languages. They also have two > steps: > > * There is the first step that checks the types but does not run the > program. In C/C++, this is the compiler, in Python it is "mypy". > * There is the second step that runs the program but does not check > the types. In C/C++, this is running the executable, in Python it is > "python". > > In Python, we can skip the first step, and perhaps that is the source of > your concern. I doubt anyone that has adopted type hinting in Python > will forget to run mypy, especially in a CI environment like you consider. In the current Python implementation, we can't skip the first step. Type hints have a significant performance impact on the Python interpreter, hence PEP 649. If we used the TypeScript approach, the typing hints would be removed before execution by the Python interpreter. As for "forget to run mypy", no-one sets out to do the wrong thing. The difference here is that with TypeScript -> JavaScript, if you forget to run the translation step, the program won't run because TypeScript is not valid JavaScript. Same was true for the old CFront C++ -> C translator. Errors are automatically detected. If you forget to run mypy, you've got a program which *looks* correct but might not be. -- cheers, Hugh Fisher ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/E7ZGBMYX7MCIX2DGDFLHB5XTSYN5IXJL/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Typing syntax and ecosystem
On Wed, 14 Apr 2021 at 08:21, Barry Warsaw wrote: > I wouldn’t necessarily be opposed to bundling a type checker with the > interpreter/stdlib, but I think there are some issues with it. Just off the > top of my head (there are undoubtedly many more issues to resolve): > > * Which type checker would we adopt or adapt, if any? Mypy. This has become an implementation issue, not one of which type system to adopt. A lot of code, even in the stdlib, has been annotated but I'm not aware of multiple different annotations with different semantics or type systems being created. For example, type equivalence by name only is used in Ada (or was, it's been many years) and probably other languages. In equivalence by name, the following code would not pass the type checker. x : list[int] y : list[int] x = y # Type error But I'm not aware of anyone implementing type by name equivalence for Python, and the original PEP 483 seems to explicitly close off that possibility. Instead the assumption seems to be Java/C++ structural equivalence for types. Skimming a bunch of current type system related PEPs, I'm not seeing anything that a Java/C++ programmer would find unfamiliar. And this is probably a good thing. > * Which parts of the typing system require more frequent release cycles? > * Is there a core technology that could be put in the stdlib and still allow > experimentation? > * Would the type checker authors become core developers? > * Do the same feature release / deprecation policies apply? No answers from me. > I would still be opposed to requiring type hinting in Python. I'm opposed to requiring type hints on everything, I want to still be able to write x = 1 x = "hello" etc without declaring any kind of type for x. -- cheers, Hugh Fisher ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/OABB53NTCBU6EKYQVVVY4IU2275XO4R4/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Typing syntax and ecosystem, take 2
> > Date: Tue, 13 Apr 2021 19:55:38 -0400 > From: Ned Batchelder > > In another message, you alluded to PEP 649 being a solution to run-time > type checking. Maybe I'm misunderstanding something: type annotations > never do type checking at runtime. As I understand it, PEP 649 is about > avoiding the overhead of evaluating the type expression itself, not > about checking the types of values. Yes, and I see that as a problem. Here are two versions of code V1 # Apocalypse may occur if foo is not foo = "coconut" V2 # Apocalypse may occur if foo is not foo : = "coconut" To the Python interpreter both have the same semantics and runtime behaviour. But V2 has type annotations, which are effectively syntactically constrained comments within individual statements. As code they do absolutely nothing. However, the performance hit from just being present is so great that talented programmers are working hard to make the Python interpreter ... ignore them more efficiently. -- cheers, Hugh Fisher ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/A24AW5W2O5OEMFYZNIWWHZVDWM7HCJKV/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Typing syntax and ecosystem
> Date: Wed, 14 Apr 2021 11:24:12 +0200 > From: Antoine Pitrou > Subject: [Python-Dev] Re: Typing syntax and ecosystem > > Can you explain why you think C++ typing is based on structural > equivalence? I'd rather not have a detailed discussion of C++ typing on python-dev. My example was Ada style type equivalence by name only, in contrast to Java/C++ style type checking which AFAIK is called "structural equivalence". But if you use another term, it won't matter. My point is that sometimes people have argued that the type checker shouldn't be part of the Python interpreter because we're not sure about the best approach and need to have freedom to experiment. I don't think that is still true. Some type system choices, such as equivalence by name only, have already been effectively ruled out. And there's now so much code already annotated assuming the Java/C++ style that I don't think a different type scheme checking can replace it. We've chosen the type scheme for Python (although there may be some fine details to do) and now we're just working on the implementation aspects. Travelling for a few days, so this is probably a good place to stop on. Thank you everybody for responding. -- cheers, Hugh Fisher ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/QRTERIPKB2QW6JB2CULRGT3CG3JX5FMO/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Typing syntax and ecosystem, take 2
> Date: Wed, 14 Apr 2021 09:57:49 +1000 > From: Chris Angelico > Subject: [Python-Dev] Re: Typing syntax and ecosystem, take 2 > > You're advocating an approach that absolutely mandates running the > type checker, but then caches the results in an executable file (the > JS file built from the TS source). Python already has a caching system > - the .pyc files - so if you're importing the same file more than > once, the cost of parsing type annotations is pretty much equivalent > to the cost of doing it in TypeScript. Thinking about it, if mypy compiled to .pyc for execution by the Python interpreter most of what I'm complaining about would go away. -- cheers, Hugh Fisher ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/LXFOU3TSSBXVCEFRMWJBBV7GHVRW357P/ Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-Dev] C99
> Message: 2 > Date: Sat, 6 Aug 2016 14:27:15 +0900 > From: INADA Naoki > To: Guido van Rossum > Cc: Ned Deily , Python-Dev > Subject: Re: [Python-Dev] C99 > Message-ID: > > Content-Type: text/plain; charset=UTF-8 > > I think these features may improve C code readability. > (Easy feature first). > > * // one line comment > > * inline function > static inline function can be used instead of may macros. > It is more readable, and type safe. My experience from a few months ago with some cross-platform code is that clang, GCC and MSVC have different ideas about how inline functions in C work. Are they static or extern? Do you need provide an implementation body somewhere? There are also differences between the C++ and C99 definitions. Probably all solvable with build settings, but not as easy as one line comments. -- cheers, Hugh Fisher ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Re: Python-Dev Digest, Vol 204, Issue 59
> Date: Wed, 8 Jul 2020 20:00:44 +0300
> From: Paul Sokolovsky
> Subject: [Python-Dev] Re: Python is the only language with lack of
[ munch ]
> Right. So, if someone would like to add something to this thread, I'd
> humbly suggest to concentrate on the lack of, and need for, of
> const-ness in the Python language core (in comparison to other languages
> or not), and usecases it enables, and not on criteria for "popularness".
>
My view is that the informal Python "don't mess with anything all in
upper case" coding convention works at least as well as any more
formal language notation for nearly all cases. It conveys intention
very well with minimum effort, and does not require programmers
to think about the language they're using rather than the problem
they are trying to solve.
I can see the case for a const annotation/keyword for simple
scalar values, almost always numbers, but am dubious about
the benefits. If someone really wants to write
IMPORTANT_SIN30 = math.sin(45)
there's only so much a compiler/interpreter can do to stop them.
"If we just provide enough detail we can catch every error" is
a mirage that's lured away so much effort for many decades.
(That said, I'd be in favour of adding math.PI and similar
names because even I find it slightly disturbing that I can write
math.pi = 3.0
and it doesn't look wrong.)
Even for simple numbers, constness can be argued. Is the
value determined when the code is written, or when run?
A lot of mutable variables in Pascal/C/Ada programs are really
constants, but the value is "number of CPU cores" or something
else that can't be determined until first use. So those other
languages that supposedly have constness are actually often
more like Python.
Once you go beyond scalar values, it's just a mess. If I write
const myd = { "answer" : 42 }
do I mean that myd will always be a reference to that object,
or that the object being pointed to has constant members?
To see what can happen if you try and build this into the
language, look at C++. It has the const keyword for objects
and object references. But then the "mutable" keyword got
added to describe object members, because programmers
needed to be able to modify the internal values of "const"
objects! So now "const" in C++ for objects just means you
don't intend to change the internal state, but it might do
so anyway.
Again, I can see a case in embedded systems for "const"
meaning "this can be put in ROM". But I don't think that
use case is common enough to justify adding to the core
language.
--
cheers,
Hugh Fisher
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/B6UBKV6D3C3NLD6WIDSWSFZLYOGPSJI6/
Code of Conduct: http://python.org/psf/codeofconduct/
