Re: [Python-Dev] PEP 382: Namespace Packages

2009-04-15 Thread M.-A. Lemburg 
On 2009-04-15 02:32, P.J. Eby wrote:
> At 10:59 PM 4/14/2009 +0200, M.-A. Lemburg wrote:
>> You are missing the point: When breaking up a large package that lives in
>> site-packages into smaller distribution bundles, you don't need namespace
>> packages at all, so the PEP doesn't apply.
>>
>> The way this works is by having a base distribution bundle that includes
>> the needed __init__.py file and a set of extension bundles the add
>> other files to the same directory (without including another copy of
>> __init__.py). The extension bundles include a dependency on the base
>> package to make sure that it always gets installed first.
> 
> If we're going to keep that practice, there's no point to having the
> PEP: all three methods (base+extensions, pkgutil, setuptools) all work
> just fine as they are, with no changes to importing or the stdlib.

Again: the PEP is about creating a standard for namespace
packages. It's not about making namespace packages easy to use for
Linux distribution maintainers. Instead, it's targeting *developers*
that want to enable shipping a single package in multiple, separate
pieces, giving the user the freedom to the select the ones she needs.

Of course, this is possible today using various other techniques. The
point is that there is no standard for namespace packages and that's
what the PEP is trying to solve.

> In particular, without the feature of being able to drop that practice,
> there would be no reason for setuptools to adopt the PEP.  That's why
> I'm -1 on your proposal: it's actually inferior to the methods we
> already have today.

It's simpler and more in line with the Python Zen, not inferior.

You are free not to support it in setuptools - the methods
implemented in setuptools will continue to work as they are,
but continue to require support code and, over time, no longer
be compatible with other tools building upon the standard
defined in the PEP.

In the end, it's the user that decides: whether to go with a
standard or not.

-- 
Marc-Andre Lemburg
eGenix.com

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

2009-03-19: Released mxODBC.Connect 1.0.1  http://python.egenix.com/

::: Try our new mxODBC.Connect Python Database Interface for free ! 


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   http://www.egenix.com/company/contact/
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] IDLE timeout.

2009-04-15 Thread Alessio Giovanni Baroni 
Hi to all,
I write on this list, because the error concerns the internals (I think).
The IDLE has a strange behaviour. Sometimes, randomly, the IDLE restart the
interpreter, with the follow exception on console:


Unhandled server exception!
Thread: SockThread
Client Address:  ('127.0.0.1', 8833)
Request:  
Traceback (most recent call last):
  File "/opt/python301/lib/python3.0/socketserver.py", line 281, in
_handle_request_noblock
self.process_request(request, client_address)
  File "/opt/python301/lib/python3.0/socketserver.py", line 307, in
process_request
self.finish_request(request, client_address)
  File "/opt/python301/lib/python3.0/socketserver.py", line 320, in
finish_request
self.RequestHandlerClass(request, client_address, self)
  File "/opt/python301/lib/python3.0/idlelib/rpc.py", line 503, in __init__
socketserver.BaseRequestHandler.__init__(self, sock, addr, svr)
  File "/opt/python301/lib/python3.0/socketserver.py", line 614, in __init__
self.handle()
  File "/opt/python301/lib/python3.0/idlelib/run.py", line 259, in handle
rpc.RPCHandler.getresponse(self, myseq=None, wait=0.05)
  File "/opt/python301/lib/python3.0/idlelib/rpc.py", line 280, in
getresponse
response = self._getresponse(myseq, wait)
  File "/opt/python301/lib/python3.0/idlelib/rpc.py", line 300, in
_getresponse
response = self.pollresponse(myseq, wait)
  File "/opt/python301/lib/python3.0/idlelib/rpc.py", line 424, in
pollresponse
message = self.pollmessage(wait)
  File "/opt/python301/lib/python3.0/idlelib/rpc.py", line 376, in
pollmessage
packet = self.pollpacket(wait)
  File "/opt/python301/lib/python3.0/idlelib/rpc.py", line 347, in
pollpacket
r, w, x = select.select([self.sock.fileno()], [], [], wait)
select.error: (4, 'Interrupted system call')

*** Unrecoverable, server exiting!


There isn't a specific reason; IDLE restart when I write some code, or when
I insert a return, or also when I do nothing.
If it is a bug, I don't know how to compile a test case, because the error
is randomly.

Thanks to all.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] IDLE timeout.

2009-04-15 Thread Ivan Krstić 

On Apr 15, 2009, at 10:05 AM, Alessio Giovanni Baroni wrote:

r, w, x = select.select([self.sock.fileno()], [], [], wait)
select.error: (4, 'Interrupted system call')



See here for an explanation of the same problem in another module:


Sounds like you ought to file a bug against IDLE to have it grow EINTR  
handling. Cheers,


--
Ivan Krstić  | http://radian.org

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

Re: [Python-Dev] IDLE timeout.

2009-04-15 Thread Alessio Giovanni Baroni 
Ah, sometimes, the exception raised is following (slightly different from
previous):

Exception in Tkinter callback
Traceback (most recent call last):
  File "/opt/python301/lib/python3.0/tkinter/__init__.py", line 1399, in
__call__
return self.func(*args)
  File "/opt/python301/lib/python3.0/tkinter/__init__.py", line 487, in
callit
func(*args)
  File "/opt/python301/lib/python3.0/idlelib/PyShell.py", line 490, in
poll_subprocess
response = clt.pollresponse(self.active_seq, wait=0.05)
  File "/opt/python301/lib/python3.0/idlelib/rpc.py", line 424, in
pollresponse
message = self.pollmessage(wait)
  File "/opt/python301/lib/python3.0/idlelib/rpc.py", line 376, in
pollmessage
packet = self.pollpacket(wait)
  File "/opt/python301/lib/python3.0/idlelib/rpc.py", line 347, in
pollpacket
r, w, x = select.select([self.sock.fileno()], [], [], wait)
select.error: (4, 'Interrupted system call')

