Re: [Python-Dev] Python Grammar Ambiguity

[Christos Georgiou]

"Michael Foord" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]

> It worries me that there might be a valid expression allowed here that I
> haven't thought of. My current rules allow anything that looks like
> ``(a, [b, c, (d, e)], f)`` - any  nested identifier list. Would anything
> else be allowed ?

Anything that goes in the left hand side of an assignment:

# example 1
>>> a=[1,2]
>>> for a[0] in xrange(10): pass

# example 2
>>> class A(object): pass

>>> a=A()
>>> for a.x in xrange(10): pass


___
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] 2.5 open issues

[Thomas Heller]

Neal Norwitz wrote:
> If you are addressed on this message, it means you have open issues
> that need to be resolved for 2.5.  Some of these issues are
> documentation, others are code issues.

> Documentation missing:
> +++
> Fredrik: ElementTree
> Gerhard: pysqlite
> Martin: msilib
> Thomas: ctypes
> 
> Thomas, I know you checked in some ctypes docs.  Is that everything or
> is there more coming?  It seemed pretty short given the size of
> ctypes.
> 
> If you don't expect to have time to finish these tasks, then it's your
> job to find someone else who will.

I was fearing it is getting too long.  How many pages do you expect or will you
tolerate (yes, this is a serious question)?

I could imaging three parts of the ctypes docs:

1. The tutorial, which is already checked in.

2. A reference manual, listing all the available functions and types (it will
probably duplicate a lot of what is in the tutorial).

3. Some articles/howtos which cover advanced issues.

I have the start of a reference manual, which is about 12 pages now.  
Incomplete, some sections
are not yet or no longer correct, but you can take a look at it here:

http://starship.python.net/crew/theller/manual/manual.html

This could be completed and committed into SVN soon.

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] rest2latex - was: Re: Raising objections

[Gerhard Häring]

Thomas Heller wrote:
> [...] I'm now happy with the tool that converts the ctypes tutorial from reST 
> to LaTeX,
> I will later (today or tomorrow) commit that into Python SVN.

Did you commit that already? Alternatively, can you send it to me, please?

-- Gerhard
___
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] rest2latex - was: Re: Raising objections

[Thomas Heller]

Gerhard Häring wrote:
> Thomas Heller wrote:
>> [...] I'm now happy with the tool that converts the ctypes tutorial 
>> from reST to LaTeX,
>> I will later (today or tomorrow) commit that into Python SVN.
> 
> Did you commit that already? Alternatively, can you send it to me, please?
> 
> -- Gerhard

I meant the ctypes tutorial in latex format, not the tool itself.

Anyway, the tool is mkydoc.py, in combination with missing.py:

http://svn.python.org/view/external/ctypes-0.9.9.6/docs/manual/

I'm not sure it is ready for public consumption ;-).

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

Re: [Python-Dev] rest2latex - was: Re: Raising objections

[engelbert . gruber]

On Fri, 28 Apr 2006, Thomas Heller wrote:


Gerhard Häring wrote:

Thomas Heller wrote:

[...] I'm now happy with the tool that converts the ctypes tutorial
from reST to LaTeX,
I will later (today or tomorrow) commit that into Python SVN.


Did you commit that already? Alternatively, can you send it to me, please?

-- Gerhard


I meant the ctypes tutorial in latex format, not the tool itself.

Anyway, the tool is mkydoc.py, in combination with missing.py:

http://svn.python.org/view/external/ctypes-0.9.9.6/docs/manual/

I'm not sure it is ready for public consumption ;-).


from what i saw it is not, because paths are hardcoded, but aside from 
this it should be usable and i am willing to take it up and into docutils, 
but this requires feedback


cheers
--___
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] 2.5 open issues

[A.M. Kuchling]

On Fri, Apr 28, 2006 at 10:27:45AM +0200, Thomas Heller wrote:
> I could imagine three parts of the ctypes docs:
  ...
> 3. Some articles/howtos which cover advanced issues.

Note that there's now a Doc/howto directory, so you could put articles
there.  The howtos aren't built as part of the documentation set, but
maybe we should work on fixing that.  

Also note that one existing howto is in reST, the first use of reST in
the Python docs.  So integrating the howtos will mean supporting reST,
and you can therefore write howtos in reST if that's convenient.

--amk

___
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] 2.5 open issues

[A.M. Kuchling]

On Thu, Apr 27, 2006 at 10:58:49PM -0700, Neal Norwitz wrote:
> If you are addressed on this message, it means you have open issues
> that need to be resolved for 2.5.  Some of these issues are
> documentation, others are code issues.  This information comes from
> PEP 356.

There are also these items in the 'possible features' section:

Modules under consideration for inclusion:

  - bdist_deb in distutils package
(Owner: ???)
http://mail.python.org/pipermail/python-dev/2006-February/060926.html

  - wsgiref to the standard library
(Owner: Phillip Eby)

  - pure python pgen module
(Owner: Guido)

  - Support for building "fat" Mac binaries (Intel and PPC)
(Owner: Ronald Oussoren)


wsgiref is the most important one, I think.  If there's anything I can
do to help, please let me know.

--amk
___
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] Is this a bad idea: picky floats?

[skip]

>From a numerical standpoint, floats shouldn't generally be compared using
equality.  I came across a bug at work yesterday where I had written:

if not delta:
return 0.0

where delta was a floating point number.  After a series of calculations
piling up round-off error delta took on a value on the order of 1e-8.  Not
zero, but it should have been.  The fix was easy enough:

if abs(delta) < EPSILON:
return 0.0

for a suitable value of EPSILON.

That got me to thinking...  I'm sure I have plenty of other similar mistakes
in my code.  (Never was much of a numerical analysis guy...)  What if there
was a picky-float setting that generated warnings if you compared two floats
using "==" (or implicitly using "not")?  Does that make sense to try for
testing purposes?  The implementation seemed straightforward enough:

http://python.org/sf/1478364

I'm sure at the very least the idea needs more thought than I've given it.
It's just a half-baked idea at this point.

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] 2.5 open issues

[Guido van Rossum]

On 4/28/06, A.M. Kuchling <[EMAIL PROTECTED]> wrote:
> There are also these items in the 'possible features' section:
> 
> Modules under consideration for inclusion:
>
>   - bdist_deb in distutils package
> (Owner: ???)
> http://mail.python.org/pipermail/python-dev/2006-February/060926.html

Isn't that MvL?

>   - wsgiref to the standard library
> (Owner: Phillip Eby)

I still hope this can go in; it will help web framework authors do the
right thing long term.

>   - pure python pgen module
> (Owner: Guido)

I'm withdrawing this for 2.5 and resubmitting it to 2.6; I have no
time to clean it up. I know it is possible using this code to create a
Python source-to-bytecode compiler in pure Python (using tokenizer.py
for the lexer and the compiler package as the bytecode generator, and
accepting the latter's imperfections) but few people have that need
and those that do can download it from SF.

>   - Support for building "fat" Mac binaries (Intel and PPC)
> (Owner: Ronald Oussoren)

Yes, this would be cool.

> wsgiref is the most important one, I think.  If there's anything I can
> do to help, please let me know.

--
--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] 2.5 open issues

[Phillip J. Eby]

At 07:38 AM 4/28/2006 -0700, Guido van Rossum wrote:
>On 4/28/06, A.M. Kuchling <[EMAIL PROTECTED]> wrote:
> >   - wsgiref to the standard library
> > (Owner: Phillip Eby)
>
>I still hope this can go in; it will help web framework authors do the
>right thing long term.

I doubt I'll have time to write documentation for it before alpha 3.  If 
it's okay for the docs to wait for one of the beta releases -- or better 
yet, if someone could volunteer to create rough draft documentation that I 
could just then edit --  then it shouldn't be a problem getting it in and 
integrated.

However, just to avoid the sort of thing that happened with setuptools, I 
would suggest, Guido, that you make a last call for objections on the 
Web-SIG, which has previously voiced more criticism of wsgiref than the 
Distutils-SIG ever had about setuptools.  Granted, most of the Web-SIG 
comments were essentially feature requests, but some complained about the 
presence of the handler framework.  Anyway, after the setuptools flap I'm a 
little shy of checking in a new library without a little more visible 
process.  :)

___
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] Dropping __init__.py requirement for subpackages

[Thomas Heller]

Thomas Wouters wrote:
> On 4/27/06, Thomas Wouters <[EMAIL PROTECTED]> wrote:
>> Alrighty then. The list has about 12 hours to convince me (and you) that
>> it's a bad idea to generate that warning. I'll be asleep by the time the
>> trunk un-freezes, and I have a string of early meetings tomorrow. I'll get
>> to it somewhere in the afternoon :)
>>
> 
> I could check it in, except the make-testall I ran overnight showed a small
> problem: the patch would generate a number of spurious warnings in the
> trunk:
> 
> /home/thomas/python/python/trunk/Lib/gzip.py:9: ImportWarning: Not importing
> directory '/home/thomas/python/python/trunk/Modules/zlib': missing
> __init__.py
> 
> /home/thomas/python/python/trunk/Lib/ctypes/__init__.py:8: ImportWarning:
> Not importing directory '/home/thomas/python/python/trunk/Modules/_ctypes':
> missing __init__.py
> 
> (and a few more zlib ones.) The reason for that is that ./Modules is added
> to the import path, by a non-installed Python. This is because of the
> pre-distutils Modules/Setup-style build method of modules (which is still
> sometimes used.) I can't find where Modules is added to sys.path, though,
> even if I wanted to remove it :)
> 
> So, do we:
>  a) forget about the warning because of the layout of the svn tree (bad,
> imho)
>  2) rename Modules/zlib and Modules/_ctypes to avoid the warning
> (inconvenient, but I don't know how inconvenient)
>  - fix the build procedure so Modules isn't added to sys.path unless it
> absolutely has to (which is only very rarely the case, I believe)
>  or lastly, make regrtest.py ignore those specific warnings?

Would not another way be to make sure Modules is moved *behind* the
setup.py build directory on sys.path?

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

Re: [Python-Dev] 2.5 open issues

[Martin v. Löwis]

Neal Norwitz wrote:
> Who is the owner for getting new icons installed with the new logo?

Nobody, so far (for Windows). Somebody should contact the owner and
find out what the license on this work is, and then tell me what
to do with them. I assume the py and pyc icons are to be replaced, and I
also assume the Vista icons are to be ignored, but what about the
other(s)?

For the OSX icons, I guess Ronald Oussoren owns the task of getting
them into the distribution.

> Fred, Fredrik, Martin:  xmlplus/xmlcore situation re: ElementTree

I still hope Fred could make progress; I had no time to look into
this further, so far.

> Documentation missing:
> +++
> Fredrik: ElementTree
> Gerhard: pysqlite
> Martin: msilib
> Thomas: ctypes
> 

msilib is on my agenda, but I might not be able to work for it in
the next weeks.

Regards,
Martin

___
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] rest2latex - was: Re: Raising objections

