Re: Anonymous email users

[Sebastian Wells via Python-list]

On Fri, 14 Jun 2024 18:00:37 -0400, avi.e.gross wrote:

> I notice that in some recent discussions, we have users who cannot be
> replied to directly as their email addresses are not valid ones, and I
> believe on purpose. Examples in the thread I was going to reply to are:
>  
>   henha...@devnull.tb
>  
>   no.email@nospam.invalid
>  
>  
> candycanearter07@candycanearter07.nomail.afraid (user  is
> generated from /dev/urandom)
>  
> I know some here suggest that we only reply to the wider community and
> they have a point. But I think there is a role for having some
> conversations offline and especially when they are not likely to be
> wanted, or even tolerated, by many in the community.
>  
> Using such fake or invalid emails makes it hard to answer the person
> directly or perhaps politely ask them for more info on their request or
> discuss unrelated common interests. Worse, when I reply, unless I use
> reply-all, my mailer sends to them futilely. When I do the reply-all, I
> have to edit out their name or get a rejection.
>  

The spammers won the spam wars, so even if you have someone's real
e-mail address, that's no guarantee that you can contact them. You
certainly wouldn't be able to contact me at my real e-mail address,
unless you also had my phone number, so you could call me and tell
me that you sent me an e-mail, and what the subject line was so I
can find it. I don't even open my e-mail inbox unless there's a
specific message I'm expecting to find there right now.

With e-mail addresses being phone-validated, it's not easy to create
a new one either. And even if I did, you can't even trust e-mail 
providers not to give your address out to spammers.

The only function e-mail addresses serve now is to positively identify
the sender of a Usenet posting so he can be targeted for harassment,
lawsuits, or worse.
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue43656] TracebackException or StackSummary.extract with capture_locals=True fail to catch exceptions raised by repr() on value of frame local variable in FrameSummary.__init__.

[Joe Wells]

Joe Wells  added the comment:

Some quick comments on Martin's pull request.

1. The changes are sufficient to let the user make things work the way it is 
requested that they work and anyone who does not start using the new 
format_locals parameter will get the old behavior.

2. A side comment: I just noticed that the docstring for FrameSummary.__init__ 
does not document the filename, lineno, and name parameters.  Perhaps this 
could be fixed at the same time?

3. The new parameter format_locals is slightly confusingly named, because it 
does not format a single string from all the locals but instead gives a 
dictionary of strings with one string for each local.

4. I personally think it would be better to include something like the example 
value for format_locals as an extra attribute of the traceback module so 
everybody doesn't have to write the same function.  That said, the documented 
example is sufficient.

5. It is not clear to me why this stringify-ing of the locals can't be done in 
StackSummary._extract_from_extended_frame_gen.  It passes the dictionary of 
locals and also the function to transform it to FrameSummary.  It would make 
more sense to transform it first.  I suppose there might be some user somewhere 
who is directly calling FrameSummary so the interface needs to stay.

6. I fantasize that the new format_locals parameter would have access to the 
frame object.  In order for this to happen, the frame object would have to be 
passed to FrameSummary instead of the 3 values (locals, name, filename) that 
are extracted from it.  I think the current interface of FrameSummary was 
designed to interoperate with very old versions of Python.  Oh well.

7. If anyone wanted to ever refactor FrameSummary (e.g., to enable my fantasy 
in point #6 just above), it becomes harder after this.  This change has the 
effect of exposing details of the interface of FrameSummary to users of 
StackSummary.extract and TracebackException.  The four parameters that the new 
parameter format_locals takes are most of the parameters of FrameSummary.

--

___
Python tracker 
<https://bugs.python.org/issue43656>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43656] TracebackException or StackSummary.extract with capture_locals=True fail to catch exceptions raised by repr() on value of frame local variable in FrameSummary.__init__.

[Joe Wells]

Joe Wells  added the comment:

1. As background, it is worth remembering that a major motivation for why 
FrameSummary.__init__ stringifies the local variable values in its parameter 
locals is to prevent the resulting data structure from keeping those values 
live.  This enables them to be garbage collected.

2. It has been suggested that TracebackException.__init__ or 
StackSummary.extract could be given a function parameter.  This could either be 
a new parameter or could involve using the existing capture_locals parameter 
with a non-bool.  The purpose of this suggestion is to allow customizing the 
use of repr to stringify local variable values.  If this suggestion is 
followed, it would be quite useful if this function parameter was given not 
just the local variable values, but also the name of the local variable and 
maybe also the stack frame it is in.  This would enable filtering out undesired 
variables.  For example, I would usually prefer to filter most of the variables 
from the __main__ module frame, because they are just noise that makes it hard 
to see the important details.  Some ability to filter would also help with the 
security issue that is discussed in issue 23597 that Irit pointed to.

3. I doubt that new students will be setting up calls to TracebackException or 
modifying sys.excepthook on their own.  Although a simple interface is clearly 
good, it might be more important to have an interface that maximizes the 
usefulness of the feature.

4. I no longer have the tracebacks my students were getting.  You can look at 
the traceback from the example in msg 404319 for a traceback.  While I was 
debugging this, I got much more complicated tracebacks because two of the 
classes in traceback.py also throw exceptions during their __init__ method that 
leave the not-yet-initialized object in a repr-will-raise-an-exception state.  
Despite having decades of programming experience, it actually took me a long 
time before I realized that the exceptions I was debugging were junk exceptions 
due to attempts to call repr on not-yet-initialized objects.  I think figuring 
this out would be extremely challenging for my second-year undergraduate 
students.

5. If one of the calls to repr in FrameSummary.__init__ raises an exception, 
this prevents all the other local variable values from being inspected.  If it 
is desired to report local variable values that cause repr to raise an 
exception, then it would be good to collect all such exceptions, which requires 
handling each exception and then continuing to traverse the traceback stack.  
Because of point 1 above, it might often be best to turn each such exception 
into a string.  To avoid infinite loops in the debugging/logging tools, it 
would often be best not to attempt to traverse the traceback stack of each of 
these extra exceptions.  If this argument is a good argument, this seems to 
mean that my most recent proposed fix is a good balance.

6. It is not clear if there is a reliable way to detect whether repr raises an 
exception due to an object's initialization having been interrupted, but all of 
the failures that I observed of this sort were for the variable name “self”.  
In one case, the repr failure was for a normal local variable of an __new__ 
method which was not a parameter of this method; the variable was named “self” 
by convention, but this convention would be difficult to automatically verify.  
In the two other cases, the repr failure was for a parameter named “self” which 
was the first parameter of an __init__ method.  So it would help to give 
special treatment to the first parameter of __init__ methods, but this would 
not solve the problem for __new__ methods.

7. In some cases, it might be a bit complicated to ensure the object is always 
in a safe state for repr-ing during initialization.  This is because there may 
be many attributes that need to be modified and this is not generally done 
atomically.  One attribute could be designated to indicate that initialization 
is done, so that repr will be extra careful if that attribute does not have an 
expected value.  Given that this is only (so far) an issue for debuggers and 
traceback inspection tools, it is not clear how to motivate everyone who writes 
a __new__, __init__, or __repr__ method to do this safely.  Documentation can 
of course help.

--

___
Python tracker 
<https://bugs.python.org/issue43656>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45604] multiprocessing.log_to_stderr missing documentation for parameter

[Alex Wells]

New submission from Alex Wells :

The documentation for multiprocessing.log_to_stderr() specifies that the method 
takes no parameters. However, intellisense in VSCode and debugging the method 
both show that there is a single parameter, "level", whose default value is 
None. 
Documentation here:
https://docs.python.org/3.7/library/multiprocessing.html#multiprocessing.log_to_stderr

The parameter appears to be a shorthand to allow you to both get the logger and 
specify the required log level in one step, rather than two. The code that 
handles the "level" parameter appears to do what I'd expect it to do.

I think the documentation simply needs a few words written about the parameter.

Thanks.

--
assignee: docs@python
components: Documentation
messages: 404965
nosy: AlexWells, docs@python
priority: normal
severity: normal
status: open
title: multiprocessing.log_to_stderr missing documentation for parameter
type: enhancement
versions: Python 3.7

___
Python tracker 
<https://bugs.python.org/issue45604>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43656] TracebackException or StackSummary.extract with capture_locals=True fail to catch exceptions raised by repr() on value of frame local variable in FrameSummary.__init__.

[Joe Wells]

Joe Wells  added the comment:

In the hopes of convincing someone to install a fix to this bug, I will mention 
a few additional points.

When I mention “the capture_locals feature”, I mean calls of the form 
traceback.TracebackException(..., capture_locals=True) and 
traceback.StackSummary.extract(..., capture_locals=True).

1. Right now, the capture_locals feature is unreliable.  If any frame on the 
entire stack has a single local variable for which repr raises an exception, 
the user gets no information whatsoever back for the entire stack except for 
that exception, and that exception does not identify the offending stack frame 
or local variable.  Also, every use of the capture_locals feature must be 
inside a try-except statement.

2. The exceptions raised by the capture_locals feature will often be junk 
exceptions carrying no useful information.  The meaning of these exceptions 
will often be “there is an incompletely initialized object in a variable 
somewhere on the stack”.  Because this is a fairly normal state of affairs, 
this will often not be useful information.

3. Although it is a excellent idea to encourage Python coders to ensure that 
__repr__ method never raise exceptions, it seems unlikely this will cause many 
__repr__ methods to be fixed in the near future.  My impression is that 
__repr__ methods that raise exceptions on incompletely initialized objects are 
common.  One reason for this might be that authors of __repr__ methods rarely 
suffer from this problem personally, because they will generally supply correct 
arguments to their own class constructors, and even when they don't (e.g., 
while building unit tests), they are unlikely to try to format to strings all 
the local variable values on the stack in the exception traceback.

4. Right now, the caller of traceback.FrameSummary(..., locals=x) needs to go 
through the entire dict x and for every value v in x test whether repr(v) 
raises an exception and if so either remove the key/value pair or change the 
value to something which can be safely repr-ed.  Then FrameSummary.__init__ 
will repeat this work and run repr on every value in x again.  So using 
FrameSummary safely requires duplicating the work, i.e., running repr on every 
value in the dict both before and during the call to FrameSummary.

5. Anyone who is using the capture_locals feature on an exception traceback has 
already caught an exception, and therefore decided not to let that exception 
“bubble up”.  Their attempts to log or otherwise cope with the exception will 
be spoiled by the capture_locals feature raising an unrelated exception.  This 
is even worse when the exception raised by the capture_locals feature is a junk 
exception that merely indicates there is an incompletely initialized object on 
the stack.  This is likely to happen because exceptions will often happen 
during the initialization of an object.

6. The most recent suggested fix does in fact report the extra repr exception 
discovered by the capture_locals feature in the string that represents the 
local variable's value.  The main effect of the current code propagating this 
repr exception is to make it harder to deal with the original exception.

I hope these points are useful.

--

___
Python tracker 
<https://bugs.python.org/issue43656>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43656] TracebackException or StackSummary.extract with capture_locals=True fail to catch exceptions raised by repr() on value of frame local variable in FrameSummary.__init__.

[Joe Wells]

Joe Wells  added the comment:

Andrei, thanks very much for the pointer to bug/issue 
https://bugs.python.org/issue39228.  I had not noticed the earlier comment by 
Irit pointing to that bug.  (Is there some way to merge bugs so that someone 
visiting one of the bugs will see the merged stream of comments?)

The remarks in that bug are precisely why my recommended fix has this line:

d[k] = ''

instead of this:

d[k] = object.__repr__(v)

Does this not meet the concern expressed there?  Something that would more 
thoroughly meet that would be the following:

if locals:
d = {}
self.locals = d
for k, v in locals.items():
try:
d[k] = repr(v)
except Exception as e:
d[k] = ''
else:
self.locals = None

I use object.__repr__ instead of repr because when repr(v) has already failed 
it is likely that repr(e) on the exception e would also be likely to fail.  
Although we could also try repr(e) first to see if it raises an exception.

Your suggested reaction to this bug (documenting Python best practice) is 
something that should be done regardless.  I completely agree.  Unfortunately, 
better documentation of how to write good Python does not address the point of 
this bug which is that debugging tools should not fail when used to debug buggy 
code.  The purpose of a debugging tool is to help with badly written code, not 
to work only with well written code.  Right now the capture_locals=True feature 
is not safe to use without wrapping it with an exception handler.  As a result 
of this bug, I have been forced to rewrite this:

def format_exception_chunks(exception):
return (traceback.TracebackException.from_exception(exception, 
capture_locals=True).format())

to instead be this:

def format_exception_chunks(exception):
try:
tbe = (traceback.TracebackException
   . from_exception(exception, capture_locals=True))
return tbe.format()
except Exception:
pass
# the traceback module fails to catch exceptions that occur when
# formatting local variables' values, so we retry without
# requesting the local variables.
try:
tbe = traceback.TracebackException.from_exception(exception)
return ('WARNING: Exceptions were raised while trying to'
' format exception traceback with local variable'
' values,\n'
'so the exception traceback was formatted without'
' local variable values.\n',
*tbe.format())
except Exception:
return ('WARNING: Exceptions were raised while trying to format'
' exception traceback,\n'
'so no formatted traceback information is being'
' provided.\n',)

My argument is that it is better to fix the bug once in traceback.py instead of 
every user of the capture_locals=True feature having to discover the hard way 
(with hours of painful bug investigation) that they need to write lots of 
exception handling and bug workarounds around their use of the 
capture_locals=True feature.

--

___
Python tracker 
<https://bugs.python.org/issue43656>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43656] TracebackException or StackSummary.extract with capture_locals=True fail to catch exceptions raised by repr() on value of frame local variable in FrameSummary.__init__.

[Joe Wells]

Joe Wells  added the comment:

I'm sorry Andrei: I misread your alteration of my example and misunderstood its 
purpose.

For anyone else reading these messages: In my most recent comment above, please 
ignore the part of my comment about Andrei's example.

So yes, Andrei, that is how people should write their code!  Your code does not 
trigger the bug because it is written in a better way.  Agreed completely.

However, this bug still needs fixed because it is currently not possible to use 
the capture_locals=True feature of the traceback module when debugging code 
written by people who do not follow Andrei's example of best practice.

--

___
Python tracker 
<https://bugs.python.org/issue43656>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43656] TracebackException or StackSummary.extract with capture_locals=True fail to catch exceptions raised by repr() on value of frame local variable in FrameSummary.__init__.

[Joe Wells]

Joe Wells  added the comment:

Here are my thoughts inspired by Andrei's insightful comments.

1. In response to the major issue Andrei raises, I agree that it is desirable 
that repr would never raise an exception.  The reasons Andrei mentions seem 
quite correct to me.  However, I think the only practical way to make that 
change would be the change the code of the repr builtin.  (Expecting the 
authors of every class in all Python code ever written to make sure that their 
__repr__ method will never raise an exception is unrealistic.)

The bug that is the topic of the issue in this bug report can be fixed by 
merely handling exceptions raised by one particular call to repr in the code of 
FrameSummary.__init__.  That change can only affect code that uses the 
traceback module to get nicer tracebacks, and only if the capture_locals=True 
feature is requested

Changing the implementation of the repr builtin could conceivably cause 
unexpected problems for lots of deployed 3rd party code during normal use, 
because repr is widely used in deployed code, and hence more care and thought 
is needed.  In contrast, changing FrameSummary.__init__ as I propose in this 
bug report will only affect code using the capture_locals=True feature of the 
traceback module, and is likely to make such code more reliable because right 
now that feature is failure-prone due to this bug.

So I propose that making repr never raise exceptions should be a different bug. 
 This bug does not need to wait for that bug to be fixed.

2. In response to a minor point of Andrei, I would like to mention that I 
encountered this because I had given students a coursework template containing 
this code:

import traceback, sys

def format_exception_chunks(exception):
return (traceback.TracebackException.from_exception(exception, 
capture_locals=True).format())

def print_exception(_ignored_type, exception, _ignored_traceback):
for chunk in format_exception_chunks(exception):
print(chunk, file=sys.stderr, end="")

# This change to sys.excepthook adds local variables to stack traces.
sys.excepthook = print_exception

This had the unfortunate effect that when a class constructor decided that it 
did not like its arguments, the students were overwhelmed by a baffling cascade 
of exception tracebacks.  So while this was indeed “for convenience of 
interactive debugging”, it had the actual effect of making it nearly impossible 
for these beginner Python programmers to do any debugging at all.  The overall 
effect of this bug is that it makes it potentially unwise to routinely rely on 
the capture_locals=True feature.  A feature that could be useful for beginners 
actually makes it worse for them.