In this case the IDLE not respond, because the python interpreter is not
restarted. I must to close all :-(.
I will open a issue in the tracker relative to IDLE for now?

Regards.


2009/4/15 Ivan Krstić 

> On Apr 15, 2009, at 10:05 AM, Alessio Giovanni Baroni wrote:
>
>>r, w, x = select.select([self.sock.fileno()], [], [], wait)
>> select.error: (4, 'Interrupted system call')
>>
>
>
> See here for an explanation of the same problem in another module:
> 
>
> Sounds like you ought to file a bug against IDLE to have it grow EINTR
> handling. Cheers,
>
> --
> Ivan Krstić  | http://radian.org
>
>
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 382: Namespace Packages

2009-04-15 Thread P.J. Eby 

At 09:51 AM 4/15/2009 +0200, M.-A. Lemburg wrote:

On 2009-04-15 02:32, P.J. Eby wrote:
> At 10:59 PM 4/14/2009 +0200, M.-A. Lemburg wrote:
>> You are missing the point: When breaking up a large package that lives in
>> site-packages into smaller distribution bundles, you don't need namespace
>> packages at all, so the PEP doesn't apply.
>>
>> The way this works is by having a base distribution bundle that includes
>> the needed __init__.py file and a set of extension bundles the add
>> other files to the same directory (without including another copy of
>> __init__.py). The extension bundles include a dependency on the base
>> package to make sure that it always gets installed first.
>
> If we're going to keep that practice, there's no point to having the
> PEP: all three methods (base+extensions, pkgutil, setuptools) all work
> just fine as they are, with no changes to importing or the stdlib.

Again: the PEP is about creating a standard for namespace
packages. It's not about making namespace packages easy to use for
Linux distribution maintainers. Instead, it's targeting *developers*
that want to enable shipping a single package in multiple, separate
pieces, giving the user the freedom to the select the ones she needs.

Of course, this is possible today using various other techniques. The
point is that there is no standard for namespace packages and that's
what the PEP is trying to solve.

> In particular, without the feature of being able to drop that practice,
> there would be no reason for setuptools to adopt the PEP.  That's why
> I'm -1 on your proposal: it's actually inferior to the methods we
> already have today.

It's simpler and more in line with the Python Zen, not inferior.

You are free not to support it in setuptools - the methods
implemented in setuptools will continue to work as they are,
but continue to require support code and, over time, no longer
be compatible with other tools building upon the standard
defined in the PEP.

In the end, it's the user that decides: whether to go with a
standard or not.


Up until this point, I've been trying to help you understand the use 
cases, but it's clear now that you already understand them, you just 
don't care.


That wouldn't be a problem if you just stayed on the sidelines, 
instead of actively working to make those use cases more difficult 
for everyone else than they already are.


Anyway, since you clearly understand precisely what you're doing, I'm 
now going to stop trying to explain things, as my responses are 
apparently just encouraging you, and possibly convincing bystanders 
that there's some genuine controversy here as well.


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

Re: [Python-Dev] Why does read() return bytes instead of bytearray?

2009-04-15 Thread R. David Murray 

On Tue, 14 Apr 2009 at 22:05, Dan Eloff wrote:

No, the read() method did not change from the 2.x series. It returns a new 
object on each call.


I think you misunderstand me, but the readinto() method looks like a
perfectly reasonable solution, I didn't realize it existed, as it's
not in the library reference on file objects. Thanks for enlightening
me, I feel a little stupid now :)


You have to follow the link from that section to the 'io' module to find
it.

The io module is about streams and is therefore in the 'generic operating
system services' section, not the 'file and directory access section',
which makes it a little harder to find when what you think you want to
know about is file access...I think this is a doc bug but I'm completely
unsure what would be a good fix.

--David
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] RELEASED Python 2.6.2

2009-04-15 Thread Barry Warsaw 
On behalf of the Python community, I'm happy to announce the  
availability of Python 2.6.2.  This is the latest production-ready  
version in the Python 2.6 series.  Dozens of issues have been fixed  
since Python 2.6.1 was released back in December.  Please see the NEWS  
file for all the gory details.


http://www.python.org/download/releases/2.6.2/NEWS.txt

For more information on Python 2.6 in general, please see

 http://docs.python.org/dev/whatsnew/2.6.html

Source tarballs, Windows installers, and (soon) Mac OS X disk images  
can be downloaded from the Python 2.6.2 page:


http://www.python.org/download/releases/2.6.2/

Please report bugs for any Python version in the Python tracker:

http://bugs.python.org

Enjoy,
-Barry

Barry Warsaw
[email protected]
Python 2.6/3.0 Release Manager
(on behalf of the entire python-dev team)



PGP.sig
Description: This is a digitally signed message part
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 382: Namespace Packages

2009-04-15 Thread Aahz 
[much quote-trimming, the following is intended to just give the gist,
but the bits quoted below are not in directe response to each other]

On Wed, Apr 15, 2009, P.J. Eby wrote:
> At 09:51 AM 4/15/2009 +0200, M.-A. Lemburg wrote:
>> 
>>  [...]
>> Again: the PEP is about creating a standard for namespace
>> packages. It's not about making namespace packages easy to use for
>> Linux distribution maintainers. Instead, it's targeting *developers*
>> that want to enable shipping a single package in multiple, separate
>> pieces, giving the user the freedom to the select the ones she needs.
>>  [...]
>
>  [...]
> Anyway, since you clearly understand precisely what you're doing, I'm  
> now going to stop trying to explain things, as my responses are  
> apparently just encouraging you, and possibly convincing bystanders that 
> there's some genuine controversy here as well.

For the benefit of us bystanders, could you summarize your vote at this
point?  Given the PEP's intended goals, if you do not oppose the PEP, are
there any changes you think should be made?
-- 
Aahz ([email protected])   <*> http://www.pythoncraft.com/

Why is this newsgroup different from all other newsgroups?
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 382: Namespace Packages