[Thomas Heller]

[EMAIL PROTECTED] wrote:
> On Fri, 28 Apr 2006, Thomas Heller wrote:
> 
>> Gerhard Häring wrote:
>>> Thomas Heller wrote:
 [...] I'm now happy with the tool that converts the ctypes tutorial
 from reST to LaTeX,
 I will later (today or tomorrow) commit that into Python SVN.
>>>
>>> Did you commit that already? Alternatively, can you send it to me, 
>>> please?
>>>
>>> -- Gerhard
>>
>> I meant the ctypes tutorial in latex format, not the tool itself.
>>
>> Anyway, the tool is mkydoc.py, in combination with missing.py:
>>
>> http://svn.python.org/view/external/ctypes-0.9.9.6/docs/manual/
>>
>> I'm not sure it is ready for public consumption ;-).
> 
> from what i saw it is not, because paths are hardcoded,

Sure, but it should only require some small changes to adapt it to
other rest sources.

> but aside from 
> this it should be usable and i am willing to take it up and into 
> docutils, but this requires feedback

I must work on the docs themselves, so I currently have only two things:

- the table in the ctypes tutorial has a totally different look than the other
  tables in the docs.  Compare
http://docs.python.org/dev/lib/ctypes-simple-data-types.html
  with
http://docs.python.org/dev/lib/module-struct.html

- feature request: it would be very nice if it were possible to generate links
into the index for functions and types from the rest sources.


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

Re: [Python-Dev] 2.5 open issues

[Martin v. Löwis]

Thomas Heller wrote:
> I was fearing it is getting too long.  How many pages do you expect
> or will you tolerate (yes, this is a serious question)?

I don't think there should be a page limit to documentation. If it is
structured into sections, then size simply doesn't matter on the Web:
people can easily skip over it / ignore it if they want to. It only
matters for the size of the distribution, but only slightly so: I doubt
it contributes significantly to the size of the whole distribution.

> 2. A reference manual, listing all the available functions and types
> (it will probably duplicate a lot of what is in the tutorial).

I would feel that this is a must-have document, and completeness is
certainly a goal here. Now, if certain parts are still undocumented,
I wouldn't make creation of this documentation a release requirement,
but text that already exists should be included.

> 3. Some articles/howtos which cover advanced issues.

I don't think they are necessary; if Andrew thinks the howto
section would be a good place, I don't mind.

> I have the start of a reference manual, which is about 12 pages now.
> Incomplete, some sections are not yet or no longer correct, but you
> can take a look at it here:
> 
> http://starship.python.net/crew/theller/manual/manual.html
> 
> This could be completed and committed into SVN soon.

Looks good to me.

Martin
___
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] Dropping __init__.py requirement for subpackages

[Thomas Wouters]

On 4/28/06, Thomas Heller <[EMAIL PROTECTED]> wrote:
Would not another way be to make sure Modules is moved *behind* thesetup.py build directory on sys.path?Indeed! I hadn't realized that, although I might've if I'd been able to find where Modules is put on 
sys.path. And, likewise, I would do as you suggest (which feels like the right thing) if I could only find out where Modules is put on sys.path :) I don't have time to search for it today nor, probably, this weekend (which is a party weekend in the Netherlands.) I'll get to it eventually, although a helpful hint from an old-timer who remembers as far back as Modules/Setup would be welcome. :)
-- Thomas Wouters <[EMAIL PROTECTED]>Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
___
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] 2.5 open issues

[Martin v. Löwis]

Guido van Rossum wrote:
>>   - bdist_deb in distutils package
>> (Owner: ???)
>> http://mail.python.org/pipermail/python-dev/2006-February/060926.html
> 
> Isn't that MvL?

I spoke in favour of including it, but don't recall ever to committing
as a "sponsor/second" of including it (and I certainly didn't write it).

I can't find a patch for bdist_deb right now, so if nobody steps forward
 with actual code to include, this gets probably dropped from 2.5. Notice
that the URL quoted actually speaks against a bdist_deb command.


>>   - Support for building "fat" Mac binaries (Intel and PPC)
>> (Owner: Ronald Oussoren)
> 
> Yes, this would be cool.

This is nearly committed. For some reason, SF apparently dropped
my last change request for it, and Ronald's patch responding
to this request, so it barely missed 2.5a2. Regardless, I guess
Ronald will release his 2.5a2 binaries in the fat form.

For those interested, one surprising (for me) challenge in this
is that WORDS_BIGENDIAN can't be a configure-time constant
anymore. It doesn't need to be a run-time thing, either, because
at run-time, you know the endianness of the (current) processor.

It isn't configure-time constant, because each individual
gcc invocations runs *two* compiler passes (cc1) and *two*
assemblers, which incidentally have different endiannesses.

So WORDS_BIGENDIAN now must be a compile-time constant;
fortunately, gcc defines either __BIG_ENDIAN__ or __LITTLE_ENDIAN__,
depending on whether it is the PPC cc1 or the x86 cc1 that runs.

To make this work with autoconf on systems which don't
define either of these constants, pyconfig.h.in now has
a block that derives WORDS_BIGENDIAN from __(BIG|LITTLE)_ENDIAN__
if they are defined, and makes it configure-time otherwise.

So in short: WORDS_BIGENDIAN will always be right, and
will have two different values in a fat binary.

Regards,
Martin
___
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] 2.5 open issues

[A.M. Kuchling]

On Fri, Apr 28, 2006 at 11:02:07AM -0400, Phillip J. Eby wrote:
> I doubt I'll have time to write documentation for it before alpha 3.  If 
> it's okay for the docs to wait for one of the beta releases -- or better 
> yet, if someone could volunteer to create rough draft documentation that I 
> could just then edit --  then it shouldn't be a problem getting it in and 
> integrated.

Barring some radical new thing in alpha3, the heavy lifting of the
"What's New" is done so I'm available to help with documentation.
(The functional programming howto can wait a little while longer.)  I
assume all we need is the module-level docs for the LibRef?

So, what's the scope of the proposed addition?  Everything in the
wsgiref package, including the simple_server module?

> However, just to avoid the sort of thing that happened with setuptools, I 
> would suggest, Guido, that you make a last call for objections on the 
> Web-SIG ...

Agreed.  Guido, another suggestion: an Artima weblog post about the
proposal, so that blog commentators notice it.

--amk
___
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] Dropping __init__.py requirement for subpackages

[Martin v. Löwis]

Thomas Wouters wrote:
> Indeed! I hadn't realized that, although I might've if I'd been able to
> find where Modules is put on sys.path. And, likewise, I would do as you
> suggest (which feels like the right thing) if I could only find out
> where Modules is put on sys.path :) I don't have time to search for it
> today nor, probably, this weekend (which is a party weekend in the
> Netherlands.) I'll get to it eventually, although a helpful hint from an
> old-timer who remembers as far back as Modules/Setup would be welcome. :)

With some debugging, I found it out: search_for_exec_prefix looks for
the presence of Modules/Setup; if that is found, it strips off /Setup,
leaving search_for_exec_prefix with -1. This then gets added to sys.path
with

/* Finally, on goes the directory for dynamic-load modules */
strcat(buf, exec_prefix);

I wasn't following exactly, so I might have mixed something up, but...
it appears that this problem here comes from site.py adding the
build directory for the distutils dynamic objects even after
Modules. The site.py code is

# XXX This should not be part of site.py, since it is needed even when
# using the -S option for Python.  See http://www.python.org/sf/586680
def addbuilddir():
"""Append ./build/lib. in case we're running in the build dir
(especially for Guido :-)"""
from distutils.util import get_platform
s = "build/lib.%s-%.3s" % (get_platform(), sys.version)
s = os.path.join(os.path.dirname(sys.path[-1]), s)
sys.path.append(s)

I would suggest fixing #586680: Add build/lib.* before adding
dynamic-load modules, by moving the code into Modules/getpath.c.
You should be able to use efound < 0 as an indication that this
is indeed the build directory.

Regards,
Martin
___
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] Internal documentation for egg formats now available

[M.-A. Lemburg]

Phillip J. Eby wrote:
> At 09:54 PM 4/27/2006 +0200, M.-A. Lemburg wrote:
>> Note that I was talking about the .pth file being
>> writable, not the directory.
> 
> Please stop this vague, handwaving FUD.  You have yet to explain how this 
> situation is supposed to arise.  Is there some platform on which files with 
> a .pth extension are automatically writable by users *when .py files are 
> not also*?
> 
> If not, then you are talking out of your... um, hat.  If files are writable 
> by other users by default, then .py files are too.  Once again: *no new 
> vector*.
> 
>> Even if they are not
>> writable by non-admins, the .pth files can point
>> to directories which are.
> 
> Uh huh.  And how does that happen, exactly?  Um, the user puts them 
> there?  What is your point, exactly?  That people can do things insecurely 
> if they're allowed near a computer?

You don't seem to want to see the problem:

By modifying site.py to take .pth files on all directories
in PYTHONPATH into account, you extend the possibility to
add "symbolic" links to a lot more directories than those
which are normally monitored by the sysadmin.

Every entry in a .pth file is added to sys.path, it even
allows imports to happen at .pth file scanning time.

A single malicious .pth file on PYTHONPATH could trick
the user into running Python modules that he isn't really
aware of.

Adding directories to PYTHONPATH which are writable by
others is easy, just add '/tmp' as entry in some .pth
file. Then put e.g. a modified os.py into /tmp and have
it execute 'rm -rf /' at import time.

In summary: I don't think that allowing .pth files on all
PYTHONPATH directories is the right way to go.

In order to solve your problem with users not being able to
install user local copies of packages, we should instead
discuss the possibility of having a standard directory
on PYTHONPATH that is being searched for such packages
and then allow .pth files only in that directory (which
is under user control).

Please consider discussing such things on python-dev before
implementing a hack that works around standard Python
behavior.

