Re: os.access with wildcards

[mike]

thanks Leif.  poor question on my part.

I had been using

glob.glob(path)==[]

and was looking for something more readable, hence

os.system('[ -e %s ]' % path )

but that doesn't seem like a good idiom for crossplatform.

I thought there may either be a way to escape the wildcards, or an
alternative to os.access, or 

any othr ideas?

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: os.access with wildcards

[mike]

thanks Leif.  poor question on my part.

I had been using

glob.glob(path)==[]

and was looking for something more readable, hence

os.system('[ -e %s ]' % path )

but that doesn't seem like a good idiom for crossplatform.

I thought there may either be a way to escape the wildcards, or an
alternative to os.access, or 

any other ideas?

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: "no variable or argument declarations are necessary."

[Antoon Pardon]

Op 2005-10-06, Diez B. Roggisch schreef <[EMAIL PROTECTED]>:
>> Suppose we have a typesystem which has the type ANY, which would mean
>> such an object could be any type. You could then have homogenous lists
>> in the sense that all elements should be of the same declared type and
>> at the same time mix all kind of type in a particular list, just
>> as python does.
>
> The you have JAVA Object or C void*. Which cause all kinds of runtime 
> troubles because they essentially circumvene the typechecking!

Why do you call this a JAVA Object or C void*? Why don't you call
it a PYTHON object. It is this kind of reaction that IMO tells most
opponents can't think outside the typesystems they have already
seen and project the problems with those type systems on what
would happen with python should it acquire a type system.

>> So how would this limit python.
>
> The limitation is that in static languages I must _know_ what type to 
> cast such an ANY, before calling anything on it. Otherwise its useless.
>
>>>even though ususally the contents of a list 
>>>share some common behaviour. And that exactly is the key point here: in 
>>>a statically typed world, that common behaviour must have been extracted 
>>>and made explicit.
>> 
>> 
>> Would my suggestion be classified as a statically typed world?
>
> See above.

Your answer tells more about you then about my suggestion.

-- 
Antoon Pardon
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: non descriptive error

[Terry Hancock]

On Thursday 06 October 2005 11:57 pm, Timothy Smith wrote:
> i try to run my app and i get this
> 
> %python DutyShift.py
> error
> 
> thats it. thats the error. mya pp was previously working, and i did make 
> some fairly large changes to it, but i'd expect a more descriptive 
> message then just "error". anyidea where i need to start looking?

By looking at the source code for DutyShift.py?

--
Terry Hancock ( hancock at anansispaceworks.com )
Anansi Spaceworks  http://www.anansispaceworks.com

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: where to find information about errors/exceptions in socket.py

[Steve Holden]

[EMAIL PROTECTED] wrote:
> Version of python: 2.4
> O/S: Win2K
> 
> I will be writing some python scripts to do some client-side
> programming that involves socket.py.  I expect that I will be making
> calls to the following methods/functions:
> 
> connect_ex()
> setsockopt()
> sendall()
> recv()
> close()
> 
> Where can one find information about whether the functions/methods
> above return error codes that provide some indication as to whether the
> function/method succeeded?  Is there an exception class for handling
> exceptions raised in socket.py?  If so, where can one find information
> about it?
> 
> I consulted the docstrings and didn't find much about return codes or
> exception classes.  Also looked at the Lutz "Programming Python"
> text...it devotes several pages to socket programming, but I didn't
> observe much with regard to error/exception handling.
> 
I'd suggest reading the documentation myself:

 http://docs.python.org/lib/module-socket.html

regards
  Steve
-- 
Steve Holden   +44 150 684 7255  +1 800 494 3119
Holden Web LLC www.holdenweb.com
PyCon TX 2006  www.python.org/pycon/

-- 
http://mail.python.org/mailman/listinfo/python-list

Can't extend function type

[Paul Rubin]

Oh well.  I had wanted to be able to define two functions f and g, and
have f*g be the composition of f and g.

>>> func_type = type(lambda: None)
>>> class composable_function(func_type):
...   def __mult__(f,g):
... def c(*args, **kw):
...   return f(g(*args, **kw))
... return c
...
Traceback (most recent call last):
  File "", line 1, in ?
TypeError: Error when calling the metaclass bases
type 'function' is not an acceptable base type
>>>

Seems like a wart to me.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: non descriptive error

[[EMAIL PROTECTED]]

You should tell us more about DutyShift.py, without the code it is very
difficult for other people to guess what's going on.

-- 
http://mail.python.org/mailman/listinfo/python-list

ANN: MathDOM 0.5.0 - MathML in Python

[Stefan Behnel]

Hi everyone,

MathDOM 0.5 is ready for download from SourceForge.

http://mathdom.sourceforge.net/

MathDOM is a set of Python modules (using PyXML and pyparsing) that import
mathematical terms as a Content MathML DOM. It currently parses MathML and
literal infix terms into a DOM and writes out MathML and literal infix,
prefix, postfix or Python terms. The DOM elements are enhanced by domain
specific methods that make using the DOM a little easier.

You can call it the shortest way between different term representations and an
enhanced Content MathML DOM. Ever noticed the annoying differences between
terms in different programming languages? Build your application around the
DOM and stop careing about the term representation that users prefer or that
your machine can execute. If you need a different representation, add a
converter, but don't change the model. Literal terms are connected through an
intermediate AST step that makes writing converters for
Python/SQL/yourfavorite easier.

** New in 0.5.0 **

This release features a completely new API for term I/O. It uses
dictionary-like classes for registering input/output converters. This makes it
easier to extend the package with custom converters. It also means that 'old'
code will break, but since the package is farely recent, I hope that this will
not make its users too much trouble. If the new API is accepted, I will try to
keep it stable in further releases. The examples were updated to show how the
new API is used.


Have fun,
Stefan
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: non descriptive error

[Steve Holden]

Timothy Smith wrote:
> i try to run my app and i get this
> 
> %python DutyShift.py
> error
> 
> 
> thats it. thats the error. mya pp was previously working, and i did make 
> some fairly large changes to it, but i'd expect a more descriptive 
> message then just "error". anyidea where i need to start looking?

I would look inside *your* program! I don't ever remember Python 
producing any message so terse and unhelpful.

A way to check this would be to run python interactively and enter the 
statement

import DutyShift

though this won't necessarily run all the logic that gets run by your 
command.

regards
  Steve
-- 
Steve Holden   +44 150 684 7255  +1 800 494 3119
Holden Web LLC www.holdenweb.com
PyCon TX 2006  www.python.org/pycon/

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: "no variable or argument declarations are necessary."

[Steve Holden]

Antoon Pardon wrote:
> Op 2005-10-06, Diez B. Roggisch schreef <[EMAIL PROTECTED]>:
> 
>>>Suppose we have a typesystem which has the type ANY, which would mean
>>>such an object could be any type. You could then have homogenous lists
>>>in the sense that all elements should be of the same declared type and
>>>at the same time mix all kind of type in a particular list, just
>>>as python does.
>>
>>The you have JAVA Object or C void*. Which cause all kinds of runtime 
>>troubles because they essentially circumvene the typechecking!
> 
> 
> Why do you call this a JAVA Object or C void*? Why don't you call
> it a PYTHON object. It is this kind of reaction that IMO tells most
> opponents can't think outside the typesystems they have already
> seen and project the problems with those type systems on what
> would happen with python should it acquire a type system.
> 
[sigh]. No, it's just you being you. Diez' intention seemed fairly clear 
to me: he is pointing out that strongly-typed systems invariably fall 
back on generic declarations when they want to allow objects of any type 
(which, it seems to me, is what you were proposing as well).

In other words, you want Python to be strongly-typed, but sometimes you 
want to allow a reference to be to any object whatsoever. In which case 
you can't possibly do any sensible type-checking on it, so this new 
Python+ or whatever you want to call it will suffer from the same 
shortcomings that C++ and java do, which is to say type checking can't 
possibly do anything useful when the acceptable type of a reference is 
specified as ANY.

> 
>>>So how would this limit python.
>>
>>The limitation is that in static languages I must _know_ what type to 
>>cast such an ANY, before calling anything on it. Otherwise its useless.
>>
>>
even though ususally the contents of a list 
share some common behaviour. And that exactly is the key point here: in 
a statically typed world, that common behaviour must have been extracted 
and made explicit.
>>>
>>>
>>>Would my suggestion be classified as a statically typed world?
>>
>>See above.
> 
> 
> Your answer tells more about you then about my suggestion.
> 
Damn, I've been keeping away from this thread lest my exasperation lead 
me to inappropriate behaviour.

Is there any statement that you *won't* argue about?

leaving-the-(hopefully)-last-word-to-you-ly y'rs  - steve
-- 
Steve Holden   +44 150 684 7255  +1 800 494 3119
Holden Web LLC www.holdenweb.com
PyCon TX 2006  www.python.org/pycon/

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python, alligator kill each other

[Duncan Booth]

infidel wrote:
> A 13-foot Burmese python recently burst after it apparently tried to
> swallow a live 6-foot alligator whole, authorities said.
> 
An allegory telling how Python the language really ought to stay slim and 
lean and not get bloated by incorporating lots of features from other 
languages?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PyObject_New

[Martin v. Löwis]

Jeremy Moles wrote:
>   PyObject* obj = _PyObject_New(&PyType_MyType);
>   obj = PyObject_Init(obj, &PyType_MyType);
>   
>   ...
> 
>   return obj;

The call to PyObject_Init is redundant: _PyObject_New
is malloc+init. However, this shouldn't cause any crashes (except in the
debug build). PyObject_Init is documented as

Initialize a newly-allocated object op with its type and initial 
reference. Returns the initialized object. If type  indicates that the 
object participates in the cyclic garbage detector, it is added to the 
detector's set of observed objects. Other fields of the object are not 
affected.

[I don't know where the mentioning of GC comes from - it appears to be
  incorrect]

> When "obj" gets back to the interpreter, Python sees it (or rather, it's
> __repr__) in accordance with what it "should" be. However, any attempt
> to USE the object results in a segfault. I feel my problem is simply
> that I'm not allocating "obj" correctly in the C++ function.

It doesn't crash because of the allocation - this code is correct.
However, it is also incomplete: none of the state of the new object
gets initialized in the fragment you are showing. So it likely crashes
because the members of the object are stray pointers or some such,
and accessing them causes a crash.

Regards,
Martin
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Controlling who can run an executable

[Magnus Lycka]

Cigar wrote:
> What I want:
> - the simplest thing that could possibly work!

A splash screen that informs the user that it's
confidential data, and that unauthorized use will
lead to prosecution?

Besides, I think it's not the program you need to
protect, but the data. Think about that. Who cares
about a hardware dongle if they can access the
information you're trying to protect in notepad or
via ODBC and MS query etc.

She's as vulnerable if someone prints out a listing
of the clients and takes that, as if someone copies
the program. If you have the ability to generate
lists of data, you might not want that feature to be
accessible to "normal" users.

Finally, there's another nice trick that you can
do, now that most computers are hooked up on the
net. Make the program report when it's being used.
The easiest way might be to make it send an email,
but I'm not quite sure how you set it up to do that
on a windows box without asking the data-thief about
email settings. Virus-programs obviously do this,
so it can't be too hard. (Actually, to do something
in your program that will alert anti-virus programs
might be a good protection!)

You could also make the program "phone home" via
a socket etc, but that requires a server that can be
reached on the net.

But as others have said, you should make this a
client-server app, and make sure the server is
physically protected, difficult to break into
(a DOS box or an old MAC?) and only serve the right
kind of data to an authenticated user connected
locally.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: semi-newbie module namespace confusion

[Magnus Lycka]

[EMAIL PROTECTED] wrote:
> The main jist of the problem is that I'm trying add data from one
> module to a list and a dictionary in another module, and it doesn't
> seem to stick over there.

It's probably best to avoid any circular depentencies, but as
long as you make sure you really use your modules as modules,
and not one of them aas a main prorgam, I think it should work.

$ cat > a.py
import b
def set_b(n):
 b.b=n
$ cat > b.py
import a
def set_a(n):
 a.a=n