2009-04-15 Thread M.-A. Lemburg 
On 2009-04-15 16:44, P.J. Eby wrote:
> At 09:51 AM 4/15/2009 +0200, M.-A. Lemburg wrote:
>> On 2009-04-15 02:32, P.J. Eby wrote:
>> > At 10:59 PM 4/14/2009 +0200, M.-A. Lemburg wrote:
>> >> You are missing the point: When breaking up a large package that
>> lives in
>> >> site-packages into smaller distribution bundles, you don't need
>> namespace
>> >> packages at all, so the PEP doesn't apply.
>> >>
>> >> The way this works is by having a base distribution bundle that
>> includes
>> >> the needed __init__.py file and a set of extension bundles the add
>> >> other files to the same directory (without including another copy of
>> >> __init__.py). The extension bundles include a dependency on the base
>> >> package to make sure that it always gets installed first.
>> >
>> > If we're going to keep that practice, there's no point to having the
>> > PEP: all three methods (base+extensions, pkgutil, setuptools) all work
>> > just fine as they are, with no changes to importing or the stdlib.
>>
>> Again: the PEP is about creating a standard for namespace
>> packages. It's not about making namespace packages easy to use for
>> Linux distribution maintainers. Instead, it's targeting *developers*
>> that want to enable shipping a single package in multiple, separate
>> pieces, giving the user the freedom to the select the ones she needs.
>>
>> Of course, this is possible today using various other techniques. The
>> point is that there is no standard for namespace packages and that's
>> what the PEP is trying to solve.
>>
>> > In particular, without the feature of being able to drop that practice,
>> > there would be no reason for setuptools to adopt the PEP.  That's why
>> > I'm -1 on your proposal: it's actually inferior to the methods we
>> > already have today.
>>
>> It's simpler and more in line with the Python Zen, not inferior.
>>
>> You are free not to support it in setuptools - the methods
>> implemented in setuptools will continue to work as they are,
>> but continue to require support code and, over time, no longer
>> be compatible with other tools building upon the standard
>> defined in the PEP.
>>
>> In the end, it's the user that decides: whether to go with a
>> standard or not.
> 
> Up until this point, I've been trying to help you understand the use
> cases, but it's clear now that you already understand them, you just
> don't care.
> 
> That wouldn't be a problem if you just stayed on the sidelines, instead
> of actively working to make those use cases more difficult for everyone
> else than they already are.
> 
> Anyway, since you clearly understand precisely what you're doing, I'm
> now going to stop trying to explain things, as my responses are
> apparently just encouraging you, and possibly convincing bystanders that
> there's some genuine controversy here as well.

Hopefully, bystanders will understand that the one single use case
you are always emphasizing, namely that of Linux distribution maintainers
trying to change the package installation layout, is really a rather
uncommon and rare use case.

It is true that I do understand what the namespace package idea is
all about. I've been active in Python package development since they
were first added to Python as a new built-in import feature in Python 1.5
and have been distributing packages with package add-ons for more than
a decade...

For some history, have a look at:

http://www.python.org/doc/essays/packages.html

Also note how that essay discourages the use of .pth files:

"""
If the package really requires adding one or more directories on sys.path (e.g.
because it has not yet been structured to support dotted-name import), a "path
configuration file" named package.pth can be placed in either the site-python or
site-packages directory.
...
A typical installation should have no or very few .pth files or something is
wrong, and if you need to play with the search order, something is very wrong.
"""

Back to the PEP:

The much more common use case is that of wanting to have a base package
installation which optional add-ons that live in the same logical
package namespace.

The PEP provides a way to solve this use case by giving both developers
and users a standard at hand which they can follow without having to
rely on some non-standard helpers and across Python implementations.

My proposal tries to solve this without adding yet another .pth
file like mechanism - hopefully in the spirit of the original Python
package idea.

-- 
Marc-Andre Lemburg
eGenix.com

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

2009-03-19: Released mxODBC.Connect 1.0.1  http://python.egenix.com/

::: Try our new mxODBC.Connect Python Data

[Python-Dev] Python Bug Day on April 23

2009-04-15 Thread Georg Brandl 
Hi,

I'd like to announce that there will be a Python Bug Day on April 23.
As always, this is a perfect opportunity to get involved in Python
development, or bring your own issues to attention, discuss them and
(hopefully) resolve them together with the core developers.

We will coordinate over IRC, in #python-dev on irc.freenode.net,
and the Wiki page http://wiki.python.org/moin/PythonBugDay has all
important information and a short list of steps how to get set up.

Please spread the word!

Georg
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 382: Namespace Packages

2009-04-15 Thread P.J. Eby 

At 09:10 AM 4/15/2009 -0700, Aahz wrote:

For the benefit of us bystanders, could you summarize your vote at this
point?  Given the PEP's intended goals, if you do not oppose the PEP, are
there any changes you think should be made?


I'm +1 on Martin's original version of the PEP, subject to the point 
brought up by someone that .pkg should be changed to a different extension.


I'm -1 on all of MAL's proposed revisions, as IMO they are a step 
backwards: they "standardize" an approach that will create problems 
that don't need to exist, and don't exist now.  Martin's proposal is 
an improvement on the status quo, Marc's proposal is a dis-improvement.


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

Re: [Python-Dev] PEP 382: Namespace Packages

2009-04-15 Thread P.J. Eby 

At 06:15 PM 4/15/2009 +0200, M.-A. Lemburg wrote:

The much more common use case is that of wanting to have a base package
installation which optional add-ons that live in the same logical
package namespace.


Please see the large number of Zope and PEAK distributions on PyPI as 
minimal examples that disprove this being the common use case.  I 
expect you will find a fair number of others, as well.


In these cases, there is NO "base package"...  the entire point of 
using namespace packages for these distributions is that a "base 
package" is neither necessary nor desirable.


In other words, the "base package" scenario is the exception these 
days, not the rule.  I actually know specifically of only one other 
such package besides your mx.* case, the logilab ll.* package.


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

Re: [Python-Dev] PEP 382: Namespace Packages