>> Here's a HOWTO to optimize startup time, without loosing
>> convenience:
> 
> I meant, a HOWTO for setuptools users who care about this, although at the 
> moment I have heard only from one -- and you're not, AFAIK, actually a 
> setuptools user.

You asked for a HOWTO, I gave you one :-)

I have played with setuptools and it lots of interesting
things, most of which are great and I applaud you for
taking the effort in creating the tool.

However, as you know, I do have a few issues with it that I'd like
to see  resolved, which is why I keep trying to convince you of
considering them (ever since you started in 2004 with this).

>> No, I'm talking about a format which has the same if not
>> more benefits as what you're trying to achieve with the
>> .egg file approach, but without all the magic and hacks.
>>
>> It's not like this wouldn't be possible to achieve.
> 
> That may or may not be true.  Perhaps if you had participated in the 
> original call to the distutils-sig for developing such a format (back in 
> December 2004), perhaps the design would've been more to your liking.
> 
> Oh wait...  you did:
> 
> http://mail.python.org/pipermail/distutils-sig/2004-December/004351.html

Indeed. And I suggested that you reconsider the idea to
use ZIP files for installation (rather than just distribution):

http://mail.python.org/pipermail/distutils-sig/2004-December/004349.html

> And if you replace 'syspathtools.use()' in that email, with 
> 'pkg_resources.require()', then it describes *exactly how setuptools 
> works  with .egg directories today*.

Interesting that you used that idea, because back then you didn't
reply to the email. Looks like I deserve some credit ;-)

If you've already implemented this (which I wasn't aware of, since
when I played with setuptools it kept installing .egg ZIP files),
then why don't you make .egg *directories* the standard installation
scheme, instead of insisting on having .egg ZIP files in
site-packages/ ?

I've now played with it again and found that for some
packages (e.g. kid and Paste) it installs these as .egg
directories (horray!).

For other packages such as elementtree which are not available
as egg files, it still creates egg files (by first downloading the
source package, then creating an egg file and installing that).

It also uses the egg files for quite a few packages that are
distributed as egg files.

So far, I've not found a pattern to this.

I wonder why you don't always create .egg directories.

> Apparently, you hadn't yet thought of any the objections that you are now 
> raising to *the very scheme that you yourself proposed*, until somebody 
> else took the trouble to actually implement it.

Where am I doing that ?

> And now you want to say that I never listen to or implement your 
> proposals?  Please.  Your email is the first documentation on record of how 
> this system w

Re: [Python-Dev] 2.5 open issues

[Phillip J. Eby]

At 11:54 AM 4/28/2006 -0400, A.M. Kuchling wrote:
>On Fri, Apr 28, 2006 at 11:02:07AM -0400, Phillip J. Eby wrote:
> > I doubt I'll have time to write documentation for it before alpha 3.  If
> > it's okay for the docs to wait for one of the beta releases -- or better
> > yet, if someone could volunteer to create rough draft documentation that I
> > could just then edit --  then it shouldn't be a problem getting it in and
> > integrated.
>
>Barring some radical new thing in alpha3, the heavy lifting of the
>"What's New" is done so I'm available to help with documentation.
>(The functional programming howto can wait a little while longer.)  I
>assume all we need is the module-level docs for the LibRef?
>
>So, what's the scope of the proposed addition?  Everything in the
>wsgiref package, including the simple_server module?

Yes.  simple_server is, coincidentally, the most controversial point on the 
Web-SIG, in that some argue for including a "better" web server.  However, 
nobody has come forth and said, "Here's my web server, it's stable and I 
want to put it in the stdlib", so the discussion wound down in general 
vagueness the last time it was brought up.

___
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] Internal documentation for egg formats now available

[M.-A. Lemburg]

M.-A. Lemburg wrote:
>>> No, I'm talking about a format which has the same if not
>>> more benefits as what you're trying to achieve with the
>>> .egg file approach, but without all the magic and hacks.
>>>
>>> It's not like this wouldn't be possible to achieve.
>> That may or may not be true.  Perhaps if you had participated in the 
>> original call to the distutils-sig for developing such a format (back in 
>> December 2004), perhaps the design would've been more to your liking.
>>
>> Oh wait...  you did:
>>
>> http://mail.python.org/pipermail/distutils-sig/2004-December/004351.html
> 
> Indeed. And I suggested that you reconsider the idea to
> use ZIP files for installation (rather than just distribution):
> 
> http://mail.python.org/pipermail/distutils-sig/2004-December/004349.html
> 
>> And if you replace 'syspathtools.use()' in that email, with 
>> 'pkg_resources.require()', then it describes *exactly how setuptools 
>> works  with .egg directories today*.
> 
> Interesting that you used that idea, because back then you didn't
> reply to the email. Looks like I deserve some credit ;-)
> 
> If you've already implemented this (which I wasn't aware of, since
> when I played with setuptools it kept installing .egg ZIP files),
> then why don't you make .egg *directories* the standard installation
> scheme, instead of insisting on having .egg ZIP files in
> site-packages/ ?
> 
> I've now played with it again and found that for some
> packages (e.g. kid and Paste) it installs these as .egg
> directories (horray!).
> 
> For other packages such as elementtree which are not available
> as egg files, it still creates egg files (by first downloading the
> source package, then creating an egg file and installing that).
> 
> It also uses the egg files for quite a few packages that are
> distributed as egg files.
> 
> So far, I've not found a pattern to this.
>

> I wonder why you don't always create .egg directories.

I've now found this section in the documentation which seems to
have the reason:

http://peak.telecommunity.com/DevCenter/EasyInstall#compressed-installation

Apart from the statement "because Python processes zipfile entries on
sys.path much faster than it does directories." being wrong,
it looks like all you'd have to do, is make --always-unzip the
default.

Another nit which seems to have been introduced in 0.6a11:
you now prepend egg directory entries to other sys.path entries,
instead of appending them.

What's the reason for that ?

Egg directory should really be treated just like any other
site-package package and not be allowed to override stdlib
modules and packages without explicit user action by
e.g. adjusting PYTHONPATH.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Apr 28 2006)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/


::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! 
___
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] 2.5 open issues

[Ronald Oussoren]

On 28-apr-2006, at 17:07, Martin v. Löwis wrote:

> Neal Norwitz wrote:
>> Who is the owner for getting new icons installed with the new logo?
>
> For the OSX icons, I guess Ronald Oussoren owns the task of getting
> them into the distribution.

That's fine by me. I'll be adding them to the universal python 2.4  
tree soon and to 2.5 when that's is done. Do have to wait for the  
contributor agreement, which the folks over at [EMAIL PROTECTED] say is  
good enough, to do that?

Ronald
___
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] 2.5 open issues

[Ronald Oussoren]

On 28-apr-2006, at 17:41, Martin v. Löwis wrote:

>
>
>>>   - Support for building "fat" Mac binaries (Intel and PPC)
>>> (Owner: Ronald Oussoren)
>>
>> Yes, this would be cool.
>
> This is nearly committed. For some reason, SF apparently dropped
> my last change request for it, and Ronald's patch responding
> to this request, so it barely missed 2.5a2. Regardless, I guess
> Ronald will release his 2.5a2 binaries in the fat form.

I hope this isn't a bad omen for this feature ;-). I've also had
to resubmit one of my changes to this tracker item because SF dropped  
it.

My 2.5a2 build will include this patch and will be a fat binary.

Ronald
___
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] 2.5 open issues

[Martin v. Löwis]

Ronald Oussoren wrote:
> That's fine by me. I'll be adding them to the universal python 2.4  
> tree soon and to 2.5 when that's is done. Do have to wait for the  
> contributor agreement, which the folks over at [EMAIL PROTECTED] say is  
> good enough, to do that?

If the artist has informally agreed to do that (so it is just the
formal signing that takes time), go ahead.

Regards,
Martin
___
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] Internal documentation for egg formats now available

[Phillip J. Eby]

At 06:20 PM 4/28/2006 +0200, M.-A. Lemburg wrote:
>A single malicious .pth file on PYTHONPATH could trick
>the user into running Python modules that he isn't really
>aware of.
>
>Adding directories to PYTHONPATH which are writable by
>others is easy, just add '/tmp' as entry in some .pth
>file. Then put e.g. a modified os.py into /tmp and have
>it execute 'rm -rf /' at import time.

You still haven't explained *how* these malicious .pth files or entries 
come into being *without the user's permission*.  How does this malicious 
user get write access to the .pth file to put /tmp into it?  Whatever your 
answer is, *that* is the security hole, not the existence of usable .pth files.

So this is still just handwaving and FUD.


> > And if you replace 'syspathtools.use()' in that email, with
> > 'pkg_resources.require()', then it describes *exactly how setuptools
> > works  with .egg directories today*.
>
>Interesting that you used that idea, because back then you didn't
>reply to the email. Looks like I deserve some credit ;-)

In truth, I completely forgot about that post and only rediscovered it 
yesterday.  When Bob and I were doing the initial design, he said he 
thought that the naively-unzipped form of an egg should be usable as-is, 
and I agreed that it made sense to do that.


>If you've already implemented this (which I wasn't aware of, since
>when I played with setuptools it kept installing .egg ZIP files),

See the --always-unzip option to easy_install, which has been there since 
0.5a9 -- i.e., since July 2005.  Package authors can also mark their 
packages "zip_safe=False" to force it to be installed unzipped (unless the 
user forces it to be zipped using --zip-ok).


>then why don't you make .egg *directories* the standard installation
>scheme, instead of insisting on having .egg ZIP files in
>site-packages/ ?

Because zip files add *less* import overhead over the life of a program 
(even a relatively short program) than directories do!

(Which, by the way, I believe I've explained to you on the distutils-SIG on 
more than one occasion, during some of the previous N times you brought 
this up.)


>I wonder why you don't always create .egg directories.

Performance, plain and simple.

What you *should* be benchmarking when you test performance impact, is 
twenty directories at the front of sys.path vs. twenty zipfiles at the 
front, both for "python -c pass" and for a program that does a few stdlib 
imports.  That will show you why EasyInstall never unzips eggs if it can 
help it.


>* I am against using ZIP as medium for package installation.

Then add this to your distutils.cfg or ~/.pydistutils.cfg and be happy 
forevermore:

[easy_install]
always_unzip = 1

If, however, you mean that you want *everyone else* to do as you prefer, 
forget about it, 'cause it's not going to happen.  You aren't setuptools' 
target user, so the defaults aren't going to be catering to your prejudices 
-- especially not the ones based on ignorance, like this one.


