Re: skipping __init__ and using exploiting a class member instead
>The use of getattr here seems unfortunate Unfortunate how? It's a perfect for what I want here ... remember the context is such that the lazily stored value is always truthy (I assert this elsewhere). > I'm not sure why you want to avoid an __init__ method. Why do you want to keep it? The more code you write the more bugs you write. Who knows, maybe I screw up the argument pass to the super __init__. Maybe I screw up the super reference. Didn't Einstein say make it as simple as possible, but no simpler? Personally, I find the ability of Python to subclass without overriding the constructor very elegant. I don't believe the other languages I've worked in can do this (C++, C#, Java)... or if there is a way it's a bit scary and discouraged. Whereas skipping the __init__ seems to be a standard part of the Python OO development process. Again, this is just the lazy eval pattern. In C#, for example, I'd write my constructors but refer to _lazy only in the foo function and in it's declaration line (which would explicitly default initialize it). At any rate, the second idiom is very pretty to me, I'm keeping it unless a compelling argument is presented. Thanks for the kibbutzing though, the first idiom was poor form, as I suspected. -- https://mail.python.org/mailman/listinfo/python-list
Re: converting letters to numbers
On Monday, October 14, 2013 10:32:36 AM UTC+5:30, Steven D'Aprano wrote: > On Sun, 13 Oct 2013 20:13:32 -0700, Tim Roberts wrote: > > > def add(c1, c2): > > % Decode > > c1 = ord(c1) - 65 > > c2 = ord(c2) - 65 > > % Process > > i1 = (c1 + c2) % 26 > > % Encode > > return chr(i1+65) > > Python uses # for comments, not %, as I'm sure you know. What language > were you thinking off when you wrote the above? Maybe Tim was putting in the percentage of CPU cycles (wetware cycles??) on Decode, Process and Encode. So we have the % but not the percent… -- https://mail.python.org/mailman/listinfo/python-list
Re: skipping __init__ and using exploiting a class member instead
> Why not simply have one, and use it to initialize your attributes, > even if it is to None? Think about it this way. None here really means "not yet initialized". It is a value that cannot occur naturally and thus functions as a not-initialized flag. But for different contexts, this value could be almost anything. It might even be truthy. So this, somewhat arbitrary, context sensitive value should be isolated as much as possible. You don't want it popping up hither and yon, you want to type as infrequently as possible and localized it to as few methods as possible. For example, look at this version of the idiom class Foo (Bar) : def foo(self, x) : if (getattr(self, "_lazy", -1) < 0 ) : self._lazy = self._count_something(x) assert (self._lazy >= 0) # a negative count is a bug not a bad data entry def count_something(self, x) : # if it's really counting something, it will return a natural number Now you really want that -1 in an __init__ method instead of the foo method? Isn't that asking for trouble when somebody copies this and rewrites it? They could change the boolean expressions in foo (i.e. < 0 means compute it, >= sanity checks the result) but fail to change the proper flag for not-yet-computed (-1) if these things are in two different methods. My way, it's all in one place. Good little idiom to ponder though. I like fussing over these things. Any good gambler develops clean habits to improve his odds, even if each act of hygiene changes the odds but slightly. I wouldn't complain if a co-worker coded this your way, but I still think it is cleaner my way. -- https://mail.python.org/mailman/listinfo/python-list
Re: Looking for UNICODE to ASCII Conversioni Example Code
On 20/10/2013 03:13, Roy Smith wrote: In article , Chris Angelico wrote: Heck, I can't even really move off 2.6 because we use Amazon's EMR service, which is stuck on 2.6. Hrm. 2.6 is now in source-only security-only support, and that's about to end (there's a 2.6.9 in the pipeline, and that's that). It's about time Amazon moved to 2.7, at least... Tell that to Amazon. Dear Amazon, Please upgrade to Python 3.3 or similar so that users can have better unicode support amongst other things. Love and kisses. Mark. -- Roses are red, Violets are blue, Most poems rhyme, But this one doesn't. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Detecting whether a value was passed for a parameter (was: skipping __init__ and using exploiting a class member instead)
Peter Cacioppi writes: > I was laboring under some misconception that there was Python magic > that allowed __init__ and only __init__ to add class attributes by > setting their values. Good to know this piece of magic isn't part of > Python, and thus lazy eval can be handled more cleanly than I > originally thought. Rather, the magic is that ‘__init__’ will be called automatically by the class creation protocol, to initialise any new instance of that class. So the method to write if you want instance-specific initialisation is still ‘__init__’. > Think about it this way. None here really means "not yet initialized". > It is a value that cannot occur naturally and thus functions as a > not-initialized flag. As you point out, though, that's not a menaing of None agreed on everywhere. You can't expect that the caller will not be passing a value of None for that parameter. > So this, somewhat arbitrary, context sensitive value should be isolated > as much as possible. You don't want it popping up hither and yon, you > want to type as infrequently as possible and localized it to as few > methods as possible. Right. The pattern you're looking for is called a “sentinel value” https://en.wikipedia.org/wiki/Sentinel_value>. Usually, the None singleton is good enough for a sentinel value, but often it has a meaning already in your context, so is not available as a sentinel value. In cases where None is not available, make a specific value that has no other meaning, and use that specifically for your parameter's sentinel value:: class Foo(object): _default_for_x = object() def __init__(self, x=_default_for_object): """ Initialise a new instance. """ if x is self._default_for_object: # No value for ‘x’ was passed, because ‘_default_for_x’ # would not be passed by accident. x = self._get_value_for_x() self.x = x def _get_default_value_for_x(self): Calculate the default ‘x’ value for this instance. """ return some_computation(self) -- \ “When a well-packaged web of lies has been sold to the masses | `\over generations, the truth will seem utterly preposterous and | _o__)its speaker a raving lunatic.” —Dresden James | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: skipping __init__ and using exploiting a class member instead
In article ,
Peter Cacioppi wrote:
> Personally, I find the ability of Python to subclass without overriding the
> constructor very elegant. I don't believe the other languages I've worked in
> can do this (C++, C#, Java)...
I'm not sure what point you're trying to make here. You certainly don't
have to write a constructor for a subclass in C++. This works perfectly
fine (and prints "Foo" when I run it):
#include
class Foo {
public:
Foo() {
printf("Foo()\n");
};
};
class Bar : Foo {
};
int main(char**, int) {
Bar b;
}
--
https://mail.python.org/mailman/listinfo/python-list
Re: skipping __init__ and using exploiting a class member instead
On 20/10/2013 08:09, Peter Cacioppi wrote: Personally, I find the ability of Python to subclass without overriding the constructor very elegant. __new__ is the constructor which to my knowledge you've not mentioned, __init__ is the initialiser as mentioned by Ben Finney. -- Roses are red, Violets are blue, Most poems rhyme, But this one doesn't. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: skipping __init__ and using exploiting a class member instead
On Sat, Oct 19, 2013 at 2:44 PM, Peter Cacioppi wrote: > Is the following considered poor Python form? > > class Foo (object) : > _lazy = None > def foo(self, x) : > self._lazy = self._lazy or self.get_something(x) > def get_something(self, x) : > # doesn't really matter > > I like this idiom for certain situations, just wondering if it will raise the > hackles of other Pythonistas. It raises my hackles, but not for any good reason. I've seen it a number of times in the Twisted codebase, so you're not alone in using it. -- Devin -- https://mail.python.org/mailman/listinfo/python-list
Python Front-end to GCC
Hey, I've been working on GCCPY since roughly november 2009 at least in its concept. It was announced as a Gsoc 2010 project and also a Gsoc 2011 project. I was mentored by Ian Taylor who has been an extremely big influence on my software development carrer. Gccpy is an Ahead of time implementation of Python ontop of GCC. So it works as you would expect with a traditional compiler such as GCC to compile C code. Or G++ to compile C++ etc. Whats interesting and deserves a significant mention is my work is heavily inspired by Paul Biggar's phd thesis on optimizing dynamic languages and his work on PHC a ahead of time php compiler. I've had so many ups and down in this project and i need to thank Andi Hellmund for his contributions to the project. http://paulbiggar.com/research/#phd-dissertation The project has taken so many years as an in my spare time project to get to this point. I for example its taken me so long simply to understand a stabilise the core fundamentals for the compiler and how it could all work. The release can be found here. I will probably rename the tag to the milestone (lucy) later on. https://github.com/redbrain/gccpy/releases/tag/v0.1-24 (Lucy is our dog btw, German Shepard (6 years young) loves to lick your face off :) ) Documentation can be found http://gcc.gnu.org/wiki/PythonFrontEnd. (Although this is sparse partialy on purpose since i do not wan't people thinking this is by any means ready to compile real python applications) I've found some good success with this project in compiling python though its largely unknown to the world simply because i am nervous of the compiler and more specifically the python compiler world. But at least to me there is at least to me an un-answered question in current compiler implementations. AOT vs Jit. Is a jit implementation of a language (not just python) better than traditional ahead of time compilation. What i can say is ahead of time at least strips out the crap needed for the users code to be run. As in people are forgetting the basics of how a computer works in my opinion when it comes to making code run faster. Simply need to reduce the number of instructions that need to be executed in order to preform what needs to be done. Its not about Jit and bla bla keyword llvm keyword instruction scheduling keyword bla. I could go into the arguments but i feel i should let the project speak for itself its very immature so you really cant compare it to anything like it but it does compile little bits and bobs fairly well but there is much more work needed. There is nothing at steak, its simply an idea provoked from a great phd thesis and i want to see how it would work out. I don't get funded of paid. I love working on compilers and languages but i don't have a day job doing it so its my little pet to open source i believe its at least worth some research. I would really like to hear the feedback good and bad. I can't describe how much work i've put into this and how much persistence I've had to have in light of recent reddit threads talking about my project. I have so many people to thank to get to this point! Namely Ian Taylor, Paul Biggar, Andi Hellmund, Cyril Roelandt Robert Bradshaw, PyBelfast, and the Linux Outlaws community. I really couldn't have got to this point in my life without the help of these people! Thanks! --Phil -- https://mail.python.org/mailman/listinfo/python-list
Re: skipping __init__ and using exploiting a class member instead
> You certainly don't have to write a constructor for a subclass in C++. Ahh, this message board is so collectively well informed (once you get past the trolls) The C++ project I worked on was religious about always overwriting parent class constructors. I had assumed this was because the language proper forbid it, but apparently it was just project protocol. Thanks again! -- https://mail.python.org/mailman/listinfo/python-list
On click functions with turtle?
Hi everyone, I have this program that writes out the name "John" in block
letters. I was just messing around because we were just introduced to turtle a
few weeks ago in class and I'm just getting the hang of it. Before I was using
"goto" a certain angle, but now I'm using "seth" and it's so much easier.
Here is my question:
I want to click on a certain letter ("J" or "O" or "H" or "N") and have the
turtle hover above that letter as in when the turtle is above the letter "N" at
the end of my program. Do I need to set the letters up as objects so when I
click inside them, I can set the turtles x and y coordinate to hover above that
letter?
Or do I need to define each letter as a function and make some "if" statements
like "if user clicks inside letter (J,O,H, or N), go to specific x, y
coordinate?"
Thanks for any help in advance. Drawing is frustrating with python, but I'm
starting to understand how it works. I think it's just the angles that trip me
up.
Here is my code:
import turtle
rectangle = turtle.Turtle()
def makeRec():
rectangle.shape("turtle")
rectangle.pensize(2)
rectangle.pencolor("red")
rectangle.speed(5)
#Draws the letter O
rectangle.penup()
rectangle.seth(180)
rectangle.fd(50)
rectangle.seth(90)
rectangle.pendown()
rectangle.pencolor("black")
rectangle.circle(30)
rectangle.penup()
rectangle.seth(180)
rectangle.fd(10)
rectangle.seth(90)
rectangle.pendown()
rectangle.circle(20)
rectangle.penup()
rectangle.seth(180)
rectangle.fd(70)
rectangle.seth(90)
rectangle.fd(30)
rectangle.seth(-90)
#Draws the letter J
rectangle.pendown()
rectangle.fd(40)
rectangle.circle(-20,180)
rectangle.seth(0)
rectangle.fd(10)
rectangle.seth(-90)
rectangle.circle(10,180)
rectangle.fd(40)
rectangle.seth(0)
rectangle.fd(10)
#Draws the letter H
rectangle.penup()
rectangle.fd(100)
rectangle.seth(-90)
rectangle.pendown()
rectangle.fd(60)
rectangle.seth(0)
rectangle.fd(10)
rectangle.seth(90)
rectangle.fd(20)
rectangle.seth(0)
rectangle.fd(20)
rectangle.seth(-90)
rectangle.fd(20)
rectangle.seth(0)
rectangle.fd(10)
rectangle.seth(90)
rectangle.fd(60)
rectangle.seth(180)
rectangle.fd(10)
rectangle.seth(-90)
rectangle.fd(30)
rectangle.seth(180)
rectangle.fd(20)
rectangle.seth(90)
rectangle.fd(30)
rectangle.seth(180)
rectangle.fd(10)
#Draws the letter N
rectangle.penup()
rectangle.seth(0)
rectangle.fd(60)
rectangle.seth(-90)
rectangle.fd(60)
rectangle.seth(90)
rectangle.pendown()
rectangle.fd(60)
rectangle.seth(0)
rectangle.fd(10)
rectangle.seth(-60)
rectangle.fd(50)
rectangle.seth(90)
rectangle.fd(45)
rectangle.seth(0)
rectangle.fd(13)
rectangle.seth(-90)
rectangle.fd(65)
rectangle.seth(180)
rectangle.fd(15)
rectangle.seth(120)
rectangle.fd(40)
rectangle.seth(-90)
rectangle.fd(35)
rectangle.seth(180)
rectangle.fd(13)
rectangle.seth(90)
rectangle.fd(5)
#Sets the turtle to the position above letter N
rectangle.penup()
rectangle.seth(90)
rectangle.fd(100)
rectangle.seth(180)
rectangle.fd(80)
rectangle.seth(-90)
print(rectangle.pos())
rectangle.setx(54)
rectangle.sety(70)
makeRec()
--
https://mail.python.org/mailman/listinfo/python-list
Re: skipping __init__ and using exploiting a class member instead
In article <0e9b51a9-bd78-4d34-b277-c463347e8...@googlegroups.com>, Peter Cacioppi wrote: > > You certainly don't have to write a constructor for a subclass in C++. > > Ahh, this message board is so collectively well informed (once you get past > the trolls) > > The C++ project I worked on was religious about always overwriting parent > class constructors. I had assumed this was because the language proper forbid > it, but apparently it was just project protocol. One of the problems with C++ is that it's such a huge language, nobody knows all of it. Most people learn some subset of the language that they get comfortable with (often because that's the subset that's used on the project they're working on). Then it's easy to assume that the part you know is all there is to know. Personally, I barely know the STL (because the various C++ projects I've worked on all predated the STL and rolled their own container classes). Likewise for most of the std streams library. -- https://mail.python.org/mailman/listinfo/python-list
Re: skipping __init__ and using exploiting a class member instead
On Mon, Oct 21, 2013 at 4:57 AM, Peter Cacioppi wrote: >> You certainly don't have to write a constructor for a subclass in C++. > > Ahh, this message board is so collectively well informed (once you get past > the trolls) > > The C++ project I worked on was religious about always overwriting parent > class constructors. I had assumed this was because the language proper forbid > it, but apparently it was just project protocol. Minor point: In C++, you don't overwrite constructors; you simply add your own. By the time a derived class's constructor is called, the parents' have all already been called. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: skipping __init__ and using exploiting a class member instead
At the risk of sounding like a fogey, I actually think I did, at one time, know the distinctions between "our projects protocol" and "the language proper" for C++. I read Scott Meyers books on C++ and STL a couple of times each and helped design the protocol that kept us reasonably safe. But this was all a long time ago, and those parts of my RAM are now storing Breaking Bad plot twists and the nuances of the Federer or Nadal debate. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Front-end to GCC
On Sunday, October 20, 2013 3:56:46 PM UTC-2, Philip Herron wrote: > I've been working on GCCPY since roughly november 2009 at least in its > concept. It was announced as a Gsoc 2010 project and also a Gsoc 2011 > project. I was mentored by Ian Taylor who has been an extremely big > influence on my software development carrer. Cool! > Documentation can be found http://gcc.gnu.org/wiki/PythonFrontEnd. > (Although this is sparse partialy on purpose since i do not wan't > people thinking this is by any means ready to compile real python > applications) Is there any document describing what it can already compile and, if possible, showing some benchmarks? > But at least to me there is at least to me an un-answered question in > current compiler implementations. AOT vs Jit. > > Is a jit implementation of a language (not just python) better than > traditional ahead of time compilation. > > What i can say is ahead of time at least strips out the crap needed > for the users code to be run. As in people are forgetting the basics > of how a computer works in my opinion when it comes to making code run > faster. Simply need to reduce the number of instructions that need to > be executed in order to preform what needs to be done. Its not about > Jit and bla bla keyword llvm keyword instruction scheduling keyword > bla. Maybe a less agressive tone (and a lot more research before going into sweeping statements that do nothing to further your own project) could result in a better level of discussion? > I could go into the arguments but i feel i should let the project > speak for itself its very immature so you really cant compare it to > anything like it but it does compile little bits and bobs fairly well > but there is much more work needed. Can you compare it to Nuitka (http://nuitka.net/), ShedSkin (http://nuitka.net/) and Pythran (http://pythonhosted.org/pythran/) when you think it's mature enough? These projects have test suits you can borrow to chart you progress along the full-language support road. It'd be good to find a place for your project on http://compilers.pydata.org/ , as soon as you better describe its workings. > There is nothing at steak, its simply an idea provoked from a great > phd thesis and i want to see how it would work out. I don't get funded > of paid. I love working on compilers and languages but i don't have a > day job doing it so its my little pet to open source i believe its at > least worth some research. It's very interesting indeed. Congratulations and thank you for your work. Victor -- https://mail.python.org/mailman/listinfo/python-list
Re: skipping __init__ and using exploiting a class member instead
In article , Peter Cacioppi wrote: > I read Scott Meyers books on C++ and STL a couple of times > each and helped design the protocol that kept us reasonably safe. Scott Meyers is an incredibly smart C++ wizard. His books are amazing. The fact that it takes somebody that smart, and books that amazing, to teach you how not to shoot yourself in the foot with a C++ compiler says a lot about the language. -- https://mail.python.org/mailman/listinfo/python-list
Printing a drop down menu for a specific field.
try:
cur.execute( '''SELECT host, city, useros, browser, ref, hits,
lastvisit FROM visitors WHERE counterID = (SELECT ID FROM counters WHERE
url = %s) ORDER BY lastvisit DESC''', page )
data = cur.fetchall()
for row in data:
(host, city, useros, browser, ref, hits, lastvisit) = row
lastvisit = lastvisit.strftime('%A %e %b, %H:%M')
print( "" )
for item in (host, city, useros, browser, ref, hits, lastvisit):
print( " %s " %
item )
except pymysql.ProgrammingError as e:
print( repr(e) )
===
In the above code i print the record of the mysql table visitors in each
row like this: http://superhost.gr/?show=log&page=index.html
Now, i wish to write the same thing but when it comes to print the
'lastvisit' field to display it in a tag so all prior
visits for the same host appear in a drop down menu opposed to as i have
it now which i only print the datetime of just the latest visit of that
host and not all its visit datetimes.
I hope i made it clear what i want to achieve.
--
https://mail.python.org/mailman/listinfo/python-list
Re: skipping __init__ and using exploiting a class member instead
Roy Smith writes: > Scott Meyers is an incredibly smart C++ wizard. His books are amazing. > The fact that it takes somebody that smart, and books that amazing, to > teach you how not to shoot yourself in the foot with a C++ compiler says > a lot about the language. +1 QotW -- \ “[W]e are still the first generation of users, and for all that | `\ we may have invented the net, we still don't really get it.” | _o__) —Douglas Adams | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
[RELEASED] Python 3.4.0a4
On behalf of the Python development team, I'm very pleased to announce the fourth and final alpha release of Python 3.4. This is a preview release, and its use is not recommended for production settings. Python 3.4 includes a range of improvements of the 3.x series, including hundreds of small improvements and bug fixes. Major new features and changes in the 3.4 release series so far include: * PEP 435, a standardized "enum" module * PEP 436, a build enhancement that will help generate introspection information for builtins * PEP 442, improved semantics for object finalization * PEP 443, adding single-dispatch generic functions to the standard library * PEP 445, a new C API for implementing custom memory allocators * PEP 446, changing file descriptors to not be inherited by default in subprocesses * PEP 450, the new "statistics" module * PEP 3156, the new "asyncio" module, a new framework for asynchronous I/O To download Python 3.4.0a4 visit: http://www.python.org/download/releases/3.4.0/ Python 3.4.0a4 has several known issues: * The Python compiler has a small memory leak. * The "asyncio" module test suite fails on some platforms. * I/O conducted by the "asyncio" module may, rarely, erroneously time out. The timeout takes one hour. Please consider trying Python 3.4.0a4 with your code and reporting any new issues you notice to: http://bugs.python.org/ Enjoy! -- Larry Hastings, Release Manager larry at hastings.org (on behalf of the entire python-dev team and 3.4's contributors) -- https://mail.python.org/mailman/listinfo/python-list
Re: Python was designed (was Re: Multi-threading in Python vs Java)
On Fri, 18 Oct 2013 22:26:02 -0700, rusi wrote: > On Saturday, October 19, 2013 2:02:24 AM UTC+5:30, Peter Cacioppi wrote: >> >> I still say that object-based is a distinct and meaningful subset of >> object-oriented programming. > > Yes that is what is asserted by > http://www-public.int-evry.fr/~gibson/Teaching/CSC7322/ReadingMaterial/ Wegner87.pdf > -- a classic though old reference The truth of a definition is not really something that is amenable to proof, only to agreement. In my experience, there is no widespread agreement on what the terms "object oriented" or "object based" programming mean. I expect that most people would consider them synonyms, or might consider the first to have some vigorous meaning while the second is just an informal term for a language that in some sense is based on objects in some way. Even if we agreed that there was a distinction between the two -- and I don't think we do -- there is certainly no agreement as to what that distinction actually is. There are far too many mediocre programmers with limited experience outside of their narrow field who assume that whatever sliver of C++/Java/Python/whatever that they learned is the One True Definition of object-oriented programming. And too many academics looking for hard boundaries between concepts which, fundamentally, exist in a continuum. It's all just part of the human tendency to pigeon-hole. According to some, Java, which has many low-level machine primitive types, is an object-oriented language, while Python, which has no machine primitives and where every value is an object, is not. Explain that one, if you can. [...] >> It's an important distinction, because a project that is constrained to >> C should (IMHO) target an object-based design pattern but not an >> object-oriented one. That said, I'm open to disputation-by-example on >> this point, provided the example is reasonably small and pretty. (If >> the only polymorphic C code is ugly and non-small, it sort of proves my >> point). Define ugly :-) One of the reasons multiple languages exist is because people find that useful programming idioms and styles are *hard to use* or "ugly" in some languages, so they create new languages with different syntax to make those useful patterns easier to use. But syntax is not everything. Whether you write: object.method(arg)// Python, VB, Ruby, Java object#method arg // OCaml object:method arg // Lua method object arg // Haskell, Mercury object method arg // Io object->method(arg) // C++, PHP method(object, arg) // Ada, Dylan send method(arg) to object // XTalk family of languages etc. does not really change the fact that you are calling a method on an object, despite the change in syntax. Even Forth has frameworks that let you write object-[oriented|based] code using a stack and reverse Polish notation syntax. [...] > Just as the study of algorithms arose out of a desire to study program > efficiency but with the nitty-gritty details of machines abstracted > away, in the same way programming language semantics arose in order to > study broad classes of languages with details hidden away. I don't think that programming language semantics arose so much in order to *study* languages, more to *program*. Programming languages pre-date the study of programming languages :-) > Unfortunately, even after 50 years of trying, semantics has been a > dismal failure in defining the what and where and whither of OOP. In a > sane world this would have signified that perhaps OOP as a concept(s) > needs to be questioned. Considering that the opposite has happened -- > programming language semantics as an area has become distinctly > 'old-fashioned' and not-so-respectable-- I can only conclude that the > world is not sane. All the words are in English, yet somehow I can't quite make sense of this paragraph. You seem to be using "semantics" in a way that doesn't quite make sense to me. To me, "programming language semantics" is the *meaning* of code: "var = func(arg)" is the syntax, "call func with arg and assign the result to var" is the semantics. What do you mean by it? > Well the tide is slowly turning -- here's a growing bunch of people > questioning the validity of OOP: > http://en.wikipedia.org/wiki/Object-oriented_programming#Criticism *Criticism* is not the same as questioning the validity. Certainly I can criticise OOP: - if you care about machine efficiency, shoving small ints into a bulky object wrapper is bad for machine efficiency; - ravioli code is to OOP as spaghetti code was to BASIC; - large, deep object hierarchies are complex and hard to understand and learn; etc. But then I can also criticise functional programming, declarative programming, imperative programming, logic programming, etc. There is no One True Programming Paradigm suitable for every task, just as there is no One True Programming Language. > Of these I find two noteworthy: >
Re: Python was designed (was Re: Multi-threading in Python vs Java)
In article <52648c54$0$29981$c3e8da3$54964...@news.astraweb.com>, Steven D'Aprano wrote: > According to > some, Java, which has many low-level machine primitive types, is an > object-oriented language, while Python, which has no machine primitives > and where every value is an object, is not. Explain that one, if you can. That's easy to explain. Python doesn't have private data, therefore it isn't OO. Well, according to the Java-esque gospel, at any rate. Whenever somebody tells you what OO means, ask him what part of the elephant he's touching. -- https://mail.python.org/mailman/listinfo/python-list
how to get current max_heap_size value of minimark in pypy 2.x
Hello, I read some articles about setting PYPY_GC_MAX environment variable. But I can't find how to get current max_heap_size value of minimark. Please let me know how-to :) Thanks, Ricky -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Front-end to GCC
> Gccpy is an Ahead of time implementation of Python ontop of GCC. So it > works as you would expect with a traditional compiler such as GCC to > compile C code. Or G++ to compile C++ etc. That is amazing. I was just talking about how someone should make a front-end to GCC on this list a couple of months ago. Awesome! > Documentation can be found http://gcc.gnu.org/wiki/PythonFrontEnd. > (Although this is sparse partialy on purpose since i do not wan't > people thinking this is by any means ready to compile real python > applications) What's missing? > I've found some good success with this project in compiling python > though its largely unknown to the world simply because i am nervous of > the compiler and more specifically the python compiler world. > > But at least to me there is at least to me an un-answered question in > current compiler implementations. AOT vs Jit. > > Is a jit implementation of a language (not just python) better than > traditional ahead of time compilation. Not at all. The value of jit compilation, I believe, is purely for the dynamic functionality that it allows. AOT compilation will never allow that, but in return you get massive performance and runtime-size gains (that is, you don't need a massive interpreter environment anymore!) If your compiler produces an executable program without the need for the python interpreter environment: Two major wins. > What i can say is ahead of time at least strips out the crap needed > for the users code to be run. As in people are forgetting the basics > of how a computer works in my opinion when it comes to making code run > faster. Agreed. > I could go into the arguments but i feel i should let the project > speak for itself its very immature so you really cant compare it to > anything like it but it does compile little bits and bobs fairly well > but there is much more work needed. I wish I had the resources to try it myself, but would love to see some performance numbers (say factorizations, or bubble-sorts, etc). Also runtime executable sizes. > I would really like to hear the feedback good and bad. I can't > describe how much work i've put into this and how much persistence > I've had to have in light of recent reddit threads talking about my > project. Please reference threads in question, would like to see the issues raised. -- MarkJ Tacoma, Washington -- https://mail.python.org/mailman/listinfo/python-list
Re: skipping __init__ and using exploiting a class member instead
That sound you here is Roy Smith hitting the nail on the head re: C++ and Scott Meyers. -- https://mail.python.org/mailman/listinfo/python-list
Re: skipping __init__ and using exploiting a class member instead
That sound you hear is Roy Smith hitting the nail on the head. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python was designed (was Re: Multi-threading in Python vs Java)
On Monday, October 21, 2013 7:51:12 AM UTC+5:30, Roy Smith wrote: > In article > Steven D'Aprano wrote: > > > According to > > some, Java, which has many low-level machine primitive types, is an > > object-oriented language, while Python, which has no machine primitives > > and where every value is an object, is not. Explain that one, if you can. > > That's easy to explain. Python doesn't have private data, therefore it > isn't OO. Well, according to the Java-esque gospel, at any rate. > > Whenever somebody tells you what OO means, ask him what part of the > elephant he's touching. Nice one ! Complementarily one can ask what does a typical Picasso cubist painting eg http://www.artchive.com/artchive/p/picasso/cadaques.jpg represent? The avant gardists will wax eloquent. And some (of us philistines) will of course say: Nothing. Just as there may an elephant which we are too blind to see, its good to keep in mind the possibility that there may be big words without anything actually there. Colloquially known as the emperor's new clothes On Monday, October 21, 2013 7:37:17 AM UTC+5:30, Steven D'Aprano wrote: > > Unfortunately, even after 50 years of trying, semantics has been a > > dismal failure in defining the what and where and whither of OOP. In a > > sane world this would have signified that perhaps OOP as a concept(s) > > needs to be questioned. Considering that the opposite has happened -- > > programming language semantics as an area has become distinctly > > 'old-fashioned' and not-so-respectable-- I can only conclude that the > > world is not sane. > > All the words are in English, yet somehow I can't quite make sense of > this paragraph. You seem to be using "semantics" in a way that doesn't > quite make sense to me. To me, "programming language semantics" is the > *meaning* of code: "var = func(arg)" is the syntax, "call func with arg > and assign the result to var" is the semantics. What do you mean by it? Yes its always good to be skeptical about the emperor's new clothes… I thought I'd point to wikipedia http://en.wikipedia.org/wiki/Semantics_%28computer_science%29 but its doing a less than stellar job of it so heres my thoughts: Programming language semantics categorises roughly into: 1. Operational 2. Denotational 3. Axiomatic 4. Algebraic Some historical context: 1. proof theory vs model theory In logic, the proof theorists want to study how to prove or reason about something The model theorists, more platonically inclined, want to say what something is Corresponds to the philosophical divide between epistemology and ontology/metaphysics. The latter can be more 'grand' but is therefore subject to the most penetrating criticism. Historically the big contributions of Aristotle and Plato were under the title of metaphysics and the big contributions of Kant and Hume were to show that for the most part metaphysics is bullshit. In short these kinds of arguments are a bit older than you and me!! In programming language research, the model-theorists end towards denotational semantics; the proof theorists tend towards axiomatic and algebraic semantics; The implementers come from the operational camp 2. programs ∈ languages > To me, "programming language semantics" is the *meaning* of code. Yes this is an eminently sensible pov (and has precedents like Hoare, Dijkstra, Floyd etc -- the 'axiomatic' guys). However you cannot really talk of the meaning of programs without talking of the meaning of programming languages. Clearly this -- the meaning of the language -- is a grander project and just as in philosophy, is as liable to called out as bullshit. As an example the repeating argument about what IS a variable indicates the crying need to discuss this more metaphysically -- ie denotational semantically -- because if we dont, the result is just a mess - in C a variable *means* this - in python it means that - in math it means something - etc > But then I can also criticise functional programming, declarative programming, > imperative programming, logic programming, etc. There is no One True > Programming > Paradigm suitable for every task, just as there is no One True Programming > Language. Analogy: When we deal with an existing code-base, we often find flaws/issues/gaffes/whatever in the design or architecture. On the other hand sometimes we find there is no design or architecture whatever I believe there is a big difference between the two. In PLs think php. I think what Stepanov is saying (and most of the others at http://en.wikipedia.org/wiki/Object-oriented_programming#Criticism ) is this distinction. My own view in summary: Between programming and mathematics, mathematics is the prior. This is obviously true as history including the name 'computer' and all its modifications. To the extent that "ontogeny recapitulates phylogeny" this is true in fact as well. The OOP aficionados are straining to break their umbilical cord with X. Th
Re: Printing a drop down menu for a specific field.
Στις 21/10/2013 2:30 πμ, ο/η Νίκος Αλεξόπουλος έγραψε:
try:
cur.execute( '''SELECT host, city, useros, browser, ref, hits,
lastvisit FROM visitors WHERE counterID = (SELECT ID FROM counters WHERE
url = %s) ORDER BY lastvisit DESC''', page )
data = cur.fetchall()
for row in data:
(host, city, useros, browser, ref, hits, lastvisit) = row
lastvisit = lastvisit.strftime('%A %e %b, %H:%M')
print( "" )
for item in (host, city, useros, browser, ref, hits, lastvisit):
print( " %s " % item )
except pymysql.ProgrammingError as e:
print( repr(e) )
===
In the above code i print the record of the mysql table visitors in each
row like this: http://superhost.gr/?show=log&page=index.html
Now, i wish to write the same thing but when it comes to print the
'lastvisit' field to display it in a tag so all prior
visits for the same host appear in a drop down menu opposed to as i have
it now which i only print the datetime of just the latest visit of that
host and not all its visit datetimes.
I hope i made it clear what i want to achieve.
Any help would be appreciated.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python was designed (was Re: Multi-threading in Python vs Java)
I've written a fair bit of code in pure C, C++, C#, Java and now getting there in Python. The difference between C# and Java is fairly minor. The others have large and significant differences between them. Garbage collectors or not is huge. Exceptions or not is huge. Dynamic or static typing is huge. Language support for polymorphism or not is huge. C code invokes a very meaningful overhead of memory management. The task of insuring that memory doesn't leak here is far larger than in garbage collected languages, and much more difficult than C++ (which can guarantee stack based destruction). This is just one language feature. I could go on and on. The idea that the differences between these languages is just syntactic sugar and aesthetics is so profoundly misguided that I can only assume that this misconception was proposed as a bizarre form of trolling. -- https://mail.python.org/mailman/listinfo/python-list
Re: Printing a drop down menu for a specific field.
Νίκος Αλεξόπουλος writes: > Any help would be appreciated. Please stop posting merely for grabbing attention. If someone is going to answer, they'll answer. Don't annoy the forum with pleas for attention. -- \“Program testing can be a very effective way to show the | `\presence of bugs, but is hopelessly inadequate for showing | _o__) their absence.” —Edsger W. Dijkstra | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: Python was designed (was Re: Multi-threading in Python vs Java)
On Mon, Oct 21, 2013 at 1:07 PM, Steven D'Aprano wrote: > One of the reasons multiple languages exist is because people find that > useful programming idioms and styles are *hard to use* or "ugly" in some > languages, so they create new languages with different syntax to make > those useful patterns easier to use. But syntax is not everything. > Whether you write: > > object.method(arg)// Python, VB, Ruby, Java > object#method arg // OCaml > object:method arg // Lua > method object arg // Haskell, Mercury > object method arg // Io > object->method(arg) // C++, PHP > method(object, arg) // Ada, Dylan > send method(arg) to object // XTalk family of languages > > > etc. does not really change the fact that you are calling a method on an > object, despite the change in syntax. Even Forth has frameworks that let > you write object-[oriented|based] code using a stack and reverse Polish > notation syntax. There seems to be a school of thought that "if it doesn't have special syntax, the language doesn't support it". This is true to an extent (eg C doesn't support sockets, the code is all in the standard library), and it does distinguish C from C++ in object orientation (C's version is simply dedicating the first function argument to 'self', where C++ and Python and so on have an alternative syntax that puts the self/this argument before the function name), but I don't know that it's the whole story. Python 2.x has special (and somewhat magical) syntax for file I/O; Python 3.x, as far as I know, has none - open and print are just builtins, with no magic around them. Which is better? I would say that standard functions are inherently more flexible (you can shadow print and call the original, for instance), but that would mean that the better way is to NOT "support" I/O. If an analogy helps, let's look at the trading card game Magic: The Gathering. The general design principle is that unusual effects get written out on the card, rather than having actual rules to support them; rulebook text is used only when printing abilities on the card is unable to do everything. (There are also keyword abilities, which are like Python's builtins - "fear" simply means "can't be blocked except by artifact and/or black creatures", and it could just as well be written out on the card.) Does this mean that Magic supports lifelink (which has entries in the Comprehensive Rulebook) but doesn't support defenders (which simply can't attack)? I think not; the game is most definitely designed for both. Granted, C probably wasn't designed with object orientation in mind; but it doesn't take very much effort to make it work (just pointer casts and some argument order conventions). Sure, a bit of real support helps (preventing accidental cross-casts), but it's pretty easy to manage without. Adding to the list of object oriented C systems is NIH: http://ifdeflinux.blogspot.com/2012/05/quick-libnih-tutorial.html It's small enough and light enough to be used by really early systems like Upstart (a Linux bootloader) and it's a garbage-collected object-oriented C library. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
