On Apr 27, 2010, at 11:43 AM, R. David Murray wrote:
>I wonder if it would be better to encourage people to post the unit
>tests and the fix as separate patch files.
I think this is not bad idea for larger fixes, where it's not trivial to
manually edit the diff.
-Barry
signature.asc
Descriptio
On Apr 27, 2010, at 02:37 PM, Tres Seaver wrote:
>You can always "shelve" the part of the patch which isn't the test: I
>do that pretty frequently in the Zope tree, where I am now doing most
>development with bzr.
Yes definitely. bzr-loom just makes that much easier to manage.
-Barry
signatu
On Apr 28, 2010, at 09:22 AM, Dirkjan Ochtman wrote:
>On Tue, Apr 27, 2010 at 23:55, Nick Coghlan wrote:
>> I believe the more important part of Barry's suggested change here is
>> requiring a link to the archived message (usually from python-dev) where
>> the PEP was accepted (be it directly by
On May 01, 2010, at 08:58 AM, Dirkjan Ochtman wrote:
>On Fri, Apr 30, 2010 at 21:09, Barry Warsaw wrote:
>>>Though maybe it should be called Conclusion instead of Accepted and
>>>used for Rejected PEPs, as well?
>>
>> Good point. What do you think about &#x
On Apr 30, 2010, at 04:28 PM, Steve Holden wrote:
>Martin v. Löwis wrote:
>>> As to Guido's point about the decision making process, Nick's right. I just
>>> want to make sure we can capture the resolution in the PEP, be it by BDFL
>>> pronouncement or "hey, silence is acceptance" email.
>>
>> I
On May 01, 2010, at 07:12 AM, Martin v. Löwis wrote:
>> IIRC in the IETF this is done by the committee chair. I think it's a
>> good idea to have this be a single person to avoid endless indecision.
>
>It then seems that this role should go to the release manager of the
>upcoming feature release.
On May 03, 2010, at 10:12 PM, Steve Holden wrote:
>Antoine Pitrou wrote:
>> Le Mon, 03 May 2010 16:11:53 -0700, Brett Cannon a écrit :
>>> And in reply to Benjamin's question about the whitespace, I guess it
>>> actually doesn't matter. More important to clean up in py3k.
>>
>> Would it be finall
On May 04, 2010, at 07:16 AM, Martin v. Löwis wrote:
>I think Mercurial chokes in the light of white space inconsistencies
>just as much as Subversion. One reason for not converting in the past
>was also that it would break merging, unless that whitespace
>normalization is applied to all these bra
On May 5, 2010, at 7:09 AM, Oleg Broytman wrote:
> On Wed, May 05, 2010 at 11:43:45AM +0100, Michael Foord wrote:
>> http://mail.python.org/pipermail/python-list/2000-July/108893.html
>>
>> which are broken
>
> Pipermail's links aren't stable AFAIU. The numbering is changing over
> time.
They
On May 05, 2010, at 11:35 AM, James Y Knight wrote:
>And of course if you're paying attention, you can fix the mbox file
>(quoting "From" etc) such that it generates the same numbers as it did
>the first time.
Mailman even has a command for this (I feel like an Apple commercial). You
should
On May 06, 2010, at 09:33 PM, Benjamin Peterson wrote:
>I don't think there's any point in being hypothetical about. I believe
>we've already said that maintence for 2.7 will last for at least 5
>years, so let's proclaim it.
+1. If our goal is to move our community to Python 3, then I think we d
I just wanted to let the python-dev community know about some tracks we had at
the recently concluded Ubuntu Developer Summit in Brussels. Among the several
Python-related discussions, we talked about what versions of Python will be
supported and default in the next version of Ubuntu (10.10, code
On May 20, 2010, at 12:53 PM, Guido van Rossum wrote:
>Sounds good to me, since this is (a) a security fix that will make
>some vendors happy, and (b) only a C-level API. I expect that some
>apps embedding Python will use this API unconditionally and this break
>with earlier Python versions; this
On May 20, 2010, at 06:01 PM, Terry Reedy wrote:
>On 5/20/2010 5:52 PM, Barry Warsaw wrote:
>> On May 20, 2010, at 12:53 PM, Guido van Rossum wrote:
>>
>>> Sounds good to me, since this is (a) a security fix that will make
>>> some vendors happy, and (b) only
On May 21, 2010, at 01:05 AM, Martin v. Löwis wrote:
Should we start thinking about releasing 2.6.6 soonish?
>>>
>>> By tradition, it should come out soon after 2.7 and be the last bugfix
>>> (except for security patches).
>>
>> I guess what I mean is, should we have (at least) one more point
On Jun 09, 2010, at 01:15 AM, Fred Drake wrote:
>On Wed, Jun 9, 2010 at 12:30 AM, Senthil Kumaran wrote:
>> it would still be a good idea to
>> introduce some of them in minor releases in 2.7. I know, this
>> deviating from the process, but it could be an option considering that
>> 2.7 is the las
On Jun 09, 2010, at 04:42 PM, M.-A. Lemburg wrote:
>Many of them are not keen on having to maintain Python2 for much
>longer, but some of them may have assets codified in Python2
>or interests based Python2 that they'll want to keep for
>more than just another 5 years.
>
>E.g. we still have custom
On Jun 09, 2010, at 09:13 AM, Bill Janssen wrote:
>Barry Warsaw wrote:
>
>> Note that Python 2.7 will be *maintained* for a very long time, which
>> should satisfy those folks who still require Python 2. Anybody on
>> older (and currently unmaintained) versions o
On Jun 10, 2010, at 09:01 AM, Steve Holden wrote:
>The current stumbling block isn't the language itself, it's the lack of
>support from third-party libraries. GSoC is addressing some of these
>issues, but so far we (the PSF, the dev community, anybody else except
>R. David Murray) haven't really
On Jun 16, 2010, at 08:48 PM, l...@rmi.net wrote:
>Well, it looks like I've stumbled onto the "other shoe" on this
>issue--that the email package's problems are also apparently
>behind the fact that CGI binary file uploads don't work in 3.1
>(http://bugs.python.org/issue4953). Yikes.
>
>I trust
On Jun 18, 2010, at 11:32 AM, Steve Holden wrote:
>Lest the readership think that the PSF is unaware of this issue, allow
>me to point out that we have already partially funded this effort, and
>are still offering R. David Murray some further matching funds if he can
>raise sponsorship to complete
On Jun 19, 2010, at 05:43 PM, Senthil Kumaran wrote:
>On Sat, Jun 19, 2010 at 01:51:04PM +0200, Antoine Pitrou wrote:
>> FWIW, the EOL extension is now part of Mercurial:
>> http://mercurial.selenic.com/wiki/EolExtension
>
>Should we all move soon now?
>Any target date you have in mind, Antoine?
On Jun 21, 2010, at 09:37 AM, Arc Riley wrote:
>Also, under where it mentions that most OS's do not include Python 3, it
>should be noted which have good support for it. Gentoo (for example) has
>excellent support for Python 3, automatically installing Python packages
>which have Py3 support for
On Jun 21, 2010, at 10:20 PM, Nick Coghlan wrote:
>Something that may make sense to ease the porting process is for some
>of these "on the boundary" I/O related string manipulation functions
>(such as os.path.join) to grow "encoding" keyword-only arguments. The
>recommended approach would be to pr
On Jun 21, 2010, at 1:56 PM, Bill Janssen wrote:
> Considering that we've just released 2.7rc2, there are an awful lot of
> red buildbots for 2.7. In fact, I don't remember having seen a green
> buildbot for OS X and 2.7. Shouldn't these be fixed?
>
> On OS X Leopard, I'm seeing failures in tes
On Jun 21, 2010, at 11:13 AM, Stephan Richter wrote:
>I really just want to be able to go to PyPI, Click on "Browse packages" and
>then select "Python 3" (it can currently be accomplished by clicking "Python"
>and then "3"). Of course, package developers need to be encouraged to add
>these Tro
On Jun 21, 2010, at 12:34 PM, Toshio Kuratomi wrote:
>I like the idea of having encoding information carried with the data.
>I don't think that an ebytes type that can *optionally* have an encoding
>attribute makes the situation less confusing, though.
Agreed. I think the attribute should always
On Jun 22, 2010, at 03:08 AM, Stephen J. Turnbull wrote:
>Barry Warsaw writes:
>
> > Would it make sense to have "encoding-carrying" bytes and str
> > types?
>
>Why limit that to bytes and str? Why not have all objects carry their
>serializer/deserialize
On Jun 21, 2010, at 01:24 PM, P.J. Eby wrote:
>OTOH, one potential problem with having the encoding on the bytes object
>rather than the ebytes object is that then you can't easily take bytes from a
>socket and then say what encoding they are, without interfering with the
>sockets API (or whatever
On Jun 21, 2010, at 03:29 PM, Toshio Kuratomi wrote:
>I wouldn't like this. It brings us back to the python2 problem where
>sometimes you pass an ebyte into a function and it works and other times you
>pass an ebyte into the function and it issues a traceback. The coercion
>must end up with a st
On Jun 21, 2010, at 01:17 PM, P.J. Eby wrote:
>I'm not really sure how much use the encoding is on a unicode object - what
>would it actually mean?
>
>Hm. I suppose it would effectively mean "this string can be represented in
>this encoding" -- which is useful, in that you could fail operations wh
On Jun 21, 2010, at 04:16 PM, P.J. Eby wrote:
>At 04:04 PM 6/21/2010 -0400, Barry Warsaw wrote:
>>On Jun 21, 2010, at 01:24 PM, P.J. Eby wrote:
>>
>> >OTOH, one potential problem with having the encoding on the bytes object
>> >rather than the ebytes object i
On Jun 22, 2010, at 08:03 AM, Nick Coghlan wrote:
>On Tue, Jun 22, 2010 at 6:16 AM, P.J. Eby wrote:
>> True, but making it a separate type with a required encoding gets rid of the
>> magical "I don't know" - the "I don't know" encoding is just a plain old
>> bytes object.
>
>So, to boil down the
On Jun 23, 2010, at 08:43 AM, Guido van Rossum wrote:
>So I propose that we drop the discussion "are URLs text or bytes" and
>try to find something more pragmatic to discuss.
email has exactly the same question, and the answer is "yes".
>For example: how we can make the suite of functions used
This is a follow up to PEP 3147. That PEP, already implemented in Python 3.2,
allows for Python source files from different Python versions to live together
in the same directory. It does this by putting a magic tag in the .pyc file
name and placing the .pyc file in a __pycache__ directory.
Dist
On Jun 24, 2010, at 10:58 AM, Benjamin Peterson wrote:
>2010/6/24 Barry Warsaw :
>> Please let me know what you think. I'm happy to just commit this to the
>> py3k branch if there are no objections . I don't think a new PEP is
>> in order, but an update to PEP 314
On Jun 24, 2010, at 01:00 PM, Benjamin Peterson wrote:
>2010/6/24 Barry Warsaw :
>> On Jun 24, 2010, at 10:58 AM, Benjamin Peterson wrote:
>>
>>>2010/6/24 Barry Warsaw :
>>>> Please let me know what you think. I'm happy to just commit this to the
>>
On Jun 24, 2010, at 02:28 PM, Barry Warsaw wrote:
>On Jun 24, 2010, at 01:00 PM, Benjamin Peterson wrote:
>
>>2010/6/24 Barry Warsaw :
>>> On Jun 24, 2010, at 10:58 AM, Benjamin Peterson wrote:
>>>
>>>>2010/6/24 Barry Warsaw :
>>>>> Ple
On Jun 24, 2010, at 10:48 AM, Brett Cannon wrote:
>While the idea is fine with me since I won't have any of my
>directories cluttered with multiple .so files, I would still want to
>add some moniker showing that the version number represents the
>interpreter and not the .so file. If I read "foo.3.
On Jun 24, 2010, at 11:27 AM, Guido van Rossum wrote:
>On Thu, Jun 24, 2010 at 10:48 AM, Brett Cannon wrote:
>> While the idea is fine with me since I won't have any of my
>> directories cluttered with multiple .so files, I would still want to
>> add some moniker showing that the version number r
On Jun 24, 2010, at 11:05 AM, Daniel Stutzbach wrote:
>On Thu, Jun 24, 2010 at 10:50 AM, Barry Warsaw wrote:
>
>> The idea is to put the Python version number in the shared library file
>> name,
>> and extend .so lookup to find these extended file names. So for example
On Jun 24, 2010, at 08:50 PM, Éric Araujo wrote:
>Le 24/06/2010 17:50, Barry Warsaw (FLUFL) a écrit :
>> Other possible approaches:
>> * Extend the distutils API so that the .so file extension can be passed in,
>>instead of being essentially hardcoded to what Pytho
On Jun 24, 2010, at 11:50 AM, Barry Warsaw wrote:
>Please let me know what you think. I'm happy to just commit this to the py3k
>branch if there are no objections . I don't think a new PEP is in
>order, but an update to PEP 3147 might make sense.
Thanks for all the quick f
Benjamin is still planning to release Python 2.7 final on 2010-07-03, so it's
time for me to work out the release schedule for Python 2.6.6 - likely the
last maintenance release for Python 2.6.
Because summer schedules are crazy, and I want to leave two weeks between
2.6.6 rc1 and 2.6.6 final, my
On Jun 25, 2010, at 12:18 PM, Barry Warsaw wrote:
>* Python 2.6.6 rc 1 on Monday 2010-08-02
>* Python 2.6.6 final on Monday 2010-08-16
I've also updated the Google calendar of Python releases:
http://www.google.com/calendar/ical/b6v58qvojllt0i6ql654r1vh00%40group.calendar.google
On Jun 24, 2010, at 11:37 PM, Éric Araujo wrote:
>Your plan seems good. Adding keyword arguments should not create
>compatibility issues, and I suspect the impact on the code of build_ext
>may be actually quite small. I’ll try to review your patch even though I
>don’t know C or compiler oddities,
On Jun 25, 2010, at 10:33 PM, Martin v. Löwis wrote:
>Am 25.06.2010 18:18, schrieb Barry Warsaw:
>> Benjamin is still planning to release Python 2.7 final on 2010-07-03, so it's
>> time for me to work out the release schedule for Python 2.6.6 - likely the
>> last main
On Jun 25, 2010, at 11:16 PM, Martin v. Löwis wrote:
>> Would that be bad or good (slipping into September)? I'd like to get a
>> release out as soon after 2.7 final as possible, but it's an entirely
>> self-imposed deadline. There's no reason why we can't push the whole 2.6.6
>> thing later if
On Jun 28, 2010, at 05:28 PM, M.-A. Lemburg wrote:
>How many Python users will compile Python in debug mode ?
How many Python users compile Python at all? :)
>The point is that the default build of Python should use
>the correct production settings for the C compiler out of
>the box and that's w
On Jun 28, 2010, at 06:03 PM, M.-A. Lemburg wrote:
>OPT already uses -O0 if --with-pydebug is used and the
>compiler supports -g. Since OPT gets added after CFLAGS, the override
>already happens...
So nobody's proposing to drop that? Good! Ignore my last message then. :)
-Barry
signature.asc
I'm trying to catch up on this thread, so I may collapse some responses or
refer to points others have brought up.
On Jun 24, 2010, at 05:53 PM, Scott Dial wrote:
>If the package has .so files that aren't compatible with other version
>of python, then what is the motivation for placing that in a
On Jun 26, 2010, at 10:22 PM, Matthias Klose wrote:
>On 24.06.2010 22:46, Barry Warsaw wrote:
>> So, we could say that PEP 384 compliant extension modules would get written
>> without a version specifier. IOW, we'd treat foo.so as using the ABI. It
>> would then be u
On Jun 25, 2010, at 04:53 AM, Scott Dial wrote:
>My suggestion was that a package that contains .so files should not be
>shared (e.g., the entire lxml package should be placed in a
>version-specific path).
Matthias outlined some of the pitfalls with this approach.
>The motivation for this PEP wa
On Jun 26, 2010, at 06:50 PM, Scott Dial wrote:
>On 6/26/2010 4:06 PM, Matthias Klose wrote:
>> On 25.06.2010 22:12, James Y Knight wrote:
>>> On Jun 25, 2010, at 4:53 AM, Scott Dial wrote:
Placing .so files together does not simplify that install process in any
way. You will still have
On Jun 25, 2010, at 11:58 AM, Brett Cannon wrote:
>> Placing .so files together does not simplify that install process in any
>> way. You will still have to handle such packages in a special way. You
>> must still compile the package multiple times for each relevant version
>> of python (with spec
On Jun 26, 2010, at 10:45 PM, Matthias Klose wrote:
>Having non-conflicting extension names is a schema which already is used on
>some platforms (debug builds on Windows). The question for me is, if just a
>renaming of the .so files is acceptable for upstream, or if distributors
>should implement
On Jun 25, 2010, at 03:42 PM, Scott Dial wrote:
>On 6/25/2010 2:58 PM, Brett Cannon wrote:
>> I assume you are talking about PEP 3147. You're right that the PEP was
>> for pyc files and that's it. No one is talking about rewriting the
>> PEP.
>
>Yes, I am making reference to PEP 3147. I make refer
On Jun 25, 2010, at 12:35 AM, M.-A. Lemburg wrote:
>Scott Dial wrote:
>> On 6/24/2010 5:09 PM, Barry Warsaw wrote:
>>>> What use case does this address?
>>>
>>>> If you want to make it so a system can install a package in just one
>>>> loca
On Jun 30, 2010, at 10:35 PM, M.-A. Lemburg wrote:
>The Python default installation dir for
>libs (including site-packages) is $prefix/lib/pythonX.X, so you
>already have separate and properly versioned directory paths.
>
>What difference would the extra version on the .so file make in
>such a set
On Jul 01, 2010, at 07:52 AM, Nick Coghlan wrote:
>Note that it works this way on Linux as well. On Kubuntu (for example)
>you need another half dozen or so additional *-dev packages installed
>to avoid unexpected test skips.
>
>Cheers,
>Nick.
>
>P.S. For anyone curious, I posted the list of extra
On Jul 01, 2010, at 10:57 PM, Paul Moore wrote:
>On 1 July 2010 20:58, Brett Cannon wrote:
>> Here is a *really* quick-and-dirty approach for non-committers to
>> create a patch they can submit. This is not extensively tested so
>> some other Hg expert should back me up on this before telling any
On Jul 01, 2010, at 03:26 PM, Brett Cannon wrote:
>On Thu, Jul 1, 2010 at 15:07, Barry Warsaw wrote:
>> Other than that, while I sometimes review patches in email, I do not
>> think patches in a tracker are the best way to manage these. A
>> dvcs's biggest strength is
On Jul 02, 2010, at 11:09 AM, Tres Seaver wrote:
>Can somebody comment on how much ongoing effort is required to keep
>that mirror running?
I'm guess "zero". Other than uploading new ssh keys, I think our svn master
has been humming along pretty well without intervention. I know that the bzr
mi
On Jul 04, 2010, at 06:58 PM, Éric Araujo wrote:
>I’d like to volunteer to maintain a tool but I’m not sure where I can
>help. I’m already proposing changes to Brett for
>Tools/scripts/patchcheck.py, and I have commented on Tools/i18n bugs,
>but these ones are already maintained by their authors (
On Jul 04, 2010, at 11:03 AM, Benjamin Peterson wrote:
>2010/7/4 Benjamin Peterson :
>> On behalf of the Python development team, I'm jocund to announce the
>> second release candidate of Python 2.7.
>
>Arg!!! This should, of course, be "final release".
Congratulations Benjamin!
-Barry
signatur
On Jul 07, 2010, at 07:30 PM, Georg Brandl wrote:
>Overall, I think that we can make stdlib docstrings valid reST -- even
>if it's reST without much markup -- but valid, so that people pulling
>in stdlib doc- strings into Sphinx docs won't get ugly warnings.
>
>What I would *not* like to see is he
On Jul 01, 2010, at 07:02 AM, Scott Dial wrote:
>I decided to prove to myself that it was not a significant issue to
>have parallel directory structures in a .tar.bz2, and I was surprised
>to find it much worse at that then I had imagined. For example,
>
># cd /usr/lib/python2.6/site-packages
># t
On Jul 07, 2010, at 12:50 PM, Brett Cannon wrote:
>On Wed, Jul 7, 2010 at 11:46, Antoine Pitrou
>wrote:
>> On Wed, 7 Jul 2010 14:12:17 -0400
>> Barry Warsaw wrote:
>>> On Jul 07, 2010, at 07:30 PM, Georg Brandl wrote:
>>>
>>> >Overall, I thi
On Jul 09, 2010, at 11:55 AM, Brett Cannon wrote:
>I think this is going to be something our crazy FLUFL likes but the
>kids don't. =)
Don't worry. If you're lucky, you'll get old too. Your eyes will go bad and
your mind will think more about tapioca. By then you might even remember that
the F
On Jul 08, 2010, at 09:14 AM, Georg Brandl wrote:
>Am 07.07.2010 23:04, schrieb Georg Brandl:
>> I can see where this is going... writing it into PEP 384 would
>> automatically get the change accepted?
I'm definitely not trying to get it in subversively. :)
>I hit "Send" prematurely. I wanted t
On Jul 08, 2010, at 01:47 AM, Matthias Klose wrote:
>On 07.07.2010 20:40, Barry Warsaw wrote:
>> Getting back to this after the US holiday. Thanks for running these
>> numbers Scott. I've opened a bug in the Python tracker and attached
>> my latest patch:
>>
>
On Jul 13, 2010, at 09:56 PM, Éric Araujo wrote:
>Note that nothing in Mercurial forces you to have a parsable
>“Name ” user name, it’s just a good practice. Dirkjan’s mapping
>uses a dummy to...@python.org address for unknown IDs, which probably
>means the other tools he’s writing depend on an em
inal
discussion.
-Barry
PEP: 3149
Title: ABI version tagged .so files
Version: $Revision: 81577 $
Last-Modified: $Date: 2010-05-27 19:54:25 -0400 (Thu, 27 May 2010) $
Author: Barry Warsaw
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 2010-07-09
Python-Version: 3.2
Post-Hist
On Jul 16, 2010, at 12:16 AM, Amaury Forgeot d'Arc wrote:
>2010/7/15 Barry Warsaw :
>> The first draft of PEP 3149 is ready for review.
>
>I like it!
Cool!
>I think it could mention the case where packages are not installed
>in the canonical directory, but placed else
3.2. This work would reduce the need to recompile
>extension modules separately on Windows for every version of Python --
>something especially pertinent when code has been orphaned but is
>still useful. The versioned .so files PEP being worked out by Barry
>Warsaw overlaps with this
a new version of
the diff and PEP, the latter attached here for your convenience.
Thanks for all the feedback.
-Barry
PEP: 3149
Title: ABI version tagged .so files
Version: $Revision: 81577 $
Last-Modified: $Date: 2010-05-27 19:54:25 -0400 (Thu, 27 May 2010) $
Author: Barry Warsaw
Status: Draft
Type
On Jul 22, 2010, at 03:58 PM, Ronald Oussoren wrote:
>I guess this is not an explicit goal of this PEP, but the structure is
>very close to supporting multiple system architectures at the same
>time. I regularly develop code that needs to run on Windows, Linux
>and OSX and it is very convenient t
On Jul 23, 2010, at 11:48 AM, Ronald Oussoren wrote:
>> I'd be open to adding the
>> platform name to the tag, but I'd probably define it as part of the
>> implementation field, e.g. foo.cpython-linux2-32m.so. Or maybe
>> start with the platform name, e.g. foo.linux2-cpython-32m. This
>> isn't
On Jul 23, 2010, at 12:54 PM, Barry Warsaw wrote:
>On Jul 23, 2010, at 11:48 AM, Ronald Oussoren wrote:
>
>>> I'd be open to adding the
>>> platform name to the tag, but I'd probably define it as part of the
>>> implementation field, e.g. foo.cpython-
On Jul 23, 2010, at 01:46 PM, sch...@gmail.com wrote:
>Doesn't anybody else think this is lost work for very little gain? My
>/usr/lib/python2.6/site-packages directory consumes 200MB on disk. I
>couldn't care less if my /usr/lib/python2.5/site-packages consumed the
>same amount of disk space...
On Jul 23, 2010, at 08:56 PM, Nick Coghlan wrote:
>On Fri, Jul 23, 2010 at 12:40 AM, Barry Warsaw
>wrote:
>> Python implementations *MAY* include additional flags in the file
>> name tag as appropriate. For example, on POSIX systems these flags
>> will also con
On Jul 24, 2010, at 07:08 AM, Guido van Rossum wrote:
>privileges enough. So, my recommendation (which surely is a
>turn-around of my *own* attitude in the past) is to give out more
>commit privileges sooner.
+1, though I'll observe that IME, actual commit privileges become much less of
a special
On Jul 26, 2010, at 10:50 AM, Ian Bicking wrote:
>On Mon, Jul 26, 2010 at 9:06 AM, Barry Warsaw wrote:
>
>> On Jul 24, 2010, at 07:08 AM, Guido van Rossum wrote:
>> >privileges enough. So, my recommendation (which surely is a
>> >turn-around of my *own* attitude in
On Jul 24, 2010, at 09:54 AM, Ronald Oussoren wrote:
>> I'd be okay including a configure option to allow you to add
>> whatever you want after the implementation, version, and flags.
>> E.g. something like:
>>
>>./configure --with-abi-tag-extension=linux2
>>
>> would lead to foo.cpython-32m
On Jul 24, 2010, at 11:59 PM, sch...@gmail.com wrote:
>Barry Warsaw writes:
>
>> On Jul 23, 2010, at 01:46 PM, sch...@gmail.com wrote:
>>
>>>Doesn't anybody else think this is lost work for very little gain? My
>>>/usr/lib/python2.6/site-packages direct
On Jul 26, 2010, at 10:53 PM, Ralf Schmitt wrote:
>Some of the things that need to be adapted are e.g. Makefiles
>(basically anything that assumes modules have a certain name), all of
>the freezers (cxFreeze, py2exe, ...). The biggest problem probably
>will be that an import will load the wrong mo
On Jul 27, 2010, at 01:54 PM, Ralf Schmitt wrote:
>Matthias Klose writes:
>
>> Not true. Package managers like dpkg/apt-get, rpm/yum and maybe
>> others do this for ages. And yes, the added "complexity" of package
>> managers does lead to increased robustness.
>
>but how does sharing things lead
On Jul 30, 2010, at 11:38 AM, Michael Foord wrote:
>I'm going to read your blog entry on the topic to evaluate it properly
>though:
>
>https://tarekziade.wordpress.com/2009/05/01/basic-plugin-system-using-abcs-
>and-the-extensions-package/
Very interesting. For Mailman 3, I have YAPS (yet anothe
Hello all!
For those of you who use the Bazaar mirrors on Launchpad of the Python
Subversion branches (dvcs ftw! :), I've just registered the Python 2.7
maintenance branch. It will take a little while to complete the import, but
when it's done you can grab it with:
% bzr branch lp:python/2.7
In working on making Python 2.7 available in Debian and Ubuntu, we ran into
two packages that fail to byte compile against Python 2.7, where they are fine
in Python 2.6. The Debian bug tracker issues are:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=590821
http://bugs.debian.org/cgi-b
On Jul 30, 2010, at 01:42 PM, Guido van Rossum wrote:
>Well it is a reserved name so those packages that were setting it
>should have known that they were using undefined behavior that could
>change at any time.
Shouldn't it be described here then?
http://docs.python.org/reference/lexical_analys
On Jul 31, 2010, at 08:32 AM, Steven D'Aprano wrote:
>On Sat, 31 Jul 2010 07:44:42 am Guido van Rossum wrote:
>> On Fri, Jul 30, 2010 at 1:53 PM, Barry Warsaw
>wrote:
>> > On Jul 30, 2010, at 01:42 PM, Guido van Rossum wrote:
>> >>Well it is a reserved na
On Jul 30, 2010, at 05:23 PM, Eric Snow wrote:
>First appeared in docs for 2.6 (October 02, 2008). Not sure if that
>is when it first because constrained this way.
>
>http://docs.python.org/library/constants.html?highlight=__debug__#__debug__
Thanks Eric, this is probably the right section of th
On Jul 31, 2010, at 12:45 AM, Georg Brandl wrote:
>to warm up for tomorrow's 3.2alpha1 release, I did a mini-sprint on
>pdb issues today. I'm pleased to report that 14 issues could be
>closed, and pdb got a range of small new features, such as commands on
>the command line, "until " or "longlist"
Hi folks,
Don't forget that I am planning to cut Python 2.6.6 rc 1 later today (probably
starting at around 2200 UTC). We have a number of release blockers currently
reported:
http://bugs.python.org/iss...@columns=title,id,activity,versions,assignee&@sort=activity&@group=priority&@filter=priorit
On Aug 02, 2010, at 12:09 PM, Antoine Pitrou wrote:
>On Mon, 02 Aug 2010 08:10:58 +0200
>Georg Brandl wrote:
>> Thanks, Benjamin! I'd also like to thank Martin and Ronald for the
>> prompt binaries, and the folks of #python-dev for support. RMing
>> was a pleasant experience so far.
>
>Are you
Over in #python-dev, Georg reminded us of a change to the python-checkins
mailing list that was discussed a few weeks ago:
http://mail.python.org/pipermail/python-dev/2010-July/101853.html
Despite the mild preference of redirecting python-checkins to
python-committers, I noticed that the list
On Aug 02, 2010, at 06:25 PM, Terry Reedy wrote:
>6:22 EDT, tracker down and has been for a couple of minutes.
>python.org and docs.python.org are fine.
>Does the daemon program that now checks on Pypi also check the tracker?
>Is there a particular place to report tracker down?
>Or should I just a
On Aug 01, 2010, at 09:56 PM, Benjamin Peterson wrote:
>2010/7/30 Barry Warsaw :
>>
>> It looks like Benjamin's change in r67171 was the relevant diff.
>
>The reason behind this was to make __debug__ assignment consistent
>with that of other reserved names. For e
On Aug 02, 2010, at 06:57 PM, Benjamin Peterson wrote:
>You feel locked out by the current tracker?
I do, but that's only because bugs.python.org is currently pinin' for the
fjords. ;)
-Barry
signature.asc
Description: PGP signature
___
Python-Dev ma
1201 - 1300 of 2704 matches
Mail list logo