>* I am against using standard distutils commands to mean
>   different things depending on which set of packages you
>   have installed (in this case the "install" command)

And as I just pointed out, you've failed to show that there is any 
practical purpose to this.  I've already made the behavior an option, and 
it's the default behavior when you use --root.  You haven't shown any 
actual use case for it being the default behavior, and practicality beats 
purity.  What's more, you said you don't want the option to make it the 
default behavior for you.  Which means that this is only about you deciding 
what is "right" for *other* people than you to have, so I don't see any 
reason to consider that subject any further.  If other people want that 
behavior, they can certainly speak up for themselves about what *actual* 
(not hypothetical) problems it creates for them.  (And when they do speak 
up, as some system packagers did, I made --root enable the old behavior and 
that addressed the *actual* problems the new behavior created for that 
audience.)


>Phillip, you're always side-stepping answering questions
>(and cutting away quoted email text doesn't help either).

Repeating arguments I've already shown to be spurious helps even less.  I 
don't see much point to chasing red herrings and straw men, either.


>You should be aware that both package authors and users
>are capable of learning and adapting.

Then they can certainly adapt to "install" doing the right thing for most 
users and most packages: to install things in such a way that they can be 
uninstalled or upgraded cleanly, by default.


>If we tell package authors to put a link to their eggs on
>PyPI along with an MD5 sum, then the users be in a much
>better position and could feel more secure about what they
>download and install.

People who want to do that can easily use:

easy_install --allow-hosts=*.python.org

or put it in their configuration files to make it the default behavior.  See

Re: [Python-Dev] 2.5 open issues

[Georg Brandl]

Martin v. Löwis wrote:
> Neal Norwitz wrote:
>> Who is the owner for getting new icons installed with the new logo?
> 
> Nobody, so far (for Windows). Somebody should contact the owner and
> find out what the license on this work is, and then tell me what
> to do with them. I assume the py and pyc icons are to be replaced, and I
> also assume the Vista icons are to be ignored, but what about the
> other(s)?

As I posted here previously, I contacted the owner, and he said that he
didn't care about specifying a license. I guess that means that we can
pick one ;)

Georg

___
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] Summer of Code mailing list

[Neal Norwitz]

There's a new SoC mailing list.

[EMAIL PROTECTED]

You can sign up here:  http://mail.python.org/mailman/listinfo/soc2006

This list is for any SoC discussion:  mentors, students, idea, etc. 
Student can submit applications starting May 1, so now is the time to
get students interested in your ideas!

Please pass this information along.

Cheers,
n
___
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] Internal documentation for egg formats now available

[Phillip J. Eby]

(Thank you, by the way, for actually reading some of the documentation 
before writing this post, and for asking questions instead of jumping to 
conclusions.)


At 06:43 PM 4/28/2006 +0200, M.-A. Lemburg wrote:
>I've now found this section in the documentation which seems to
>have the reason:
>
>http://peak.telecommunity.com/DevCenter/EasyInstall#compressed-installation
>
>Apart from the statement "because Python processes zipfile entries on
>sys.path much faster than it does directories." being wrong,

Measure it.  Be sure to put the directories or zipfiles *first* on the 
path, not last.  The easiest way to do so accurately would be to 
easy_install some packages first using --zip-ok and then using 
--always-unzip, and compare the two.

Finally, try installing them --multi-version, and compare that, to get the 
speed when none of the packages are explicitly put on sys.path.


>it looks like all you'd have to do, is make --always-unzip the
>default.

You mean, all that *you'd* have to do is put it in your distutils 
configuration to make it the default for you, if for some reason you have a 
lot of programs that resemble "python -c 'pass'" in their import behavior.  :)


>Another nit which seems to have been introduced in 0.6a11:
>you now prepend egg directory entries to other sys.path entries,
>instead of appending them.
>
>What's the reason for that ?

It eliminates the possibility of conflicts with system-installed packages, 
or packages installed using the distutils, and provides the ability to 
install stdlib upgrades.


>Egg directory should really be treated just like any other
>site-package package and not be allowed to override stdlib
>modules and packages

Adding them *after* site-packages makes it impossible for a user to install 
a local upgrade to a system-installed package in site-packages.

One problem that I think you're not taking into consideration, is that 
setuptools does not overwrite packages except with an identical 
version.  It thus cannot replace an existing "raw" installation of a 
package by the distutils, except by deleting it (which it used to support 
via --delete-conflicting) or by installing ahead of the conflict on sys.path.

Since one of the problems with using --delete-conflicting was that users 
often don't have write access to site-packages, it's far simpler to just 
organize sys.path so that eggs always take precedence over their parent 
directory.  Thus, eggs in site-packages get precedence over site-packages 
itself, and eggs on PYTHONPATH get precedence over PYTHONPATH.


>without explicit user action by
>e.g. adjusting PYTHONPATH.

Installing to a PYTHONPATH directory *is* an explicit user 
action.  Installing something anywhere is an explicit user request: "I'd 
like this package to be importable, please."  If you don't want what you 
install to be importable by default, use --multi-version, which installs 
packages but doesn't put them on sys.path until you ask for them at runtime.

___
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] 2.5 open issues

[Thomas Heller]

Georg Brandl wrote:
> Martin v. Löwis wrote:
>> Neal Norwitz wrote:
>>> Who is the owner for getting new icons installed with the new logo?
>> Nobody, so far (for Windows). Somebody should contact the owner and
>> find out what the license on this work is, and then tell me what
>> to do with them. I assume the py and pyc icons are to be replaced, and I
>> also assume the Vista icons are to be ignored, but what about the
>> other(s)?
> 
> As I posted here previously, I contacted the owner, and he said that he
> didn't care about specifying a license. I guess that means that we can
> pick one ;)
> 

If this is really possible (but I doubt that) I suggest we pick the license
that Just had for his logo:

"""

If you do not agree with this LICENSE, you had better not looked at THE LOGO.
"""

http://starship.python.net/~just/pythonpowered/

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] Adding wsgiref to stdlib

[Guido van Rossum]

PEP 333 specifies WSGI, the Python Web Server Gateway Interface v1.0;
it's written by Phillip Eby who put a lot of effort in it to make it
acceptable to very diverse web frameworks. The PEP has been well
received by web framework makers and users.

As a supplement to the PEP, Phillip has written a reference
implementation, "wsgiref". I don't know how many people have used
wsgiref; I'm using it myself for an intranet webserver and am very
happy with it. (I'm asking Phillip to post the URL for the current
source; searching for it produces multiple repositories.)

I believe that it would be a good idea to add wsgiref to the stdlib,
after some minor cleanups such as removing the extra blank lines that
Phillip puts in his code. Having standard library support will remove
the last reason web framework developers might have to resist adopting
WSGI, and the resulting standardization will help web framework users.

Last time this was brought up there were feature requests and
discussion on how "industrial strength" the webserver in wsgiref ought
to be but nothing like the flamefest that setuptools caused (no
comments please).

I'm inviting people to discuss the addition of wsgiref to the standard
library. I'd like the discussion to be finished before a3 goes out;
technically it can go in up till the b1 code freeze, but I don't
really want to push it that close. I'd like the focus of the
discussion to be "what are the risks of adding wsgiref to the stdlib";
not "what could we think of that's even better". Achieving a perfect
decision is not the goal; having general consensus that adding it
would be better than not adding is would be good. Pointing out
specific bugs in wsgiref and suggesting how they ought to be fixed is
also welcome.

--
--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] Bug day?

[John J Lee]

Is another bug day planned in the next week or two?


John
___
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] Adding wsgiref to stdlib

[Bill Janssen]

> I'm inviting people to discuss the addition of wsgiref to the standard
> library. I'd like the discussion to be finished before a3 goes out;

+1.

I think it's faily low-risk.  WSGI has been discussed and implemented
for well over a year; there are many working implementations of the
spec.  Adding wsgiref to the stdlib would help other implementors of
the spec.

I think there should be a better server implementation in the stdlib,
but I think that can be added separately.  (Personally, I'd like to
find the time to (a) make Medusa thread-safe, and (b) add WSGI to it.
If anyone would like to help with that, send me mail.)

Bill
___
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] Adding wsgiref to stdlib

[Phillip J. Eby]

At 11:03 AM 4/28/2006 -0700, Guido van Rossum wrote:
>(I'm asking Phillip to post the URL for the current
>source; searching for it produces multiple repositories.)

Source browsing: http://svn.eby-sarna.com/wsgiref/
Anonymous SVN:   svn://svn.eby-sarna.com/svnroot/wsgiref


___
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] 2.5 open issues

[Martin v. Löwis]

Georg Brandl wrote:
> As I posted here previously, I contacted the owner, and he said that he
> didn't care about specifying a license. I guess that means that we can
> pick one ;)

Can you please ask whether he would be willing to fill out a contrib
form (http://www.python.org/psf/contrib/contrib-form/)? Without
some kind of explicit contribution, I hesitate to use it.

Regards,
Martin
___
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] rest2latex - was: Re: Raising objections

[engelbert . gruber]

i commited mkpydoc to docutils/sandbox/pydoc-writer with some small 
modifications

   - Patch for python 2.3.
   - Filenames from command line.
   - Guard definition of ``locallinewidth`` against redefinition.
   - latex needs definition of ``locallinewidth``.

1. there isnt a copyright in mkpydoc.py, could everybody involved agree on
PD so it can go into docutils.
2. edloper/docpy is another possibility
3. as is http://www.rexx.com/~dkuhlman/rstpythonlatex_intro.html
4. AND

* An unpatched latex2html is unable to handle ``longtable`` options.
   Maybe remove the ``[c]`` and put the longtable into a center
   environment, but python doc uses ``tablei`` and `` longtablei``.
* (th) the table in the ctypes tutorial has a totally different look than
   the other tables in the docs.  Compare
   `ctypes `_
   with `std pydoc `__ .

   see previous *
* (th) feature request: it would be very nice if it were possible to
   generate links into the index for functions and types from the rest sources.
* Document ``markup.py`` and ``missing.py``.
* Title, author, ... are hardcoded.

and i am on workshop next week, so please be patient and i dont know if 
this will ever work.

-- 
  contributions welcome --- d.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

[Python-Dev] Float formatting and #

[Georg Brandl]

Is there a reason why the "alternate format" isn't documented for float
conversions in http://docs.python.org/lib/typesseq-strings.html ?

'%#8.f' % 1.0 keeps the decimal point while '%8.f' % 1.0 drops it.

