[Python-Dev] Returned mail: Data format error

2005-02-03 Thread anthony
Your message was not delivered due to the following reason:

Your message could not be delivered because the destination computer was
unreachable within the allowed queue period. The amount of time
a message is queued before it is returned depends on local configura-
tion parameters.

Most likely there is a network problem that prevented delivery, but
it is also possible that the computer is turned off, or does not
have a mail system running right now.

Your message could not be delivered within 7 days:
Mail server 190.102.237.222 is not responding.

The following recipients could not receive this message:


Please reply to [EMAIL PROTECTED]
if you feel this message to be in error.

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] redux: fractional seconds in strptime

2005-02-03 Thread Skip Montanaro

Brett> Everyone went silent on this topic.  Does this mean people just
Brett> stopped caring (which I doubt since I know Skip wants this bad
Brett> enough to bring it up every so often)?  Was it the issue of
Brett> symmetry with strftime?

I have a patch to do strptime() fractional seconds, but stumbled on the
reverse direction (making strftime() accept fractional seconds).

I'll submit a patch with what I have later today.  I have to catch a train
just now.

Skip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Is msvcr71.dll re-redistributable?

2005-02-03 Thread Jack Jansen
On 3 Feb 2005, at 02:01, Phillip J. Eby wrote:
Sounds like this puts all Python users in the clear, since Python is 
the Licensee Software in that case.  So, anybody can distribute 
msvcr71 as "part of" Python.

OTOH, the other wording sounds like Python itself has to have a 
click-wrap, tear-open, or signature EULA!  IOW, the EULA appears to 
prohibit free distribution of the runtime with a program that has no 
EULA.

