Re: Unable to run pip in Windows 10
On 10 October 2017 at 21:37, Michael Cuddehe wrote: > I have tried multiple versions, 32 & 64 bit. Same problem. > > "This app can't run on your PC. To find a version for your PC, check with > the software publisher." It's difficult to know what to say - it runs fine for me (Windows 10, Python 3.6, 64-bit, downloaded from python.org). Maybe check that the file you downloaded is complete, by confirming the size/checksum matches? Do you have any antivirus software that could be interfering? Paul -- https://mail.python.org/mailman/listinfo/python-list
Re: about 'setattr(o, name, value)' and 'inspect.signature(f)'
Agreed. I was being lazy and didn't check precisely which exception was raised before writing the code. "Making this code production ready is left as an exercise for the reader" :-) On 11 October 2017 at 01:59, Steve D'Aprano wrote: > On Wed, 11 Oct 2017 02:15 am, Paul Moore wrote: > >> These are all run-time behaviours, and so there's no way you can check >> for them ahead of time. If you want to be sure setattr is allowed, you >> need to handle possible exceptions: >> >> try: >> setattr(o, name, value) >> except Exception: >> # deal with the problem > > > I would say that you should only catch AttributeError here. Anything else is, > in my opinion, a bug in the object o that needs to be spotted and fixed. > > Even catching AttributeError is a bit... suspicious. Why exactly are we trying > to attach attributes to arbitrary objects like None or "Hello World"? > > But certainly if you get something like UnicodeDecodeError or ImportError from > trying to set an attribute, that's a bug in o.__setattr__ that needs fixing. > > > -- > Steve > “Cheer up,” they said, “things could be worse.” So I cheered up, and sure > enough, things got worse. > > -- > https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: Lies in education [was Re: The "loop and a half"]
On 2017-10-10 13:09, Bill wrote: > (at least based upon "The C++ Programming Language", 3rd ed.) My impression when I read "The C++ Programming Language" as a teenager (many years ago) was that the 1st edition was an excellent, if somewhat dense book, while the 3rd edition was completely impenetrable without first having read the 1st edition. -- Thomas Jollans -- https://mail.python.org/mailman/listinfo/python-list
Re: Unable to run pip in Windows 10
On 2017-10-10 22:37, Michael Cuddehe wrote: > I have tried multiple versions, 32 & 64 bit. Same problem. > > "This app can't run on your PC. To find a version for your PC, check with > the software publisher." > You're going to have to give us some more information for anybody to be able to really help you here. We just don't know what's going on. - What exactly did you install? - Can you start the Python interpreter? * How exactly did you go about this - How exactly do you try to run pip? - What exactly happens when you try? You quoted an error message, and that's great. What's missing is really any information on how you GOT this error message. -- Thomas Jollans -- https://mail.python.org/mailman/listinfo/python-list
Solved (Was: Re: [Q] days -> months)
Oh never mind it, after so many trial and error, i did make months format with success, thanks!!! Sincerely, Byung-Hee. -- ^고맙습니다 _救濟蒼生_ 감사합니다_^))// -- https://mail.python.org/mailman/listinfo/python-list
Re: Lies in education [was Re: The "loop and a half"]
On 11/10/17 01:48, Bill wrote: Steve D'Aprano wrote: On Tue, 10 Oct 2017 06:06 am, Stefan Ram wrote: In his book about programming, Bjarne Stroustrup writes: |We try hard to avoid "white lies"; that is, we refrain from |oversimplified explanations that are clear and easy to |understand, but not true in the context of real languages and |real problems. Bjarne Stroustrup is famous for designing one of the most heavyweight, baraque, hard-to-understand, difficult-to-use programming languages in common use. While C++ has many excellent features, and is constrained by the need to be compatible with C, I don't think many people believe that it is a well-designed language. It is a well-designed language. It is and was carefully thought out. I was manfully trying not to head off on another OT trail, but this is simply not true. C++ is designed, true, but well designed? It has a fundamental flaw; it wants to be both a high-level language and compatible with C, under the mistaken impression that C is a high level language. Since C is actually an excellent macro-assembler, this dooms the exercise from the very start. C++ lives in the no-man's land between programming languages that care quite a lot what processor they are running on and programming languages that wouldn't recognise hardware if it came up and bit them. It can be used either way, but comes with all the baggage for both. I am yet to see a C++ program that wasn't more comprehensible when rendered as either C or Python (or the high-level language of your choice, I imagine). -- Rhodri James *-* Kynesim Ltd -- https://mail.python.org/mailman/listinfo/python-list
Re: Lies in education [was Re: The "loop and a half"]
Rhodri James : > C++ is designed, true, but well designed? It has a fundamental flaw; > it wants to be both a high-level language and compatible with C, under > the mistaken impression that C is a high level language. Since C is > actually an excellent macro-assembler, this dooms the exercise from > the very start. C++ was never compatible with C, any more than Peter Jackson's Hobbit movies were a rendition of JRR Tolkien's "Hobbit, or There and Back Again." Objective C, by contrast, was designed to be compatible with C. That's why its syntax looks so weird. > C++ lives in the no-man's land between programming languages that care > quite a lot what processor they are running on and programming > languages that wouldn't recognise hardware if it came up and bit them. C is the traditional application programming language in the Unix family. It doesn't see any hardware. It only sees function libraries and virtual memory. (Exception: recent memory barrier semantics in C force every C and C++ programmer to be acutely aware of multicore RAM cache behavior the moment you start doing multithreading or multiprocessing. To me, this looks more like a bug than a feature in the languages.) > It can be used either way, but comes with all the baggage for both. I > am yet to see a C++ program that wasn't more comprehensible when > rendered as either C or Python (or the high-level language of your > choice, I imagine). I agree. C++'s main problem is that it tries to solve the wrong problem. A C++ compiler seeks to make sure your program doesn't have bugs. That noble (but futile) goal makes it painful to program in C++. Python and C don't try to protect you. In return, you get syntactic convenience that probably enhances the quality of your programs. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Lies in education [was Re: The "loop and a half"]
On 2017-10-11, Bill wrote: > [...] I'm not here to "cast stones", I like Python. I just think > that you shouldn't cast stones at C/C++. Not while PHP exists. There aren't enough stones in the world... -- Grant Edwards grant.b.edwardsYow! Is it 1974? What's at for SUPPER? Can I spend gmail.commy COLLEGE FUND in one wild afternoon?? -- https://mail.python.org/mailman/listinfo/python-list
Re: Lies in education [was Re: The "loop and a half"]
On Thu, Oct 12, 2017 at 12:16 AM, Marko Rauhamaa wrote: > Rhodri James : > >> C++ is designed, true, but well designed? It has a fundamental flaw; >> it wants to be both a high-level language and compatible with C, under >> the mistaken impression that C is a high level language. Since C is >> actually an excellent macro-assembler, this dooms the exercise from >> the very start. > > C++ was never compatible with C, any more than Peter Jackson's Hobbit > movies were a rendition of JRR Tolkien's "Hobbit, or There and Back > Again." The places where C++ is not a superset of C are mostly things you wouldn't want to be doing anyway. You can generally take C code and compile it with a C++ compiler, and it'll have the same semantics. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Lies in education [was Re: The "loop and a half"]
On 11/10/2017 14:16, Marko Rauhamaa wrote: C++'s main problem is that it tries to solve the wrong problem. A C++ compiler seeks to make sure your program doesn't have bugs. That noble (but futile) goal makes it painful to program in C++. It's painful to program for lots of reasons, I don't think that is the main one. The ideas behind C++'s many features individually make perfectly good sense - on paper. Until you look at ghastly examples of C++ source code and it really hurts your eyes. Python and C don't try to protect you. In return, you get syntactic convenience that probably enhances the quality of your programs. Python, maybe. C syntax isn't as painful as C++ but I still have a lot of trouble with it. (Eg. the variable declaration 'char(*(*x[3])())[5]'. The name of the variable can be found lurking in that lot somewhere, but what's the type?) Not so convenient. -- bartc -- https://mail.python.org/mailman/listinfo/python-list
Re: Lies in education [was Re: The "loop and a half"]
On Thu, Oct 12, 2017 at 1:14 AM, bartc wrote: > Python, maybe. C syntax isn't as painful as C++ but I still have a lot of > trouble with it. (Eg. the variable declaration 'char(*(*x[3])())[5]'. The > name of the variable can be found lurking in that lot somewhere, but what's > the type?) Not so convenient. People love showcasing stupid examples like that. But how often do you REALLY make declarations that complex? That's not technically strawmanning, since C syntax does indeed include that, but you're cherry-picking the most extreme example. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
RE: Unable to run pip in Windows 10
- What exactly did you install? >> Latest install: Python 3.5.4 (v3.5.4:3f56838, Aug 8 2017, 02:17:05) [MSC v.1900 64 bit (AMD64)] on win32 >> Downloaded from python.org. - Can you start the Python interpreter? >> Yes...works fine. * How exactly did you go about this >> ?? - How exactly do you try to run pip? >> Command prompt: c:\Users\FFC>pip import (module) >> - What exactly happens when you try? >> Windows error message: "This app can't run on your PC" -Original Message- From: Python-list [mailto:python-list-bounces+mcuddehe=strategicga@python.org] On Behalf Of Thomas Jollans Sent: Wednesday, October 11, 2017 3:30 AM To: python-list@python.org Subject: Re: Unable to run pip in Windows 10 On 2017-10-10 22:37, Michael Cuddehe wrote: > I have tried multiple versions, 32 & 64 bit. Same problem. > > "This app can't run on your PC. To find a version for your PC, check > with the software publisher." > You're going to have to give us some more information for anybody to be able to really help you here. We just don't know what's going on. - What exactly did you install? - Can you start the Python interpreter? * How exactly did you go about this - How exactly do you try to run pip? - What exactly happens when you try? You quoted an error message, and that's great. What's missing is really any information on how you GOT this error message. -- Thomas Jollans -- https://mail.python.org/mailman/listinfo/python-list --- This email has been checked for viruses by AVG. http://www.avg.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Unable to run pip in Windows 10
On 11 October 2017 at 15:46, Michael Cuddehe wrote: > - What exactly did you install? >>> Latest install: Python 3.5.4 (v3.5.4:3f56838, Aug 8 2017, 02:17:05) [MSC > v.1900 64 bit (AMD64)] on win32 >>> Downloaded from python.org. > - Can you start the Python interpreter? >>> Yes...works fine. >* How exactly did you go about this >>> ?? > - How exactly do you try to run pip? >>> Command prompt: c:\Users\FFC>pip import (module) >>> > - What exactly happens when you try? >>> Windows error message: "This app can't run on your PC" There's no "pip import" command - I guess you meant "pip install"? Rather than transcribing what you did, can you include a copy and paste of the actual text in your command window? I also googled for the message you quoted, and I see that it's a Windows message (not one from pip or Python). The most obvious suggestion from that was "you're running a 64-bit application on a 32-bit Windows". I note from the above: > Latest install: Python 3.5.4 (v3.5.4:3f56838, Aug 8 2017, 02:17:05) [MSC > v.1900 64 bit (AMD64)] Are you running 32-bit Windows? If so, you got the wrong version of Python (you need the 32-bit version). Paul -- https://mail.python.org/mailman/listinfo/python-list
Re: Lies in education [was Re: The "loop and a half"]
Chris Angelico :
> The places where C++ is not a superset of C are mostly things you
> wouldn't want to be doing anyway. You can generally take C code and
> compile it with a C++ compiler, and it'll have the same semantics.
Here's a C/C++ program:
#include
int main()
{
struct {} s;
printf("%d\n", (int) sizeof 'a');
printf("%d\n", (int) sizeof s);
return 0;
}
When compiled (with gcc) as a C program, the output is:
4
0
When the same program is compiled (with gcc) as a C++ program, the
output is:
1
1
That is not immediately all that significant but points to subtle
incompatibilities between the data models of C and C++.
Then we have syntactic problems:
int main()
{
void *s = "hello";
char *t = s;
return 0;
}
which, as a C program, makes gcc perfectly happy, but a C++ compilation
complains:
test.C: In function ‘int main()’:
test.C:5:15: error: invalid conversion from ‘const void*’ to ‘void*’ \
[-fpermissive]
void *s = "hello";
^~~
test.C:6:15: error: invalid conversion from ‘void*’ to ‘char*’ [-fper\
missive]
char *t = s;
^
(The first one should trigger an error message even in C compilation,
but string literals were standardized to be "semiconstant" in C.)
Marko
--
https://mail.python.org/mailman/listinfo/python-list
Re: Lies in education [was Re: The "loop and a half"]
On 2017-10-11, Marko Rauhamaa wrote: > Bill : >> Steve D'Aprano wrote: >>> Bjarne Stroustrup is famous for designing one of the most >>> heavyweight, baraque, hard-to-understand, difficult-to-use >>> programming languages in common use. While C++ has many excellent >>> features, and is constrained by the need to be compatible with C, I >>> don't think many people believe that it is a well-designed language. >> >> It is a well-designed language. It is and was carefully >> thought out. One could argue that there are perhaps "too many >> ways" to do a given thing in Python (one could say it's >> features are "not orthogonal"). I'm sure you are familiar with >> where the language drew its name. I'm not here to "cast >> stones", I like Python. I just think that you shouldn't cast >> stones at C/C++. > > One is allowed to have opinions and express them. We are not talking > about religion here. > > I don't like everything in Python. On the whole, though, it is an > excellent language. In practice, it is the best available tool for most > programming needs I face. > > There are situations where C++ is suitable. Its primary > advantage over C is the automatic generation of the virtual > table. However, having programmed in C++ for a decade or so, it > has left a bad taste in my mouth. Its core philosophy (ie, do > the utmost at compile time) is cumbersome and misplaced. Until > very recently, C++ didn't offer a good way to implement > callback functions, for example. Some other cool stuff in C++ and how it relates to a Python features as I understand them: Support for Resource Acquisition is Initialization (RAII) with constructors and destructors is a big advantage. Python's got this now, too, with with. C++'s big idea of allowing you to define you own data types and make them work precisely as you wish is a great idea, only it's too bad it requires such experience and skill to get it right. Python provides a similar feature with dynamic typing, though the urge to implement my own type that acts just like one of the built-in types hardly ever comes to me in Python, thanks to its fabulous standard library, which regularly uses these features. C++ compile-time polymorphism using templates is awesome and vital, but unfortunately (or fortunately?) abusable for compile-time data processing and foster-parent of horrid compiler error message bloat. Run-time polymorphism using inheritance is a feature that in both Python and C++ is easy to overcomplicate with the multiple inheritance feature. Alternatives are almost always preferable. Some people also appreciate C++'s improvements upon C's type sytem enough to compile all their C programs with C++. I dig const qualifiers, even though I'm comletely fine with their absence from Python. I'd use C++ for stuff--but Python is perfect for my needs, meanwhile the advantages I'd get from using C++ wouldn't be relevant to my work. If I ever need to write a device driver I'm really screwed. -- Neil Cerutti -- https://mail.python.org/mailman/listinfo/python-list
Re: Lies in education [was Re: The "loop and a half"]
On 11/10/2017 15:52, breamore...@gmail.com wrote: On Wednesday, October 11, 2017 at 3:14:51 PM UTC+1, bartc wrote: On 11/10/2017 14:16, Marko Rauhamaa wrote: Python and C don't try to protect you. In return, you get syntactic convenience that probably enhances the quality of your programs. Python, maybe. C syntax isn't as painful as C++ but I still have a lot of trouble with it. (Eg. the variable declaration 'char(*(*x[3])())[5]'. The name of the variable can be found lurking in that lot somewhere, but what's the type?) Not so convenient. https://cdecl.org/ tells me that your variable declaration is a syntax error so maybe not much of an example. Perhaps you didn't write or paste it properly. The site tells me that: char(*(*x[3])())[5] (with or without a trailing semicolon) means: declare x as array 3 of pointer to function returning pointer to array 5 of char (Example taken from page 122 of the C book "K&R2", in a section about writing a program to make sense of complex declarations.) Anyway that fact you either tripped up on typing it, or that you had to use a special tool to find out what it meant, sort of reinforces my point... -- bartc -- https://mail.python.org/mailman/listinfo/python-list
Re: Unable to run pip in Windows 10
"Access is denied" sounds like you've installed Python for all users (i.e. in C:\Program Files) and you're not using an elevated prompt to run pip. If you have Python in C:\Program Files, you either need to install modules in your user environment (via pip install --user) which means they'll only be visible to you, or you need to be running as a system administrator to install them for anyone (which means running pip from a command prompt that was opened via "run as administrator") Paul On 11 October 2017 at 16:43, Michael Cuddehe wrote: > Running 64 bit Windows 10. > Re-installed Python 3.6.3 - Download Windows x86-64 web-based installer. Same > problem. > Screen capture attached. > > > -Original Message- > From: Paul Moore [mailto:p.f.mo...@gmail.com] > Sent: Wednesday, October 11, 2017 10:10 AM > To: Michael Cuddehe > Cc: Thomas Jollans; python-list@python.org > Subject: Re: Unable to run pip in Windows 10 > > On 11 October 2017 at 15:46, Michael Cuddehe wrote: >> - What exactly did you install? Latest install: Python 3.5.4 (v3.5.4:3f56838, Aug 8 2017, 02:17:05) [MSC >> v.1900 64 bit (AMD64)] on win32 Downloaded from python.org. >> - Can you start the Python interpreter? Yes...works fine. >>* How exactly did you go about this ?? >> - How exactly do you try to run pip? Command prompt: c:\Users\FFC>pip import (module) >> - What exactly happens when you try? Windows error message: "This app can't run on your PC" > > There's no "pip import" command - I guess you meant "pip install"? > > Rather than transcribing what you did, can you include a copy and paste of > the actual text in your command window? > > I also googled for the message you quoted, and I see that it's a Windows > message (not one from pip or Python). The most obvious suggestion from that > was "you're running a 64-bit application on a 32-bit Windows". I note from > the above: > >> Latest install: Python 3.5.4 (v3.5.4:3f56838, Aug 8 2017, 02:17:05) >> [MSC >> v.1900 64 bit (AMD64)] > > Are you running 32-bit Windows? If so, you got the wrong version of Python > (you need the 32-bit version). > Paul > > > --- > This email has been checked for viruses by AVG. > http://www.avg.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Unable to run pip in Windows 10
On 10/11/2017 08:46 AM, Michael Cuddehe wrote: > - What exactly did you install? >>> Latest install: Python 3.5.4 (v3.5.4:3f56838, Aug 8 2017, 02:17:05) [MSC > v.1900 64 bit (AMD64)] on win32 ^^^ So your OS is 32 bit? If so, you can't run 64-bit software on it. This v.1900 was downloaded from python.org? Or is it from a different web site? -- https://mail.python.org/mailman/listinfo/python-list
Re: Lies in education [was Re: The "loop and a half"]
On 11/10/2017 15:36, Chris Angelico wrote: On Thu, Oct 12, 2017 at 1:14 AM, bartc wrote: Python, maybe. C syntax isn't as painful as C++ but I still have a lot of trouble with it. (Eg. the variable declaration 'char(*(*x[3])())[5]'. The name of the variable can be found lurking in that lot somewhere, but what's the type?) Not so convenient. People love showcasing stupid examples like that. But how often do you REALLY make declarations that complex? That's not technically strawmanning, since C syntax does indeed include that, but you're cherry-picking the most extreme example. Sure. Statistically most declarations are going to be things like 'int' or 'char*. But more complicated ones (usually not as bad as the example), crop up often enough to be a nuisance. I may see them more than others because I very often need to interface one of my languages with some API defined in C, and I need to exactly understand what the types are so that I can create compatible ones. Anyone else can just include the apposite headers and be done with it without needing to see what's inside. While on the subject of C syntax, here are some fun ambiguities: f(x);// call function with arg x, or declare x of type f? a*b; // multiply a by b, or declare b of type pointer to a? (a)*b// multiply a by b, or cast *b to type a? I understand that in C++, you also have things like this, but in spades. -- bartc -- https://mail.python.org/mailman/listinfo/python-list
Re: Lies in education [was Re: The "loop and a half"]
Grant Edwards wrote: On 2017-10-11, Bill wrote: [...] I'm not here to "cast stones", I like Python. I just think that you shouldn't cast stones at C/C++. Not while PHP exists. There aren't enough stones in the world... PHP seems (seemed?) popular for laying out web pages. Are their vastly superior options? I'm a little naive in this matter, thus my question. -- https://mail.python.org/mailman/listinfo/python-list
Lies in education [was Re: The "loop and a half"]
> >> [...] I'm not here to "cast stones", I like Python. I just think > >> that you shouldn't cast stones at C/C++. > > Not while PHP exists. There aren't enough stones in the world... > > > > PHP seems (seemed?) popular for laying out web pages. Are their vastly > superior options? Python? Superior syntax for sure -- https://mail.python.org/mailman/listinfo/python-list
Re: Lies in education [was Re: The "loop and a half"]
On Thu, Oct 12, 2017 at 2:43 AM, Marko Rauhamaa wrote:
> Chris Angelico :
>
>> The places where C++ is not a superset of C are mostly things you
>> wouldn't want to be doing anyway. You can generally take C code and
>> compile it with a C++ compiler, and it'll have the same semantics.
>
> Here's a C/C++ program:
>
>
> #include
>
> int main()
> {
> struct {} s;
> printf("%d\n", (int) sizeof 'a');
> printf("%d\n", (int) sizeof s);
> return 0;
> }
>
>
> When compiled (with gcc) as a C program, the output is:
>
> 4
> 0
>
> When the same program is compiled (with gcc) as a C++ program, the
> output is:
>
> 1
> 1
>
> That is not immediately all that significant but points to subtle
> incompatibilities between the data models of C and C++.
Indeed - their handling of empty structs is different. But that
doesn't invalidate my point; how often do you declare a variable that
has nothing in it? Remember, a Python object with no attributes still
has an identity, a type, and so on; in C, data has no type or
identity, so this truly has no data attributes. This is legal but
extremely esoteric, and the difference in sizeof is less about an
incompatible data model and more about the definition of an empty
struct.
> Then we have syntactic problems:
>
>
> int main()
> {
> void *s = "hello";
> char *t = s;
> return 0;
> }
>
>
> which, as a C program, makes gcc perfectly happy, but a C++ compilation
> complains:
>
>test.C: In function ‘int main()’:
>test.C:5:15: error: invalid conversion from ‘const void*’ to ‘void*’ \
>[-fpermissive]
> void *s = "hello";
> ^~~
>test.C:6:15: error: invalid conversion from ‘void*’ to ‘char*’ [-fper\
>missive]
> char *t = s;
> ^
>
> (The first one should trigger an error message even in C compilation,
> but string literals were standardized to be "semiconstant" in C.)
Also something you should not be using. For hysterical raisins,
certain things in C are legal-yet-highly-inadvisable, and one of them
is putting string literals into non-const pointers. (C didn't
originally even _have_ const.) You'll probably find that some
compilers give a warning (at least if -Wall is active), but even if
not, you shouldn't be doing this.
So I stand by my original statement. Yes, there are incompatibilities,
but it's easy enough to write code that's compatible with both. Hmm,
something tells me I've heard this sort of thing before...
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: Unable to run pip in Windows 10
On 10/11/2017 11:54 AM, Michael Torrie wrote: On 10/11/2017 08:46 AM, Michael Cuddehe wrote: - What exactly did you install? Latest install: Python 3.5.4 (v3.5.4:3f56838, Aug 8 2017, 02:17:05) [MSC v.1900 64 bit (AMD64)] on win32 ^^^ This is exactly what I see from 64 bit python installed on 64 bit Windows. 'win32' refers to the Windows platform, versus linux, unix, darwin, etc. Yes, it is confusing. So your OS is 32 bit? The next line says that this binary runs fine. So 'No'. The problem is specific to trying to run pip. This v.1900 was downloaded from python.org? MSC v.1900 is the latest Microsoft C compiler, which was used to compile the binary. It is not downloaded. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Unable to run pip in Windows 10
On 10/11/2017 10:46 AM, Michael Cuddehe wrote: - What exactly did you install? Latest install: Python 3.5.4 (v3.5.4:3f56838, Aug 8 2017, 02:17:05) [MSC v.1900 64 bit (AMD64)] on win32 Downloaded from python.org. - Can you start the Python interpreter? Yes...works fine. * How exactly did you go about this ?? - How exactly do you try to run pip? Command prompt: c:\Users\FFC>pip import (module) Try running instead ...> python -m pip install or to specifically ensure that you run 3.5, ...> py -3.5 -m pip install and if that fails, copy the entire response. - What exactly happens when you try? Windows error message: "This app can't run on your PC" -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Lies in education [was Re: The "loop and a half"]
On 2017-10-11, bartc wrote: > On 11/10/2017 15:36, Chris Angelico wrote: >> On Thu, Oct 12, 2017 at 1:14 AM, bartc wrote: >>> Python, maybe. C syntax isn't as painful as C++ but I still have a lot of >>> trouble with it. (Eg. the variable declaration 'char(*(*x[3])())[5]'. The >>> name of the variable can be found lurking in that lot somewhere, but what's >>> the type?) Not so convenient. >> >> People love showcasing stupid examples like that. But how often do you >> REALLY make declarations that complex? That's not technically >> strawmanning, since C syntax does indeed include that, but you're >> cherry-picking the most extreme example. > > Sure. Statistically most declarations are going to be things like 'int' > or 'char*. But more complicated ones (usually not as bad as the > example), crop up often enough to be a nuisance. The easiest way to make stuff like that readable is to unroll them into a sequence of typedefs. But, a lot of people never really learn how to do that... -- Grant Edwards grant.b.edwardsYow! ... I don't like FRANK at SINATRA or his CHILDREN. gmail.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Lies in education [was Re: The "loop and a half"]
On Wed, 2017-10-11 at 15:14 +0100, bartc wrote: > On 11/10/2017 14:16, Marko Rauhamaa wrote: > > Python and C don't try to protect you. In return, you get syntactic > > convenience that probably enhances the quality of your programs. > > Python, maybe. C syntax isn't as painful as C++ but I still have a lot > of trouble with it. (Eg. the variable declaration 'char(*(*x[3])())[5]'. > The name of the variable can be found lurking in that lot somewhere, but > what's the type?) Not so convenient. I believe the type of any variable in C is the same as its declaration, but with the variable name deleted. So: char (*(*[3])())[5] That is, an array of 3 pointers to functions that return pointers to arrays of 5 characters. Jonathan -- https://mail.python.org/mailman/listinfo/python-list
Re: Lies in education [was Re: The "loop and a half"]
On Wednesday, October 11, 2017 at 3:14:51 PM UTC+1, bartc wrote: > On 11/10/2017 14:16, Marko Rauhamaa wrote: > > > Python and C don't try to protect you. In return, you get syntactic > > convenience that probably enhances the quality of your programs. > > Python, maybe. C syntax isn't as painful as C++ but I still have a lot > of trouble with it. (Eg. the variable declaration 'char(*(*x[3])())[5]'. > The name of the variable can be found lurking in that lot somewhere, but > what's the type?) Not so convenient. > > -- > bartc https://cdecl.org/ tells me that your variable declaration is a syntax error so maybe not much of an example. -- Kindest regards. Mark Lawrence. -- https://mail.python.org/mailman/listinfo/python-list
Re: Lies in education [was Re: The "loop and a half"]
On 2017-10-11, Bill wrote: > Grant Edwards wrote: >> On 2017-10-11, Bill wrote: >> >> >>> [...] I'm not here to "cast stones", I like Python. I just think >>> that you shouldn't cast stones at C/C++. >> Not while PHP exists. There aren't enough stones in the world... >> > > PHP seems (seemed?) popular for laying out web pages. It's not really used for "laying out" web pages. Thats what HTML and CSS do. PHP is for server-side generation of dynamic content and handling of submitted forms and uploaded data. > Are their vastly superior options? Yes: Python. There are other choices that while superior to PHP aren't as good as Python. :) > I'm a little naive in this matter, thus my question. -- Grant Edwards grant.b.edwardsYow! Those people look at exactly like Donnie and gmail.comMarie Osmond!! -- https://mail.python.org/mailman/listinfo/python-list
Re: Lies in education [was Re: The "loop and a half"]
On Thu, Oct 12, 2017 at 5:22 AM, Grant Edwards wrote: > On 2017-10-11, bartc wrote: >> On 11/10/2017 15:36, Chris Angelico wrote: >>> On Thu, Oct 12, 2017 at 1:14 AM, bartc wrote: Python, maybe. C syntax isn't as painful as C++ but I still have a lot of trouble with it. (Eg. the variable declaration 'char(*(*x[3])())[5]'. The name of the variable can be found lurking in that lot somewhere, but what's the type?) Not so convenient. >>> >>> People love showcasing stupid examples like that. But how often do you >>> REALLY make declarations that complex? That's not technically >>> strawmanning, since C syntax does indeed include that, but you're >>> cherry-picking the most extreme example. >> >> Sure. Statistically most declarations are going to be things like 'int' >> or 'char*. But more complicated ones (usually not as bad as the >> example), crop up often enough to be a nuisance. > > The easiest way to make stuff like that readable is to unroll them > into a sequence of typedefs. But, a lot of people never really > learn how to do that... The most complexity you'll usually see is a function that accepts/returns a pointer, and those generally should be typedef'd. But even if not, they're still not anything like as bad as the mythical examples that get touted as "why C is bad" or "why variable declarations are bad" or "why type declarations are bad". ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Lies in education [was Re: The "loop and a half"]
Chris Angelico :
> On Thu, Oct 12, 2017 at 2:43 AM, Marko Rauhamaa wrote:
>> That is not immediately all that significant but points to subtle
>> incompatibilities between the data models of C and C++.
>
> Indeed - their handling of empty structs is different. But that
> doesn't invalidate my point; how often do you declare a variable that
> has nothing in it?
In my case, this particular problem caused a bug once some years back.
> Remember, a Python object with no attributes still
> has an identity, a type, and so on; in C, data has no type or
> identity, so this truly has no data attributes. This is legal but
> extremely esoteric, and the difference in sizeof is less about an
> incompatible data model and more about the definition of an empty
> struct.
Here's a tiny example from the Linux kernel:
struct snd_ac97_build_ops {
int (*build_3d) (struct snd_ac97 *ac97);
int (*build_specific) (struct snd_ac97 *ac97);
int (*build_spdif) (struct snd_ac97 *ac97);
int (*build_post_spdif) (struct snd_ac97 *ac97);
#ifdef CONFIG_PM
void (*suspend) (struct snd_ac97 *ac97);
void (*resume) (struct snd_ac97 *ac97);
#endif
void (*update_jacks) (struct snd_ac97 *ac97); /* for jack-sharing */
};
Such #ifdef'ed structures abound in the Linux kernel. We had a similar
situation with the *whole* structure consisting of #ifdef'ed segments. I
had naively assumed that word alignment was preserved regardless of the
preprocessing conditions.
> So I stand by my original statement. Yes, there are incompatibilities,
> but it's easy enough to write code that's compatible with both. Hmm,
> something tells me I've heard this sort of thing before...
Python++ FTW?
Marko
--
https://mail.python.org/mailman/listinfo/python-list
Re: Lies in education [was Re: The "loop and a half"]
On Thu, Oct 12, 2017 at 5:35 AM, Marko Rauhamaa wrote: > Chris Angelico : > >> On Thu, Oct 12, 2017 at 2:43 AM, Marko Rauhamaa wrote: >>> That is not immediately all that significant but points to subtle >>> incompatibilities between the data models of C and C++. >> >> Indeed - their handling of empty structs is different. But that >> doesn't invalidate my point; how often do you declare a variable that >> has nothing in it? > > In my case, this particular problem caused a bug once some years back. Once. Probably in your entire career. In my case, never, and I spent about fifteen years of my life writing mostly either C or C++ code. This is NOT common. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Lies in education [was Re: The "loop and a half"]
On 11/10/17 15:36, Chris Angelico wrote: On Thu, Oct 12, 2017 at 1:14 AM, bartc wrote: Python, maybe. C syntax isn't as painful as C++ but I still have a lot of trouble with it. (Eg. the variable declaration 'char(*(*x[3])())[5]'. The name of the variable can be found lurking in that lot somewhere, but what's the type?) Not so convenient. People love showcasing stupid examples like that. But how often do you REALLY make declarations that complex? That's not technically strawmanning, since C syntax does indeed include that, but you're cherry-picking the most extreme example. That's only really one level more complex than declarations I use fairly regularly (I am an embedded system programmer most of the time). On the other hand, I never actually do declare things in that way: typedef is your friend, and makes your C code much easier to read. -- Rhodri James *-* Kynesim Ltd -- https://mail.python.org/mailman/listinfo/python-list
Re: Lies in education [was Re: The "loop and a half"]
On 11/10/2017 17:16, Jonathan Cast wrote: On Wed, 2017-10-11 at 15:14 +0100, bartc wrote: On 11/10/2017 14:16, Marko Rauhamaa wrote: Python and C don't try to protect you. In return, you get syntactic convenience that probably enhances the quality of your programs. Python, maybe. C syntax isn't as painful as C++ but I still have a lot of trouble with it. (Eg. the variable declaration 'char(*(*x[3])())[5]'. The name of the variable can be found lurking in that lot somewhere, but what's the type?) Not so convenient. I believe the type of any variable in C is the same as its declaration, but with the variable name deleted. Yes, I think we got that... So: char (*(*[3])())[5] ..which doesn't help, and in fact makes things worse, as now you don't have a start point at which to start unravelling it. You have to do it from the inside out. That is, an array of 3 pointers to functions that return pointers to arrays of 5 characters. But you left out the dozen steps needed to get from that to this! Anyway if such a type can be more clearly expressed like this, why doesn't a language simply allow that, or near enough? Why does it need to be cryptic, or require an external tool to encode and decode (there is a reason that CDECL exists) or require the programmer to apply an algorithm? -- bartc -- https://mail.python.org/mailman/listinfo/python-list
Re: Lies in education [was Re: The "loop and a half"]
On Thu, Oct 12, 2017 at 3:29 AM, Rhodri James wrote: > On 11/10/17 15:36, Chris Angelico wrote: >> >> On Thu, Oct 12, 2017 at 1:14 AM, bartc wrote: >>> >>> Python, maybe. C syntax isn't as painful as C++ but I still have a lot of >>> trouble with it. (Eg. the variable declaration 'char(*(*x[3])())[5]'. The >>> name of the variable can be found lurking in that lot somewhere, but >>> what's >>> the type?) Not so convenient. >> >> >> People love showcasing stupid examples like that. But how often do you >> REALLY make declarations that complex? That's not technically >> strawmanning, since C syntax does indeed include that, but you're >> cherry-picking the most extreme example. > > > That's only really one level more complex than declarations I use fairly > regularly (I am an embedded system programmer most of the time). On the > other hand, I never actually do declare things in that way: typedef is your > friend, and makes your C code much easier to read. I wouldn't consider embedded systems to be the most common kind of C coding out there, particularly when people compare against C++ (I don't remember ever hearing of anyone doing embedded work in C++, though I'm sure it does happen). Nevertheless, you're exactly right about the typedefs. Writing crazily complicated type declarations without typedefs is like writing massively nested list comprehensions without intermediate variables. Hey look, Python's terrible! Or maybe they're just non-idiomatic examples. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Lies in education [was Re: The "loop and a half"]
On 11/10/2017 19:30, Chris Angelico wrote: On Thu, Oct 12, 2017 at 5:22 AM, Grant Edwards The easiest way to make stuff like that readable is to unroll them into a sequence of typedefs. But, a lot of people never really learn how to do that... The most complexity you'll usually see is a function that accepts/returns a pointer, and those generally should be typedef'd. But even if not, they're still not anything like as bad as the mythical examples that get touted as "why C is bad" or "why variable declarations are bad" or "why type declarations are bad". IME typedefs can make things worse, especially if used even for basic types. Then you spend your time tracing back typedefs to see what they mean (was it a char, or struct or what?). C can combine the abstruseness of its type declarations, overuse of macros, and overuse of #if/ifdef blocks to render a lot of code a complete nightmare to try and understand. Or debug. Or maintain. Or port. Or implement (if testing a compiler). I've looked at some of my generated C code, and here's one common example, not a complex type: tokenrec * (*)[] But I couldn't figure that out from the top of my head. Bear in mind this was in a parameter list that can change the meaning of []. I looked at the original source and that type is written like this: ref [] ref tokenrec 'ref' means 'pointer to', and it can also be written like this: pointer [] pointer tokenrec In English, 'pointer to array of pointer to tokenrec'. See how the source language corresponds almost exactly to the English, and both are written left to right. Now go back and look at the C version - where do you even start? Are those parentheses significant? (I've no idea.) The most complex of /my/ types to appear in generated C is probably this, used as a cast in this assignment: pcptr = (*(int64 * (**) (void))pcptr)(); (Original source is this: pcptr := ref ref function=>ref int64(pcptr)^^() In English, the cast is 'pointer to pointer to function returning pointer to int64'. The line includes two dereferences (^^) which /I think/ account for two of the "*" in the C version. Which * are dereferences, and which are part of the type, or indeed whether only one * is the dereference, I have absolutely no idea. Great language...) -- bartc -- https://mail.python.org/mailman/listinfo/python-list
Re: Lies in education [was Re: The "loop and a half"]
On 11/10/2017 20:30, Chris Angelico wrote: On Thu, Oct 12, 2017 at 3:29 AM, Rhodri James wrote: On 11/10/17 15:36, Chris Angelico wrote: That's only really one level more complex than declarations I use fairly regularly (I am an embedded system programmer most of the time). On the other hand, I never actually do declare things in that way: typedef is your friend, and makes your C code much easier to read. I wouldn't consider embedded systems to be the most common kind of C coding out there, particularly when people compare against C++ (I don't remember ever hearing of anyone doing embedded work in C++, though I'm sure it does happen). Nevertheless, you're exactly right about the typedefs. Writing crazily complicated type declarations without typedefs is like writing massively nested list comprehensions without intermediate variables. Hey look, Python's terrible! Or maybe they're just non-idiomatic examples. Look at my last example posted a few minutes before this. You'd say the C needed typedefs. But in the original language, type declarations are clear enough that they don't need typedefs. The typedefs help to mitigate a problem in one language that doesn't exist in the other. Surely it's better to have neither the cryptic type nor the typedef. Everything would be much cleaner. -- bartc -- https://mail.python.org/mailman/listinfo/python-list
Re: Lies in education [was Re: The "loop and a half"]
Mikhail V wrote: [...] I'm not here to "cast stones", I like Python. I just think that you shouldn't cast stones at C/C++. Not while PHP exists. There aren't enough stones in the world... PHP seems (seemed?) popular for laying out web pages. Are their vastly superior options? Python? Superior syntax for sure I believe that. What accounts for the popularity of PHP then? -- https://mail.python.org/mailman/listinfo/python-list
Re: Lies in education [was Re: The "loop and a half"]
Grant Edwards wrote: On 2017-10-11, Bill wrote: Grant Edwards wrote: On 2017-10-11, Bill wrote: [...] I'm not here to "cast stones", I like Python. I just think that you shouldn't cast stones at C/C++. Not while PHP exists. There aren't enough stones in the world... PHP seems (seemed?) popular for laying out web pages. It's not really used for "laying out" web pages. Thats what HTML and CSS do. PHP is for server-side generation of dynamic content and handling of submitted forms and uploaded data. Thank you. I DO appreciate learning about the correct terminology. -- https://mail.python.org/mailman/listinfo/python-list
Re: Lies in education [was Re: The "loop and a half"]
On 2017-10-11, Bill wrote: > Mikhail V wrote: > [...] I'm not here to "cast stones", I like Python. I just think > that you shouldn't cast stones at C/C++. Not while PHP exists. There aren't enough stones in the world... >>> PHP seems (seemed?) popular for laying out web pages. Are their vastly >>> superior options? >> Python? Superior syntax for sure > > I believe that. What accounts for the popularity of PHP then? I ask myself that everytime I have to work with it. -- Grant Edwards grant.b.edwardsYow! FOOLED you! Absorb at EGO SHATTERING impulse gmail.comrays, polyester poltroon!! -- https://mail.python.org/mailman/listinfo/python-list
Re: Lies in education [was Re: The "loop and a half"]
On Thu, Oct 12, 2017 at 7:07 AM, Bill wrote: > Mikhail V wrote: > > [...] I'm not here to "cast stones", I like Python. I just think > that you shouldn't cast stones at C/C++. Not while PHP exists. There aren't enough stones in the world... >>> PHP seems (seemed?) popular for laying out web pages. Are their vastly >>> superior options? >> >> Python? Superior syntax for sure > > > I believe that. What accounts for the popularity of PHP then? It's popular, therefore people use it. It's purely self-perpetuating. There was a time (a time forever gone) when you could get extremely cheap web hosting with PHP support, but other scripting languages were only available if you paid more. That created a culture of low-grade sites gravitating to PHP and MySQL, which meant that software aimed at them (WordPress, various forum software, MediaWiki) would be written in PHP. And that means that anyone who wants to mod them (WordPress particularly) has to learn PHP. It's an endless cycle. But since it's the lowest-end sites that have traditionally driven that demand for PHP, there's a general tendency for low-grade programmers to gravitate to it, so there's a lot of really REALLY bad code out there. Yes, someone's going to chime in with (a) "You can write good code in PHP" and/or (b) "Big sites like Facebook and Wikipedia use PHP, so it must be fine". I don't care. About either. They're irrelevant to someone who's looking over the job postings... the chances that a PHP job will involve bad code are far higher than, say, Haskell jobs, which will be rarer but much less hit-and-miss. There's basically no reason to use PHP unless you're working in existing PHP code (as mentioned, things like WordPress plugins). Also: http://thedailywtf.com/articles/are-you-down-with-php- ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Lies in education [was Re: The "loop and a half"]
Bill writes: > Mikhail V wrote: > [...] I'm not here to "cast stones", I like Python. I just think > that you shouldn't cast stones at C/C++. Not while PHP exists. There aren't enough stones in the world... >>> PHP seems (seemed?) popular for laying out web pages. Are their vastly >>> superior options? >> Python? Superior syntax for sure > > I believe that. What accounts for the popularity of PHP then? Two things, probably. First, it was almost always pre-installed even on low-cost hosting. Second, you could start very simply because it was designed to be used embedded. Tiny little bits of code could so something -- not need for a "framework". Other languages were not always installed (I'm sure it's better these days) and those that were (Perl almost always was) could not, by default, be used embedded -- you had to generate the whole page. What is (or are) the Python way (or ways) to do it? -- Ben. -- https://mail.python.org/mailman/listinfo/python-list
Re: Lies in education [was Re: The "loop and a half"]
On Thu, Oct 12, 2017 at 7:42 AM, Ben Bacarisse wrote: > Bill writes: > >> Mikhail V wrote: >> [...] I'm not here to "cast stones", I like Python. I just think >> that you shouldn't cast stones at C/C++. > Not while PHP exists. There aren't enough stones in the world... > PHP seems (seemed?) popular for laying out web pages. Are their vastly superior options? >>> Python? Superior syntax for sure >> >> I believe that. What accounts for the popularity of PHP then? > > Two things, probably. First, it was almost always pre-installed even on > low-cost hosting. Second, you could start very simply because it was > designed to be used embedded. Tiny little bits of code could so > something -- not need for a "framework". > > Other languages were not always installed (I'm sure it's better these > days) and those that were (Perl almost always was) could not, by > default, be used embedded -- you had to generate the whole page. > > What is (or are) the Python way (or ways) to do it? Check out Django and Flask, the two most popular ways. I quite like Flask. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Lies in education [was Re: The "loop and a half"]
On Wednesday, October 11, 2017 at 4:47:43 PM UTC+1, bartc wrote: > On 11/10/2017 15:52, wrote: > > On Wednesday, October 11, 2017 at 3:14:51 PM UTC+1, bartc wrote: > >> On 11/10/2017 14:16, Marko Rauhamaa wrote: > >> > >>> Python and C don't try to protect you. In return, you get syntactic > >>> convenience that probably enhances the quality of your programs. > >> > >> Python, maybe. C syntax isn't as painful as C++ but I still have a lot > >> of trouble with it. (Eg. the variable declaration 'char(*(*x[3])())[5]'. > >> The name of the variable can be found lurking in that lot somewhere, but > >> what's the type?) Not so convenient. > > > https://cdecl.org/ tells me that your variable declaration is a syntax > > error so maybe not much of an example. > > Perhaps you didn't write or paste it properly. The site tells me that: > > char(*(*x[3])())[5] > > (with or without a trailing semicolon) means: > > declare x as array 3 of pointer to function returning pointer to > array 5 of char > > (Example taken from page 122 of the C book "K&R2", in a section about > writing a program to make sense of complex declarations.) > > Anyway that fact you either tripped up on typing it, or that you had to > use a special tool to find out what it meant, sort of reinforces my point... > > -- > bartc Don't know what happened there but what the heck. More importantly is the fact that due to your magnificent performance recently you have been promoted to be the General Manager of my Dream Team. You can of course cement your place when you explain how, in your language, converting an invalid piece of user input, which should be an integer, is always converted to zero, and how you handle the inevitable divide by zero errors that will always, eventually, occur. -- Kindest regards. Mark Lawrence. -- https://mail.python.org/mailman/listinfo/python-list
Re: Lies in education [was Re: The "loop and a half"]
On 11/10/2017 21:52, breamore...@gmail.com wrote:
>> More importantly is the fact that due to your magnificent
performance recently you have
been promoted to be the General Manager of my Dream Team.
Thanks, I guess.
You can of course cement your place when you explain how, in your language, converting an invalid
piece of user input, which should be an integer, is always converted to
zero, and how you handle the inevitable divide by zero errors that will
always, eventually, occur.
You mean it shouldn't do what happens here (Py3):
a = input("? ").split()
x = int(a[0])
y = int(a[1])
print (x,y)
print (x/y)
and somebody enters '10 0' ? I don't think you can do much about that.
However since that thread I've tweaked the way I do this, so that here
[non-Python code]:
print "? "
readln a, b# read each as int, float or string
println a/b# floating point divide
this produces these a/b results for various inputs:
10 20 # 0.50
10,20 # 0.50
10skjhf 20 # error, divide string by int
17.9 2 # 8.95
10 # error, divide int by string ("")
# (blank) error, divide string by string
.1e10 1e5 # 1.00
ten twenty # error, divide string by string
For throwaway programs, or for testing, or for trusted input, this is
perfectly reasonable. For perfect error checking, you need to do a bit
more work on either verifying input, or using more sophisticated parsing.
--
bartc
--
https://mail.python.org/mailman/listinfo/python-list
Lies in education [was Re: The "loop and a half"]
Bill wrote: > Mikhail V wrote: > > Python? Superior syntax for sure > > I believe that. What accounts for the popularity of PHP then? I can't tell for PHP for sure... As in many cases in software world, there is a principle of "who was the first there to solve some task". Probably also it was bundled with many Web solutions at the time when Web market started to grow, IDK. PS Off-topic: I have a related observation regarding popularity of software. There is such a program "VLC", which is a video player. Some would think it is sort of best free player, etc. I was also under impression, but then I've found a video player called "MPC-HC". I have started to use it and quickly understood that it is by far more superior player than VLC, literally by all core parameters - performance, codec support, customizable key bindings with a lot of internal commands. (Remark for Linux users: there is no Linux version of that player, it is Windows-only) So, I think one key to popularity is mostly related to *marketing*, in case of MPC, there is also a problem of a *good name* for the software. Once I was trying to remember, what was that nice player and just couldnt remember. MPC, MTC, HTC... So if it was from the beginning somthing more catchy like "Vulcano" or "Tornado" then I bet it would had way bigger user community now. And surprisingly, VLC seems to be more popular (if we take Windows), despite it can't even read some video formats, which MPC can. So go figure. Most important, one should not rely on those trashy "Top-10 ..." articles, and don't judge by the fancy GUI, but try the software yourself for some time. -- https://mail.python.org/mailman/listinfo/python-list
Re: Lies in education [was Re: The "loop and a half"]
bartc wrote: While on the subject of C syntax, here are some fun ambiguities: f(x);// call function with arg x, or declare x of type f? a*b; // multiply a by b, or declare b of type pointer to a? (a)*b// multiply a by b, or cast *b to type a? Technically these are not ambiguous in C, because the context always makes it clear whether you're dealing with a declaration or an expression. The indications can be subtle sometimes, but they're there. In C++ they really are ambiguous in some cases, and some arbitrary rules had to be added to disambiguate them. (I think the rule is "if it could be a declaration, then it is" or something like that.) -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: Lies in education [was Re: The "loop and a half"]
bartc wrote: tokenrec * (*)[] > the original source and that type is written like this: ref [] ref tokenrec The idiomatic way to write that type in C would be tokenrec ** -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: Lies in education [was Re: The "loop and a half"]
Neil Cerutti wrote: I dig const qualifiers, even though I'm comletely fine with their absence from Python. Out of curiosity, do you have any insights into why you like them in C++, if you don't miss them in Python? -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: Lies in education [was Re: The "loop and a half"]
On 11/10/2017 23:03, Gregory Ewing wrote: bartc wrote: tokenrec * (*)[] > the original source and that type is written like this: ref [] ref tokenrec The idiomatic way to write that type in C would be tokenrec ** The original has an extra pointer so idiomatic C might be more: tokenrec *** But this still defines a different type, namely: pointer to pointer to pointer to tokenrec not: pointer to array of pointer to tokenrec If you want to lose all array information, and really don't care if you're dealing with a pointer, or an array (and don't mind changing how such a value is passed, and how it is accessed) then this is fine for you. You just have to access a 'tokenrec ***args' parameter as ***args. Or **args[i]. Or *args[i][j]. **(args[i]). Or ***args. Or args[i][j][k]. Yes, any combination will work! Only one will be correct. In the original source, it can only be accessed one way - the correct way. Using the non-idiomatic 'tokenrec *(*)[]' in C imposes some extra constraints, but doesn't do the full job. However my complaint was about the syntax; the type system of C is another subject. (How I ended up talking about C in this group I don't know. But yesterday I mentioned Python in the C group, so ...) -- bartc -- https://mail.python.org/mailman/listinfo/python-list
Re: Lies in education [was Re: The "loop and a half"]
Chris Angelico writes: > On Thu, Oct 12, 2017 at 7:42 AM, Ben Bacarisse wrote: >> Bill writes: >> >>> Mikhail V wrote: >>> [...] I'm not here to "cast stones", I like Python. I just think >>> that you shouldn't cast stones at C/C++. >> Not while PHP exists. There aren't enough stones in the world... >> > PHP seems (seemed?) popular for laying out web pages. Are their vastly > superior options? Python? Superior syntax for sure >>> >>> I believe that. What accounts for the popularity of PHP then? >> >> Two things, probably. First, it was almost always pre-installed even on >> low-cost hosting. Second, you could start very simply because it was >> designed to be used embedded. Tiny little bits of code could so >> something -- not need for a "framework". >> >> Other languages were not always installed (I'm sure it's better these >> days) and those that were (Perl almost always was) could not, by >> default, be used embedded -- you had to generate the whole page. >> >> What is (or are) the Python way (or ways) to do it? > > Check out Django and Flask, the two most popular ways. I quite like > Flask. I see. Both appear to be frameworks (I'd heard of Django). Do you know if they widely available on low-cost hosting packages? (I don't think they are on mine, but that's dirt-cheap because I don't use it for anything important!) One thing that helped PHP was that it could be used (and learned) in an incremental way. You could add a "this page last updated on..." text in a line or two to an existing page. Then a button to change the layout or theme. Then a simple form and so on. Many professionals started that way. In the early days, there ware few other routes into the technical side of web authoring. That helped to cement PHP as the dominant technology because it was what they knew. -- Ben. -- https://mail.python.org/mailman/listinfo/python-list
Re: Lies in education [was Re: The "loop and a half"]
Gregory Ewing writes: > bartc wrote: > >> tokenrec * (*)[] >> >> the original source and that type is written like this: >> >> ref [] ref tokenrec > > The idiomatic way to write that type in C would be > >tokenrec ** That's a different type. I think you mean that a human writing C (rather than bartc's code generator) would probably design the code to use tokenrec ** then I agree, but the latter is not just a different way to write the former. -- Ben. -- https://mail.python.org/mailman/listinfo/python-list
Re: Lies in education [was Re: The "loop and a half"]
On Oct 11, 2017, at 9:07 AM, Bill wrote: > > Grant Edwards wrote: >> On 2017-10-11, Bill wrote: >> >> >>> [...] I'm not here to "cast stones", I like Python. I just think >>> that you shouldn't cast stones at C/C++. >> Not while PHP exists. There aren't enough stones in the world... >> > > PHP seems (seemed?) popular for laying out web pages. Are their vastly > superior options? I'm a little naive in this matter, thus my question. > -- > https://mail.python.org/mailman/listinfo/python-list AFAIK, JavaScript frameworks has largely replaced PHP. I personally use Pelican to generate static web pages and use JavaScript sparingly. Chris R. -- https://mail.python.org/mailman/listinfo/python-list
Re: Lies in education [was Re: The "loop and a half"]
On Thu, Oct 12, 2017 at 9:44 AM, Ben Bacarisse wrote:
> Chris Angelico writes:
>> Check out Django and Flask, the two most popular ways. I quite like
>> Flask.
>
> I see. Both appear to be frameworks (I'd heard of Django). Do you know
> if they widely available on low-cost hosting packages? (I don't think
> they are on mine, but that's dirt-cheap because I don't use it for
> anything important!)
Generally, low-cost hosting will offer Python, and then you can
install Flask/Django from there. For example, you can deploy to Heroku
(zero-dollar hosting for small sites), and as long as you provide a
file called "requirements.txt", they'll install whatever you depend
on.
> One thing that helped PHP was that it could be used (and learned) in an
> incremental way. You could add a "this page last updated on..." text in
> a line or two to an existing page. Then a button to change the layout
> or theme. Then a simple form and so on.
>
> Many professionals started that way. In the early days, there ware few
> other routes into the technical side of web authoring. That helped to
> cement PHP as the dominant technology because it was what they knew.
Yeah. The trouble is that this is a really REALLY bad way to design
something. Have you seen a city that grew one house at a time, and had
streets added to service those houses? Not good. The end result is
that PHP is still bound by this "just a bit of scripting inside your
HTML" structure, which has annoying consequences in certain areas
(like whitespace before the first "https://en.wikipedia.org/wiki/Foo"; without some help from the web
server, eg Apache's mod_rewrite. In contrast, Python and Flask would
handle that like this:
@app.route("/wiki/")
def show_article(article):
...
Have a think about what the PHP setup implies. Arbitrary files in your
web server tree are not just automatically available (as they'd be if
you use flat-file hosting like GitHub Pages), but they are
*executable*. You don't have to set the file mode to say "this is
executable", you just have to have the file there with the appropriate
name. So PHP-based web sites end up having to monitor their uploads
and downloads lest someone slip something in and then run it on the
server... with full permissions. With Flask, in contrast, you can make
an uploads directory that's automatically downloadable, but nothing in
it will ever be executed.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: Lies in education [was Re: The "loop and a half"]
r...@zedat.fu-berlin.de (Stefan Ram) writes: > Ben Bacarisse writes: >>That's a different type. I think you mean that a human writing C >>(rather than bartc's code generator) would probably design the code to >>use tokenrec ** then I agree, but the latter is not just a different way >>to write the former. > > That most difficult thing in C in the realm of type > declarations for me is: > > Define a function »g« with a parameter »x« of type »int«, so > that this function »g« returns a pointer to another function. > This other function has a parameter of type »char« and returns > a double value. > > /Without/ a typedef. You read a C type from the "inside out", going right if you can and left when you can't. That rule can be reversed to built up the type: You know it has (read "g is a function taking an int") g(int x) and since g returns a pointer you will have *g(int x) But it returns a pointer to a function taking a char so we must add (char) on the right but the brackets can't go here: *g(int x)(char) because then you would be read "function taking a char" before the pointer to. We need extra brackets to stop us reading right until we've read left: (*g(int x))(char) This forces "g is a function taking int returning a pointer to...". Finally, we just need the type of the function whose pointer is being returned: double (*g(int x))(char) Check with you finger on the name and reading right when you can and left when you can't (because of brackets). And then you re-write it using a typedef. Knowing how is simply interesting, not useful. -- Ben. -- https://mail.python.org/mailman/listinfo/python-list
OT: MPC-HC project ending? [Re: Lies in education [was Re: The "loop and a half"]]
On Wed, Oct 11, 2017 at 4:45 PM, Mikhail V wrote: > > PS Off-topic: > I have a related observation regarding popularity of software. > There is such a program "VLC", which is a video player. Some would > think it is sort of best free player, etc. I was also under impression, > but then I've found a video player called "MPC-HC". > I have started to use it and quickly understood that it is by far more > superior player than VLC, literally by all core parameters - performance, > codec support, customizable key bindings with a lot of internal commands. > (Remark for Linux users: there is no Linux version of that player, it > is Windows-only) I went to https://mpc-hc.org/2017/07/16/1.7.13-released-and-farewell/ and it says: July 16, 2017 XhmikosR v1.7.13, the latest, and probably the last release of our project… For quite a few months now, or even years, the number of active developers has been decreasing and has inevitably reached zero. This, unfortunately, means that the project is officially dead and this release would be the last one. …Unless some people step up that is. So, if someone’s willing to really contribute and has C/C++ experience, let me know on IRC or via e-mail. Otherwise, all things come to an end and life goes on. It’s been a nice journey and I’m personally pretty overwhelmed having to write this post. Thanks to everyone who has contributed in any way all these years; Remember, MPC-HC is an 11-year old project. -- boB -- https://mail.python.org/mailman/listinfo/python-list
Re: OT: MPC-HC project ending? [Re: Lies in education [was Re: The "loop and a half"]]
On Thu, Oct 12, 2017 at 11:38 AM, boB Stepp wrote: > On Wed, Oct 11, 2017 at 4:45 PM, Mikhail V wrote: > >> >> PS Off-topic: >> I have a related observation regarding popularity of software. >> There is such a program "VLC", which is a video player. Some would >> think it is sort of best free player, etc. I was also under impression, >> but then I've found a video player called "MPC-HC". >> I have started to use it and quickly understood that it is by far more >> superior player than VLC, literally by all core parameters - performance, >> codec support, customizable key bindings with a lot of internal commands. >> (Remark for Linux users: there is no Linux version of that player, it >> is Windows-only) > > I went to https://mpc-hc.org/2017/07/16/1.7.13-released-and-farewell/ > and it says: > > > > July 16, 2017 XhmikosR > > v1.7.13, the latest, and probably the last release of our project… > > For quite a few months now, or even years, the number of active > developers has been decreasing and has inevitably reached zero. This, > unfortunately, means that the project is officially dead and this > release would be the last one. > > …Unless some people step up that is. > > So, if someone’s willing to really contribute and has C/C++ > experience, let me know on IRC or via e-mail. > > Otherwise, all things come to an end and life goes on. It’s been a > nice journey and I’m personally pretty overwhelmed having to write > this post. > > Thanks to everyone who has contributed in any way all these years; > Remember, MPC-HC is an 11-year old project. > > If it wants new life, it's probably going to need a Linux version, because that's where a lot of developers hang out. The reality is that open source developers are much more likely to develop on Linux than on Windows; you can maintain a Windows port of a Linux program with fewer Windows experts than maintaining the entire program on Windows. The other option, though, would be for the useful parts to become feature suggestions for VLC. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Lies in education [was Re: The "loop and a half"]
Chris Angelico writes:
> On Thu, Oct 12, 2017 at 9:44 AM, Ben Bacarisse wrote:
>> Chris Angelico writes:
>>> Check out Django and Flask, the two most popular ways. I quite like
>>> Flask.
>>
>> I see. Both appear to be frameworks (I'd heard of Django). Do you know
>> if they widely available on low-cost hosting packages? (I don't think
>> they are on mine, but that's dirt-cheap because I don't use it for
>> anything important!)
>
> Generally, low-cost hosting will offer Python, and then you can
> install Flask/Django from there. For example, you can deploy to Heroku
> (zero-dollar hosting for small sites), and as long as you provide a
> file called "requirements.txt", they'll install whatever you depend
> on.
>
>> One thing that helped PHP was that it could be used (and learned) in an
>> incremental way. You could add a "this page last updated on..." text in
>> a line or two to an existing page. Then a button to change the layout
>> or theme. Then a simple form and so on.
>>
>> Many professionals started that way. In the early days, there ware few
>> other routes into the technical side of web authoring. That helped to
>> cement PHP as the dominant technology because it was what they knew.
>
> Yeah. The trouble is that this is a really REALLY bad way to design
> something.
Yes, I know that's the way of the devil, just I'm explaining why PHP is
popular!
> Have you seen a city that grew one house at a time, and had
> streets added to service those houses? Not good. The end result is
> that PHP is still bound by this "just a bit of scripting inside your
> HTML" structure, which has annoying consequences in certain areas
> (like whitespace before the first " situations, and the way "include" works), plus it binds your URLs to
> the concrete file system. That may not seem like too much of a
> problem, but it's a pretty big limitation; you can't have URLs like
> "https://en.wikipedia.org/wiki/Foo"; without some help from the web
> server, eg Apache's mod_rewrite.
I don't follow this. Your "can't" and "big limitation" suggests
something inevitable, but I don't see it as an intrinsic problem with
the language. I'm sure PHP is not as flexible as the frameworks you
mention, but you are not tied to URLs mapping to files. Maybe you meant
that this is what often happens, or what most people do, with PHP.
> In contrast, Python and Flask would
> handle that like this:
>
> @app.route("/wiki/")
> def show_article(article):
> ...
>
> Have a think about what the PHP setup implies. Arbitrary files in your
> web server tree are not just automatically available (as they'd be if
> you use flat-file hosting like GitHub Pages), but they are
> *executable*. You don't have to set the file mode to say "this is
> executable", you just have to have the file there with the appropriate
> name. So PHP-based web sites end up having to monitor their uploads
> and downloads lest someone slip something in and then run it on the
> server... with full permissions. With Flask, in contrast, you can make
> an uploads directory that's automatically downloadable, but nothing in
> it will ever be executed.
Yes, it's fraught with security issues.
--
Ben.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Lies in education [was Re: The "loop and a half"]
On Thu, Oct 12, 2017 at 11:55 AM, Ben Bacarisse wrote: > Chris Angelico writes: >> it binds your URLs to >> the concrete file system. That may not seem like too much of a >> problem, but it's a pretty big limitation; you can't have URLs like >> "https://en.wikipedia.org/wiki/Foo"; without some help from the web >> server, eg Apache's mod_rewrite. > > I don't follow this. Your "can't" and "big limitation" suggests > something inevitable, but I don't see it as an intrinsic problem with > the language. I'm sure PHP is not as flexible as the frameworks you > mention, but you are not tied to URLs mapping to files. Maybe you meant > that this is what often happens, or what most people do, with PHP. How would you, with PHP itself, handle database-provided URLs? The only way I've ever seen it done is at an external level - such as mod_rewrite - which means that someone else, *not* the PHP script, is managing your URLs. They're pushed to some external config file somewhere. That's okay for just one URL pattern, but it doesn't scale well, which is why (for example) Wikipedia's editing pages are "/w/index.php?" instead of, say, "/wiki/Foo/edit" or "/wiki/edit/Foo". Unless you know something I don't? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Lies in education [was Re: The "loop and a half"]
Chris Angelico writes: > On Thu, Oct 12, 2017 at 11:55 AM, Ben Bacarisse wrote: >> Chris Angelico writes: >>> it binds your URLs to >>> the concrete file system. That may not seem like too much of a >>> problem, but it's a pretty big limitation; you can't have URLs like >>> "https://en.wikipedia.org/wiki/Foo"; without some help from the web >>> server, eg Apache's mod_rewrite. >> >> I don't follow this. Your "can't" and "big limitation" suggests >> something inevitable, but I don't see it as an intrinsic problem with >> the language. I'm sure PHP is not as flexible as the frameworks you >> mention, but you are not tied to URLs mapping to files. Maybe you meant >> that this is what often happens, or what most people do, with PHP. > > How would you, with PHP itself, handle database-provided URLs? The > only way I've ever seen it done is at an external level - such as > mod_rewrite - which means that someone else, *not* the PHP script, is > managing your URLs. They're pushed to some external config file > somewhere. That's okay for just one URL pattern, but it doesn't scale > well, which is why (for example) Wikipedia's editing pages are > "/w/index.php?" instead of, say, "/wiki/Foo/edit" or > "/wiki/edit/Foo". > > Unless you know something I don't? Provided some early part of the URL is handled by PHP, the rest of the URL path is provided to PHP in $_SERVER["PATH_INFO"]. -- Ben. -- https://mail.python.org/mailman/listinfo/python-list
Re: Lies in education [was Re: The "loop and a half"]
On Thu, 12 Oct 2017 02:43 am, Marko Rauhamaa wrote:
> Chris Angelico :
>
>> The places where C++ is not a superset of C are mostly things you
>> wouldn't want to be doing anyway. You can generally take C code and
>> compile it with a C++ compiler, and it'll have the same semantics.
>
> Here's a C/C++ program:
>
>
> #include
>
> int main()
> {
> struct {} s;
> printf("%d\n", (int) sizeof 'a');
> printf("%d\n", (int) sizeof s);
> return 0;
> }
>
>
> When compiled (with gcc) as a C program, the output is:
>
> 4
> 0
>
> When the same program is compiled (with gcc) as a C++ program, the
> output is:
>
> 1
> 1
>
> That is not immediately all that significant but points to subtle
> incompatibilities between the data models of C and C++.
I don't think anyone should expect that platform specific details like the
size of a char should be precisely the same between C and C++. Even two
different C compilers could return different values.
> Then we have syntactic problems:
[...]
I don't believe that anyone meant to imply that C++ is an exact superset of C.
I know I didn't, although I acknowledge that my terminology was lazy.
C++ is broadly-speaking compatible with C, with just enough differences to act
as landmines to the unwary. Good enough?
--
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Test Bank for Introduction to Sociology 10th Edition by Anthony Giddens
On Wednesday, July 12, 2017 at 5:15:39 PM UTC-4, Test Banks wrote: > Greetings, > > You can get Test Bank for " Introduction to Sociology 10th Edition by Anthony > Giddens, Mitchell Duneier, Richard P. Appelbaum, Deborah Carr " at very > reasonable price. Our team is available 24/7 and 365 days / year to respond > your requests. Send us an email at pro.fast(@)hotmail(dot)com > > Place your order at PRO.FAST(@)HOTMAIL(DOT)COM > > ISBN Numbers for this book (ISBN-13: 9780393289688) > > INTRODUCTION TO SOCIOLOGY 10TH EDITION BY GIDDENS TEST BANK > > You can also email for other Sociology books Solutions and Test Bank at low > prices and our team will try to get all resources you need. > > Do not post your reply here. Simply send us an email at PRO.FAST (AT) HOTMAIL > (DOT) COM > > Cheers, -- https://mail.python.org/mailman/listinfo/python-list
Re: Looping [was Re: Python and the need for speed]
On Wed, 11 Oct 2017 10:57 pm, Stefan Ram wrote:
> FWIW, in is book "Touch of Class" (2009) Bertrand Meyer writes:
>
> |Such instructions are just the old goto in sheep's clothing.
> |Treat them the same way as the original:
> |
> |/Touch of Methodology/:
> | Sticking to one-entry, one-exit building blocks
> |Stay away from any "break" or similar control mechanism.
I have a great deal of respect for Meyer, but in this case I think he has it
badly wrong on both counts (`break` and "one-entry, one-exit").
Unrestricted GOTO (as in BASIC, circa 1970, where you could jump to any line
in the code, or as in assembly) is rightly considered harmful (albeit
necessary in assembly). But if Meyer means *any* sort of jump ("similar
control mechanism"), then that would rule out not just `break` and `continue`
but also:
* while loops
* for loops
* if...else
* case/switch statements
* calling subroutines (functions or procedures)
* exception handling
Remember that a function call is basically a GOTO in disguise: execution jumps
to the function, and jumps back when the function returns. In BASIC, there
was a GOSUB intermediate between a GOTO and a procedure call.
Surely Meyer doesn't mean to say we should never call functions or use
`while`, `for` or `if`. So he has to distinguish between kinds of jumps:
Good jumps (I presume):
* function calls
* if...else
* looping
Evil jumps:
* unrestricted BASIC-style GOTO/GOSUB any line number
* break/continue
Not sure:
* GOTO where there are restrictions on where you can jump
* COMEFROM
(I kid: I'm sure Meyer would oppose COMEFROM, and I expect that even
Pascal-style restricted GOTO would be on his "evil" list to avoid.)
So the question becomes, why are such harmless, simple to understand,
innocuous jumps like `break` and `continue` in the evil list, when they not
only simplify code but make it more efficient?
# with break
for i in range(2**64):
if isprime(i):
print(i, "is prime")
break
# without break
still_searching = True
for i in range(2**64):
if still_searching and isprime(i):
print(i, "is prime")
still_searching = False
# without break, attempt number 2
still_searching = True
i = 0
while still_searching and i < 2**64:
if isprime(i):
print(i, "is prime")
still_searching = False
Unrestricted jumps *into* a subroutine are hard to reason about. In general,
subroutines should have a single entry point. But the requirement for one
exit is too strict. From the caller's perspective, there is no way to tell
how many exit point a function has: subroutines are black boxes that the
caller cannot see into, and the difference between a single exit and multiple
exits is invisible.
But from the point of view of the subroutines, the rule "one exit" is like the
rule "no break" for loops: it makes the code more complex and less efficient.
If you're done, you're done, and you might as well return out of the function
rather than write boilerplate code to pad it out until you get to the very
end. With only a single condition to test, there's not much difference
between the two:
# with single exit # with multiple exits
def foo(): def foo():
if condition: if condition:
result = 1 return 1
else: return 2
result = 2
return result
but as the number of decision points increase, the complexity required to keep
a single exit also increases.
Ironically, after telling us to stick to code with one entry and one exit,
Meyer then contradicts himself by recommending exceptions:
> |You can use exception handling as a technique of last resort
> |to handle unexpected events for which the normal control
> |structures let you down.
Even more ironically, exception handling is most similar to a COMEFROM, which
was invented as a joke.
--
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Lies in education [was Re: The "loop and a half"]
Steve D'Aprano writes:
> On Thu, 12 Oct 2017 02:43 am, Marko Rauhamaa wrote:
>
>> Chris Angelico :
>>
>>> The places where C++ is not a superset of C are mostly things you
>>> wouldn't want to be doing anyway. You can generally take C code and
>>> compile it with a C++ compiler, and it'll have the same semantics.
>>
>> Here's a C/C++ program:
It's not a C program in the sense that it's undefined in C. A struct
with no members is a constraint violation.
>>
>> #include
>>
>> int main()
>> {
>> struct {} s;
>> printf("%d\n", (int) sizeof 'a');
>> printf("%d\n", (int) sizeof s);
>> return 0;
>> }
>>
>>
>> When compiled (with gcc) as a C program, the output is:
>>
>> 4
>> 0
>>
>> When the same program is compiled (with gcc) as a C++ program, the
>> output is:
>>
>> 1
>> 1
>>
>> That is not immediately all that significant but points to subtle
>> incompatibilities between the data models of C and C++.
>
> I don't think anyone should expect that platform specific details like the
> size of a char should be precisely the same between C and C++. Even two
> different C compilers could return different values.
The size of (in the sense of sizeof) an expression of type char is
defined to be 1. All conforming C and C++ compilers must return 1 in
such a case. The difference being highlighted here is that, in C, 'a'
is an integer expression. In C++ it's of type char.
--
Ben.
--
https://mail.python.org/mailman/listinfo/python-list
Logging from files doesn't work
Hello,
apparently my reading comprehension is nose diving these days. After
reading python cookbook and a few other tutorials i still can't get a
simple logging from a few files to work.
I suspected my file organization - all files are in the same directory,
causing problem. But it appears it is not.
Anyway, in the example below, only logging from main.py works. I also want
to have login from "test1/test.py" to write into the same common log file.
And how can i accomplish the same if test.py is in the same directory as
main.py?
dir structure:
src/
|- main.py
|-test/
|-test.py
code:
test.py:
import logging
# neither of below produce any results
log = logging.getLogger("test1.test")
# log = logging.getLogger(__name__)
def fun():
print("DADADA")
log.debug(" DADADADA " )
main.py:
from test1.test import fun
def main():
log = logging.getLogger(__name__)
log.setLevel(logging.DEBUG)
fh = logging.FileHandler("nja_" +
datetime.now().strftime("%Y_%b_%d_%H_%M_%S") +".log")
formatter = logging.Formatter('%(levelname)s - %(asctime)s -
%(funcName)10s() %(lineno)s - %(message)s')
fh.setFormatter(formatter)
log.addHandler(fh)
log.debug("Yes, this line is in the log file")
fun()
log.debug("And this one is too")
this is 3.5 version.
Thank you in advance.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Logging from files doesn't work
if i change print statements in both files to print out "__name__":
__main__
test1.test
On Wed, Oct 11, 2017 at 10:02 PM, Andrew Z wrote:
> Hello,
>
> apparently my reading comprehension is nose diving these days. After
> reading python cookbook and a few other tutorials i still can't get a
> simple logging from a few files to work.
> I suspected my file organization - all files are in the same directory,
> causing problem. But it appears it is not.
>
> Anyway, in the example below, only logging from main.py works. I also want
> to have login from "test1/test.py" to write into the same common log file.
>
> And how can i accomplish the same if test.py is in the same directory as
> main.py?
>
> dir structure:
> src/
> |- main.py
> |-test/
> |-test.py
>
> code:
> test.py:
>
> import logging
> # neither of below produce any results
>
> log = logging.getLogger("test1.test")
> # log = logging.getLogger(__name__)
>
> def fun():
>print("DADADA")
>log.debug(" DADADADA " )
>
>
> main.py:
>
> from test1.test import fun
>
> def main():
>
>log = logging.getLogger(__name__)
>log.setLevel(logging.DEBUG)
>
>fh = logging.FileHandler("nja_" +
> datetime.now().strftime("%Y_%b_%d_%H_%M_%S") +".log")
>formatter = logging.Formatter('%(levelname)s - %(asctime)s -
> %(funcName)10s() %(lineno)s - %(message)s')
>fh.setFormatter(formatter)
>log.addHandler(fh)
>
>log.debug("Yes, this line is in the log file")
>
>fun()
>
>log.debug("And this one is too")
>
>
>
> this is 3.5 version.
>
> Thank you in advance.
>
--
https://mail.python.org/mailman/listinfo/python-list
Re: Logging from files doesn't work
aha. So the issue is that main.py's __name__ attribute == "__main__" and
test.py is "test1.test".
if i manually assign names:
main.py - >
log = logging.getLogger("MAIN")
test.py - >
log = logging.getLogger("MAIN.test1.test")
then logging is working perfectly well.
This brings me to the question - what is wrong with me file
naming/structure that confuses the logging module? I'm not sure i
really want to have each little file in it's own directory too..
but i'm open for suggestions.
On Wed, Oct 11, 2017 at 10:15 PM, Andrew Z wrote:
> if i change print statements in both files to print out "__name__":
> __main__
> test1.test
>
> On Wed, Oct 11, 2017 at 10:02 PM, Andrew Z wrote:
>
>> Hello,
>>
>> apparently my reading comprehension is nose diving these days. After
>> reading python cookbook and a few other tutorials i still can't get a
>> simple logging from a few files to work.
>> I suspected my file organization - all files are in the same directory,
>> causing problem. But it appears it is not.
>>
>> Anyway, in the example below, only logging from main.py works. I also
>> want to have login from "test1/test.py" to write into the same common log
>> file.
>>
>> And how can i accomplish the same if test.py is in the same directory as
>> main.py?
>>
>> dir structure:
>> src/
>> |- main.py
>> |-test/
>> |-test.py
>>
>> code:
>> test.py:
>>
>> import logging
>> # neither of below produce any results
>>
>> log = logging.getLogger("test1.test")
>> # log = logging.getLogger(__name__)
>>
>> def fun():
>>print("DADADA")
>>log.debug(" DADADADA " )
>>
>>
>> main.py:
>>
>> from test1.test import fun
>>
>> def main():
>>
>>log = logging.getLogger(__name__)
>>log.setLevel(logging.DEBUG)
>>
>>fh = logging.FileHandler("nja_" +
>> datetime.now().strftime("%Y_%b_%d_%H_%M_%S") +".log")
>>formatter = logging.Formatter('%(levelname)s - %(asctime)s -
>> %(funcName)10s() %(lineno)s - %(message)s')
>>fh.setFormatter(formatter)
>>log.addHandler(fh)
>>
>>log.debug("Yes, this line is in the log file")
>>
>>fun()
>>
>>log.debug("And this one is too")
>>
>>
>>
>> this is 3.5 version.
>>
>> Thank you in advance.
>>
>
>
--
https://mail.python.org/mailman/listinfo/python-list
Re: Lies in education [was Re: The "loop and a half"]
Actually, FORTRAN and COBOL and Algol (for its control structures) Trying to support both of the first two was entertaining -- when you declared a variable, it wasn't enough to say it was an Integer: you had to also declare whether it was represented in Binary or Decimal, and also specify the desired precision. The IBM/360 architecture supported both binary and decimal integers, where the decimals were stored as BCD nybbles of arbitrary fixed length (as opposed to binary integers matching the machine word size) The world migrated away from PL/I back in those days because of the one-size fits none consequences of trying to do everything. So I always find myself looking askance when language designers try to repeat the exercise. You know, like designing a largely-interpreted object-oriented language with libraries supporting a functional programming style. I think I've seen a language like that somewhere around this forum. But I like it anyway Roger Christman Pennsylvania State University On Wed, Oct 11, 2017 12:07 PM, Dennis Lee Bieber wrote: > On Wed, 11 Oct 2017 00:21:46 -0400, Bill >declaimed the following: > >>PL-I has already been taken. That is a pretty free-wheeling language > > I think I once heard PL-1 described as trying to combine FORTRAN and >COBOL... > > > -- https://mail.python.org/mailman/listinfo/python-list
Re: Logging from files doesn't work
On 11Oct2017 22:27, Andrew Z wrote:
aha. So the issue is that main.py's __name__ attribute == "__main__" and
test.py is "test1.test".
Yeah. If you invoke a module as "python -m module_name" its __name__ field is
"__main__". That makes the boilerplate work, but breaks your expectation that
__name__ is usually module_name.
if i manually assign names:
main.py - >
log = logging.getLogger("MAIN")
test.py - >
log = logging.getLogger("MAIN.test1.test")
then logging is working perfectly well.
This brings me to the question - what is wrong with me file
naming/structure that confuses the logging module? I'm not sure i
really want to have each little file in it's own directory too..
I confess to not using the logging module in the module-named-based fashion
that seems to be the default recommendation. I usually prefer to set up the
root logger to log somewhere suitable to the main program (typically just
stderr by default), and set up special logging for other things as needed.
As what may be a poor example, I've got a mail filing program which monitors
maildirs for arriving messages to refile. So I've got a class associated with
each monitored maildir with these methods:
@property
def logdir(self):
''' The pathname of the directory in which log files are written.
'''
varlog = cs.env.LOGDIR(self.environ)
return os.path.join(varlog, 'mailfiler')
This essentially computes "$HOME/var/log/mailfiler" as the place where all the
logfiles are saved. And this:
def folder_logfile(self, folder_path):
''' Return path to log file associated with the named folder.
TODO: base on relative path from folder root, not just basename.
'''
return os.path.join(self.logdir, '%s.log' % (os.path.basename(folder_path)))
which computes "$HOME/var/log/mailfiler/spool.log" as the logfile when working
on my maildir "$HOME/mail/spool".
And then off it goes with a FileHandler for that path for the filing actions
for that maildir.
So you're not contrained to drop log files all through your source tree (ewww!)
My opinion is that you should decide where your logfiles _should_ live; it
generally has nothing (or little) to do with the module name. I keep mine,
generally, in various subdirectories of "$HOME/var/log".
Cheers,
Cameron Simpson (formerly c...@zip.com.au)
--
https://mail.python.org/mailman/listinfo/python-list
Re: Lies in education [was Re: The "loop and a half"]
On Thu, Oct 12, 2017 at 12:19 PM, Ben Bacarisse wrote: > Chris Angelico writes: > >> On Thu, Oct 12, 2017 at 11:55 AM, Ben Bacarisse wrote: >>> Chris Angelico writes: it binds your URLs to the concrete file system. That may not seem like too much of a problem, but it's a pretty big limitation; you can't have URLs like "https://en.wikipedia.org/wiki/Foo"; without some help from the web server, eg Apache's mod_rewrite. >>> >>> I don't follow this. Your "can't" and "big limitation" suggests >>> something inevitable, but I don't see it as an intrinsic problem with >>> the language. I'm sure PHP is not as flexible as the frameworks you >>> mention, but you are not tied to URLs mapping to files. Maybe you meant >>> that this is what often happens, or what most people do, with PHP. >> >> How would you, with PHP itself, handle database-provided URLs? The >> only way I've ever seen it done is at an external level - such as >> mod_rewrite - which means that someone else, *not* the PHP script, is >> managing your URLs. They're pushed to some external config file >> somewhere. That's okay for just one URL pattern, but it doesn't scale >> well, which is why (for example) Wikipedia's editing pages are >> "/w/index.php?" instead of, say, "/wiki/Foo/edit" or >> "/wiki/edit/Foo". >> >> Unless you know something I don't? > > Provided some early part of the URL is handled by PHP, the rest of the > URL path is provided to PHP in $_SERVER["PATH_INFO"]. Is it possible to do that without having ".php" visible in the path? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Lies in education [was Re: The "loop and a half"]
On 2017-10-11, Chris Angelico wrote: > But since it's the lowest-end sites that have traditionally driven > that demand for PHP, there's a general tendency for low-grade > programmers to gravitate to it, so there's a lot of really REALLY bad > code out there. And there are a lot of people providing really REALLY bad answers on various support fora. I learned very quickly to pay no attention to people providing answers to PHP questions on any web-based forum. I've probably been spoiled by the level of discorse in this list/group, but I was absolutely dumbfounded by the wrong answers people drooled onto the interwebs. PHP is the poster child for cargo-cult programming where people cut/paste chunks of garbage without really understanding what they're doing. Even the official PHP documentation is pretty bad. It's not usually outright wrong, but it's very incomplete, and leaves a _lot_ of things undefined. Of course the PHP lanugage itself is such a mess, it's often not very easy to understand what's going on. -- Grant -- https://mail.python.org/mailman/listinfo/python-list
Re: Lies in education [was Re: The "loop and a half"]
On 2017-10-11, Gregory Ewing wrote: > Neil Cerutti wrote: >> I dig >> const qualifiers, even though I'm comletely fine with their >> absence from Python. > > Out of curiosity, do you have any insights into why you > like them in C++, if you don't miss them in Python? I like them in C because it allows the linker to place them in ROM with the code. It also _sometimes_ provides useful diagnostics when you pass a pointer to something which shouldn't be modified to something that is going to try to modify it. -- Grant -- https://mail.python.org/mailman/listinfo/python-list
Re: Lies in education [was Re: The "loop and a half"]
On 2017-10-12, Steve D'Aprano wrote: > I don't think anyone should expect that platform specific details like the > size of a char should be precisely the same between C and C++. I don't knwo about that. > Even two > different C compilers could return different values. Nope. If sizeof char is not 1, then it's not C. That doesn't mean that a char can't be 9, 11, 16, 20, 32, or 64 bits, but sizeof char is 1. -- Grant -- https://mail.python.org/mailman/listinfo/python-list
Re: Lies in education [was Re: The "loop and a half"]
bartc wrote: The original has an extra pointer so idiomatic C might be more: tokenrec *** I was going by your English description, which when translated into C gives only two pointers. But I think you're right that the C version really has 3 levels of indirection, so the meaning of "array" in the original language must be something different from what it is in C. My point was that C makes very little distinction between "pointer to foo" and "pointer to first element of array of foo", so it's not usual practice to write declarations as convoluted as "* (*)[]". If you want to lose all array information, and really don't care if you're dealing with a pointer, or an array (and don't mind changing how such a value is passed, and how it is accessed) then this is fine for you. You lose that information in C anyway. There's no way for the function to tell whether it was passed a pointer to a single value or a pointer to an array, and if the latter, how many elements are in the array. If you want that information passed, you have to arrange it separately. You don't get it just by writing "* (*)[]" instead of "***" for the argument type. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: Lies in education [was Re: The "loop and a half"]
Ben Bacarisse wrote: That's a different type. I think you mean that a human writing C (rather than bartc's code generator) would probably design the code to use tokenrec ** then I agree, but the latter is not just a different way to write the former. Yes, I was translating his English description of the type into C, using C's meaning of the word "array". It seems that arrays in the original language (Algol? One of Bart's inventions?) are somewhat richer things. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
