ily need to use the classic gettext API.
Barry
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)
iQCVAwUBSc1E2XEjvBPtnXfVAQKc5QP+NOgx0Q/yZ47d1HKR2M/TP4gwT08hr1K2
rTZ+YsGVQ6B+pO36uBi3dwOWNzVbPd3VMBCPNE/TBiGRHklqNiI4AxjRyougdmcw
6nhZomS0GxlE//r27nKx/Wl+qS/b8eQ6UWB/jpGRGL1+K/TuI4Zij0yUY
kage with rich enough metadata that
downstreams don't need anything else to overlay their build rules
according to their own needs.
Barry
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)
iQCVAwUBSc5Lf3EjvBPtnXfVAQJoJQQAjJ4BeTk/ovhPvfJLMOSM+mcB7wz4XaX8
X9YlCnmQzPyNtbPdaaaLtkE8
to
2.6.2, please do so before rc1. You'll need to get approval from me
for all changes between 2.6.2rc1 and 2.6.2 final.
Please let me know if this schedule does not work for you.
Barry
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)
iQCVAwUBSc/t63EjvBPtnXfVAQLL1QQAs1MQK
#x27;t be doing any more releases after that.
I don't have an ETA for 3.0.2, but I'm happy to do it whenever it
makes sense.
Barry
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)
iQCVAwUBSdEMYXEjvBPtnXfVAQLNLQP/XY9Wv3QvoqvEhgberz45inXqMpiMuhAL
knw+tjtpwt
o any security-only releases after the
final patch release.
Barry
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)
iQCVAwUBSdE+0HEjvBPtnXfVAQL4AQQAnYyOeFlVfitJvsJF5gPXJbz5D2BqH9OA
2B9lEuUpVBooaZpsu/CHHgTCUYAVsrqvVBYbRCwsfsvy1mMet7503703vCaJbzxc
MyEBzaHllX6q8froEDc26tQC8aYUs2/kLUL9C9O/inh
the work myself.
I'm +0/-1 (idea/work) on doing them all, but I think a /few/ errnos
would be very handy. I certainly check ENOENT and EEXIST very
frequently, so being able to easily catch or ignore those would be a
big win. I'm sure there's one or two others that would
or are there
objections in principle?
+1/jfdi :)
Barry
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)
iQCVAwUBSdVFMXEjvBPtnXfVAQJeeQQAl5yYTLCUT4M4jQBY0yb39uNexREytnmp
Oo+8gaehi2at62WbeIXa3GRojfWcpAJfGEWIWxsIEe8vRBMfNJphfsiN62rD1CIt
Awn9SPPka9Xxfd3fsdvfKxDpJysK1pcqNFi5e49lXgbmt8XJ
this from the new SIG page.
http://wiki.python.org/moin/Special%20Interest%20Groups
Barry
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)
iQCVAwUBSdelonEjvBPtnXfVAQI0QQP/c0mXr4OA+yLOFHqSksFxT5pkt2xPtxPO
25VfcGFmP0FydsGMW0fpIPC9nw3kaZhtwtx5iYiRXOg796IParSzSdleKwRdabwA
SH
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Apr 5, 2009, at 5:06 AM, Martin v. Löwis wrote:
- decide what to do with the bzr mirrors
I don't see any reason to keep them running on python.org. There are,
or will be, other alternatives.
Barry
-BEGIN PGP SIGNATURE-
Ve
ng the PSF license). Should I remove them
from both the Python 2.x and 3.x trunks?
Barry
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)
iQCVAwUBSdj2S3EjvBPtnXfVAQJvkAQAhj/Go+OtfYP//OZ7HIHwTjaeMlpAkfwn
iPxE6O8gY0K48J1AUmjvGSeckfP4FRqVJWOVMQYvX8yTHNFnCJxDSl4J
full test run takes *hours*). On the whole though, it's a net win
because you know the main tree is always good. This is especially
useful around release time! But I guess it's up to Benjamin now to
push for that :).
Barry
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.
#x27;t the policy just that nothing can go into 2.7 that
isn't backported from 3.1? Whether the actual backport happens or not
is up to the developer though. OTOH, we talked about a lot of things
and my recollection is probably fuzzy.
Barry
-BEGIN PGP SIGNATURE-
Version: GnuPG
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Apr 5, 2009, at 7:37 PM, Matthias Klose wrote:
Barry Warsaw schrieb:
Someone (I'm sorry, I forgot who) asked me at Pycon about stripping
out
Demos and Tools. I'm happy to remove the two I wrote - Tools/world
and
Tools/pynche
page:
http://www.python.org/download/releases/2.6.2/
Bugs can be reported in the Python bug tracker:
http://bugs.python.org
Enjoy,
Barry
Barry Warsaw
ba...@python.org
Python 2.6/3.0 Release Manager
(on behalf of the entire python-dev team)
-BEGIN PGP SIGNATURE-
Version: GnuPG v
from that decision, I haven't come up with an
elegant way to allow /output/ in both bytes and strings (input is I
think theoretically easier by sniffing the arguments).
Barry
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)
iQCVAwUBSd3Vf3EjvBPtn
g encoded data, in which case the header names are
probably still strings of ASCII-ish unicodes and the values are
bytes. It's this distinction (and I think the competing use cases)
that make a true Python 3.x API for email more complicated.
Thinking about this stuff makes me nostalgic for th
On Apr 9, 2009, at 11:08 AM, Bill Janssen wrote:
Barry Warsaw wrote:
Anyway, aside from that decision, I haven't come up with an
elegant way to allow /output/ in both bytes and strings (input is I
think theoretically easier by sniffing the arguments).
Probably a good thing. It
don't think that there's really any
ambiguity at all about what type you should be getting.
In that case, we really need the bytes-in-bytes-out-bytes-in-the-chewy-
center API first, and build things on top of that.
-Barry
PGP.sig
Description: This is a digitally signed message p
On Apr 9, 2009, at 10:52 PM, Aahz wrote:
On Thu, Apr 09, 2009, Barry Warsaw wrote:
So, what I'm really asking is this. Let's say you agree that there
are
use cases for accessing a header value as either the raw encoded
bytes or
the decoded unicode. What should this return:
message as text on the boundaries. Internally, it should be all bytes
(although even that is a pain to write ;).
-Barry
PGP.sig
Description: This is a digitally signed message part
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.
On Apr 9, 2009, at 11:55 AM, Daniel Stutzbach wrote:
On Thu, Apr 9, 2009 at 6:01 AM, Barry Warsaw wrote:
Anyway, aside from that decision, I haven't come up with an elegant
way to allow /output/ in both bytes and strings (input is I think
theoretically easier by sniffing the argu
want to add an interface, probably
to the parser and message class, to allow an application to store
message payloads in other than memory. Parsing and holding onto
messages with huge payloads can kill some applications, when you might
not care too much about the actual payload content.
B
On Apr 9, 2009, at 11:21 PM, Nick Coghlan wrote:
Barry Warsaw wrote:
I don't know whether the parameter thing will work or not, but you're
probably right that we need to get the bytes-everywhere API first.
Given that json is a wire protocol, that sounds like the right
approach
f
is is waiting for input from Mark
Dickinson, and it relates to test_cmath failing on Solaris 10. If
Mark fixes that, he's welcome to commit it, otherwise I will remove
the release blocker tag on the issue and release 2.6.2 anyway.
Plan on me tagging 2.6.2 final Sunday evening.
Chee
27;] = b'Some Bytes'
or
message.headers['Subject'] = Header(bytes=b'Some Bytes',
encoding='utf-8')
Explicit is better than implicit, right?
Yes.
Again, I really like the general idea, if I might quibble about some
of the details. Thanks for a great
On Apr 9, 2009, at 11:41 PM, Tony Nelson wrote:
At 22:38 -0400 04/09/2009, Barry Warsaw wrote:
...
So, what I'm really asking is this. Let's say you agree that there
are use cases for accessing a header value as either the raw encoded
bytes or the decoded unicode. What should t
I put that hack-
drink-coffee-twitter clone?
-Barry
PGP.sig
Description: This is a digitally signed message part
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.pytho
values.
I disagree. IMHO, structured header types should have object values,
and something like
While I agree, there's still a need for a higher level API that make
it easy to do the simple things.
message['to'] = "Barry 'da FLUFL' Warsaw "
should be s
t a 'thdr' was that we'd want to index
'by' it. :)
-Barry
PGP.sig
Description: This is a digitally signed message part
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
U
On Apr 10, 2009, at 2:06 PM, Michael Foord wrote:
Shouldn't headers always be text?
/me weeps
PGP.sig
Description: This is a digitally signed message part
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/py
On Apr 10, 2009, at 3:06 PM, Stephen J. Turnbull wrote:
Bill Janssen writes:
Barry Warsaw wrote:
In that case, we really need the
bytes-in-bytes-out-bytes-in-the-chewy-
center API first, and build things on top of that.
Yep.
Uh, I hate to rain on a parade, but isn't that how we ar
On Apr 11, 2009, at 8:20 AM, Mark Dickinson wrote:
On Fri, Apr 10, 2009 at 2:31 PM, Barry Warsaw
wrote:
bugs.python.org is apparently down right now, but I set issue 5724 to
release blocker for 2.6.2. This is waiting for input from Mark
Dickinson,
and it relates to test_cmath failing on
. Possibly
others. The default would probably be some unstructured parser for
headers like Subject.
-Barry
PGP.sig
Description: This is a digitally signed message part
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman
tting the set of realname/addresses out of
the header?
-Barry
PGP.sig
Description: This is a digitally signed message part
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.p
On Apr 11, 2009, at 8:39 AM, Chris Withers wrote:
Barry Warsaw wrote:
>>> message['Subject']
The raw bytes or the decoded unicode?
A header object.
Yep. You got there before I did. :)
Okay, so you've picked one. Now how do you spell the other way?
str(messa
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
ba...@python.org
Python 2.6/3.0 Release Manager
(on behalf of the entire python-dev team)
PGP.sig
Description: This
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
Python-Dev@python.org
http://mail.pyt
On Apr 17, 2009, at 5:42 AM, Piet van Oostrum wrote:
Maybe a link to the MacOSX image can also be added to
http://www.python.org/download
Done.
-Barry
PGP.sig
Description: This is a digitally signed message part
___
Python-Dev mailing list
Python
working on splitting
two of my Tools (pynche and world) off into separate projects and
can't remember what we decided about that.
-Barry
PGP.sig
Description: This is a digitally signed message part
___
Python-Dev mailing list
Python-Dev
unicode and bytes if its not utf-8 data. Why not simply return string
if its valid
utf-8 otherwise return bytes? Then in the app you check for the type
for the object,
string or byte and deal with reporting errors appropriately.
Barry
___
Python
s if its a string no problem, if its
a byte deal with the exceptions seems simple.
How do I do this detection with the PEP proposal?
Do I end up using the byte interface and doing the utf-8 decode
myself?
Barry
___
Python-Dev mailing list
Python
e.
How do I do this detection with the PEP proposal?
Do I end up using the byte interface and doing the utf-8 decode
myself?
No, you should encode using the "strict" error handler, with the
locale encoding. If the file name encodes successfully, it's correct,
otherwise, it&#x
On May 1, 2009, at 5:55 PM, Michael Foord wrote:
P for Proposal (to replace Active Proposal)? Every active PEP is a
proposal...
+1
Maybe even s/Active/Proposed/g ?
-Barry
PGP.sig
Description: This is a digitally signed message part
___
Python
fixes the issue. This did not appear to happen
site-wide, just for python-checkins AFAICT.
-Barry
PGP.sig
Description: This is a digitally signed message part
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/p
x27;t land in trunk until they too are solid and complete
(with docs and tests). If a particular feature doesn't make it, it'll
just wait until the next release, which would be only 12 months off
instead of almost 2 years off.
-Barry
PGP.sig
Description:
ranch. Nothing goes into Python 2.7 that isn't already in Python 3.1.
-Barry
PGP.sig
Description: This is a digitally signed message part
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscr
ts alone might not tell you everything). Then at least
you can get a rough idea of how generally popular a module is in the
wider community. Also, a module should have to live on its own two
feet for while on Cheeseshop before being considered for inclusion in
the stdlib.
-Barry
PGP.s
2.x branch. Meaning, add it to 3.x first and then
backport if you want. I don't believe a new feature has to be in a /
released/ version of 3.x first for it to show up in the next 2.x
release.
-Barry
PGP.sig
Description: This is a digi
eXY-maint"
because this will point to the long lived maintenance branch.
The fork
I'm sure this has been discussed but I missed it. Why was this change
made? If nothing else, it breaks many years of tradition.
-Barry
PGP.sig
Description: This is a digitally signed message pa
er code.python.org, or sys.revision), *cannot*
be agnostic of the specific technology.
Agreed. I originally chose code.python.org because I didn't want to
be biased (maybe I should have been :). +1 for hg.python.org. I'd
prefer to spell out sys.mercurial_revision.
-Barry
PG
not possible or feasible, then given the documented
sys.subversion semantics, I think we should just freeze the tuple at
e.g. ('CPython', 'branches/release26-maint', None).
-Barry
PGP.sig
Description: This is a digitally signed message part
__
should be
working. I don't know what if anything might be wrong with the
gateway. Are both directions affected or only one way?
-Barry
PGP.sig
Description: This is a digitally signed message part
___
Python-Dev mailing list
Python-De
"we're all adults here"[1]? I have no problem
with making it difficult but possible to write buggy but practical
code. Software engineering is a messy business.
-Barry
[1] That may not be literally true any more, but still :)
PGP.sig
Description: This is a digi
ke that on
23-September.
Does anybody have objections to that schedule? If not, I'll try to
spend some time over the next few days looking at outstanding bugs,
and marking release blockers, etc.
-Barry
PGP.sig
Description: This is a digitally sign
On Sep 9, 2009, at 9:29 AM, Nick Coghlan wrote:
Barry Warsaw wrote:
I had previously wanted to release Python 2.6.3 over the summer,
but for
various personal reasons, the summer was just too insane. I'd like
to
reschedule a 2.6.3 release, shooting for final release on 25-
September.
On Sep 9, 2009, at 1:29 PM, Ned Deily wrote:
In article <11a6545d-7204-4f61-b55b-1cc77cb56...@python.org>,
Barry Warsaw wrote:
I still want to release by the 25th, but I'd be willing to move the
rc
to Monday the 21st. We're really just trying to avoid a brown bag
moment
On Sep 10, 2009, at 12:57 PM, Martin v. Löwis wrote:
Barry Warsaw schrieb:
I had previously wanted to release Python 2.6.3 over the summer,
but for
various personal reasons, the summer was just too insane. I'd like
to
reschedule a 2.6.3 release, shooting for final release on 25-
Sept
On Sep 16, 2009, at 7:53 AM, Antoine Pitrou wrote:
Of course, all this will perhaps have been discussed before the
summit.
Sure, but not resolved. :)
I do think stdlib evolution should be high on the list of topics.
-B
PGP.sig
Description: This is a digitally signed message part
___
rtain on is the IDLE hang. If
this only affects OS X 10.6 and there is no progress on it by the time
2.6.3 is otherwise ready, I'm willing to knock this down in severity.
Martin, you have the other showstopper bug for 2.6.3. Do you think
you will be able to fix that one in time
, so the solution would
make a
good candidate for 2.6.3?
I made this a release blocker, but reserve the right to bump it down
again.
-Barry
PGP.sig
Description: This is a digitally signed message part
___
Python-Dev mailing list
Python-Dev
On Sep 25, 2009, at 4:18 PM, Jesse Noller wrote:
Barry - this is your call, but I think
http://bugs.python.org/issue6990 should be a rel blocker too.
Done.
-Barry
PGP.sig
Description: This is a digitally signed message part
___
Python-Dev mailing
a decision that the only the caller can decide
why not add a keyword param to control the parsing?
IPv4Network( '192.168.1.1/16', syntax='loose' )
(I'm sure syntax='loose' is not right but you get the idea.)
Barry
___
ith a x86_64 Python image.
No matter what I use for archs its always the same.
I would expect to see -arch arg to GCC but it is not there.
export CFLAG="-arch i386"
did not work either.
Am I doing something wrong or is this broken o
16')
You can decide on which bug this shows.
1) parse must raise exception on bad input
2) repr does not show input
Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail
On 27 Sep 2009, at 03:12, Ned Deily wrote:
In article <90a90a3c-e037-4fca-95d2-a46a5c6dd...@barrys-emacs.org>,
Barry Scott wrote:
I'm working with http://svn.python.org/projects/python/trunk on Mac
OS
X 10.6.1
using Apples xcode gcc 4.2.1.
When I run the followi
e fix important enough to include without the test?
-Barry
PGP.sig
Description: This is a digitally signed message part
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.pytho
ced me that argparse is a win.
-Barry
PGP.sig
Description: This is a digitally signed message part
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/option
wisty if-conditions are de-facto part of getopt's
API.
-Barry
PGP.sig
Description: This is a digitally signed message part
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscr
this entire thread, but I don't see
much point in making it easy to go from getopt to argparse. The two
are so different that I think you're either going to jump all in or
not. Maybe that's just me though as I really don't see much use for
getopt any more (even for throwa
On Sep 29, 2009, at 9:43 PM, s...@pobox.com wrote:
It's been awhile since I rebuilt Python and ran the test suite. This
evening I noticed this on my Mac (OS X 10.5):
What version of Python?
-Barry
PGP.sig
Description: This is a digitally signed message
u pretty much know how to do it for any supporting API. So we
should adopt it across all of the standard library.
-Barry
PGP.sig
Description: This is a digitally signed message part
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.pyt
. No commits to the 2.6 tree are allowed
without checking with me first (via IRC, bug tracker or email). I'll
make an exception for svnmerge bookkeeping.
-Barry
PGP.sig
Description: This is a digitally signed message part
___
Python-De
. Barring any unforeseen
problems, we will make the final 2.6.3 release this Friday, October
2nd. Please give this release candidate a spin and let us know if you
encounter any show stopping problems.
Enjoy,
-Barry
PGP.sig
Description: This is a digitally signed message part
On Sep 30, 2009, at 11:22 AM, Steven Bethard wrote:
On Wed, Sep 30, 2009 at 5:21 AM, Barry Warsaw
wrote:
On Sep 29, 2009, at 11:15 PM, Martin v. Löwis wrote:
I would propose that the format argument gets an argument name,
according to the syntax it is written in. For PEP 3101 format,
I
#x27;A foo of type {type}, defaulting to {42}')
(although that last looks weird ;).
-Barry
PGP.sig
Description: This is a digitally signed message part
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/pyth
r than that, I think argparse supports Guido's use case very nicely.
-Barry
PGP.sig
Description: This is a digitally signed message part
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/pyth
t I
will have bugs because a translator forgot the trailing 's'. This
exactly the motivation that led to PEP 292 $-strings.
In fact, while we're at it, it would be kind of cool if I could use $-
strings in log templates. Antoine's idea of accepting a callable
might fit th
On Sep 30, 2009, at 3:36 PM, Sridhar Ratnakumar wrote:
2.6.3rc1 builds fine on Linux x86/x86_64, MacOSX 10.4 ppc/x86,
Windows 32bit/64bit, HP-UX, AIX and Solaris just like 2.6.2 did.
Thanks for the feedback! Did you run the test suite on any of these?
-Barry
PGP.sig
Description: This is
, **kwargs):
self.fmt = fmt
self.args = args
self.kwargs = kwargs
def __str__(self):
return string.Template(self.fmt).substitute(*args, **kwargs)
Right, thanks. This is a very cool feature that I didn't know logging
supported!
-Barry
PGP.sig
Description: This
this into
2.6.3. It
really needed to be brought up back when Barry called for
identification
of significant 2.6 bugs and patches rather than after the RC had
already
been released.
Right. Scott, you can get reviews and support for the patch now so
that the bug can be addressed in
release like
breaking "import sys" or the build process, etc.
We're always gonna have bugs, so that can't be it. :)
-Barry
PGP.sig
Description: This is a digitally signed message part
___
Python-Dev mailing list
Python
On Oct 1, 2009, at 5:48 PM, Sridhar Ratnakumar wrote:
No new significant failures have been found. (Some trivial issues
have been reported in the bug tracker).
Fantastic, thanks. I'll be tagging the final release soon.
-Barry
PGP.sig
Description: This is a digitally signed message
ition to {}-strings might have limited usefulness, but
enabling their use has clear benefits. You just then have to decide
how important TOOWTDI is.
-Barry
PGP.sig
Description: This is a digitally signed message part
___
Python-Dev mailing list
Py
e see
http://docs.python.org/whatsnew/2.6.html
Please report bugs for any Python version in the Python tracker.
http://bugs.python.org
Enjoy,
-Barry
Barry Warsaw
ba...@python.org
Python 2.6 Release Manager
(on behalf of the entire python-dev team)
PGP.sig
Description: This is a digi
use of $-strings.
I also don't think this is a case of anti-TOOWTDI. For most
situations {}-strings are great (IMO), but in the specific translation
domain, I suspect $-strings are still better.
-Barry
PGP.sig
Description: This is a digitally signed message part
_
uld also render
existing translations of the %-formatted string templates useless.
Speaking of translation support has xgettext been updated to support {}?
It is a life saver to have xgettext report that "This %s and %s" is not
translatable.
Barry
_
quick
Python 2.6.4.
-Barry
PGP.sig
Description: This is a digitally signed message part
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/pytho
6.2, 2.6.1,
and 2.6.0, right? Have you tried the fix in those older versions to
be sure?
If, as I hope, the answer to that is "yes", then I strongly support
releasing a fixed setuptools instead of reverting the change to Python.
-Barry
PGP.sig
Description: This is a digitally
.
3) We (a.k.a. Tarek with our blessing) hijacks the setuptools name
(e.g. on cheeseshop) and releases a new version
I still hope #2 happens, but let's have a deadline for when the more
drastic measures will be taken.
-Barry
PGP.sig
Description: This is a digitally
On Oct 5, 2009, at 10:50 AM, Daniel Stutzbach wrote:
On Mon, Oct 5, 2009 at 9:32 AM, Barry Warsaw wrote:
If, as I hope, the answer to that is "yes", then I strongly support
releasing a fixed setuptools instead of reverting the change to
Python.
How do your propose to get the
On Oct 4, 2009, at 4:11 AM, Nick Coghlan wrote:
Barry Warsaw wrote:
I also don't think this is a case of anti-TOOWTDI. For most
situations
{}-strings are great (IMO), but in the specific translation domain, I
suspect $-strings are still better.
I agree that keeping string.Template a
perator) is
becoming more appealing...
-Barry
PGP.sig
Description: This is a digitally signed message part
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailma
them. Hopefully we can avoid the situation with 2.6.3 having
such critical bugs.
2.6.4 final is planned for 18-October.
Cheers,
-Barry
PGP.sig
Description: This is a digitally signed message part
___
Python-Dev mailing list
Python-Dev@python.org
n in 2.6.3. However if Martin von Loewis approves of the
patch and feels strongly that it should go in 2.6.4, I'll allow it.
-Barry
PGP.sig
Description: This is a digitally signed message part
___
Python-Dev mailing list
Python-Dev@
want us to be very careful about 2.6.4. This isn't a normal bug fix
release, it's specifically there to remove the brown paper bag of
2.6.3 from our heads. So let's be conservative and fix this one in
2.6.5.
-Barry
PGP.sig
Description: This is a digitally
s for "not --disable-toolbox-glue", the _scproxy
module has no dependencies on the toolbox glue.
The attached patch should fix the issue,
Patch fixed it. Barry, can Ronald apply the patch?
Since this is a 2.6.3 regression, yes.
Thanks,
-Barry
PGP.sig
Description: This is a digitally
On Oct 8, 2009, at 4:31 AM, Tarek Ziadé wrote:
- no more namespaced packages system, if PEP 381 (namespaces package
support) makes it to 2.7
Make that PEP 382:
http://www.python.org/dev/peps/pep-0382/
-Barry
PGP.sig
Description: This is a digitally signed message part
On Oct 8, 2009, at 8:45 AM, Zvezdan Petkovic wrote:
On Oct 7, 2009, at 2:09 PM, Barry Warsaw wrote:
I want us to be very careful about 2.6.4. This isn't a normal bug
fix release, it's specifically there to remove the brown paper bag
of 2.6.3 from our heads. So let's be c
. Can
we close that (again) now?
http://bugs.python.org/issue7064
I am still being very conservative about what goes in 2.6.4. Only
regressions introduced in 2.6.3 are being accepted. There's plenty of
time after that for patches to go in for 2.6.5.
-Barry
PGP.sig
Description:
, at least
we're on the same page now it seems. :-)
:)
-Barry
PGP.sig
Description: This is a digitally signed message part
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Uns
1001 - 1100 of 2826 matches
Mail list logo