$ python
Python 2.2.3 (#1, Feb  2 2005, 12:20:51)
[GCC 3.2.3 20030502 (Red Hat Linux 3.2.3-49)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
 >>> import a,b
 >>> a.set_b('B')
 >>> b.set_a('A')
 >>> a.a
'A'
 >>> b.b
'B'
 >>>
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python, alligator kill each other

[Roel Schroeven]

infidel wrote:
> By Denise Kalette
> Associated Press
> 
> MIAMI - The alligator has some foreign competition at the top of the
> Everglades food chain, and the results of the struggle are horror-movie
> messy.
> 
> A 13-foot Burmese python recently burst after it apparently tried to
> swallow a live 6-foot alligator whole, authorities said.
> 
> ...
> 
> ... It is unknown how many pythons are competing with the thousands of
> alligators in the Everglades, but at least 150 have been captured in
> the past two years ...

When I read the title 'Python vs. Alligator' on Slashdot, I thought it
was about some comparison between Python and an unknown-to-me
programming language Alligator.

-- 
If I have been able to see further, it was only because I stood
on the shoulders of giants.  -- Isaac Newton

Roel Schroeven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: dcop module under Python 2.4

[Diez B. Roggisch]

[EMAIL PROTECTED] wrote:
> Hi all,
> at the end I upgraded to 2.4, but now I am not able to load dcop module
> (part of the Python-KDE3 bindings).
> Any help?

Install PyKDE for 2.4


Diez
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: "no variable or argument declarations are necessary."

[Paul Rubin]

Steve Holden <[EMAIL PROTECTED]> writes:
> In other words, you want Python to be strongly-typed, but sometimes
> you want to allow a reference to be to any object whatsoever. In which
> case you can't possibly do any sensible type-checking on it, so this
> new Python+ or whatever you want to call it will suffer from the same
> shortcomings that C++ and java do, which is to say type checking can't
> possibly do anything useful when the acceptable type of a reference is
> specified as ANY.

Let's see if I understand what you're saying:

C and Java: you get useful type checking except when you declare
a reference as type ANY.  This is a shortcoming compared to:

Python: where you get no useful type checking at all.

That is not very convincing logic.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: When someone from Britain speaks, Americans hear a "British accent"...

[Steve Holden]

DaveM wrote:
> On Fri, 07 Oct 2005 00:33:43 -, Grant Edwards <[EMAIL PROTECTED]> wrote:
[...]
> 
>>For example: In British English one uses a plural verb when the
>>subject consists of more than one person.  Sports teams,
>>government departments, states, corporations etc. are 
>>grammatically plural.  In American, the verb agrees with the
>>word that is the subject, not how many people are denoted by
>>that word.
>>
>>In sports (thats "sport" for you Brits):
> 
OK, so how do you account for the execresence "That will give you a 
savings of 20%", which usage is common in America?

There aren't any universal rules, except possibly "British people speak 
English while Americans don't". Nowadays relatively few people on either 
side of the Atlantic even know the difference between a collective noun 
and a plural, so there's little hope of them being able to correctly 
apply any rule there might be (and yes, I split that infinitive just to 
annoy any pedants who may be reading).
> 
> Yes.
> 
> 
>>American: Minnesota is behind 7-0.  The Vikings are behind 7-0.
>> British: Minnesota are behind 7-0. The Vikings are behind 7-0.
> 
> 
> True.
> 
> 
>>In politics:
> 
> 
>> American: The war department has decided to cancel the program.
>>  British: The war department have decided to cancel the program.
> 
> 
> Not sure about this one. They may be used interchangeably as neither strikes
> me as sounding "odd".
> 
Then again, there's room for infinite disagreement about these topics. I 
mentioned a while ago that I disliked the English on a bumper sticker I 
liked, which read

"Some village in Texas is missing their idiot".

Several people defended this, saying that a village could use the plural 
possessive "their". I personally found it odd (and essentially 
non-grammatical) not because either the singular or plural forms should 
be mandated but because this one manages to mix them up. So

"Some village in Texas are missing their idiot"

would be better (though it sounds like the kind of thing only the idiot 
alluded to would say), while my preferred choice would be

"Some village in Texas is missing its idiot".

Then again, what can you expect from a country whose leader pronounces 
"nuclear" as though it were spelled "nucular"? I suppose it's only a 
matter of time before they change the spelling just like they did with 
"aluminium".

tongue-in-cheek-ly y'rs  - steve
-- 
Steve Holden   +44 150 684 7255  +1 800 494 3119
Holden Web LLC www.holdenweb.com
PyCon TX 2006  www.python.org/pycon/

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: "no variable or argument declarations are necessary."

[Brian Quinlan]

Paul Rubin wrote:
> Brian Quinlan <[EMAIL PROTECTED]> writes:
> 
>>Without a clear idea of the nature of the proposal, it is impossible
>>to assess it's costs and benefits. So could a proponent of optional
>>declarations please provide a more clear proposal?
> 
> 
> There is no proposal on the table.  There's a discussion of how this
> stuff can work, and whether it's useful.  As for how the compiler
> deals with imported modules, see for example Common Lisp or Haskell or
> ML--how do they do it?

Except that you are providing neither useful input on how it could work 
nor on whether it would be useful. All you are doing is telling people 
to do research on other languages (that resumably do things in a way 
more to your liking).

In conclusion, this thread is unlikely to make any useful progress.

Cheers,
Brian
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Can't extend function type

[Diez B. Roggisch]

Paul Rubin wrote:
> Oh well.  I had wanted to be able to define two functions f and g, and
> have f*g be the composition of f and g.
> 
> >>> func_type = type(lambda: None)
> >>> class composable_function(func_type):
> ...   def __mult__(f,g):
> ... def c(*args, **kw):
> ...   return f(g(*args, **kw))
> ... return c
> ...
> Traceback (most recent call last):
>   File "", line 1, in ?
> TypeError: Error when calling the metaclass bases
> type 'function' is not an acceptable base type
> >>>
> 
> Seems like a wart to me.

Well - function inheritance is not known so far in python - and in no 
other language I know.

How do you expect to create f and g, even if above construct would work? 
Basdically you want __mult__ being part of f or g when python encounters 
  something like this

f * g

But then how did you plan to declare f?

def f(composable_function)(x):
 pass


obviously won't work.

So the only way to achieve this with current semantics is to make f anf 
g objects with a call methods. In that very moment, you're done - as 
extending from object is no problem :)


class ComposeableFunction(object):

 def __call__(self, *args, **kwargs):
return self.second(self.first(*args, **kwargs))

 def __mul__(self, other):
nc = ComposeableFunction()
nc.first = other
nc.second = self
return nc


class f(ComposeableFunction):
 def __call__(self, x):
return x * 2


class g(ComposeableFunction):
 def __call__(self, x):
return x + 2


f = f()
g = g()

print f(4)
print g(4)
print (f*g)(4)


Diez
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: "no variable or argument declarations are necessary."

[Steve Holden]

Paul Rubin wrote:
> Steve Holden <[EMAIL PROTECTED]> writes:
> 
>>In other words, you want Python to be strongly-typed, but sometimes
>>you want to allow a reference to be to any object whatsoever. In which
>>case you can't possibly do any sensible type-checking on it, so this
>>new Python+ or whatever you want to call it will suffer from the same
>>shortcomings that C++ and java do, which is to say type checking can't
>>possibly do anything useful when the acceptable type of a reference is
>>specified as ANY.
> 
> 
> Let's see if I understand what you're saying:
> 
> C and Java: you get useful type checking except when you declare
> a reference as type ANY.  This is a shortcoming compared to:
> 
> Python: where you get no useful type checking at all.
> 
> That is not very convincing logic.

As we say in Yorkshire, "There's none as thick as them that wants to 
be". Let's try to get this in context.

Antoon:
> Suppose we have a typesystem which has the type ANY, which would mean
> such an object could be any type. You could then have homogenous lists
> in the sense that all elements should be of the same declared type and
> at the same time mix all kind of type in a particular list, just
> as python does.

Diez:
> The you have JAVA Object or C void*. Which cause all kinds of runtime 
> troubles because they essentially circumvene the typechecking!

Antoon:
> Why do you call this a JAVA Object or C void*? Why don't you call
> it a PYTHON object. It is this kind of reaction that IMO tells most
> opponents can't think outside the typesystems they have already
> seen and project the problems with those type systems on what
> would happen with python should it acquire a type system.

Me:
> Diez' intention seemed fairly clear 
> to me: he is pointing out that strongly-typed systems invariably fall 
> back on generic declarations when they want to allow objects of any type 
> (which, it seems to me, is what you were proposing as well).

You:
> C and Java: you get useful type checking except when you declare
> a reference as type ANY.  This is a shortcoming compared to:
> 
> Python: where you get no useful type checking at all.
> 
The points that have repeatedly been made are:

1. That even the strict typings required by languages like Java and C++ 
actually end up getting in the way when the pragmatic requirements of 
real-world problems have to be taken into account.

2. That the benefits of declarations are overstated by many of their 
proponents.

3. That Python as it is today allows the dynamic creation of names, 
which are therefore inherently not available for declaration.

On existing evidence it's extremely unlikely that this post will end the 
thread, but I certainly wish *something* would. Unfortunately I seem to 
have become part of the problem in that respect :-)

regards
  Steve
-- 
Steve Holden   +44 150 684 7255  +1 800 494 3119
Holden Web LLC www.holdenweb.com
PyCon TX 2006  www.python.org/pycon/

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: "no variable or argument declarations are necessary."

[Paul Rubin]

Brian Quinlan <[EMAIL PROTECTED]> writes:
> > There is no proposal on the table.  There's a discussion of how this
> > stuff can work, and whether it's useful.  As for how the compiler
> > deals with imported modules, see for example Common Lisp or Haskell or
> > ML--how do they do it?
> 
> Except that you are providing neither useful input on how it could
> work nor on whether it would be useful. All you are doing is telling
> people to do research on other languages (that resumably do things in
> a way more to your liking).

Nah.  I just see the import statement as a solved problem.  Do it the
same way those other languages do.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: "no variable or argument declarations are necessary."

[Diez B. Roggisch]

> Why do you call this a JAVA Object or C void*? Why don't you call
> it a PYTHON object. It is this kind of reaction that IMO tells most
> opponents can't think outside the typesystems they have already
> seen and project the problems with those type systems on what
> would happen with python should it acquire a type system.

Well, because maybe I wanted you to give you an example of languages 
that are statically typed and have such an any construct - that, by the 
way, is not a piece of inguine imagination of yours, but has been 
thought of before, e.g. CORBA (and called there any, too)? It makes no 
sense putting python into that context - as it is _not_ statically 
typed. Which you should know, after discussing this very subject way too 
long.

>>>Would my suggestion be classified as a statically typed world?
>>
>>See above.
> 
> 
> Your answer tells more about you then about my suggestion.

Your answer tells us something too: Just because you don't know anything 
about typechecking does not mean that you are in the position to make 
assumptions on "how things could work if the people who know stuff 
wouldn't be so stupid". That's like saying "cars can't fly because the 
stupid engineers lack my sense of imagination."

Just blathering about the possibility of some super-duper-typechecker 
and countering criticism or being told about problems in that domain by 
making bold statements that this sure could work - provide us with an 
implementation.

Or maybe - just maybe - you could sit back and think about the fact that 
lots of people who are way cleverer than you and me have been working on 
this subject, and so far haven't found a way. Which doesn't necessarily 
mean that there is no way - but certainly its hard, theory-laden work 
and won't emerge in a NG discussion by some snide remarks of either you 
or anybody else.


Diez
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: "no variable or argument declarations are necessary."

[Diez B. Roggisch]

Paul Rubin wrote:
> Steve Holden <[EMAIL PROTECTED]> writes:
> 
>>In other words, you want Python to be strongly-typed, but sometimes
>>you want to allow a reference to be to any object whatsoever. In which
>>case you can't possibly do any sensible type-checking on it, so this
>>new Python+ or whatever you want to call it will suffer from the same
>>shortcomings that C++ and java do, which is to say type checking can't
>>possibly do anything useful when the acceptable type of a reference is
>>specified as ANY.
> 
> 
> Let's see if I understand what you're saying:
> 
> C and Java: you get useful type checking except when you declare
> a reference as type ANY.  This is a shortcoming compared to:
> 
> Python: where you get no useful type checking at all.
> 
> That is not very convincing logic.

No, he said that this typechecking wouldn't make sense in the case of 
ANY being used. And the plethorea of ClassCastExceptions and Segfault 
proves the point :)

Diez
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: "no variable or argument declarations are necessary."

[Ben Sizer]

Paul Rubin wrote:

> Let's see if I understand what you're saying:
>
> C and Java: you get useful type checking except when you declare
> a reference as type ANY.  This is a shortcoming compared to:
>
> Python: where you get no useful type checking at all.
>
> That is not very convincing logic.

It's started to get very misleading - Python gives you plenty of
type-checking, as we all know, just not at compile-time. Also comparing
Python to C/Java as you have done is not very appropriate unless you
want Python to have the same sort of compile times as C and Java do.

I think you're doing a small disservice to respond to Steve when not
acknowledging the context of the thread, where Diez was explaining that
the system used in ML would not work in Python, then Antoon made a
suggestion that would fix that particular problem but make others
worse.