3. In response to Andrei's suggested change to my minimal example to reproduce 
the bug, I have a few comments.  First, his minimal example is just as good as 
mine for reproducing the bug.  Second, my example is inspired by the two 
classes I mention whose constructors trigger the bug: both of them do it by 
leaving the incompletely initialized object missing an attribute that repr 
depends on, so they both raise a missing attribute exception when an attempt is 
made to print the incompletely initialized object.  I suspect this is a quite 
common pattern in deployed Python code.  I suspect that people have not made 
efforts to avoid this pattern because it only triggers a bug when exception 
tracebacks are investigated, because the only reference to the incompletely 
initialized object is in the stack frame of the constructor method (either 
__new__ or __init__) which in turn is only referenced from the traceback.  
Third, my example deliberately has as little code as possible in the __repr__ 
method to convey the key issue.  Fourth, one of these two examples (mine or 
Andrei's) should go into the unit tests when the bug is fixed.

4. I notice that the code of unittest.util.safe_repr gives an example of how to 
use object.__repr__(obj) to get something formatted for an object whose normal 
__repr__ method has raised an exception.  So I alter my recommended fix to the 
following:

if locals:
d = {}
self.locals = d
for k, v in locals.items():
try:
d[k] = repr(v)
except Exception:
d[k] = ''
else:
self.locals = None

5. Can someone please change the Stage of this issue to something other than 
“resolved” and the Resolution of this issue to something other than “not a bug”?

I hope these comments are helpful and this bug gets somehow fixed.

--

___
Python tracker 
<https://bugs.python.org/issue43656>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43656] TracebackException or StackSummary.extract with capture_locals=True fail to catch exceptions raised by repr() on value of frame local variable in FrameSummary.__init__.

[Joe Wells]

Joe Wells  added the comment:

I would like to request that this bug be repopened and fixed.

I've changed (or at least tried to change, I'm not sure if it will let me) the 
title of the bug to point out that the failure happens in 
FrameSummary.__init__.  It does not happen in StackSummary.format.

This problem makes the capture_locals=True feature of TracebackException and 
StackSummary and the "locals" parameter of FrameSummary unreliable.  If any one 
of the local variables in any frame on the stack is in an inconsistent state 
such that repr will raise an exception, the processing of the traceback fails.  
This kind of inconsistent state is of course likely to happen during debugging, 
which is precisely when you would want the capture_locals feature to actually 
work so you can see what is going wrong.

Just one example of an exception traceback being created with an unsafe local 
variable value in one of the stack frames is in the following line:

  from _pydecimal import Decimal as D; D(None)

The _pydecimal.Decimal.__new__ method raises an exception when it sees a value 
it doesn't know how to convert to Decimal.  When it does this, the new object 
it was creating is left in an inconsistent state missing the _sign attribute.  
When you try to inspect the resulting exception traceback with 
traceback.TracebackException(..., capture_locals=True), this raises an 
exception.

While I was tracking this bug down, I discovered that the 
traceback.TracebackException.__init__ method has the same problem: it 
initializes the _str attribute used by the __str__ method quite late and when 
it raised an exception before this point, the incompletely initialized 
TracebackException object caused repr to fail.  There's at least one more class 
in traceback.py that also has this problem, but I don't remember which one it 
is.

The cascade of exceptions causing exceptions causing exceptions makes the 
capture_locals feature difficult to use and debug.

Here is a short snippet that reproduces the bug on Python 3.9.7:

import traceback
class TriggerTracebackBug:
def __init__(self):
raise RuntimeError("can't build a TriggerTracebackBug object for some 
reason")
self._repr = 'if we reached this line, this object would have a repr 
result'
def __repr__(self):
return self._repr
try:
TriggerTracebackBug()
except Exception as e:
# this method call fails because there is a stack frame with a local
# variable (self) such that repr fails on that variable's value:
traceback.TracebackException.from_exception(e, capture_locals=True)

It's clear that it is too much to expect every class to implement a safe 
__repr__ method.  So it also seems clear to me that 
traceback.FrameSummary.__init__ is the place to fix it.

My suggested fix is to replace this line in the latest Lib/traceback.py:

self.locals = {k: repr(v) for k, v in locals.items()} if locals else 
None

with something like this code (written in a somewhat awkward way because that 
helped while I was debugging it):

if locals:
d = {}
self.locals = d
for k, v in locals.items():
try:
d[k] = repr(v)
except Exception:
d[k] = ''
else:
self.locals = None

I've tested this code in an older version of Python and it fixed the problem 
for me.

--
nosy: +jbw
title: StackSummary.format fails if repr(value) fails -> TracebackException or 
StackSummary.extract with capture_locals=True fail to catch exceptions raised 
by repr() on value of frame local variable in FrameSummary.__init__.

___
Python tracker 
<https://bugs.python.org/issue43656>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Simple SSL client hangs

[Douglas Wells]

In article <871r821wlg@hornfels.zedat.fu-berlin.de>,
Loris Bennett  wrote:
>In Perl I have the following
>
>  use IO::Socket::SSL;
>  my $my_socket = new IO::Socket::SSL(PeerAddr => 'some.server.somewhere,
> PeerPort => 12345,
>);
>  my $line = <$my_socket>;
>  print("$line\n");
>  say $my_socket 'ECHO 1';
>  $line = <$my_socket>;
>  print("$line\n");
>
>This runs as expected and I get
>
>  200 Some Server Somewhere - Hello [123.456.789.123]
>  310 Hello Echo
>
>If I try the same with the following Python code:
>
>  import socket
>  import ssl
>  HOST = "some.server.somewhere"
>  PORT = 12345
>  context = ssl.create_default_context()
>  with socket.create_connection((HOST, PORT)) as sock:
>  with context.wrap_socket(sock, server_hostname=HOST) as ssock:
>  data = ssock.recv(1024)
>  print(data.decode())
>  ssock.write(b'ECHO 1')
>  data = ssock.read(1024)
>  print(data.decode())
>
>I get a timeout for the 'ECHO' command:
>
>  200 Some Server Somewhere - Hello [123.456.789.123]
>  501 Timeout
>
>Does anyone have an idea what I might be doing wrong?

Loris,

You don't specify the type of your server, but it looks like a
"normal" SMTP or NNTP or whatever server.  This type of server is line
oriented.

The Perl "say" operation adds a trailing line terminator.  The Python
"ssl:write" does not.  Try adding an appropriate line terminator to
your Python code.  Most likely it needs to be CR-LF.  Perhaps use
"ssock.write(b'ECHO 1\r\n')

 - dmw
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue34960] macOS builds expose stack_size option in LINKEDFOORSHARED and pyconfig

[Simon Wells]

Simon Wells  added the comment:

oh the rabbit hole...

as i have other builds of python3.7 on my system i wanted to ensure it used the 
correct python and python-config (python 3.7 was built and installed into 
$HOME/Projects/python/inst/) as such its a rather convoluted configure command 
for libxml2

LDFLAGS="-L$HOME/Projects/python/inst/lib" 
PATH=/Users/simon/Projects/python/inst/bin/:$PATH ./configure 
--prefix=/Users/simon/Projects/python/inst/ 
--with-python=/Users/simon/Projects/python/inst/bin/python3 
--with-python-install-dir=/Users/simon/Projects/python/inst/lib/python3.7/site-packages

the LDFLAGS envvar was required as python-config --ldflags also does not 
provide -L for the python libary

$make
ld: library not found for -lpython3.7m

in config.log for libxml2 (PYTHON_LIBS which is the output of 
$HOME/Projects/python/python3-config --ldflags)
PYTHON_LIBS='-lpython3.7m -ldl -framework CoreFoundation 
-Wl,-stack_size,100 -framework CoreFoundation'


after LDFLAGS="..." is added

$make
...
  CCLD libxml2mod.la
ld: -stack_size option can only be used when linking a main executable
clang: error: linker command failed with exit code 1 (use -v to see invocation)

if you want more log lines please let me know but those should be the only 
relevant ones

--

___
Python tracker 
<https://bugs.python.org/issue34960>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34960] python-config bad ldflags on macOS

[Simon Wells]

Simon Wells  added the comment:

ah ok, sorry i wasn't clear at first, the issue isn't when building python its 
when building a library which depends on python in this case libxml2, which 
when given the --enable-python stuff uses 
"PYTHON_LIBS=`python$PYTHON_VERSION-config --ldflags`" and therefore is being 
given the -Wl,stack_size linker option which is not valid for non main 
executables according to the error produced from clang

--

___
Python tracker 
<https://bugs.python.org/issue34960>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34960] python-config bad ldflags on macOS

[Simon Wells]

Simon Wells  added the comment:

with a fresh 3.7.0 download

./configure --prefix=... --enable-shared
make -j5
make install

path/to/python3-config --ldflags
-lpython3.7m -ldl -framework CoreFoundation -Wl,-stack_size,100 -framework 
CoreFoundation

--

___
Python tracker 
<https://bugs.python.org/issue34960>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34960] python-config bad ldflags on macOS

[Simon Wells]

New submission from Simon Wells :

if you didn't build python as a framework it adds 
sysconfig.get_config_vars('LINKFORSHARED') when you run 'python-config 
--ldflags' this resolves to

>>> sysconfig.get_config_var('LINKFORSHARED')
'-Wl,-stack_size,100  -framework CoreFoundation 
/usr/local/opt/python/Frameworks/Python.framework/Versions/3.7/Python'

the '-Wl,-stack_size' ldflag causes issues for clang with the error

"ld: -stack_size option can only be used when linking a main executable"

--
components: macOS
messages: 327545
nosy: ned.deily, ronaldoussoren, xzcvczx
priority: normal
severity: normal
status: open
title: python-config bad ldflags on macOS
type: behavior
versions: Python 3.6, Python 3.7

___
Python tracker 
<https://bugs.python.org/issue34960>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24255] Replace debuglevel-related logic with logging

[Eryn Wells]

Eryn Wells  added the comment:

Actually, I spoke too soon. My current employer isn't too keen on us 
contributing to open source, so I can't do this. Sorry!

--

___
Python tracker 
<https://bugs.python.org/issue24255>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24255] Replace debuglevel-related logic with logging

[Eryn Wells]

Eryn Wells  added the comment:

Hi, it sounds like my original patch is the preferred approach. I can put up a 
GitHub PR for that.

--

___
Python tracker 
<https://bugs.python.org/issue24255>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24255] Replace debuglevel-related logic with logging

[Eryn Wells]

Eryn Wells added the comment:

Here's a patch that replaces all the debuglevel stuff with logging. There's a 
single module-level logger that handles it all.

I wasn't sure if it would be okay to break API compatibility, so I kept the 
debuglevel flag and the set_debuglevel() method even though they don't do 
anything.

Most of the information that was being print()ed is still there, but I cleaned 
it up a little and added a few more messages.

The INFO level messages are pretty sparse, with DEBUG providing a lot more raw 
data from the request.

--
keywords: +patch
Added file: http://bugs.python.org/file39651/http-client-logging.patch

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24255
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24255] Replace debuglevel-related logic with logging

[Eryn Wells]

Eryn Wells added the comment:

Hi. This is my first issue, but I'd be willing to have a go at updating this 
module. Do either of you have specific ideas about what changes you want here? 

My thought was to import logging, create a logger object, and start by 
replacing all the self.debuglevel stuff with appropriate log statements. Does 
that make sense? Do each of the classes need separate loggers, or is just one 
module-level logger enough?

--
nosy: +erynofwales

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24255
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Python RPM Package build error

[Wells, David J]

Hello List,

 

I am attempting to build an rpm from Python-3.1.3.tar.bz2 with the
included spec file from /Python-3.1.3/Misc/RPM/ and it fails with the
following error:

Does anyone have any ideas?

 

# rpmbuild -ba python-3.1.spec

 