So, in an amusing turn of events, the EULA actually appears to forbid 
the current offering of Python for Windows, since it does not have 
such a EULA.
That was also my conclusion last year:-(
But at least Python can still be distributed without msvcr71, putting 
the burden of obtaining it on the end user, because of Python's 
license. In another project we're using GPL, and careful reading 
(disclaimer: IANAL) has not convinced me that GPL and the EULA are 
compatible. Actually, I have this vague feeling that the MSVC 7 EULA 
(plus the fact that MS isn't shipping msvcr71.dll with Windows) might 
have been drafted specifically to be incompatible with the clause in 
GPL that doesn't allow you to link against third party libraries unless 
they're part of the OS.

What we've done in that project is link with msvcr71.dll, but not 
include it in the installer. I think that we could (theoretically) 
still be dragged into court by the FSF, but at least not by Microsoft.
--
Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma 
Goldman

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


[Python-Dev] Wanted: members for Python Security Response Team

2005-02-03 Thread Guido van Rossum
If you read BugTraq, python-announce or the Daily Python URL today,
you would have noticed a Python Security Advisory. (If you missed it:
http://www.python.org/security/PSF-2005-001/ .)

This was the first one issued in this form, but I'm sure it won't be
the last one. Until now, we haven't had any infrastructure for this
type of thing. In this particular case, the original discoverer first
asked on c.l.py for advice on how to proceed, which yielded only
unhelpful referrals to SF or python-dev. Then he wrote the authors of
the affected module. Fredrik was so kind to forward it to me, and I
happened to have time to deal with it. (Hey, I work for a security
company, so I would have *made* time if I had to.)

But I may not always be that responsive -- I could be busy, or
traveling, or people might not think of mailing me. I believe it would
be better if there was a "response team" for such situations. The
response team would normally not have to do anything; they wouldn't
have to be actively looking for security bugs, for example. But anyone
with a (suspected) security problem related to Python would be able to
email the team (e.g. security at python.org), trusting that the
information would be kept confidential until a patch is developed; the
response team would then investigate the problem and decide on an
appropriate response.

I want to be on the team; Barry also works for a security company and
I hope he'll want to join (he can also make up a better acronym :-); I
hope at least one person from the release team can be involved, e.g.
Anthony; and I would like to see some more volunteers involved to have
a good spread of availability and expertise. (How about a Windows
user?) If you want to be on the team, send email to me *personally*.
For discussion about the team's responsibilities and procedures,
please follow up here.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Wanted: members for Python Security Response Team

2005-02-03 Thread Skip Montanaro

Guido> For discussion about the team's responsibilities and procedures,
Guido> please follow up here.

I noticed the checkins.  I think there is one other necessary output: source
patches against all the affected versions need to be made available so
people can apply the patch to an existing installed version without needing
to upgrade.

Skip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Wanted: members for Python Security Response Team

2005-02-03 Thread Guido van Rossum
> I noticed the checkins.  I think there is one other necessary output: source
> patches against all the affected versions need to be made available so
> people can apply the patch to an existing installed version without needing
> to upgrade.

Patches for 2.2, 2.3 and 2.4 are on the website
(python.org/security/PSF-2005-001/ has links). The module didn't exist
before 2.2.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


[Python-Dev] Re: Is msvcr71.dll re-redistributable?

2005-02-03 Thread Alexander Schremmer
On Tue, 01 Feb 2005 21:17:17 +0100, Thomas Heller wrote:

> The 2.4 python.org installer installs msvcr71.dll on the target system.
> 
> If someone uses py2exe or a similar tool to create a frozen application,
> is he allowed to redistribute this msvcr71.dll to other users together
> with his application or not, even if he doesn't own MSVC?

How about statically compiling the code? Then you do not need to distribute
the runtime library. It should not make a big difference for the rather
large file python24.dll

Kind regards,
Alexander

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Re: Is msvcr71.dll re-redistributable?

2005-02-03 Thread Thomas Heller
Alexander Schremmer <[EMAIL PROTECTED]> writes:

> On Tue, 01 Feb 2005 21:17:17 +0100, Thomas Heller wrote:
>
>> The 2.4 python.org installer installs msvcr71.dll on the target system.
>> 
>> If someone uses py2exe or a similar tool to create a frozen application,
>> is he allowed to redistribute this msvcr71.dll to other users together
>> with his application or not, even if he doesn't own MSVC?
>
> How about statically compiling the code? Then you do not need to distribute
> the runtime library. It should not make a big difference for the rather
> large file python24.dll

This would not work since each binary extension for Python 2.4 uses the
dll runtime lib.

Thomas

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


[Python-Dev] python-dev Summary for 2005-01-01 through 2005-01-15 [draft]

2005-02-03 Thread Brett C.
Wow, another summary out the same week as the previous one!  Perk of keeping 
things short and to the point.  Then again keeping them this simple and short 
begs the question of whether the summaries are worth it still at that point.

Regardless, probably will send this one out Saturday or Sunday so corrections 
need to get in by then.

-
=
Summary Announcements
=
PyCon_ will be upon us come late March!  Still time to plan to go.
A warning on the thoroughness off this summary is in order.  While trying to 
delete a single thread of email I managed to accidentally delete my entire 
python-dev mailbox.  I did the best I could to retrieve the emails but it's 
possible I didn't resuscitate all of my emails, so I may have overlooked something.

.. _PyCon: http://www.pycon.org/
===
Summary
===
-
PEP movements
-
.. tip:: PEP updates by email are available as a topic from the 
`Python-checkins`_ mailing list.

`PEP 246`_ was a major topic of discussion during the time period covered by 
this summary.  This all stemmed from `Guido's blog`_ entries on optional type 
checking. This led to a huge discussion on many aspects of protocols, 
interfaces, and adaptation and the broadening of this author's vocabulary to 
include "Liskov violation".

"Monkey typing" also became a new term to know thanks to Phillip J. Eby's 
proto-PEP on the topic (found at 
http://peak.telecommunity.com/DevCenter/MonkeyTyping).  Stemming from the 
phrase "monkey see, monkey do", it's Phillip version of taking PEP 246 
logically farther (I think; the whole thing is more than my currently 
burned-out-on-school brain can handle right now).

.. _Python-checkins: http://mail.python.org/mailman/listinfo/python-checkins
.. _PEP 246: http://www.python.org/peps/pep-0246.html
.. Guido's blog: http://www.artima.com/weblogs/index.jsp?blogger=guido
Contributing threads:
  - `getattr and __mro__ <>`__
  - `Son of PEP 246, redux <>`__
  - `PEP 246: lossless and stateless <>`__
  - `PEP 246: LiskovViolation as a name <>`__
  - `"Monkey Typing" pre-PEP, partial draft <>`__

Optional type checking: how to inadvertently cause a flame war worse than 
decorators

`Guido's blog`_ had comments on the idea of adding optional static type 
checking to Python.  While just comments in a blog, it caused a massive 
response from people, mostly negative from what I gathered.  After Guido 
discussed things some more it culminated in a blog entry found at 
http://www.artima.com/weblogs/viewpost.jsp?thread=87182 that lays out what his 
actual plans are.  I highly recommend reading it since it suggests adding 
optional run-time type checking for function arguments along with some other 
proposals.

All of this led to `PEP 246`_ getting updated.  For some more details on that 
see the `PEP movements`_ section of this summary.

And if there is a lesson to be learned from all of this, it's that when Alex 
Martelli and Phillip J. Eby start a technical discussion it's going to be long, 
in-depth, complex, and lead to my inbox being brimming in python-dev email.

--
Let's get the AST branch done!
--
Guido posted an email to the list stating he would like to to make progress 
towards integrating "things like type inferencing, integrating PyChecker, or 
optional static type checking" into Python.  In order to make that easier he 
put out a request that people work on the AST branch and finish it.

For those that don't know about Python's back-end, the compiler as it stands 
now takes the parse tree from the parser and emits bytecode directly from that. 
 This is far from optimal since the parse tree is more verbose than needed and 
it is not the easiest thing to work with.

The AST branch attempts to fix this by taking a more traditional approach to 
compiling.  This means the parse tree is used to generate an AST (abstract 
syntax tree; and even more technically could be considered a control flow graph 
in view of how it is implemented) which in turn is used to emit bytecode.  The 
AST itself is much easier to work with when compared to the parse tree; better 
to know you are working with an 'if' guard thanks to it being an 'if' node in 
the AST than checking if the parse tree statement you are working with starts 
with 'if' and ends with a ':'.

While all of this sounds great, the issue is the AST branch is not finished 
yet.  It is not entirely far off, but new features from 2.4 (decorators and 
generator expressions) need to be added along with more bug fixing and clean up.

This means the AST branch is going to get finished for 2.5 somehow.  But help 
is needed.  While the usual suspects who have previously contributed to the 
branch are hoping to finish

[Python-Dev] Weekly Python Patch/Bug Summary

2005-02-03 Thread Kurt B. Kaiser
Patch / Bug Summary
___

Patches :  284 open ( +4) /  2748 closed ( +1) /  3032 total ( +5)
Bugs:  804 open ( +1) /  4812 closed (+13) /  5616 total (+14)
RFE :  167 open ( +0) /   142 closed ( +1) /   309 total ( +1)

New / Reopened Patches
__

Patch for Lib/bsddb/__init__.py to work with modulefinder  (2005-01-31)
   http://python.org/sf/1112812  opened by  Tony Meyer

New tutorial tests in test_generators.py  (2005-01-31)
   http://python.org/sf/1113421  opened by  Francis Girard

Add SSL certificate validation  (2005-02-01)
   http://python.org/sf/1114345  opened by  James Eagan

support PY_LONGLONG in structmember  (2005-02-02)
   http://python.org/sf/1115086  opened by  Sam Rushing

Add SSL certificate validation  (2005-02-03)
   http://python.org/sf/1115631  opened by  James Eagan

Patches Closed
__

Make history recall a-cyclic  (2004-03-11)
   http://python.org/sf/914546  closed by  kbk

New / Reopened Bugs
___

Cannot ./configure on FC3 with gcc 3.4.2  (2005-01-26)
CLOSED http://python.org/sf/1110007  reopened by  liturgist

cgi.FieldStorage memory usage can spike in line-oriented ops  (2005-01-30)
   http://python.org/sf/1112549  opened by  Chris McDonough

patch 1079734 broke cgi.FieldStorage w/ multipart post req.  (2005-01-31)
   http://python.org/sf/1112856  opened by  Irmen de Jong

ioctl has problems on 64 bit machines  (2005-01-31)
   http://python.org/sf/1112949  opened by  Stephen Norris

move_file()'s return value when dry_run=1 unclear  (2005-01-31)
   http://python.org/sf/1112955  opened by  Eelis

Please add do-while guard to Py_DECREF etc.  (2005-01-31)
   http://python.org/sf/1113244  opened by  Richard Kettlewell

OSATerminology still semi-broken  (2005-01-31)
   http://python.org/sf/1113328  opened by  has

document {m} regex matcher wrt empty matches  (2005-01-31)
   http://python.org/sf/1113484  opened by  Wummel

keywords in keyword_arguments not possible  (2005-02-01)
CLOSED http://python.org/sf/1113984  opened by  Christoph Zwerschke

inicode.decode  (2005-02-01)
CLOSED http://python.org/sf/1114093  opened by  Manlio Perillo

copy.py bug  (2005-02-02)
   http://python.org/sf/1114776  opened by  Vincenzo Di Somma

webbrowser doesn't start default Gnome browser by default  (2005-02-02)
   http://python.org/sf/1114929  opened by  Jeremy Sanders

eval !  (2005-02-02)
CLOSED http://python.org/sf/1115039  opened by  Andrew Collier

Built-in compile function with PEP 0263 encoding bug  (2005-02-03)
   http://python.org/sf/1115379  opened by  Christoph Zwerschke

os.path.splitext don't handle unix hidden file correctly  (2005-02-04)
   http://python.org/sf/1115886  opened by  Jeong-Min Lee

Bugs Closed
___

broken link in tkinter docs  (2005-01-24)
   http://python.org/sf/1108490  closed by  jlgijsbers

recursion core dumps  (2005-01-26)
   http://python.org/sf/1110055  closed by  tim_one

install_lib fails under Python 2.1  (2004-11-02)
   http://python.org/sf/1058960  closed by  loewis

Double __init__.py executing  (2004-06-22)
   http://python.org/sf/977250  closed by  loewis

Cannot ./configure on FC3 with gcc 3.4.2  (2005-01-26)
   http://python.org/sf/1110007  closed by  liturgist

IDLE hangs due to subprocess  (2004-12-28)
   http://python.org/sf/1092225  closed by  kbk

Empty curses module is loaded in win32  (2004-07-12)
   http://python.org/sf/989333  closed by  tebeka

Tab / Space Configuration Does Not Work in IDLE  (2003-08-05)
   http://python.org/sf/783887  closed by  kbk

Negative numbers to os.read() cause segfault  (2004-12-01)
   http://python.org/sf/1077106  closed by  mwh

Time module missing from latest module index  (2005-01-25)
   http://python.org/sf/1109523  closed by  montanaro

keywords in keyword_arguments not possible  (2005-02-01)
   http://python.org/sf/1113984  closed by  rhettinger

unicode.decode  (2005-02-01)
   http://python.org/sf/1114093  closed by  lemburg

eval !  (2005-02-02)
   http://python.org/sf/1115039  closed by  rhettinger

New / Reopened RFE
__

All Statements Should Have Return Values (Syntax Proposal)  (2005-02-01)
CLOSED http://python.org/sf/1114404  opened by  Lenny Domnitser

RFE Closed
__

All Statements Should Have Return Values (Syntax Proposal)  (2005-02-01)
   http://python.org/sf/1114404  closed by  goodger

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com