Also, for %g the alternate form keeps trailing zeroes.

While at it, I noticed a difference between %f and %g:

'%.3f' % 1.123 is "1.123" while
'%.3g' % 1.123 is "1.12".

Is that intentional?

Georg

___
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] [Web-SIG] Adding wsgiref to stdlib

[Ian Bicking]

Guido van Rossum wrote:
> PEP 333 specifies WSGI, the Python Web Server Gateway Interface v1.0;
> it's written by Phillip Eby who put a lot of effort in it to make it
> acceptable to very diverse web frameworks. The PEP has been well
> received by web framework makers and users.
> 
> As a supplement to the PEP, Phillip has written a reference
> implementation, "wsgiref". I don't know how many people have used
> wsgiref; I'm using it myself for an intranet webserver and am very
> happy with it. (I'm asking Phillip to post the URL for the current
> source; searching for it produces multiple repositories.)
> 
> I believe that it would be a good idea to add wsgiref to the stdlib,
> after some minor cleanups such as removing the extra blank lines that
> Phillip puts in his code. Having standard library support will remove
> the last reason web framework developers might have to resist adopting
> WSGI, and the resulting standardization will help web framework users.

I'd like to include paste.lint with that as well (as wsgiref.lint or 
whatever).  Since the last discussion I enumerated in the docstring all 
the checks it does.  There's still some outstanding issues, mostly where 
I'm not sure if it is too restrictive (marked with @@ in the source). 
It's at:

   http://svn.pythonpaste.org/Paste/trunk/paste/lint.py

I think another useful addition would be some prefix-based dispatcher, 
similar to paste.urlmap (but probably a bit simpler): 
http://svn.pythonpaste.org/Paste/trunk/paste/urlmap.py

The motivation there is to give people the basic tools to simple 
multi-application hosting, and in the process implicitly suggest how 
other dispatching can be done.  I think this is something that doesn't 
occur to people naturally, and they see it as a flaw in the server (that 
the server doesn't have a dispatching feature), and the result is either 
frustration, griping, or bad kludges.  By including a basic 
implementation of WSGI-based dispatching the standard library can lead 
people in the right direction for more sophisticated dispatching.

And prefix dispatching is also quite useful on its own, it's not just 
educational.

> Last time this was brought up there were feature requests and
> discussion on how "industrial strength" the webserver in wsgiref ought
> to be but nothing like the flamefest that setuptools caused (no
> comments please).

No one disagreed with the basic premise though, just some questions 
about the particulars of the server.  I think there were at least a 
couple small suggestions for the wsgiref server; in particular maybe a 
slight refactoring to make it easier to use with https.


-- 
Ian Bicking  /  [EMAIL PROTECTED]  /  http://blog.ianbicking.org
___
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] Float formatting and #

[Georg Brandl]

Georg Brandl wrote:
> Is there a reason why the "alternate format" isn't documented for float
> conversions in http://docs.python.org/lib/typesseq-strings.html ?
> 
> '%#8.f' % 1.0 keeps the decimal point while '%8.f' % 1.0 drops it.
> 
> Also, for %g the alternate form keeps trailing zeroes.
> 
> While at it, I noticed a difference between %f and %g:
> 
> '%.3f' % 1.123 is "1.123" while
> '%.3g' % 1.123 is "1.12".
> 
> Is that intentional?

Reviewing the printf man page, this is okay since for %f, the precision is the
number of digits after the decimal point while for %g, it is the number of
significant digits. Still, that should be documented in the Python manual.

Georg

___
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] [Web-SIG] Adding wsgiref to stdlib

[Guido van Rossum]

On 4/28/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
> I'd like to include paste.lint with that as well (as wsgiref.lint or
> whatever).  Since the last discussion I enumerated in the docstring all
> the checks it does.  There's still some outstanding issues, mostly where
> I'm not sure if it is too restrictive (marked with @@ in the source).
> It's at:
>
>http://svn.pythonpaste.org/Paste/trunk/paste/lint.py

That looks fine to me; I'm not in this business full-time so I'll
await others' responses.

> I think another useful addition would be some prefix-based dispatcher,
> similar to paste.urlmap (but probably a bit simpler):
> http://svn.pythonpaste.org/Paste/trunk/paste/urlmap.py

IMO this is getting into framework design. Perhaps something like this
could be added in 2.6?

--
--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] [Web-SIG] Adding wsgiref to stdlib

[Ian Bicking]

Guido van Rossum wrote:
>> I think another useful addition would be some prefix-based dispatcher,
>> similar to paste.urlmap (but probably a bit simpler):
>> http://svn.pythonpaste.org/Paste/trunk/paste/urlmap.py
> 
> 
> IMO this is getting into framework design. Perhaps something like this
> could be added in 2.6?

I don't think it's frameworky.  It could be used to build a very 
primitive framework, but even then it's not a particularly useful 
starting point.

In Paste this would generally be used below any framework (or above I 
guess, depending on which side is "up").  You'd pass /blog to a blog 
app, /cms to a cms app, etc.  WSGI already is very specific about what 
needs to be done when doing this dispatching (adjusting SCRIPT_NAME and 
PATH_INFO), and that's all that the dispatching needs to do.

The applications themselves are written in some framework with internal 
notions of URL dispatching, but this doesn't infringe upon those. 
(Unless the framework doesn't respect SCRIPT_NAME and PATH_INFO; but 
that's their problem, as the dispatcher is just using what's already 
allowed for in the WSGI spec.)  It also doesn't overlap with frameworks, 
as prefix-based dispatching isn't really that useful in a framework.

The basic implementation is:

class PrefixDispatch(object):
 def __init__(self):
 self.applications = {}
 def add_application(self, prefix, app):
 self.applications[prefix] = app
 def __call__(self, environ, start_response):
 apps = sorted(self.applications.items(),
   key=lambda x: -len(x[0]))
 path_info = environ.get('PATH_INFO', '')
 for prefix, app in apps:
 if not path_info.startswith(prefix):
 continue
 environ['SCRIPT_NAME'] = environ.get('SCRIPT_NAME', '')+prefix
 environ['PATH_INFO'] = environ.get('PATH_INFO', 
'')[len(prefix):]
 return app(environ, start_response)
 start_response('404 Not Found', [('Content-type', 'text/html')])
 return ['Not Found']


There's a bunch of checks that should take place (most related to /'s), 
and the not found response should be configurable (probably as an 
application that can be passed in as an argument).  But that's most of 
what it should do.


-- 
Ian Bicking  /  [EMAIL PROTECTED]  /  http://blog.ianbicking.org
___
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] [Web-SIG] Adding wsgiref to stdlib

[Phillip J. Eby]

At 02:32 PM 4/28/2006 -0500, Ian Bicking wrote:
>Guido van Rossum wrote:
> > PEP 333 specifies WSGI, the Python Web Server Gateway Interface v1.0;
> > it's written by Phillip Eby who put a lot of effort in it to make it
> > acceptable to very diverse web frameworks. The PEP has been well
> > received by web framework makers and users.
> >
> > As a supplement to the PEP, Phillip has written a reference
> > implementation, "wsgiref". I don't know how many people have used
> > wsgiref; I'm using it myself for an intranet webserver and am very
> > happy with it. (I'm asking Phillip to post the URL for the current
> > source; searching for it produces multiple repositories.)
> >
> > I believe that it would be a good idea to add wsgiref to the stdlib,
> > after some minor cleanups such as removing the extra blank lines that
> > Phillip puts in his code. Having standard library support will remove
> > the last reason web framework developers might have to resist adopting
> > WSGI, and the resulting standardization will help web framework users.
>
>I'd like to include paste.lint with that as well (as wsgiref.lint or
>whatever).  Since the last discussion I enumerated in the docstring all
>the checks it does.  There's still some outstanding issues, mostly where
>I'm not sure if it is too restrictive (marked with @@ in the source).
>It's at:
>
>http://svn.pythonpaste.org/Paste/trunk/paste/lint.py

+1, but lose the unused 'global_conf' parameter and 'make_middleware' 
functions.


>I think another useful addition would be some prefix-based dispatcher,
>similar to paste.urlmap (but probably a bit simpler):
>http://svn.pythonpaste.org/Paste/trunk/paste/urlmap.py

I'd rather see something a *lot* simpler - something that just takes a 
dictionary mapping names to application objects, and parses path segments 
using wsgiref functions.  That way, its usefulness as an example wouldn't 
be obscured by having too many features.  Such a thing would still be quite 
useful, and would illustrate how to do more sophisticated 
dispatching.  Something more or less like:

 from wsgiref.util import shift_path_info

 # usage:
 #main_app = AppMap(foo=part_one, bar=part_two, ...)

 class AppMap:
 def __init__(self, **apps):
 self.apps = apps

 def __call__(self, environ, start_response):
 name = shift_path_info(environ)
 if name is None:
 return self.default(environ, start_response)
 elif name in self.apps:
 return self.apps[name](environ,start_response)
 return self.not_found(environ, start_response)

 def default(self, environ, start_response):
 self.not_found(environ, start_response)

 def not_found(self, environ, start_response):
 # code to generate a 404 response here

This should be short enough to highlight the concept, while still providing 
a few hooks for subclassing.

___
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] [Web-SIG] Adding wsgiref to stdlib

[Guido van Rossum]

It still looks like an application of WSGI, not part of a reference
implementation. Multiple apps looks like an advanced topic to me; more
something that the infrastructure (Apache server or whatever) ought to
take care of.

I don't expect you to agree with me. But I don't expect you to be able
to convince me either. Maybe you can convince Phillip; I'm going to
try to sit on my hands now.

--Guido