mv: cannot stat `idle': No such file or directory

+ echo '#!/usr/bin/env python2.6'

+ echo 'import os, sys'

+ echo 'os.execvp(/usr/bin/python2.6, [/usr/bin/python2.6,
/usr/lib/python3.1/idlelib/idle.py] + sys.argv[1:])'

+ echo 'print Failed to exec Idle'

+ echo 'sys.exit(1)'

+ chmod 755 /var/tmp/python2.6-3.1.3-root/usr/bin/idle2.6

+ cp -a Tools /var/tmp/python2.6-3.1.3-root/usr/lib64/python3.1

+ rm -f mainpkg.files

+ find /var/tmp/python2.6-3.1.3-root/usr/lib64/python3.1/lib-dynload -type
f

+ sed 's|^/var/tmp/python2.6-3.1.3-root|/|'

+ grep -v -e '_tkinter.so$'

error: Bad exit status from /var/tmp/rpm-tmp.7647 (%install)

 

/var/tmp/rpm-tmp.7647 include the following:

 

#  check to see if there are any straggling #! lines

find $RPM_BUILD_ROOT -type f | xargs egrep -n '^#!
*/usr/local/bin/python' \

  | grep ':1:#!' /tmp/python-rpm-files.$$ || true

if [ -s /tmp/python-rpm-files.$$ ]

then

   echo '*'

   cat /tmp/python-rpm-files.$$

   cat @EOF

   *

 There are still files referencing /usr/local/bin/python in the

 install directory.  They are listed above.  Please fix the .spec

 file and try again.  If you are an end-user, you probably want

 to report this to jafo-r...@tummy.com as well.

   *

@EOF

   rm -f /tmp/python-rpm-files.$$

   exit 1

fi

rm -f /tmp/python-rpm-files.$$

 



#  CLEAN



 







/usr/lib/rpm/brp-compress 

/usr/lib/rpm/brp-strip 

/usr/lib/rpm/brp-strip-static-archive 

/usr/lib/rpm/brp-strip-comment-note

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

[issue10012] httplib shadows builtin, assumes strings

[Cliff Wells]

New submission from Cliff Wells cl...@develix.com:

httplib.py ~Line 924

def putheader(self, header, *values):
str = '%s: %s' % (header, '\r\n\t'.join(values))
self._output(str)


should be changed to something like:


def putheader(self, header, *values):
...
s = '%s: %s' % (header, '\r\n\t'.join([str(v) for v in values]))
self._output(s)

The current version shadows str builtin with a local variable.  join method 
assumes strings so they should probably be explicitly cast (at least one 3rd 
party library appears to pass Content-length as an integer, causing this to 
fail.  Of course, this can't be done unless the str builtin is no longer 
shadowed.

--
components: Library (Lib)
messages: 117852
nosy: cwells
priority: normal
severity: normal
status: open
title: httplib shadows builtin, assumes strings
versions: Python 2.7

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10012
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

string.Template question

[Wells Oliver]

Can you use dicts with string.Template?

e.g. a structure like:

game = {
'home': {'team': row['home_team_full'], 'score': 
row['home_score'],
'record': '0-0', 'pitcher': {
'id': home_pitcher.attrib['id'], 'name':
home_pitcher.attrib['last_name'], 'wins': home_pitcher.attrib['wins'],
'losses': home_pitcher.attrib['losses']
}, 'win': home_win}
}

Then, in the template, 'game' is passed, but I want to access like
$home.pitcher.id

This doesn't seem to work, though. Is it possible? Or must everything
in the dict passed to string.Template be one-level deep string
variables?
-- 
http://mail.python.org/mailman/listinfo/python-list

Question about typing: ints/floats

[Wells]

This seems sort of odd to me:

 a = 1
 a += 1.202
 a
2.202

Indicates that 'a' was an int that was implicitly casted to a float.
But:

 a = 1
 b = 3
 a / b
0

This does not implicitly do the casting, it treats 'a' and 'b' as
integers, and the result as well. Changing 'b' to 3.0 will yield a
float as a result (0.1)

Is there some way to explain the consistency here? Does python
implicitly change the casting when you add variables of a different
numeric type?

Anyway, just  curiosity more than anything else. Thanks!
-- 
http://mail.python.org/mailman/listinfo/python-list

Instantiate an object based on a variable name

[Wells]

Sorry, this is totally basic, but my Google-fu is failing:

I have a variable foo. I want to instantiate a class based on its
value- how can I do this?
-- 
http://mail.python.org/mailman/listinfo/python-list

[issue7549] 2.6.4 Win32 linked to debug DLLs?

[John Wells]

John Wells johnx...@gmail.com added the comment:

Thanks for the quick follow-up. 

You're right -- given your explanation of what wininst-8_d.exe is, the
interesting question now is why it is running. I get two errors every
day, in the early hours of the morning. Before I delete this file, I
will see if ProcessMonitor will provide an answer.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7549
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7549] 2.6.4 Win32 linked to debug DLLs?

[John Wells]

New submission from John Wells johnx...@gmail.com:

I installed 2.6.4 x86 on Win7 x64. My Python app runs fine, but I get
daily errors in the event app log:

SOURCE: SideBySide
EVENT ID: 33
MESSAGE: Activation context generation failed for
C:\WinUtils\Python26\Lib\distutils\command\wininst-8_d.exe. Dependent
Assembly
Microsoft.VC80.DebugCRT,processorArchitecture=x86,publicKeyToken=1fc8b3b9a1e18e3b,type=win32,version=8.0.50608.0
could not be found. Please use sxstrace.exe for detailed diagnosis. 

I'm not a developer, but Google suggests to me that the reference to
Microsoft.VC80.DebugCRT indicates that some part of Python 2.6.4 was
linked to the debug version of the VC++ 2005 DLLs. Apparently this
shouldn't have been done, since the debug DLLs can't be redistributed.

Or is there some other fix for this?

--
components: Windows
messages: 96655
nosy: jw113
severity: normal
status: open
title: 2.6.4 Win32 linked to debug DLLs?
type: behavior
versions: Python 2.6

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7549
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Odd json encoding erro

[Wells]

I get this exception when decoding a certain JSON string:

'ascii' codec can't encode character u'\u2019' in position 8: ordinal
not in range(128)

The JSON data in question:

http://mlb.com/lookup/json/named.player_info.bam?sport_code=%27mlb%27player_id=%27489002%27

It's in the 'high_school' key. Is there some string function I can run
on the information before I decode it to avoid this?

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

Re: Odd json encoding erro

[Wells]

Sorry- more detail- the actual problem is an exception thrown when
running str() on the value, like so:

 a = u'St. Paul\u2019s School For Boys (MN) HS'
 print str(a)
Traceback (most recent call last):
  File stdin, line 1, in module
UnicodeEncodeError: 'ascii' codec can't encode character u'\u2019' in
position 8: ordinal not in range(128)

Is there some way to run str() against a unicode object?
-- 
http://mail.python.org/mailman/listinfo/python-list

Parsing json where object keys are not quoted?

[Wells]

Is there some way to finagle the json module to parse JSON (well,
almost JSON) where the object keys are not in quotes? I know it's not
100% valid JSON, but I'm just curious.

I don't have control over the data, so I can't make it fit the spec :)
-- 
http://mail.python.org/mailman/listinfo/python-list

Arcane question regarding white space, editors, and code collapsing

[Wells]

I work in TextMate a lot, which I generally love, but it's code
collapsing confounds me. Essentially you have to indent blank lines to
the proper level for the current block. Then it will collapse that
section as one section. If you have simply a new line, it will see it
as a break, and not collapse, though the python interpreter doesn't
care- it only cares about lines of actual code.

Is it... pythonic, then, to have these lines of tabs/spaces to support
code collapsing? Is it proper, improper, or irrelevant?

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

list vs tuple for a dict key- why aren't both hashable?

[Wells]

I'm not quite understanding why a tuple is hashable but a list is not.
Any pointers? Thanks!
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: list vs tuple for a dict key- why aren't both hashable?

[Wells]

On Nov 8, 2:42 pm, Mick Krippendorf mad.m...@gmx.de wrote:
 Wells wrote:
  I'm not quite understanding why a tuple is hashable but a list is not.

 The short answer has already been given. Here is the long answer:

 For objects p and q, p==q implies hash(p)==hash(q). It is essential for
 dicts and sets that objects used as keys/elements uphold this law, and
 also that, for an object o, hash(o) doesn't change during the lifetime
 of o. What if you write a class that doesn't? Let's see:

  class Thing(object):

 ...     def __init__(self, value):
 ...         self.value = value
 ...     def __eq__(self, other):
 ...         return self.value == other.value
 ...     def __hash__(self):
 ...         return hash(self.value)
 ...     def __repr__(self):
 ...         return Thing(%s) % self.value
 ...

  thinglist = [Thing(i) for i in xrange(10)]

  thingdict = dict((y,x) for x,y in enumerate(thinglist))

  print thingdict[thinglist[5]]
 5

  thinglist[5].value = 99

  print thingdict[thinglist[5]]

 Traceback (most recent call last):
   File stdin, line 1, in module
 KeyError: Thing(99)

 What happened? __eq__ and __hash__ both depend on a mutable attribute,
 and when that attribute was changed, their outcome changed as well. If a
 Thing is stored as key in a dict and later it's value attribute is
 changed, it cannot be found anymore. Too bad.

 BTW, this doesn't work either:

  print thingdict[Thing(5)]

 Traceback (most recent call last):
   File stdin, line 1, in module
 KeyError: Thing(5)

 wheras this works:

  print thingdict[Thing(6)]

 6

 What has this got to do with lists and tuples? Well, two tuples x and y
 are considered equal, iff:

  all(a==b for a,b in zip(x,y))

 Also, by the law above, hash(x)==hash(y). Since tuples are immutable, x
 and y (and hash(x) and hash(y)) will be equal as long as they live.

 Lists have the same properties regarding equality, but are mutable.
 If we'd use a list as key in a dict and append an element to the list,
 __eq__ and __hash__ would return something different than before the
 append. The list couldn't be found anymore, just like the instance of
 the broken Thing class above. Lists are not hashable, because it would
 lead to untraceable bugs otherwise, and it would confuse beginners.

 This also teaches a lesson on how to implement __eq__ and __hash__, if
 you must. Just make sure your objects always do uphold the law above,
 and do not change in respect to __hash__ during their lifetime. OTOH it
 is possible to do otherwise, as long as you don't try to use these
 objects as elements of a set or keys in a dictionary. But then, why
 would you bother to implement your own __hash__ method?

 Regards,
 Mick.

Thanks Mick - this was very enlightening!
-- 
http://mail.python.org/mailman/listinfo/python-list

disutils, project structure developing - n00b question

[Wells]

So I have my project partitioned like so:

./setup.py
./pymlb/
./pymlb/fetcher.py
./demos
./demos/demo.py

In demo.py I have:

from pymlb import fetcher

However, it fails b/c pymlb is up a folder. It's also NOT installed as
a module in my module directory because it's a development effort and
I don't want to run setup.py to install them. See what I mean?

What's the work around here?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Komodo(!)

[John Wells]

On Fri, Aug 14, 2009 at 3:28 PM, Kee Netheryk...@kagi.com wrote:
 From the web site it looks like the free version does not include the
 debugging stuff.

 I've been using the paid version with the debugger functionality and I find
 it easy to use and incredibly nice for trying to understand what the code is
 doing. The built-in debugger has saved me tons of time, especially when
 troubleshooting CGIs.

 I'm using a Mac and of the Python IDEs I looked at, Komodo had the easiest
 to use user interface, in my opinion.

I've been using Netbeans with Python support and have enjoyed it. Have
you tried it? It has integrated debugging, etc as well, and the price
(free) is right. I'm curious how it compares to Komodo

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

Ordering of dict keys values

[Wells Oliver]

I understand that the keys in a dictionary are ordered not randomly but
something practically close to it, but if I create a SQL query like so:

query = 'INSERT INTO Batting (%s) VALUES(%s)' % (','.join(stats.keys()),
','.join(stats.values()))

Can I at least rely on the value being in the same index as its
corresponding key?

-- 
Wells Oliver
we...@submute.net
-- 
http://mail.python.org/mailman/listinfo/python-list

RPY2 examples?

[Wells Oliver]

I am trying to find examples using RPY2 to render R graphs to PNG/PDF/etc.
The only things I can find use rpy 1.x. Any references? Thanks!

-- 
Wells Oliver
we...@submute.net
-- 
http://mail.python.org/mailman/listinfo/python-list

Question regarding style/design..

[Wells Oliver]

Sometimes I see relatively small application, generally task scripts,
written as essentially a list of statements. Other times, I see them neatly
divided into functions and then the if __name__ == '__main__': convention.
Is there a preference? Is there an... application scope such that the
preference shifts from the former to the latter? I understand the use of the
__name__ == 'main' convention for building unit tests, but I'm mixed on
using it in scripts/small applications.
Thanks for any thoughts!

-- 
Wells Oliver
we...@submute.net
-- 
http://mail.python.org/mailman/listinfo/python-list

MySQLdb and ordering of column names in list returned by keys() w/ a DictCursor

[Wells Oliver]

Is there some kind of mysterious logic to how the the columns are ordered
when executing the following:

sql = SELECT player_id, SUM(K) AS K, SUM(IP) AS IP, SUM(ER) AS ER, SUM(HR)
AS HR, SUM(H) AS H, SUM(BB) AS BB, Teams.league FROM Pitching INNER JOIN
Teams ON Pitching.team = Teams.team_id WHERE Date BETWEEN '%s' AND '%s'
GROUP BY player_id % (start, date)
cursor.execute(sql)

for row in cursor.fetchall():
print row.keys()

What I get is:

['league', 'BB', 'HR', 'IP', 'K', 'H', 'player_id', 'ER']

Neither alphabetical nor the order in which they were specified in the query
nor... any seeming order I can suss out. Any ideas? Thanks!

(cursor being a MySQLdb.cursors.DictCursor object.)

-- 
Wells Oliver
we...@submute.net
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: MySQLdb and ordering of column names in list returned by keys() w/ a DictCursor

[Wells Oliver]

Will this order at least be the same for that same query every time the
script is executed?

On Thu, Jul 2, 2009 at 10:48 AM, Tim Chase python.l...@tim.thechases.comwrote:

 sql = SELECT player_id, SUM(K) AS K, SUM(IP) AS IP, SUM(ER) AS ER, SUM(HR)
 AS HR, SUM(H) AS H, SUM(BB) AS BB, Teams.league FROM Pitching INNER JOIN
 Teams ON Pitching.team = Teams.team_id WHERE Date BETWEEN '%s' AND '%s'
 GROUP BY player_id % (start, date)
 cursor.execute(sql)

 for row in cursor.fetchall():
print row.keys()

 What I get is:

 ['league', 'BB', 'HR', 'IP', 'K', 'H', 'player_id', 'ER']

 Neither alphabetical nor the order in which they were specified in the
 query
 nor... any seeming order I can suss out. Any ideas? Thanks!

 (cursor being a MySQLdb.cursors.DictCursor object.)


 My guess is you're experiencing the fact that dicts are unordered by nature
 which allows it to return in any order it likes (usually per the internal
 representation/storage).

 -tkc






-- 
Wells Oliver
we...@submute.net
-- 
http://mail.python.org/mailman/listinfo/python-list

n00b confusion re: local variable referenced before assignment error

[Wells Oliver]

Writing a class which essentially spiders a site and saves the files
locally. On a URLError exception, it sleeps for a second and tries again (on
404 it just moves on). The relevant bit of code, including the offending
method:

class Handler(threading.Thread):
def __init__(self, url):
threading.Thread.__init__(self)
self.url = url

def save(self, uri, location):
try:
handler = urllib2.urlopen(uri)
except urllib2.HTTPError, e:
if e.code == 404:
return
else:
print retrying %s (HTTPError) % uri
time.sleep(1)
self.save(uri, location)
except urllib2.URLError, e:
print retrying %s % uri
time.sleep(1)
self.save(uri, location)

if not os.path.exists(os.path.dirname(location)):
os.makedirs(os.path.dirname(location))

file = open(location, w)
file.write(handler.read())
file.close()

...

But what I am seeing is that after a retry (on catching a URLError
exception), I see bunches of UnboundLocalError: local variable 'handler'
referenced before assignment errors on line 38, which is the
file.write(handler.read()) line..

What gives?

-- 
Wells Oliver
we...@submute.net
-- 
http://mail.python.org/mailman/listinfo/python-list

A question on scope...

[Wells Oliver]

In writing out python classes, it seems the 'self' is optional, meaning that
inside a class method, self.foo = bar has the same effect as foo = bar.
Is this right? If so, it seems a little odd- what's the rationale?

Or am I mistaken?

-- 
Wells Oliver
we...@submute.net
-- 
http://mail.python.org/mailman/listinfo/python-list

Assigning a list to a key of a dict

[Wells]

Why can't I do this?

teams = { SEA: Seattle Mariners }
for team, name in teams.items():
teams[team][roster] = [player1, player2]

I get an error:

Traceback (most recent call last):
  File ./gamelogs.py, line 53, in module
teams[team][roster] = [player1, player2]
TypeError: 'str' object does not support item assignment

You can see that I am trying to make a key called roster for each
team item in the dictionary, which is a list of players.
-- 
http://mail.python.org/mailman/listinfo/python-list

n00b question: Possible to pass lists to a Template class?

[Wells]

Is it possible to pass a list to the Template.substitute method and
use that in the template, like so..

g = string.Template(gametemplate)
print g.substitute(recap = none, winner = game[winner], loser =
game[loser])

Then in the template...

bwinner.team

Where winner.team would be the value of game[winner][team].

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

Re: n00b question: Possible to pass lists to a Template class?

[Wells]

On May 13, 11:14 am, Wells we...@submute.net wrote:
 Is it possible to pass a list to the Template.substitute method and
 use that in the template, like so..

 g = string.Template(gametemplate)
 print g.substitute(recap = none, winner = game[winner], loser =
 game[loser])

 Then in the template...

 bwinner.team

 Where winner.team would be the value of game[winner][team].

 Thanks!

Sorry, I meant dicts, not lists. Like I said, n00b question.
-- 
http://mail.python.org/mailman/listinfo/python-list

Assigning multiple variables to a list a la php's list()

[Wells]

Can you take a list and have it exploded into variables w/ one
command? Something like..


list = ['foo', 'bar']
[a, b] = list

Then 'a' would be foo and 'b' 'bar'.

Like list($a,$b) = $list in PHP.

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

ONLINE EARNINGS $$$ 500 - $$$ 1000 PER MONTH WITHOUT INVESTMENT...

[alan wells]

ONLINE EARNINGS $$$ 500 - $$$ 1000 PER MONTH WITHOUT INVESTMENT...

projectpayday has been proven to a legit source of income that can be
earned the same day you sign up.the best programme i found in online
that it pays
more than $100 perday to me. they provides you step by step guide
untill than you made your first payment.You won't get rich but
1,000s of people have proven it's
a realistic extra income system for the Average Joe.. just have a
look at this network.when i just join here i start earn within 15
minutes

http://tinyurl.com/45twel

The best opportunity to earn money. It is a free money making network.
Mkke use it
--
http://mail.python.org/mailman/listinfo/python-list

Re: Kill an OS process from script (perhaps unix specific)

[Douglas Wells]

In article [EMAIL PROTECTED],
  [EMAIL PROTECTED] writes:
 Hi,
 I'm trying to run a process from a python script. I need the exit
 status of that process but do not care about its output, so until now
 was using os.system(). But it turned out that the process often went
 into an infinite loop, so I wrote a SIGALRM handler. Unfortunately the
 code I came up with is quite kludgy:
 
 import subprocess
 ...
 try:
   p = subprocess.Popen(..., shell = True)
   pid = p.pid
   os.waitpid(pid...)
   ...
 except ...: # Thrown by alarm signal handler
   os.kill(pid + 1)  # Real pid = shell pid + 1
   ...
 
 The os.kill is very hacky and unsafe so I was looking for better
 ideas. Any help will be greatly appreciated. Thanks!

Assuming that the problem is really an infinite loop (and not just
an arbitrary delay), you could use the simple construct:

 import os
 code = os.system (ulimit -t secs ; ...)

That's not guaranteed to work on all POSIX systems, but it should
work with at least ash, bash, and ksh.  And it would would be
limit cputime secs ; ... if you somehow got hooked up with a
C shell.

 - dmw

-- 
.   Douglas Wells .  Connection Technologies  .
.   Internet:  -sp9804- -at - contek.com- .
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Default parameter for a method

[Cliff Wells]

On Wed, 2008-04-16 at 13:47 -0500, Larry Bates wrote:
 [EMAIL PROTECTED] wrote:
  I wanted to know if there's any way to create a method that takes a
  default parameter, and that parameter's default value is the return
  value of another method of the same class. For example:
  
  class A:
  def __init__(self):
  self.x = 1
  
  def meth1(self):
  return self.x
  
  def meth2(self, arg=meth1()):
  # The default `arg' should would take the return value of
  meth1()
  print 'arg is', arg
  
  This obviously doesn't work. I know I could do
  
  ...
  def meth2(self, arg=None):
  if arg is None:
  arg = self.meth1()
  
  but I'm looking for a more straightforward way.
 
 You can write this as:
 
  def meth2(self, arg=None):
  arg = arg or self.meth1()
 
 IMHO - You can't get much more straightforward than that.

What if arg is 0 an empty list or anything else that's False?

def meth2(self, arg=None):
arg = (arg is not None) or self.meth1()

is what you want.


Regards,
Cliff


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

Re: subprocess.Popen pipeline bug?

[Douglas Wells]

In article [EMAIL PROTECTED],
  Marko Rauhamaa [EMAIL PROTECTED] writes:
 
 This tiny program hangs:
 
 
 #!/usr/bin/env python
 import subprocess
 a = subprocess.Popen('cat',shell = True,stdin = subprocess.PIPE,
  stdout = subprocess.PIPE)
 b = subprocess.Popen('cat /dev/null',shell = True,stdin = a.stdout)
 a.stdin.close()
 b.wait() # hangs
 a.wait() # never reached
 
 
 It shouldn't, should it?

Yes, it should.

This issue is related to the subtleties of creating a pipeline in
POSIX environments.  The problem is that the cat command in
subprocess a never completes because it never encounters an EOF
(on a.stdin).  Even though you issue a close call (a.stdin.close ()),
you're not issuing the last close.  That's because there is still
at least one file descriptor open in subprocess tree b.  That
happened because it was open when the subprocess module executed
a POSIX fork call and it got duplicated as part of the fork call.

I don't see any clean and simple way to actually fix this.  (That's
one of the reasons why POSIX shells are so complicated.)  There
are a couple of work-arounds that you can use:

1) Force close-on-exec on the specific file descriptor:

import subprocess
a = subprocess.Popen('cat',shell = True,stdin = subprocess.PIPE,
 stdout = subprocess.PIPE)
# * beginning of changes
import os, fcntl
fd = a.stdin.fileno ()
old = fcntl.fcntl (fd, fcntl.F_GETFD)
fcntl.fcntl (fd, fcntl.F_SETFD, old | fcntl.FD_CLOEXEC)
# * end of changes
b = subprocess.Popen('cat /dev/null',shell = True,stdin = a.stdout)
a.stdin.close()
b.wait()
a.wait()

Or if it happens to not cause undesired side-effects for you, you can
2) Force close-on-exec *all* non-standard file descriptors by using
the close_fds argument to Popen:

import subprocess
a = subprocess.Popen('cat',shell = True,stdin = subprocess.PIPE,
 stdout = subprocess.PIPE)
# * beginning of changes
# b = subprocess.Popen('cat /dev/null',shell = True,stdin = a.stdout)
b = subprocess.Popen('cat /dev/null',shell = True,stdin = a.stdout,
 close_fds = True)
# * end of changes
a.stdin.close()
b.wait()
a.wait()

Good luck.

 - dmw

-- 
.   Douglas Wells .  Connection Technologies  .
.   Internet:  -sp9804- -at - contek.com- .
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Threading the Python interpreter