2009-04-15 Thread M.-A. Lemburg 
On 2009-04-15 19:38, James Y Knight wrote:
> 
> On Apr 15, 2009, at 12:15 PM, M.-A. Lemburg wrote:
> 
>> The much more common use case is that of wanting to have a base package
>> installation which optional add-ons that live in the same logical
>> package namespace.
>>
>> The PEP provides a way to solve this use case by giving both developers
>> and users a standard at hand which they can follow without having to
>> rely on some non-standard helpers and across Python implementations.
> 
> I'm not sure I understand what advantage your proposal gives over the
> current mechanism for doing this.
> 
> That is, add to your __init__.py file:
> 
> from pkgutil import extend_path
> __path__ = extend_path(__path__, __name__)
> 
> Can you describe the intended advantages over the status-quo a bit more
> clearly?

Simple: you don't need the above lines in your __init__.py file
anymore and can rely on a Python standard for namespace packages
instead of some helper implementation.

The fact that you have a __pkg__.py file in your package dir
will signal the namespace package character to Python's importer
and this will take care of the lookup process for you.

Namespace packages will be just as easy to write, install and
maintain as regular Python packages.

-- 
Marc-Andre Lemburg
eGenix.com

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

2009-03-19: Released mxODBC.Connect 1.0.1  http://python.egenix.com/

::: Try our new mxODBC.Connect Python Database Interface for free ! 


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   http://www.egenix.com/company/contact/
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 382: Namespace Packages

2009-04-15 Thread James Y Knight 


On Apr 15, 2009, at 12:15 PM, M.-A. Lemburg wrote:

The much more common use case is that of wanting to have a base  
package

installation which optional add-ons that live in the same logical
package namespace.

The PEP provides a way to solve this use case by giving both  
developers

and users a standard at hand which they can follow without having to
rely on some non-standard helpers and across Python implementations.


I'm not sure I understand what advantage your proposal gives over the  
current mechanism for doing this.


That is, add to your __init__.py file:

from pkgutil import extend_path
__path__ = extend_path(__path__, __name__)

Can you describe the intended advantages over the status-quo a bit  
more clearly?


James
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 382: Namespace Packages

2009-04-15 Thread M.-A. Lemburg 
On 2009-04-15 19:59, P.J. Eby wrote:
> At 06:15 PM 4/15/2009 +0200, M.-A. Lemburg wrote:
>> The much more common use case is that of wanting to have a base package
>> installation which optional add-ons that live in the same logical
>> package namespace.
> 
> Please see the large number of Zope and PEAK distributions on PyPI as
> minimal examples that disprove this being the common use case.  I expect
> you will find a fair number of others, as well.
> 
> In these cases, there is NO "base package"...  the entire point of using
> namespace packages for these distributions is that a "base package" is
> neither necessary nor desirable.
> 
> In other words, the "base package" scenario is the exception these days,
> not the rule.  I actually know specifically of only one other such
> package besides your mx.* case, the logilab ll.* package.

So now you're arguing against having base packages... at least you've
dropped the strange idea of using Linux distribution maintainers
as central use case ;-)

Think of base namespace packages (the ones providing the __init__.py
file) as defining the namespace. They setup ownership and the basic
infrastructure needed by add-ons.

If you take Zope as example, the Products/ package dir is a good
example: the __init__.py file in that directory is provided by the
Zope installation (generated during Zope instance creation), so Zope
"owns" the package.

With the proposal, Zope could declare this package dir a namespace
base package by adding a __pkg__.py file to it.

Zope add-ons could then be installed somewhere else on sys.path
and include a Products/ dir as well, only this time it doesn't have
the __init__.py file, but only a __pkg__.py file.

Python would then take care of integrating the add-on Products/ dir
Python module/package contents with the base package.

-- 
Marc-Andre Lemburg
eGenix.com

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

2009-03-19: Released mxODBC.Connect 1.0.1  http://python.egenix.com/

::: Try our new mxODBC.Connect Python Database Interface for free ! 


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   http://www.egenix.com/company/contact/
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 382: Namespace Packages

2009-04-15 Thread A.M. Kuchling 
On Wed, Apr 15, 2009 at 01:59:34PM -0400, P.J. Eby wrote:
> Please see the large number of Zope and PEAK distributions on PyPI as  
> minimal examples that disprove this being the common use case.  I expect 
> you will find a fair number of others, as well.
   ...
> In other words, the "base package" scenario is the exception these days, 
> not the rule.  I actually know specifically of only one other such 
> package besides your mx.* case, the logilab ll.* package.

Isn't that pretty even, then?  zope.* and PEAK are two examples of one
approach; and mx.* and ll.* are two examples that use the base package
approach.  Neither approach seems to be the more common one, and both
are pretty rare.

--amk
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Correction: Python Bug Day on April 25

2009-04-15 Thread Georg Brandl 
Hi,

I managed to screw up the date, so here it goes again:

I'd like to announce that there will be a Python Bug Day on April 25.
As always, this is a perfect opportunity to get involved in Python
development, or bring your own issues to attention, discuss them and
(hopefully) resolve them together with the core developers.

We will coordinate over IRC, in #python-dev on irc.freenode.net,
and the Wiki page http://wiki.python.org/moin/PythonBugDay has all
important information and a short list of steps how to get set up.

Please spread the word!

Georg

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

Re: [Python-Dev] PEP 382: Namespace Packages

2009-04-15 Thread P.J. Eby 

At 02:52 PM 4/15/2009 -0400, A.M. Kuchling wrote:

On Wed, Apr 15, 2009 at 01:59:34PM -0400, P.J. Eby wrote:
> Please see the large number of Zope and PEAK distributions on PyPI as
> minimal examples that disprove this being the common use case.  I expect
> you will find a fair number of others, as well.
   ...
> In other words, the "base package" scenario is the exception these days,
> not the rule.  I actually know specifically of only one other such
> package besides your mx.* case, the logilab ll.* package.

Isn't that pretty even, then?  zope.* and PEAK are two examples of one
approach; and mx.* and ll.* are two examples that use the base package
approach.  Neither approach seems to be the more common one, and both
are pretty rare.


If you view the package listings on PyPI, you'll see that the "pure" 
namespaces currently in use include:


alchemist.*
amplecode.*
atomisator.*
bda.*
benri.*
beyondskins.*
bliptv.*
bopen.*
borg.*
bud.*
...

This is just going down to the 'b's, looking only at packages whose 
PyPI project name reflects a nested package name, and only including 
those with entries that:


