Noob question: Is all this typecasting normal?

[Russ P.]

That seems superficially like an easy distinction. Indeed, PEP 8
explicitly is meant to apply only to code intended for inclusion in
the Python standard library.

But consider:

Python libraries generally don't get into the standard library until
they've had a history of widespread public use as an external library.
This helps ensure many of the harder-to-find wrinkles get discovered
through wide exposure and ironed out before becoming standard.

Code bases, especially library interfaces, that get a lot of use
across wide communities are naturally going to have a whole lot of
other people's code directly using those interfaces.

Interfaces that are so widely used garner a high resistance to change,
especially for something as non-functional as a naming convention.

Choosing the naming convention for one's code is much easier to do
when its usage base is smaller than when that base is larger.
Therefore the easiest time to choose when to code in conformance to
PEP 8 is right at the start.

The best conclusion I can come to from this? Unless you explicitly
*never* intend sharing your code with *anyone*, it's best to code all
your Python code in accordance with PEP 8 anyway. You then don't have
to make the decision about whether this is the time to follow PEP 8 or
not; just do it by default, and you avoid the needless pain on those
occasions, often unforeseeable at the start, where your code later
ends up widely used.

--
 \       “One of the most important things you learn from the internet |
  `\   is that there is no ‘them’ out there. It's just an awful lot of |
_o__)                                            ‘us’.” —Douglas Adams |
Ben Finney

Fair enough, but for code that is not intended for general public
usage (i.e., most code) so-called camelCase is every bit as good if
not better than using underscores to divide variable names. It saves a
few characters, and in my opinion it's significantly easier to read.
Identifiers divided by underscores always appear to me at first glance
to be multiple words, and I find that very annoying.

So unless you think the standard library will someday include code for
air traffic management, I'll stick with camelCase, and I'll thank you
for not making an issue of it.

As far as I am concerned, this is one of the most important bits of
advice in PEP 8:

A Foolish Consistency is the Hobgoblin of Little Minds

 

[vk]

Any more word on userio?

None yet, I'm afraid. Should've started a different thread for it -
but it's stuck here (in obscurity) forever xd.

 

[Steven D'Aprano]

for each his own.

Please don't top-post.

Please don't quote the ENTIRE body of text (PLUS doubling it by including
a completely useless HTML version) just to add a trivial comment. Trim
the text you are replying to.

Any more word on userio?

I doubt many people care about it. Why don't you write it, put it up on
the Cheeseshop, and see if anyone uses it? Just because you think it is
useful doesn't mean others do, but if they do, then great.

 

[Steven D'Aprano]

But indeed, you obviously cannot add strings with numerics nor
concatenate numerics with strings. This would make no sense.

The OP comes from a Perl background, which AFAIK allows you to concat
numbers to strings and add strings to numbers. That's probably the (mis)
feature he was hoping Python had.

 

[sprad]

The OP comes from a Perl background, which AFAIK allows you to concat
numbers to strings and add strings to numbers. That's probably the (mis)
feature he was hoping Python had.

That's correct -- and that's been one of the more difficult parts of
my transition. Learned C++ in college, spent a few years doing Perl,
and now all of a sudden type matters again. It's a very different
philosophy, but I'm determined to stick with it until I have an Aha!
moment and find something I can do more easily than I can with Perl.

 

[Roy Smith]

That's correct -- and that's been one of the more difficult parts of
my transition. Learned C++ in college, spent a few years doing Perl,
and now all of a sudden type matters again. It's a very different
philosophy, but I'm determined to stick with it until I have an Aha!
moment and find something I can do more easily than I can with Perl.

The Aha! moment comes 6 months from now, when you discover that you can
understand the Python code you wrote 6 months ago, but the Perl code you
wrote at the same time has become gibberish, even to you.

The other day, I came upon this gem. It's a bit of perl embedded in a
Makefile; this makes it even more gnarly because all the $'s get doubled to
hide them from make:

define absmondir
$(shell perl -e ' \                                                        
                                  
sub absmon { my $$a = $$_[0]; \                                            
                                  
   if ( $$^O =~ m/cygwin|MSWin32/i ) {                                    
                                   
      $$prefix = `/bin/mount -p|awk "NR==2{print \\\$$1}"`;
chomp($$prefix); \
      $$a = ($$_[1]||"$(PWD)") . "/$$a" \
         unless ( $$a =~ m !^?$$prefix|/|[A-Za-z]! ); \
   } else { $$a = ($$_[1]||"$(PWD)") . "/$$a" unless ( $$a =~ m !^/! ); } \
   return unslash(undot(undotdot($$a))); }; \
sub unslash ($$) { $$_[0] =~ s://+:/:g; $$_[0] =~ s:/$$::; return($$_[0]);
}; \
sub undot ($$) { $$_[0]=~s:/\./:/:g; return ($$_[0]); }; \
sub undotdot ($$) { my $$in = $$_[0]; \
      return ( $$in =~ s:/[^/.][^/]*/\.\.::g )?undotdot($$in):$$in; }; \
print absmon("$(1)","$(2)"); \
' )                                                                        
                                  
endef

Barf-o-rama. I know what it's supposed to do, and I still can't figure it
out.

 

[James Mills]

I guess perl must have coercing for it's built-in
types ? *shrugs* To be honest, doing such operations
doesn't make much sense to me ... It's difficult to
correctly understand what the following expression
should evaluate to:
Traceback (most recent call last):

That's correct -- and that's been one of the more difficult parts of
my transition. Learned C++ in college, spent a few years doing Perl,
and now all of a sudden type matters again. It's a very different
philosophy, but I'm determined to stick with it until I have an Aha!
moment and find something I can do more easily than I can with Perl.

As mentioned string formatting is your friend

cheers
James

 

[Gabriel Genellina]

The other day, I came upon this gem. It's a bit of perl embedded in a
Makefile; this makes it even more gnarly because all the $'s get doubled
to
hide them from make:

define absmondir
$(shell perl -e ' \                                                    
sub absmon { my $$a = $$_[0]; \                                        
   if ( $$^O =~ m/cygwin|MSWin32/i ) {                                  
      $$prefix = `/bin/mount -p|awk "NR==2{print \\\$$1}"`;
chomp($$prefix); \
      $$a = ($$_[1]||"$(PWD)") . "/$$a" \
         unless ( $$a =~ m !^?$$prefix|/|[A-Za-z]! ); \
   } else { $$a = ($$_[1]||"$(PWD)") . "/$$a" unless ( $$a =~ m !^/! );
} \
   return unslash(undot(undotdot($$a))); }; \
sub unslash ($$) { $$_[0] =~ s://+:/:g; $$_[0] =~ s:/$$::;
return($$_[0]);
}; \
sub undot ($$) { $$_[0]=~s:/\./:/:g; return ($$_[0]); }; \
sub undotdot ($$) { my $$in = $$_[0]; \
      return ( $$in =~ s:/[^/.][^/]*/\.\.::g )?undotdot($$in):$$in; }; \
print absmon("$(1)","$(2)"); \
' )                                                                    
endef

Barf-o-rama. I know what it's supposed to do, and I still can't figure
it out.

Ouch! Me too, when I come to some piece of Perl code I've written some
years ago, I invariably think "what's all this noise?". Never happens with
other languages I've used in the past.

 

[J Kenneth King]

The other day, I came upon this gem. It's a bit of perl embedded in a
Makefile; this makes it even more gnarly because all the $'s get
doubled to
hide them from make:

define absmondir
$(shell perl -e ' \                                                
    sub absmon { my $$a = $$_[0]; \                                
           if ( $$^O =~ m/cygwin|MSWin32/i ) {                    
                    $$prefix = `/bin/mount -p|awk "NR==2{print