[Douglas Wells]

In article [EMAIL PROTECTED],
  Nick Stinemates [EMAIL PROTECTED] writes:
 MooJoo wrote:
  Since I'm running each python instance in a new process, I don't believe 
  that there is a problem and, in my testing so far, I haven't encountered 
  anything that would lead me to believe there is a potential time bomb 
  here. Am I correct in my assumption this is OK or just lucky so far?

 FYI -- That's not multi threading that's multiprocessing. You're safe.

Actually that's multiprogramming (or less commonly multitasking).
It's a common confusion, but in the literature, multiprocessing
means the use of multiple processors (often via multiple cores
in todays desktop systems).

Unfortunately for the cause of language regularity, the terms
developed separately in somewhat different communities.  The term
multiprocessing evolved in the early 1960s associated with a
hardware manufacturer of multiprocessor systems.  The term process
evolved in the mid 1960s associated with the academic community.
And the term multiprogramming evolved in the late 1960s.  All three
terms were eventually accepted by the larger computing community
with little change in their original meanings.

But, the OP should still be safe.

 - dmw

-- 
.   Douglas Wells .  Connection Technologies  .
.   Internet:  -sp9804- -at - contek.com- .
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: sockets -- basic udp client

[Douglas Wells]

In article [EMAIL PROTECTED],
  [EMAIL PROTECTED] [EMAIL PROTECTED] writes:

I have had some difficulty following the assertions, corrections,
and misquoting in this article thread, so apologies in advance if
I have missed a correction or misunderstood an assertion.

[ quoting partially corrected: ]
 
 Here is the example above converted to a more straightforward udp
 client that isolates the part I am asking about:
 
 import socket, sys
 
 host =  'localhost'  #sys.argv[1]
 port = 3300
 s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
 
 data = 'hello world'
 num_sent = 0
 while num_sent  len(data):
 num_sent += s.sendto(data, (host, port))
 
 print Looking for replies; press Ctrl-C or Ctrl-Break to stop.
 while 1:
 buf = s.recv(2048)
 
 #Will the following if statement do anything?
 if not len(buf):
 break
 
 print Received from server: %s % buf
 --

 But, for the specific case that you have asked about, since the
 default for timeout is no timeout, or block forever, your question:
 
 #Will the following if statement do anything?
 if not len(buf):
 break
 
 The answer is that you are right, it will do nothing.  But, if you set
 a time out on the socket, and you receive no data and the timeout
 expires, checking for the length of zero and a break is one way to
 jump out of the loop if you need to.

That is not correct in my experience.  The test not len(buf) --
or perhaps more clearly len(buf) == 0 is a valid way, perhaps
the preferred way, of detecting a zero length datagram as transmitted
via UDP (socket.SOCK_DGRAM).

Zero length datagrams are perfectly valid in UDP and in fact are
the recommended way of initiating certain protocol actions.  See,
for example, the Time Protocol (RFC 868, top of page 2).

While POSIX regular files and TCP streams use a zero read result
to indicate end-of-file, the action is different for message-based
sockets (and STREAMS).  In the case of UDP, there is no concept
of end-of-file, and thus no API mechanism for indicating such.
Instead, the zero return is used to indicate a zero-length message.

Timeouts are indicated by raising an exception:

- In the case of the settimeout method of socket, a socket.timeout
  exception is raised.
- In the case of use of socket option socket.SO_SNDTIMEO, a
  socket.error exception is raised w/ errno = EAGAIN.

 For example:
 
 import socket, sys
 
 host =  'localhost'  #sys.argv[1]
 port = 3300
 s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
 
 s.settimeout(1.0)
 buf = ''
 
 data = 'hello world'
 num_sent = 0
 
 while num_sent  len(data):
 num_sent += s.sendto(data, (host, port))
 
 print Looking for replies; press Ctrl-C or Ctrl-Break to stop.
 while True:
 
 try:
 buf, addr = s.recvfrom(2048)
 except:
 pass
 
 #Will the following if statement do anything?
 # In this case it will cause the script to jump out of the loop
 # if it receives no data for a second.
 if not len(buf):
 break
 
 print Received from server: %s % buf

The reason that this example *seems* to work is that you mask the
exception.  What is actually happening is that the timeout of the
recvfrom call raises socket.timeout, which is ignored.  Then because
buf has been explicitly set to zero length (near the beginning of
the program), and because it is *not* modified as a result of the
recvfrom call, the length is still zero, and the break is executed.
Try commenting out the try/except construct, or try actually
providing at least one non-zero length response (such that buf is
modified) and seeing if it ever terminates.

I would also like to point out that the original example (quoted
from the book) used connect' and recv w/ UDP).  One of the
purposes of using this construct (rather than using recvfrom)
is to simplify identification of the remote system:  When you
connect to a UDP socket, the OS will only send messages to that
system and will ignore messages that do not originate from that
IP address (ignoring the issue IP address spoofing).

 - dmw

-- 
.   Douglas Wells .  Connection Technologies  .
.   Internet:  -sp9804- -at - contek.com- .
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Can anyone help, please?

[Douglas Wells]

In article [EMAIL PROTECTED],
  maehhheeyy [EMAIL PROTECTED] writes:
 Hi, right now I'm using Python and Multicast. I have the code for
 Multicast receiver on Python but I keep getting this error;

Hi,

In the future please use a Subject: line that is relevant to your
inquiry.  Many people only read articles with interesting
subjects.  This is particularly true in groups like this one with
200+ messages a day.

 File string, line 1, in bind
 error: (10049, Can't assign requested address)
 
 The error is coming from this line;
 sock.bind ((MCAST_ADDR, MCAST_PORT))

You didn't provide either the OS that you're running on, nor your
network interface configuration, both of which are relevant to use
of IP-multicast.  (Many/most languages, including Python, do not
have a separate networking model:  they simply provide access to
the one provided by the target platform.

 This is the code that I am using:
 
 [ ... ]
 
 ANY = 0.0.0.0
 [ ... ]
 
 status = sock.setsockopt(socket.IPPROTO_IP,
  socket.IP_ADD_MEMBERSHIP,
  socket.inet_aton(MCAST_ADDR) +
 socket.inet_aton(ANY));

If I had to guess based on facts available, I would guess that
your operating system requires you to select the appropriate
interface.  Try replacing the second argument (the ANY one) with
the address of the networking interface over which you wish to
communicate.  Note that the interface *must* be multicast-capable
(on many platforms), and localhost usually is not.  So, you want
an/the address on your Ethernet interface, for example.

I include below an example program that works on my system (FreeBSD)
and has been somewhat altered to be similar to your failing test case.

 - dmw

=
#! /usr/bin/env python

# Receiver:

##

import socket
import struct
import time

MULTICAST_ADDR = '225.0.0.1'
PORT = 1200
REPORT_LENGTH = 1024000
BUFFSIZE = 1024

ANY_IPADDR = struct.pack (!L, socket.INADDR_ANY)
INTERFACE_ADDR = socket.gethostbyname (socket.gethostname ())

ip = socket.inet_aton (MULTICAST_ADDR) + socket.inet_aton (INTERFACE_ADDR)

sock = socket.socket (socket.AF_INET, socket.SOCK_DGRAM, socket.IPPROTO_UDP)
sock.setsockopt (socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
sock.setsockopt (socket.SOL_SOCKET, socket.SO_REUSEPORT, 1)

sock.setsockopt (socket.IPPROTO_IP, socket.IP_ADD_MEMBERSHIP, ip)

sock.bind ((socket.inet_ntoa (ANY_IPADDR), PORT))

start = time.time ()
total_data_length = 0
print 'Listening ...'

while 1:
try:
data, addr = sock.recvfrom (BUFFSIZE)
total_data_length += len (data)
if (total_data_length % REPORT_LENGTH) == 0:
elapsed = time.time () - start
print %7.3f: %d octets from %s % (elapsed, 
total_data_length, addr)
except socket.error, e:
print Socket error + e
break

##

=

-- 
.   Douglas Wells .  Connection Technologies  .
.   Internet:  -sp9804- -at - contek.com- .
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Is anyone happy with csv module?

[Cliff Wells]

On Wed, 2007-12-12 at 07:04 -0800, massimo s. wrote:

 If by thoroughly you mean it actually describes technically what it
 is and does but not how to really do things, yes, it is thoroughly
 documented.
 The examples section is a joke. 

Actually I rarely use the csv module these days, but I find a quick
glance at the examples to be sufficient in most cases.

 It gives good examples for the
 simplest usage cases (good), then it almost immediately digs into
 details like the Unicode stuff, leaving aside the rest. DictWriter and
 DictReader are absent from the examples. And also the Sniffer.

I take full responsibility for the lack of documentation on the Sniffer.
If you are interested in using it, I'd be happy to help you out and
maybe we could get some docs submitted.  It's actually remarkably simple
to use, but I admit looking at the source won't make you think so ;-)

Regards,
Cliff

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

Re: Is anyone happy with csv module?

[Cliff Wells]

On Wed, 2007-12-12 at 09:50 +1100, Ben Finney wrote:
 massimo s. [EMAIL PROTECTED] writes:

  Yes, but it's natural for a spreadsheet-like thing to have organized
  columns of data, often.
 
 Perhaps, but that's not relevant. CSV is a serialisation format for
 tabular data, and is only a spreadsheet-like thing in its heritage.
 The CSV data stream is not spreadsheet-like at all.

To add some weight to this point, if CSV *weren't* considered a
serialization format (or protocol) this module most likely would have
never been accepted into the standard library in the first place.  There
was some debate when the PEP was submitted over whether CSV was to be
considered a file format (like an .XLS file) or a serialization protocol
(like XML or HTTP).
Fortunately the latter was agreed up and so the module was deemed
appropriate for inclusion in the standard libraries.

Whether or not anyone agrees with this point of view is now mostly
irrelevant, since *by definition* the Python csv module intends to
implement a protocol.  Other implementations remain free to vary in
their definition of CSV.

Regards,
Cliff

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

Re: Some pythonic suggestions for Python

[Cliff Wells]

On Thu, 2007-11-08 at 15:00 -0500, Frank Samuelson wrote:
 I love Python, and it is one of my 2 favorite
 languages.  I would suggest that Python steal some
 aspects of the S language.

In general, I agree that Python has some antiquated concepts at its core
(statements being a major one) and that some of these things make the
language inconsistent and introduce additional syntax.
  
However, despite the apparent close-mindedness of some of the
respondents (it doesn't look like current Python syntax, hence it's
ugly), I also agree with them to a degree: changing Python at this
level would mean it would no longer be Python, it would be some other
language.  What you are basically asking is that GvR abandon Python
(like ABC before it) and start on a next generation language.  That's
quite a request.  I'm not saying it's a bad request, simply that you
should recognize the scale of request you are making.

On a more practical level, you might take a look at Boo.  It's
intentionally Python-like in appearance, yet lifts several key
limitations (and is probably far more open to suggestions at this early
stage in its life).  Unfortunately it's nowhere near Python in
completeness (notably documentation, size of community and overall
maturity) and, for better or worse, it runs on .NET/Mono.  

Regards,
Cliff



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

Re: Socket - gaierror

[Douglas Wells]

In article [EMAIL PROTECTED],
 [EMAIL PROTECTED] writes:
 On Aug 27, 12:32 pm, Larry Bates [EMAIL PROTECTED] wrote:
 
 Changing it to IP gives me the same exact error...
 
   File bin/prgram.py, line 123, in notify
 smtp = smtplib.SMTP(XXX.XXX.XXX.XXX)
 
   File /usr/lib/python2.4/smtplib.py, line 255, in __init__
 addr = socket.gethostbyname(socket.gethostname())
 
 gaierror: (-2, 'Name or service not known')
 
 Looks like the smtp port is closed on the client machine...doh Should
 have gotten to that!
 
 ~Sean

Note that the lookup is of your *local* system name
(socket.gethostname()).  I suspect that the name of your client
system (the one running the python script) is not registered in
DNS.

Try ping'ing your own system and see if that resolves in DNS.  In
UNIX/Linux you can use the hostname command; in any system you can
write a python script to print the result of socket.gethostname().

 - dmw


-- 
.   Douglas Wells .  Connection Technologies  .
.   Internet:  -sp9804- -at - contek.com- .
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Socket - gaierror

[Douglas Wells]

In article [EMAIL PROTECTED],
 [EMAIL PROTECTED] writes:
 On Aug 27, 4:22 pm, [EMAIL PROTECTED] (Douglas Wells) wrote:
  In article [EMAIL PROTECTED],
 
   [EMAIL PROTECTED] writes:
   On Aug 27, 12:32 pm, Larry Bates [EMAIL PROTECTED] wrote:
 
   Changing it to IP gives me the same exact error...
 
 File bin/prgram.py, line 123, in notify
   smtp = smtplib.SMTP(XXX.XXX.XXX.XXX)
 
 File /usr/lib/python2.4/smtplib.py, line 255, in __init__
   addr = socket.gethostbyname(socket.gethostname())
 
   gaierror: (-2, 'Name or service not known')
 
   ~Sean
 
  Note that the lookup is of your *local* system name
  (socket.gethostname()).  I suspect that the name of your client
  system (the one running the python script) is not registered in
  DNS.
 
  Try ping'ing your own system and see if that resolves in DNS.  In
  UNIX/Linux you can use the hostname command; in any system you can
  write a python script to print the result of socket.gethostname().
 
   - dmw
 
 I found a solution...but still not sure why that happened.
 
 [EMAIL PROTECTED]:17:08:5E:EF:0F:/usr/local/sw/program/bin# hostname
 00:17:08:5E:EF:0F
 [EMAIL PROTECTED]:17:08:5E:EF:0F:/usr/local/sw/program/bin# ping 
 00:17:08:5E:EF:0F
 ping: unknown host 00:17:08:5E:EF:0F
 
  socket.gethostname()
 '00:17:08:5E:EF:0F'
 
 Workaround: pass the 'local_hostname' arg to the smtplib.SMTP() call
 with localhost
 
 ie smtp.SMTP(some.computer, local_hostname=localhost)
 
 This is just overriding the socket.gethostname() call entirely.
 
 Did a bit of testing with the /etc/hosts file, and even with an entry
 to the hostname it can't resolve the ip.
 The problem is the name 00:17:08:5E:EF:0F  PS.  I didn't choose to
 set the hostname that way.
 
 ~Sean

That would be a reasonable workaround.  The process of sending
e-mail via SMTP could need the local host name for at least two
uses:  1) the SMTP initial connection (RFC 2821) requires the
client to identify itself (provide its host name); 2) the mail
headers (RFC 2822) should include a return address, which probably
defaults to using your user name at your client host name.

The hostname of your system (00:17:08:5E:EF:0F) is silly when used
with SMTP.  Your system administrator is either ill-informed or is
actively trying to prevent users from using their systems as
servers. It has the form of an IPv6 numeric host address.

Given the pathnames in your command interchange, you have a UNIX,
Linux, or UNIX-like system. According to the Linux and UNIX standards:

  - If your system is IPv6-capable, the use of such a name with
gethostbyname invokes unspecified behavior.   First, the function
is not defined to work with such numeric identifiers.  Second,
it is not guaranteed to work with non-IPv4 names, and probably
can't be registered in pre-i18n DNS data bases.

  - Even if your system is not IPv6-capable, such a host name is going
to confuse many other systems that would be IPv6-capable and attempt
to resolve the odd-ball name that your system provides.

  - Even if that worked, you're providing an IPv6 name form in
conjunction with an IPv4 protocol (at least when you explicitly
provide the IP address as a dotted-quad).

 - dmw

-- 
.   Douglas Wells .  Connection Technologies  .
.   Internet:  -sp9804- -at - contek.com- .
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Comparing RFC1123 based Dates

[Douglas Wells]

In article [EMAIL PROTECTED],
  Phoe6 [EMAIL PROTECTED] writes:
 Phoe6 wrote:
  I would like to parse RFC 1123 date format and compare two dates. I
  find that
  datetime module does not specifically confirms to any RFC. Any
  suggestions as how I can handle the RFC 1123 date format using
  standard libraries before I go to re based parsing?
 
 Well,
  import time
  timeobj = time.strptime(Thu, 01 Dec 1994 16:00:00 GMT,%a, %d %b %Y 
  %H:%M:%S %Z)
 
 was easy.

Well, it might have been easy, but it's got several gotchas (in
both Python and C), including:

  - The zone field (%Z) only corresponds for the GMT and UT timezones,
which are obsolete (see RFC 2822).  There is no support for
the recommended +/-time-offset form.

  - The day-of-week (%a) and month (%b) fields in strptime and
strftime are subject to the process's locale, whereas the RFC
time forms are not.  Those are hardwired to names that happen
to correspond to the C, POSIX, and probably most of the en_*
locales, but not to others that would be used by billions of
people.  Thus anyone using your program who doesn't happen to
reside in one of the English-speaking countries (or does and
is using a native locale) is likely to encounter problems when
using your program.

  - The day-of-week field is optional.

  - Comments are allowed (but deprecated) in the whitespace fields
of the time format.  (On the other hand, I've never seen this
is normal e-mail.)

I find the use of strptime and strftime difficult enough to manage
with Internet date/times that I restrict my use of them to programs
that are limited to processing date/times.  Even then, I then
explicitly set the locale (LC_TIME) to the C locale.  Otherwise,
I use ad hoc code that explicitly recognizes the RFC-defined forms.

