Rép : Why is str(None) == 'None' and not an empty string?
On 8/28/2013 4:57 AM, Piotr Dobrogost wrote: > Having repr(None) == 'None' is sure the right thing but why does str(None) == > 'None'? Wouldn't it be more correct if it was an empty string? the point of str(obj) is to return a string containing the obj (a sequence of characters if it is unbound or not built-in, etc.)... If you set the rule str(None)=="", then you will cause plenty of problems. For instance, if you want to build a string like request="SELECT X"+"IN Y"+"WHERE B="+String(B) to prepare a sequel request, and the field B happens to be sometimes "None", you would automatically end up with """SELECT X IN Y WHERE B=''""" instead of """SELECT X IN Y WHERE B='None'""", and your sql request will fall into limbos... -- http://mail.python.org/mailman/listinfo/python-list
Re: Interface and duck typing woes
Le 29 août 2013 à 00:56, python-list-requ...@python.org a écrit :
"""While designing a simple library, I found myself asking a
philosophical question: to check or not to check the parameter's
interface?
I think that, considering it is Python, the usual answer would be
"no", but here is the situation that got me thinking:
class Flock:
def __init__(self):
self.ducks= []
def do_stuff(self):
for duck in self.ducks:
duck.quack()
class Duck:
def quack(self):
#quack-quack
pass
f = Flock()
d = Duck()
f.ducks.append(d)
f.do_stuff()
Ok, no big deal there, the problem is if the user forgets to implement
the quack() method. The stack trace would complain that "duck.quack()"
is wrong, but that can happen hundreds of lines after the user
actually added the object to the Flock, and it can be hard to find out
what is happening and which object is wrong.
Of course I don't want to check isistance(), I like duck typing, but
should I check if hasattr() and callable() before adding to the
container? What is the pythonic way to deal with it? Am I worrying too
much ;-)?
Thanks,
Joe"""
Hey Joe,
I am no depository of the pythonic way to think(tm) but I would create flock
and inherit Duck from flock, or possibly set Flock as a method of ducks.
that would look like this:
class Flock():
def __init__(self, flock):
self.flock=flock
class Duck(Flock):
def __init(self, flock):
super().__init__(flock)
then you only need to create some functions for any object to display the lists
and or dicts that you will create outside these classes, in the main or in
another function...
you just instantiate them like that:
Donald=Duck('Donald')
or (rather):
flock=[]
flock.append(Duck('Donald'))
one big advantage with this method is, you can creat plenty of other bird
classes and append them to a list.
Alternatively, you could have just one class Flock and then set duck as an
attribute of flock, and set a list of your flock as a private attribute (the
self.duck thing in your code... Well... Could be handled in a better way...)
but that is another story, the one before is way simpler for your purpose.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Is there a function that applies list of functions to a value?
On Friday, August 30, 2013 8:23:44 AM UTC+2, alex23 wrote: > On 30/08/2013 4:14 PM, fp2...@gmail.com wrote: > > > For this purpose however, I suspect that a named function with a proper > > docstring that can be imported and reused over and over again is probably > > more appropriate than a lambda > > > > Given that in Chris' example the lambda was returned from a factory, > > importing the inner function by name is never going to be a concern. > > > > It's also possible to assign to both __name__ and __doc__ for a lambda, > > which can be useful at times. I am sorry, I can't see any of Chris' code in this thread, where is it??? -- http://mail.python.org/mailman/listinfo/python-list
Re: Is there a function that applies list of functions to a value?
On Friday, August 30, 2013 8:36:40 AM UTC+2, alex23 wrote:
> On 30/08/2013 4:17 PM, fp2...@gmail.com wrote:
>
> > On Wednesday, August 28, 2013 8:50:53 PM UTC+2, Josh English wrote:
>
> >> def compose(*funcs):
>
> >> for func in funcs:
>
> >> if not callable(func):
>
> >> raise ValueError('Must pass callable functions')
>
>
>
> > Imho still, the ValueError you are raising is not that important in this
> > context, it would raise an Error anyway.
>
>
>
> The main advantage with Josh's approach is that it fails at the point of
>
> composition, not when the composed function is first used. It'd be even
>
> more useful if it aggregated a list of the failing functions and
>
> returned their names as part of the error.
>
>
>
> Personally, I'd go with an assertion:
>
>
>
> assert all(map(callable, funcs)), "Must pass callable functions"
>
>
>
> I find that it makes it more obvious that this is part of the function
>
> contract rather than the actual body.
it is a valid point, but I would contend that it makes this quick and easy code
a little bit heavy just for the sake of ensuring that you are composing
composable functions... The assertion is definitely better.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Encapsulation unpythonic?
On Saturday, August 17, 2013 2:26:32 PM UTC+2, Fernando Saldanha wrote: > I am new to Python, with experience in Java, C++ and R. > > > > As I understand encapsulation is not a big thing in the Python world. I read > that you can put two underscores before the name of a variable within a class > declaration but in the many examples of code I looked at this is not widely > used. I also read that encapsulation is "unpythonic." > > > > Questions: > > > 2) If it is in fact true that encapsulation is rarely used, how do I deal > with the fact that other programmers can easily alter the values of members > of my classes? > Fernando, it is widely accepted that Python pays very little attention to encapsulation as a principle set in stone. Chaz's definition of encapsulation is also mine. Now you need to consider that taking this principle off the hostel of OOP does not mean that you can do whatever you fancy and you can't make anything unsettable. There are plenty of techniques within Python that allow you to protect your arguments (in particular, decorators) inside a Class. Now, lets get to the pretentious philosophical discussion: I guess encapsulation is quite the opposite of, say, dynamic typing, which is arguably core in Python. In practice this allows Python to be less verbose: at the end of the day, if you look back at your previous languages, don't you find that some of their compulsory features are usually more of a pain than something useful in practice? And after all, whither encapsulation? Can't we just have objects whose arguments are determined externally if we want to? And that is the ballgame: as my old tutor says: "the claptrap of setters and getters does not need to be here if it is unnecessary". I would add: "so long as you can have them when you deem it necessary", and Python allows that. -- http://mail.python.org/mailman/listinfo/python-list
Re: Encapsulation unpythonic?
On Saturday, August 31, 2013 4:35:39 AM UTC+2, Steven D'Aprano wrote:
> On Fri, 30 Aug 2013 10:43:28 -0700, Fabrice Pombet wrote:
>
>
>
> > On Saturday, August 17, 2013 2:26:32 PM UTC+2, Fernando Saldanha wrote:
>
>
>
> >> 2) If it is in fact true that encapsulation is rarely used, how do I
>
> >> deal with the fact that other programmers can easily alter the values
>
> >> of members of my classes?
>
> >>
>
> > Fernando, it is widely accepted that Python pays very little attention
>
> > to encapsulation as a principle set in stone.
>
>
>
> Widely accepted by whom?
>
most people(except you, apparently, but I fear that you do not really accept in
general)
>
>
> Python code is *full* of encapsulation. Functions, methods, classes,
>
> modules, packages, even local variables, are all mechanisms for
>
> encapsulating code and data. Those who say that Python has little or no
>
> encapsulation are talking rubbish.
> > Chaz's definition of
>
> > encapsulation is also mine.
>
>
>
> Who is Chaz, and what definition does he have?
See above me chaz...@gmail.com, the definition of encapsulation from his OST
course is fine by y standards, quoting him:
"I'm taking the Python Cert series w/ O'Reilly School of Technology, which I
recommend if you've got a good handle on OO programming. In any event,
according to what I've learned, "encapsulation is the idea that the only way to
access or change the data inside an object is by calling its methods. This idea
has never really gained much ground in the Python world, and it is normally
considered acceptable to both read and set an object's attributes from anywhere
in a program."
Keep in mind that we are talking about Encapsulation(a general/philosophical
principle) as opposed to encapsulating (i.e. setting an argument so that it can
only be read/written from within its class/object)
this is a key conceptual point. I agree with you that Python allows you to
enforce the encapsulation principle within your code, whenever you want it. But
not as a principle that you NEED to respect(as in Java for instance). It is, in
my opinion, much better this way.
> And now you are talking about information hiding and protection, which is
>
> not the same of encapsulation, no matter what the academics think.
>
> Sometimes the air gets a bit too thin to breathe way up at the top of
>
> those ivory towers...
>
I am no academic, and I think that's right.
>
>
> Encapsulation is about grouping code that needs to be together together.
>
> In contract, you have programming languages that give you little, or
>
> nothing, in the way of grouping -- everything is one big chunk of code,
>
> with GOTO or GOSUB to jump from place to place.
>
>
I think that I prefer chaz' definition (it is, how could I put it... A tad
easier to understand)
>
> Functions and procedures are the first, most simple, form of
>
> encapsulation. Classes allow you to encapsulate multiple functions
>
> ("methods") together with the data they need to operate on in one chunk.
>
> Even in C++ or Java, you can have classes that provide no information
>
> hiding at all -- just declare everything "public".
>
>
>
> On the other hand, non-OOP languages like C can implement information
>
> hiding. In C, you can hide information from other files by declaring them
>
> as "static". Variables declared inside a brace-delimited block only exist
>
> within that block: local variables are hidden. For example:
>
>
>
> int foo;
>
> static int bar;
>
>
>
>
>
> bar is hidden from other files. Likewise, in this function:
>
>
>
>
>
> int func(void) {
>
>int baz;
>
>...
>
> }
>
>
>
>
>
> baz is local to func, and invisible to any other function.
>
>
>
> So you can have information hiding without classes, and classes without
>
> information hiding. The two concepts are obviously independent, but as
>
> usual, the academics who are in love with OOP like to pretend that
>
> anything that is of any interest whatsoever in computing was invented by
>
> Java and C++.
>
>
>
> There are even languages with functions, but no local variables. For
>
> instance, older versions of Forth let you define functions, what Forth
>
> calls "words", but all functions operate on the same global stack.
>
>
>
> Python has excellent encapsulation: we can combine code that ought to be
>
>
Re: Encapsulation unpythonic?
On Saturday, August 31, 2013 9:03:58 AM UTC+2, Gary Herron wrote:
> On 08/30/2013 11:07 PM, Fabrice Pombet
> wrote:
>
>
> ... long discussion elided ...
>
> well, look at that:
>
> a=(1,2)
> a=2+3 ->a is an object and I have changed its type and value from outside. As
> far as I am concerned this is one hell of an encapsulation violation... Could
> you do this -strictly speaking- in Java or C++?
>
>
>
>
> Yes, in fact you can do that in C++ and java:
>
>
>
> Obj1 a = ...some object...;
>
> { // new scope...
>
> Obj2 a = ...another object...;
>
> }
>
>
>
> On one line, the name 'a' is bound to one object, and later it is
> bound to another object. Your Python code is similar, binding the
> name 'a' to object (1,2) on one line and the object 5 on the next
> line. Granted, Python seems a little freer because, with it's
> dynamic typing, one doesn't need to create a new scope to rebind a
> name, but all languages with variable names allow some control over
> binding/rebinding names.
>
>
>
> But this has *nothing* at all to do with objects and encapsulation.
>
>
>
> Please don't confuse:
>
> the binding of names to objects and
>
>
>
> the existence of objects and their encapsulated behavior
>
>
> They are very different things.
>
>
>
> --
> Dr. Gary Herron
> Department of Computer Science
> DigiPen Institute of Technology
> (425) 895-4418
That's interesting, can you do this in C++ or java:
class X():
--
http://mail.python.org/mailman/listinfo/python-list
Re: Encapsulation unpythonic?
On Saturday, August 31, 2013 9:42:55 AM UTC+2, Fabrice Pombet wrote:
> On Saturday, August 31, 2013 9:03:58 AM UTC+2, Gary Herron wrote:
>
> > On 08/30/2013 11:07 PM, Fabrice Pombet
>
> > wrote:
>
> >
>
> >
>
> > ... long discussion elided ...
>
> >
>
> > well, look at that:
>
> >
>
> > a=(1,2)
>
> > a=2+3 ->a is an object and I have changed its type and value from outside.
> > As far as I am concerned this is one hell of an encapsulation violation...
> > Could you do this -strictly speaking- in Java or C++?
>
> >
>
> >
>
> >
>
> >
>
> > Yes, in fact you can do that in C++ and java:
>
> >
>
> >
>
> >
>
> > Obj1 a = ...some object...;
>
> >
>
> > { // new scope...
>
> >
>
> > Obj2 a = ...another object...;
>
> >
>
> > }
>
> >
>
> >
>
> >
>
> > On one line, the name 'a' is bound to one object, and later it is
>
> > bound to another object. Your Python code is similar, binding the
>
> > name 'a' to object (1,2) on one line and the object 5 on the next
>
> > line. Granted, Python seems a little freer because, with it's
>
> > dynamic typing, one doesn't need to create a new scope to rebind a
>
> > name, but all languages with variable names allow some control over
>
> > binding/rebinding names.
>
> >
>
> >
>
> >
>
> > But this has *nothing* at all to do with objects and encapsulation.
>
> >
>
> >
>
> >
>
> > Please don't confuse:
>
> >
>
> > the binding of names to objects and
>
> >
>
> >
>
> >
>
> > the existence of objects and their encapsulated behavior
>
> >
>
> >
>
> > They are very different things.
>
> >
>
> >
>
> >
>
> > --
>
> > Dr. Gary Herron
>
> > Department of Computer Science
>
> > DigiPen Institute of Technology
>
> > (425) 895-4418
>
>
>
> That's interesting, can you do this in C++ or java:
>
>
>
> class X():
def __init__(self, *arg):
for x in arg:
self.x=x
and then:
a=X("x","y","z")
and then:
a.w="w"
?
I guess my point was dynamic typing and encapsulation go a little in opposite
directions in terms of philosophy, and it is therefore clear that Python
privileges "dynamic typing" kind of thinking over encapsulation as a
philosophical stance. Am I the only one thinking like this?
--
http://mail.python.org/mailman/listinfo/python-list
Re: Encapsulation unpythonic?
> > http://nedbatchelder.com/text/names.html > > > > --Ned. This is an excellent explanation, thank you. It is mostly of theoretical interest though, and in practice, I still contend that the consequences towards the syntax are (or seem, if you prefer) analogous to those of the lack of encapsulation. -- http://mail.python.org/mailman/listinfo/python-list
Re: Encapsulation unpythonic?
On Saturday, August 31, 2013 1:46:52 PM UTC+2, Steven D'Aprano wrote: > On Fri, 30 Aug 2013 23:07:47 -0700, Fabrice Pombet wrote: > > > > > well, look at that: > > > > > > a=(1,2) > > > a=2+3 ->a is an object and I have changed its type and value from > > > outside. > > > > Incorrect. You have not changed the type or value of any object. "a" is > > not an object, it is a *name*, and while you can change the object bound > > to the name, the objects remain unchanged. > > > > When you do this: > > > > x = 23 > > x = 42 > > > > the *object* 23 does not change, only the name binding changes. To do > > otherwise would cause all sorts of surprises: > > > > # THIS DOES NOT HAPPEN IN PYTHON > > # or any other language, as far as I am aware > > x = 23 > > y = x # y now has the value 23 > > x = 42 # change the value of the object ### NOT SO! ### > > print y > > => prints 42 > > > > Name binding (assignment) does not change objects. It changes the link > > between a name and the object, but the object remains untouched (unless > > it is unbound, and garbage collected). Assignment is not mutation. > > Assigning to a name does not modify the object that was previously bound. > > > > > > But even if you were right about changing the type and value of objects > > in place -- Python allows you to mutate lists and dicts in place, and > > even mutate the type of some objects, although not built-ins -- your > > understanding is still confused. Re-assignment (re-binding) of local > > variables is hardly a violation of encapsulation. But if it was, then > > Java and C++ have no encapsulation either, because you can re-assign to > > local variables inside a function too. > > > > If you want to see a language without encapsulation, you need to look at > > something like 1970s-style BASIC, a language where all variables are > > global, where there is no support for grouping related code into separate > > modules or files, where the closest thing to a function call is GOTO or > > GOSUB. > > > > Of course, languages can have *more* or *less* encapsulation than other > > languages. C lets you encapsulate related functions into a file, but it > > has no way of grouping data and functions together except loosely, in a > > file. C++ adds classes, which has more encapsulation since you can group > > functions and their data together. > > > > > > > > > As far as I am concerned this is one hell of an encapsulation > > > violation... Could you do this -strictly speaking- in Java or C++? > > > > Of course you could. All you need is a way to tell the compiler not to > > type-check the variable "a". Or more practically, some way to declare > > variable "a" as a reference to an untyped or generic value. C# has the > > dynamic keyword for this functionality. I don't know about Java or C++, > > but the JVM is certainly capable of implementing dynamic typing as there > > are various dynamically-typed languages built on top of the JVM, such as > > OpenXION and Cobra. > -- > > Steven Steve, I think that your definition of encapsulation is too wide to give a reasonable answer to the question at hand. If I understand you correctly, you are taking encapsulation as a language characteristic, rather than a principle. Plus, you seem to forget that encapsulation is an OOP principle, and, forgive me if I am wrong, does not apply normally to functions or languages like C. Please read Steve Holden's (in chaz') definition, and tell us whether you think that Python enforces strongly this principle, I think that would be a good basis for an agreement. My answer is no, it doesn't, but it allows you to abide by it if you want to. Unlike Java or C++ who would tend to do exactly the contrary (enforces it strictly, and (possibly?) allow you to discard it at times with a few jiffies (or not? I don't know)) -- http://mail.python.org/mailman/listinfo/python-list
Re: Encapsulation unpythonic?
> That said, though, when you consider the language ecosystem rather > > than just the language, there is a strong tendency for Java and C++ > > code to wrap everything up with functions (no public data members), > > whereas Python code is far more likely to have external code directly > > access data inside an object. You usually will find Java code calling > > methods to change members, whereas that's done in Python only when > > there's a need for it. Yep, this is precisely my point, if you take encapsulation as a philosophical principle, Java and C++ would tend to be abiding by it, as a "default" setting that you can at times change, whereas python would tend to be the contrary. In other words, you can set some encapsulation if and when you want to, but you can leave your code without it when it's not needed/inconvenient. So I guess that we are actually all agreeing on this one. -- http://mail.python.org/mailman/listinfo/python-list