1. use setuptools,
2. declare one or more namespace packages, and
3. do not depend on some sort of "base" or "core" package.

Technically, setuptools doesn't support base packages anyway, but if 
the organization appeared to be based on a "core+plugins/addons" 
model (as opposed to "collection of packages grouped in a namespace") 
I didn't include it in the list above -- i.e., I'm bending over 
backwards to be fair in the count.


If somebody wants to do a formal count of base vs. pure, it might 
provide interesting stats.  I initially only mentioned Zope and PEAK 
because I have direct knowledge of the developers' intent regarding 
their namespace packages.


However, now that I've actually looked at a tiny sample of PyPI, it's 
clear that the actual field use of pure namespace packages has 
positively exploded since setuptools made it practical to use them.


It's unclear, however, who is using base packages besides mx.* and 
ll.*, although I'd guess from the PyPI listings that perhaps Django 
is.  (It seems that "base" packages are more likely to use a 
'base-extension' naming pattern, vs. the 'namespace.project' pattern 
used by "pure" packages.)


Of course, I am certainly not opposed to supporting base packages, 
and Martin's version of PEP 382 is a plus for setuptools because it 
would allow setuptools to better support the "base" scenario.


But pure packages are definitely not a minority; in fact, a 
superficial observation of the full PyPI list suggests that there may 
be almost as many projects using pure-namespace packages, as there 
are non-namespaced projects!


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

Re: [Python-Dev] Correction: Python Bug Day on April 25

2009-04-15 Thread Maciej Fijalkowski 
On Wed, Apr 15, 2009 at 1:10 PM, Georg Brandl  wrote:
> Hi,
>
> I managed to screw up the date, so here it goes again:
>
> I'd like to announce that there will be a Python Bug Day on April 25.
> As always, this is a perfect opportunity to get involved in Python
> development, or bring your own issues to attention, discuss them and
> (hopefully) resolve them together with the core developers.
>
> We will coordinate over IRC, in #python-dev on irc.freenode.net,
> and the Wiki page http://wiki.python.org/moin/PythonBugDay has all
> important information and a short list of steps how to get set up.
>
> Please spread the word!
>
> Georg
>
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/fijall%40gmail.com
>

Are you aware that this directly conflicts with TurboGears world-wide sprint?

Not sure if this is relevant, just a notice.

Cheers,
fijal
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Correction: Python Bug Day on April 25

2009-04-15 Thread Georg Brandl 
Maciej Fijalkowski schrieb:
> On Wed, Apr 15, 2009 at 1:10 PM, Georg Brandl  wrote:
>> Hi,
>>
>> I managed to screw up the date, so here it goes again:
>>
>> I'd like to announce that there will be a Python Bug Day on April 25.

> Are you aware that this directly conflicts with TurboGears world-wide sprint?
> 
> Not sure if this is relevant, just a notice.

I have been made aware :)

I don't think it will be much of a problem though.

Georg

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

Re: [Python-Dev] PEP 382: Namespace Packages

2009-04-15 Thread Tarek Ziadé 
On Wed, Apr 15, 2009 at 9:22 PM, P.J. Eby  wrote:
> At 02:52 PM 4/15/2009 -0400, A.M. Kuchling wrote:
>>
>> On Wed, Apr 15, 2009 at 01:59:34PM -0400, P.J. Eby wrote:
>> > Please see the large number of Zope and PEAK distributions on PyPI as
>> > minimal examples that disprove this being the common use case.  I expect
>> > you will find a fair number of others, as well.
>>   ...
>> > In other words, the "base package" scenario is the exception these days,
>> > not the rule.  I actually know specifically of only one other such
>> > package besides your mx.* case, the logilab ll.* package.
>>
>> Isn't that pretty even, then?  zope.* and PEAK are two examples of one
>> approach; and mx.* and ll.* are two examples that use the base package
>> approach.  Neither approach seems to be the more common one, and both
>> are pretty rare.
>
> If you view the package listings on PyPI, you'll see that the "pure"
> namespaces currently in use include:
>
> alchemist.*
> amplecode.*
> atomisator.*
> bda.*
> benri.*
> beyondskins.*
> bliptv.*
> bopen.*
> borg.*
> bud.*
> ...
>
> This is just going down to the 'b's, looking only at packages whose PyPI
> project name reflects a nested package name, and only including those with
> entries that:
>
> 1. use setuptools,
> 2. declare one or more namespace packages, and
> 3. do not depend on some sort of "base" or "core" package.
>
> Technically, setuptools doesn't support base packages anyway, but if the
> organization appeared to be based on a "core+plugins/addons" model (as
> opposed to "collection of packages grouped in a namespace") I didn't include
> it in the list above -- i.e., I'm bending over backwards to be fair in the
> count.
>
> If somebody wants to do a formal count of base vs. pure, it might provide
> interesting stats.  I initially only mentioned Zope and PEAK because I have
> direct knowledge of the developers' intent regarding their namespace
> packages.
>
> However, now that I've actually looked at a tiny sample of PyPI, it's clear
> that the actual field use of pure namespace packages has positively exploded
> since setuptools made it practical to use them.
>
> It's unclear, however, who is using base packages besides mx.* and ll.*,
> although I'd guess from the PyPI listings that perhaps Django is.  (It seems
> that "base" packages are more likely to use a 'base-extension' naming
> pattern, vs. the 'namespace.project' pattern used by "pure" packages.)
>
> Of course, I am certainly not opposed to supporting base packages, and
> Martin's version of PEP 382 is a plus for setuptools because it would allow
> setuptools to better support the "base" scenario.
>
> But pure packages are definitely not a minority; in fact, a superficial
> observation of the full PyPI list suggests that there may be almost as many
> projects using pure-namespace packages, as there are non-namespaced
> projects!
>

In the survey I have done on packaging, 34% of the people that
answered are using setuptools namespace
feature, which currently makes it impossible to use the namespace for
the base package.

Now for the "base" or "core" package, what peoplethat uses setuptools
do most of the time:

1- they use zc.buildout so they don't need a base package : they list
in a configuration files all packages needed
   to build the application, and one of these package happen to have