I'm not convinced that the Java route - where you type out lengthy type
declarations to get some compile-time typechecking which you usually
end up having to bypass later anyway - is at all beneficial, at least
not in the context of Python. I can't ever remember a time when I
thought "type checking really saved me from a bug there" when using
C/C++/Java, but I _can_ remember many times where I've had to consider
which cast or conversion to use, or had to write another overloaded
function to accommodate a similar-but-different type, or debug a
complex template message, or add a superfluous base class or interface,
all just to get the kind of genericity that Python gives for free. And
it's no good saying that variable declarations will be optional,
because as soon as these statically-typed variables enter the standard
library, every Python programmer will have to take these considerations
on board when writing their code, whether we want to use them or not.

-- 
Ben Sizer

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: [Info] PEP 308 accepted - new conditional expressions

[Robin Becker]

As mentioned earlier only a dictator can make such decisions and of course as 
with many dictatorships the wrong decision is often made. There's no such thing 
as a benevolent dictatorship.
-- 
Robin Becker

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: os.access with wildcards

[Fredrik Lundh]

Leif K-Brooks wrote:

>>os.access(path,mode)
>>
>> where path may contain linux style wildcards.
>
> os.access(glob.glob(path), mode)

Traceback (most recent call last):
  File "", line 1, in ?
TypeError: access() argument 1 must be string, not list

it's not clear from the OP if he wants

[os.access(file, mode) for file in glob.glob(path))]

os.access(glob.glob(path)[0], mode)

or, most likely, simply

if glob.glob(path):
... some matching file exists ...

 



-- 
http://mail.python.org/mailman/listinfo/python-list

Re: "no variable or argument declarations are necessary."

[Roy Smith]

"Ben Sizer" <[EMAIL PROTECTED]> wrote:
> It's started to get very misleading - Python gives you plenty of
> type-checking, as we all know, just not at compile-time.

There's more to it than just that.  Python's type checking is not just not 
done at compile time, it's done as late in run time as possible.  One might 
call it just-in-time type checking.

It's not hard to imagine a Python-like language which included (perhaps 
optional) variable declarations.  A declaration would essentially be an 
assertion which was checked after each assignment to that name.  So, you 
could write:

int i = 5
i = 5.6

and the second statement would throw TypeError.  This would give you 
C++/Java style type safety, but it still wouldn't be compile time.

