Re: Python's only one way to do it philosophy isn't good?
On Jun 27, 11:41 pm, John Nagle [EMAIL PROTECTED] wrote: One right answer would be a pure reference counted system where loops are outright errors, and you must use weak pointers for backpointers. ... The general idea is that pointers toward the leaves of trees should be strong pointers, and pointers toward the root should be weak pointers. While I agree that weak pointers are good and can not be an afterthought, I've written code where back changed dynamically, and I'm pretty sure that Nagle has as well. Many programs with circular lists have an outside pointer to the current element, but the current element changes. All of the links implementing the list have to be strong enough to keep all of the list alive. Yes, one can implement a circular list as a vector with a current index, but that has space and/or time consequences. It's unclear that that approach generalizes for more complicated structures. (You can't just pull all of the links out into such lists.) In short, while disallowing loops with strong pointers is a right answer, it isn't always a right answer, so it can't be the only answer. -andy -- http://mail.python.org/mailman/listinfo/python-list
Re: Python's only one way to do it philosophy isn't good?
On Jun 28, 1:09 pm, John Nagle [EMAIL PROTECTED] wrote: Andy Freeman wrote: On Jun 27, 11:41 pm, John Nagle [EMAIL PROTECTED] wrote: While I agree that weak pointers are good and can not be an afterthought, I've written code where back changed dynamically, and I'm pretty sure that Nagle has as well. That sort of thing tends to show up in GUI libraries, especially ones that have event ordering issues. It's a tough area. It shows up almost anywhere one needs to handle recurring operations. It also shows up in many dynamic search structures. Yes, one can implement a circular list as a vector with a current index, but that has space and/or time consequences. We used to see things like that back in the early 1980s, but today, worrying about the space overhead associated with keeping separate track of ownership and position in a circular buffer chain isn't a big deal. Insert and delete can be a big deal. O(1) is nice. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python's only one way to do it philosophy isn't good?
On Jun 27, 1:15 am, Paul Rubin http://[EMAIL PROTECTED] wrote: Dennis Lee Bieber [EMAIL PROTECTED] writes: What happens when two individuals release libraries using these proposed macros -- and have implement conflicting macros using the same identifiers -- and you try to use both libraries in one application? Something like the current situation with Python web frameworks ;) Actually, no. For python, the most reasonable macro scope would be the file, so different files in the same application could easily use conflicting macros without any problems. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python's only one way to do it philosophy isn't good?
On Jun 26, 10:03 am, Paul Rubin http://[EMAIL PROTECTED] wrote: Map doesn't work on generators or iterators because they're not part of the common lisp spec, but if someone implemented them as a library, said library could easily include a map that handled them as well. Right, more scattered special purpose kludges instead of a powerful uniform interface. Huh? The interface could continue to be (map ...). Python's for statement relies on the fact that python is mostly object oriented and many of the predefined types have an iterator interface. Lisp lists and vectors currently aren't objects and very few of the predefined types have an iterator interface. It's easy enough to get around the lack of objectness and add the equivalent of an iterator iterface, in either language. The fact that lisp folks haven't bothered suggests that this isn't a big enough issue. The difference is that lisp users can easily define python-like for while python folks have to wait for the implementation. Syntax matters. -- http://mail.python.org/mailman/listinfo/python-list
Re: Too many 'self' in python.That's a big flaw in this language.
On Jun 27, 2:54 pm, John Nagle [EMAIL PROTECTED] wrote: But, what about something in between like only using the dot (.) for a shorter notation? How about Mavis Beacon Teaches Typing? How about no wouldn't it be better suggestions until at least three months after the suggester has written at least 1000 lines of working code.? -- http://mail.python.org/mailman/listinfo/python-list
Re: Python's only one way to do it philosophy isn't good?
On Jun 27, 8:09 am, Chris Mellon [EMAIL PROTECTED] wrote:
On 6/27/07, Andy Freeman [EMAIL PROTECTED] wrote:
It's easy enough to get around the lack of objectness and add the
equivalent of an iterator iterface, in either language. The fact that
lisp folks haven't bothered suggests that this isn't a big enough
issue.
Is this where I get to call Lispers Blub programmers, because they
can't see the clear benefit to a generic iteration interface?
The Blub argument relies on inability to implement comparable
functionality in blub. (For example, C programmers don't get to
call Pythonists Blub programmers because Python doesn't use {} and
Pythonistas don't get to say the same about C programmers because C
doesn't use whitespace.) Generic iterators can be implemented by lisp
programmers and some have. Others haven't had the need.
The difference is that lisp users can easily define python-like for
while python folks have to wait for the implementation.
Yes, but Python already has it (so the wait time is 0), and the Lisp
user doesn't.
for isn't the last useful bit of syntax. Python programmers got to
wait until 2.5 to get with. Python 2.6 will probably have syntax
that wasn't in Python 2.5.
Lisp programmers with a syntax itch don't wait anywhere near that long.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python's only one way to do it philosophy isn't good?
On Jun 26, 12:26 am, Paul Rubin http://[EMAIL PROTECTED] wrote: Precisely, I think that's what Alexander was trying to get across, Lisp didn't have a uniform interface for traversing different types of sequence. And he's wrong, at least as far as common lisp is concerned - map does exactly that. http://www.lispworks.com/documentation/HyperSpec/Body/f_map.htm Map doesn't work on generators or iterators because they're not part of the common lisp spec, but if someone implemented them as a library, said library could easily include a map that handled them as well. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python's only one way to do it philosophy isn't good?
On Jun 26, 8:49 am, Andy Freeman [EMAIL PROTECTED] wrote: Map doesn't work on generators or iterators because they're not part of the common lisp spec, but if someone implemented them as a library, said library could easily include a map that handled them as well. Note that this is is a consequence of something that Python does better than lisp. Far more parts of python are defined in terms of named operations which are data-type independent. As a result, they work on things that the implementor (or spec) never considered. That said, it's no big deal for a lisp program that needed an enhanced map that also understands iterators and generators to use it. Compare that with what a programmer using Python 2.4 has to do if she'd like the functionality provided by 2.5's with statement. Yes, with is just syntax, but it's extremely useful syntax, syntax that can be easily implemented with lisp-style macros. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python's only one way to do it philosophy isn't good?
On Jun 26, 10:10 am, Paul Rubin http://[EMAIL PROTECTED] wrote: Andy Freeman [EMAIL PROTECTED] writes: Compare that with what a programmer using Python 2.4 has to do if she'd like the functionality provided by 2.5's with statement. Yes, with is just syntax, but it's extremely useful syntax, syntax that can be easily implemented with lisp-style macros. Not really. Yes really, as the relevant PEP shows. The it works like pseudo- code is very close to how it would be defined with lisp-style macros. The with statement's binding targets all have to support the protocol, which means a lot of different libraries need redesign. That's a different problem, and it's reasonably solvable for anyone who wants to use the roll-your-own with while writing an application running under 2.4. (You just add the relevant methods to the appropriate classes.) The big obstacle is the syntax of the with-statement. There's no way to define it in python with user-code. -- http://mail.python.org/mailman/listinfo/python-list
Re: Lisp-like macros in Python?
On May 1, 9:10 am, sturlamolden [EMAIL PROTECTED] wrote:
I was
wondering if it is possible to emulate some of the functionality in
Python using a function decorator that evals Python code in the stack
frame of the caller. The macro would then return a Python expression
as a string. Granted, I know more Python than Lisp, so it may not work
exactly as you expect.
How about something that can't be done with a function, such as the
functionality of the with statement that was added to python 2.5?
Yes, it has to handle a suite of statements.
It would be nice if it handled both the {as target} and no target
forms.
Also, it shouldn't rely on magic names - if it needs a variable for
its purposes, it should guarantee that said variable and/or use can
not be one that affects how the rest of the user's program behaves.
There's a fair amount of relevant discussion in
http://www.python.org/dev/peps/pep-0343/
.
--
http://mail.python.org/mailman/listinfo/python-list