the scripts to launch the application.

2 - they have a "main" package that doesn't use the same namespace,
but uses setuptools instal_requires metadata
 to include namespaced packages. It acts like zc.buildout in some ways.

For example, you mentioned atomisator.* in your example, this app has
a main package called "Atomisator" (notice the upper A)
that uses strategy #2

But frankly, the "base package" scenario is not spread these days
simply because it's not obvious to
do it without depending on a OS that has its own strategy to install packages.
For example, if you are not under debian, it's a pain to use logilab
packages because
they use this common namespace for several packages and a plain python
installation of the various packages
won't work out of the box under other systems like windows. (and for
pylint, I ended up creating my own distribution for windows...)

So :
- having namespaces natively in Python is a big win (Namespaces are
one honking great idea -- let's do more of those!)
- being able to still write some code under the primary namespace is
something I (and lots of people) wish we could do
  with setuptools, so it's a big win too.

Regards,
Tarek
-- 
Tarek Ziadé | http://ziade.org
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 382: Namespace Packages

2009-04-15 Thread M.-A. Lemburg 
On 2009-04-15 21:22, P.J. Eby wrote:
> At 02:52 PM 4/15/2009 -0400, A.M. Kuchling wrote:
>> On Wed, Apr 15, 2009 at 01:59:34PM -0400, P.J. Eby wrote:
>> > Please see the large number of Zope and PEAK distributions on PyPI as
>> > minimal examples that disprove this being the common use case.  I
>> expect
>> > you will find a fair number of others, as well.
>>...
>> > In other words, the "base package" scenario is the exception these
>> days,
>> > not the rule.  I actually know specifically of only one other such
>> > package besides your mx.* case, the logilab ll.* package.
>>
>> Isn't that pretty even, then?  zope.* and PEAK are two examples of one
>> approach; and mx.* and ll.* are two examples that use the base package
>> approach.  Neither approach seems to be the more common one, and both
>> are pretty rare.
> 
> If you view the package listings on PyPI, you'll see that the "pure"
> namespaces currently in use include:
> 
> alchemist.*
> amplecode.*
> atomisator.*
> bda.*
> benri.*
> beyondskins.*
> bliptv.*
> bopen.*
> borg.*
> bud.*
> ...
> 
> This is just going down to the 'b's, looking only at packages whose PyPI
> project name reflects a nested package name, and only including those
> with entries that:
> 
> 1. use setuptools,
> 2. declare one or more namespace packages, and
> 3. do not depend on some sort of "base" or "core" package.
> 
> Technically, setuptools doesn't support base packages anyway, but if the
> organization appeared to be based on a "core+plugins/addons" model (as
> opposed to "collection of packages grouped in a namespace") I didn't
> include it in the list above -- i.e., I'm bending over backwards to be
> fair in the count.

Hmm, setuptools doesn't support the notion of base packages, ie.
packages that provide their own __init__.py module, so I fail
to see how your list or any other list of setuptools-depend
packages can be taken as indicator for anything related to
base packages.

Since setuptools probably introduced the idea of namespace
sharing packages to many authors in the first place, such
a list is even less appropriate to use as sample base.

That said, I don't think such statistics provide any useful
information to decide on the namespace import strategy standard
for Python which is the subject of the PEP.

They just show that one helper-based mechanism is used more than
others and that's simply a consequence of there not being a
standard built-in way of using namespace packages in Python.

Whether base packages are useful or not is really a side aspect
of the PEP and my proposal. I'm more after a method that doesn't
add more .pkg file cruft to Python's import mechanism.

Those .pth files were originally meant to help older Python "packages"
(think the early PIL or Numeric extensions) to integrate nicely into
the new scheme without having to fully support dotted package names
right from the start.

-- 
Marc-Andre Lemburg
eGenix.com

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

2009-03-19: Released mxODBC.Connect 1.0.1  http://python.egenix.com/

::: Try our new mxODBC.Connect Python Database Interface for free ! 


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   http://www.egenix.com/company/contact/
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Why does read() return bytes instead of bytearray?

2009-04-15 Thread Benjamin Peterson 
2009/4/15 R. David Murray :
> On Tue, 14 Apr 2009 at 22:05, Dan Eloff wrote:
>>>
>>> No, the read() method did not change from the 2.x series. It returns a
>>> new object on each call.
>>
>> I think you misunderstand me, but the readinto() method looks like a
>> perfectly reasonable solution, I didn't realize it existed, as it's
>> not in the library reference on file objects. Thanks for enlightening
>> me, I feel a little stupid now :)
>
> You have to follow the link from that section to the 'io' module to find
> it.
>
> The io module is about streams and is therefore in the 'generic operating
> system services' section, not the 'file and directory access section',
> which makes it a little harder to find when what you think you want to
> know about is file access...I think this is a doc bug but I'm completely
> unsure what would be a good fix.

I've added a like to the io module in the see also section of the file
and directory systems.



-- 
Regards,
Benjamin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] RELEASED Python 2.6.2

2009-04-15 Thread Russell E. Owen 
Thank you for 2.6.2.

I see the Mac binary installer isn't out yet (at least it is not listed 
on the downloads page). Any chance that it will be compatible with 3rd 
party Tcl/Tk?

Most recent releases have not been; the only way I know to make a 
compatible build is to build the installer on a machine that already has 
a 3rd party Tcl/Tk installed; the resulting binary is then compatible 
with both 3rd party versions of Tcl/Tk and also with Apple's ancient 
built in version.

-- Russell

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

Re: [Python-Dev] RELEASED Python 2.6.2

2009-04-15 Thread Ned Deily 
In article ,
 "Russell E. Owen"  wrote:
> I see the Mac binary installer isn't out yet (at least it is not listed 
> on the downloads page). Any chance that it will be compatible with 3rd 
> party Tcl/Tk?
> 
> Most recent releases have not been; the only way I know to make a 
> compatible build is to build the installer on a machine that already has 
> a 3rd party Tcl/Tk installed; the resulting binary is then compatible 
> with both 3rd party versions of Tcl/Tk and also with Apple's ancient 
> built in version.