Perhaps a better way to describe it is that the checking isn't an is-a 
assertion, but an acts-like assertion (sort of like Java's interfaces).  To 
take an example, in the function:

def first3(y):
if len(y) < 3:
 return y
return y[0:3]

all I really need from the argument is that I can call len() on it and it 
can be sliced.  An easy way to describe this would be to say that y must be 
a sequence, but that's not strictly accurate, since I can easily declare my 
own class which meets those requirements without being a subclass of 
sequence (even ignoring for the moment that 'sequence', while talked about 
in the documentation, doesn't actually exist as something you can subclass).
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: non descriptive error

[Tomasz Lisowski]

Timothy Smith wrote:
> i try to run my app and i get this
> 
> %python DutyShift.py
> error
> 
> 
> thats it. thats the error. mya pp was previously working, and i did make 
> some fairly large changes to it, but i'd expect a more descriptive 
> message then just "error". anyidea where i need to start looking?

It seems to me, like a result of a "print" statement, exexcuted 
somewhere (maybe in the except: clause). You may look for lines similar to:

print "error"

Tomasz Lisowski
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: "no variable or argument declarations are necessary."

[Antoon Pardon]

Op 2005-10-07, Steve Holden schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>> Op 2005-10-06, Diez B. Roggisch schreef <[EMAIL PROTECTED]>:
>> 
Suppose we have a typesystem which has the type ANY, which would mean
such an object could be any type. You could then have homogenous lists
in the sense that all elements should be of the same declared type and
at the same time mix all kind of type in a particular list, just
as python does.
>>>
>>>The you have JAVA Object or C void*. Which cause all kinds of runtime 
>>>troubles because they essentially circumvene the typechecking!
>> 
>> 
>> Why do you call this a JAVA Object or C void*? Why don't you call
>> it a PYTHON object. It is this kind of reaction that IMO tells most
>> opponents can't think outside the typesystems they have already
>> seen and project the problems with those type systems on what
>> would happen with python should it acquire a type system.
>> 
> [sigh]. No, it's just you being you. Diez' intention seemed fairly clear 
> to me: he is pointing out that strongly-typed systems invariably fall 
> back on generic declarations when they want to allow objects of any type 
> (which, it seems to me, is what you were proposing as well).

It is not about falling back on generic declarartion, it is about
how such object will be treated. Diez seems to think that
strongly-typed language can only deal with generic declarations
by using something that allows circumventing the type system.

> In other words, you want Python to be strongly-typed, but sometimes you 
> want to allow a reference to be to any object whatsoever. In which case 
> you can't possibly do any sensible type-checking on it, so this new 
> Python+ or whatever you want to call it will suffer from the same 
> shortcomings that C++ and java do, which is to say type checking can't 
> possibly do anything useful when the acceptable type of a reference is 
> specified as ANY.

And you are wrong. The problem with the C void* construct (I'm not that
familiar with java) is that all type information is lost. When you
use such a parameter in a function you have no idea what you are
working with.

But that doesn't need to be if you have a typesystem with an ANY type.
Such a type declaration would mean that object of any type could be
used here. However that doesn't imply that the type information
of the actual objects used, has to be lost. That type information
may still be available and usefull for further type checking.

That you and Diez can only think about C, C++ or java constructs
when I mention an ANY type, is your limitation. It doesn't
need to be the limitation of a specific type system.

-- 
Antoon Pardon
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Question

[contact]

Hi, this email address does not exist. Please go to the site and use the 
correct form to send your message.

No one has seen this message.

Thanks
Matchfinder
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: "no variable or argument declarations are necessary."

[Steven D'Aprano]

On Fri, 07 Oct 2005 06:01:00 -0400, Roy Smith wrote:

> There's more to it than just that.  Python's type checking is not just not 
> done at compile time, it's done as late in run time as possible.  One might 
> call it just-in-time type checking.

Well there you go then. Instead of pulling our hair out that Python has no
type checking ("that's a bug in the language design, woe woe woe!!!") we
can just say that Python does JIT type checking, which not only is a
feature, but also satisfies the Pointy Haired Bosses who demand buzzwords
they can't understand.

-- 
Steven.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: "no variable or argument declarations are necessary."

[Christophe]

Roy Smith a écrit :
> There's more to it than just that.  Python's type checking is not just not 
> done at compile time, it's done as late in run time as possible.  One might 
> call it just-in-time type checking.

It's more of a "Nearly too late" type checking I would say. Not that I 
complain but it would be great if there were also some automatic type 
checking to catch a few errors as soon as possible.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: New Python book

[Maurice LING]

I had the opportunity to glance through the book in Borders yesterday. 
On the whole, I think it is well covered and is very readable. Perhaps I 
was looking for a specific aspect, and I find that threads did not get 
enough attention. Looking at the index pages, the topics on threads 
(about 4-5 pages) is mainly found in the context of GUI programming.

maurice


Dick Moores wrote:

> (Sorry, my previous post should not have had "Tutor" in the subject 
> header.)
> 
> Magnus Lie Hetland's new book, _Beginning Python: From Novice to
> Professional_ was published by Apress on Sept. 26 (in the U.S.). My copy
> arrived in the mail a couple of days ago. Very much worth a look, IMHO.
> But what do the experts here think?
> 
> 
> 
> Dick Moores
> [EMAIL PROTECTED]
> 
> 

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: check html file size

[Xah Lee]

Xah Lee wrote: « would anyone like to translate the following perl
script to Python or Scheme (scsh)?»

Here's the Python version.

# -*- coding: utf-8 -*-
# Python


# Wed Oct  5 15:50:31 PDT 2005
# given a dir, report all html file's size. (counting inline images)
# XahLee.org

import re, os.path, sys

inpath= '/Users/t/web/'

while inpath[-1] == '/': inpath = inpath[0:-1] # get rid of trailing
slash

if (not os.path.exists(inpath)):
print "dir " + inpath + " doesn't exist!"
sys.exit(1)

##
# subroutines


def getInlineImg(file_full_path):
'''getInlineImg($file_full_path) returns a array that is a list of
inline images. For example, it may return ['xx.jpg','../image.png']'''

FF = open(file_full_path,'rb')
txt_segs = re.split( r'src', unicode(FF.read(),'utf-8'))
txt_segs.pop(0)
FF.close()
linx=[]
for linkBlock in txt_segs:
matchResult = re.search(r'\s*=\s*\"([^\"]+)\"', linkBlock)
if matchResult: linx.append( matchResult.group(1) )
return linx


def linkFullPath(dir,locallink):
'''linkFullPath(dir, locallink) returns a string that is the full
path to the local link. For example,
linkFullPath('/Users/t/public_html/a/b', '../image/t.png') returns
'Users/t/public_html/a/image/t.png'. The returned result will not
contain double slash or '../' string.'''
result = dir + '/' + locallink
result = re.sub(r'//+', r'/', result)
while re.search(r'/[^\/]+\/\.\.', result): result =
re.sub(r'/[^\/]+\/\.\.', '', result)
return result

def listInlineImg(htmlfile):
'''listInlineImg($html_file_full_path) returns a array where each
element is a full path to inline images in the html.'''
dir=os.path.dirname(htmlfile)
imgPaths = getInlineImg(htmlfile)
result = []
for aPath in imgPaths:
result.append(linkFullPath( dir, aPath))
return result


##
# main

fileSizeList=[]
def checkLink(dummy, dirPath, fileList):
for fileName in fileList:
if '.html' == os.path.splitext(fileName)[1] and
os.path.isfile(dirPath+'/'+fileName):
totalSize = os.path.getsize(dirPath+'/'+fileName)
imagePathList = listInlineImg(dirPath+'/'+fileName)
for imgPath in imagePathList: totalSize +=
os.path.getsize(imgPath)
fileSizeList.append([totalSize, dirPath+'/'+fileName])


os.path.walk(inpath, checkLink, 'dummy')

fileSizeList.sort(key=lambda x:x[0],reverse=True)

for it in fileSizeList: print it
print "done reporting."



-
This Python version is a direct translation of the Perl version. They
match pretty much line by line.

for both the Python version and the Perl version, see:
 http://xahlee.org/perl-python/check_html_size.html

Would any lisper provides a Scheme version? i don't think i'll do a
Scheme version anytime soon. Please, Schemers, show us some fanfare.

 Xah
 [EMAIL PROTECTED]
∑ http://xahlee.org/

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: "no variable or argument declarations are necessary."

[Fredrik Lundh]

"Christophe" wrote:

> It's more of a "Nearly too late" type checking I would say. Not that I
> complain but it would be great if there were also some automatic type
> checking to catch a few errors as soon as possible.

use assert as the soonest possible point.  implementing "type gates" is
trivial, if you think you need them.

 



-- 
http://mail.python.org/mailman/listinfo/python-list

recursive function

[mg]

Hello,

In a recursive function like the following :


def foo( j ) :
  j += 1
  while j < n : j = foo( j )
  return j


in found that the recursivity is limited (1000 iterations). Then, I have 
two questions :
- why this mecanism has been implemented ?
- it is possible to increase or remove (and how) the number of iterations ?

Regards,
Mathieu
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: "no variable or argument declarations are necessary."

[Antoon Pardon]

Op 2005-10-07, Diez B. Roggisch schreef <[EMAIL PROTECTED]>:
>> Why do you call this a JAVA Object or C void*? Why don't you call
>> it a PYTHON object. It is this kind of reaction that IMO tells most
>> opponents can't think outside the typesystems they have already
>> seen and project the problems with those type systems on what
>> would happen with python should it acquire a type system.
>
> Well, because maybe I wanted you to give you an example of languages 
> that are statically typed and have such an any construct

But since I have no such type system in mind, such an example is useless.

> - that, by the 
> way, is not a piece of inguine imagination of yours, but has been 
> thought of before, e.g. CORBA (and called there any, too)? It makes no 
> sense putting python into that context - as it is _not_ statically 
> typed. Which you should know, after discussing this very subject way too 
> long.

The fact that something else uses the same name, for something
doesn't mean it has to be implemented the same way.

Would my suggestion be classified as a statically typed world?
>>>
>>>See above.
>> 
>> 
>> Your answer tells more about you then about my suggestion.
>
> Your answer tells us something too: Just because you don't know anything 
> about typechecking does not mean that you are in the position to make 
> assumptions on "how things could work if the people who know stuff 
> wouldn't be so stupid". That's like saying "cars can't fly because the 
> stupid engineers lack my sense of imagination."

Then argue against my ideas, and not your makings of it.

If I just use 'ANY' and you fill that in with C void* like
implementation and argue against that, then you are arguing
against your own ghosts, but not against what I have in mind.

It may very well turn out that my idea is useless, but I will
only accept that when someone comes with arguments against
my actual idea, and not with arguements against their projection
of it.

> Just blathering about the possibility of some super-duper-typechecker 
> and countering criticism or being told about problems in that domain by 
> making bold statements that this sure could work - provide us with an 
> implementation.

You have not counterd my idea with criticism. You have decorated my
idea with how you think it would be implemented (C void*) and argued
against that. I don't need to give an implementation to notice, that
you jumped to a particular implementation and basicly just countered
that implementation, not the idea in general.

> Or maybe - just maybe - you could sit back and think about the fact that 
> lots of people who are way cleverer than you and me have been working on 
> this subject, and so far haven't found a way. Which doesn't necessarily 
> mean that there is no way - but certainly its hard, theory-laden work 
> and won't emerge in a NG discussion by some snide remarks of either you 
> or anybody else.

As far as I'm concerned that was just meant as a matter of fact remark,
with no snide intentions.

-- 
Antoon Pardon
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: When someone from Britain speaks, Americans hear a "British accent"...

[Steven D'Aprano]

On Fri, 07 Oct 2005 09:01:21 +0100, Steve Holden wrote:

> and yes, I split that infinitive just to 
> annoy any pedants who may be reading

*Real* pedants will know that English is not Latin, does not follow the
grammatical rules of Latin, and that just because split infinitives are
impossible -- not forbidden, impossible -- in Latin is no reason to forbid
them in English.

The linguist Steven Pinker calls the sort of people who claim split
infinitives are bad English "language mavens", and he doesn't mean it as
a compliment. See, for example, chapter 12 in his book "The Language
Instinct".


[snip]
> "Some village in Texas is missing their idiot".
> 
> Several people defended this, saying that a village could use the plural 
> possessive "their". 

"Several people" being the idiots missed by the villages? :-)

> I personally found it odd (and essentially 
> non-grammatical) not because either the singular or plural forms should 
> be mandated but because this one manages to mix them up. So
> 
> "Some village in Texas are missing their idiot"
> 
> would be better (though it sounds like the kind of thing only the idiot 
> alluded to would say), 

Absolutely. "Some villages" would work, but not village singular.

> while my preferred choice would be
> 
> "Some village in Texas is missing its idiot".

Yes, that's the puppy.

I think where the people are getting confused is that it is (arguably)
acceptable to use "their" in place of "his or her", as in:

"Should the purchaser lose their warranty card..."

Some of the more conservative grammarians argue against that construction,
many accept it in informal speech or writing but not formal, and a few
(like myself!) argue that it is time to get with the 21st century and just
accept it even in formal language. If it was good enough for Willie
Shakespeare, it is good enough for me.


-- 
Steven.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: "no variable or argument declarations are necessary."

[Christophe]

Fredrik Lundh a écrit :
> "Christophe" wrote:
> 
> 
>>It's more of a "Nearly too late" type checking I would say. Not that I
>>complain but it would be great if there were also some automatic type
>>checking to catch a few errors as soon as possible.
> 
> 
> use assert as the soonest possible point.  implementing "type gates" is
> trivial, if you think you need them.

Still, it would be great if there were also some automatic type checking 
  in place. Using assert is hardly automatic and non intrusive.

I mean, why not ? Why does the compiler let me do that when you know 
perfectly that that code is incorrect :
def f():
  return "a" + 5

Of course the system can't be perfect but it doesn't need to be. It 
doesn't need to constrain us in any way but if it can detect some errors 
early, then it is worth it.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: py2exe 0.6.3 released

[could ildg]

Nice job~Thank you.On 10/7/05, Jimmy Retzlaff <[EMAIL PROTECTED]> wrote:
py2exe 0.6.3 released=py2exe is a Python distutils extension which converts Python scriptsinto executable Windows programs, able to run without requiring aPython installation. Console and Windows (GUI) applications, Windows
NT services, exe and dll COM servers are supported.Changes in 0.6.3:* First release assembled by py2exe's new maintainer, Jimmy  Retzlaff. Code changes in this release are from Thomas Heller
  and Gordon Scott.* The dll-excludes option is now available on the command line.  It was only possible to specify that in the options argument to  the setup function before.  The dll-excludes option can now be used to filter out dlls like
  msvcr71.dll or even w9xpopen.exe.* Fix from Gordon Scott: py2exe crashed copying extension modules  in packages.Changes in 0.6.2:* Several important bugfixes:  - bundled extensions in packages did not work correctly, this
made the wxPython single-file sample fail with newer wxPythonversions.  - occasionally dlls/pyds were loaded twice, with very strangeeffects.  - the source distribution was not complete.
  - it is now possible to build a debug version of py2exe.Changes in 0.6.1:* py2exe can now bundle binary extensions and dlls into the  library-archive or the executable itself.  This allows to
  finally build real single-file executables.  The bundled dlls and pyds are loaded at runtime by some special  code that emulates the Windows LoadLibrary function - they are  never unpacked to the file system.
  This part of the code is distributed under the MPL 1.1, so this  license is now pulled in by py2exe.* By default py2exe now includes the codecs module and the  encodings package.
* Several other fixes.Homepage:Download from the usual location:<
http://sourceforge.net/project/showfiles.php?group_id=15583>Enjoy,Jimmy--http://mail.python.org/mailman/listinfo/python-list

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: recursive function

[Juho Schultz]

mg wrote:
> Hello,
> 
> In a recursive function like the following :
> 
> 
> def foo( j ) :
>  j += 1
>  while j < n : j = foo( j )
>  return j
> 
> 
> in found that the recursivity is limited (1000 iterations). Then, I have 
> two questions :
> - why this mecanism has been implemented ?
> - it is possible to increase or remove (and how) the number of iterations ?
> 
> Regards,
> Mathieu

Try the following for answers to both questions:

import sys
print sys.setrecursionlimit.__doc__

I guess 1000 is the default value.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: When someone from Britain speaks, Americans hear a "British accent"...

[Richie Hindle]

[Steve]
> and yes, I split that infinitive just to 
> annoy any pedants who may be reading

[Steven]
> *Real* pedants will know that English is not Latin, does not follow the
> grammatical rules of Latin, and that just because split infinitives are
> impossible -- not forbidden, impossible -- in Latin is no reason to forbid
> them in English.

Your previous post to this thread was chock-full of split nominatives: "The
Hollywood voice", "the specific regional accent", "the English-speaking
world", "the original French".  And you call yourself a grammarian.

-- 
Richie Hindle
[EMAIL PROTECTED]
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: recursive function

[Brandon K]

Is there no way to implement your idea in a classical loop? Usually the 
syntax is cleaner, and there is no limit (except the limit of the range 
function in certain cases).  For example what would be wrong with.

def foo(j):
 while j < n:
j+=1
 return j

I don't know much about the internals of python, but to me it seems like 
if you're going to be doing this on the level of 1000s of iterations, 
there might be some overhead to using recursion (i.e. function calls) 
that a loop wouldn't have (but that's just a guess).

> Hello,
> 
> In a recursive function like the following :
> 
> 
> def foo( j ) :
>  j += 1
>  while j < n : j = foo( j )
>  return j
> 
> 
> in found that the recursivity is limited (1000 iterations). Then, I have 
> two questions :
> - why this mecanism has been implemented ?
> - it is possible to increase or remove (and how) the number of iterations ?
> 
> Regards,
> Mathieu


== Posted via Newsgroups.com - Usenet Access to over 100,000 Newsgroups 
==
Get Anonymous, Uncensored, Access to West and East Coast Server Farms! 
== Highest Retention and Completion Rates! HTTP://WWW.NEWSGROUPS.COM ==


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: recursive function

[Brandon K]

> def foo(j):
> while j < n:
> j+=1
> return j
> 

of course I mean:
def foo(j):
 while j < n:
 j+=1
 return j

sorry


== Posted via Newsgroups.com - Usenet Access to over 100,000 Newsgroups 
==
Get Anonymous, Uncensored, Access to West and East Coast Server Farms! 
== Highest Retention and Completion Rates! HTTP://WWW.NEWSGROUPS.COM ==


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: divide

[Andrew Gwozdziewycz]

Do the divisions have to be themselves rectangles?


xB_C___x
x_Ax


would be a representation of the problem?
However, though, I think that what you mean with your Points being  
smaller and things, is that the points are centered in the middle of  
their peice of the rectangle, whichs makes the problem really easy.
If that is the case, notice that:
 width of Rectangle A =  2 * the_x_coordinate_ofA
  Subsequent widths can be found by subtracting the left side of the  
rectangle from the equation above. This is modified as follows

width of Rectangle X = 2 * the_x_coordinate_ofX - width_so_far

The height of your rectangles will all be the same (if i read the  
question right), so translating this to python is simple.






On Oct 6, 2005, at 10:33 PM, Shi Mu wrote:

> I have three points in a rectangle and i wonder how to use PYTHON  
> to divide the rectangle into three
> parts with each point located in the different part.
> For instance, Point A
> goes to Part I, Point B goes to Part II and Point C goes to Part III.
> And the distance between any point within Part I and Point A is  
> smaller than to Point B and Point C. And the similar rule applies  
> to Part II and Part III.
> Thanks for any idea.
> -- 
> http://mail.python.org/mailman/listinfo/python-list

---
Andrew Gwozdziewycz
[EMAIL PROTECTED]
http://ihadagreatview.org
http://plasticandroid.org


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: "no variable or argument declarations are necessary."

[Paul Rubin]

"Fredrik Lundh" <[EMAIL PROTECTED]> writes:
> use assert as the soonest possible point.  implementing "type gates" is
> trivial, if you think you need them.

What this is about (to me at least) is the edit-debug cycle.  Let's
say I write some Python code, using assert to validate datatypes.
Maybe I've made 4 errors.  I then write a test function and run it.
Boom, the first assert fails.  I fix the first error, run again.
Boom, the next assert fails.  Fix the next error, run again, boom,
fix, etc.  Four edit-debug cycles.

With static typing, I run the compiler, get 4 error messages, fix all
4, and can get on with the next phase of testing with three fewer edit
cycles.  That's a definite benefit of languages like Java.  It's not
imaginary.  Unit tests on Python code don't make it go away.  I have
less Java experience than Python experience by now, but I still find
that Java programs take me fewer iterations to get working than Python
programs.  The trouble is that Java has a thousand deficiencies that
outweigh that particular benefit, so overall I like Python a lot
better anyway.

Now some of the Python-is-perfect crowd seems to suffer from a "Blub
paradox" (http://c2.com/cgi/wiki?BlubParadox).  They see annoying,
static typed languages like C and Java, and they see pleasant,
dynamically typed languages like Python, and conclude that static
types = annoying, when in fact they can be orthogonal.  So, can there
be a language that's both statically typed, and pleasant?  I haven't
used one yet, but lately I've been reading about Haskell and want to
give it a try.  I keep finding statements like:

To me, Haskell is what Python should have evolved to. As a long-time
Python programmer, I have been very, very pleased with Haskell and am
currently working on porting my code to it (and write new code in
Haskell at every opportunity).
   (http://supybot.com/Members/jemfinch/haskell-sucks/document_view)

or:

Using Haskell to develop OpenAFP.hs led to programs that eat constant
2MB memory, scale linearly, and are generally 2OOM faster than my Perl
library.

Oh, and the code size is 1/10.
   (http://www.perl.com/pub/a/2005/03/03/pugs_interview.html -
Autrijus also raves about how great the book "Types and
Programming Languages" supposedly is--I'm trying to borrow
a copy.  Yeah, this is a Perl comparison, but I think of
Perl as being roughly equivalent to Python except a lot uglier).

or:

Haskell is the least-broken programming language available today. C,
C++, Perl, Python, Java, and all the other languages you've heard of
are all much more broken, so debating their merits is pointless. :-)
Unfortunately Real Life involves dealing with brokenness.
   (http://www106.pair.com/rhp/books.html)

or:

In conducting the independent design review at Intermetrics, there
was a significant sense of disbelief.  We quote from [CHJ93]: "It
is significant that Mr. Domanski, Mr. Banowetz and Dr. Brosgol
were all surprised and suspicious when we told them that Haskell
prototype P1 (see appendix B) is a complete tested executable
program.  We provided them with a copy of P1 without explaining
that it was a program, and based on preconceptions from their past
experience, they had studied P1 under the assumption that it was a
mixture of requirements specification and top level design.  They
were convinced it was incomplete because it did not address issues
such as data structure design and execution order."
   (http://haskell.org/papers/NSWC/jfp.ps - this was from a bake-off
   for a military application where the Haskell solution had 85 lines
   of code to Ada's 767, C++'s 1105, and Relational Lisp's 274). 

Obviously I'm in the usual rose-colored-glasses phase of finding out
about something new and interesting, but I can't help thinking these
guys are onto something.  Quite a few of the Haskell Cafe mailing list
members seem to have come to Haskell from Python.  (Haskell tutorial:
http://www.isi.edu/~hdaume/htut/ - I've read most of this and it looks
pretty cool--definitely a steeper learning curve than Python but the
result looks a lot more powerful).
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: New Python book

[Jeremy Jones]

Maurice LING wrote:

>I had the opportunity to glance through the book in Borders yesterday. 
>On the whole, I think it is well covered and is very readable. Perhaps I 
>was looking for a specific aspect, and I find that threads did not get 
>enough attention. Looking at the index pages, the topics on threads 
>(about 4-5 pages) is mainly found in the context of GUI programming.
>
>maurice
>
>  
>
I don't have my hard copy of the book, but from memory and grepping over 
the soft copy, you appear to be correct.  Remember, though, that this is 
a beginning book on Python and *I* would consider threading a more 
advanced topic.  I think putting threading in the context of GUI 
programming is just about right for an intro book.

- jmj
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: "no variable or argument declarations are necessary."

[Diez B. Roggisch]

Antoon Pardon wrote:
> Then argue against my ideas, and not your makings of it.
>
> If I just use 'ANY' and you fill that in with C void* like
> implementation and argue against that, then you are arguing
> against your own ghosts, but not against what I have in mind.

Well, you didn't tell us what you had in mind. You just said "let's
introduce something like any". I showed you existing implementations of
such a concept that have problems. You say "thats not what _I_ have in
mind, so your criticism doesn't apply." Guess what, I can't read your
mind. But you did not tell me in what your idea is different from
existing concepts.

> You have not counterd my idea with criticism. You have decorated my
> idea with how you think it would be implemented (C void*) and argued
> against that. I don't need to give an implementation to notice, that
> you jumped to a particular implementation and basicly just countered
> that implementation, not the idea in general.

Again - where is your idea layed out in (more) detail, so that one can
discuss them? That was all that I'm asking - which of course you
carefully avoided...

> As far as I'm concerned that was just meant as a matter of fact remark,
> with no snide intentions.

Where exactly come the facts? All I see is some vague "there should be
something better, by introducing ANY". But no details how typechecking
then would work. I showed you that existing type systems can't properly
cope with ANY so far and allow for much errors. Just saying "but mine
won't" is a little bit thin, don't you think?l

Diez

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python recipes: list mixin, improved timeit, etc

[Steven D'Aprano]

On Thu, 06 Oct 2005 21:03:33 -0700, barnesc wrote:

> I added some recipes to the Python Cookbook:
> 
>  - listmixin
> 
>Use ListMixin to create custom list classes from a small subset of
>list methods:
> 
>http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/440656

That looks great. Now, if only I understood mixins: what are they, and
what they are for, and in particular, how they differ from mere
subclassing.

I've spent some time searching for a good definition on the web, but the
main problem I've found is that most discussions on mixins assume
you already know what they are. Those that don't are talking about
Ruby or Lisp or some other language other than Python. I don't speak
those languages, so their code examples don't make a lot of sense to me.

Anyhoo, I've struggled on, but obviously I Just Don't Get It because
using mixins looks like subclassing to me.

Can anyone help me understand what's going on?


Thanks,


-- 
Steven.

-- 
http://mail.python.org/mailman/listinfo/python-list

Python interpreter bug

[alainpoint]

Hello,

I came accross what i think is a serious bug in the python interpreter.

Membership testing seems not to work for list of objects when these
objects have a user-defined __cmp__ method.
It is present in Python 2.3 and 2.4. I don't know about other versions.
The following code illustrates the bug:
from random import choice
class OBJ:
def __init__(self,identifier):
self.id=identifier
self.allocated=0
def __cmp__(self,other):
return cmp(other.allocated,self.allocated)
mylist=[OBJ(i) for i in range(20)]
excluded=[obj for obj in mylist if obj.id>choice(range(20))]
for obj in mylist:
if obj in excluded:
assert obj.id in [objt.id for objt in excluded]
continue

Running the above snippet will trigger the assert. The culprit seems to
be the __cmp__ method which sorts on a key with constant value.
Best regards
Alain

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python recipes: list mixin, improved timeit, etc

[Michele Simionato]

Well, suppose you have a class MyObject and you want to add to it some
methods to make its instances into a database. You could put these
methods into another class called Storable (the mixin class).
Then you can mix MyObject with Storable and get what you want,
a class StorableObject inheriting both from Storable and MyObject.
Of course you can reuse Storable to make storable even other
classes, for  instance you could define a StorableOtherObject
inheriting from OtherObject and Storable.

Once in a time, I thought mixins where a good idea; now I don't think
so since they are too easily abused (see Zope 2) and as a consequence
you get spaghetti-inheritance, where you have objects with methods
inherited from everywhere. So be very careful if you want to use
mixins; often you can go without them.

Just my 2 Euro cents,

  Michele Simionato

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: "no variable or argument declarations are necessary."

[Diez B. Roggisch]

> It is not about falling back on generic declarartion, it is about
> how such object will be treated. Diez seems to think that
> strongly-typed language can only deal with generic declarations
> by using something that allows circumventing the type system.

No, I don't - now it's you who makes assumptions about what I think. ML
and other FPs show that genericity can be done without circumvening.
Templates and generics in C++ partially do so.
>
> > In other words, you want Python to be strongly-typed, but sometimes you
> > want to allow a reference to be to any object whatsoever. In which case
> > you can't possibly do any sensible type-checking on it, so this new
> > Python+ or whatever you want to call it will suffer from the same
> > shortcomings that C++ and java do, which is to say type checking can't
> > possibly do anything useful when the acceptable type of a reference is
> > specified as ANY.
>
> And you are wrong. The problem with the C void* construct (I'm not that
> familiar with java) is that all type information is lost. When you
> use such a parameter in a function you have no idea what you are
> working with.

You don't know JAVA - I do. And nobody said that it lost that
type-information. It doesn't. Still, errors occur - namely
ClassCastEcxeptions.

That indicates that going back and forth via ANY doesn't necessarily
lose any type information, but the capability of today's type-systems
to keep that information across such a transition. This won't work:

Object foo = A();
B bar = (B) foo;

And please, pretty please don't argue with the simplicity of that
example - think of a bazillion statements between these two, possibly
done with run-time-instantiated classes that weren't known at
compile-time.

> But that doesn't need to be if you have a typesystem with an ANY type.
> Such a type declaration would mean that object of any type could be
> used here. However that doesn't imply that the type information
> of the actual objects used, has to be lost. That type information
> may still be available and usefull for further type checking.

JAVA has that.

> That you and Diez can only think about C, C++ or java constructs
> when I mention an ANY type, is your limitation. It doesn't
> need to be the limitation of a specific type system.

Again: where are the specifics of this system? In your head? Tell us
the gory detail, please.

Diez

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: "no variable or argument declarations are necessary."

[Roy Smith]

Paul Rubin  wrote:
> What this is about (to me at least) is the edit-debug cycle.  Let's
> say I write some Python code, using assert to validate datatypes.
> Maybe I've made 4 errors.  I then write a test function and run it.
> Boom, the first assert fails.  I fix the first error, run again.
> Boom, the next assert fails.  Fix the next error, run again, boom,
> fix, etc.  Four edit-debug cycles.
> 
> With static typing, I run the compiler, get 4 error messages, fix all
> 4, and can get on with the next phase of testing with three fewer edit
> cycles.

That's certainly the plan, but my experience is that it's not the whole 
story, for a few reasons.

1) I can often run 4 Python edit-debug cycles in the time it takes me to 
run a single C++ cycle, especially if there's a whole pile of build system 
gunk layered on top of the raw compile step.

2) When I get a bunch of compile errors, I know that many of them are just 
cascaded from a single problem.  Thus, I tend to fix the first one and only 
take a quick look at all the others.  If it's obvious what the problem is, 
I'll fix it, but as often as not, I'll just recompile and see what pops out 
the next time.

3) Many times, I'll spend more time making the compiler happy than the 
protection it affords me is worth.  C++ is such a complex language, it's 
really hard to write a compiler which follows every detail of the spec, and 
the details are what kills you.  We had a case the other day where a 
const_cast of a reference returned by a function worked just fine on 
Solaris, but failed on HPUX.  We ended up with three guys digging through 
reference manuals trying to figure out how const_cast and references are 
supposed to interact.  We ended up deciding what we were doing was legal, 
but we still had to devise a work-around so it compiled on all platforms.  
It's actually a little more complex than that, because we don't even write 
raw const_cast's, we use a CONST_CAST macro to work around older compilers 
that don't support modern casting, so we burned a little more time 
double-checking that our macro expansion wasn't at fault.  We could have 
done a lot of Python edit-debug cycles in the time it took to sort that one 
out.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python recipes: list mixin, improved timeit, etc

[Paul Rubin]

Steven D'Aprano <[EMAIL PROTECTED]> writes:
> That looks great. Now, if only I understood mixins: what are they, and
> what they are for, and in particular, how they differ from mere
> subclassing.

I'm not sure what you mean by "mere subclassing" so maybe there is no
difference.  Mixins are sort of a design pattern, not any whiz-tech
thing.  The terminology comes from Flavors which was one of the early
multiple inheritance OOP systems.  Flavors terminology was inspired by
ice cream: you could go to Tosci's and get plain ice cream, or ice
cream with your choice of various mix-ins like raisins, M&M's, heath
bar pieces, etc., which you could combine orthogonally.  In Flavors
and in Python, mix-ins are superclasses that you inherit to turn on a
feature.  The classic example is a Window class, with mixins for
scroll bars, title bars, pulldown menu, etc.  So if you want a window
with a scroll bar, you'd say

   class Window_with_scroll_bar(Window, Scrollbar): pass

and you'd get a class that understands the operations of both windows
and scroll bars.  Flavors had automatic method combination that you
have to spell out manually in Python, making the scheme a little bit
less useful.  But see SocketServer for a clever example of mixins to
implement concurrency in a TCP listener.  The basic server class is
TCPServer and you inherit from ThreadingMixin to make a threading
server or ForkingMixin to make a forking server.

I guess what makes something a mix-in is that you normally don't
inherit from it directly.  You inherit from some other class and the
mix-in is an "add-on" superclass that supplies some extra functionality.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: "no variable or argument declarations are necessary."

[Diez B. Roggisch]

> Now some of the Python-is-perfect crowd seems to suffer from a "Blub
> paradox" (http://c2.com/cgi/wiki?BlubParadox).  They see annoying,
> static typed languages like C and Java, and they see pleasant,
> dynamically typed languages like Python, and conclude that static
> types = annoying, when in fact they can be orthogonal.  So, can there
> be a language that's both statically typed, and pleasant?  I haven't
> used one yet, but lately I've been reading about Haskell and want to
> give it a try.

Nobody says that there can't be possibly better languages like python
overall, or for specific tasks. However, this discussion is about
introducing type-checking to python. And as someone who has done his
fair share of FP programming let me assure you that

 - all declarations are fully type annotated. The inference only comes
into play on _expressions_. The result in python would be that you'd
have to write

def foo(x:int):int :
 return 10

but then could use

x = foo()

which made the inference possible. But it _doesn't figure out that foo
returns an int because there is one returned, and misses the :int in
the declaration! Genericity is reached through solving somewhat more
complicated type equations - but these still require declarations:

def bar(l:list[whatever]):whatever :
 return head(l)

x = bar([10])

can be resolved as [] will me a list-constructor that gets passed an
int literal - wich in turn means that whatever as type-variable is
bound to int, and thus x is an int, as that is the return type of bar.

 - FPs share their own set of problems - try writing a server. The have
inherent troubles with event-driven programs. Then you need monads, and
that makes things a little bit more ugly...

Still, FP is cool. But python too. And just attaching some
type-inference to python won't work.

Diez

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python recipes: list mixin, improved timeit, etc

[Paul Rubin]

"Michele Simionato" <[EMAIL PROTECTED]> writes:
> Once in a time, I thought mixins where a good idea; now I don't think
> so since they are too easily abused (see Zope 2) and as a consequence
> you get spaghetti-inheritance, where you have objects with methods
> inherited from everywhere. So be very careful if you want to use
> mixins; often you can go without them.

Yeah, I wonder though how much of that is a result of Python's
cavalier approach to multiple inheritance.  Does that happen much in
CLOS?  In Java because of multiple interfaces?  I've studied Flavors a
little and mix-ins were used in some extensive ways, but maybe
programs using them required extra care.

The Python tutorial does caution against indiscriminate use of
multiple inheritance.  I tried coding something without it, wished
that I'd used it and did so in the next version, but still am not sure
if I gained anything or not.
-- 
http://mail.python.org/mailman/listinfo/python-list

CSV like file format featured recently in Daily Python URL?

[Alex Willmer]

I'm trying to track down the name of a file format and python module,
that was featured in the Daily Python URL some time in the last month or
two.

The format was ASCII with a multiline header defining types for the
comma seperated column data below. It may have had the capability to
store multiple tables in one file. There was news on the homepage that
an alternate 'no data here' syntax was also supported.

An example file had vaguely this structure:

columnname as datatype
columnname as datatype
columnname as datatype
columnname as datatype

data,data,data,data
data,"other data",data,data
data,data,"",data

Can anyone remember this file format/python module?

With thanks

Alex

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: "no variable or argument declarations are necessary."

[Paul Rubin]

"Diez B. Roggisch" <[EMAIL PROTECTED]> writes:
>  - FPs share their own set of problems - try writing a server. The
> have inherent troubles with event-driven programs.

Erlang?

> Still, FP is cool. But python too. And just attaching some
> type-inference to python won't work.

Yeah, I've figured declarations in Python would be more like Common
Lisp's, i.e. optional, enforced at compile time only when the compiler
can easily figure it out, and at runtime otherwise.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Continuous system simulation in Python

[François Pinard]

[Robert Kern]

> [...] an ODE integrator would probably want to adaptively select its
> timesteps as opposed to laying out a uniform discretization upfront.

Eons ago, I gave myself such a little beast (but really found in an
Appendix of a book on simulation), which I use since then whenever I
need it, not so often in these days.  If you are curious, see:

  http://fp-etc.progiciels-bpi.ca/rke.html

yet I'm sure there is just plenty of such things, all around.

The above is in C, not in Python.  I vaguely remember having once
rewritten the thing in Python, then discarded the result as not fast
enough for the need I then had.  If I really needed to use it nowadays,
I'll probably try to quickly link it through Pyrex.  Or just look around
a bit for some already made, and maybe better solution. :-)

It is easy and convenient, when writing a mixed discrete and continuous
simulation system, to tie the advancement control of the various active
ODE solvers within the main loop of the discrete event scheduler.

-- 
François Pinard   http://pinard.progiciels-bpi.ca
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python recipes: list mixin, improved timeit, etc

[Steven D'Aprano]

On Fri, 07 Oct 2005 05:11:00 -0700, Michele Simionato wrote:

> Well, suppose you have a class MyObject and you want to add to it some
> methods to make its instances into a database. You could put these
> methods into another class called Storable (the mixin class).
> Then you can mix MyObject with Storable and get what you want,
> a class StorableObject inheriting both from Storable and MyObject.
> Of course you can reuse Storable to make storable even other
> classes, for  instance you could define a StorableOtherObject
> inheriting from OtherObject and Storable.

So mixins are just a sub-class [pun intended] of sub-classing?

I've just found this:

[quote]
A mixin class is a parent class that is inherited from - but not as
a means of specialization. Typically, the mixin will export services to a
child class, but no semantics will be implied about the child "being a
kind of" the parent.
[end quote]

from http://c2.com/cgi/wiki?MixIn

Is that all they are?

It is amazing how you can take the simplest concept, and by using
appropriate terminology, make it as confusing and opaque as you want...

*wink*


-- 
Steven.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: "no variable or argument declarations are necessary."

[Diez B. Roggisch]

Paul Rubin wrote:
> "Diez B. Roggisch" <[EMAIL PROTECTED]> writes:
> >  - FPs share their own set of problems - try writing a server. The
> > have inherent troubles with event-driven programs.
>
> Erlang?

Guess what, worked with that, too :) And let me assure you - it does
have pretty much runtime type error issues. It's interpreted. I'm not
sure what the compiler/parser gets at loading a source file. And the
Mnesia distributed database lets you easily query the wrong values...
It's interesting, and it's concurrent programming paradigms are great.
But it's far from being perfect, and needs thourough testing before
deploying new code.

> > Still, FP is cool. But python too. And just attaching some
> > type-inference to python won't work.
>
> Yeah, I've figured declarations in Python would be more like Common
> Lisp's, i.e. optional, enforced at compile time only when the compiler
> can easily figure it out, and at runtime otherwise.

Easy cases are easy... The thing is: I'm all for typechecking as long
as it doesn't burden me. In FP it doesn't, as the expressional power is
way better. But in JAVA, it does. And just doing wishful-thinking about
that Python should do better that won't help... :)

Diez

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: When someone from Britain speaks, Americans hear a "British accent"...

[Steve Holden]

Richie Hindle wrote:
> [Steve]
> 
>>and yes, I split that infinitive just to 
>>annoy any pedants who may be reading
> 
> 
> [Steven]
> 
>>*Real* pedants will know that English is not Latin, does not follow the
>>grammatical rules of Latin, and that just because split infinitives are
>>impossible -- not forbidden, impossible -- in Latin is no reason to forbid
>>them in English.
> 
> 
> Your previous post to this thread was chock-full of split nominatives: "The
> Hollywood voice", "the specific regional accent", "the English-speaking
> world", "the original French".  And you call yourself a grammarian.
> 
I am presuming this post was meant to be a joke? No smileys, though, so 
you force us to make up our own minds.

Or is "the green tomato" also unacceptable?

regards
  Steve
-- 
Steve Holden   +44 150 684 7255  +1 800 494 3119
Holden Web LLC www.holdenweb.com
PyCon TX 2006  www.python.org/pycon/

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Can Python replace TCL/Expect

[Jorgen Grahn]

On Thu, 06 Oct 2005 17:08:03 GMT, Cameron Laird <[EMAIL PROTECTED]> wrote:
> In article <[EMAIL PROTECTED]>,
> Jorgen Grahn  <[EMAIL PROTECTED]> wrote:
>   .
>   .
>   .
>>It depends. I do not feel /that/ advanced, but I've been bitten by pexpect's
>>limitations several times in several places.
>>
>>... which puts me in a weird position ;-) I /loathe/ the Tcl language, but I
>>have to admit that its expect functionality is far superior to Python's.
>   .
>   .
>   .