-- 
.   Douglas Wells .  Connection Technologies  .
.   Internet:  -sp9804- -at - contek.com- .
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: asyncore and OOB data

[Douglas Wells]

In article [EMAIL PROTECTED],
Steve Holden [EMAIL PROTECTED] writes:
 Douglas Wells wrote:
  
  Third, the TCP protocol, which you have selected via the SOCK_STREAM
  option doesn't support OOB at all, so there's no way that you can
  even send OOB data in the manner that you are expecting.
  
 Wrong. The URGENT pointer indicates that the data begins with 
 out-of-band data. You are correct, however, in stating that the FTP 
 protocol doesn't support or implement out-of-band data transmissions.

Well, first I have to admit that I just looked at the wiki article
on out-of-band (http://en.wikipedia.org/wiki/Out-of-band) and
it also makes a statement that TCP urgent data is OOB.  But I
disagree with that interpretation.  So, let me acknowledge that
there are dissenting opinions, and explain my assertion in terms
of the OP's problem of wanting a separate data stream (or at least
that was my interpretation).

First, I fully acknowledge that the concept of TCP's URGENT pointer
itself is out-of-band, but I don't know of any way to associate
data, in the form of an identifiable set of octets, with that
concept.  As supporting evidence I offer the following:

  - There is no way for the sender and the receiver to agree on
the *start* of an urgent data set.  The end point is clearly
identified by the urgent pointer, but the start is time dependent
and is not identified in the TCP communication stream. Thus, the
sender could not express the concept of sending a particular
data value, e.g. This string, to the receiver reliably.

  - If receivers are highly responsive (meaning that the receiver
is always able to process incoming data without having to
discard any of it), there will be no difference in the behavior
of two receivers, one of which properly implements the concept
of the urgent pointer, and the other of which totally ignores
the concept of urgency.

  - There appears to be no way to actually read any OOB data from
a Berkeley socket API. (As I noted my system, at least, returns
an error in this case.)

  Let's switch to the positive, however.  What TCP does have is the
  concept of urgent data.  Urgent data is data that the sender
  believes is so important that the receiver should discard intermediate
  data, if necessary, in order to process the urgent data -- but the
  urgent data is sent *in-band*.
  
 No, technically the urgent data is out-of-band, isn't it? There is no 
 requirement to ditch the other data in the packet, so urgent data can be 
 interspersed without loss of regular in-band data if required.

This is the same point that I argued above.  I now acknowledge that
some people think of the TCP urgent concept as OOB.  I don't; but
this is a matter of definition and almost certainly not an issue
for coherent argument.

  In the case of FTP, the concept of urgent data is used to allow
  the user side to interrupt the data transfer, which it does by
  sending an ABOR command.  The underlying problem is that the server
  might be blocked on a receive on the data connection and not
  listening for commands on the control connection.  So the user
  side is required to perform some special action that includes
  sending urgent data, which the server can then process specially.
  This problem arises primarily in systems without either threading
  or asynchronous I/O APIs.  Your use of asyncore should alleviate
  this problem.

  The thing that may be confusing you is that for whatever reason
  the designers of the Berkeley socket API (which is what you are
  using when running under POSIX/Linux/MS Windows), chose to use the
  OOB flags (e.g., MSG_OOB) to indicate the *transmission* of OOB
  data -- but it's not really OOB data.  In fact, when I attempt to
  receive using the MSG_OOB flag using the OS interfaces on my system,
  I get back an error (EINVAL - Invalid argument).  I would expect
  that asyncore would report this error somehow or other.
  
 You can, of course, expect what you like, but experience is the best 
 guide to what will actually happen.

Agreed, but having acknowledged that I had never used asyncore,
I was trying to express the hope that the designers would not
purposely discard a error condition without notifying the user,
particularly for a reliable transfer method such as TCP.

   Steve

 - dmw

-- 
.   Douglas Wells .  Connection Technologies  .
.   Internet:  -sp9804- -at - contek.com- .
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: asyncore and OOB data

[Douglas Wells]

In article [EMAIL PROTECTED],
 billiejoex [EMAIL PROTECTED] writes:
 Douglas Wells wrote:
 
  Second, when I look at the FTP specification, I don't find the
  concept of OOB anywhere.  So, it's not clear what OOB data would
  mean in terms of the defined FTP commands in any case.
 
 Steve Holde wrote:
 
  You are correct, however, in stating that the FTP
  protocol doesn't support or implement out-of-band
  data transmissions.
 
 Wait a sec. RFC959 [1], on chapter 4.1.3 says:
 
 [ ... ]
 
 I believe that the TCP urgent flag, activated by using
 socket.MSG_OOB, should be set when client must send the Sync signal
 (RFC854 [2] talks about it). I think that you do not find references
 of OOB in RFC959 (FTP) just because it is specified into RFC854
 (Telnet).

The point that I was trying to make, which Steve made more clearly
that I did in the referenced paragraph, is that FTP doesn't support
OOB data transmission, not that RFP doesn't require the use of OOB
information (in the form of the Telnet Synch signal).

Note that FTP limits the commands that may be issues while a data
transfer in progress.  The RFC isn't totally explicit, but the
general notion is that issuing a data transfer command (such as
STOR or RETR) is not allowed while another data transfer is in
progress.

 - dmw

-- 
.   Douglas Wells .  Connection Technologies  .
.   Internet:  -sp9804- -at - contek.com- .
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: asyncore and OOB data

[Douglas Wells]

In article [EMAIL PROTECTED],
 billiejoex [EMAIL PROTECTED] writes:
 In an asyncore based FTP server I wrote I should be able to receive
 OOB data from clients.
 A client sending such kind of data should act like this:
 
  import socket
  s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
  s.connect(('127.0.0.1', 21))
  s.sendall('hello there\r\n', socket.MSG_OOB)
 
 According to asyncore documentation I should handle this kind of event
 in handle_expt method of dispatcher class, that should be called
 when OOB is received by the underlying socket. I've tried to override
 handle_expt method in such way:
 
 def handle_expt(self):
 print OOB data arrived
 data = self.socket.recv(1024, socket.MSG_OOB)
 print data
 
 ...but, even if it is called, data contains only a \n character
 instead of the entire string (hello there\r\n).
 Why does this happen? Should I have to use a different approach?

You should use a different approach, but first you need to read
the relevant documentation.

I've never used asyncore, but when I look at the documentation,
the only reference that I find to OOB says:
Called when there is out of band (OOB) data for a socket
connection.  This will almost never happen, as OOB is
tenuously supported and rarely used.
That should be fair warning.

Second, when I look at the FTP specification, I don't find the
concept of OOB anywhere.  So, it's not clear what OOB data would
mean in terms of the defined FTP commands in any case.

Third, the TCP protocol, which you have selected via the SOCK_STREAM
option doesn't support OOB at all, so there's no way that you can
even send OOB data in the manner that you are expecting.

Let's switch to the positive, however.  What TCP does have is the
concept of urgent data.  Urgent data is data that the sender
believes is so important that the receiver should discard intermediate
data, if necessary, in order to process the urgent data -- but the
urgent data is sent *in-band*.

In the case of FTP, the concept of urgent data is used to allow
the user side to interrupt the data transfer, which it does by
sending an ABOR command.  The underlying problem is that the server
might be blocked on a receive on the data connection and not
listening for commands on the control connection.  So the user
side is required to perform some special action that includes
sending urgent data, which the server can then process specially.
This problem arises primarily in systems without either threading
or asynchronous I/O APIs.  Your use of asyncore should alleviate
this problem.

The thing that may be confusing you is that for whatever reason
the designers of the Berkeley socket API (which is what you are
using when running under POSIX/Linux/MS Windows), chose to use the
OOB flags (e.g., MSG_OOB) to indicate the *transmission* of OOB
data -- but it's not really OOB data.  In fact, when I attempt to
receive using the MSG_OOB flag using the OS interfaces on my system,
I get back an error (EINVAL - Invalid argument).  I would expect
that asyncore would report this error somehow or other.

In summary, you almost certainly can't use the concept of a separate
OOB channel to transfer data in an FTP environment.  If you really,
really need something like this, you will need to extend the FTP
protocol for your special purposes.

 - dmw

-- 
.   Douglas Wells .  Connection Technologies  .
.   Internet:  -sp9804- -at - contek.com- .
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Convert to C/C++?

[Douglas Wells]

In article [EMAIL PROTECTED],  SpreadTooThin [EMAIL PROTECTED] writes:
 I am wondering if someone who knows the implemention of python's time
 could help converting this to c/c++

First the obligatory sermon:

If you are truly intending to utilize a UUID generator on a UNIX
platform, I urge you to seek out and use a native implementation.
Both Linux and FreeBSD distributions include such a capability,
and there are also functions available in freely available libraries.
Such a native function would offer several advantages over the
code you are attempting to copy:

   1) it could utilize the full capability of the clock rather
  than be limited to the microseconds precision in gettimeofday;
   2) it is probably implemented utilizing a system locking function
  to provide a truly unique-per-system UID;
   3) it would almost certainly incorporate a per-machine unique
  identifier, as called for by the spec, and which is missing
  from your prototype code;
   4) it would have easier access to better pseudo-random number
  generators;
   4) it would probably be coded better than the code you provide,
  which squanders quite a bit of precision (I haven't counted
  exactly, but I would guess about 10 bits worth);
   
Also, it sounds as though you are not comfortable coding in C (as
most of the information that you seek is straight-forwardly available
from the Python and UNIX documentation), and there are numerous
subtleties in the code that you must develop:
   1) the management of endianness will require careful attention
  to your use of this function;
   2) conversion to and from 64-bit numbers requires attention to
  the suffixes.

With that said;

Python doesn't define the time epoch except on UNIX platforms, but
it's almost certainly the same as on UNIX.  So,

time.time() is equivalent to:
double time_time (void) { struct timeval tv;
gettimeofday (tv, (void *) NULL);
return tv.tv_sec + tv.tv_usec / 1e6); }

random.randrange(value) is approximately equivalent to:
long random_randrange (unsigned long stop) {
return rand () % stop; }
 - with the caveats that:
1) you should choose a better pseudo-random number generator
   than rand();
2) you should be sure to initialize the random function, e.g.,
   via srand();

   nanoseconds = int(time.time() * 1e9)
   # 0x01b21dd213814000 is the number of 100-ns intervals between the
   # UUID epoch 1582-10-15 00:00:00 and the Unix epoch 1970-01-01 00:00:00.
   self.timestamp = int(nanoseconds/100) + 0x01b21dd213814000L
   self.clock_seq = random.randrange(114L) # instead of stable storage
   self.time_low = self.timestamp  0xL
   self.time_mid = (self.timestamp  32L)  0xL
   self.time_hi_version = (self.timestamp  48L)  0x0fffL
   self.clock_seq_low = self.clock_seq  0xffL
   self.clock_seq_hi_variant = (self.clock_seq  8L)  0x3fL

You should look up the definition of the various fields (e.g.,
clock_seq, time_low, time_mid) in a UUID specification, for example
IETF RFC 4122.  They have precise width requirements.

   #print 'timestamp ', self.timestamp, self.time_low, self.time_mid, 
 self.time_hi_version
   #print 'clock_seq ', self.clock_seq, self.clock_seq_low, 
 self.clock_seq_hi_variant
 
 vs unix gettimeofday
 
 int gettimeofday(struct timeval *tp, struct timezone *tzp);

By the way, the UNIX gettimeofday function does not include timezone:
the prototype of the second argument is void * and must be passed
as NULL.

Good luck, - dmw

-- 
.   Douglas Wells .  Connection Technologies  .
.   Internet:  -sp9804- -at - contek.com- .
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: result of os.times() is different with 'time' command

[Douglas Wells]

[various posting problems corrected and response interspersed in
previous post for purposes of coherent response]

In article [EMAIL PROTECTED],
aspineux [EMAIL PROTECTED] writes:
 On 2 Feb, 19:30, [EMAIL PROTECTED] wrote:
  Hi,
 
  I have a question about os.times().
  os.times() returns a tuple containing user time and system time,
  but it is not matched to the result of 'time' command.
  For example, os.times() reports that user time is 39.85 sec,
  but 'time' command reports that user time is 28.55sec.
  (machine: Python2.5, MacOS X 10.4 Tiger, MacBook 1.83GHz intel core
  duo)
 
[ source elided ]
 
 I dont see anything wrong !
 Did you try to measure time with your watch ?
 Did you try a simple python test.py without the time command ?
 Maybe python is 'disturbed' by the intel core
 
 can you try this ?
 
 # strace python test.py  21 | grep time
 times({tms_utime=1, tms_stime=1, tms_cutime=0, tms_cstime=0}) =
 43021
 times({tms_utime=2238, tms_stime=2, tms_cutime=0, tms_cstime=0})  = 430220049
 write(1, n=35, v=14930352\nutime=22.37, st..., 41n=35, v=14930 52
 utime=22.37, stime=0.01

Note that this likely won't work.  First, strace is not native to
OS X; ktrace is the analogous native command.  Second, OS X almost
certainly implements the times system call in terms of getrusage.

Result:

$ python -V
Python 2.5
$ time python ostimetest.py
n=35, v=14930352
utime=39.85, stime=0.2167
real0m28.554suser0m23.938ssys 0m0.177s

 
  This shows that os.times() reports that user time is 39.85sec,
  but time command shows that user time is 23.938sec.
  Why os.times() reports wrong result? Do I have any mistake?
 
  --
  kwatch

Yes, I can reproduce this on my FreeBSD system.  No, I do not believe
that you have made a mistake.  Yes, I believe that you have uncovered
a bug in the Python os/posix modules.

Here's my analysis (although I should note that I've not looked
at the source of Python previously).  I'm looking at Python 2.4.3,
but this looks like a long existing bug:

The following code exists in the source code module
Modules/posixmodule.c @ posix_times:
struct tms t;
clock_t c;
[ ... ]
c = times(t);
[ ... ]
return Py_BuildValue(d,
 (double)t.tms_utime / HZ,
 (double)t.tms_stime / HZ,
 (double)t.tms_cutime / HZ,
 (double)t.tms_cstime / HZ,
 (double)c / HZ);
This is incorrect.  It should not be dividing by HZ, but by the
result of the dynamic value 'sysconf (_SC_CLK_TCK)'.  Even if
it were to use a compile time value, the proper value would be
CLK_TCK, not HZ.

So here's what's happening.  Neither my FreeBSD nor the OP's Mac
defines HZ as a compile time variable, but the same source module
also contains the following code:
#ifndef HZ
#define HZ 60 /* Universal constant :-) */
#endif /* HZ */
So, the Python posix module is using 60 instead of the proper
value, which happens to be 128 on my FreeBSD, and 100 on the OP's
OS X(*).  (BTW, this sort of historic code is exactly why POSIX
no longer defines HZ.)

In support of this, I note that the following ratios exist:
  user time from os.times / user time from time command
39.85 / 23.938 = 1.665
  CLK_TCK / HZ
  100 / 60 = 1.667
which are in reasonably close agreement!

 - dmw

[*] I've actually only looked at OS X for the PPC platform, not
for the User's Intel platform, but I'm fairly certain that the
CLK_TCK value is the same on both.

-- 
.   Douglas Wells .  Connection Technologies  .
.   Internet:  -sp9804- -at - contek.com- .
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How to sort using hash's key?

[Cliff Wells]

On Thu, 2007-02-01 at 04:54 +0800, JoJo wrote:

 I want to sort a dict via its key,but I have no idea on how to do it.
 Please help me,thanks.

You can't.  There is, however, a recipe for an ordered dict on ASPN:

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


 3webXS HiSpeed Dial-up...surf up to 5x faster than regular dial-up alone... 
 just $14.90/mo...visit www.get3web.com for details

You pay $15/mo for dialup???

Regards,
Cliff

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

Re: Type casting a base class to a derived one?

[Cliff Wells]

On Thu, 2007-01-11 at 08:41 -0600, Chris Mellon wrote:
 On 11 Jan 2007 15:01:48 +0100, Neil Cerutti [EMAIL PROTECTED] wrote:
  On 2007-01-11, Frederic Rentsch [EMAIL PROTECTED] wrote:
   If I derive a class from another one because I need a few extra
   features, is there a way to promote the base class to the
   derived one without having to make copies of all attributes?
  
   class Derived (Base):
  def __init__ (self, base_object):
 # ( copy all attributes )
 ...
  
   This looks expensive. Moreover __init__ () may not be available
   if it needs to to something else.
  
   Thanks for suggestions
 
  How does it make sense to cast a base to a derived in your
  application?
 
 
 I can't figure out any circumstance when you'd need to do this in
 Python. Upcasting like this is something you do in statically typed
 languages. I suspect that the OP doesn't really believe dynamic
 casting works and doesn't want to pass a derived class for some
 reason.

I actually encountered a need to do so (and I recalled seeing this
thread which is why I'm replying to it now).  I've got a dispatch system
based on object type.  Objects come from an external source (an ORM), so
I can't efficiently set their types at the point of creation (nor would
I necessarily want to).  However, in different contexts, I may want them
to be dispatched differently (i.e as if they are a different type).  In
fact, often the same object will be handled differently within two or
more contexts during the lifetime of that object.  It would be nice to
be able to cast them to a derived class (which actually adds no new
methods or attributes, just changes the type) at that exact moment to
cause the dispatcher to handle them differently.

Now, that being said, it's quite possible the system *could* have been
designed to not dispatch based on type, but quite frankly it works quite
elegantly and naturally for everything but this one case.