Thanks for the reminder.  FWIW, that issue has recently been documented 
and there is a patch for the build script to ensure that the 3rd party 
Tcl/Tk is present during the installer build.  I don't think it made it 
into the 2.6.2 source tree, though.



-- 
 Ned Deily,
 [email protected]

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

Re: [Python-Dev] PEP 382: Namespace Packages

2009-04-15 Thread P.J. Eby 

At 10:20 PM 4/15/2009 +0200, M.-A. Lemburg wrote:

Whether base packages are useful or not is really a side aspect
of the PEP and my proposal.


It's not whether they're useful, it's whether they're required.  Your 
proposal *requires* base packages, and for people who intend to use 
pure packages, this is NOT a feature: it's a bug.


Specifically, it introduces a large number of unnecessary, 
boilerplate dependencies to their package distribution strategy.


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

Re: [Python-Dev] RELEASED Python 2.6.2

2009-04-15 Thread Barry Warsaw 

On Apr 15, 2009, at 4:47 PM, Russell E. Owen wrote:


Thank you for 2.6.2.

I see the Mac binary installer isn't out yet (at least it is not  
listed

on the downloads page). Any chance that it will be compatible with 3rd
party Tcl/Tk?

Most recent releases have not been; the only way I know to make a
compatible build is to build the installer on a machine that already  
has

a 3rd party Tcl/Tk installed; the resulting binary is then compatible
with both 3rd party versions of Tcl/Tk and also with Apple's ancient
built in version.


I can't answer this, but Ronald is building the OS X image for 2.6.2,  
AFAIK.  I think it will be out soon, and maybe he can answer your Tcl/ 
Tk question.


-Barry



PGP.sig
Description: This is a digitally signed message part
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 382: Namespace Packages

2009-04-15 Thread P.J. Eby 

At 10:00 PM 4/15/2009 +0200, Tarek Ziadé wrote:

Now for the "base" or "core" package, what peoplethat uses setuptools
do most of the time:

1- they use zc.buildout so they don't need a base package : they list
in a configuration files all packages needed
   to build the application, and one of these package happen to have
the scripts to launch the application.

2 - they have a "main" package that doesn't use the same namespace,
but uses setuptools instal_requires metadata
 to include namespaced packages. It acts like zc.buildout in some ways.

For example, you mentioned atomisator.* in your example, this app has
a main package called "Atomisator" (notice the upper A)
that uses strategy #2


I think that there is some confusion here.  A "main" package or 
buildout that assembles a larger project from components is not the 
same thing as having a "base" package for a namespace package.


A base or core package is one that is depended upon by most or all of 
the related projects.  In other words, the dependencies are in the 
*opposite direction* from what you described above.  To have a base 
package in setuptools, you would move the target code from the 
namespace package __init__.py to another module or subpackage within 
your namespace, then make all your other projects depend on the 
project containing that module or subpackage.


And I explicitly excluded from my survey any packages that were 
following this strategy, on the assumption that they might consider 
switching to an __init__.py or __pkg__.py strategy if some version of 
PEP 382 were supported by setuptools, since they already have a 
"base" or "core" project -- in that case, they are only changing ONE 
of their packages' distribution metadata to adopt the new strategy, 
because the dependencies already exist.




So :
- having namespaces natively in Python is a big win (Namespaces are
one honking great idea -- let's do more of those!)
- being able to still write some code under the primary namespace is
something I (and lots of people) wish we could do
  with setuptools, so it's a big win too.


Yes, that's why I support Martin's proposal: it would allow 
setuptools to support this case in the future, and it would also 
allow improved startup times for installations with many 
setuptools-based namespace packages installed in flat form.  (Contra 
MAL's claims of decreased performance: adopting Martin's proposal 
allows there to be *fewer* .pth files read at startup, because only 
.pkg files for an actually-imported package need to be read.)


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

Re: [Python-Dev] Why does read() return bytes instead of bytearray?

2009-04-15 Thread Lisandro Dalcin 
On Wed, Apr 15, 2009 at 12:05 AM, Dan Eloff  wrote:
>>No, the read() method did not change from the 2.x series. It returns a new 
>>object on each call.
>
> I think you misunderstand me, but the readinto() method looks like a
> perfectly reasonable solution, I didn't realize it existed, as it's
> not in the library reference on file objects. Thanks for enlightening
> me, I feel a little stupid now :)
>

However, your original question is still valid ... Why a binary read()
returns an immutable type?


-- 
Lisandro Dalcín
---
Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC)
Instituto de Desarrollo Tecnológico para la Industria Química (INTEC)
Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET)
PTLC - Güemes 3450, (3000) Santa Fe, Argentina
Tel/Fax: +54-(0)342-451.1594
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Why does read() return bytes instead of bytearray?

2009-04-15 Thread Antoine Pitrou 
Lisandro Dalcin  gmail.com> writes:
> 
> However, your original question is still valid ... Why a binary read()
> returns an immutable type?

Because bytes is the standard type for holding binary data. Bytearray should
only be used when there's a real, measured performance advantage doing so
(which, IMHO, is rarer than you think). An immutable type makes daily
programming much less error-prone.

Regards

Antoine.


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

Re: [Python-Dev] PEP 382: Namespace Packages

2009-04-15 Thread Stephen J. Turnbull 
M.-A. Lemburg writes:

 > Hmm, setuptools doesn't support the notion of base packages, ie.
 > packages that provide their own __init__.py module, so I fail
 > to see how your list or any other list of setuptools-depend
 > packages can be taken as indicator for anything related to
 > base packages.

AFAICS the only things PJE has said about base packages is that

  (a) they aren't a universal use case for namespace packages, and
  (b) he'd like to be able to support them in setuptools, but admits
  that at present they aren't.

Your arguments against the PEP supporting namespace packages as
currently supported by setuptools seem purely theoretical to me, while
he's defending an actual and common use case.  "Although practicality
beats purity."  I think that for this PEP it's more important to unify
the various use cases for namespace packages than it is to get rid of
the .pth files.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 382: Namespace Packages

2009-04-15 Thread P.J. Eby 