> On to more constructive matters:  what are you doing about
> Pexpect's limitations?  Have the maintainers responded to you
> when you write?  Are you tempted to compose enhancements for
> yourself?

There is hobby hacking, and there is work. I've encountered pexpect during
work, and haven't had the time and energy to look into it. I hereby
apologize to the pexpect developers. Not for whining, but for not helping
out.

/Jorgen

-- 
  // Jorgen GrahnR'lyeh wgah'nagl fhtagn!
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python recipes: list mixin, improved timeit, etc

[Mike Meyer]

Steven D'Aprano <[EMAIL PROTECTED]> writes:
> On Thu, 06 Oct 2005 21:03:33 -0700, barnesc wrote:
>> I added some recipes to the Python Cookbook:
>> 
>>  - listmixin
>> 
>>Use ListMixin to create custom list classes from a small subset of
>>list methods:
>> 
>>http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/440656
>
> That looks great. Now, if only I understood mixins: what are they, and
> what they are for, and in particular, how they differ from mere
> subclassing.

One way to look at it is that mixins are a special case of
subclassing. They aren't different, just specific.

Mixins are abstract. Using Paul's example, you'd never declare a
ScrollBar object, only subclasses that also inherit from some form of
Window.

Mixins are about behavior, not type. If you have real mixins, then an
object of a class that inherits from a mixin is not an instance of the
mixin class.