Just pointing out that just because we don't see a need for something
doesn't invalidate it.  It just makes it something we had thought of ;-)
  

Regards,
Cliff



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

Re: Type casting a base class to a derived one?

[Cliff Wells]

On Wed, 2007-01-24 at 12:57 -0600, Chris Mellon wrote:

 
 In Python, you can do this simply by re-assigning the __class__. I'm
 not convinced that your type system makes sense, here though. Any
 reasonable ORM should be able to persist and reload an object without
 losing the type information. Perhaps it's just a blind spot in the way
 I think about types. Assuming that the limitations of your ORM are
 external and out of your control, I would still ensure that whatever
 generic objects are being loaded from the ORM are converted into
 real objects of the correct type as soon as possible. For example,
 if you're persisting a file, you might just save the filename, and
 your ORM might return a string of the filename. I would want to
 convert that back into a file object ASAP, rather than writing all my
 code to accept either a FLO or a string and converting then.
 
 If you know what to upcast something to, then you know what type it
 is. If you know what type it is, then (in Python) you can simply
 assume it is of that type.

Probably being more specific would help in this case ;-)

What I'm doing is implementing an object-publishing mechanism in my
template engine (Breve).  The type decision isn't known until the moment
of rendering (i.e. in the template itself).  Say for instance a set of
records is pulled from the ORM (SQLAlchemy in this case) and that these
records represent articles in a blog.  These records, until they hit the
template, have no real representation in HTML.  The decision about how
to present them is up to the template.  The dispatch mechanism I
referred to earlier is a way that I allow users of the template system
to register how a particular object should be rendered in HTML (a
flattener).  This allows commonly represented objects to be used
without a lot of template clutter.
However, if you consider the case of a blog, then if the template
receives a list of articles, it would seem reasonable to present those
articles in at least two ways: first as a table of contents in the page
gutter, and then perhaps as two or three summaries in the main part of
the page.  But this isn't known to the lower layers of the application,
only to the template.  Therefore it would be nice if the template user
could register two classes with the flattener, both representations of
the original object but simply with a different type.  

I'll give a concrete example:

class Person: # assume this is something from the ORM
name = Kenny

class PersonRow ( Person ):
pass

def flatten_person ( p ):
return spanomg, you've killed %p/span % p.name

def flatten_personrow ( p ):
return trtd%s/td/tr % p.name

register_flattener ( PersonRow, flatten_personrow )
register_flattener ( Person, flatten_person )


Now, assuming a list of Person records were passed in as 'persons', then
in the template the template author could simply use:

div [
# show the first person
persons [ 0 ],

# show a table of all persons
table [
[ PersonRow ( p ) for p in persons ]
]
]


 What you're describing is a disjoint between your actual type system
 (that is, the one you have in code) and your theoretical type system
 (the one that you model your code around). To me, this is a huge red
 warning flag.

What I'm describing is a disjoint between how I want my template engine
to be used (I tend to build backwards, writing the desired template code
and then the engine code to support that use) and what can be easily and
efficiently achieved.  But yes, in a way you are correct since my
theoretical type system is constrained by Python's type system (Breve
templates are Python expressions).

That being said, I'm certain I'll come up with a solution that doesn't
bug me too much, it's just that the obvious solution doesn't exist
(type casting).

 I'm arguing against the idea that it makes sense, in Python, to
 upcast.

I think it's definitely a corner-case, but I'd be reluctant to claim it
would never be of use.

 I agree, but without a use case it's hard to understand the limits and
 needs of a requirement. So if you can't think of a need for a feature,
 it becomes difficult to understand how you might implement that
 feature.

Certainly.  Several years of using Python has never suggested a use to
me prior to this.

Regards,
Cliff


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

Re: Type casting a base class to a derived one?

[Cliff Wells]

On Wed, 2007-01-24 at 11:37 -0800, Cliff Wells wrote:

 
 class Person: # assume this is something from the ORM
 name = Kenny
 
 class PersonRow ( Person ):
 pass
 
 def flatten_person ( p ):
 return spanomg, you've killed %p/span % p.name
 
 def flatten_personrow ( p ):
 return trtd%s/td/tr % p.name
 
 register_flattener ( PersonRow, flatten_personrow )
 register_flattener ( Person, flatten_person )
 
 
 Now, assuming a list of Person records were passed in as 'persons', then
 in the template the template author could simply use:
 
 div [
 # show the first person
 persons [ 0 ],
 
 # show a table of all persons
 table [
 [ PersonRow ( p ) for p in persons ]
 ]
 ]
 

I should add that the reason I don't want to just say, call
flatten_personrecord() directly from the template (which would be a
reasonable solution in this example) is because I have a longer-term
goal that would require an object at that point.

What I expect I'll end up doing is using a factory function that returns
the desired object at that point, but it will require a bit more
explanation at the template level than I'd like:

table [
[ render_as ( PersonRow, p ) for p in persons ]
]

or something similar.


Regards,
Cliff

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

Re: ANN: Dejavu 1.5.0RC1

[Cliff Wells]

On Wed, 2007-01-24 at 14:57 -0800, Robert Brewer wrote:

 1. Expressions: pure Python lambda querying. This is perhaps the most
appealing feature of Dejavu.


Actually I just went and looked and personally I find the documentation
the most appealing feature.

Regards,
Cliff

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

Re: template engine

[Cliff Wells]

piotr wrote:
 On Sat, 13 Jan 2007 16:42:16 -0200, Jorge Godoy wrote:
 
 Take a look at Kid (http://www.kid-templating.org/) and Genshi
 (http://genshi.edgewall.org/).
 
 I've already done a short look at kid, but to be honest I don't like it's
 XML/Python syntax. I strongly prefer idea from SimpleTAL or HTMLTemplates
 where HTML and Python code are separated.
 But syntax is for me not so important like functionality so maybe I have
 to get back and look at kid again :)
 
 any other engines? :)

Perhaps Breve might interest you:

http://breve.twisty-industries.com

Regards,
Cliff

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

Re: merits of Lisp vs Python

[Cliff Wells]

On Sun, 2006-12-10 at 01:28 -0800, Kay Schluehr wrote:


 Who really wants to write web apps? Web apps are just an excuse for
 Pythonistas to write web frameworks.


I've been lurking, waiting for the right moment to toss in my two cents,
and finally, and here it is.

I've been using Python heavily for many years (since late 1.5.1) and
frankly I've gotten a bit bored with it.  I think your statement
indirectly (and unintentionally I'm sure) sums up why.   Python is
certainly pragmatic.  Python has *everything* you'd want for writing
applications: extensive libraries, flexibility, etc.  

Unfortunately, writing applications is boring. 

The way I like to overcome this boredom (and hence stay productive) is
by writing clever code.  I don't mean obfuscated one-liners (although
I'm guilty of that too), rather I mean generalizing code, creating
frameworks and then developing the application in that framework, that
sort of thing.  Python has been pretty good for me so far in keeping the
ceiling high enough that I could stretch but not bump my head too often.
I suspect I'm not alone in this need (hence the unusual number of web
frameworks written in Python).   

However lately I've noticed that the ceiling is quite apparent: Python
programmers are free to define DSL's via functions, classes, clever
operator overloading, etc, but not in the one way that actually makes
them really interesting: macros.
It might be true that macros would make it more difficult for someone
else to understand my code (although I doubt much more than say, Zope or
Twisted, or any of the popular ORMs floating about).   Regardless, let's
take a moment to consider another point of view: I. DON'T. CARE.  That's
right.  I don't care if anyone else can read it.  Frankly I may not even
care if *I* can read it in a year.   Every year I look back at what I've
written the previous year and think about how much better I could have
done it *this* year.  This has gone on for over twenty years now and I
suspect that if that fact ever changed it would probably be time for me
to retire from programming as I'd have stopped learning (or would at
least be bored out of my mind).

The majority of code is throwaway.  That is, whatever need it was
written to fulfill will cease to exist, the coder will think of some
brilliant new approach that requires a major rewrite, another programmer
with different ideas will rewrite it from the ground up (probably in a
new language), a library will appear that renders it moot, etc, etc.
While I'm sure there is a huge base of ancient code out there somewhere,
faithfully powering our banks and dams and pushing fractions of pennies
about, I simply don't care.  Someone may have to read it, please god
don't let it be me.  I don't care about old application code.  It's
effing boring.  I don't just program because it pays the bills.  I
program because I *like to program*.   That means not having arbitrary
limits to what I can express so that some hypothetical 8th grader can
come along in some future decade and grok some one-off program I hacked
together over a weekend.   If I write code during a drunken binge, then
dammit, I'll run that code in another drunken binge.  If not, then I'll
damn well rewrite it when I'm sober.   I neither want nor need moral
programming imperatives handed down from above.   I will write crappy
code whenever I damn well feel like it.  If I learn something from it,
all the better.  If not, well that's my choice as an adult to take that
path.

There is lots of talk about how, if Python had macros, everyone would
create their own mini-languages and it would be a virtual Tower of
Babel, etc, etc.  Perhaps.  But of course, given how much syntax Python
has grown since 1.5 (most of which is there to compensate for
statement-oriented syntax and lack of macros) I'd suggest that perhaps
the tower is already being built directly into the language.

As an aside, it's pretty sad when many of the c.l.lisp folks on this
thread seem more polite in general than the c.l.py crowd.   Lisp may
have expression-based syntax and macros, but it's also got Eric Naggum.
If we can't have the nice features of Lisp, let's at least not adopt its
downsides.

Regards,
Cliff

P.S.  As a disclaimer, I *have* had a few beers tonight already and
have, in fact, been binge-coding, so if this seems like a rant, I
reserve the right to deny all knowledge of anything I may have written
up to this point. 



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

Re: merits of Lisp vs Python

[Cliff Wells]

On Mon, 2006-12-11 at 08:11 -0800, [EMAIL PROTECTED] wrote:

 Bill Atkins wrote:
   On the plus side, Python makes less demands on the
   capabilities of the editor. All you really need
   is block-shifting commands. Bracket matching is
   handy for expressions but not vital, and you
   certainly don't need bracket-based auto-indenting.
 
  Oh, please.  So we should restrict the power of the languages we
  choose just to make sure that our code can be edited in Notepad?
 
 In the real world, it's a non-negligible consideration, IMO.  I find
 myself needing to write code on machines that aren't my usual dev
 machine at least a couple of times a year, and not having to install a
 particular editor is nice (especially in terms of keeping the
 modifications to someone else's machine down to a minimum).
 
 It's hardly a dealbreaker for a particular language, but it's far from
 worthless.


For the most part, editing Python isn't an issue, but I think it's a
fallacy to claim that significant whitespace has no impact on editing
and refactoring.   There's a reason indent-region doesn't work for
Python code in Emacs (and probably never will - I consider the hopefully
uncommon practice of putting pass statements at the end of blocks
marginally silly).   There was a time (many years ago) when I used this
feature of Emacs to catch indentation errors in C code.  Just run
indent-region on the entire file and you get a fast visual indication of
where you misplaced a brace.  Trying this on Python code would require
you to restore from a backup file.
Another example is copying and pasting from external sources (web pages
for instance) where the indentation gets totally screwed.  In a language
with block delimiters this is fixed with a couple keystrokes in Emacs.
In Python it requires manually comparing each line with the original (or
typing it in manually to begin with).

I *like* the significant whitespace in Python but let's not pretend
there isn't at least a small penalty.  And I strongly suspect Python's
varied syntactical rules impose far more of a load on code editors
than Lisp does (it certainly offers more opportunity for the editor to
do the wrong thing).   

Regards,
Cliff



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

Re: merits of Lisp vs Python

[Cliff Wells]

On Sat, 2006-12-09 at 00:26 -0800, hankhero wrote:

 The Common-Lisp object systems has all and more OO-features, some which
 you never probably have thought of before. Here's one:
 Inheritance lets you specialise a method so a rectangle and a circle
 can have a different Draw method. If you wouldn't have OO you would
 need a function with if statements to dispatch on thing, if
 thing=rectange then drawRectangle if thing=circle then drawCircle.
 What if you want a draw method that takes a thing and a backend, then
 you need if statements again, draw(self,backend): if backend ==
 postscript do one thing else do another.
 Maybe you can solve this with multiple inheritance, creating
 RectangePostscript and CirclePostscript objects. Lisp supports multiple
 inheritance too, but also multimethods which allow a looser coupling
 between objects and dispatching on all parameters, not only the first
 parameter (self in python speak). Just define one method
 draw(rectange,postscript) and another draw(rectangle, pdf)

This mechanism doesn't make much sense in Python since dispatching based
on type rather than on capability is considered bad in the Python
world, and for good reason. 
The classic example is file-like objects.  What if you have two methods,
one that takes a file object and another that takes a string and you
pass an object that has string as a base class but provides file-like
capabilities?  Which method should be called?  Better to explicitly call
the desired method.  Multimethods may make sense in many languages but
not so much in Python.  

Regards,
Cliff


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

Re: profanity on comp.lang.python (was Re: Pyro stability)

[Cliff Wells]

On Wed, 2006-11-08 at 06:49 -0800, Beliavsky wrote:
 Cliff Wells wrote:

  The LA Times had a story that claimed that 64% of U.S. citizens use the
  word fuck and that 74% of us have heard it in public (I'll assume the
  remainder are your fellow AOL users).  I expect extrapolating these
  results worldwide wouldn't be far off the mark (the Brits were quite
  successful at spreading this versatile word).
 
 If this is supposed to justify using bad language in a public forum, it
 is poorly reasoned. Having heard f*** does not mean they were not
 annoyed. 
 100% of people have seen trash on the street, but that does
 not justify littering. 

Poorly reasoned or not, it was clearly poorly read, since the article I
mentioned also claimed that the majority of people also used the word.
Odd, I'd think with your selective reading skills you'd simply be able
to ignore words you don't like.

Regardless, I think the idea that certain words are profanity is fairly
silly.  They are words.  It's the meaning and intent behind them that
can be offensive.  If someone says fuck off then I'd expect you to be
offended *since that was the intent of the message* (of course if you
manage to not be offended then that makes you the better man, but
apparently that's rarely strived for).  On the other hand if someone
says that's fucking great in a positive way and you are offended by
it, well I'd say that's *your* problem and your best bet is to turn off
your TV, your PC, your radio, stop reading and try to limit interactions
with other people lest you be overwhelmed by how they really speak and
act.

 If a group of people don't mind profanity, there
 is no harm in their swearing to each other. But Usenet is read by a
 wide range of people, and needlessly offending some of them is wrong.

I halfway agree with you.  I tend to limit my profanity in public forums
and when speaking to strangers, etc.  On the other hand, when in public
I also expect to hear that language from others and am not offended by
it.  

And expecting anyone to escape without offense on Usenet is pretty
unrealistic.

 The OP used f** just for emphasis. English is a rich language,
 and there are better ways of doing that.

Hm, lots of people disagree with you.  In fact, simply because that word
*does* happen to be less widely used in this group it gave it extra
emphasis and was probably the most effective word he could have used in
this particular instance.  I don't think anyone here will have forgotten
his endorsement anytime soon.

Incidentally, using  to disguise profanity when the intended word
is perfectly understood is pretty silly too.  I strongly suspect you'd
be just as offended if I said f*** off as if I'd typed it out.  Once
again, intent and meaning are what matter rather than a particular
sequence of characters.

Regards,
Cliff

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

Re: profanity on comp.lang.python (was Re: Pyro stability)

[Cliff Wells]

On Wed, 2006-11-08 at 10:12 -0800, Carl J. Van Arsdall wrote:
 BartlebyScrivener wrote:

  I agree. And Python is an extremely serious matter calling for decorum
  and propriety.

 Lol, is it really now?  And I suppose its your definition of decorum and 
 not mine right?  Things like that are always relative.  I think decorum 
 would state that you should be an adult and not make a big deal out of 
 nothing.  But that's just me, and as I said, its all relative.

I think you missed the irony in his statement (or perhaps confused
BartlebyScrivener with Beliavsky, who was the original plaintiff).

Regards,
Cliff

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

Re: profanity on comp.lang.python (was Re: Pyro stability)

[Cliff Wells]

On Wed, 2006-11-08 at 10:42 -0800, Paddy wrote:

 I too know your wrong Aahz. The written word is not the same as that
 spoken. People should make an effort to put across their meaning in a
 clear manner. If I were going to an interview I would be very careful
 about swearing and most likely not do it. People complain about the
 friendliness and tone of groups, and mention it when talking about
 programming languages.

But of course, this was never about friendliness or tone.  The person
who uttered the dreaded word was actually speaking quite positively
about Pyro.  The complaint was about the use of a particular word, not
the intent of it.

 Not everyone swears like Eddy Murphy in Beverley Hills Cop, and a lot
 of those that do, would not do so when they want to impress, or
 communicate with a stranger.

But of course not everyone is a double-edged sword that can just as
easily be turned against either party.  If we limit ourselves to saying
what is going to be the most palatable for the widest audience we will
most likely find ourselves confined to discussing the weather. 

And of course, people who worry too much about impressing others rarely
do.  Just ask DHH of Ruby on Rails fame:

http://static.flickr.com/47/127984254_ddd4363d6a_m.jpg

Personally I find people trying to impose their personal beliefs on
others to be at least as offensive as any particular swear word and
about a million times as dangerous.  

 P.S. I did a google search and found 540,000 hits for python in c.l.p.
 and only 121 for f***. thats less than one in a thousand. Lets keep it
 that way please.

Well, I think that's a good point: the one instance we had that spawned
this thread fell well within this one-in-a-thousand boundary.  So
there was no indication that c.l.py was in danger of turning into a
sailor's bar.  

I'll apply an old software maxim (from sendmail?) to the topic of public
interaction: Be liberal in what you accept, conservative in what you
send.  Applying this would suggest that both parties were equally at
fault in this situation, so perhaps we can just leave it at that.  

Regards,
Cliff


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

Re: profanity on comp.lang.python (was Re: Pyro stability)

[Cliff Wells]

On Wed, 2006-11-08 at 11:18 -0800, Aahz wrote:
 In article [EMAIL PROTECTED],
  [EMAIL PROTECTED] wrote:
 
 I'm with Beliavsky on this one.  I can't see any particular reason to curse
 in a forum such as c.l.py.  It just coarsens the discussion with no obvious
 positive benefit as far as I can see.
 
 Actually, I do agree that profanity should be avoided on c.l.py; what
 I disagree with rather vociferously is having language police like
 Beliavsky.  I consider Beliavsky's offense far worse than the original
 post.

I think this sums up my point of view as well (although I would have
used around 3215 more words to say it). 

Cliff


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

Re: Unicode/ascii encoding nightmare

[Cliff Wells]

On Tue, 2006-11-07 at 08:10 +0200, Hendrik van Rooyen wrote:
 John Machin [EMAIL PROTECTED] wrote:
 
 8---
 
  I strongly suggest that you read the docs *FIRST*, and don't tinker
  at all.
 

  This is *good* advice - its unlikely to be followed though, as the OP is 
 prolly
 just like most of us - you unpack the stuff out of the box and start 
 assembling
 it, and only towards the end, when it wont fit together, do you read the 
 manual
 to see where you went wrong...

I fall right into this camp(fire).  I'm always amazed and awed at people
who actually read the docs *thoroughly* before starting.  I know some
people do but frankly, unless it's a step-by-step tutorial, I rarely
read the docs beyond getting a basic understanding of what something
does before I start tinkering.

I've always been a firm believer in the Chinese proverb:

I hear and I forget
I see and I remember
I do and I understand

Of course, I usually just skip straight to the third step and try to
work backwards as needed.  This usually works pretty well but when it
doesn't it fails horribly.  Unfortunately (for me), working from step
one rarely works at all, so that's the boat I'm stuck in.

I've always been a bit miffed at the RTFM crowd (and somewhat jealous, I
admit).  I *do* RTFM, but as often as not the fine manual confuses as
much as clarifies.  I'm not convinced this is the result of poor
documentation so much as that I personally have a different mental
approach to problem-solving than the others who find documentation
universally enlightening.  I also suspect that I'm not alone in my
approach and that the RTFM crowd is more than a little close-minded
about how others might think about and approach solving problems and
understanding concepts. 

