On Oct 14, 2010, at 10:29 AM, Guido van Rossum wrote:
>Could it be IPv6?
I don't think so. I have IPv6 disabled on at least one of the machines.
Also, I'm sure this failure did not occur before Ubuntu 10.10 final.
It also fails on Python 3.1.
-Barry
signature.asc
Description: PGP signature
_
On Oct 14, 2010, at 07:38 PM, Antoine Pitrou wrote:
>There doesn't seem to be anything really mysterious, actually. The
>exception message says it all :)
Yep. Looks like Ubuntu 10.10 added UBUNTU_MENUPROXY to the default
environment and that's what's killing it. I'll bet those Ubuntu buildbots
On Oct 14, 2010, at 08:27 PM, Martin v. Löwis wrote:
>I think it was intentional (at least deliberate), but I think it is a
>problem and should be reverted. There is, at any point, the official
>version that Python uses for autoconf, which at the moment is 2.65.
>The rationale is that with changin
On Oct 14, 2010, at 09:11 PM, Martin v. Löwis wrote:
>> I don't see it as any more of a problem than upgrading against other
>> dependencies (like gcc?).
>
>Ok, so let's drop the requirement then.
Good for me. Is there a place where this requirement is documented?
-Barry
signature.asc
Descrip
On Oct 15, 2010, at 12:40 PM, Benjamin Peterson wrote:
>2010/10/15 Raymond Hettinger :
>> After rereading http://bugs.python.org/issue9778 , I'm growing concerned
>> about an impending ABI freeze before the core devs find time to fix the
>> 32-bit hash limitation.
>> ISTM, the use of 64-bit builds
On Oct 16, 2010, at 01:50 PM, Georg Brandl wrote:
>> --- python/branches/py3k/Doc/library/sys.rst (original)
>> +++ python/branches/py3k/Doc/library/sys.rst Sat Oct 16 03:04:07 2010
>> @@ -955,6 +955,11 @@
>> module for informational purposes; modifying this value has no effect on
>> the
>>
On Oct 18, 2010, at 04:04 PM, Éric Araujo wrote:
>Raymond Hettinger noticed on the tracker that there are different
>interpretations of the “accepted” resolution:
>
>> Traditionally it denotes an approved patch, not a agreement that the
>> bug is valid.
I'm with Raymond; I've always used 'accepte
On Oct 19, 2010, at 03:53 AM, Victor Stinner wrote:
>Seven months after my first commit related to this issue, the full test suite
>of Python 3.2 pass with ASCII, ISO-8859-1 and UTF-8 locale encodings in a non-
>ascii source directory. It means that Python 3.2 now process correctly
>filenames in
On Oct 20, 2010, at 05:50 PM, Michael Foord wrote:
>Wow, that's very interesting. Whilst a lot of people on this list will have
>an interest in knowing about this it still isn't the right list for
>discussing it. The python-porting list *is* an entirely appropriate list and
>it would be great to s
On Oct 20, 2010, at 02:11 AM, Victor Stinner wrote:
>I plan to fix Python documentation: specify the encoding used to decode all
>byte string arguments of the C API. I already wrote a draft patch: issue
>#9738. This lack of documentation was a big problem for me, because I had to
>follow the fu
On Oct 21, 2010, at 05:57 PM, Benjamin Peterson wrote:
>In the interest of getting 3.1.3 and 2.7.1 out by next year, here's a
>tentative release schedule:
>
>November 13th - RC1
>November 27th - RC2
>December 11th - Final
Sounds like you're planning to get finals out this year, not next :). +1 f
I will also do any future 2.6 release from svn. It does mean that patches for
those release need to make it into svn. I propose that only the RM have commit
to the svn branches after the switch.
Sent from my digital lollipop.
On Oct 23, 2010, at 2:03 PM, "Martin v. Löwis" wrote:
> Am 22.10.2
On Oct 26, 2010, at 09:19 PM, Nick Coghlan wrote:
>On Tue, Oct 26, 2010 at 5:31 PM, Georg Brandl wrote:
>> This looks more like "Add gitignore". Do we really want to check in
>> ignore files for every possible DVCS?
>
>No, but supporting the current big four open source ones (svn, hg,
>bzr, git)
On Oct 26, 2010, at 04:46 PM, Michael Foord wrote:
>I find the big-ball-of-mud style development, where everything lives inside
>huge monolithic modules, very painful. I also think that it is an extremely
>bad example for new developers. There is something to be said for consistency
>within the st
On Oct 26, 2010, at 09:54 PM, Antoine Pitrou wrote:
>I think it comes down to the preference of whoever works the most
>actively on it. Michael is the most active contributor to unittest by
>far, and I suppose he prefers it to be split into several submodules.
And that seems perfectly reasonable
On Oct 27, 2010, at 03:54 AM, Scott Dial wrote:
>As with others, I don't see the harm in committers who use those tools
>adding and maintaining these files. Seems akin to having
>Misc/python-mode.el and Misc/Vim/python.vim. It's all in the spirit of
>supporting the tools that people are actually u
On Oct 27, 2010, at 02:54 PM, Éric Araujo wrote:
>I remember a discussion about Vim files some time ago. I use Vim with
>the files from Misc/Vim, which are up-to-date and more useful than the
>files shipped with Vim. I don’t use plugins or external files, so I’m
>-1 on removing Misc/Vim.
FWIW,
Who is the target audience for a Python 2.8? What exactly would a Python 2.8
accomplish?
If Python 2.8 doesn't include new features, well, then what's the point?
Python 2.7 will be bug fix maintained for a long time, longer in fact than
previous Python 2 versions. So a no-feature Python 2.8 can'
On Oct 28, 2010, at 04:17 PM, exar...@twistedmatrix.com wrote:
>On 04:04 pm, ba...@python.org wrote:
>>
>>I'd *much* rather this enthusiasm be spent on making Python 3 rock, and >in
>>porting third party code to Python 3.
>
>Enthusiasm isn't fungible.
Maybe so, but I think it's actually more fun
On Oct 28, 2010, at 04:07 PM, l...@rmi.net wrote:
>I hope 3.X use expands; in fact, I've bet the future of at
>least one book on it. And even 1/4 of new users seems a
>large enough subset to care about too. But one can't help
>but wonder if most of the development community is focused
>on som
On Oct 28, 2010, at 04:57 PM, Alexander Belopolsky wrote:
>On Thu, Oct 28, 2010 at 4:52 PM, Alexander Belopolsky
> wrote:
>> On the second look, the problem may not be that bad ...
>
>Nope, the problem is even worse. It looks like Sphinx in py3k
>requires 2.x python:
>
>$ ../python.exe tools/sphi
On Oct 27, 2010, at 09:19 AM, Brett Cannon wrote:
>In the name of completeness for people not aware of the issue,
>http://bugs.python.org/issue9893 discusses actually removing these
>files in preference to files maintained by others. If Misc/Vim were to
>be dropped we could place a text file much
On Oct 27, 2010, at 10:34 AM, R. David Murray wrote:
>To put your mind at ease, Barry, I'd not want to do that either :)
Phew! But I wasn't worried, 'cause I know you're not insane. (Though the
fact that you've effectively inherited the email package does bring that into
question. :)
>But by (
On Oct 25, 2010, at 02:28 PM, Vinay Sajip wrote:
>I've just checked in a change to logging into the py3k branch (r85835),
>including doc changes and tests, for providing slightly more flexibility in
>alternative format styles for logging.
>
>Basically, Formatter.__init__ gets an extra optional key
On Oct 29, 2010, at 12:43 PM, Casey Duncan wrote:
>I like Python 3, I am using it for my latest projects, but I am also keeping
>Python 2 compatibility. This incurs some overhead, and basically means I am
>still really only using Python 2 features. So in some respects, my Python 3.x
>support is on
Another quick thought. What would people think about regular timed releases if
python 2.7? This is probably more a question for Benjamin but doing sonmight
provide better predictability and "customer service" to our users. I might like
to see monthly releases but even quarterly would probably b
That's a much better idea!
Sent from my digital lollipop.
On Oct 29, 2010, at 3:31 PM, Ian Bicking wrote:
> On Fri, Oct 29, 2010 at 12:21 PM, Barry Warsaw wrote:
> On Oct 29, 2010, at 12:43 PM, Casey Duncan wrote:
>
> >I like Python 3, I am using it for my latest pro
It certainly doesn't have to.
Sent from my digital lollipop.
On Oct 29, 2010, at 4:06 PM, Antoine Pitrou wrote:
> On Fri, 29 Oct 2010 15:54:19 -0400
> Barry Warsaw wrote:
>> Another quick thought. What would people think about regular timed releases
>> if python 2.7?
&
On Oct 29, 2010, at 08:14 PM, Raymond Hettinger wrote:
>I would like to simplify and clean-up the API for the unittest module
>by de-documenting assertSetEqual(), assertDictEqual(),
>assertListEqual, and assertTupleEqual().
As a general principle, I think all public API methods should be document
On Oct 29, 2010, at 04:23 PM, Benjamin Peterson wrote:
>At the moment, I'm planning to do regular maintenance releases for 3.1 and
>2.7 roughly every 6 months.
Cool. The actual interval doesn't matter as much as the regularity. I say
that speaking as a semi-former RM who sadly didn't adhere to
On Oct 31, 2010, at 09:54 AM, Gregory P. Smith wrote:
>> - moving the documentation to an "advanced" or "complete reference" section
>>
>
>Agreed, I perfer simply deemphasizing these methods by reorganizing the
>documentation and mentioning in their documentation to, "just use
>assertEqual." De-d
On Oct 31, 2010, at 04:39 PM, Eric Smith wrote:
>What are your thoughts on adding a str.format_from_mapping (or similar
>name, maybe the suggested "format_map") to 3.2?
+1 for the shorter name.
-Barry
signature.asc
Description: PGP signature
___
Pyth
On Nov 02, 2010, at 03:43 PM, Brett Cannon wrote:
>On Tue, Nov 2, 2010 at 15:33, Nick Coghlan wrote:
>> On Tue, Nov 2, 2010 at 12:35 PM, Brett Cannon wrote:
>>> So basically it seems like we have learned a lesson: we prefer to have
>>> our code structured in files that match the public API. I th
On Nov 03, 2010, at 11:06 AM, Ben Finney wrote:
>Is this a case where it would be better if the package names had the
>leading underscore: ‘_utils’, ‘_suite’, etc.?
>
>Does the convention on single-leading-underscore identifiers as “don't
>rely on this name staying the same in future versions” hol
On Nov 03, 2010, at 12:34 AM, Antoine Pitrou wrote:
>I don't agree with this. Until it's documented, it's an implementation
>detail and should be able to change without notice.
>If someone wants to depend on some undocumented detail of the directory
>layout it's their problem (like people dependin
On Nov 04, 2010, at 02:44 PM, Allan McRae wrote:
>While this is not strictly related to python development, I thought that
>developers of python might be interested in some of the lessons provided by
>this. So forgive me if this is really wrong for this list...
>
>Recently Arch Linux did a big tra
On Nov 04, 2010, at 11:33 PM, Nick Coghlan wrote:
> world: /usr/bin/env python (I have no idea what this script is even for)
It's basically a front-end to ISO 3166 country codes. IOW, it prints the
expansion of top-level domain names and can do some reverse lookups too.
E.g.
% Tools/world/worl
On Nov 10, 2010, at 12:34 PM, Jesus Cea wrote:
>On 09/11/10 22:17, "Martin v. Löwis" wrote:
>> bugs.python.org is moving to a new hardware; this also involves a new IP
>> address. The migration will happen on Thursday, likely around 8:00 UTC.
>> If all goes well, outage should be very short.
>
>Se
I finally found a chance to address all the outstanding technical issues
mentioned in bug 9807:
http://bugs.python.org/issue9807
I've uploaded a new patch which contains the rest of the changes I'm
proposing. I think we still need consensus about whether these changes are
good to commit. Wi
On Nov 11, 2010, at 12:41 AM, Alexander Belopolsky wrote:
>Is it OK to add __all__ to such modules that does not include all
>names not starting with an underscore? Is it OK to then remove names
>that clearly were not intended to be public?
I would say in general, yes. It's a good small moderni
On Nov 12, 2010, at 12:02 AM, Nick Coghlan wrote:
>My personal opinion is that we should be trying to get the standard
>library to the point where __all__ definitions are unnecessary - if a
>name isn't in __all__, it should start with an underscore (and if that
>is true, then the __all__ definitio
On Nov 12, 2010, at 10:29 AM, Martin v. Löwis wrote:
>As you may have noticed: I updated the buildbot master to release 0.8.2.
>If you notice any problems, please post them here.
Pretty! My buildbot seems fine.
>Slave operators can upgrade their installations at their own pace;
>buildbot is hig
On Nov 19, 2010, at 11:50 PM, Nick Coghlan wrote:
>- date SVN will go read only
Please note that svn cannot be made completely read-only. We've already
decided that versions already in maintenance or security-only mode (2.5, 2.6,
2.7, 3.1) will get updates and releases only via svn. But only th
On Nov 19, 2010, at 06:12 PM, Georg Brandl wrote:
>Am 19.11.2010 15:46, schrieb Barry Warsaw:
>> On Nov 19, 2010, at 11:50 PM, Nick Coghlan wrote:
>>
>>>- date SVN will go read only
>>
>> Please note that svn cannot be made completely read-only. We've
On Nov 10, 2010, at 04:27 PM, Barry Warsaw wrote:
>I finally found a chance to address all the outstanding technical issues
>mentioned in bug 9807:
>
>http://bugs.python.org/issue9807
>
>I've uploaded a new patch which contains the rest of the changes I'm
>pr
On Nov 23, 2010, at 01:50 PM, Michael Foord wrote:
>Right. As it happens I just submitted a patch to Barry Warsaw's enum package
>(nice), flufl.enum [1], to allow namedtuple style creation of named
>constants:
Thanks for the plug (and the nice patch).
FWIW, the documentation for the package is h
On Nov 23, 2010, at 03:15 PM, Michael Foord wrote:
>(Well, there is a third option that takes __name__ and sets the constants in
>the module automagically. I can understand why people would dislike that
>though.)
Personally, I think if you want that, then the explicit class definition is a
better
On Nov 23, 2010, at 12:57 PM, Fred Drake wrote:
>>From a backward-compatibility perspective, what makes sense depends on
>whether they're used to implement existing constants (socket.AF_INET,
>etc.) or if they reserved for new features only.
As is usually the case, there's little reason to change
On Nov 23, 2010, at 05:02 PM, Michael Foord wrote:
>> * Enums are not subclassed from ints or strs. They are a distinct data type
>>that can be converted to and from ints and strs. EIBTI.
>
>But if we are to use it *in* the standard library (as opposed to merely
>adding a module *to* the sta
On Nov 23, 2010, at 11:52 AM, P.J. Eby wrote:
>This reminds me: a stdlib enum should support proper pickling and copying;
>i.e.:
>
>assert SomeEnum.anEnum is pickle.loads(pickle.dumps(SomeEnum.anEnum))
>
>This could probably be implemented by adding something like:
>
>def __reduce__(self):
On Nov 25, 2010, at 12:41 AM, Antoine Pitrou wrote:
>On Wed, 24 Nov 2010 20:43:47 +0100 (CET)
>barry.warsaw wrote:
>> Author: barry.warsaw
>> Date: Wed Nov 24 20:43:47 2010
>> New Revision: 86731
>>
>> Log:
>> Final patch for issue 9807.
>
>This seems to have broken compilation under Windows:
>
On Nov 27, 2010, at 02:01 PM, Michael Foord wrote:
>(Note that there is no *particular* hurry to get this into 3.2 - the beta is
>due imminently. I wouldn't object to it )
Indeed. I don't think the time is right to try to get this into 3.2.
-Barry
signature.asc
Description: PGP signature
On Nov 30, 2010, at 01:09 PM, Michael Foord wrote:
>PEP 291 is very old and should probably be retired. I don't think anyone is
>maintaining standard libraries in py3k that are also compatible with Python
>2.anything. (At least not in a single codebase.)
I agree. I think we should change the sta
On Nov 30, 2010, at 12:11 PM, Brett Cannon wrote:
>I will channel Neal: "I decline and/or do not want to respond". =)
PEP 291 updated.
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python
On Dec 02, 2010, at 12:59 PM, Terry Reedy wrote:
>On 12/2/2010 8:36 AM, Lennart Regebro wrote:
>> On Wed, Dec 1, 2010 at 20:17, Antoine Pitrou wrote:
>>> And I'm not sure what this package called "Python" is (“a high-level
>>> object-oriented programming language”? like Java?), but I'm pretty sur
On Dec 02, 2010, at 08:44 PM, Martin v. Löwis wrote:
>Since the "barry" account already exists, you first need to log into
>that (likely using a password). You can then claim the LP OpenID as
>being associated with that account, and use LP in the future.
Thanks Martin.
-Barry
signature.asc
Desc
On Dec 02, 2010, at 11:21 PM, Martin v. Löwis wrote:
>Well, the PEP 384 text in PEP 3149 specifies a change. It's not clear
>whether this change was accepted when PEP 3149 was accepted, or whether
>it was accepted when PEP 384 was accepted, or whether it was not
>accepted at all, or whether it was
On Dec 03, 2010, at 12:51 AM, Amaury Forgeot d'Arc wrote:
>Sure. But today (before 3.2b1) we want to merge PEP3149 and PEP384;
>they change the paths and filenames used by python.
>Either we modify distutils to comply with the new names,
>or defer these PEPs until distutils2 is ready.
I do not th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Patch #1520294 adds support for attributes defined with PyGetSetDef
in extension modules to pydoc, specifically so things like help
(array.array.typecode) gives something useful, like the attribute's
docstring for instance.
Along the way, I added
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jul 10, 2006, at 9:52 PM, Barry Warsaw wrote:
> Patch #1520294 adds support for attributes defined with PyGetSetDef
> in extension modules to pydoc, specifically so things like help
> (array.array.typecode) gives something useful,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jul 13, 2006, at 9:15 AM, Nick Coghlan wrote:
> Could you include a "look up late-breaking types" function in
> types.py that site.py calls after it finishes setting up the
> standard library path?
>
> Still a little hackish, I know, but it see
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jul 13, 2006, at 2:03 PM, [EMAIL PROTECTED] wrote:
> Having been exhorted (or maybe I mean "excoriated") by your
> friendly release
> manager earlier this week to post my comments and criticisms about
> Python here
> rather than vent in random
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Just as 2.5b2 was being release, I updated SF patch #1520294:
https://sourceforge.net/tracker/index.php?
func=detail&aid=1520294&group_id=5470&atid=305470
This fixes the pydoc, inspect, and types modules for built-in types
like getset and m
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jul 13, 2006, at 12:12 PM, Barry Warsaw wrote:
> I've updated SF patch #1520294 and assigned it back to Georg for
> another quick review.
Neal commented in the patch that it might help to explain the
implementation a bit. I&#
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jul 20, 2006, at 3:32 PM, Georg Brandl wrote:
> Perhaps you could put the objects into _testcapi. That way no new
> module
> has to be deployed (is _testcapi installed on every system?)
That doesn't seem importable in types.py either. You /coul
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Since Anthony didn't speak up, I took his silence as assent and went
ahead and committed the changes. r50881 and r50885 for *nix and
Windows, just in case the deafening silence turns into a howl of
derision :).
- -Barry
-BEGIN PGP SIGNATUR
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jul 28, 2006, at 1:39 AM, Anthony Baxter wrote:
> I've been thinking the same thing, too. A quick chat to Neal says that
> he also agrees.
>
> There's still a lot more bugs popping up than I'm really comfortable
> with. I guess this is inevitable -
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Re: Python 2.5 compatibility
On Jul 28, 2006, at 8:57 AM, Barry Warsaw wrote:
> +1. It would give me more type to port and test a few of my
> applications to the new version.
>
> I'm still working on Mailman but the most painful
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jul 30, 2006, at 4:27 PM, Fred L. Drake, Jr. wrote:
> On Sunday 30 July 2006 16:17, Georg Brandl wrote:
>> The second "type" seems to be superfluous. ;)
>
> I was thinking it suggested there was a local named "type". But if
> not, yeah.
>
> I ge
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Aug 4, 2006, at 11:43 AM, M.-A. Lemburg wrote:
> How about generating a warning instead and then go for the exception
> in 2.6 ?
From the perspective of wanting to avoid blog entries in 2007
railing against our gratuitous breakages in Python 2.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Aug 16, 2006, at 7:37 AM, Thomas Wouters wrote:
>
> Can I suggest making 'python -t' the default, in 2.6? It makes
> python warn about mixing tabs and spaces in indentation. In Py3k, '-
> tt' (the error-raising version) will be the default,
+1.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Aug 20, 2006, at 11:24 AM, Guido van Rossum wrote:
> I wonder if it would make sense to focus in 2.6 on making porting of
> 2.6 code to 3.0 easier, rather than trying to introduce new features
> in 2.6. We've done releases without new language feat
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Aug 22, 2006, at 11:26 AM, Michael Hudson wrote:
> Oh my word, even I had nearly forgotten about that.
>
> I think the latest version is here:
>
>http://starship.python.net/crew/mwh/toext/
>
> and source is here:
>
>http://codespeak.net/svn
I am considering producing a Python 2.3.6 release, which would of course only be a bug fix maintenance release. The primary reason is that not all OS distributions have upgraded to Python 2.4 and I think it's worthwhile for us to bless a release that fixes known critical bugs. I'm willing to be
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Aug 29, 2006, at 11:29 AM, Georg Brandl wrote:
> There's one problem: it was thought for a long time that there
> wouldn't be
> any more 2.3 releases, so bug fixes were applied only in the head
> and 2.4
> branch.
>
> If there will be a 2.3.6,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sep 5, 2006, at 1:10 PM, Raymond Hettinger wrote:
>> This change looks wrong:
>>
>> PyDoc_STRVAR(rpartition__doc__,
>> -"S.rpartition(sep) -> (head, sep, tail)\n\
>> +"S.rpartition(sep) -> (tail, sep, head)\n\
>>
>> It looks like the code itself do
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sep 5, 2006, at 1:46 PM, Raymond Hettinger wrote:
>> ISTM this is just begging for newbie (and maybe not-so-newbie)
>> confusion. Why not just document both as returning (left, sep,
>> right) which seems the most obvious description of what
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sep 5, 2006, at 2:06 PM, Raymond Hettinger wrote:
>> Then shouldn't rpartition be S.rpartition(sep) -> (rest, sep, tail)
>
> Gads, the cure is worse than the disease.
>
> car and cdr are starting to look pretty good ;-)
LOL, the lisper in me likes
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sep 5, 2006, at 2:32 PM, Raymond Hettinger wrote:
> Another thought is that strings don't really have a left and right.
> They have a beginning and end. The left/right or top/bottom
> distinction
> is culture specific.
For the target of the met
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sep 5, 2006, at 4:13 PM, Raymond Hettinger wrote:
> Tim Peters wrote:
>
>>upto, sep, rest
>>
>> in whatever order they apply.
>>
> In the rpartition case, that would be (rest, sep, upto) which seems a
> bit cryptic.
>
> We need some choice of w
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sep 5, 2006, at 4:43 PM, Jim Jewett wrote:
> I think I finally figured out where Raymond is coming from.
>
> For Raymond, "head" is where he started processing -- for rpartition,
> this is the .endswith part.
>
> For me, "head" is the start of the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sep 8, 2006, at 6:06 PM, Mihai Ibanescu wrote:
> There is no description of what happens when Py_BuildValue fails.
> Will it
> decref the python object passed in? Will it not?
I just want to point out that the C API documentation is pretty
sil
On Sep 9, 2006, at 2:10 PM, Martin v. Löwis wrote:
> Barry Warsaw schrieb:
>> Thoughts? I don't want to waste my time if nobody thinks a 2.3.6
>> would
>> be useful, but I'm happy to do it if there's community support. I'll
>> also need the usual
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sep 28, 2006, at 8:49 PM, <[EMAIL PROTECTED]> wrote:
> What is lost according to him is information about how the elements of
> a module work together. The docstrings tend to be narrowly focused on
> the particular function or variable, and too of
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Oct 9, 2006, at 11:28 AM, Fredrik Lundh wrote:
>> 1. Does this seem like a reasonable addition to the standard library?
>
> I cannot remember ever doing this, or seeing anyone except Perforce
> doing this, and it'll only save you a few lines of cod
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Oct 10, 2006, at 5:47 PM, Raymond Hettinger wrote:
>> the slightly obscure bit that requires some getting used to is
>> that all these flags don't really mean "I have such and such
>> feature" but just "I could have such and such
>> feature, if the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Oct 12, 2006, at 4:08 AM, Anthony Baxter wrote:
> I've had a couple of queries about whether PSF-2006-001 merits a
> 2.3.6.
> Personally, I lean towards "no" - 2.4 was nearly two years ago now.
> But I'm
> open to other opinions - I guess peopl
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Oct 12, 2006, at 1:34 PM, Terry Reedy wrote:
> Perhaps all that is needed from both a practical and public relations
> viewpoint is the release of a 2.3.5U4 security patch as a separate
> file
> listed just after 2.3.5 on the source downloads pag
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Oct 12, 2006, at 3:27 PM, Anthony Baxter wrote:
> Mostly it is easy for me, with the one huge caveat. As far as I
> know, the Mac
> build is a single command to run for Ronald, and the Doc build
> similarly for
> Fred. I don't know what Martin
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Oct 12, 2006, at 5:03 PM, Gregory P. Smith wrote:
> IMHO thats a backwards view; I'm with Barry. Requiring human
> intervention to do anything other than press the big green "go" button
> to launch the "official" release build process is an opport
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Oct 12, 2006, at 5:07 PM, Martin v. Löwis wrote:
> Of course, that makes the idea die here and now. Without volunteers
> to do the actual work, it just won't happen.
True, and there's no carrot/stick of a salary to entice people into
doing what
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Oct 12, 2006, at 8:46 PM, Alexey Borzenkov wrote:
> Ugh... that's just not fair. Because of this there will be no spawn*p*
> in python for another two years. x_x
Correct, but don't let that stop you. That's what distutils and the
Cheeseshop are
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Oct 22, 2006, at 8:51 AM, [EMAIL PROTECTED] wrote:
> Is there anyone else with a g5 who can do a vanilla Unix (not
> framework)
> build on an up-to-date g5 from an up-to-date Subversion
> repository? It
> would be nice if someone else could at
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Oct 22, 2006, at 11:24 PM, [EMAIL PROTECTED] wrote:
> According to /usr/include/sqlite3.h, what's installed by Apple is
> 3.1.3.
> Aside from the possibility that I somehow compiled against
> /usr/include/sqlite3.h and linked against /usr/local/l
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Nov 9, 2006, at 9:01 AM, A.M. Kuchling wrote:
> Should I backport this change to 2.5.1? Con: The patch adds two new
> internal functions, _sync_flush() and _sync_close(), so it's an
> internal API change. Pro: it's a patch that should reduce chan
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Nov 9, 2006, at 2:15 PM, [EMAIL PROTECTED] wrote:
>
> Martin> In any case, the patch being contributed uses SCons. If
> people
> Martin> think this is unmaintainable, this is a reason to
> reject the
> Martin> patch.
>
> Could SCons
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Nov 12, 2006, at 3:55 PM, Fredrik Lundh wrote:
> would anyone mind if I added the above classes to the datetime
> module ?
+1. I mean, we have an example of UTC in the docs, so, er, why not
include it in the stdlib?!
- -Barry
-BEGIN PGP
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Nov 28, 2006, at 8:53 AM, Anthony Baxter wrote:
> (The only other packaging thing like this that I'm aware of is
> python-minimal in Ubuntu. This is done for installation purposes
> and wacky dependency issues that occur when a fair chunk of the O/
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Nov 28, 2006, at 2:41 PM, Mike Orr wrote:
> On 11/28/06, Barry Warsaw <[EMAIL PROTECTED]> wrote:
>> For distros like Gentoo or Ubuntu that rely heavily on their
>> own system Python for the OS to work properly, I'm
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Nov 28, 2006, at 4:05 PM, Guido van Rossum wrote:
> On 11/28/06, Barry Warsaw <[EMAIL PROTECTED]> wrote:
>> There's a related issue that may or may not be in scope for this
>> thread. For distros like Gentoo or Ubuntu
1401 - 1500 of 2704 matches
Mail list logo