Mixins are one way to deal with the lack of multiple inheritance. But
even languages with multiple inheritance find the idea useful.

http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python recipes: list mixin, improved timeit, etc

[Michele Simionato]

Paul Rubin wrote:
> Yeah, I wonder though how much of that is a result of Python's
> cavalier approach to multiple inheritance.  Does that happen much in
> CLOS?  In Java because of multiple interfaces?  I've studied Flavors a
> little and mix-ins were used in some extensive ways, but maybe
> programs using them required extra care.

I don't think Python approach to multiple inheritance is cavalier (you
may want
to clarify that statement). In CLOS multiple inheritance is less of a
problem
since (multi)methods are defined outside classes. One could argue that
using classes also as a scope-control mechanism (i.e. doing the job of
modules) is an abuse.

> The Python tutorial does caution against indiscriminate use of
> multiple inheritance.  I tried coding something without it, wished
> that I'd used it and did so in the next version, but still am not sure
> if I gained anything or not.

Nowadays I tend to use delegation via __getattr__ instead of multiple
inheritance.

Michele Simionato

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Can't extend function type

[Christopher Subich]

Diez B. Roggisch wrote:
> Paul Rubin wrote:
> 
>> Oh well.  I had wanted to be able to define two functions f and g, and
>> have f*g be the composition of f and g.
>>
>> >>> func_type = type(lambda: None)
>> >>> class composable_function(func_type):
>> ...   def __mult__(f,g):
>> ... def c(*args, **kw):
>> ...   return f(g(*args, **kw))
>> ... return c
>> ...
>> Traceback (most recent call last):
>>   File "", line 1, in ?
>> TypeError: Error when calling the metaclass bases
>> type 'function' is not an acceptable base type
>> >>>
>>
>> Seems like a wart to me.
> 
> So the only way to achieve this with current semantics is to make f anf 
> g objects with a call methods. In that very moment, you're done - as 
> extending from object is no problem :)
> 
> 
> class ComposeableFunction(object):
> 
> def __call__(self, *args, **kwargs):
> return self.second(self.first(*args, **kwargs))

Note, with a little bit of massaging, you can turn ComposableFunction 
into a decorator, for more natural function definition:

(Untested, I'm not on a system with Py2.4 at the moment):
class Composable(object):
 def __init__(self,f):
 self.callable = f
 def __call__(self,*args, **kwargs):
 return self.callable(*args, **kwargs)
 def __mul__(self,other):
 return Composable(lambda (*a, **kwa): self.callable(other(*a, 
**kwa)))

Usage:

@Composable
def f(x):
 return x**2

@Composable
def g(x):
 return x+1

# And we shouldn't even need a @Composable on the last in the sequence
def h(x):
 return x/2.0

 >>>f(1)
1
 >>>(f*g)(1)
4
 >>>(f*g*h)(2)
4

This might not combine neatly with methods, however; the bound/unbound 
method magic is still mostly voodoo to me.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: "no variable or argument declarations are necessary."

[Steve Holden]

Christophe wrote:
> Fredrik Lundh a écrit :
> 
>>"Christophe" wrote:
>>
>>
>>
>>>It's more of a "Nearly too late" type checking I would say. Not that I
>>>complain but it would be great if there were also some automatic type
>>>checking to catch a few errors as soon as possible.
>>
>>
>>use assert as the soonest possible point.  implementing "type gates" is
>>trivial, if you think you need them.
> 
> 
> Still, it would be great if there were also some automatic type checking 
>   in place. Using assert is hardly automatic and non intrusive.
> 
> I mean, why not ? Why does the compiler let me do that when you know 
> perfectly that that code is incorrect :
> def f():
>   return "a" + 5
> 
> Of course the system can't be perfect but it doesn't need to be. It 
> doesn't need to constrain us in any way but if it can detect some errors 
> early, then it is worth it.

While this is a perfectly acceptable feature request, we should remember 
that Python is developed and maintained by a volunteer team. Do we 
*really* want them spending their time adding "features" like this?

regards
  Steve
-- 
Steve Holden   +44 150 684 7255  +1 800 494 3119
Holden Web LLC www.holdenweb.com
PyCon TX 2006  www.python.org/pycon/

-- 
http://mail.python.org/mailman/listinfo/python-list

BayPIGgies: October 13, 7:30pm (IronPort)

[Aahz]

The next meeting of BayPIGgies will be Thurs, October 13 at 7:30pm at
IronPort.

Tim Thompson will describe and demonstrate the interaction between
Burning Man and Python using two applications, Radio Free Quasar and
Ergo.

BayPIGgies meetings alternate between IronPort (San Bruno, California)
and Google (Mountain View, California).  For more information and
directions, see http://www.baypiggies.net/


Before the meeting, we sometimes meet at 6pm for dinner.  Discussion of
dinner plans is handled on the BayPIGgies mailing list.  

Advance notice:  We've got some options on the plate for November 10 but
haven't settled anything yet.  Please send e-mail to
[EMAIL PROTECTED] if you want to suggest an agenda (or volunteer
to give a presentation).  The meeting agenda for December 8 has been set.
-- 
Aahz ([EMAIL PROTECTED])   <*> http://www.pythoncraft.com/

The way to build large Python applications is to componentize and
loosely-couple the hell out of everything.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Simple prototype text editor in python

[thakadu]

Thanks for everyones advice. I finally went
for a very basic BSD style template that
I found somewhere. Its really short and
easy to understand, at least to me!

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Book "Python and Tkinter Programming"

[projecktzero]

striker wrote:
> Does anyone who has this book willing to sell it.  Please e-mail me the
> condition and any other details if you are interested.
> Thanks,
> Kevin

half.com has a couple of people selling it. One for $35.24 and another
for $129.97.

-- 
http://mail.python.org/mailman/listinfo/python-list

How to run python scripts with IDLE

[vyzasatya]

Hi all,
My problem is
# I have to run a script which takes a command line parameter which is
unicode text
# I cant use Windows console as it doesnt support /display unicode
# I dont seems to find a way to pass command line arguments to scripts
in IDLE.
Please suggest me what I can do.
Thanks in Advance
Ravi

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Continuous system simulation in Python

[Robert Kern]

François Pinard wrote:
> [Robert Kern]
> 
>>[...] an ODE integrator would probably want to adaptively select its
>>timesteps as opposed to laying out a uniform discretization upfront.
> 
> Eons ago, I gave myself such a little beast (but really found in an
> Appendix of a book on simulation), which I use since then whenever I
> need it, not so often in these days.  If you are curious, see:
> 
>   http://fp-etc.progiciels-bpi.ca/rke.html
> 
> yet I'm sure there is just plenty of such things, all around.
> 
> The above is in C, not in Python.  I vaguely remember having once
> rewritten the thing in Python, then discarded the result as not fast
> enough for the need I then had.  If I really needed to use it nowadays,
> I'll probably try to quickly link it through Pyrex.  Or just look around
> a bit for some already made, and maybe better solution. :-)