At 09:59 AM 4/16/2009 +0900, Stephen J. Turnbull wrote:

I think that for this PEP it's more important to unify
the various use cases for namespace packages than it is to get rid of
the .pth files.


Actually, Martin's proposal *does* get rid of the .pth files in 
site-packages, and replaces them with other files inside the 
individual packages.  (Thereby speeding startup times when many 
namespace packages are present but only a few are used.)


So Martin's proposal is a win for performance and even for decreasing 
clutter.  (The same number of special files will be present, but they 
will be moved inside the namespace package directories instead of 
being in the parent directory.)




AFAICS the only things PJE has said about base packages is that

  (a) they aren't a universal use case for namespace packages, and
  (b) he'd like to be able to support them in setuptools, but admits
  that at present they aren't.


...and that Martin's proposal would actually permit me to do so, 
whereas MAL's proposal would not.


Replacing __init__.py with a __pkg__.py wouldn't change any of the 
tradeoffs for how setuptools handles namespace packages, except to 
add an extra variable to consider (i.e., two filenames to keep track of).


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

Re: [Python-Dev] PEP 382: Namespace Packages

2009-04-15 Thread glyph 


On 15 Apr, 09:11 pm, [email protected] wrote:
I think that there is some confusion here.  A "main" package or 
buildout that assembles a larger project from components is not the 
same thing as having a "base" package for a namespace package.


I'm certainly confused.

Twisted has its own system for "namespace" packages, and I'm not really 
sure where we fall in this discussion.  I haven't been able to follow 
the whole thread, but my original understanding was that the PEP 
supports "defining packages", which we now seem to be calling "base 
packages", just fine.  I don't understand the controversy over the 
counterproposal, since it seems roughly functionally equivalent to me.


I'd appreciate it if the PEP could also be extended cover Twisted's very 
similar mechanism for namespace packages, 
"twisted.plugin.pluginPackagePaths".  I know this is not quite as widely 
used as setuptools' namespace package support, but its existence belies 
a need for standardization.


The PEP also seems a bit vague with regard to the treatment of other 
directories containing __init__.py and *.pkg files.  The concept of a 
"defining package" seems important to avoid conflicts like this one:


   http://twistedmatrix.com/trac/ticket/2339

More specifically I don't quite understand the PEP's intentions towards 
hierarchical packages.  It says that all of sys.path will be searched, 
but what about this case?


In Twisted, the suggested idiom to structure a project which wants to 
provide Twisted plugins is to have a directory structure like this:


 MyProject/
   myproject/
 __init__.py
   twisted/
 plugins/
   myproject_plugin.py

If you then put MyProject on PYTHONPATH, MyProject/twisted/plugins will 
be picked up automatically by the plugin machinery.  However, as 
"twisted" is *not* a "namespace" package in the same way, .py files in 
MyProject/twisted/ would not be picked up - this is very much 
intentional, since the "twisted" namespace is intended to be reserved 
for packages that we actually produce.  If either MyProject/twisted or 
MyProject/twisted/plugins/ had an __init__.py, then no modules in 
MyProject/twisted/plugins/ would be picked up, because it would be 
considered a conflicting package.


This is important so that users can choose not to load the system- 
installed Twisted's plugins when they have both a system-installed 
version of Twisted and a non-installed development version of Twisted 
found first on their PYTHONPATH, and switch between them to indicate 
which version they want to be the "base" or "defining" package for the 
twisted/plugins/ namespace.


Developers might also want to have a system-installed Twisted, but a 
non-installed development version of MyProject on PYTHONPATH.


I hope this all makes sense.  As I understand it, both setuptools and 
the proposed standard would either still have the bug described by 
ticket 2339 above, or would ignore twisted/plugins/ as a namespace 
package because its parent isn't a namespace package.  I apologize for 
not testing with current setuptools before asking, but I'm not sure my 
experiments would be valid given that my environment is set up with 
assumptions from Twisted's system.


P.S.: vendor packaging systems *ARE* a major use case for just about any 
aspect of Python's package structure.  I really liked MvL's coverage of 
"vendor packages", in the PEP, since this could equally well apply to 
MSIs, python libraries distributed in bundles on OS X, debs, or RPMs. 
If this use-case were to be ignored, as one particular fellow seems to 
be advocating, then the broken packages and user confusion that has been 
going on for the last 5 years or so is just going to get worse.

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

[Python-Dev] Issue5434: datetime.monthdelta

2009-04-15 Thread Jess Austin 
hi,

I'm new to python core development, and I've been advised to write to
python-dev concerning a feature/patch I've placed at
http://bugs.python.org/issue5434, with Rietveld at
http://codereview.appspot.com/25079.

This patch adds a "monthdelta" class and a "monthmod" function to the
datetime module.  The monthdelta class is much like the existing
timedelta class, except that it represents months offset from a date,
rather than an exact period offset from a date.  This allows us to
easily say, e.g. "3 months from now" without worrying about the number
of days in the intervening months.

>>> date(2008, 1, 30) + monthdelta(1)
datetime.date(2008, 2, 29)
>>> date(2008, 1, 30) + monthdelta(2)
datetime.date(2008, 3, 30)

The monthmod function, named in (imperfect) analogy to divmod, allows
us to round-trip by returning the interim between two dates
represented as a (monthdelta, timedelta) tuple:

>>> monthmod(date(2008, 1, 14), date(2009, 4, 2))
(datetime.monthdelta(14), datetime.timedelta(19))

Invariant: dt + monthmod(dt, dt+td)[0] + monthmod(dt, dt+td)[1] == dt + td

These also work with datetimes!  There are more details in the
documentation included in the patch.  In addition to the C module
file, I've updated the datetime CAPI, the documentation, and tests.

I feel this would be a good addition to core python.  In my work, I've
often ended up writing annoying one-off "add-a-month" or similar
functions.  I think since months work differently than most other time
periods, a new object is justified rather than trying to shoe-horn
something like this into timedelta.  I also think that the round-trip
functionality provided by monthmod is important to ensure that
monthdeltas are "first-class" objects.

Please let me know what you think of the idea and/or its execution.

thanks,
Jess Austin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com