On 4/28/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> >> I think another useful addition would be some prefix-based dispatcher,
> >> similar to paste.urlmap (but probably a bit simpler):
> >> http://svn.pythonpaste.org/Paste/trunk/paste/urlmap.py
> >
> >
> > IMO this is getting into framework design. Perhaps something like this
> > could be added in 2.6?
>
> I don't think it's frameworky.  It could be used to build a very
> primitive framework, but even then it's not a particularly useful
> starting point.
>
> In Paste this would generally be used below any framework (or above I
> guess, depending on which side is "up").  You'd pass /blog to a blog
> app, /cms to a cms app, etc.  WSGI already is very specific about what
> needs to be done when doing this dispatching (adjusting SCRIPT_NAME and
> PATH_INFO), and that's all that the dispatching needs to do.
>
> The applications themselves are written in some framework with internal
> notions of URL dispatching, but this doesn't infringe upon those.
> (Unless the framework doesn't respect SCRIPT_NAME and PATH_INFO; but
> that's their problem, as the dispatcher is just using what's already
> allowed for in the WSGI spec.)  It also doesn't overlap with frameworks,
> as prefix-based dispatching isn't really that useful in a framework.
>
> The basic implementation is:
>
> class PrefixDispatch(object):
>  def __init__(self):
>  self.applications = {}
>  def add_application(self, prefix, app):
>  self.applications[prefix] = app
>  def __call__(self, environ, start_response):
>  apps = sorted(self.applications.items(),
>key=lambda x: -len(x[0]))
>  path_info = environ.get('PATH_INFO', '')
>  for prefix, app in apps:
>  if not path_info.startswith(prefix):
>  continue
>  environ['SCRIPT_NAME'] = environ.get('SCRIPT_NAME', '')+prefix
>  environ['PATH_INFO'] = environ.get('PATH_INFO',
> '')[len(prefix):]
>  return app(environ, start_response)
>  start_response('404 Not Found', [('Content-type', 'text/html')])
>  return ['Not Found']
>
>
> There's a bunch of checks that should take place (most related to /'s),
> and the not found response should be configurable (probably as an
> application that can be passed in as an argument).  But that's most of
> what it should do.
>
>
> --
> Ian Bicking  /  [EMAIL PROTECTED]  /  http://blog.ianbicking.org
>


--
--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] [Web-SIG] Adding wsgiref to stdlib

[Ian Bicking]

Guido van Rossum wrote:
> It still looks like an application of WSGI, not part of a reference
> implementation. Multiple apps looks like an advanced topic to me; more
> something that the infrastructure (Apache server or whatever) ought to
> take care of.

I don't understand the distinction between "application of WSGI" and 
"reference implementation".  The reference implementation *is* an 
application of WSGI... using the reference implementation doesn't make 
something more or less WSGI.

Also, wsgiref *is* infrastructure.  When using the HTTP server, there is 
no other infrastructure, there is nothing else that will do this prefix 
dispatching for you.

Apache and other web servers also provides this functionality, and with 
the right configuration it will provide the identical environment as a 
prefix dispatcher.  To me that's a positive.  I've seen cases where 
other people have done the same prefix dispatching in Python *without* 
matching the interface of anybody else's code or environment; that's the 
sort of thing a reference implementation is meant to keep people from doing.


-- 
Ian Bicking  /  [EMAIL PROTECTED]  /  http://blog.ianbicking.org
___
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] [Web-SIG] Adding wsgiref to stdlib

[Phillip J. Eby]

At 01:19 PM 4/28/2006 -0700, Guido van Rossum wrote:
>It still looks like an application of WSGI, not part of a reference
>implementation. Multiple apps looks like an advanced topic to me; more
>something that the infrastructure (Apache server or whatever) ought to
>take care of.

I'm fine with a super-simple implementation that emphasizes the concept, 
not feature-richness.  A simple dict-based implementation showcases both 
the wsgiref function for path shifting, and the idea of composing an 
application out of mini-applications.  (The point is to demonstrate how 
people can compose WSGI applications *without* needing a framework.)

But I don't think that this demo should be a prefix mapper; people doing 
more sophisticated routing can use Paste or Routes.

If it's small enough, I'd say to add this mapper to wsgiref.util, or if 
Guido is strongly set against it being in the code, we should at least put 
it in the documentation as an example of how to use 'shift_path_info()' in 
wsgiref.util.

___
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] [Web-SIG] Adding wsgiref to stdlib

[Guido van Rossum]

On 4/28/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> If it's small enough, I'd say to add this mapper to wsgiref.util, or if
> Guido is strongly set against it being in the code, we should at least put
> it in the documentation as an example of how to use 'shift_path_info()' in
> wsgiref.util.

I'm for doing what you think is best.

--
--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] [Web-SIG] Adding wsgiref to stdlib

[Collin Winter]

On 4/28/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 01:19 PM 4/28/2006 -0700, Guido van Rossum wrote:
> >It still looks like an application of WSGI, not part of a reference
> >implementation. Multiple apps looks like an advanced topic to me; more
> >something that the infrastructure (Apache server or whatever) ought to
> >take care of.
>
> I'm fine with a super-simple implementation that emphasizes the concept,
> not feature-richness.  A simple dict-based implementation showcases both
> the wsgiref function for path shifting, and the idea of composing an
> application out of mini-applications.  (The point is to demonstrate how
> people can compose WSGI applications *without* needing a framework.)
>
> But I don't think that this demo should be a prefix mapper; people doing
> more sophisticated routing can use Paste or Routes.
>
> If it's small enough, I'd say to add this mapper to wsgiref.util, or if
> Guido is strongly set against it being in the code, we should at least put
> it in the documentation as an example of how to use 'shift_path_info()' in
> wsgiref.util.

Perhaps this could go in Demo/wsgiref/?

Collin Winter
___
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] [Web-SIG] Adding wsgiref to stdlib

[Ian Bicking]

Phillip J. Eby wrote:
>> I'd like to include paste.lint with that as well (as wsgiref.lint or
>> whatever).  Since the last discussion I enumerated in the docstring all
>> the checks it does.  There's still some outstanding issues, mostly where
>> I'm not sure if it is too restrictive (marked with @@ in the source).
>> It's at:
>>
>>http://svn.pythonpaste.org/Paste/trunk/paste/lint.py
> 
> 
> +1, but lose the unused 'global_conf' parameter and 'make_middleware' 
> functions.

Yeah, those are just related to Paste Deploy and wouldn't go in.

>> I think another useful addition would be some prefix-based dispatcher,
>> similar to paste.urlmap (but probably a bit simpler):
>> http://svn.pythonpaste.org/Paste/trunk/paste/urlmap.py
> 
> 
> I'd rather see something a *lot* simpler - something that just takes a 
> dictionary mapping names to application objects, and parses path 
> segments using wsgiref functions.  That way, its usefulness as an 
> example wouldn't be obscured by having too many features.  Such a thing 
> would still be quite useful, and would illustrate how to do more 
> sophisticated dispatching.  Something more or less like:
> 
> from wsgiref.util import shift_path_info
> 
> # usage:
> #main_app = AppMap(foo=part_one, bar=part_two, ...)
> 
> class AppMap:
> def __init__(self, **apps):
> self.apps = apps
> 
> def __call__(self, environ, start_response):
> name = shift_path_info(environ)
> if name is None:
> return self.default(environ, start_response)
> elif name in self.apps:
> return self.apps[name](environ,start_response)
> return self.not_found(environ, start_response)
> 
> def default(self, environ, start_response):
> self.not_found(environ, start_response)
> 
> def not_found(self, environ, start_response):
> # code to generate a 404 response here
> 
> This should be short enough to highlight the concept, while still 
> providing a few hooks for subclassing.

That's mostly what I was thinking, though using a full prefix (instead 
of just a single path segment), and the default is the application at 
'', like in my other email.

paste.urlmap has several features I wouldn't propose (like domain and 
port matching, more Paste Deploy stuff, and a proxy object that I should 
probably just delete); I probably should have been more specific. 
URLMap's dictionary interface isn't that useful either.

Another feature that the example in my other email doesn't have is / 
handling, specifically redirecting /something-that-matches to 
/something-that-matches/ (something Apache's Alias doesn't do but should).

Host and port matching is pretty easy to do at the same time, and in my 
experience can be useful to do at the same time, but I don't really care 
if that feature goes in.

-- 
Ian Bicking  /  [EMAIL PROTECTED]  /  http://blog.ianbicking.org
___
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] [Web-SIG] Adding wsgiref to stdlib

[Ian Bicking]

Phillip J. Eby wrote:
> At 01:19 PM 4/28/2006 -0700, Guido van Rossum wrote:
> 
>> It still looks like an application of WSGI, not part of a reference
>> implementation. Multiple apps looks like an advanced topic to me; more
>> something that the infrastructure (Apache server or whatever) ought to
>> take care of.
> 
> 
> I'm fine with a super-simple implementation that emphasizes the concept, 
> not feature-richness.  A simple dict-based implementation showcases both 
> the wsgiref function for path shifting, and the idea of composing an 
> application out of mini-applications.  (The point is to demonstrate how 
> people can compose WSGI applications *without* needing a framework.)
> 
> But I don't think that this demo should be a prefix mapper; people doing 
> more sophisticated routing can use Paste or Routes.

I don't see why not to use prefix matching.  It is more consistent with 
the handling of the default application ('', instead of a method that 
needs to be overridden), and more general, and the algorithm is only 
barely more complex and not what I'd call sophisticated.  The default 
application handling in particular means that AppMap isn't really useful 
without subclassing or assigning to .default.

Prefix matching wouldn't show off anything else in wsgiref, because 
there's nothing else to use; paste.urlmap doesn't use any other part of 
Paste either (except one unimportant exception) because there's just no 
need.


-- 
Ian Bicking  /  [EMAIL PROTECTED]  /  http://blog.ianbicking.org
___
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] [Web-SIG] Adding wsgiref to stdlib

[Phillip J. Eby]

At 04:04 PM 4/28/2006 -0500, Ian Bicking wrote:
>I don't see why not to use prefix matching.  It is more consistent with
>the handling of the default application ('', instead of a method that
>needs to be overridden), and more general, and the algorithm is only
>barely more complex and not what I'd call sophisticated.  The default
>application handling in particular means that AppMap isn't really useful
>without subclassing or assigning to .default.
>
>Prefix matching wouldn't show off anything else in wsgiref,

Right, that would be taking away one of the main reasons to include it.

To make the real dispatcher, I'd flesh out what I wrote a little bit, to 
handle the "default" method in a more meaningful way, including the 
redirect.  All that should only add a few lines, however.

___
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] binary trees. Review obmalloc.c

[Martin v. Löwis]

Vladimir 'Yu' Stepanov wrote:
> * To adapt allocation of blocks of memory with other alignment. Now 
> alignment is rigidly set on 8 bytes. As a variant, it is possible to 
> use alignment on 4 bytes. And this value can be set at start of the 
> interpreter through arguments/variable environments/etc. At testing 
> with alignment on 4 or 8 bytes difference in speed of work was not 
> appreciable.

That depends on the hardware you use, of course. Some architectures
absolutely cannot stand mis-aligned accesses, and programs will just
crash if they try to perform such accesses.

