Re: type hinting backward compatibility with python 3.0 to 3.4
Chris Angelico wrote: How do you declare that a parameter must be an instance of some class? Classes are themselves created at run time. Or would your typing system require that all types be created in some declarable way? Types that you want statically checked have to be described in a declarative way, because the description is going to be processed by a tool that is not executing the program. You wouldn't be able to put a type that can't be described declaratively into a type annotation, but there would be no reason to do so in the first place. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: type hinting backward compatibility with python 3.0 to 3.4
On 21/05/2017 06:41, Chris Angelico wrote: On Sun, May 21, 2017 at 3:30 PM, Gregory Ewing wrote: Chris Angelico wrote: But since Python _does_ work with dynamic evaluation (which consequently demands that these kinds of things be expressions evaluated at compile time), it must by definition be possible to have side effects. In most languages, type declarations are not expressions and aren't evaluated at all in the usual sense, so questions of evaluation order and side effects just don't apply. If we were designing a static typing system for Python from scratch, I would be strongly arguing that type hints shouldn't be expressions evaluated at run time, because it's such a poor fit for the intended use. Introspectable by all means, but evaluated by default, no. How do you declare that a parameter must be an instance of some class? Classes are themselves created at run time. Or would your typing system require that all types be created in some declarable way? They might be /created/ at runtime, but it's a pretty good bet that the name A in this declaration: class A... is the name of a class. The question in Python, as always, is whether an A used as the name of a type in a type, is still this same A. And presumably such a type hint can precede the declaration of A. In fact the declaration of A might be in a different module from its use in a type hint, which means that, in the CPython byte-code compiler anyway, it is not visible at compile-time, when type hints could best be put to good effect. Furthermore, both A, and the type-hinting code, might be conditional. So that on Tuesdays, A is a class, the rest of the week it's the name of a module. Python doesn't make things easy. -- bartc -- https://mail.python.org/mailman/listinfo/python-list
Re: type hinting backward compatibility with python 3.0 to 3.4
On Sun, May 21, 2017 at 7:15 PM, Gregory Ewing wrote: > Chris Angelico wrote: >> >> How do you declare that a parameter must be an instance of some class? >> Classes are themselves created at run time. Or would your typing >> system require that all types be created in some declarable way? > > > Types that you want statically checked have to be described > in a declarative way, because the description is going to be > processed by a tool that is not executing the program. > > You wouldn't be able to put a type that can't be described > declaratively into a type annotation, but there would be no > reason to do so in the first place. That kind of difference is fine with an external tool, but it'd make the language itself inconsistent. For (say) mypy to be able to check your code, it needs to be able to figure out what classes exist. Fine, no problem. But for CPython to be able to run your code, it needs to be able to syntactically verify everything. With mypy, if your classes are too dynamic, you might have to create a stub file that's more static (but non-functional) just for the type checking. Can you do that if your type checker is part of the language? What happens if the stub file is flat-out wrong? (Again, with mypy, all you break is the type checker.) There's a lot of difference between PEP 484 type hints and C-style static typing. Or even PEP 484 and Pike-style type hinting, where you can say "object(implements yada yada)" and you'll generally mean "yada yada or a subclass thereof" (though not necessarily). Pike's static type checks are only useful if the type in question exists in a static context - otherwise you have to just use "object" or some other parent class. (Or just ignore type checking for that. It's a dynamically-typed language, so static checking is as optional as it is in Python.) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: type hinting backward compatibility with python 3.0 to 3.4
On Sun, May 21, 2017 at 7:29 PM, bartc wrote: > > They might be /created/ at runtime, but it's a pretty good bet that the name > A in this declaration: > > class A... > > is the name of a class. The question in Python, as always, is whether an A > used as the name of a type in a type, is still this same A. And presumably > such a type hint can precede the declaration of A. > > In fact the declaration of A might be in a different module from its use in > a type hint, which means that, in the CPython byte-code compiler anyway, it > is not visible at compile-time, when type hints could best be put to good > effect. That isn't a problem - mypy follows imports. It'd be pretty useless if it didn't :) > Furthermore, both A, and the type-hinting code, might be conditional. So > that on Tuesdays, A is a class, the rest of the week it's the name of a > module. Or, more plausible example: on platforms that have a system-provided source of entropy, random.random is an instance of SystemRandom, but on those that don't, it's an instance of DeterministicRandom with an arbitrarily-chosen seed. The two will have slightly different APIs. > Python doesn't make things easy. Python makes things flexible, which has a cost. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Python compiled by tcc
Am 18.05.17 um 10:10 schrieb Christian Gollwitzer: The whole discussion reminds me of the "bumblebees can't fly" thing. tcc is a very small compiler (some 100kb) which supports most of C99. For what it's worth, I compiled Python 3.6.1 on Linux/x86 using tcc. It was a simple matter of cloning tcc, compiling/installing it and the doing CC=tcc ./configure make in the Python source folder. It only failed at the final linker step, because the tcc linker does not understand the flags -Xlinker -export-dynamic. The compilation was extremely fast, it took 5s of wall clock time and 3s of user time to go from the sources to the python executable. The ./python executable generated this way does work as far as I can tell, however "make test" fails with an import error - module "socket" is not available. Additionally, after linking "python", the compilation went on and required a C++ compiler, which was no problem in itself, but of course fell back to g++ - tcc only supports pure C. So IMHO it should be a breeze to compile a pure C Python extension into something which successfully runs with the gcc compiled python. On OSX, it was not successfull, because tcc cannot yet create executable binaries on disk in Mach-O format, however, ibraries are possible and runtime-linking (JIT) works without problems. I guess that compiling the full thing on Windows could work with CC=tcc, if the GNU utils arae available (Cygwin/MSYS/Linux subsystem) Christian -- https://mail.python.org/mailman/listinfo/python-list
Re: How to install Python package from source on Windows
On 20/05/2017 19:37, Chris Angelico wrote: rosuav@sikorsky:~/linux$ find -name \*.c -or -name \*.h | wc -l 44546 These repositories, by the way, correspond to git URLs https://github.com/python/cpython, git://pike-git.lysator.liu.se/pike.git, git://source.winehq.org/git/wine, and https://github.com/torvalds/linux respectively, if you want to check my numbers. Two language interpreters, a popular execution subsystem, and an OS kernel. I'd like to see you create a single-file version of the Linux kernel that compiles flawlessly on any modern compiler and has no configure script. I've had a look at the Linux stuff. (BTW, when copying to Windows, the file "aux" occurs several times, which causes problems as it's a reserved filename I think. Also there were a dozen conflicts where different versions of the same file wanted to be stored at the same location.) So, it /is/ big: 24000 .c files, 19000 .h files, out of 59000 total. (And 12000 directories, but I think that includes multiple "." and ".." instances, so probably 'only' about 4000.) However, I assume then when it is at some point compiled to binary, that a single image file results. An attempt to create a single source file would result in a representation somewhere between those two points. But it sounds like it wouldn't be possible, or practical, to have a single source that works for every possible target; it might have to be one source file for each of a number of the most common targets. I've noticed a number of files that look like assembly code - not C anyway - that also need to be taken into account. But on something this size, it is not absolutely essential the end result is exactly one file. A dozen files in one flat directory that can be trivially compiled would still be an improvement. (If you imagine a future where the number of targets has increased a hundred-fold (or we colonise the galaxy and there are a million possible targets), then it might become clearer that the approach used here - putting files for every conceivable machine in the same place - is not scalable.) -- bartc -- https://mail.python.org/mailman/listinfo/python-list
Re: Python compiled by tcc
On 21/05/2017 10:32, Christian Gollwitzer wrote: Am 18.05.17 um 10:10 schrieb Christian Gollwitzer: The whole discussion reminds me of the "bumblebees can't fly" thing. tcc is a very small compiler (some 100kb) which supports most of C99. For what it's worth, I compiled Python 3.6.1 on Linux/x86 using tcc. It was a simple matter of cloning tcc, compiling/installing it and the doing CC=tcc ./configure make in the Python source folder. It only failed at the final linker step, because the tcc linker does not understand the flags -Xlinker -export-dynamic. The compilation was extremely fast, it took 5s of wall clock time and 3s of user time to go from the sources to the python executable. That's good news, the fact that such a small compiler can go a good way towards compiling quite an elaborate project, with only some technicalities getting in the way. (And it makes you wonder what on earth those other tools are up to.) BTW, how long did an incremental change take to build? I've measured 5 seconds before with gcc. Tcc might be slower in its generated code, but if you just want to quickly see the result of a modification, that the result might run at half the speed is irrelevant. (Not such good news for me, as now I feel obliged to make my own C compiler manage it. And it sort of competes with tcc for compilation speed (and size too but that wasn't intentional). However it lacks some C99 features at the minute.) -- bartc -- https://mail.python.org/mailman/listinfo/python-list
Re: Python compiled by tcc
Am 21.05.17 um 12:38 schrieb bartc: On 21/05/2017 10:32, Christian Gollwitzer wrote: Am 18.05.17 um 10:10 schrieb Christian Gollwitzer: The whole discussion reminds me of the "bumblebees can't fly" thing. tcc is a very small compiler (some 100kb) which supports most of C99. For what it's worth, I compiled Python 3.6.1 on Linux/x86 using tcc. It was a simple matter of cloning tcc, compiling/installing it and the doing CC=tcc ./configure make BTW, how long did an incremental change take to build? I've measured 5 seconds before with gcc. Tcc might be slower in its generated code, but if you just want to quickly see the result of a modification, that the result might run at half the speed is irrelevant. If I do touch Python/Python-ast.c time make python it says real0m0.564s user0m0.394s sys 0m0.149s BTW the Xlinker option is a good example to see why autoconf is needed. They were lazy and had a simple switch on `uname` to find the option, instead of testing it with the compile-macros of autoconf. (Not such good news for me, as now I feel obliged to make my own C compiler manage it. And it sort of competes with tcc for compilation speed (and size too but that wasn't intentional). However it lacks some C99 features at the minute.) haha :) Good luck with that. Remember, tcc supports x86, x86_64, MIPS, ARM, ARM64, and C67, so it is a serious beast. Christian -- https://mail.python.org/mailman/listinfo/python-list
Re: How to install Python package from source on Windows
On Sun, May 21, 2017 at 8:23 PM, bartc wrote: > On 20/05/2017 19:37, Chris Angelico wrote: > >> rosuav@sikorsky:~/linux$ find -name \*.c -or -name \*.h | wc -l >> 44546 >> >> These repositories, by the way, correspond to git URLs >> https://github.com/python/cpython, >> git://pike-git.lysator.liu.se/pike.git, >> git://source.winehq.org/git/wine, and >> https://github.com/torvalds/linux respectively, if you want to check >> my numbers. Two language interpreters, a popular execution subsystem, >> and an OS kernel. >> >> I'd like to see you create a single-file version of the Linux kernel >> that compiles flawlessly on any modern compiler and has no configure >> script. > > > I've had a look at the Linux stuff. (BTW, when copying to Windows, the file > "aux" occurs several times, which causes problems as it's a reserved > filename I think. Also there were a dozen conflicts where different versions > of the same file wanted to be stored at the same location.) I don't understand where you would have obtained the sources that there are duplicate files. It's easiest just to clone someone's git repo (eg Linus Torvald's). > So, it /is/ big: 24000 .c files, 19000 .h files, out of 59000 total. (And > 12000 directories, but I think that includes multiple "." and ".." > instances, so probably 'only' about 4000.) > > However, I assume then when it is at some point compiled to binary, that a > single image file results. There are kernel modules too. > An attempt to create a single source file would result in a representation > somewhere between those two points. But it sounds like it wouldn't be > possible, or practical, to have a single source that works for every > possible target; it might have to be one source file for each of a number of > the most common targets. > > I've noticed a number of files that look like assembly code - not C anyway - > that also need to be taken into account. But on something this size, it is > not absolutely essential the end result is exactly one file. A dozen files > in one flat directory that can be trivially compiled would still be an > improvement. > > (If you imagine a future where the number of targets has increased a > hundred-fold (or we colonise the galaxy and there are a million possible > targets), then it might become clearer that the approach used here - putting > files for every conceivable machine in the same place - is not scalable.) Actually it's not scalable as soon as you have TWO targets. Every change has to be made to both source files. And where they differ, you need markers to say that it's different. You know, like ifdef lines usually are. I wonder if maybe the current system isn't the result of incompetence after all? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: How to install Python package from source on Windows
Am 21.05.17 um 12:23 schrieb bartc: On 20/05/2017 19:37, Chris Angelico wrote: rosuav@sikorsky:~/linux$ find -name \*.c -or -name \*.h | wc -l 44546 These repositories, by the way, correspond to git URLs https://github.com/python/cpython, git://pike-git.lysator.liu.se/pike.git, git://source.winehq.org/git/wine, and https://github.com/torvalds/linux respectively, if you want to check my numbers. Two language interpreters, a popular execution subsystem, and an OS kernel. I'd like to see you create a single-file version of the Linux kernel that compiles flawlessly on any modern compiler and has no configure script. I've had a look at the Linux stuff. (BTW, when copying to Windows, the file "aux" occurs several times, which causes problems as it's a reserved filename I think. Also there were a dozen conflicts where different versions of the same file wanted to be stored at the same location.) So, it /is/ big: 24000 .c files, 19000 .h files, out of 59000 total. (And 12000 directories, but I think that includes multiple "." and ".." instances, so probably 'only' about 4000.) However, I assume then when it is at some point compiled to binary, that a single image file results. No, it doesn't, at least not necessarily. The Linux kernel includes all of the device drivers that are supported by Linux. This is the main reason that it is such a big project. These device drivers can either be linked statically into the kernel, which makes sense for all stuff which is needed during the boot process, or on embedded systems, or compiled into kernel modules, kind of "dynamic libraries" of the kernel, which it loads/unloads at runtime. An attempt to create a single source file would result in a representation somewhere between those two points. But it sounds like it wouldn't be possible, or practical, to have a single source that works for every possible target; It is most definitely not. Linux runs on a large diversity of platforms. It has an elaborate build process, wicth a GUI to configure all the compile options. Probably no human would be able to set them to a reasonable value without the help of thsi software. Christian -- https://mail.python.org/mailman/listinfo/python-list
Re: How to install Python package from source on Windows
Chris Angelico writes: > On Sun, May 21, 2017 at 8:23 PM, bartc wrote: >> On 20/05/2017 19:37, Chris Angelico wrote: >> >>> rosuav@sikorsky:~/linux$ find -name \*.c -or -name \*.h | wc -l >>> 44546 >>> >>> These repositories, by the way, correspond to git URLs >>> https://github.com/python/cpython, >>> git://pike-git.lysator.liu.se/pike.git, >>> git://source.winehq.org/git/wine, and >>> https://github.com/torvalds/linux respectively, if you want to check >>> my numbers. Two language interpreters, a popular execution subsystem, >>> and an OS kernel. >>> >>> I'd like to see you create a single-file version of the Linux kernel >>> that compiles flawlessly on any modern compiler and has no configure >>> script. >> >> >> I've had a look at the Linux stuff. (BTW, when copying to Windows, >> the file "aux" occurs several times, which causes problems as it's a >> reserved filename I think. Also there were a dozen conflicts where >> different versions of the same file wanted to be stored at the same >> location.) > > I don't understand where you would have obtained the sources that > there are duplicate files. It's easiest just to clone someone's git > repo (eg Linus Torvald's). It happened to me recently when cloning a git repository from GitHub, using GitHub Desktop, to a Mac OS file system. Some filenames differed only in case, like "INFO" and "info" in the same directory. Mac OS considered them the same file, Git tried to associate them with different objects, or something like that. Cat-astrophic :) Something similar happened on Windows with filenames that ended in a period, in the same repository after the problems on Mac OS had been fixed. Apparently Windows considers "log-3.1." the same as "log-3.1" - is that right? (This cloning attempt was not made by me but by a colleague who has access to a Windows computer. It was mostly calendar dates in a format that uses periods.) I was surprised that Git (or GitHub Desktop) simply failed so badly. Not sure what it could have done instead. (There were also filenames that Mac OS or Windows rejected. Also filenames that were truly horrible - a couple contained backspaces.) Incidentally, I used Python scripts to find and fix issues in those filenames, including character encoding issues. Smooth sailing :) -- https://mail.python.org/mailman/listinfo/python-list
Re: How to install Python package from source on Windows
On Sun, May 21, 2017 at 9:43 PM, Jussi Piitulainen wrote: > It happened to me recently when cloning a git repository from GitHub, > using GitHub Desktop, to a Mac OS file system. Some filenames differed > only in case, like "INFO" and "info" in the same directory. Mac OS > considered them the same file, Git tried to associate them with > different objects, or something like that. Cat-astrophic :) > > Something similar happened on Windows with filenames that ended in a > period, in the same repository after the problems on Mac OS had been > fixed. Apparently Windows considers "log-3.1." the same as "log-3.1" - > is that right? (This cloning attempt was not made by me but by a > colleague who has access to a Windows computer. It was mostly calendar > dates in a format that uses periods.) > > I was surprised that Git (or GitHub Desktop) simply failed so badly. > Not sure what it could have done instead. Why are you surprised that it failed, if you agree that there's nothing else it could have done? The fault is with the file system that is unable to distinguish file names that are logically distinct. It's not the file system's place to fold case; if anything, it's the UI's job. And git has been given content for both file names, so what's it going to do other than attempt to create both files? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: How to install Python package from source on Windows
Chris Angelico writes: > On Sun, May 21, 2017 at 9:43 PM, Jussi Piitulainen wrote: >> It happened to me recently when cloning a git repository from GitHub, >> using GitHub Desktop, to a Mac OS file system. Some filenames differed >> only in case, like "INFO" and "info" in the same directory. Mac OS >> considered them the same file, Git tried to associate them with >> different objects, or something like that. Cat-astrophic :) >> >> Something similar happened on Windows with filenames that ended in a >> period, in the same repository after the problems on Mac OS had been >> fixed. Apparently Windows considers "log-3.1." the same as "log-3.1" - >> is that right? (This cloning attempt was not made by me but by a >> colleague who has access to a Windows computer. It was mostly calendar >> dates in a format that uses periods.) >> >> I was surprised that Git (or GitHub Desktop) simply failed so badly. >> Not sure what it could have done instead. > > Why are you surprised that it failed, if you agree that there's > nothing else it could have done? The fault is with the file system > that is unable to distinguish file names that are logically distinct. > It's not the file system's place to fold case; if anything, it's the > UI's job. And git has been given content for both file names, so > what's it going to do other than attempt to create both files? I was surprised that it didn't notice and report that things went wrong while it was creating the clone that it was unable to handle afterwards. It apparently created an inconsistent index and thought everything was fine at that point. Then failed to understand its own state. It could have noticed that it's about to create a file that is already there when it shouldn't be. -- https://mail.python.org/mailman/listinfo/python-list
Re: How to install Python package from source on Windows
On Sun, May 21, 2017 at 11:33 PM, Jussi Piitulainen wrote: > I was surprised that it didn't notice and report that things went wrong > while it was creating the clone that it was unable to handle afterwards. > It apparently created an inconsistent index and thought everything was > fine at that point. Then failed to understand its own state. > > It could have noticed that it's about to create a file that is already > there when it shouldn't be. Interesting. I'm not sure how best to solve that, but at best, all you'll get is a tidy error message - and "git status" should report on the problem, one way or another. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: How to install Python package from source on Windows
On 21/05/2017 12:06, Chris Angelico wrote:
On Sun, May 21, 2017 at 8:23 PM, bartc wrote:
(If you imagine a future where the number of targets has increased a
hundred-fold (or we colonise the galaxy and there are a million possible
targets), then it might become clearer that the approach used here - putting
files for every conceivable machine in the same place - is not scalable.)
Actually it's not scalable as soon as you have TWO targets. Every
change has to be made to both source files. And where they differ, you
need markers to say that it's different. You know, like ifdef lines
usually are. I wonder if maybe the current system isn't the result of
incompetence after all?
Let's say we have a very simple OS that just does this:
beep(1000,100) # pitch, duration
and stops. So the above is the entire source. It runs on disparate
machines A and B. Each of those needs to provide an implementation of
beep():
def beep(p,d): # machine A
out(0x100, p)
out(0x101, d)# or whatever
def beep(p,d): # machine B
callint(0x30, p,d)
Now I want to port it to a new machine, and need to provide a custom
version of beep() that works here:
def beep(p,d):
print("bp!")
Explain why ALL these drivers, including the one I've just created, need
to be part of the common source code for the OS.
Or why a change in the source code of the OS, eg. changing it to:
beep(500, 50)
beep(2000,200)
Needs to be done in three different places.
--
Bartc
--
https://mail.python.org/mailman/listinfo/python-list
Re: How to install Python package from source on Windows
On Mon, May 22, 2017 at 12:58 AM, bartc wrote:
> On 21/05/2017 12:06, Chris Angelico wrote:
>>
>> On Sun, May 21, 2017 at 8:23 PM, bartc wrote:
>
>
>>> (If you imagine a future where the number of targets has increased a
>>> hundred-fold (or we colonise the galaxy and there are a million possible
>>> targets), then it might become clearer that the approach used here -
>>> putting
>>> files for every conceivable machine in the same place - is not scalable.)
>>
>>
>> Actually it's not scalable as soon as you have TWO targets. Every
>> change has to be made to both source files. And where they differ, you
>> need markers to say that it's different. You know, like ifdef lines
>> usually are. I wonder if maybe the current system isn't the result of
>> incompetence after all?
>
>
> Let's say we have a very simple OS that just does this:
>
> beep(1000,100) # pitch, duration
>
> and stops. So the above is the entire source. It runs on disparate machines
> A and B. Each of those needs to provide an implementation of beep():
>
> def beep(p,d): # machine A
> out(0x100, p)
> out(0x101, d)# or whatever
>
> def beep(p,d): # machine B
> callint(0x30, p,d)
>
> Now I want to port it to a new machine, and need to provide a custom version
> of beep() that works here:
>
> def beep(p,d):
> print("bp!")
>
> Explain why ALL these drivers, including the one I've just created, need to
> be part of the common source code for the OS.
I don't know. YOU are the one who said the source code should be in a
single file. The normal thing to do is to (a) have separate source
files for different underlying hardware, and then (b) have *a
configure script* that decides which one should be compiled in. That
way, you only compile in those parts that you need, and link them
together appropriately. Every piece of important code exists in one
place.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: type hinting backward compatibility with python 3.0 to 3.4
On Sun, May 21, 2017 at 2:38 AM, Chris Angelico wrote: > On Sun, May 21, 2017 at 7:29 PM, bartc wrote: > > > > They might be /created/ at runtime, but it's a pretty good bet that the > name > > A in this declaration: > > > > class A... > > > > is the name of a class. The question in Python, as always, is whether an > A > > used as the name of a type in a type, is still this same A. And > presumably > > such a type hint can precede the declaration of A. > > > > In fact the declaration of A might be in a different module from its use > in > > a type hint, which means that, in the CPython byte-code compiler anyway, > it > > is not visible at compile-time, when type hints could best be put to good > > effect. > > That isn't a problem - mypy follows imports. It'd be pretty useless if > it didn't :) > > > Furthermore, both A, and the type-hinting code, might be conditional. So > > that on Tuesdays, A is a class, the rest of the week it's the name of a > > module. > > Or, more plausible example: on platforms that have a system-provided > source of entropy, random.random is an instance of SystemRandom, but > on those that don't, it's an instance of DeterministicRandom with an > arbitrarily-chosen seed. The two will have slightly different APIs. > > > Python doesn't make things easy. > > Python makes things flexible, which has a cost. > > ChrisA > -- > https://mail.python.org/mailman/listinfo/python-list > Perhaps a good way to distinguish between a class that can be used as a type and a class that cannot be used as a type would be to require some sort of dunder method be defined on the type class. At first I was thinking `__type__`, but then I remembered that's already in use. maybe something as simple as `__hint__`. That or only allow classes that inherit from `type` to be used in type annotations. I'm just spit balling ideas here. -- https://mail.python.org/mailman/listinfo/python-list
Re: type hinting backward compatibility with python 3.0 to 3.4
Could something like this support forward declarations without the hackish use of strings? On Sun, 21 May 2017 at 12:01 justin walters wrote: > On Sun, May 21, 2017 at 2:38 AM, Chris Angelico wrote: > > > On Sun, May 21, 2017 at 7:29 PM, bartc wrote: > > > > > > They might be /created/ at runtime, but it's a pretty good bet that the > > name > > > A in this declaration: > > > > > > class A... > > > > > > is the name of a class. The question in Python, as always, is whether > an > > A > > > used as the name of a type in a type, is still this same A. And > > presumably > > > such a type hint can precede the declaration of A. > > > > > > In fact the declaration of A might be in a different module from its > use > > in > > > a type hint, which means that, in the CPython byte-code compiler > anyway, > > it > > > is not visible at compile-time, when type hints could best be put to > good > > > effect. > > > > That isn't a problem - mypy follows imports. It'd be pretty useless if > > it didn't :) > > > > > Furthermore, both A, and the type-hinting code, might be conditional. > So > > > that on Tuesdays, A is a class, the rest of the week it's the name of a > > > module. > > > > Or, more plausible example: on platforms that have a system-provided > > source of entropy, random.random is an instance of SystemRandom, but > > on those that don't, it's an instance of DeterministicRandom with an > > arbitrarily-chosen seed. The two will have slightly different APIs. > > > > > Python doesn't make things easy. > > > > Python makes things flexible, which has a cost. > > > > ChrisA > > -- > > https://mail.python.org/mailman/listinfo/python-list > > > > Perhaps a good way to distinguish between a class that can be used as a > type and a class > that cannot be used as a type would be to require some sort of dunder > method be > defined on the type class. At first I was thinking `__type__`, but then I > remembered that's > already in use. maybe something as simple as `__hint__`. > > That or only allow classes that inherit from `type` to be used in type > annotations. > > I'm just spit balling ideas here. > -- > https://mail.python.org/mailman/listinfo/python-list > -- Oliver My StackOverflow contributions My CodeProject articles My Github projects My SourceForget.net projects -- https://mail.python.org/mailman/listinfo/python-list
Re: How to install Python package from source on Windows
On 21/05/2017 17:51, breamore...@gmail.com wrote: On Saturday, May 20, 2017 at 10:56:17 PM UTC+1, bartc wrote: I am still also sticking with the belief that you know about as much about programming as the RUE knows about unicode. What major projects have you worked on? Actually what have you worked on? I've been retired since the start of the millennium. Before that I mostly created low-end CAD systems for PCs, largely for a non-English market. Before that I mainly developed experimental hardware such as board computers and video cards. For that, I also developed small language tools to help out. And some years before, I recall being paid money to program in Fortran for government research. After getting my CS degree. That's my brief resume`; what's yours? I recall from Chris Angelico that your online code has no test code, The online code I linked to are demonstrations of my private one-man projects. They are largely language projects and demos of how to produce compact and briskly-executing code. They are also demos of how such projects can be still be supplied as source yet tidily packaged to exclude troublesome and irrelevant details. They are also just examples that show Another Way of doings things. That they have no formal tests doesn't matter. I'm not selling anything or desperate for people to use them. But it shows what can be done and what would be nice of other projects. I don't think you can reject the concept of having a project being presented in a compact and accessible form just because one particular example of it doesn't meet your exacting standards. I think it was YOU that got me wasting time downloading that VS2015 solution, all 1MB of it [download size; unknown installation size], when someone posts today that they pretty much managed the same job with a 1.5MB solution [installation size]. It seems some things /can/ work on a small scale after all. yet you claim it's the best thing since sliced bread because it's so fast, and so small. It's not all about my stuff. Tiny C is also small and fast (and works). Whoopee do!!! I'd love working testing your code, at least I'd know I was in a job for life. /I/ certainly would be if I was obliged to use that entire raft of tools you suggested! (I have wondered more than once if these massive tools, and colossal software in general, existed partly to provide extra employment to programmers, as well as to maintain shares in companies producing memory, storage, and processors. And training programs. The world economy would probably grind to a halt if everyone adopted my working practices!) -- bartc -- https://mail.python.org/mailman/listinfo/python-list
Python Geosystem / KML / Google Earth
Hi, I have used some time to look around the internet, but seems not to get me further, therefore i think i would ask in here :) I would like to add an overlay picture in google maps, ny add it to KML file, that part i think i know how to do. What i have issues with is to calculate the 4 corners of the picture. If o know the center lat/lon and i want to add the picture (10m x 10m) with this position in the middle of the picture? Also how to know how many pixels this picture have to be... maybe the ratio is enough and then it will scale it automatic. I think this is mainly a issues of understanding the geo system, but also how to code it, what libraries are smartest to use etc. Hope you can help me in any direction :) /Kasper -- https://mail.python.org/mailman/listinfo/python-list
Re: How to install Python package from source on Windows
On 21/05/2017 16:21, Chris Angelico wrote: On Mon, May 22, 2017 at 12:58 AM, bartc wrote: On 21/05/2017 12:06, Chris Angelico wrote: Explain why ALL these drivers, including the one I've just created, need to be part of the common source code for the OS. I don't know. YOU are the one who said the source code should be in a single file. No, it was you challenged me to produce a one-file kernel source code. What I wanted was a more streamlined, more compact, more portable, less troublesome way of distributing self-contained applications. I wasn't suggesting bundling the source to an entire OS with it! I don't consider the CPython bundle that portable because it really demands that it be built under Linux. There is (now) a grudging concession for Windows, but that solution wasn't satisfactory when I tried it. My links show extreme versions of what is possible. For much simple applications, but they will still comprise 1% of the number of files that would otherwise be required if I simply made available my sprawling working setup like everyone else. (With Linux kernels, I don't know enough about them to provide realistic answers. But 60,000 files seems a lot, for the same reason that 100,000 files for a C compiler [gcc] seems a lot considering that some are MUCH smaller. But then, both these projects are dwarfed by the apparent 1.5 *million* files of the VS sources.) -- bartc -- https://mail.python.org/mailman/listinfo/python-list
Re: How to install Python package from source on Windows
On Mon, May 22, 2017 at 5:32 AM, bartc wrote: > On 21/05/2017 16:21, Chris Angelico wrote: >> >> On Mon, May 22, 2017 at 12:58 AM, bartc wrote: >>> >>> On 21/05/2017 12:06, Chris Angelico wrote: > > >>> Explain why ALL these drivers, including the one I've just created, need >>> to >>> be part of the common source code for the OS. >> >> >> I don't know. YOU are the one who said the source code should be in a >> single file. > > > No, it was you challenged me to produce a one-file kernel source code. Yes, because you claimed that non-trivial projects could follow your model of making a single source file that can then be compiled as-is. It seems that you ended up arguing in favour of splitting the file out and compiling only the parts you need, right? > What I wanted was a more streamlined, more compact, more portable, less > troublesome way of distributing self-contained applications. I wasn't > suggesting bundling the source to an entire OS with it! If the OS kernel can be considered an application (and in GNU Hurd, I believe it can), then there should be no reason for your claims to stop short of it. Unless they don't actually hold up for anything more than a trivial toy project. > I don't consider the CPython bundle that portable because it really demands > that it be built under Linux. There is (now) a grudging concession for > Windows, but that solution wasn't satisfactory when I tried it. Oh? Demands to be built under Linux? Where do you get that from? With the exception of some controller boards and such, Python is generally built on the target system, so the Mac builds are built on Macs, the Windows builds are built on Windows, the OS/2 builds are built on OS/2, and the snozberry builds taste like they were built on snozberries. > My links show extreme versions of what is possible. For much simple > applications, but they will still comprise 1% of the number of files that > would otherwise be required if I simply made available my sprawling working > setup like everyone else. > > (With Linux kernels, I don't know enough about them to provide realistic > answers. But 60,000 files seems a lot, for the same reason that 100,000 > files for a C compiler [gcc] seems a lot considering that some are MUCH > smaller. But then, both these projects are dwarfed by the apparent 1.5 > *million* files of the VS sources.) The thing is, that "sprawling working setup" is actually a well-designed system where each file has a purpose. (At least in theory. You might find some places where that's not actually happening, but it's always the intention.) If you were to lump everything into a fraction the number of files, you'd end up needing to divide sections in those files to help organize them. And that's what directories and files are for. We've had linkers since roughly the dawn of compilers, and they're not just to let people "sprawl". They're there to let people organize. Why are you so afraid of multiple source files? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
update python 3.4.2 to 3.4.6 on Windows X64
Hi, I am wondering how to update/install python 3.4.2 to 3.4.6 on Win X64 (Win 10), the PSF only provides tarballs for the 3.4.6 installation. cheers -- https://mail.python.org/mailman/listinfo/python-list
Re: update python 3.4.2 to 3.4.6 on Windows X64
On Mon, May 22, 2017 at 7:14 AM, Daiyue Weng wrote: > Hi, I am wondering how to update/install python 3.4.2 to 3.4.6 on Win X64 > (Win 10), the PSF only provides tarballs for the 3.4.6 installation. Do you actually need 3.4.6, or can you upgrade to 3.5 or 3.6? Full installers are available for the newer versions; the 3.4 branch is in its last phase of support, where installers aren't actually built. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: update python 3.4.2 to 3.4.6 on Windows X64
okay, I see, I will uninstall 3.4 and install 3.6. thanks On 21 May 2017 at 22:18, Chris Angelico wrote: > On Mon, May 22, 2017 at 7:14 AM, Daiyue Weng wrote: > > Hi, I am wondering how to update/install python 3.4.2 to 3.4.6 on Win X64 > > (Win 10), the PSF only provides tarballs for the 3.4.6 installation. > > Do you actually need 3.4.6, or can you upgrade to 3.5 or 3.6? Full > installers are available for the newer versions; the 3.4 branch is in > its last phase of support, where installers aren't actually built. > > ChrisA > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: update python 3.4.2 to 3.4.6 on Windows X64
On 2017-05-21 22:23, Daiyue Weng wrote: okay, I see, I will uninstall 3.4 and install 3.6. You don't have to uninstall 3.4 until you really don't need it, when you've fulling moved to the new version and you need the disk space; just don't install 3.6 into the same folder (they default to installing into different folders anyway, e.g. Python34 vs Python36). thanks On 21 May 2017 at 22:18, Chris Angelico wrote: On Mon, May 22, 2017 at 7:14 AM, Daiyue Weng wrote: > Hi, I am wondering how to update/install python 3.4.2 to 3.4.6 on Win X64 > (Win 10), the PSF only provides tarballs for the 3.4.6 installation. Do you actually need 3.4.6, or can you upgrade to 3.5 or 3.6? Full installers are available for the newer versions; the 3.4 branch is in its last phase of support, where installers aren't actually built. ChrisA -- https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: type hinting backward compatibility with python 3.0 to 3.4
bartc wrote: In fact the declaration of A might be in a different module from its use in a type hint, which means that, in the CPython byte-code compiler anyway, it is not visible at compile-time, when type hints could best be put to good effect. The static type checker would have to understand enough about imports to deal with that. Furthermore, both A, and the type-hinting code, might be conditional. So that on Tuesdays, A is a class, the rest of the week it's the name of a module. But that situation is hardly *static*, so you can't blame a static type checker for not coping with it. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: type hinting backward compatibility with python 3.0 to 3.4
Chris Angelico wrote: With mypy, if your classes are too dynamic, you might have to create a stub file that's more static (but non-functional) just for the type checking. Can you do that if your type checker is part of the language? I think you may have misunderstood. I'm not suggesting that the runtime interpreter should perform static type checking. I'm only suggesting that it should treat type annotations completely passively -- essentially as comments that are constrained to have the syntax of expressions. The type checking itself would still be done as a separate operation that can use stub files, etc. just the same as mypy does now. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: How to install Python package from source on Windows
Jussi Piitulainen wrote: I was surprised that Git (or GitHub Desktop) simply failed so badly. Not sure what it could have done instead. It's not really git's fault, it's a consequence of differing filename conventions on different platforms. The only way to avoid such problems is to refrain from using names like that in the first place, and for code that will only ever run on a Linux system, there's no motivation to do that. Even when you're trying to keep your filesnames cross-platform, it's hard to avoid slipping up sometimes. For example, MacOSX is so unix-like it's easy to forget that the file system is actually case-insensitive. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: I need help with making my claculator
First, you have to have a Tk instance before you do anything else. Take a look at this example, and then expand upon it to create the calculator http://python-textbok.readthedocs.io/en/1.0/Introduction_to_GUI_Programming.html -- https://mail.python.org/mailman/listinfo/python-list
Re: How to install Python package from source on Windows
bartc wrote: I don't consider the CPython bundle that portable because it really demands that it be built under Linux. There is (now) a grudging concession for Windows, but that solution wasn't satisfactory when I tried it. We already know that building Python from source on Windows is not easy, but nobody should *need* to do that unless they're actively working on developing Python itself. Binary packages are provided for everyone else. It's easy on Linux because unix was designed by programmers for programmers, and the whole environment and culture is built around "compile from source" being the usual way to *intall* as well as develop software. On Windows, in contrast, the usual way to install software is to use a binary package. Compiling from sources is an exotic activity done only by developers, and making it easy for non-developers is not a goal. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: How to install Python package from source on Windows
On 21/05/2017 21:46, Chris Angelico wrote: On Mon, May 22, 2017 at 5:32 AM, bartc wrote: Why are you so afraid of multiple source files? [When other people build your app from sources] Because then they are likely to need automation to deal with it. And that introduces an extra dependency. Coming from me, that wouldn't be an issue because I'm good at anticipating likely problems, having experienced so many myself with other people's apps, and will make it easy (for example by supplying just one file, or by specifying the steps in English). Others though are not usually so considerate. > If the OS kernel can be considered an application (and in GNU Hurd, I > believe it can), then there should be no reason for your claims to > stop short of it. Unless they don't actually hold up for anything more > than a trivial toy project. What are the criteria for a project to be considered a toy? Older versions of my languages were exclusively used to in the past to write all my software. I think I might have sold some £10m or so or of it, and that's not inflation adjusted. A very useful and productive toy! -- bartc -- https://mail.python.org/mailman/listinfo/python-list
Re: How to install Python package from source on Windows
On 22/05/2017 01:07, Gregory Ewing wrote: is not easy, but nobody should *need* to do that unless they're -- https://mail.python.org/mailman/listinfo/python-list
Re: How to install Python package from source on Windows
I think what Bart is saying is that the Python developers should provide an amalgamated source file that's pre-configured for Windows, so that someone who wants to compile on Windows doesn't have to deal with all the complexities of the general build system. While that might be possible, I don't see what how it would be of much use. You're not going to want to edit such a "source" file, so its only use would be to install as-is. But if that's all you want, you might as well use a binary installer. I suppose it would make it easier to experiment with using a different compiler, but even then you're probably going to have to make some changes to the source to get it to work, and hand-editing generated source is neither recommended nor fun. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: How to install Python package from source on Windows
On 22/05/2017 01:17, Gregory Ewing wrote: I think what Bart is saying is that the Python developers should provide an amalgamated source file that's pre-configured for Windows, so that someone who wants to compile on Windows doesn't have to deal with all the complexities of the general build system. The 'one-file' idea is one approach to simplifying the building of open-source applications. Probably, it's more suited to those who just want to try out, or use, a bit of software. (The GMP library, for example, has no official binary releases. You have to build from source, and I think it has an even longer configure script than CPython! The end-result is a single .dll file of a few hundred KB. Even if I could get a binary myself, if I make use of it as a dependency, anyone building my software would also have to acquire it and build it from source. And it might not work. Result: I don't use gmp.) For CPython, yes, the files are all over the place, but that wouldn't be so bad if at least it was possible to just compile them and link in the various bits. But all sorts of other things are going on, and that info is not provided. While that might be possible, I don't see what how it would be of much use. You're not going to want to edit such a "source" file, so its only use would be to install as-is. But if that's all you want, you might as well use a binary installer. A one-file CPython might be under 250Kloc, not too bad to play with, but I'm not sure it would work as there are multiple binary files to build, not a single executable. (Maybe one source per executable, but that would still need discrete, shared headers otherwise there would be duplication.) I think it would be on the cards to have a streamlined CPython distribution that only had a C compiler as a requirement, and nothing else. Unless I'm missing something. -- Bartc -- https://mail.python.org/mailman/listinfo/python-list
Scala considering significant indentation like Python
The creator of Scala, Martin Odersky, has proposed introducing Python-like significant indentation to Scala and getting rid of braces: I was playing for a while now with ways to make Scala's syntax indentation-based. I always admired the neatness of Python syntax and also found that F# has benefited greatly from its optional indentation-based syntax, so much so that nobody seems to use the original syntax anymore. https://github.com/lampepfl/dotty/issues/2491 -- Steve Emoji: a small, fuzzy, indistinct picture used to replace a clear and perfectly comprehensible word. -- https://mail.python.org/mailman/listinfo/python-list
Re: How to install Python package from source on Windows
Gregory Ewing writes: > Jussi Piitulainen wrote: >> I was surprised that Git (or GitHub Desktop) simply failed so badly. >> Not sure what it could have done instead. > > It's not really git's fault, it's a consequence of differing > filename conventions on different platforms. The only way to I understand that, but the way it failed was worse than I expected. -- https://mail.python.org/mailman/listinfo/python-list
Re: How to install Python package from source on Windows
bartc wrote: The 'one-file' idea is one approach to simplifying the building of open-source applications. Probably, it's more suited to those who just want to try out, or use, a bit of software. But on Windows, that use case is normally covered by installing a *binary*, not compiling from source. If the developer is in a position to supply a source distribution that's pre-configured to compile on Windows with no further effort, then it's only one small step for him to compile it himself and distribute the binary. (The GMP library, for example, has no official binary releases. You have to build from source, So using it on Windows isn't supported very well. This is in contrast to Python, for which a pretty comprehensive set of Windows binaries *is* available. A one-file CPython might be under 250Kloc, not too bad to play with, but I'm not sure it would work as there are multiple binary files to build, not a single executable. The number of files isn't really the issue. The point is that it wouldn't really be source in the sense of something human-editable. If you're not going to edit it, then it might as well be a binary. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: How to install Python package from source on Windows
On Mon, May 22, 2017 at 4:17 PM, Gregory Ewing wrote: >> (The GMP library, for example, has no official binary releases. You have >> to build from source, > > > So using it on Windows isn't supported very well. This is > in contrast to Python, for which a pretty comprehensive set > of Windows binaries *is* available. > It's more that people on Windows don't tend to "install GMP". They install program XYZ, which creates a window on the screen. The assumption is that it will include all the DLLs that it needs. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: I need help with making my claculator
woo...@gmail.com wrote: > First, you have to have a Tk instance before you do anything else. Take a > look at this example, and then expand upon it to create the calculator > http://python-textbok.readthedocs.io/en/1.0/Introduction_to_GUI_Programming.html While I agree that creating a Tk instance explicitly is preferable tkinter will create one if you don't: >>> import tkinter >>> tkinter._default_root is None True >>> frame = tkinter.Frame() >>> tkinter._default_root >>> frame.master is tkinter._default_root True -- https://mail.python.org/mailman/listinfo/python-list
