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 descript
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
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
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 a
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 provid
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 b
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
__
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 desir
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
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
> s
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
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 t
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 build
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
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
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.wikipedi
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 he
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 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 pla
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
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 t
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
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...
>>
>
>
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
(
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 ston
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 mor
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
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
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 i
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 bu
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,
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
> >>> co
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
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 va
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?) popul
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.
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?)
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? Superi
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 han
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 fun
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])()
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
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 somewh
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
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 poi
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 variab
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?) p
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
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
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 var
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
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
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
> >> [...] 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? Supe
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 vast
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 some
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
"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 b
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.
P
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
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:
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.
>
- 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
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 co
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 thi
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
>> act
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
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
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 n
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
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 real
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 impenetra
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
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.
74 matches
Mail list logo