So Python should err on the safe side, and only use a smaller alignment
when it is known not to hurt.

OTOH, I don't see the *advantage* in reducing the alignment.

> * To expand the maximal size which can be allocated by means of the 
> given module. Now the maximal size is 256 bytes.

Right. This is somewhat deliberate, though; the expectation is that
fragmentation will increase dramatically if even larger size classes
are supported.

> * At the size of the allocated memory close to maximal, the
> allocation of blocks becomes inefficient. For example, for the
> sizesof blocks 248 and 256 (blocksize), values of quantity of
> elements (PAGESIZE/blocksize) it is equal 16. I.e. it would be
> possible to use for the sizes of the block 248 same page, as for the
> size of the block 256.

Good idea; that shouldn't be too difficult to implement: for sizes above
215, pools need to be spaced apart only at 16 bytes.

Regards,
Martin
___
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] [Web-SIG] Adding wsgiref to stdlib

[Ian Bicking]

Phillip J. Eby wrote:
> At 04:04 PM 4/28/2006 -0500, Ian Bicking wrote:
> 
>> I don't see why not to use prefix matching.  It is more consistent with
>> the handling of the default application ('', instead of a method that
>> needs to be overridden), and more general, and the algorithm is only
>> barely more complex and not what I'd call sophisticated.  The default
>> application handling in particular means that AppMap isn't really useful
>> without subclassing or assigning to .default.
>>
>> Prefix matching wouldn't show off anything else in wsgiref,
> 
> 
> Right, that would be taking away one of the main reasons to include it.

That's putting the cart in front of the horse, using a matching 
algorithm because that's what shift_path_info does, not because it's the 
most natural or useful way to do the match.

I suggest prefix matching not because it shows how the current functions 
in wsgiref work, but because it shows a pattern of dispatching WSGI 
applications on a level that is typically (but for WSGI, unnecessarily) 
built into the server.  The educational value is in the pattern, not in 
the implementation.

If you want to show how the functions in wsgiref work, then that belongs 
in documentation.  Which would be good too, people like examples, and 
the more examples in the wsgiref docs the better.  People are much less 
likely to see examples in the code itself.

> To make the real dispatcher, I'd flesh out what I wrote a little bit, to 
> handle the "default" method in a more meaningful way, including the 
> redirect.  All that should only add a few lines, however.

It will still be only a couple lines less than prefix matching.

Another issue with your implementation is the use of keyword arguments 
for the path mappings, even though path mappings have no association 
with keyword arguments or valid Python identifiers.

-- 
Ian Bicking  /  [EMAIL PROTECTED]  /  http://blog.ianbicking.org
___
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] [Web-SIG] Adding wsgiref to stdlib

[Phillip J. Eby]

At 05:47 PM 4/28/2006 -0500, Ian Bicking wrote:
>It will still be only a couple lines less than prefix matching.

That's beside the point.  Prefix matching is inherently a more complex 
concept, and more likely to be confusing, without introducing much in the 
way of new features.  If I want to dispatch /foo/bar, why not just use:

 AppMap(foo=AppMap(bar=whatever))


So, I don't see prefix matching as introducing anything that's worth the 
extra complexity.  If somebody needs a high-performance prefix matcher, 
they can get yours from Paste.

If I was going to include a more sophisticated dispatcher, I'd add an 
ordered regular expression dispatcher, since that would support use cases 
that the simple or prefix dispatchers would not, but it would also support 
the prefix cases without nesting.


>Another issue with your implementation is the use of keyword arguments for 
>the path mappings, even though path mappings have no association with 
>keyword arguments or valid Python identifiers.

That was for brevity; it should probably also take a mapping argument.

___
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] [Web-SIG] Adding wsgiref to stdlib

[Phillip J. Eby]

At 04:34 PM 4/28/2006 -0700, Titus Brown wrote:
>Hi, Phillip,
>
>I'm getting this error when I run the tests, with both Python 2.3 and
>2.4:
>
>==
>FAIL: testHeaderFormats (wsgiref.tests.test_handlers.HandlerTests)
>--
>Traceback (most recent call last):
>   File "/disk/u/t/dev/misc/wsgiref/src/wsgiref/tests/test_handlers.py", 
> line 205, in testHeaderFormats
> (stdpat%(version,sw), h.stdout.getvalue())
>AssertionError: ('HTTP/1.0 200 OK\\r\\nDate: \\w{3} \\w{3} [ 0123]\\d 
>\\d\\d:\\d\\d:\\d\\d \\d{4}\\r\\nServer: FooBar/1.0\r\nContent-Length: 
>0\\r\\n\\r\\n', 'HTTP/1.0 200 OK\r\nDate: Fri, 28 Apr 2006 23:28:11 
>GMT\r\nServer: FooBar/1.0\r\nContent-Length: 0\r\n\r\n')
>
>--

This is probably due to Guido's patch to make the Date: header more RFC 
compliant.  I'll take a look at it this weekend.


>On a separate note, what are you actually proposing to include?  It'd be
>good to remove the TODO list, for example, unless those are things To Be
>Done before adding it into Python 2.5.

Well, it looks like the "validate" bit will be going in, and we're talking 
about what to put in "router", so that'll take care of half the list right 
there.  :)

The other two items can wait, unless somebody wants to contribute them.



>Will it be added as 'wsgi' or 'wsgiref?

I assumed it would be wsgiref, which would allow compatibility with 
existing code that uses it.


>I'd also personally suggest putting anything intended for common use
>directly under the top level, i.e.
>
> wsgiref.WSGIServer
>
>vs
>
> wsgiref.simple_server.WSGIServer

I'm against this, because it would force the handlers and simple_server 
modules to be imported, even for programs not using them.


>And, finally, is there any documentation?

Only the docstrings.  Contributions are more than welcome.


___
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] [Web-SIG] Adding wsgiref to stdlib

[Ian Bicking]

Phillip J. Eby wrote:
> At 05:47 PM 4/28/2006 -0500, Ian Bicking wrote:
>> It will still be only a couple lines less than prefix matching.
> 
> That's beside the point.  Prefix matching is inherently a more complex 
> concept, and more likely to be confusing, without introducing much in 
> the way of new features.  

I just don't understand this.  It's not more complex.  Prefix matching 
works like:

   get the prefixes
   order them longest first
   check each one against PATH_INFO
   use the matched app
   or call the not found handler

Name matching works like:

   get the mapping
   get the next chunk
   get the app associated with that chunk
   use that app
   or call the not found handler

One is not more complex than the other.


> If I want to dispatch /foo/bar, why not just use:
> 
> AppMap(foo=AppMap(bar=whatever))

You create an intermediate application with no particular purpose.  You 
get two default handlers, two not found handlers, and you create an 
object tree that is distracting because it is artificial.  Paths are 
strings, not trees or objects.  When you confuse strings for objects you 
are moving into framework territory.

> If I was going to include a more sophisticated dispatcher, I'd add an 
> ordered regular expression dispatcher, since that would support use 
> cases that the simple or prefix dispatchers would not, but it would also 
> support the prefix cases without nesting.

That is significantly more complex, because SCRIPT_NAME/PATH_INFO cannot 
be used to express what the regular expression matched.  It also 
overlaps with frameworks.  WSGI doesn't offer any standard mechanism to 
do that sort of thing.  It could (e.g., a wsgi.path_vars key), but it 
doesn't.  Or you do something that looks like mod_rewrite, but no one 
wants that.

Prefix based routing represents a real cusp -- more than that, and you 
have to invent conventions not already present in the WSGI spec, and you 
overlap with frameworks.  Less than that... well, you can't do a whole 
lot less than that.

-- 
Ian Bicking  |  [EMAIL PROTECTED]  |  http://blog.ianbicking.org
___
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] 2.5 open issues

[Neal Norwitz]

Here's what's left for 2.5 after the most recent go around.

There's no owner for these items.  If no one takes them, they won't
get done and I will move them to deferred within a week:

  * Add @decorator decorator to functional, rename to functools?
What's the benefit of @decorator?  Who made functional?  It's new
in 2.5, right?  If so, move it or it will be functional for all 2.x.

  * Remove the fpectl module?
   Does anyone use this?  It can probably be removed, but someone
needs to do the work.

  * new icons is lost and needs a shepherd to make python look spiffy

  * what's happening with these modules:  timing, cl, sv?

n


On 4/28/06, A.M. Kuchling <[EMAIL PROTECTED]> wrote:
> On Thu, Apr 27, 2006 at 10:58:49PM -0700, Neal Norwitz wrote:
> > If you are addressed on this message, it means you have open issues
> > that need to be resolved for 2.5.  Some of these issues are
> > documentation, others are code issues.  This information comes from
> > PEP 356.
>
> There are also these items in the 'possible features' section:
> 
> Modules under consideration for inclusion:
>
>   - bdist_deb in distutils package
> (Owner: ???)
> http://mail.python.org/pipermail/python-dev/2006-February/060926.html
>
>   - wsgiref to the standard library
> (Owner: Phillip Eby)
>
>   - pure python pgen module
> (Owner: Guido)
>
>   - Support for building "fat" Mac binaries (Intel and PPC)
> (Owner: Ronald Oussoren)
> 
>
> wsgiref is the most important one, I think.  If there's anything I can
> do to help, please let me know.
>
> --amk
> ___
> 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/nnorwitz%40gmail.com
>
___
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] Weekly Python Patch/Bug Summary

[Kurt B. Kaiser]

Patch / Bug Summary
___

Patches :  378 open ( +7) /  3199 closed ( +4) /  3577 total (+11)
Bugs:  901 open ( -7) /  5792 closed (+25) /  6693 total (+18)
RFE :  214 open ( +3) /   214 closed ( +2) /   428 total ( +5)

New / Reopened Patches
__

Allow PyArg_ParseTupleAndKeywords to unpack tuples  (2006-04-22)
   http://python.org/sf/1474454  reopened by  loewis

Allow PyArg_ParseTupleAndKeywords to unpack tuples  (2006-04-21)
   http://python.org/sf/1474454  opened by  Roger Upole

detect %zd format for PY_FORMAT_SIZE_T  (2006-04-22)
   http://python.org/sf/1474907  opened by  Brett Cannon

New doctest option: +SKIP  (2006-04-23)
CLOSED http://python.org/sf/1475231  opened by  Edward Loper

patch fixing #1448060 (gettext.py bug)  (2006-04-24)
   http://python.org/sf/1475523  opened by  Thenault Sylvain