scipy has wrapped LSODA and VODE from ODEPACK. There are a few more
integrators in ODEPACK which could easily be wrapped with f2py should
someone feel the urge. We'd probably wrap yours, too, if it weren't
GPLed.  ;-)

-- 
Robert Kern
[EMAIL PROTECTED]

"In the fields of hell where the grass grows high
 Are the graves of dreams allowed to die."
  -- Richard Harter

-- 
http://mail.python.org/mailman/listinfo/python-list

Python recipes: list mixin, improved timeit, etc

[barnesc]

>So mixins are just a sub-class [pun intended] of sub-classing?
>
>I've just found this:
>
>[quote]
>A mixin class is a parent class that is inherited from - but not as
>a means of specialization. Typically, the mixin will export services to a
>child class, but no semantics will be implied about the child "being a
>kind of" the parent.
>[end quote]
>
>from http://c2.com/cgi/wiki?MixIn
>
>Is that all they are?
>
>It is amazing how you can take the simplest concept, and by using
>appropriate terminology, make it as confusing and opaque as you want...
>
>*wink*
>

"A mixin is an atomic unit in an object-oriented language that adds
functionality to another class."

 - http://www.macromedia.com/support/documentation/en/flex/1/mixin/
   mixin2.html#118542

The only experience I've had with mixins is in Python, where
UserDict has a class DictMixin that defines the full dictionary
interface from a minimal subset of dictionary methods.

The Python docs don't define mixin.  I just assumed this was a case
where a programmer needed a name more descriptive than foo, so he
called it mixin, and that stuck.  :)

 - Connelly Barnes
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python interpreter bug

[Simon Percivall]

Why would it be a bug? You've made it so that every instance of OBJ is
equal to every other instance of OBJ. The behaviour is as expected.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python interpreter bug

[Steve Holden]

[EMAIL PROTECTED] wrote:
> Hello,
> 
> I came accross what i think is a serious bug in the python interpreter.
> 
> Membership testing seems not to work for list of objects when these
> objects have a user-defined __cmp__ method.
> It is present in Python 2.3 and 2.4. I don't know about other versions.
> The following code illustrates the bug:
> from random import choice
> class OBJ:
>   def __init__(self,identifier):
>   self.id=identifier
>   self.allocated=0
>   def __cmp__(self,other):
>   return cmp(other.allocated,self.allocated)
> mylist=[OBJ(i) for i in range(20)]
> excluded=[obj for obj in mylist if obj.id>choice(range(20))]
> for obj in mylist:
>   if obj in excluded:
>   assert obj.id in [objt.id for objt in excluded]
>   continue
> 
I presume you just put the "continue" in there for fun?

 >>> for obj in mylist:
...   print obj in excluded
...
True
True
True
True
True
True
True
True
True
True
True
True
True
True
True
True
True
True
True
True
 >>> OBJ(0) == OBJ(1)
True

> Running the above snippet will trigger the assert. The culprit seems to
> be the __cmp__ method which sorts on a key with constant value.

Well indeed. As far as I can see your objects will all test equal. Did 
you mean the __cmp__ method to return cmp(other.id, self.id)?

regards
  Steve
-- 
Steve Holden   +44 150 684 7255  +1 800 494 3119
Holden Web LLC www.holdenweb.com
PyCon TX 2006  www.python.org/pycon/

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Merging sorted lists/iterators/generators into one stream of values...

[George Sakkis]

"Lasse Vågsæther Karlsen" <[EMAIL PROTECTED]> wrote:

> Ok, that one looks more sleak than what I came up with.

For the most efficient and elegant solution, check out Raymond Hettinger's 
reply to:

http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/141934

George


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: "no variable or argument declarations are necessary."

[Antoon Pardon]

Op 2005-10-07, Diez B. Roggisch schreef <[EMAIL PROTECTED]>:
>
> Antoon Pardon wrote:
>> Then argue against my ideas, and not your makings of it.
>>
>> If I just use 'ANY' and you fill that in with C void* like
>> implementation and argue against that, then you are arguing
>> against your own ghosts, but not against what I have in mind.
>
> Well, you didn't tell us what you had in mind.

Indeed I hadn't. It wasn't needed for the question I posed then.

> You just said "let's
> introduce something like any". I showed you existing implementations of
> such a concept that have problems.

But as far as I can see that is a problem of the implementation
not necessarily of the concept.

> You say "thats not what _I_ have in
> mind, so your criticism doesn't apply." Guess what, I can't read your
> mind. But you did not tell me in what your idea is different from
> existing concepts.

Indeed you can't read my mind, but what pops up in your mind shows
your preconceptions. You could have just answered the question
as it was posed, instead of filling in the details yourself, maybe
remarking that you didn't see how it would work with current
type systems you know off.

>> You have not counterd my idea with criticism. You have decorated my
>> idea with how you think it would be implemented (C void*) and argued
>> against that. I don't need to give an implementation to notice, that
>> you jumped to a particular implementation and basicly just countered
>> that implementation, not the idea in general.
>
> Again - where is your idea layed out in (more) detail, so that one can
> discuss them? That was all that I'm asking - which of course you
> carefully avoided...

Sure I'm reluctant to give details. I consider this a hostile
environment, for this kind of proposals. I'm sure people will
be able to come up with all kind of problems my idea won't solve
and will see this as a reason to think the idea is useless.

Since I have no intention to 

>> As far as I'm concerned that was just meant as a matter of fact remark,
>> with no snide intentions.
>
> Where exactly come the facts?

About how you filled in the details yourself when all I mentioned
was a type system with an "ANY" type.

> All I see is some vague "there should be
> something better, by introducing ANY". But no details how typechecking
> then would work. I showed you that existing type systems can't properly
> cope with ANY so far and allow for much errors. Just saying "but mine
> won't" is a little bit thin, don't you think?l

The main idea is that type information would be available at two places.

1) The names, which carry the declared type.

2) The objects which carry the type/class they belong too.

When an object is bound to a name, a check is made that the type of the
object is compatible with the declared type of the name.

A name with type ANY, would be just like any python variable or
instance now. Python could implement this by instead of storing its
variables in dictionaries as (name, value) tuples, by storing them
as (name, declaration, value) tuples and making the necesarry checks
at (re)bind time. Variables that are not declared would get the
ANY declaration so that current scripts would just remain working
as they do now. But as the compiler got more sophisticated some
of these checks might be doable at compile time instead of at
run time.

-- 
Antoon Pardon
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python interpreter bug

[alainpoint]

There is definitely a bug.
Maybe the follownig snippet is more clear:
class OBJ:
def __init__(self,identifier):
self.id=identifier
self.allocated=0
#def __cmp__(self,other):
#   return cmp(other.allocated,self.allocated)
mylist=[OBJ(i) for i in range(10)]
excluded=[obj for obj in mylist if obj.id in [2,4,6,8]]
exclusion_list_by_id=[2,4,6,8]
print 'exclusion list by id=',exclusion_list_by_id
for obj in mylist:
print 'current obj=',obj.id,
if obj in excluded:
print ' ---> THIS OBJECT IS EXCLUDED'
assert obj.id in exclusion_list_by_id
continue
print

If you uncomment the two lines, the assert will be erroneously
triggered.
Alain

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Merging sorted lists/iterators/generators into one stream of values...

[Lasse Vågsæther Karlsen]

Thanks, that looks like Mike's solution except that it uses the
built-in heapq module.

While this one contains less code than Mike's solution it seems to lack
the ability to control the comparison operation, which means it won't
work in my case. I need to both be able to sort on an arbitrary field
name (could be done using a list where I place the field first), and
also to be able to sort in a different order than smallest-first.

Perhaps by adjusting the data that is returned through each source
would do that. I'll look into it.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: "no variable or argument declarations are necessary."

[Paul Rubin]

"Diez B. Roggisch" <[EMAIL PROTECTED]> writes:
> > Erlang?
> 
> Guess what, worked with that, too :) And let me assure you - it does
> have pretty much runtime type error issues. It's interpreted.

Yes, it makes no attempt at being statically typed.  It's like Python
that way, AFAIK.

> Easy cases are easy... The thing is: I'm all for typechecking as long
> as it doesn't burden me. In FP it doesn't, as the expressional power is
> way better. But in JAVA, it does. And just doing wishful-thinking about
> that Python should do better that won't help... :)

How about Lisp?  It seems to do some good there, without getting in
the way.
-- 
http://mail.python.org/mailman/listinfo/python-list

Python 2nd favorite language in Linux Journal poll

[beliavsky]

Linux Journal annually polls its readers on questions such as their
favorite programming language. In the 2005 poll, Python is 2nd, its
highest ranking ever. Below are the results by year. I wish that
rankings beyond the first 3 were available and that the number of votes
were shown. Nerds like numbers, not journalist blather :). I found this
data for earlier years by Googling

"linux journal  readers choice awards".

2005
1. C++
2. Python
3. PHP

2004
Favorite Programming Language
1. C
2. Perl
3. C++

Ah, favorite programming language-time for a flame war. A bit of a
shake-up this year: after being knocked out of first place last year, C
reclaims it this year and C++ drops to third. The P language in the top
three is Perl, while PHP slips to fourth place, closely followed by
Python. The voting was close this year, too; only 59 votes separated C
from C++.

2003
Favorite Programming Language
1. C++
2. C
3. PHP
Quick, everyone to your keyboard: the flame war begins in 5, 4, 3,
2In a reversal of last year's winner and runner-up, C++ moved into
first place in 2003 by a mere 23 votes. Perl, meanwhile, got kicked out
of the top three for the first time in the history of our awards.
Continuing the C theme, C# is the favorite write-in vote.

2002
Favorite Programming Language
1. C
2. C++
3. Perl

C++ kicked Perl out of the second-favorite position this year, and only
17 votes kept C++ out of the top spot. In its first year on the
``official'' list, Kylix/Object Pascal came in fourth. Following that
was a close vote spread between PHP, Java and Python, in that order.
One quite reasonable voter wrote in that he uses ``whichever is best
for the project''. And to the voter who felt bad about preferring bash
shell scripting, don't worry, you're not alone.

2001
Favorite Programming Language
1. C
2. Perl
3. C++

Here's another category where we took your advice from last year and
split C/C++ into separate categories because, hey, they're not the
same. Java and PHP finish out the top five, with Python just missing
out by 15 votes. Kylix/Object Pascal had a strong write-in showing,
over 200 votes.

2000
1. C/C++
2. Perl
3. Java

``Plain C (without the ++).''

The perennial C/C++ wins 40% of your votes this year. To everyone who
took the time to remind us that C and C++ are not the same language, we
hear you loud and clear. Second and third place go to Perl and Java,
while Python continues to expand its fan base by claiming 8%.

1999
1. C/C++
2. Perl
3. Java

``Something wants to make me vote for Logo... but I'll spare you. :)''

The old UNIX standard--the closest thing we have to a cross-platform
assembler--wins nearly half the vote at 49.4%. We'll have to split C
and C++ next year; we received countless ``I hate C++'' comments, a
sentiment shared by nearly everyone who voted. Perl had an excellent
showing, with 20.6% of the vote, compared to the up-and-coming Python
which scored 4%. At 9.5%, Java appears to have become rather popular,
and a concerted effort from PHP enthusiasts managed to score it 4.6%.
Emacs (meaning ELisp, probably) received a large number of write-ins.
Doesn't anyone use assembly code anymore?

1998
1. Perl
2. Tcl/Tk

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python interpreter bug

[Fredrik Lundh]

[EMAIL PROTECTED] wrote:

> I came accross what i think is a serious bug in the python interpreter.

> Membership testing seems not to work for list of objects when these
> objects have a user-defined __cmp__ method.