\\\$$1}"`;
chomp($$prefix); \
      $$a = ($$_[1]||"$(PWD)") . "/$$a" \
         unless ( $$a =~ m !^?$$prefix|/|[A-Za-z]! ); \
   } else { $$a = ($$_[1]||"$(PWD)") . "/$$a" unless ( $$a =~ m !^/!
); } \
   return unslash(undot(undotdot($$a))); }; \
sub unslash ($$) { $$_[0] =~ s://+:/:g; $$_[0] =~ s:/$$::;
return($$_[0]);
}; \
sub undot ($$) { $$_[0]=~s:/\./:/:g; return ($$_[0]); }; \
sub undotdot ($$) { my $$in = $$_[0]; \
      return ( $$in =~ s:/[^/.][^/]*/\.\.::g )?undotdot($$in):$$in; }; \
print absmon("$(1)","$(2)"); \
' )                                                                
    endef

Barf-o-rama. I know what it's supposed to do, and I still can't
figure it out.

Ouch! Me too, when I come to some piece of Perl code I've written some
years ago, I invariably think "what's all this noise?". Never happens
with other languages I've used in the past.

I still occassion upon the chance to write some Perl, and even as a
full-time developer who works with Python for a living, I relish every
opportunity.

The funny thing is that I've never had the problem of writing code like
this in Perl. The example is a very poor use-case and doesn't reflect on
the useful/useless-ness of the language itself but more on the choices
of the implementor.

Perl is a very useful language overall and when used properly, very
powerful.

 

[Aahz]

[following up late]

Fair enough, but for code that is not intended for general public
usage (i.e., most code) so-called camelCase is every bit as good if
not better than using underscores to divide variable names. It saves a
few characters, and in my opinion it's significantly easier to read.
Identifiers divided by underscores always appear to me at first glance
to be multiple words, and I find that very annoying.

So unless you think the standard library will someday include code for
air traffic management, I'll stick with camelCase, and I'll thank you
for not making an issue of it.

You are missing the point: suppose you write a useful library in your air
traffic management application, maybe one that does a good job of
handling user input. If you have done a proper job of abstracting it
from your application as a whole, you could easily publicize it, but it
will never get into the standard library unless it meets current PEP8
guidelines. Why fuss about trying to figure out which parts of your
application might in the future be published?
--
Aahz ([email protected]) <*> http://www.pythoncraft.com/

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are, by
definition, not smart enough to debug it." --Brian W. Kernighan

 

[Steven D'Aprano]

You are missing the point: suppose you write a useful library in your
air traffic management application, maybe one that does a good job of
handling user input. If you have done a proper job of abstracting it
from your application as a whole, you could easily publicize it, but it
will never get into the standard library unless it meets current PEP8
guidelines. Why fuss about trying to figure out which parts of your
application might in the future be published?

You know, it is quite possible that some people may not care whether or
not their code ends up in the standard library. Holding out the
possibility of inclusion in the std lib may not be quite the
encouragement you expect

 

[Tim Rowe]

So unless you think the standard library will someday include code for
air traffic management, I'll stick with camelCase, and I'll thank you
for not making an issue of it.

Another late comment, sorry, but as an air traffic management safety
consultant, I'm quite interested about where in ATM you plan to use
Python code, and how you will be meeting the applicable safety
standards in the relevant administration.