IndentationError for unexpected indent  (2006-04-24)
   http://python.org/sf/1475845  opened by  Roger Miller

Add help reference on Mac  (2006-04-25)
   http://python.org/sf/1476578  opened by  Bruce Sherwood

__init__.py'less package import warnings  (2006-04-27)
   http://python.org/sf/1477281  opened by  Thomas Wouters

Allow os.listdir to accept file names longer than MAX_PATH  (2006-04-26)
   http://python.org/sf/1477350  opened by  Roger Upole

Fix doctest nit.  (2006-04-28)
   http://python.org/sf/1478292  opened by  Thomas Heller

Picky floats  (2006-04-28)
   http://python.org/sf/1478364  opened by  Skip Montanaro

Patches Closed
__

Allow PyArg_ParseTupleAndKeywords to unpack tuples  (2006-04-22)
   http://python.org/sf/1474454  closed by  loewis

Weak linking support for OSX  (2006-04-17)
   http://python.org/sf/1471925  closed by  ronaldoussoren

test for broken poll at runtime  (2006-04-17)
   http://python.org/sf/1471761  closed by  ronaldoussoren

New doctest option: +SKIP  (2006-04-23)
   http://python.org/sf/1475231  closed by  tim_one

start testing strings > 2GB  (2006-04-17)
   http://python.org/sf/1471578  closed by  twouters

New / Reopened Bugs
___

non-keyword argument following keyword  (2006-04-23)
   http://python.org/sf/1474677  opened by  George Yoshida

pickling files works with protocol=2.  (2006-04-22)
   http://python.org/sf/1474680  opened by  Kirill Simonov

Document os.path.join oddity on Windows  (2006-04-23)
CLOSED http://python.org/sf/1475009  opened by  Miki Tebeka

example code in what's new/sqlite3 docs  (2006-04-23)
CLOSED http://python.org/sf/1475080  opened by  James Pryor

Tkinter hangs in test_tcl  (2006-04-23)
   http://python.org/sf/1475162  opened by  Thomas Wouters

Poorly worded description for socket.makefile()  (2006-04-24)
   http://python.org/sf/1475554  opened by  Roy Smith

replacing obj.__dict__ with a subclass of dict  (2006-04-24)
   http://python.org/sf/1475692  opened by  ganges master

SystemError in socket sendto  (2006-04-25)
CLOSED http://python.org/sf/1476111  opened by  CyDefect

Documentation date stuck on "5th April 2006"  (2006-04-25)
CLOSED http://python.org/sf/1476216  opened by  Mat Martineau

StringIO should implement __str__()  (2006-04-25)
CLOSED http://python.org/sf/1476356  opened by  Dom Lachowicz

Finish PEP 343 terminology cleanup  (2006-04-26)
   http://python.org/sf/1476845  opened by  Nick Coghlan

Missing import line in example  (2006-04-26)
CLOSED http://python.org/sf/1477102  opened by  Bruce Eckel

Incorrect code in example  (2006-04-26)
CLOSED http://python.org/sf/1477140  opened by  Bruce Eckel

test_bsddb skipped -- Failed to load /home/shashi/Python-2.4  (2006-04-27)
   http://python.org/sf/1477450  opened by  shashi

test_ctypes: undefined symbol: XGetExtensionVersion  (2006-04-28)
   http://python.org/sf/1478253  opened by  balducci

Invalid value returned by util.get_platform() on HP  (2006-04-28)
CLOSED http://python.org/sf/1478326  opened by  Sébastien Sablé

test_capi crashed -- thread.error: can't allocate lock  (2006-04-28)
CLOSED http://python.org/sf/1478400  opened by  shashi

datetime.datetime.fromtimestamp ValueError. Rounding error  (2006-04-28)
CLOSED http://python.org/sf/1478429  opened by  Erwin Bonsma

size limit exceeded for read() from network drive  (2006-04-28)
   http://python.org/sf/1478529  opened by  Mark Sheppard

Bugs Closed
___

IDLE does not start 2.4.3  (2006-04-17)
   http://python.org/sf/1471806  closed by  egrimes

TempFile can hang on Windows  (2006-04-20)
   http://python.org/sf/1473760  closed by  tim_one

import module with .dll extension  (2006-04-18)
   http://python.org/sf/1472566  closed by  gbrandl

Document os.path.join oddity on Windows  (2006-04-23)
   http://python.org/sf/1475009  closed by  gbrandl

example code in what's new/sqlite3 docs  (2006-04-23)
   http://python.org/sf/1475080  closed by  akuchling

interactive: no cursors ctrl-a/e... in 2.5a1/linux/debian  (2006-04-18

Re: [Python-Dev] binary trees. Review obmalloc.c

[Tim Peters]

[Vladimir 'Yu' Stepanov]
>> * To adapt allocation of blocks of memory with other alignment. Now
>> alignment is rigidly set on 8 bytes. As a variant, it is possible to
>> use alignment on 4 bytes. And this value can be set at start of the
>> interpreter through arguments/variable environments/etc. At testing
>> with alignment on 4 or 8 bytes difference in speed of work was not
>> appreciable.

[Martin v. Löwis]
> That depends on the hardware you use, of course. Some architectures
> absolutely cannot stand mis-aligned accesses, and programs will just
> crash if they try to perform such accesses.

Note that we _had_ to add a goofy "long double" to the PyGC_Head union
because some Python platform required 8-byte alignment for some types
... see rev 25454.  Any spelling of malloc() also needs to return
memory aligned for any legitimate purpose, and 8-byte alignment is the
strictest requirement we know of across current Python platforms.

> So Python should err on the safe side, and only use a smaller alignment
> when it is known not to hurt.
>
> OTOH, I don't see the *advantage* in reducing the alignment.

It could cut wasted bytes.  There is no per-object memory overhead in
a release-build obmalloc:  the allocatable part of a pool is entirely
used for user-visible object memory, except when the alignment
requirement ends up forcing unused (by both the user and by obmalloc)
pad bytes.  For example, Python ints consume 12 bytes on 32-bit boxes,
but if space were allocated for them by obmalloc (it's not), obmalloc
would have to use 16 bytes per int to preserve 8-byte alignment.

OTOH, obmalloc (unlike PyGC_Head) has always used 8-byte alignment,
because that's what worked best for Vladimir Marangozov during his
extensive timing tests.  It's not an isolated decision -- e.g., it's
also influenced by, and influences, "the best" pool size, and (of
course) cutting alignment to 4 would double the number of "size
classes" obmalloc has to juggle.

>> * To expand the maximal size which can be allocated by means of the
>> given module. Now the maximal size is 256 bytes.

> Right. This is somewhat deliberate, though; the expectation is that
> fragmentation will increase dramatically if even larger size classes
> are supported.

It's entirely deliberate ;-)  obmalloc is no way trying to be a
general-purpose allocator.  It was designed specifically for the
common memory patterns in Python, aiming at large numbers of small
objects of the same size.  That's extremely common in Python, and
allocations larger than 256 bytes are not. The maximum size was
actually 64 bytes at first.After that, dicts grew an embedded
8-element table, which vastly increased the size of the dict struct. 
obmalloc's limit was boosted to 256 then, although it could have
stopped at the size of a dict (in the rough ballpark of 150 bytes). 
There was no reason (then or now) to go beyond 256.

>> * At the size of the allocated memory close to maximal, the
>> allocation of blocks becomes inefficient. For example, for the
>> sizesof blocks 248 and 256 (blocksize), values of quantity of
>> elements (PAGESIZE/blocksize) it is equal 16. I.e. it would be
>> possible to use for the sizes of the block 248 same page, as for the
>> size of the block 256.

> Good idea; that shouldn't be too difficult to implement: for sizes above
> 215, pools need to be spaced apart only at 16 bytes.

I'd rather drop the limit to 215 then <0.3 wink>.  Allocations that
large probably still aren't important to obmalloc, but it is important
that finding a requested allocation's "size index" be as cheap as
possible.  Uniformity helps that.

On modern boxes, it may be desirable to boost POOL_SIZE -- nobody has
run timing experiments as comprehensive as Vladimir ran way back when,
and there's no particular reason to believe that the same set of
tradeoffs would look best on current architectures.
___
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] 2.5 open issues

[Collin Winter]

On 4/28/06, Neal Norwitz <[EMAIL PROTECTED]> wrote:
> There's no owner for these items.  If no one takes them, they won't
> get done and I will move them to deferred within a week:
>
>   * Add @decorator decorator to functional, rename to functools?
> What's the benefit of @decorator?  Who made functional?  It's new
> in 2.5, right?  If so, move it or it will be functional for all 2.x.

The PEP responsible for functional (PEP 309) was written by Peter
Harris, with the partial class (the module's sole member for a while)
coded by Hye-Shik Chang and Raymond Hettinger. Comments in the module
list Hye-Shik Chang as the maintainer.

I'd very much like to see functional renamed to functools, and I've
cooked up the necessary changes to handle the move (SF #1478788).

Collin Winter
___
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] 2.5 open issues

[Tim Peters]

[Georg Brandl]
>> As I posted here previously, I contacted the owner, and he said that he
>> didn't care about specifying a license. I guess that means that we can
>> pick one ;)

[Martin v. Löwis]
> Can you please ask whether he would be willing to fill out a contrib
> form (http://www.python.org/psf/contrib/contrib-form/)? Without
> some kind of explicit contribution, I hesitate to use it.

Me too, but stronger than hesitation.  Georg, if he doesn't sign a
contrib form, we have no legal right to distribute his work, or to
license Python's users to (re)distribute it either.  That's just the
way the world works.

Or if the fellow just doesn't want to bother picking the "initial
license" the contrib form requires, tell him to pick the Academic Free
License, Version 2.1.  Well, you should actually ask him to ask his
lawyer to decide that with him, but since I'm not on hallucinogens at
the moment, making the choice for him is the only thing that will work
in the real world -- it just has to look like it was his choice ;-)
___
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] Float formatting and #

[Tim Peters]

[Georg Brandl]
> ...
> Reviewing the printf man page, this is okay since for %f, the precision is the
> number of digits after the decimal point while for %g, it is the number of
> significant digits. Still, that should be documented in the Python manual.

Well, there are a lot of little details in C's formats.  Filling in
the gaps people happen to notice is one way to proceed; another is to
point to external docs for C's rules, like

http://www-ccs.ucsd.edu/c/lib_prin.html#Print%20Functions
___
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