Also, much documentation (including the Python docs) tends to be
reference-manual style.  This is great if you *already* understand the
problem and just need details, but does about as much for
*understanding* as a dictionary does for learning a language.  When I'm
perusing the Python reference manual, I usually find that 10 lines of
example code are worth 1000 lines of function descriptions and
cross-references.

Just my $0.02.

Regards,
Cliff


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

Re: Unicode/ascii encoding nightmare

[Cliff Wells]

On Mon, 2006-11-06 at 15:47 -0800, John Machin wrote:
 Gabriel Genellina wrote:
  At Monday 6/11/2006 20:34, Robert Kern wrote:
 
  John Machin wrote:
Indeed yourself. Have you ever considered reading posts in
chronological order, or reading all posts in a thread?
  
  That presumes that messages arrive in chronological order and
  transmissions are
  instantaneous. Neither are true.
 
  Sometimes I even got the replies *before* the original post comes.
 
 What is in question is the likelihood that message B can appear before
 message A, when both emanate from the same source, and B was sent about
 7 minutes after A.

Usenet, email, usenet/email gateways, internet in general...  all in
all, pretty likely.  I've often seen replies to my posts long before my
own post shows up.  In fact, I've seen posts not show up for several
hours.   

Regards,
Cliff



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

Python extensions on Win32

[Cliff Wells]

For various sundry reasons, I find myself needing to deliver a
Windows-based Python app.  I also chose Python 2.5 for this platform.

The app has several requirements, all of which are available for Python
2.5/Win32 except one: pycurl.  So I decided to try building the source
but as it turns out, building C programs on Windows isn't nearly as
straightforward as on Linux, so I'm a bit lost.

I've downloaded the free Visual C++ Studio 2005, the pycurl sources (and
the requisite curl libs, etc), but pycurl insists I don't have a C
compiler compatible with VC++ 2003 (which I'm assuming is what Python
2.5 is built with).

So, for anyone who might know:

1) Is VC++ 2005 compatible with VC++ 2003?  If not, how can someone
acquire VC++ 2003 (aside from thepiratebay.org)?  The Microsoft site
seems to be a dead end here unless you've put out for a spendy MSDN
subscription.

2) If it is compatible, is there some specific incantation needed (env
variables, etc) to make pycurl use it?

3) If this is a dead-end, will mingw32 work instead (the error message
from pycurl implies it might, but I have doubts)?  Or will this only
work with the cygwin version of Python?

4) How much alcohol will be required to forget all this when I'm done?


Thanks,
Cliff

-- 

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

Re: Python blogging software

[Cliff Wells]

On Wed, 2006-09-13 at 19:28 +0200, Irmen de Jong wrote:
 Cliff Wells wrote:
  I'm currently using Frog, and it's decent, but lacks some fundamental
  features (tags for one).  Since Irmen is probably going to scrap it
  anyway, I'm kind of fishing about for something new.
 
 That is not really true. I won't scrap Frog. One of the reasons
 would be that I'm using it myself ;-)
 Perhaps you confused it with the possible scrapping of the Snakelets
 appserver it runs on? I'm thinking about rebuilding Frog on one
 of the more established servers such as Turbogears.
 But haven't had the time to start this.

Yes, I saw that and took it to mean you were scrapping Frog as well (of
course, if you scrap Snakelets, I suspect any new Frog would have
little in common with the existing one except perhaps the moniker).

BTW, I still like Frog (it's still near the top of the Python blog heap
IMO), I just needed some things it didn't have.

Regards,
Cliff

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

Re: Why not event-driven packages in other than the main thread?

[Cliff Wells]

On Thu, 2006-09-14 at 11:13 +0200, Tor Erik wrote:
 Hi,
 
 I've developed an application were I've used Tkinter for the GUI.
 When I ran the GUI in another thread than the main, it kept locking
 up.
 I experienced similar problems with Twisted.
 
 Both of these tools are event-based, so I guess that is the root of the 
 problem...
 
 But could anyone tell me why running these in a thread other than the 
 main one doesn't work?

They probably use signals (Twisted I'm sure does) and it's documented
that signals don't work with threads:

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

Regards,
Cliff

-- 

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

Re: Why not event-driven packages in other than the main thread?

[Cliff Wells]

On Thu, 2006-09-14 at 03:22 -0700, Cliff Wells wrote:

 They probably use signals (Twisted I'm sure does) and it's documented
 that signals don't work with threads:
 
 http://docs.python.org/lib/module-signal.html


Er, specifically, they only work with the main thread.

Cliff
-- 

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

Python blogging software

[Cliff Wells]

There's been a lot of blogs started in Python, but given the recent
spate of web frameworks, I'm surprised that some blogging package hasn't
taken front seat yet.

I'm currently using Frog, and it's decent, but lacks some fundamental
features (tags for one).  Since Irmen is probably going to scrap it
anyway, I'm kind of fishing about for something new.

I've seen a few written in Zope/Plone, but they looked not quite
interesting enough given the resources it would take to run them.  At
least two were started in TurboGears but seem to have vaporized.

Anyone aware of any functional (doesn't need to be complete, beta is
fine) blog software written in Python?  

Regards,
Cliff
-- 

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

Re: Python blogging software

[Cliff Wells]

On Wed, 2006-09-13 at 00:29 -0700, Cliff Wells wrote:

 Anyone aware of any functional (doesn't need to be complete, beta is
 fine) blog software written in Python?  

Hmph.  And as soon as I hit send I find

 http://wiki.python.org/moin/PythonBlogSoftware

Okay, so is there any *not* on that list that should be considered (and
perhaps added to the list)?

Regards,
Cliff

-- 

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

Re: Python blogging software

[Cliff Wells]

On Wed, 2006-09-13 at 08:22 -0700, Fuzzyman wrote:
 Cliff Wells wrote:
  On Wed, 2006-09-13 at 00:29 -0700, Cliff Wells wrote:
 
   Anyone aware of any functional (doesn't need to be complete, beta is
   fine) blog software written in Python?
 
  Hmph.  And as soon as I hit send I find
 
   http://wiki.python.org/moin/PythonBlogSoftware
 
  Okay, so is there any *not* on that list that should be considered (and
  perhaps added to the list)?
 
 Firedrop2 is a client-side blog program (generates static HTML to be
 uploaded to your webserver).

I looked at this but didn't care for it as it doesn't appear to allow
for comments (feature-wise it's a few steps down from Frog, which I
already have working).

For anyone who's interested, what I finally settled on was Bitakora.  It
violated one of my own requirements (it runs on Zope), but because it's
multiuser and quite featureful and modern, the tradeoff seemed worth it:
  
http://www.codesyntax.com/bitakora/about

I will say that installing it was something of a pain.  If the Zope guys
want to know why Zope has been left behind, one of the first things I'd
suggest is to clean up zope.org.  Bitakora has several dependencies and
nearly all of the links to these dependencies led me on a wild goose
chase of broken links, multiple incompatible versions, incompatible
forks, etc.  

For those who might follow in my footsteps, the dependencies (with
correct links to correct versions) are:

Epoz: http://iungo.org/products/Epoz/
Localizer: http://www.ikaaro.org/localizer
TextIndexNG2: http://opensource.zopyx.biz/OpenSource/TextIndexNG
CookieCrumbler: http://hathawaymix.org/Software/CookieCrumbler

It also depends on BTreeFolder2, but that's included in the latest Zope
2.8 series.

I think the worst of all of these was surprisingly Epoz.  There are at
least three distinct branches of this product: the original
(deprecated), it's replacement (kupu), and a fork (which happens to be
the correct one).  The information on zope.org gives little indication
that there might be such a fork (but is quite happy to lead you in
circles).  I noticed that several of the products mentioned the pain of
maintaining software on zope.org (and so had moved their software
elsewhere), so this is probably the root of the problem.

Anyway, Zope complaints aside, Bitakora is really great and I'd
recommend that anyone looking for a friendly, multiuser blog take a
look.


Regards,
Cliff


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

Re: Are Python's reserved words reserved in places they dont need to be?

[Cliff Wells]

On Wed, 2006-09-13 at 10:30 +0200, Fredrik Lundh wrote:
 Antoon Pardon wrote:
 
  One place where I would use such a feature is in a unittest
  package.  I think being able to write self.assert or self.raise
  looks better than having to append an underscore.
 
 patch here:
 
 http://mail.python.org/pipermail/python-list/2001-June/047996.html


Did you happen to remember this post or is Google *really* your friend?


Cliff

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

Re: Is it just me, or is Sqlite3 goofy?

[Cliff Wells]

On Tue, 2006-09-12 at 13:01 +0200, Fredrik Lundh wrote:
 Mike Owens wrote:
 
  Crackpot? And now we get to why I took the flamebait -- wonderfully
  constructive comments such as this.
  
  I know SQLite's author. Besides being a nice and clearly very
  intelligent person, he also holds a master's degree in electrical
  engineering from Georgia Tech and a PhD in computer science from Duke
  University. His crackpot software is used by Sun, Apple, Symbian,
  Google, AOL, Philips, DLink, and I don't know how many other
  companies, not to mention countless open source projects such as
  Mozilla, PHP, and now Python.
 
 but is he a member of Mensa?


Now *there's* a group of crackpots.


Cliff
-- 

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

Re: best small database?

[Cliff Wells]

On Mon, 2006-09-11 at 13:23 +, David Isaac wrote:
 I have no experience with database applications.
 This database will likely hold only a few hundred items,
 including both textfiles and binary files.
 
 I would like a pure Python solution to the extent reasonable.

Since no one's mentioned it:

http://schevo.org/trac/wiki

-- 

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

Re: best small database?

[Cliff Wells]

On Tue, 2006-09-12 at 12:29 -0700, Kay Schluehr wrote:

 Just one stupid remark since the limits of my language are the limits
 of my world: I've not the slightest association with the seemingly
 nonsense word buzhug and don't even know how to pronounce it
 correctly. Would you have the kindness to enlighten me/us ?

I simply assumed it was guhzub backwards.

Cliff

-- 

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

Re: Are Python's reserved words reserved in places they dont need to be?

[Cliff Wells]

On Tue, 2006-09-12 at 18:05 -0700, Robert Hicks wrote:
 metaperl wrote:
  Istvan Albert wrote:
   metaperl wrote:
--  python -i
 class = algebra
  File stdin, line 1
class = algebra
  ^
SyntaxError: invalid syntax
  
   Designing a syntax to avoid all possible newbie errors is impractical
   because as soon as you are finished with one iteration the new newbies
   will start making different kinds of errors...
 
  You are missing the point: the point is that the above could be
  considered correct if the rules of Python were that an assignment
  statement takes
  IDENTIFIER '=' LVALUE
 
  Also  class IDENTIFIER COLON could also be considered correct.
 
 
 Yes it could but it isn't and isn't likely to be. Simply do not use
 reserved words. That rule is hardly limited to Python.

I'm surprised so many people misunderstand his complaint.  It isn't as
simple as don't do it.  The OP is referring to autogenerated code and
attributes.  This means you must tell the source of the generated items
(perhaps a database table) that it can't have a column named class or
pass or add hacks in to work around it (an easy one would be to prefix
autogenerated attributes, which also helps work around the lack of
private attributes in Python).

Whether or not this should be changed is tangential to the OP's point.
It must be a bit frustrating to state the obvious over and over and see
it misinterpreted each time.  Python has shortcomings.  This is one of
them, whether there's valid reasons for it or not.  It's better to
acknowledge it and offer something useful rather than that isn't the
Python way, don't do it.


Cliff

-- 

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

Re: python-database

[Cliff Wells]

On Sun, 2006-09-03 at 21:30 -0700, sridhar wrote:
 is there any way to call stored procedures from python as in java?

I mostly use PostgreSQL, so perhaps it's different for some other
databases, but calling stored procedures doesn't require any special
support from the language or driver.  Usually you simply SELECT from the
stored procedure.

Also, you might be interested to know that with PostgreSQL you can also
*write* stored procedures in Python which I consider a huge plus.

Regards,
Cliff

-- 

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

Re: Pros/Cons of Turbogears/Rails?

[Cliff Wells]

On Thu, 2006-08-31 at 23:31 +0200, BJörn Lindqvist wrote:
 On 8/31/06, Jorge Vargas [EMAIL PROTECTED] wrote:
  On 31 Aug 2006 08:24:29 -0700, Adam Jones [EMAIL PROTECTED] wrote:
 
  Someone ones said on the mailing list TG is the Ubuntu of web
  frameworks, and I think I'll add and you can strip down the kernel and
  it wont break :)
 
 But that is not really true. If you use Cheetah instead of Kid, you
 lose out: No widgets,

Untrue.  Even though I don't use widgets much myself, I wanted to make
sure they *could* be used with TurboStan, so I did a quick test with
Kevin's autocomplete widget.  Worked fine.  I can't see why Cheetah
would be any different.

  no auto-generated code 

What auto-generated code?  The example templates that you get with 
quickstart?  Hardly a loss.

 and the (incomplete)
 documentation won't apply anymore (it assumes Kid templates ofcourse).

True.  However I've had little trouble translating from Kid to Stan (and
that's probably a longer jump than from Kid to Cheetah).

 If you use SQLAlchemy instead of SQLObject, no identity framework,

Completely false.

  no administrative tools (tg-admin sql, 

True. 

 CatWalk etc

True.  

 ) and no documentation.

Partially true.  The documentation exists but some of it is out-of-date
and it was never very complete to begin with.  Of course, like many OSS
projects, the mailing list is your best resource and SQLAlchemy itself
has quite good documentation.

 If you use prototype instead of MochiKit... I have no idea what
 happens 

You get Prototype instead of MochiKit.

 and using another webserver than CherryPy isn't possible right
 now, I guess?

Not that I'm aware of.  Nor do I think it would make much sense since
CherryPy is the heart of TurboGears.  I typically use CherryPy to serve
the dynamic content and a real webserver (Nginx) to serve static files.
I've never felt this was a handicap.

 In fact, if you decide to replace so many modules that TurboGears
 depend on, what do you gain in using TurboGears at all? 

If you got to the point where you were replacing more parts than you
were using, then you'd certainly want to find a different framework as
TurboGears is clearly not for you.  I fail to see your point.

Personally I've chosen to go a different route on a couple things and
leave the rest intact.  I expect most people are the same.  With most
frameworks, there's typically one or two things most people don't like
and it's nice to be able to replace those things without a lot of fuss.
I don't see how that's a liability.

 It seems like
 the TurboGears developers have a lot of work to do, (and a lot of
 documentation to write) if they want to make their framework as easy
 to use as others (ie: Django) that takes a more holistic approach.

That's odd, because I've actually used both and found TurboGears far
easier to get started with (no mucking about with Apache and mod_python
for one thing, no need to setup explicit url regexes just to get hello,
world on a page).  

