[Python-Dev] Issue5434: datetime.monthdelta

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 mod

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

On 15 Apr, 09:11 pm, p...@telecommunity.com 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 sy

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

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

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

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.

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

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

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

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 > n

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

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 th

Re: [Python-Dev] RELEASED Python 2.6.2

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 ma

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

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

Re: [Python-Dev] RELEASED Python 2.6.2

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

Re: [Python-Dev] RELEASED Python 2.6.2

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 ma

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

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 did

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

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 >>

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

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

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

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-wid

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

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 issu

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

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, a

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

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 togethe

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

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 packag

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

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

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

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

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

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

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

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

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

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 p

[Python-Dev] Python Bug Day on April 23

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

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

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

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

[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 nam

[Python-Dev] RELEASED Python 2.6.2

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 de

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

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 lib

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

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 >> p

Re: [Python-Dev] IDLE timeout.

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/t

Re: [Python-Dev] IDLE timeout.

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:

[Python-Dev] IDLE timeout.

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: SockThrea

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

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