it does not work if they have *your* __cmp__ method, no.  if you add
a print statement to the method, you'll figure out why:

def __cmp__(self,other):
print "CMP", other.allocated, self.allocated
return cmp(other.allocated,self.allocated)

 



-- 
http://mail.python.org/mailman/listinfo/python-list

Re: When someone from Britain speaks, Americans hear a "British accent"...

[Richie Hindle]

[Richie]
> Your previous post to this thread was chock-full of split nominatives: "The
> Hollywood voice", "the specific regional accent", "the English-speaking
> world", "the original French".  And you call yourself a grammarian.

[Steve]
> I am presuming this post was meant to be a joke?

It was.

> No smileys, though, so you force us to make up our own minds.

Yes.  8-)

> Or is "the green tomato" also unacceptable?

It ought to be considered unacceptable by people who think that "to
correctly apply" is unacceptable, which is the point that Stephen was
making:

> *Real* pedants will know that English is not Latin, does not follow the
> grammatical rules of Latin, and that just because split infinitives are
> impossible -- not forbidden, impossible -- in Latin is no reason to forbid
> them in English.

Split nominatives like "the green tomato" are also impossible in Latin, but
no-one seems to object to their use in English.

-- 
Richie Hindle
[EMAIL PROTECTED]
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python interpreter bug

[alainpoint]

Sorry Fredrik but I don't understand. Just comment out the assert and
you have different results depending on whether an unrelated sort
function is defined.
This seems weird to me !

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Can't extend function type

[Paul Rubin]

"Diez B. Roggisch" <[EMAIL PROTECTED]> writes:
> Well - function inheritance is not known so far in python - and in no
> other language I know.

Yeah, I didn't really expect it to work, but it seems like a logical
consequence of type/class unification.

> Basically you want __mult__ being part of f or g when python
> encounters something like this
> 
> f * g
> 
> But then how did you plan to declare f?

Come to think of it, that's also a wart.  I'd been thinking of
using a decorator, as Christopher Subich suggested,

@composable
def f(x): ...

but it's not how the decorator could actually work (other than through
gross CPython-specific hacks).

> So the only way to achieve this with current semantics is to make f
> anf g objects with a call methods. In that very moment, you're done -
> as extending from object is no problem :)

Yeah, I thought of that, but felt it wasn't in the proper spirit :)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: [Info] PEP 308 accepted - new conditional expressions

[Eric Nieuwland]

Robin Becker wrote:

> As mentioned earlier only a dictator can make such decisions and of 
> course as
> with many dictatorships the wrong decision is often made. There's no 
> such thing
> as a benevolent dictatorship.

Ever cared to check what committees can do to a language ;-)

--eric

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python recipes: list mixin, improved timeit, etc

[George Sakkis]

"Steven D'Aprano" <[EMAIL PROTECTED]> wrote:

> I've just found this:
>
> [quote]
> A mixin class is a parent class that is inherited from - but not as
> a means of specialization. Typically, the mixin will export services to a
> child class, but no semantics will be implied about the child "being a
> kind of" the parent.
> [end quote]
>
> from http://c2.com/cgi/wiki?MixIn
>
> Is that all they are?
>
> It is amazing how you can take the simplest concept, and by using
> appropriate terminology, make it as confusing and opaque as you want...
>
> *wink*

 Now this reminds me of Xah's entertaining posts about "moronicities of the 
tech-geek industry
jargon" .

George


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python interpreter bug

[Steve Holden]

[EMAIL PROTECTED] wrote:
> Sorry Fredrik but I don't understand. Just comment out the assert and
> you have different results depending on whether an unrelated sort
> function is defined.
> This seems weird to me !
> 
Perhaps you don't understand what's going on. The test

 obj in excluded

is succeeding for all your objects because all instances of the OBJ 
class compare equal, and so the assert is failing for the ones that 
don;t actually appear in the "excluded" list.

regards
  Steve
-- 
Steve Holden   +44 150 684 7255  +1 800 494 3119
Holden Web LLC www.holdenweb.com
PyCon TX 2006  www.python.org/pycon/

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Can't extend function type

[Michele Simionato]

If you google a bit on the newsgroup, you should find a message
from me asking about the ability to subclass FunctionType, and
a reply from Tim Peters saying that the only reason why this
was not done is lack of developer time and the fact that this was
not considered an important priority.


 Michele Simionato

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: "no variable or argument declarations are necessary."

[Diez B. Roggisch]

> > You just said "let's
> > introduce something like any". I showed you existing implementations of
> > such a concept that have problems.
>
> But as far as I can see that is a problem of the implementation
> not necessarily of the concept.

Without any concept, sure there can't be problems with that concept.

> > You say "thats not what _I_ have in
> > mind, so your criticism doesn't apply." Guess what, I can't read your
> > mind. But you did not tell me in what your idea is different from
> > existing concepts.
>
> Indeed you can't read my mind, but what pops up in your mind shows
> your preconceptions. You could have just answered the question
> as it was posed, instead of filling in the details yourself, maybe
> remarking that you didn't see how it would work with current
> type systems you know off.

How can one answer a question without what he knows? Sure I fill in the
context. If I wouldn't know that this whole NG is about python, I
wouldn't know how to answer most of the questions that arise here.
Which is a general thing about communication.

But I certainly have had more contact with type systems than you had -
so my "filling-out" was by no means unreasonable - as you imply.
Without further details, one can only guess. And debuking guesswork by
saying "but _that_ wasn't what I meant" as you permanently do is easy -
but doesn't make _your_ point valid.

> Sure I'm reluctant to give details. I consider this a hostile
> environment, for this kind of proposals. I'm sure people will
> be able to come up with all kind of problems my idea won't solve
> and will see this as a reason to think the idea is useless.

Why hostile? Because people will possibly destroy your wishful thinking
by providing counter examples - if they exist? I doubt that a serious
proposal would get suppressed here - as the static compilers that have
shown up recently prove, as they have been greeted and met with
reasonable criticism where it was in order.

You didn't come up with an Idea so far, as I'm concerned. Just some
random thoughts.

But then again, here we go:

> The main idea is that type information would be available at two places.
>
> 1) The names, which carry the declared type.

 JAVA.

> 2) The objects which carry the type/class they belong too.

That already is the case.

> When an object is bound to a name, a check is made that the type of the
> object is compatible with the declared type of the name.

JAVA exactly does that.

> A name with type ANY, would be just like any python variable or
> instance now. Python could implement this by instead of storing its
> variables in dictionaries as (name, value) tuples, by storing them
> as (name, declaration, value) tuples and making the necesarry checks
> at (re)bind time. Variables that are not declared would get the
> ANY declaration so that current scripts would just remain working
> as they do now.

So far, this is exactly what java does - plus a more dynamic approach
to method/function invocation on ANY. So it seems my assumptions about
what you had in mind weren't so false after all, eh?

>But as the compiler got more sophisticated some
> of these checks might be doable at compile time instead of at
> run time.

Well, that exactly is the point where we make the transition from "this
is how things work" to pure speculation. Can't say that there won't be
a solution someday - but certainly it requires much more, and from
above nobody can say that this would solve _any_ problem.

What you propose above is what JAVA does - plus more dynamicity. Well,
given that even the  "non-dynamic, everything has to be annotated" JAVA
fails to deal with ANY (called Object there), I can't see how a more
dynamic environment will do _better_ in that respect. So unless you lay
out some more detailed ideas how that works, this surely won't do much
if any better than JAVA does today - and JAVA sucks _precisely_ because
of the half-static-half-dynamic nature. It gives you both troubles -
runtime errors like in python, together with compile-time limitations.

Let's face it: you don't know much about type-systems. I do know a bit
more - but don't claim to possess the holy grail. And I don't say that
more powerful analyzing isn't possible. However, all you do so far is
fantasizing and "fail to see why not". Well, that failure might be
because of limited sight on your side - not necessarily on our, which
you constantly claim.

Visions are a nice thing - but actually, in the scientific domain not
so much a vision, but proofs are what is needed. And if you consider it
hostile that nobody buys your ideas because so far they aren't more
than marketing/whishful thinking, I'm sorry that I can't help you.

Diez

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python interpreter bug

[alainpoint]

I understand this, Steve.
I thought the _cmp_ method was a helper for sorting purposes. Why is it
that a membership test needs to call the __cmp__ method?
If this isn't a bug, it is at least unexpected in my eyes.
Maybe a candidate for inclusion in the FAQ?
Thank you for answering
Alain

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Lambda evaluation

[Eric Nieuwland]

Joshua Ginsberg wrote:
> Try this one:
>
 d = {}
 for x in [1,2,3]:
> ... d[x] = lambda *args: args[0]*x
> ...
 d[1](3)

try it with:
d[x] = (lambda x=x: (lambda *args: args[0]*x))()

the outer lambda fixes the value of x and produces the inner lambda 
with the fixed x value

--eric

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python interpreter bug

[Fredrik Lundh]

[EMAIL PROTECTED] wrote:

> Sorry Fredrik but I don't understand. Just comment out the assert and
> you have different results depending on whether an unrelated sort
> function is defined.
>
> This seems weird to me !

not if you look at what it prints.

(if it seems weird to you that 0 equals 0, it's time for a break)

 



-- 
http://mail.python.org/mailman/listinfo/python-list

Re: in-memory db? gadfly?

[chris]

sqlite worked perfectly, thanks.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: When someone from Britain speaks, Americans hear a "British accent"...

[Rocco Moretti]

Steve Holden wrote:

>> On Fri, 07 Oct 2005 00:33:43 -, Grant Edwards <[EMAIL PROTECTED]> 
>> wrote:

>>> For example: In British English one uses a plural verb when the
>>> subject consists of more than one person.  Sports teams,
>>> government departments, states, corporations etc. are grammatically 
>>> plural.  In American, the verb agrees with the
>>> word that is the subject, not how many people are denoted by
>>> that word.
> 
> There aren't any universal rules, except possibly "British people speak 
> English while Americans don't". 

I believe you overgeneralize. :)

A Welshman would likely be offended if you implied he spoke English, and 
the Scots are notorious for only speaking English when they have too. (I 
remember a news story some years back about a Scottish "lad" who was 
fined/imprisoned for replying to an official court representative with 
"Aye" rather than "Yes".) For that matter there are plenty of people in 
Cornwall and even in London (Cockney) who speak something that is only 
called "English" for lack of a better term.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: When someone from Britain speaks, Americans hear a "British accent"...

[Grant Edwards]

On 2005-10-07, DaveM <[EMAIL PROTECTED]> wrote:

>>For example: In British English one uses a plural verb when the
>>subject consists of more than one person.  Sports teams,
>>government departments, states, corporations etc. are 
>>grammatically plural.  In American, the verb agrees with the
>>word that is the subject, not how many people are denoted by
>>that word.
>>
>>In sports (thats "sport" for you Brits):
>
> Yes.
>
>> American: Minnesota is behind 7-0.  The Vikings are behind 7-0.
>>  British: Minnesota are behind 7-0. The Vikings are behind 7-0.
>
> True.
>
>>In politics:
>
>>  American: The war department has decided to cancel the program.
>>   British: The war department have decided to cancel the program.
>
> Not sure about this one. They may be used interchangeably as neither strikes
> me as sounding "odd".

It could be that both are used in British English and I only
notice the "have" usage.  In US English it's always "has"
because "deptartment" is considered singular:

"departement has" and "departements have"

For some reason I find this sort of thing fascinating enough to
have download the entire "story of English" series off Usenet...

-- 
Grant Edwards   grante Yow!  Yow! Now we can
  at   become alcoholics!
   visi.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python interpreter bug

[[EMAIL PROTECTED]]

Your __cmp__ method will always return 0, so all objects will be equal
when you add the method, as Simon and Steve pointed out. The result is
all objects will pass the test of being a member of excluded.
If you do not add a __cmp__ method objects will be compared on identy -
call the id() function to see the identity of an object. An alternative
would be Steve's proposal to compare on the id attribute instead of the
allocated attribute

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python interpreter bug

[[EMAIL PROTECTED]]

Your __cmp__ method will always return 0, so all objects will be equal
when you add the method, as Simon and Steve pointed out. The result is
all objects will pass the test of being a member of excluded.
If you do not add a __cmp__ method objects will be compared on identy -
call the id() function to see the identity of an object. An alternative
would be Steve's proposal to compare on the id attribute instead of the
allocated attribute

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: "no variable or argument declarations are necessary."

[Fredrik Lundh]

"Christophe" wrote:

> I mean, why not ? Why does the compiler let me do that when you know
> perfectly that that code is incorrect :

> def f():
>   return "a" + 5

probably because the following set is rather small:

bugs caused by invalid operations involving only literals, that are not
discovered during initial testing

 



-- 
http://mail.python.org/mailman/listinfo/python-list