Judging from your above comments it sounds to me like you're mostly
speculating about TurboGears.

 TurboGears more seem to be like emacs than Ubuntu - infinitely
 customizable...

Not quite enough IMO, but close enough.

 In the future both Rails and TurboGears will probably be great. But
 since someone mentioned Rails moving to YARV, and TurboGears moving to
 SQLAlchemy and Markup, it seems to me that they are both in a state of
 flux and not quite ready yet.

TurboGears is certainly in a state of flux although from an outside
(i.e. API) standpoint it's not nearly as bad as you might think from the
changes that have gone on under the hood.  There's been only a few
breaking changes up til now (I converted a site I'd built on 0.8 to the
latest SVN last night and most of the issues I encountered were with my
own changes to TurboStan).

Regards,
Cliff

-- 

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

Re: Pros/Cons of Turbogears/Rails?

[Cliff Wells]

On Thu, 2006-08-31 at 09:04 -0700, Paul Boddie wrote:

 SkunkWeb (3.4.0), Zope (2.9.4 and 3.2.1), Plone (2.5), Karrigell (2.3),
 CherryPy (2.2.1), Spyce (2.1), QP (1.8), Cymbeline (1.3.1), Django
 (0.95), Webware (0.9.1), Pylons (0.9.1), TurboGears (0.8.9), PyLucid
 (v0.7.0RC4), Paste (0.4.1), web.py (.138)

And ironically, the one with the *lowest* version number (web.py) is
used to power some fairly large (and ambitious) public projects:

https://www.youos.com/ ( see http://blog.youos.com/?p=49 )
http://reddit.com/

I'd like to claim that in OSS, version numbers mean little, but I still
recall Windows NT 1.0 (er, I mean 3.1), so I guess they don't mean much
anywhere.  Version numbers are *picked* by project leads for varying
reasons, so comparing version numbers from different projects is pretty
pointless.  Is Windows 2000 more stable than Linux 2.6?  It ought to be
since it's 769 times more mature, right?  Even if you called it Windows
NT 5.0, I'd have to wonder if it's even twice as stable (I'm being
intentionally generous here, so bear with me).

Personally I tend to look at what the users (especially former users)
say about a project and what's been or being done with that project.  If
it seems promising, I try it.  I can't think of any other reasonable way
of making that decision.

Regards,
Cliff

-- 

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

Re: avoiding file corruption

[Cliff Wells]

On Sun, 2006-08-27 at 07:51 -0700, Amir Michail wrote:

 How often do you need to open a file multiple times for writing?

How often do you write code that you don't understand well enough to
fix?  This issue is clearly a problem within *your* application.

I'm curious how you could possibly think this could be solved in any
case.  What if you accidentally open two instances of the application?
How would Python know?  You are asking Python to perform an OS-level
operation (and a questionable one at that).

My suggestion is that you use a real database if you need concurrent
access.  If you don't need concurrent access then fix your application.

 As a high-level language, Python should prevent people from corrupting
 data as much as possible.

Data is application-specific.  Python has no idea how you intend to
use your data and therefore should not (even if it could) try to protect
you.

Regards,
Cliff

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

Re: Out-dated compiled modules (*.pyc)?

[Cliff Wells]

On Sat, 2006-08-26 at 18:54 +, Dennis Lee Bieber wrote:

   Normally, Python compares the date stamps of the files (and maybe
 some internal magic values) and only rebuilds the .pyc if the .py is
 newer.

Perhaps the OP should check both the system date on his PC and the
timestamp on the pyc files in question.

Cliff


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

Re: What do you want in a new web framework?

[Cliff Wells]

On Thu, 2006-08-24 at 04:28 -0700, Paul Boddie wrote:
 Cliff Wells wrote:
  On Thu, 2006-08-24 at 04:04 +, Tim Roberts wrote:
   Cliff Wells [EMAIL PROTECTED] wrote:
   
   But there are interesting things in Ruby (and Ruby 2 should take care of
   lots of warts Ruby 1.8 has) that Python could learn from.  All-in-all,
   Ruby is mostly as good as Python in most ways and better than Python in
   a couple key ways.
 
 The big difference between Ruby and Python is the lifecycle phase that
 the languages/systems are in: Ruby arguably has room for a lot of basic
 improvements in the architecture of the virtual machine and presumably
 has a list of must add features that cover gaping holes with respect
 to certain audiences [1], whereas Python has been around for ages and
 has covered most of the critical gaps in the feature list (although we
 can always suggest things which bother our own part of the community).
 Whereas the Ruby people merely have to agree on how critical their
 missing features are and to move in one widely agreed direction, the
 Python people face a tougher choice as to what should be done next;
 strategies include a tidying-up exercise to make the language more
 coherent, a complete reimplementation, deep modifications to the
 runtime, the introduction of radical new semantics.

All true, but there's a more fundamental difference that's going to show
more as a larger number of people become used to Ruby's semantics: any
Ruby statement can be used as an expression.  This is firmly from the
Lisp family of languages whereas Python's statement-based syntax is
firmly in the Fortran branch.  With the exception of Lisp itself, no
language has seen the popularity of this style of programming until
Ruby.  I think this represents a real danger to Python's mindshare.
Once people have tried expression-based languages, they tend to be
loathe to return to statement-based languages.  To date,
expression-based languages have been mostly of interest in academia or
to a small group of elitists and so weren't practical to use for
day-to-day work.  Ruby has changed that and I think we're just starting
to see the fallout.  Rails may have brought them there, but Ruby itself
is keeping them there.  My fear is that the expression-based family of
languages is the Homo Sapiens to our statement-based Neanderthals and we
can either evolve or disappear.  Python is unique in many ways and I'd
hate to see those unique features lost because we're stuck on the wrong
evolutionary branch.

 The fewer obvious issues that a language has, the less energy there is
 in the community to deal with those issues thoroughly, I think. I guess
 the Perl community chose a bold new direction in line with the
 observation that a big vision can inspire much more in people than lots
 of incremental changes to an existing vision, but the energy required
 to follow through on such a vision can be immense. In addition to all
 this, a large existing community is more likely to want larger benefits
 for smaller levels of disruption because of the amount of existing
 code. Thus, the available energy for change is less in a mature project
 than in a growing project because people have to constantly monitor the
 breakage in their existing investments in the language.
 
   ...but you can't READ Ruby code.
 
  Yeah, that's one of the big reasons I haven't seriously considered
  trying it.  It's expressive, got interesting features... and appears
  unreadable to me.  I'm usually pretty good at deciphering most
  languages, even if I haven't used them before, but Ruby is one of the
  exceptions.
 
 My feeling is that I'd rather learn more about Lisp or Scheme than Ruby
 - the benefits are greater and for me Lisp and Scheme increasingly have
 the edge on readability. Perhaps I'm just not tuned in to
 Smalltalk-style syntaxes.

I'm in the same camp.  As I mentioned earlier, it's been mostly inertia
and the wealth of the Python community that's kept me with Python.
That's why I was so excited when I found Logix.  Lisp-like features with
Python's syntax that generates Python bytecode.  Actually Logix is
perhaps too far the other direction as it supports Lisp-style macros and
the creation of arbitrary syntax, which perhaps would justify some of
the fears people have of Lisp-like languages.  
The part I found appealing was having Python-like syntax in an
expression-based language, with the capability to integrate completely
with Python libraries.  Absolutely the best of both worlds.  I've been
trying to contact the author of Logix to find out what the status of the
project is or if he's abandoned it.  If you haven't looked at it you
really ought to.

http://livelogix.net/logix/


  This brings us back around to the web framework debates.  For many
  people Ruby fits their brains and for others Python does.  I think
  frameworks are similar.  I tried Django and while I thought it was a
  great product, it simply didn't fit how I think about that problem

Re: Python Syntax Highlighting Module

[Cliff Wells]

On Mon, 2006-08-21 at 08:19 -0700, gene tani wrote:
 [EMAIL PROTECTED] wrote:
  Hello,
  I have an idea for a project which involves an editor that supports
  syntax highlighting.  This would be for any language, particularly php,
  html, css, etc.  I would like to write this program using python.  It
  would only make sense to base this upon existing open source code.  My
  question is there a python module or examples on how to write a code
  editor which supports modulated syntax highlighting?
 
  Thank you,
  Blaine
 
 just a *few* examples

If I were to start a GUI editor project, I'd undoubtedly start by
looking at Scintilla:

http://www.scintilla.org/

Also see:
http://scintilla.sourceforge.net/ScintillaRelated.html

Regards,
Cliff
-- 

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

Re: What do you want in a new web framework?

[Cliff Wells]

On Wed, 2006-08-23 at 02:28 -0700, Paul Boddie wrote:
 Cliff Wells wrote:

  No, the reason Rails is successful is due to being a decent, focused
  product with *great* marketing (screencasts, anyone?).
 
 Screencasts? Perhaps, like a great showman, they draw in the punters
 effectively enough, but I'd rather developers concentrate on writing
 decent documentation than stuffing the pipes of the Internet up with
 multi-megabyte proprietary blobs showing some individual developing
 hello world (and still having to practise slight-of-hand in order to
 make it slick enough).

Well, I think screencasts are pretty great for this type of thing.
Think about the primary complaint: Which one do I choose?.  It can
take a while to wade through the various documentation (or lack of),
install, do some basic tests, etc and the whole process can be pretty
wearing on a newcomer.  A screencast on the other hand lets you lazily
sip coffee while you get a small feel for the framework.  I think it
also shows what someone who *knows* the framework can do (which can be
nearly impossible to know when you're testing it yourself).  The 20
minute wiki screencast would be the 2 day trial and error for someone
new to the framework. 

 
 [...]
 
  Also the fact that Ruby doesn't suck isn't hurting Rails any either.  If
  GvR wants to improve Python's status against Ruby, I suggest looking at
  what people are *really* raving about in the Ruby world (despite how
  they got there) and address those issues rather than getting sidetracked
  with this nonsense.
 
 First of all, I'd take the raving from the Ruby scene with a pinch of
 salt, given the tendency of the blog personalities doing the raving to
 breathlessly declare some kind of victory at every turn - as Steve
 Holden once said, these people are good at the don't mention the
 weaknesses style of marketing, and that's probably something various
 Python Web framework developers have picked up quite effectively. 

Oh sure.  And you have to also remind yourself that most of these guys
are coming from PHP where practically nothing sucks by comparison (and
there are *lots* of PHP people to convert).  

But there are interesting things in Ruby (and Ruby 2 should take care of
lots of warts Ruby 1.8 has) that Python could learn from.  All-in-all,
Ruby is mostly as good as Python in most ways and better than Python in
a couple key ways.  Add marketing to that (whatever kind it happens to
be) and you've got the recipe for success. 

When I suggest using Python to customers they tend to get nervous as if
it's some esoteric language that might disappear off the map next
weekend and is only known to 12 people.  I shouldn't need to reassure
people that it is what it is: one of the most popular languages in use
today.  That's the other kind of bad marketing that Python should avoid.

 I'd rather the Python core developers stopped chasing shadows and looked at
 the Python distribution in its entirety. Hopefully, the Python 3000
 exercise will see its focus shift into really removing the artifacts of
 legacy decisions in both the language and the library rather than
 shoehorning more wishlist items into the language.

My single wishlist item (which will probably never happen) is actually
the *removal* of a single feature: the distinction between statements
and expressions.  Forget list comprehensions, ternary operators, etc.
You get them with no additional syntax in expression-based languages.  I
played with Logix a bit (but sadly the project appears dead) and the
expression-based Python syntax it provides gives me goose-bumps.

At this point in my life, inertia keeps me with Python (it's good
enough and I lack the time and energy to convert to another language),
but there's little doubt in my mind that this distinction will
eventually force me elsewhere *wipes away tear*.  


Regards,
Cliff

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

Re: What do you want in a new web framework?

[Cliff Wells]

On Wed, 2006-08-23 at 22:13 +0200, Peter Maas wrote:
 Alex Martelli wrote:
  Indeed, it has been truthfully observed that Python's the only language
  with more web frameworks than keywords.
  
  I have already suggested to the BDFL that he can remedy this situation
  in Py3k: all he has to do, of course, is to add a LOT more keywords.
 
 Here is another remedy: he adds one of the frameworks to the standard
 library :)

That didn't help Tk maintain a monopoly on Python GUI toolkits.

Cliff

-- 

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

Re: What do you want in a new web framework?

[Cliff Wells]

On Thu, 2006-08-24 at 04:04 +, Tim Roberts wrote:
 Cliff Wells [EMAIL PROTECTED] wrote:
 
 But there are interesting things in Ruby (and Ruby 2 should take care of
 lots of warts Ruby 1.8 has) that Python could learn from.  All-in-all,
 Ruby is mostly as good as Python in most ways and better than Python in
 a couple key ways.
 
 ...but you can't READ Ruby code.  

Yeah, that's one of the big reasons I haven't seriously considered
trying it.  It's expressive, got interesting features... and appears
unreadable to me.  I'm usually pretty good at deciphering most
languages, even if I haven't used them before, but Ruby is one of the
exceptions.

 One of the things I like best about
 Python is that, like Cobol, you can read Python code like prose (or poetry
 ;) and, for the most part, know what the code does, even without being a
 Python guru.  I have not had the same experience with Ruby.  There are
 special characters in there that make the program say something I can't
 immediately discern.

There's the line noise aspect, but also some things are just expressed
in what appears (to me) to be rather non-idiomatic ways.  But I suppose
it depends on your background.  A rather brilliant friend of mine with a
Smalltalk background thinks that the Ruby reads like a novel. Shrug. He
also reads Japanese, so maybe that's a factor ;-)

 To be sure, people whose opinions I trust (one of whom is Cliff Wells) have
 said that Ruby is great, so I suppose I need to look again.  I just haven't
 had the same aha! experience that I had with Python.

Thanks for the vote of confidence. I have lots of opinions, but even I
only trust a few of them ;-)

I think Ruby has great things and I'm certain it's a great fit for many
people.  But I'm with you 100% on Python's readability.  I just wish we
could have the great things from both.

This brings us back around to the web framework debates.  For many
people Ruby fits their brains and for others Python does.  I think
frameworks are similar.  I tried Django and while I thought it was a
great product, it simply didn't fit how I think about that problem
domain.  TurboGears on the other hand did, and really, it helped clarify
a few things I had vague notions about.  I think we'll do better not
trying to shoehorn people into one or the other.

Regards,
Cliff
-- 

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

Re: What do you want in a new web framework?

[Cliff Wells]

On Tue, 2006-08-22 at 08:15 +, Tim Roberts wrote:

 Ordinarily, I think the do it yourself nature of Python is a great thing,
 and I would never try to dissuade someone from reinventing something
 themselves.  However, in the case of web frameworks, I believe Marc is
 fundamentally correct: the web framework proliferation in Python is
 actually doing the language a huge disservice.

I disagree.  Even if most of the frameworks end up being nothing more
than research artifacts, the fact is they embody research.  Without
research the Python web framework space will be forever relegated to
runner-up (and probably has-been at some point).

 Consider Ruby.  If someone asks, I'd like to do a web site with Ruby, what
 should I use?, the answer comes back loud, clear, and unanimous: Ruby on
 Rails.  

Or Wee. Or Nitro. Or Nemo. Or others that are surely to be written as
Ruby gains acceptance and experienced users capable of writing them.

 If someone asks, I'd like to do a web site with Python, what
 should I use?, she gets 25 different answers.  Look at HTMLGen, Cheetah,
 WebWare, CherryPy, Karrigell, Django, Pylons, Plone, Zope, TurboGears,
 etc., etc., none of which are pre-installed in the typical Linux
 distribution.  To the non-programming decision maker, that kind of response
 makes Python look unprofessional -- a toy.

Ruby on Rails doesn't come preinstalled either.  I don't think it's
appropriate (and apparently most Linux distros currently agree) to
install web programming frameworks by default.

I will add that at least a few distros offer TurboGears, Django and
Pylons as add-ons.

 Now, please do not send me ugly emails accusing me of running down Python.
 I've been a Python believer since 1.52.  I've done web sites in at least 5
 of the frameworks, and I even wrote one of the wiki pages that compares web
 frameworks.  However, it is only the fact that I *AM* a true Python
 believer that gave me the patience and incentive to try 5 different
 frameworks.  If a corporate decision maker were involved, that would never
 happen.  Python would simply fall off of the list of options, and the job
 would get done in PHP or Ruby on Rails.

Yes, because PHP has only one web framework too ;-)

 I agree with Marc.  PLEASE do not create yet another Python web
 framework.  Let's pick one, and join together to turn it into the One,
 True, Unquestioned Web Solution.

Yes, and for those of us who may not like your choice, we can move to
another language or write our own, so nothing will have changed.

I think the entire concept that Ruby on Rails is successful because it
happens to be the dominant solution on what was previously a practically
unknown language is just plain ridiculous. If that's the case then why
hasn't Eiffel taken over the world?  Or Lua?  Or Io?

No, the reason Rails is successful is due to being a decent, focused
product with *great* marketing (screencasts, anyone?).

We've had several good Python web frameworks for some time, but
practically zero marketing (except for Zope/Plone, which as it turns
out, weren't such great products, at least not for the 80% solution
that Rails targets).  

Also the fact that Ruby doesn't suck isn't hurting Rails any either.  If
GvR wants to improve Python's status against Ruby, I suggest looking at
what people are *really* raving about in the Ruby world (despite how
they got there) and address those issues rather than getting sidetracked
with this nonsense.  


Regards,
Cliff
-- 

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