Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #86597 > unrolled thread

Re: Python Worst Practices

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Python Worst Practices Dave Angel <davea@davea.name> - 2015-02-27 16:59 -0500

#86597 — Re: Python Worst Practices

On 02/27/2015 04:40 PM, Chris Angelico wrote:
> On Sat, Feb 28, 2015 at 8:37 AM, Dave Angel <davea@davea.name> wrote:
>> Right.  In C and C++, instead of being the first slide, it'd be the first 3
>> or 4.  Between header file conflicts (especially good because the stdlib
>> itself has many multiply-defined symbols, duplicate header files, and
>> contradictory include path patterns)
>
> Yeah, Python has some issues with sys.path and how your local module
> can unexpectedly shadow a stdlib one, but at least the stdlib itself
> doesn't have any conflicts. I should not ever have to do this dance:
>
> #include <somefile.h>
> #undef SOME_SYMBOL
> #include <otherfile.h>
>
> But sadly, I do

I can remember resorting to #pragmas to print out clues to include 
order, when recursive includes were masking what on earth was going 
wrong.  Imagine, compile time printing.

Fortunately, in Forth and Python, there's much less distinction between 
compile time and run time.  And in Python, lots of metadata and 
reflection data is left lying around to be inspected in case of confusion.

Don't get me wrong, I love C++, even if I don't use it the way the 
purists would like.  But there are many warts that drive me up the wall, 
and consequently I avoid many features which could improve my C++ life. 
  I haven't found nearly as many in Python.


-- 
DaveA

[toc] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web