Re: Class Issue`
On 2019-03-06, Marko Rauhamaa wrote: > Rhodri James : >> On 06/03/2019 14:15, Calvin Spealman wrote: C++ (a language I have no respect for) >>> This was uncalled for and inappropriate. Please keep discord civil. >> >> That was the civil version :-) > > C++ is a programming language without feelings. I dunno about that -- I've had to maintain C++ code on a couple projects, and I'm pretty sure C++ hates _me_. > It's nobody's ethnicity, sexual orientation, race or religion, > either. You can despise it freely. And I think I've know people for whom it is their religion. :) That said, I don't think that stating ones lack of respect for some particular programming language is uncivil -- particularly compared to the things I've said about PHP in the past (maybe not in this group). -- Grant Edwards grant.b.edwardsYow! I just heard the at SEVENTIES were over!! And gmail.comI was just getting in touch with my LEISURE SUIT!! -- https://mail.python.org/mailman/listinfo/python-list
Re: Class Issue`
Rhodri James : > On 06/03/2019 14:15, Calvin Spealman wrote: >>> C++ (a language I have no respect for) >> This was uncalled for and inappropriate. Please keep discord civil. > > That was the civil version :-) C++ is a programming language without feelings. It's nobody's ethnicity, sexual orientation, race or religion, either. You can despise it freely. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Class Issue`
On 06/03/2019 14:44, Chris Angelico wrote: Ouch, did C++ burn you in the past? I've tried and failed to learn the language three times. It's been suggested that my mistake was using Stroustrop's book :-) There just seem to be so much boilerplate and fiddly bits that it quickly gets too complex to hold a project design in my head. Python, by contrast, Just Worked and showed me how to think about OO design without half the drama. Sounds like Rhodri has strong expectations about how languages should behave, and C++ does fulfil this. So maybe there's some respect here after all:) Fine, you've got me there :-) -- Rhodri James *-* Kynesim Ltd -- https://mail.python.org/mailman/listinfo/python-list
Re: Class Issue`
On Thu, Mar 7, 2019 at 1:34 AM Rhodri James wrote: > > On 06/03/2019 14:15, Calvin Spealman wrote: > >> C++ (a language I have no respect for) > > This was uncalled for and inappropriate. Please keep discord civil. > > That was the civil version :-) > Ouch, did C++ burn you in the past? IMO it's a language that has way too many features stuffed into it (yes, the language, not just the standard library - the actual syntax is overly complicated IMO), but it isn't an abysmal language. There *are* horrendous languages in the world, and C++ is not one of them. That said, though, saying "I have no respect for" is a reasonably civil statement, but perhaps factually wrong. Here it is in context: > The behaviour you should expect even from C++ (a language I have no > respect for) is a compile-time error complaining that you are passing an > integer to a string parameter and vice versa. Sounds like Rhodri has strong expectations about how languages should behave, and C++ does fulfil this. So maybe there's some respect here after all :) But it wasn't terribly uncivil. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Class Issue`
On 06/03/2019 14:15, Calvin Spealman wrote: C++ (a language I have no respect for) This was uncalled for and inappropriate. Please keep discord civil. That was the civil version :-) -- Rhodri James *-* Kynesim Ltd -- https://mail.python.org/mailman/listinfo/python-list
Re: Class Issue`
> C++ (a language I have no respect for)
This was uncalled for and inappropriate. Please keep discord civil.
On Wed, Mar 6, 2019 at 7:12 AM Rhodri James wrote:
> On 05/03/2019 22:39, Milt wrote:
> > The following code gives me unusual results - base on experience with
> C++.
> >
> > class Car:
> > # carColor = None
> > # mileage = None
> >
> > def __init__(self, color = None, miles = None):
> >self.mileage = miles
> >self.carColor = color
> >
> > def print(self):
> >print(f"Color: {self.carColor}")
> >print(f"Mileage: {self.mileage}")
> >
> > myCar = Car('blue', 15000)
> > myCar.print()
> >
> > print()
> >
> > myCar = Car(25000, 'orange')
> > myCar.print()
>
> The behaviour you should expect even from C++ (a language I have no
> respect for) is a compile-time error complaining that you are passing an
> integer to a string parameter and vice versa. Python is a dynamically
> typed language; it doesn't enforce any restrictions on what types of
> object can be bound to any given name. This is occasionally a surprise
> when you're being careless, but it really shouldn't break your
> expectations.
>
> --
> Rhodri James *-* Kynesim Ltd
> --
> https://mail.python.org/mailman/listinfo/python-list
>
--
CALVIN SPEALMAN
SENIOR QUALITY ENGINEER
cspea...@redhat.com M: +1.336.210.5107
TRIED. TESTED. TRUSTED.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Class Issue`
On 05/03/2019 22:39, Milt wrote:
The following code gives me unusual results - base on experience with C++.
class Car:
# carColor = None
# mileage = None
def __init__(self, color = None, miles = None):
self.mileage = miles
self.carColor = color
def print(self):
print(f"Color: {self.carColor}")
print(f"Mileage: {self.mileage}")
myCar = Car('blue', 15000)
myCar.print()
print()
myCar = Car(25000, 'orange')
myCar.print()
The behaviour you should expect even from C++ (a language I have no
respect for) is a compile-time error complaining that you are passing an
integer to a string parameter and vice versa. Python is a dynamically
typed language; it doesn't enforce any restrictions on what types of
object can be bound to any given name. This is occasionally a surprise
when you're being careless, but it really shouldn't break your expectations.
--
Rhodri James *-* Kynesim Ltd
--
https://mail.python.org/mailman/listinfo/python-list
Re: Class Issue`
On 3/5/2019 6:11 PM, Kevin Hu wrote: Python is a language with very weak typing, Python runtime objects are strongly dynamically typed. Their type/class is one of their attributes. All classes are subclasses of class 'object'. Python names (variables) are untyped in a sense, or one could say their default type is 'object'. and it’ll happily shoehorn data into variables This describes C, which puts data into permanently names blocks of memory. Python puts data into objects, not names. It associates names/variables with objects. it’ll assign arguments to parameters in order, which is the expected behavior. Parameters are names and arguments are objects. Yes, if the arguments are not named in a called, they named in order. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Class Issue`
On 3/5/19, Kevin Hu wrote: > > Python is a language with very weak typing, and it’ll happily shoehorn data > into variables even when you don’t expect it to. Python has strong typing, in that it doesn't implicitly coerce unrelated types in expressions. However, it has no enforced static typing of variables. It relies on runtime type checking and protocols. The term "duck typing" was coined for this case. -- https://mail.python.org/mailman/listinfo/python-list
Re: Class Issue`
Milt,
On 6/03/19 11:39 AM, Milt wrote:
The following code gives me unusual results - base on experience with C++.
class Car:
# carColor = None
# mileage = None
def __init__(self, color = None, miles = None):
self.mileage = miles
self.carColor = color
def print(self):
print(f"Color: {self.carColor}")
print(f"Mileage: {self.mileage}")
myCar = Car('blue', 15000)
myCar.print()
print()
myCar = Car(25000, 'orange')
myCar.print()
When executed the following results:
Color: blue
Mileage: 15000
Color: 25000
Mileage: orange
It appears that the constructor ignores the assignment statements and
makes the assignment based on the ordering in the __init__ declaration.
It is risky to decide that Python should behave in a certain fashion,
just because another language does. Would you decide that the word
"blue" may not be used because in French it is "bleu"? If all
programming languages did look/work the same way, why would there be
multiple languages? However, your understanding of C++ gives you a
flying start with Python - apart from a few pesky 'gotchas'!
In the term "ignores the assignment statements", what "assignment
statements" are being discussed?
Yes, without keywords, the positional rule applies.
myCar = Car('blue', 15000)
is the same as:
myCar = Car(color = 'blue', miles = 15000)
Instead of:
myCar = Car(25000, 'orange')
try:
myCar = Car(miles=25000, color='orange')
If you've gone to the trouble of defining keyword-arguments in the
method, greater satisfaction will be gained from calling the method
similarly (and cause less confusion on the part of your readers!)
Meantime I have a very low-mileage Edsel in an attractive lemon color,
going cheap...
Jokes aside: using the __str__() and __repr__() "magic methods" is more
'pythonic' than adding a print method to a class.
For a nicely-formatted output (albeit without mentioning that it is
describing a "Car" or "myCar" - per print(), above):
def __str__(self):
return f"Color: {self.carColor}\nMileage: {self.mileage}"
...
myCar = Car(color = 'blue', miles = 15000)
print( myCar )
For extra credit, seeing we're talking about 'being pythonic': car_color
and my_car.
Alternately, to present the output formatted as a class definition/ready
for instantiation:
def __repr__(self):
return f"Car( color={self.car_color}, miles={self.mileage} )"
NB if both methods appear in a class, printing the class (ie print(
my_car ) ) will prefer __repr__() over __str__().
All the best...
--
Regards =dn
--
https://mail.python.org/mailman/listinfo/python-list
Re: Class Issue`
I believe for the correct behavior you’ll need:
myCar = Car(color=‘blue’, miles=15000)
myCar = Car(miles=25000, color=‘orange’)
In which case both objects will be initialized as the way you’d expect.
Python is a language with very weak typing, and it’ll happily shoehorn data
into variables even when you don’t expect it to. In this case it’ll assign
arguments to parameters in order, which is the expected behavior.
Regards,
Kevin
> On Mar 5, 2019, at 16:39, Milt wrote:
>
> The following code gives me unusual results - base on experience with C++.
>
> class Car:
># carColor = None
># mileage = None
>
>def __init__(self, color = None, miles = None):
> self.mileage = miles
> self.carColor = color
>
>def print(self):
> print(f"Color: {self.carColor}")
> print(f"Mileage: {self.mileage}")
>
> myCar = Car('blue', 15000)
> myCar.print()
>
> print()
>
> myCar = Car(25000, 'orange')
> myCar.print()
>
>
> When executed the following results:
>
> Color: blue
> Mileage: 15000
>
> Color: 25000
> Mileage: orange
>
> It appears that the constructor ignores the assignment statements and makes
> the assignment based on the ordering in the __init__ declaration.
> --
> Regards,
>
> Milt
>
> --
> https://mail.python.org/mailman/listinfo/python-list
--
https://mail.python.org/mailman/listinfo/python-list
Re: Class Issue`
On Wed, Mar 6, 2019 at 10:01 AM Milt wrote:
>
> The following code gives me unusual results - base on experience with C++.
> def __init__(self, color = None, miles = None):
>self.mileage = miles
>self.carColor = color
>
> myCar = Car('blue', 15000)
> myCar = Car(25000, 'orange')
>
> It appears that the constructor ignores the assignment statements and
> makes the assignment based on the ordering in the __init__ declaration.
Based on your experience with C++, what tells the compiler that you
can pass arguments in any order? Would you write multiple constructors
taking different arguments? Because you didn't do that here.
What you CAN do is call the constructor with keyword arguments:
Car(color='blue', miles=15000)
Car(miles=25000, color='orange')
But otherwise, Python (just like C++) will pass the arguments in the
order you wrote them.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Class Issue`
The following code gives me unusual results - base on experience with C++.
class Car:
# carColor = None
# mileage = None
def __init__(self, color = None, miles = None):
self.mileage = miles
self.carColor = color
def print(self):
print(f"Color: {self.carColor}")
print(f"Mileage: {self.mileage}")
myCar = Car('blue', 15000)
myCar.print()
print()
myCar = Car(25000, 'orange')
myCar.print()
When executed the following results:
Color: blue
Mileage: 15000
Color: 25000
Mileage: orange
It appears that the constructor ignores the assignment statements and
makes the assignment based on the ordering in the __init__ declaration.
--
Regards,
Milt
--
https://mail.python.org/mailman/listinfo/python-list
